Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signaturemust be over something other than just the TBSCertificate

[Erwann Abalea <[e-mail]>]

Bonjour,

2015-06-12 15:30 GMT+02:00 Rob Stradling <[e-mail]>:

> 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 [e-mail]):
>>>
>>>   * 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 ;)