Hi Steffen: On March 12, 2009 06:41:33 am Steffen Fiksdal wrote: > Hi! > > I am currently looking into the usage of EKU's for CA certificates and > hope someone of you guys can help me. > > Given the following scenario: > 1) A CA certificate with EKU "Client Authentication". This would mean that the CA certificate is ONLY usable for Client Authentication - as is stated in RFC5280:
"If the extension is present, then the certificate MUST only be used for one of the purposes indicated." It says earlier: "In general, this extension will appear only in end entity certificates." And, specifically, it mentions for CA Certificates: " Certificate using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application. If a CA includes extended key usages to satisfy such applications, but does not wish to restrict usages of the key, the CA can include the special KeyPurposeId anyExtendedKeyUsage in addition to the particular key purposes required by the applications. " So, while what you are doing is not, strictly speaking, disallowed by the RFC, it is certainly NOT encouraged. > 2) An enterprise certificate issued by the CA certificate in 1) with EKU > "Client Authentication" and "Server Authentication" > I presume that you mean an End Entity Certificate... > And my questions are: > 1) What is the purpose of setting EKU's for CA certificates? These isn't one - the EKU values in CA Certificates should be empty as indicated above. Otherwise you can have some very strange effects, depending on your interpretation of the RFC. > 2) Is the scenario above "allowed" ? As I mentioned above, it may be allowed, but it would mean that the CA certificate is only usable for (depending on your interpretation): 1) Performing Client Authentication ONLY with the CA Certificate (i.e.: you couldn't use the CA certificate to sign other certificates) or 2) That the CA is *ONLY* allowed to issue certificates that are used for client Authentication *ONLY*. > 3) Should a certificate chain validation of the above scenario succeed? > I would say "probably not" - since the serverAuth Key Usage is outside of the "allowed" uses for the CA Certificate. > I tried the "openssl verify -purpose sslclient" on the above scenario and > the validation succeeded. If openssl says it's ok, then it is ok :) > > My reason for asking is that we struggle with a chain validation of the > above scenario using some other technology... > Please keep in mind that the path validation built into OpenSSL is fairly rudimentary, and doesn't fully implement the entire algorithm in RFC5280 (unless, I believe, you a) are somehow able to provide all of the CRL or OCSP information, and b) you are using the most up to date OpenSSL, which has the understanding of nameConstraints, policyMappings, and even then, the support is somewhat hit and miss if you have nameConstraints set to "critical" ), so relying on it to perform 100% correct RFC3280/RFC5280 PDVal is not always possible. If you are looking for a tool that more fully supports full PDVal (and which integrates with OpenSSL), you may want to take a look at Pathfinder :) http://www.carillon.ca/tools/pathfinder.php Have fun. -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
