Re: [Trans] Precertificate format

[Rob Stradling <[e-mail]>]

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