On 15/09/14 14:55, Rob Stradling wrote:
On 15/09/14 14:27, Erwann Abalea wrote:
<snip>
AKI being a variable extension, how could the log know which one of
{issuerName+serialNumber}, {keyIdentifier},
{issuerName+serialNumber+keyIdentifier} content will be found in the
final certificate?
Funny you should mention this. Right now I'm working on SCT
verification code for OpenSSL with Steve Henson and Emilia. Just a few
minutes ago Steve asked the very same question you've just asked here.
So I just looked at the language in RFC6962 Section 3.2. I think "the
TBSCertificate also has its Authority Key Identifier changed to match
the final issuer" is sufficiently vague that we need to file an erratum
to RFC6962 to specify exactly how to deal with the optionality of the
various AKI components.
I also just looked at the certificate-transparency.org code for
inspiration, but it seems to be doing completely the wrong thing! It's
copying the final cert issuer's AKI rather than SKI. :-(
Sorry, ignore that. Looks like the certificate-transparency.org code is
actually copying the Issuer Name and AKI from the Precertificate Signing
Certificate. That's correct.
Nonetheless, I still think RFC6962 needs an erratum to deal with the
optionality of the various AKI components.
If it's the log signer's job, then in the PreCert signing certificate
situation, there's no non-conformance to RFC5280 (regarding to
issuerName+serialNumber uniqueness).
Correct. The serialNumber is identical, but the issuerName is different.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
