2014-09-15 11:32 GMT+02:00 Rob Stradling <[email protected]>:
> On 12/09/14 20:26, Erwann Abalea wrote:
>
>> [...]
>> It can only work if the log signs the content (=TBSCertificate) and not
>> the whole CMS, thus ignoring the PreCert issuer signature. Leaving that
>> signature aside isn't more risky than it is now because it's already the
>> case (the log removes the poison extension before signing the resulting
>> certificate, right?).
>>
>
> 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?
My understanding was that it's the issuer's job. 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?
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).
--
Erwann.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
