Subject: Re: [Trans] [trans] #4 (rfc6962-bis): Should we sign TBS for Certificates?

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

#4: Should we sign TBS for Certificates?

Comment (by [email-masked]):

 There seems to be a consensus among the authors that this is a good idea.
 As Emilia Kasper put it:
 "I can see only strong benefits in this: 1) unifying the handling of
 precertificates and certificates and 2) avoiding all sorts of library
 slack and brokenness in handling the unsigned component of the
 certificates."
 That implies that the signature in the SCT will not cover the signature in
 the X.509 certificate itself, so it would validate for different
 certificates that are the same TBSCertificate, signed with the same key
 multiple times (potentially yielding different signatures).
 To allow auditing of the original submission, I propose adding a field to
 the PrecertChainEntryV2/X509ChainEntry struct (which will be unified) to
 include the original submission.

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

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

---

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

Comment (by [email-masked]):

 Eran, don't the existing PrecertChainEntryV2/X509ChainEntry structs
 already hold the original submission?

 Can't we resolve this ticket just by changing
 !SignedCertificateTimestamp.signed_entry and
 !TimestampedEntry.signed_entry from...
                select(entry_type) {
                    case x509_entry: ASN.1Cert;
                    case precert_entry_V2: TBSCertificate;
                } signed_entry;
 ...to...
                select(entry_type) {
                    case x509_entry: TBSCertificate;
                    case precert_entry_V2: TBSCertificate;
                } signed_entry;

 I think it makes sense to retain a different struct for each
 !LogEntryType, rather than try to unify them.  New !LogEntryType values
 might be defined in future that aren't unifiable with the existing two.

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