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

From: "trans issue tracker" <[email-masked]>
Date: Mon, 08 Jun 2015 15:33:18 -0000

#79: Precertificate signature must be over something other than just the
TBSCertificate

Comment (by [email-masked]):

 I don't think any action is required. The I-D already says:

 "A precertificate is a CMS signed-data object that contains a
 TBSCertificate in its SignedData.encapContentInfo.eContent field,
 identified by the OID <TBD> in the
 SignedData.encapContentInfo.eContentType field."

 In other words: option 2 is what the I-D already propose.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  [email-masked]           |  [email-masked]
     Type:  defect                   |      Status:  assigned
 Priority:  blocker                  |   Milestone:
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/79#comment:4>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 08 Jun 2015 19:31:36 -0000

Comment (by [email-masked]):

 OK, I agree that option 2 is what the I-D already proposes.  However, in
 the interest of helping implementers to avoid missing this requirement, I
 suggest we add a note to -bis along the lines of...

 "Note that RFC5652 requires a content-type attribute and a message-digest
 attribute to be included in signedAttrs."

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/79#comment:5>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 11 Jun 2015 12:42:10 -0000

Changes (by [email-masked]):

 * 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.

 Priority:  blocker                  |   Milestone:  review

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/79#comment:6>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 11 Jun 2015 14:00:41 -0000

Changes (by [email-masked]):

 * status:  assigned => closed
 * resolution:   => fixed

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:
  [email-masked]           |  [email-masked]
     Type:  defect                   |      Status:  closed
 Priority:  blocker                  |   Milestone:  review
Component:  rfc6962-bis              |     Version:
 Severity:  -                        |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/79#comment:7>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Jun 2015 17:42:01 -0400

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.

---

From: Rob Stradling <[email-masked]>
Date: Fri, 12 Jun 2015 14:30:53 +0100

> 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."

>>   After discussion with Rob, core point is that the CMS signature is
>> not an X509 signature.
>>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 12 Jun 2015 17:27:57 +0200

Bonjour,

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

> Precertificate to be a CMS structure that contains a TBSCertificate and a
> signature over just that TBSCertificate.

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.

>>>   rfcs/commit/546e6e9451186e96ddd7b54ca02f17c8d86f951e.
This commit has nothing to do with the ticket ;)

---

From: Rob Stradling <[email-masked]>
Date: Fri, 12 Jun 2015 16:45:06 +0100

On 12/06/15 16:27, Erwann Abalea wrote:
<snip>
> contains the TBSCertificate), and the resulting signed precertificate
> can be manipulated to become a valid certificate:
>    - build a SEQUENCE containing the TBSCertificate, a properly
> formatted SignatureAlgorithm, and the signature (reencode it from OCTET
> STRING to BIT STRING)

Indeed.

> NOT id-data. Or require the presence of the SignedAttributes.

Ben, do you want to allocate an OID from the Google arc for this?

<snip>
> This commit has nothing to do with the ticket ;)

It was a series of several commits.  That was the final one.

Click the link just to the right of "1 parent".  Then do the same again, 
and you should arrive at...
https://github.com/google/certificate-transparency-rfcs/commit/c62061213c5085cf4d0f266dc8aa2c803bcf4c8f

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Jun 2015 13:38:18 -0400

Rob,
> "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.
happens to all of us ;-)
> construct a certificate from the precertificate."
I might say: "The signature on the CMS structure used to convey a 
pre-certificate
is not the same as the signature that appears in the X.509 certificate, 
per se."

Steve