Policy-Discussion

[Michael Tänzer <michael.taenzer AT cacert.org>]

Hi,

apart from the controversial question of whether or not we should set a
minimum key size there are some other (and I expect less controversial)
changes to the CPS that need to be discussed so I'd like to split them
from the other discussion:

https://www.cacert.org/policy/CertificationPracticeStatement.php#p7.1.2

So here's the abstract for those who don't like reading long mails:
<abstract>
drop cRLSign on client certs because it's downright dangerous and has no
application whatsoever. Add keyAgreement because it allows you to use
diffie-hellman keys. Drop serverAuth from client certs and probably
clientAuth from server certs too. Add crlDistributionPoints everywhere
because it's needed for revocation on clients who can't do OCSP for some
reason.
</abstract>


_Client Certificate Extensions_

Change "keyUsage=digitalSignature,keyEncipherment,cRLSign" to
"keyUsage=digitalSignature,keyEncipherment,keyAgreement"

Reasoning:
- 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.


Change
"extendedKeyUsage=emailProtection,clientAuth,serverAuth,msEFS,msSGC,nsSGC"
to "extendedKeyUsage=emailProtection,clientAuth,msEFS,msSGC,nsSGC"

Reasoning:
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. 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"

Reasoning:
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
value: 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).



_Server Certificate Extensions_

Change "keyUsage=digitalSignature,keyEncipherment" to
"keyUsage=digitalSignature,keyEncipherment,keyAgreement"

Reasoning:
Same reasoning as for client certs, minus the cRLSign part.


Change "extendedKeyUsage=clientAuth,serverAuth,nsSGC,msSGC" to
"extendedKeyUsage=serverAuth,nsSGC,msSGC"

Reasoning:
Analogous to the client certs, although it may be argued that a server
may play the role of a client in the communication with another server.


Add "crlDistributionPoints=URI:<crlUri> where <crlUri> is replaced with
the URI where the certificate revocation list relating to the
certificate is found"

Reasoning:
Same as above.



_Code Signing Certificates Extensions_

Here we could go two ways: a) Make the code signing certificate a client
certificate with additional capabilities as it is now or b) make the
code signing certificate a totally separate kind of certificate.

b) has the theoretical advantage that it only gives the privileges to
those certificates that are absolutely needed and probably less messages
are signed with the same key while a) is probably more usable.

So I'm slightly favouring a).


Under a):
Change "keyUsage=digitalSignature,keyEncipherment" to
"keyUsage=digitalSignature,keyEncipherment,keyAgreement" and add
"crlDistributionPoints=URI:<crlUri> where <crlUri> is replaced with the
URI where the certificate revocation list relating to the certificate is
found"

Reasoning:

Same as above. (Strange that serverAuth is not present here while it is
in normal client certs)


Under b):
Change "keyUsage=digitalSignature,keyEncipherment" to
"keyUsage=digitalSignature",
"extendedKeyUsage=emailProtection,clientAuth,codeSigning,msCodeInd,msCodeCom,msEFS,msSGC,nsSGC"
to "extendedKeyUsage=codeSigning,msCodeInd,msCodeCom,msSGC,nsSGC" and
add "crlDistributionPoints=URI:<crlUri> where <crlUri> is replaced with
the URI where the certificate revocation list relating to the
certificate is found"

Reasoning:
This drastically reduces the rights this certificate has and therefore
reduces the attack vectors. But this may be a tiny gain given the
usability problems it implies ("which of my certs is actually the code
signing cert?").


Additional information on those extensions:
- Key Usage: https://tools.ietf.org/html/rfc5280#section-4.2.1.3
- Extended Key Usage: https://tools.ietf.org/html/rfc5280#section-4.2.1.12
- CRL Distribution Points:
https://tools.ietf.org/html/rfc5280#section-4.2.1.13
- General information from the OpenSSL perspective:
http://linux.die.net/man/5/x509v3_config



Cheers,
-- 
Michael Tänzer
CAcert Support Team Leader

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature