Hi Reimer, Thanks for the comments. Answers in-line, and a new document is on the web at http://www.eugridpma.org/temporary/eugridpma-certprofile-20060814-0-6.pdf http://www.eugridpma.org/temporary/eugridpma-certprofile-20060814-0-6.doc Reimer Karlsen-Masur, DFN-CERT wrote:

... In section 2.2:

Within the Issuer and Subject DNs, the following attributes *are known to cause problems*:

That was a piece of legacy text that I ought to have removed. As the document was restructure, this is now a plain list of attributeTypes.

2.2.4 DomainComponent, country, organization, organizationalUnit, etc. ... 2.2.5 commonName ...

I am confused. Why are these causing problems, except maybe for multiple RDNs of same name (except for DCs)?

Multiple "O"'s are OK, and even multiple CNs are rumoured to be OK (the CERN-IS CA will find out :-)

In section 3.3.8 only some forms of the AKI block the in-place replacement of CA certificates. If the AKI does only contain the hash value I think it is working fine. IMO this hash only changes if the CA key changes. And "in-place replacement" means extending the lifetime of a CA certificate and maybe changing the serial number but nothing else, right?

If the AKI of an EE cert contains the dirname (i.e. the subject DN) of the issuing CA issuing CA (note: this is the right number of repetitions of "issuing CA" cause it is the *issuer* DN of the EE certs issuing CA cert) plus the EE certs issuing CAs certificate serial number the problems start when the replacement CA certificate gets a new serial number (which it should as to sections above).

When an in-place CA cert replacement is eventually planned for in the future and this will come with a CA key change, above does not apply and it is better to not use AKIs at all.

This updated text should be better: The authorityKeyIdentifier is not usually interpreted by the software. It is not known to cause issues with grid software, as it is ignored. The extension MUST NOT be marked critical. If the AKI contains information that changes when the CA certificate is modified, it will block any “smooth” replacement of CA certificates (i.e. updating a CA certificate to modify the expiry date). Possible attributes in AKI include the directoryName of the authority that issued the issuer certificate (safe as it should not change) plus the serial number (which may or may not change), and/or the keyId of the end-entity issuing CA. If the keyIdentifier has been generated using one of the two recommended methods from RFC3280 (i.e. is purely derived from the public key value), it will not impair smooth replacement.

AKIs are also used in (Sub-)CA certificates, so similar apply there.

In section 3.3.12 the AIA could additionally/alternatively hold the issuing CAs certificate download URI. Can also be set in Sub-CA certificates. This can be used to automatically retrieve CA certs for validation path building and path validation. IMO at least Microsoft's smart card Single-Sign-Logon is using these.

Added to 3.3.12. Cheers, DavidG. -- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **

Hi Jens, Jensen, J (Jens) wrote:

David, I have now finally had time to go through the document and made only a few changes. And fixed a few bugs, like commonName cannot use IA5String as encoding. I used Word's change tracker.

http://www.grid-support.ac.uk/files/eugridpma-certprofile-20060814-0-6-jens....

Thanks for the update. I've merged all changed in the new version 0.7, on the web at http://www.eugridpma.org/temporary/ in both formats.

What would be the consequences of saying in 4.1 "RDNs MUST be in the Right Order". Will we lose SWITCH and Purdue?

I've added a lot of new text in this section, to explain that it SHOULD NOT be used but MAY be ok for intermediate CAs to have the 'reverse' ordering (i.e. issuing no more than 2 trusted subordinates), but is MUST be in the correct order for end-entity certificates. This accommodates the SWITCH EE issuing CAs, that have reversed the ordering last year (although it took SwissSign some time to implement these changes). Other options are not supportable by Globus, as the wild card matching is done at the end of the string only. So, just like SwissSign did for SWITCH, I think the Purdue CA will have to re-order the components as well to get the signing_policy file to work.

Would it be worth expanding section 5 into a general annotated openssl.cnf? If new CAs feel this would be useful, I will be happy to provide something (if so, please reply to me).

I seems like #5 is getting larger and larger, but I'm not sure we want the OpenSSL config to be in this document, though. The software is quite volatile, with options appearing and disappearing all the time, so maybe we should move some of existing stuff that is just too openssl specific out of this doc, and on to a Wiki.

The document has also gradually started to describe how software deals with certificates - browsers, OpenLDAP, etc. This could be expanded.

Indeed. But there is something to be said as well for getting the basic guidance out for new CAs on a relatively short time scale. OpenLDAP got included there since UNICORE (and also other services used in DEISA) depend on it & browsers since they are needed to register to a VO in many grids. If we can get the issues with at least the current software needed for grid operations in there, we should do it (GT, UNICORE, BouncyCastle, OpenSSL, Sun's JCE, OpenLDAP, VOMS (-Admin) & VOMRS, ...) Thanks! DavidG. -- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **