The Classic X.509 Profile Update and other assorted issues David Groep, July 2007

Classic X.509 AP updates (v4.1) Major points addressed in 4.1 explicit definition of what we mean with “should” FQDN “ownership” maximum 5 years without any kind of checking reformulated on-line CA architectures includes explicitly the two pre-vetted architectures keyUsage SHOULD (was MUST) be critical in CA certs compliance with Grid Certificate Profile draft (in OGF)

Classic v4.1 Updates (1) clearer definition of what we mean by should FQDN ‘ownership’ A form of validation after at most five years this has been buried in very old minutes and has now been made explicit

Classic v4.1 Updates (2) On-line CA architectures

Classic v4.1 Updates (4) keyUsage extensions SHOULD be critical in a CA cert this used to be a MUST, but that would unnecessarily exclude some commercial top-level CAs (e.g., NetTrust) Compliance with Grid Certificate Profile document document is now in draft in the OGF CAOPS-WG almost finished embodies lots and lots of community knowledge on what a certificate ought to look like read it before you setup a new CA, or regenerate a root cert, or think about an end-entity certificate profile Auditing: if you re-issue without a new identity vetting, you MUST keep the original records for at least as long as there are certs based on this vetting plus the default grace period

Classic v4.1+ - what is still pending Still pending for a next version some real insights in the necessary site security measures certificate/crl profile to be revised once the OGF document thereon is formally published language clarification on documented traceability in various places

Other (non-) contentious issues discussed in TR CRLs for compromised CAs non-repudiation bit in keyUsage and how that relates to email signing the Meaning of Locality and why to use O if you can objectSigning bits should we also address who is allowed to get this bit? should the organisation be involved (Milan)? or does it only asserts that the code was signed by this user, as is done in the UK, NL, AT and so better keep as is? Prepare the profile a bit better for Robot certificates CDP in EE certificates ought to point to a DER CRL auditable tracability in ID vetting and alternative solutions – and the meaning of SHOULD

the TERENA Academic CA Repository TACAR the TERENA Academic CA Repository trusted and centralized place where root CA certs can be stored and safely retrieved which is policy-neutral (but ‘IGTF-ready’) for CAs directly managed by TERENA members belonging to a national academic PKI in member states for all CAs set-up to support not-for-profit research, in which the academic community is directly involved

IGTF Distribution in Other Formats Apart from validation via TACAR, the IGTF manages a distribution of all accredited authorities formerly known as Anders’ RPM set, today also available as: JKS, tar-gz, configure && make, … usually built by the EUGridPMA (me, actually) mirrored twice-daily to the apgridpma.org site copied and re-distributed by downstream vendors (EGEE/LCG, VDT, …) also contains the fetch-crl utility (now at version 2.6.3) Download location https://dist.eugridpma.info/distribution/

Some dates for you to remember and schedule September 4-5, 2007 TF-EMC2 meeting, Prague, CZ September 19-21, 2007 11th EUGridPMA meeting, Thessaloniki, GR October 15-19 – OGF 21 CAOPS, IGTF, …, Seattle (WA), USA January 14-16, 2007 12th EUGridPMA meeting, Amsterdam, NL