brief history and background

Certificate Profile Revisited‘certificates considered harmful’

David Groep, TAGPMA Ottawa meeting, July 2006

Cert Profile, TAGPMA Ottawa – July 2006 - 2David Groep – davidg@eugridpma.org

Brief History and Background

In the Beginning was Mike Helm Grid Certificate Extensions Profile

(CAOPS-WG Community Practice Doc) March 2003 (GGF10) List of attributes/extensions and their associated

questions Was probably too early, and did not progress much

(due to lack of community interest at the time?)

Growth of the CA distribution and Grid deployment without practical guidance for CAs many extensions used (or omitted), inconsistent use ‘liberal’ interpretation of relevant standards

(both by the CAs and by middleware) Naming mess caused by (older?) versions of OpenSSL

Cert Profile, TAGPMA Ottawa – July 2006 - 3David Groep – davidg@eugridpma.org

Some examples: serialNumber RDN

serialNumber RDN attribute in the subject name originally supposed to be a hardware s/n standard meaning extended to include unique identifiers also

for persons one un-named CA managed to convince OpenCA to have

the certificate s/n embedded in the subject DN !(so much for renew/rekey with the same DN …)

Attribute also suffered name confusion in OpenSSL OpenSSL <= 0.9.7? : OID represented as “SN” (sic!) OpensSSL > 0.9.7? : represented as “serialNumber” (correct)

since typical DN comparison in the grid is based on the string representation

subscriber is left frustrated issue is raised over and over again in grid support channels the CA package distributor (me) get complaints for “non-

functioning CAs”

Cert Profile, TAGPMA Ottawa – July 2006 - 4David Groep – davidg@eugridpma.org

Some examples: LDAP server certs

some clients (in this case OpenLDAP) check for the appropriate extensions in the server cert extendedKeyUsage: serverAuth

ORnsCertType: server

one of these must be present, or openLDAP will fail

but some grid middleware can live without having either set, and then allow all usage(setting either attribute but not allowing server use correctly makes the middleware reject such a server, though)

so it’s not obvious to CAs to they should include extendedKeyUsage, since the EE certs initially ‘appear to work’

Cert Profile, TAGPMA Ottawa – July 2006 - 5David Groep – davidg@eugridpma.org

Aims

Document described each relevant attribute/extension what is does (be it good or harm) to the major pieces of

(grid) software guidance for new CAs define (for already accredited CAs) what must be changed

also: make clear to our software development community where we expect the software to actually adhere to standards

Initial draft out there. Planned updates: rewrite to use RFC2119 language everywhere cover more attributes/extensions example and input on what actually works and is in use

Cert Profile, TAGPMA Ottawa – July 2006 - 6David Groep – davidg@eugridpma.org

Certificate fields: serialNumber

Cert Profile, TAGPMA Ottawa – July 2006 - 7David Groep – davidg@eugridpma.org

Certificate fields: Issuer and Subject

Ordering of the RDN is important as well RFC3280bis may finally have guidance C (or the DCs) must be first in the SEQUENCE,

CN must be last in the ASN.1 SEQUENCE

Cert Profile, TAGPMA Ottawa – July 2006 - 8David Groep – davidg@eugridpma.org

Subject, Issuer ordering

New 3280bis draft might have some guidance anyway, never start the SEQUENCE with CN …

Cert Profile, TAGPMA Ottawa – July 2006 - 9David Groep – davidg@eugridpma.org

Subject, Issuer RDN components

as mentioned before, that was a CA that did that!

Cert Profile, TAGPMA Ottawa – July 2006 - 10David Groep – davidg@eugridpma.org

Subject, Issuer RDN components

our good old friend … ahum might still be needed for non-compliant S/MIME

software that still cannot interpret subjectAltName

SHOULD NOT be used

Cert Profile, TAGPMA Ottawa – July 2006 - 11David Groep – davidg@eugridpma.org

Subject, Issuer RDN components

luckily, there are no accredited CAs with uid or userid as of yet

as both are valid according to some standard, this confusion will never go away, and remains dangerous

this MUST NOT be used

Cert Profile, TAGPMA Ottawa – July 2006 - 12David Groep – davidg@eugridpma.org

Application guidance: extKeyUsage

more of these will be there, and should be documented

input welcomed!

Cert Profile, TAGPMA Ottawa – July 2006 - 13David Groep – davidg@eugridpma.org

Things that apparently are not obvious

Cert Profile, TAGPMA Ottawa – July 2006 - 14David Groep – davidg@eugridpma.org

Venturing into Java may reveal unexpected quirks

Cert Profile, TAGPMA Ottawa – July 2006 - 15David Groep – davidg@eugridpma.org

Guidance

CA root/subordinate certificates best to keep minimal

basicConstraints = critical, CA: TRUE keyUsage = critical, keyCertSign, cRLSign

that’s all that is actually needed

policy oid looks nice, but will certainly become out-of-date soon

CRL Distribution Points is intended for EE certs

Cert Profile, TAGPMA Ottawa – July 2006 - 16David Groep – davidg@eugridpma.org

Guidance EE certificates

needed by profile or software basicConstraints = critical, CA:FALSE (but …) keyUsage = critical, digitalSignature, keyEncipherment,

dataEncipherment(digital Signature needed for, e.g. S/MIME rekeying mails)

cRLDistributionPoints with a URL certificatePolicies: at least one OID, but more in the

near future (for the IGTF AP, 1SCPs, …)

extendedKeyUsage = {client,server}Auth(or nsCertType=SSL{Server,Client}, but that one is obsolete)needed for, e.g. OpenLDAP

more extendedKeyUsage might be needed or useful for user certs, more testing is required

Cert Profile, TAGPMA Ottawa – July 2006 - 17David Groep – davidg@eugridpma.org

To do

document is certainly not complete v0.4 (on the web soon) has been updated to

better reflect the 3280bis draft much more input needed

text but also application testing

in-depth discussion on a complete draft @ GGF18?

Q&D