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 – [email protected]

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


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”


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’


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


Certificate fields: serialNumber


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


Subject, Issuer ordering

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


Subject, Issuer RDN components

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



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

software that still cannot interpret subjectAltName

SHOULD NOT be used



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


Application guidance: extKeyUsage

more of these will be there, and should be documented

input welcomed!


Things that apparently are not obvious


Venturing into Java may reveal unexpected quirks


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


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


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?

brief history and background

Documents