On 15/09/14 14:27, Erwann Abalea wrote:
2014-09-15 11:32 GMT+02:00 Rob Stradling wrote:
Yes. The log removes the poison extension, and (if a Precertificate
Signing Certificate was used) it also changes the issuer name and
AKI to match those of the final certificate's issuing CA. This
behaviour can remain the same.
Concerning these last changes (issuer name and AKI), are they under the
responsibility of the certificate issuer, or of the log signer?
Hi Erwann. That was my understanding too until Emilia corrected me a
few days ago!
My understanding was that it's the issuer's job.
No, it's the log signer's job. The Precertificate's Issuer Name and AKI
need to match the Precertificate Signing Certificate's Subject Name and SKI.
Upon receipt of a Precertificate, the log signer does the following:
1. Verify the Precertificate's signature.
2. Extract the TBSCertificate part of the Precertificate.
3. Remove the poison extension.
4. Change the Issuer name to match the Issuer name of the final
cert's issuer.
5. Change the AKI to match the SKI of the final cert's issuer.
6. Use that modified TBSCertificate to construct the SCT.
7. Generate the SCT signature.
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. :-(
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
