Michael Voucko wrote:

> > An Authority Key Identifier extension can contain
> > a) the value of the issuer cert's "Subject Key Identifier", or
> > b) The value of the issuer cert's Issuer name and serial number, or
> > c) both.
> >
> > Most commercial CAs do a, some do b.  AFAIK, none do c.
> > b and c are less flexible than a because having the issuer's serial number
> > in it doesn't accomodate CA cert renewal.
> 
> Yes, I also deceided to go with b) as a) only detects renewal of keys -
> not of certs.

I'm not sure what you mean by that.  

Is it your intent to prevent a cert from being verified with a renewed
version of the CA cert?  I ask because that's what types b and c do,
unfortunately.

Type a permits a cert to be verified using a newer (renewed) copy of a
CA's cert, as long as the new CA cert has the same public key and same 
Subject Key ID extension as the older CA cert.  Type b (or c) only permit 
a cert to be verified with the orignal CA cert with which it was issued, 
because only that cert has the serial number that appears in the type b 
AKID extension.

> it's a c) type PKI
> generated with openssl. I guess there is a bunch of people using such a
> combination b/c in the man page about creating a cert request this
> combination is suggested in one of the example configuration files.
> 
> You may want to checkout the page
> www.openssl.org/docs/apps/req.html#CONFIGURATION_FILE_FORMAT
> The relevant section is

>   [ v3_ca ]
> 
>   subjectKeyIdentifier=hash
>   authorityKeyIdentifier=keyid:always,issuer:always
>   basicConstraints = CA:true

Thanks for pointing out that example.  I think this example was meant 
more to illustrate the different possible options than to recommend 
that they all be used.  

--
Nelson B

Reply via email to