Subject: RE: EKU: ambiguity in RFC 3280

From: "Manger, James H" <[email-masked]>
Date: Wed, 3 Aug 2005 12:58:05 +1000

On the topic of EKUs…

Do any public CAs allow the user to choose the EKU values (or whether or not to include the extension)?
Do any include anyExtendedKeyUsage?

VeriSign, for instance, offer SSL (actually HTTPS), personal (email) and code signing certificates.  I assume these include { id-kp-serverAuth, id-kp-clientAuth }, { id-kp-emailProtection } and { id-kp-codeSigning } EKU extension values respectively.  None of these certificates can be reliably used for another purpose, such as signing a SOAP message, as relying parties that understand (the non-critical) EKU will reject the certificate as it does not include anyExtendedKeyUsage.

P.S. The minimal text associated with the id-kp-{client|server}Auth EKU values is “TLS WWW {client|server} authentication”.  “WWW” implies (to me) that these purposes are specifically for HTTPS.  Other uses of TLS/SSL (such as LDAP over TLS) are not covered by these identifiers.  Perhaps 3280bis could make this a bit clearer by explicitly mentioning HTTP, instead of just WWW.