Certificate Profile Revisited certificates considered harmful David Groep, TAGPMA Ottawa meeting, Ju

1
Certificate Profile Revisitedcertificates
considered harmfulDavid Groep, TAGPMA Ottawa
meeting, July 2006
2
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

3
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 lt 0.9.7? OID represented as SN
  (sic!)
• OpensSSL gt 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

4
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 its not obvious to CAs to they should include
  extendedKeyUsage, since the EE certs initially
  appear to work

5
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

6
Certificate fields serialNumber
7
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

8
Subject, Issuer ordering

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

9
Subject, Issuer RDN components

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

10
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

11
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

12
Application guidance extKeyUsage

• more of these will be there, and should be
  documented
• input welcomed!

13
Things that apparently are not obvious
14
Venturing into Java may reveal unexpected quirks
15
Guidance

• CA root/subordinate certificates
• best to keep minimal
• basicConstraints critical, CA TRUE
• keyUsage critical, keyCertSign, cRLSign
• thats 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

16
Guidance EE certificates

• needed by profile or software
• basicConstraints critical, CAFALSE (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,serverAuth(or
  nsCertTypeSSLServer,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

17
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 _at_ GGF18?

18

• QD