Subject: Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer key hash into the Precertificate

From: "trans issue tracker" <[email-masked]>
Date: Wed, 01 Jul 2015 13:31:46 -0000

#80: Re-introduce the issuer key hash into the Precertificate

Comment (by [email-masked]):

 I don't understand this problem.

 The I-D says "SignedData.signerInfos MUST contain a signature from the
 same (root or intermediate) CA that will ultimately issue the
 certificate."

 signerInfos includes "SignerIdentifier ::= CHOICE {
         issuerAndSerialNumber IssuerAndSerialNumber,
         subjectKeyIdentifier [0] SubjectKeyIdentifier }"

 Surely this is sufficient to identify the issuer?

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

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

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 01 Jul 2015 13:44:08 -0000

On the analogous situation for X.509, the extra_data included with the
 entry includes the certificate itself and the chain of signers, so again,
 this seems unnecessary.

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

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 01 Jul 2015 16:59:30 -0000

Comment (by [email-masked]):

 This problem affects browser clients and any other client that wants to
 verify that an SCT corresponds to a particular cert.  A browser has the
 full cert chain (from the TLS handshake) and the corresponding SCTs, but
 it is _not_ expected to have the full log entries (i.e. extra_data, etc).

 In the current text, the SCT is bound to the Issuer Name (because that's
 in the TBSCertificate), but not to the Issuer Key (because that's not in
 the TBSCertificate).

 There could exist two or more publicly-trusted intermediate CA certs with
 the same Name but different Keys.  One of those intermediates might be
 logged, while the other(s) are not logged.  Each of them could issue leaf
 certs that have an identical TBSCertificate.  Only one of those leaf certs
 needs to be logged for there to exist SCT(s) that are valid for all of
 those leaf certs.

 The logged leaf cert might get revoked, but the other(s) might not get
 revoked.  However, the SCT(s) would still work for all of those certs,
 including the non-logged ones.

 Therefore, we need to fix SCTs so that they're bound to the Issuer Key
 Hash as well as the Issuer Name.

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

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 01 Jul 2015 17:03:02 -0000

#80: Re-introduce the issuer key hash into the SCT

 Just noticed an error in the summary.  Perhaps that was the cause of the
 confusion.

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 02 Jul 2015 10:00:01 -0400

Rob,

I agree with your conclusoon that inclusion of the issuer public key hash
will enable a browser to verify the correspondence between an SCT without
interacting with a log. Even though we don't yet have a browser behavior
spec, I agree that this is a good candidate behavior to enable.

Do you propose this as an extension to the current SCT format, or a change
to the format?  If you propose a change, then I'll argue that my proposed
cert type declaration and checks performed fields also should be included,
since we'll be making a not backward compatible change to the SCT. If this
is an (optional) extension, then I guess my proposed fields can be the 
second
and third extensions defined.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Fri, 03 Jul 2015 15:32:23 +0100

> Rob,

Hi Steve.

> to the format?

A change to the format.  Proposal here:

https://github.com/google/certificate-transparency-rfcs/pull/58

> If you propose a change, then I'll argue that my proposed
> since we'll be making a not backward compatible change to the SCT.

6962-bis has already made backwards-incompatible changes to RFC6962 SCT v1.

> If this is an (optional) extension, then I guess my proposed fields can be
> the second and third extensions defined.

I think that required fields should be in the main part of the SCT 
structure, whilst optional fields should be extensions.

IINM, we agreed a while ago that your proposed fields (cert type 
declaration and checks performed) would be, at most, optional.

(I still think that it makes more sense for monitors, not logs, to 
perform checks relating to the declared cert type).

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

-- 
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: "trans issue tracker" <[email-masked]>
Date: Mon, 06 Jul 2015 10:50:49 -0000

Changes (by [email-masked]):

 * status:  assigned => closed
 * resolution:   => needs-review

Comment:

 Fixed here:
 https://github.com/google/certificate-transparency-
 rfcs/commit/f2650ef2b776a05eb280614b967efe2fcc4cf44e

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

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

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 06 Jul 2015 11:26:31 -0000

* status:  closed => reopened
 * resolution:  needs-review =>
 * milestone:   => review

Comment:

 I just realized that resolving as "needs-review" was the wrong thing to
 do.  Reopening and setting milestone to "review" instead.

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

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

---

From: "trans issue tracker" <[email-masked]>
Date: Tue, 07 Jul 2015 17:22:37 -0000

Changes (by [email-masked]):

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

 Severity:  -                 |  Resolution:  fixed

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