[caops-wg] Certificate Profile document, update v0.5

[Reimer Karlsen-Masur, DFN-CERT]

Hi David,

please find some comments below.

David Groep wrote:
> Dear all,
> 
> The last version of the certificate profile draft document is now almost
> two months old, so its high time for a new version that we can discuss
> in Washington (GGF18).
...
> Please have a look through the document, and send your comments, 
> suggestions,
> and text on additional extensions.

In section 2.2:

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

...

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)?

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.

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.

-- 
Kind Regards

Reimer Karlsen-Masur
--
Dipl.-Inform. Reimer Karlsen-Masur (PKI Team), DFN-CERT Services GmbH
https://www.dfn-cert.de, +49 40 808077-615 / +49 40 808077-555 (Hotline)
PGP RSA/2048, 1A9E4B95, A6 9E 4F AF F6 C7 2C B8  DA 72 F4 5E B4 A4 F0 66
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7125 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/caops-wg/attachments/20060814/d1a4c922/attachment.bin