Bonjour,
2015-06-12 15:30 GMT+02:00 Rob Stradling <[email protected]>:
> On 11/06/15 22:42, Stephen Kent wrote:
>
>> what does it mean to not be "an X509 signature"?
>>
>> I thought the intent was to use a CMS object, and thus the signature
>> would be defined by that (profiled) CMS object.
>>
>
> Hi Steve. That's correct.
>
> At the top of ticket #79 I wrote:
> "If I understand the CMS spec correctly, then we're currently defining a
> Precertificate to be a CMS structure that contains a TBSCertificate and a
> signature over just that TBSCertificate.
> That means that the components of a Precertificate can be trivially
> rearranged into an X.509 certificate with a valid signature!"
>
> It turns out that I didn't understand correctly. :-)
>
> Ben added some text to help clarify the situation:
> "Note that, because of the structure of CMS, the signature on the CMS
> object will not be a valid X.509v3 signature and so cannot be used to
> construct a certificate from the precertificate."
>
And this is true if and only if the
SignedData.encapContentInfo.eContentType field is set to a value different
from id-data (id-data is the OID { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }).
If the eContentType is set to id-data, the CMS producer can omit the
SignedAttributes, the signature is performed over the eContent (which
contains the TBSCertificate), and the resulting signed precertificate can
be manipulated to become a valid certificate:
- take the TBSCertificate and the signature from the CMS/precertificate,
- build a SEQUENCE containing the TBSCertificate, a properly formatted
SignatureAlgorithm, and the signature (reencode it from OCTET STRING to BIT
STRING)
- you have a valid certificate
To avoid this, just make sure that the TBD in the current rfc6962-bis is
NOT id-data. Or require the presence of the SignedAttributes.
#79: Precertificate signature must be over something other than just the
>>> TBSCertificate
>>>
>>> Changes (by [email protected]):
>>>
>>> * milestone: => review
>>>
>>>
>>> Comment:
>>>
>>> After discussion with Rob, core point is that the CMS signature is
>>> not an X509 signature.
>>>
>>> Fixed at https://github.com/google/certificate-transparency-
>>> rfcs/commit/546e6e9451186e96ddd7b54ca02f17c8d86f951e.
>>>
>>
This commit has nothing to do with the ticket ;)
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
