1 / 18

Brief History and Background

Certificate Profile Revisited ‘certificates considered harmful’ David Groep, TAGPMA Ottawa meeting, July 2006. Brief History and Background. In the Beginning was Mike Helm Grid Certificate Extensions Profile (CAOPS-WG Community Practice Doc) March 2003 (GGF10)

christianmoore
Télécharger la présentation

Brief History and Background

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Certificate Profile Revisited‘certificates considered harmful’David 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 <= 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”

  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 it’s 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 • 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

  16. 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

  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 @ GGF18?

  18. Q&D

More Related