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

From: "trans issue tracker" <[email-masked]>
Date: Fri, 27 Mar 2015 16:08:11 -0000

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

 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!

 To fix this, we need to either...

 1. Require the SignedData.encapContentInfo.eContent field to contain
 "something || TBSCertificate" or "TBSCertificate || something".
 or
 2. Require a signed attribute to be present in
 SignedData.signerInfos[0].signedAttrs.  This is essentially equivalent to
 "TBSCertificate || something" in terms of what gets signed.

 I think 2 is the cleaner solution, unless there's a cryptographic reason
 to prefer "something || TBSCertificate" (e.g. to protect against chosen
 prefix collisions?)

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-trans-
  [email-masked]           |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  blocker                  |  Milestone:
Component:  rfc6962-bis              |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

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

---

From: "trans issue tracker" <[email-masked]>
Date: Fri, 27 Mar 2015 16:08:36 -0000

Changes (by [email-masked]):

 * owner:  [email-masked] =>
     [email-masked]
 * status:  new => assigned

-- 
-------------------------------------+-------------------------------------
 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:1>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Fri, 27 Mar 2015 16:31:33 -0000

Comment (by [email-masked]):

 It is unclear to me whether this is really a problem.

 RFC 5652 says: "The input to the signature generation process includes the
 result of
    the message digest calculation process and the signer's private key.
    The details of the signature generation depend on the signature
    algorithm employed."

 It then defers to RFC 5280 for the actual definition of the algorithms.

 AFAIK, RFC 5280 only specifies algorithms that are intended to work on
 bulk data (i.e. TBSCertificates), and hence they always digest the data
 first.

 This would imply that the signature would be over a digest of a digest.
 However, its not the clearest RFC I ever read. If that interpretation is
 correct, then there is no problem.

 If there is a problem, I agree that option 2 is better.

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

---

From: Erwann Abalea <[email-masked]>
Date: Mon, 30 Mar 2015 13:29:35 +0200

Specify that the EncapsulatedContentInfo MUST be some specific value
(allocate an OID from IETF/IANA/whatever).
RFC5652 states that if the EncapsulatedContentInfo is not id-data, then the
signedAttrs MUST be present (whence solution 2 will apply).

2015-03-27 17:08 GMT+01:00 trans issue tracker <[email-masked]>:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
Erwann.

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 31 Mar 2015 11:39:14 -0000

Comment (by [email-masked]):

 > It is unclear to me whether this is really a problem.

 OK, further investigation required.

 <snip>
 > If there is a problem, I agree that option 2 is better.

 Assuming for now that there is a problem...

 Erwann suggests:
 "Specify that the !EncapsulatedContentInfo MUST be some specific value
 (allocate an OID from IETF/IANA/whatever).
 RFC5652 states that if the !EncapsulatedContentInfo is not id-data, then
 the signedAttrs MUST be present (whence solution 2 will apply)."

 RFC5652 says that when signedAttrs is present...

      "it MUST contain, at a minimum, the following two attributes:

          A content-type attribute having as its value the content type
          of the !EncapsulatedContentInfo value being signed.  Section
          11.1 defines the content-type attribute.  However, the
          content-type attribute MUST NOT be used as part of a
          countersignature unsigned attribute as defined in Section 11.4.

          A message-digest attribute, having as its value the message
          digest of the content.  Section 11.2 defines the message-digest
          attribute."

 Putting just those two required attributes in signedAttrs seems
 sufficient.

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