Re: AW: [igtf-general] Re: [caops-wg] Certificate Profile document, update v0.5
Hi Ursula, all, Epting, Ursula wrote:
Dear Jens, David and all, the document is very well done, good work! I've added some small comments and (possible) corrections of typos (using word track changes on Jens' doc, after accepting all his changes)
I've merged these in and produced version 0.8 - now on the web at http://www.eugridpma.org/temporary/ Most of the comments I've just merged, some are discussed below: * in section 2.1, on the serial number stuff: I've created a new subsection ("2.2 Serial Number") and put all this text there. * in section 3.1, "version number must be set to "2"": this is indeed the encoding of the version number in the first INTEGER of the certificate * section 3.2.1 "dNSName" and others funky capitalisation taken from the standards documents (where things never start with a capital letter) * On the Unicore need for "nsCertType: server, client" I've not seen this requirement before (of having a need for *both* server *and* client being asserted here). If you can dig up the email, I'll be very happy. Please do. * Section 4.2 "Key lengths and hashed" Since SHA-256 is not supported, we'll have to live with SHA-1 for the time being, despite it having only 80 bits effective. Thanks a lot, DavidG.
Mit freundlichen Gruessen/ With kind regards
Ursula Epting
Ursula Epting Forschungszentrum Karlsruhe Institut fuer Wissenschaftliches Rechnen (IWR) Grid Infrastruktur und Services (GIS) Tel. +049 (0)7247-82-6786 Fax +049 (0)7247-82-7786 e-mail: ursula.epting@iwr.fzk.de ----------------------------------------------- GridKa-Zertifikat SHA1-Fingerprint: 0B:DD:25:06:98:74:D6:81:DD:1E:AF:2F:AD:7A:EA:10:75:CE:7E:6E ----------------------------------------------- ************************************************************************** The Institute for Scientific Computing of Forschungszentrum Karlsruhe will again run its annual GridKa School from September 11-15, 2006. Please find further information at http://www.fzk.de/gks06 . **************************************************************************
-----Ursprüngliche Nachricht----- Von: Jensen, J (Jens) [mailto:J.Jensen@rl.ac.uk] Gesendet: Dienstag, 15. August 2006 09:31 An: David Groep; dg-eur-ca@services.cnrs.fr Cc: All IGTF Members (igtf-general); CAOPS-WG Betreff: RE: [igtf-general] Re: [caops-wg] Certificate Profile document, update v0.5
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-2006 0814-0-6-jens.doc
What would be the consequences of saying in 4.1 "RDNs MUST be in the Right Order". Will we lose SWITCH and Purdue?
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).
The document has also gradually started to describe how software deals with certificates - browsers, OpenLDAP, etc. This could be expanded.
Thanks, --jens
-----Original Message----- From: owner-caops-wg@ggf.org [mailto:owner-caops-wg@ggf.org]On Behalf Of David Groep Sent: 14 August 2006 13:08 To: dg-eur-ca@services.cnrs.fr Cc: All IGTF Members (igtf-general); CAOPS-WG Subject: Re: [igtf-general] Re: [caops-wg] Certificate Profile document, update v0.5
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-20060 814-0-6.pdf
http://www.eugridpma.org/temporary/eugridpma-certprofile-20060 814-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 **
-- 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 **
participants (1)
-
David Groep