AW: [igtf-general] Re: [caops-wg] Certificate Profile document, update v0.5

Wed Aug 16 06:48:16 CDT 2006

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 at 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 at rl.ac.uk] Gesendet: Dienstag, 15. August 2006 09:31 An:
>> David Groep; dg-eur-ca at 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 at ggf.org 
>> [mailto:owner-caops-wg at ggf.org]On Behalf Of David Groep Sent: 14 August
>> 2006 13:08 To: dg-eur-ca at 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 **