Adjustments to the CPS Regarding the Key Usage Attributes in Certificates
see Policy Decisions p20111113
Abstract
- Drop cRLSign on client certs because it's downright dangerous and has no application whatsoever.
- Add keyAgreement on all end-user certs because it allows you to use diffie-hellman keys.
- Mark keyUsage extension as critical as required by RFC.
- Drop serverAuth from client certs.
- Add crlDistributionPoints everywhere because it's needed for revocation on clients who can't do OCSP for some reason.
- Add subjectAltName to code signing certs as they should be extended capability client certs
Full Version
It is resolved that the CPS section 7.1.2 "Certificate Extensions" is changed as following:
Client Certificates
keyUsage=digitalSignature,keyEncipherment,cRLSign
Changed to
keyUsage=digitalSignature,keyEncipherment,keyAgreement(critical)
Reasons:
cRLSign means that the certificate is able to sign certificate revocation lists (those blacklists that contain the serial numbers of revoked certs) and should only be present on certificates that are under the control of CAcert because it means that if you are an attacker and compromise a cert you could still produce a valid CRL which doesn't contain that cert although it has been revoked in our system. Dropping this usage extension is critical!
keyAgreement means that you will be able to use cryptographic primitives like Diffie-Hellman keys in certificates. While adding this is not critical it gives members more choice how to secure themselves.
nonRepudiation is not added as it would conflict with CPS section 1.4.3 "Unreliable Applications" which explicitly states "Non-repudiation is not to be implied from use of CAcert certificates. Rather, certificates may provide support or evidence of actions, but that evidence is testable in any dispute."
Marking the keyUsage as critical (if present) is required by the RFC
extendedKeyUsage=emailProtection,clientAuth,serverAuth,msEFS,msSGC,nsSGC
Changed to
extendedKeyUsage=emailProtection,clientAuth,msEFS,msSGC,nsSGC
Reasons:
- Client certificates should not be used for the server authentication in TLS therefore the serverAuth part should be dropped. If you need it use a server certificate which has it. It also may pose a problem for risk evaluation if we treat client certs like server certs. Dropping this is not as critical however.
Add
crlDistributionPoints=URI:<crlUri> where <crlUri> is replaced with the URI where the certificate revocation list relating to the certificate is found
Reasons:
Adding the crlDistributionPoints is critical to make revocation work for clients that can't or don't want to use OCSP (e.g. because they're too old, don't have a direct internet connection or a company might take caching into account). We keep CRLs anyway so we need to advertise them to the clients in the certificate.
- As for not specifying a concrete URL: If we have multiple subroots we need a separate CRL for each of them so specifying it for each of them in the policy would be too much. Also as we scale up we might want to split up our CRLs into multiple per subroot which keeps them smaller (e.g. all certificates issued in one month are handled in one CRL). The CRL is already quite huge (more than 4 MB) so this really is a problem for scalability (fortunately there's OCSP but that doesn't solve all problems).
Server Certificates
keyUsage=digitalSignature,keyEncipherment
Change to
keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)
Reasons:
Same as above
Add
crlDistributionPoints=URI:<crlUri> where <crlUri> is replaced with the URI where the certificate revocation list relating to the certificate is found
Reasons:
Same as above
Code Signing Certificates
keyUsage=digitalSignature,keyEncipherment
Change to
keyUsage=digitalSignature,keyEncipherment,keyAgreement (critical)
Reasons:
Same as above
Add
crlDistributionPoints=URI:<crlUri> where <crlUri> is replaced with the URI where the certificate revocation list relating to the certificate is found
Reasons:
Same as above
Add
subjectAltName=(as per ยง3.1.1.).
Reasons:
- Make the code signing certificate indeed a client certificate with extended capabilities (this picks up a comment already present in the CPS). If we would really like to make code signing and client certs completely different certs we should drop other fields from the cert too in order to reduce risks, but that comes at the cost of reduced usability.
References
Additional information on those extensions: