Subject: [Trans] [trans] #127 (rfc6962-bis): confusing case is allowed: submission of pre-cert without embedding SCT in issued cert

From: "trans issue tracker" <[email-masked]>
Date: Tue, 17 Nov 2015 21:50:36 -0000

#127: confusing case is allowed: submission of pre-cert without embedding SCT in
issued cert

 [https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-10#section-3.2
 Section 3.2] says "The CA MAY incorporate the returned SCT in the issued
 certificate." Under what circumstances would a CA submit a pre-certificate
 and NOT embed the SCT? If a CA isn't planning to embed an SCT in a
 certificate it would seem appropriate to submit the issued certificate.

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

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

---

From: "trans issue tracker" <[email-masked]>
Date: Wed, 18 Nov 2015 22:26:35 -0000

Comment (by [email-masked]):

 At first glance I would tend to agree there's not much point intentionally
 submitting a pre-certificate and not embedding the resulting SCT, however
 in practice I can see cases where this would happen for operational
 reasons.

 Let's say a CA submits a precertificate to 6 logs in parallel, and then
 waits until they get enough SCTs back to meet the minimums per Chrome's EV
 CT policy.  Maybe one of the logs is performing badly and takes too long
 to respond, but then does respond with a valid SCT, or maybe a log
 responds but the network connection is broken such that the CA never
 receives the response.

 In this scenario the CA has enough SCTs, so it embeds them in a
 certificate and issues it.  If the MAY was a MUST, it would imply that a
 CA is in error if they don't embed an SCT and I don't think that makes
 sense in this case.

 Severity:  -            |  Resolution:
 Keywords:               |

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Nov 2015 17:36:58 -0500

That's a good explanation of a possible rationale for this being a
MAY; it needs to be included, as an example, in the document so
that other folks don't ask the same question as David.

Steve

---

From: "trans issue tracker" <[email-masked]>
Date: Thu, 19 Nov 2015 10:28:57 -0000

Comment (by [email-masked]):

 "The CA MAY incorporate the returned SCT in the issued certificate" is
 worded like that very deliberately.

 In addition to Adam's point, please see ticket #10.
 (tl;dr  Name redaction relies on precertificates.  We want to support name
 redaction when SCTs or inclusion proofs are sent via OCSP Stapling or the
 CT TLS extension.  To do this, we need Precertificate SCTs that probably
 won't be embedded in certs)

 Let's leave this ticket open for now, and revisit it after ticket #10 has
 been fully addressed.

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