Bonjour Rob, Thanks for your valuable comments, we're currently implementing this in our CA, and the RFC5280 conformance of the PreCert Signing Certificate scenario is pleasing. No need to remove our constraints or cheat to circumvent them...
2014-09-16 12:25 GMT+02:00 Rob Stradling <[email protected]>: > 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. > Ok. So the reference code takes for granted that the CA will use the same strategy to populate the PreCert Signing Certificate and the final issued certificate. That's not an unusual assumption, but: > Nonetheless, I still think RFC6962 needs an erratum to deal with the > optionality of the various AKI components. +1 This should be stated somewhere. -- Erwann.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
