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

2. 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)

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

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

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

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

7. Other (non-) contentious issues discussed in TR
CRLs for compromised CAs
non-repudiation bit in keyUsage
and how that relates to 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

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

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

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