Subject: [Trans] Question about Draft 19 - Section 4.2

From: Ryan Sleevi <[email-masked]>
Date: Sun, 23 Oct 2016 14:41:57 -0700

I'm curious to understand the interpretation of Section 4.2, and it's
presumed implications for CT clients.

At present, Section 4.2 (
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-19#section-4.2
)  states:

   An intermediate CA certificate or intermediate CA precertificate that
   contains the Name Constraints [RFC5280] extension MAY be logged in
   place of end-entity certificates issued by that intermediate CA, as
   long as all of the following conditions are met

As I read this, this implies that this is not an obligation upon
clients to recognize this extension, or this approach to logging. That
is, a client (such as Google Chrome) may consider rejecting such
certificates as part of its Certificate Transparency policy. At
present, this is where the thinking of Chrome is, but if it's
perceived to obligate clients to recognize such events, then I'd like
to try to see how to tweak the text to make it clearer that this is
optional - for logs and for clients.

>From discussing with some of the authors, and from those in the CA and
log operator space, it doesn't seem that there's a clear agreement
about the implication of the text, and whether or not it belongs in
https://datatracker.ietf.org/doc/draft-strad-trans-redaction/ (as a
technical means for redaction). However, if there's WG consensus that
it is merely descriptive about how such a mechanism would work (via
MAY), rather than prescriptive upon a client implementation, then
perhaps it's worth noting more explicitly as such, without
meaningfully altering the text that has passed WG consensus.

---

From: Peter Bowen <[email-masked]>
Date: Sun, 23 Oct 2016 16:07:24 -0700

> optional - for logs and for clients.

The draft clearly calls for TLS clients to accept this.  See section 8:

   TLS servers MUST use at least one of the three mechanisms listed
   below to present one or more SCTs from one or more logs to each TLS
   client during full TLS handshakes, where each SCT corresponds to the
   server certificate or to a name-constrained intermediate the server
   certificate chains to.

Section 10.2.6 makes it clear that section 8 defines compliance:

   If any certificate in a chain includes the transparency_info
   (Section 8.5) TLS extension identifier in the TLS Feature [RFC7633]
   certificate extension, then CT compliance (using any of the
   mechanisms from Section 8) is required.

It appears that the methiod in 4.2 is explicitly called out in other
sections and does not appear to be optional for clients.

> meaningfully altering the text that has passed WG consensus.

I don't think it needs moving.  The objective to allow named subjects
of certificates to detect mis-issuance is met by using Name
Constrained CAs.  Just as a subject monitors for end-entity
certificates she did not authorize, she should also monitor for
subordinate CAs she did not authorize.  The effect is the same --
ensuring that there is proper authorization for the issuance of
certificates.

The key difference between an unconstrained CA and name constrained CA
is pre-notification of intent to issue.  With an unconstrained CA, any
name can show up at any time.  However with a NC CA, there is clear
notice of what names are to be issued.  This is even better than a
standard end-entity certificate checking, as the subject can
preemptively take action rather than waiting for the first EE
certificate to be issued.

Thanks,
Peter

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 23 Oct 2016 16:28:42 -0700

On Sunday, October 23, 2016, Peter Bowen <[email-masked]> wrote:

> On Sun, Oct 23, 2016 at 2:41 PM, Ryan Sleevi <[email-masked]
> <javascript:;>> wrote:

It is precisely these sections that I have heard disagreeing
interpretations, precisely because it implies dictating policy about what a
client accepts.

As a counter-interpretation, what about clients that impose policy on the
SCTs delivered - such as Chrome does.

Either we accept CT compliance is locally defined - which suggests
optionality - or it's an unnessecary constraint on policy inconsistent with
existing 6962 implementations.

> ensuring that there is proper authorization for the issuance of

While this is true, as you know, this is not the only objective of CT from
existing implementations.

For example, it prevents detection of misissuance as defined by the
CA/Browser Forum's Baseline Requirements, as name constrained sub-CAs still
have obligations of issuance practice imposed on them.

Your interpretation suggests the only value of CT is for specific domain
holders, but I don't believe that's a correct or shared interpretation.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 24 Oct 2016 13:03:57 +0100

On 24/10/16 00:28, Ryan Sleevi wrote:
<snip>
> optionality - or it's an unnessecary constraint on policy inconsistent
> with existing 6962 implementations.

RFC6962 and 6962-bis specify the technical mechanisms of CT.  Therefore,
it seems entirely appropriate for these documents to define what
constitutes basic CT compliance.

This doesn't prevent TLS Clients from adding extra/stricter requirements
via their own CT Policies though.  For example, 6962-bis draft 19
section 10.2.5 says...
  "To be considered compliant, a certificate MUST be accompanied by at
   least one valid SCT."
...but section 8.1 recognizes that...
  "TLS clients may have policies related to the above risks requiring
   servers to present multiple SCTs.  For example, at the time of
   writing, Chromium [Chromium.Log.Policy] requires multiple SCTs to
   be presented with EV certificates in order for the EV indicator to
   be shown."

Similarly, I think a future Chrome CT Policy could conceivably state
that Chrome will only accept SCTs that correspond to end-entity certs,
even though 6962-bis specifies the option of SCTs for name-constrained
intermediates.

That said, if you're certain that Chrome won't accept SCTs for
name-constrained intermediates as currently defined in 6962-bis, then
I'd be in favour of moving this feature to the Redaction draft.  Since
we've completed WGLC for 6962-bis, I presume this possible course of
action would be a matter for the WG chairs and/or Area Directors to
consider.

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

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 24 Oct 2016 09:07:15 -0700

> action would be a matter for the WG chairs and/or Area Directors to

I can't say with certainty, because I think it touches back on the
issues previously discussed in the CA/Browser Forum and in Chromium CT
Policy list - which is that a variety of solutions exist, some
technical and some policy, and the appropriate solution will likely
sit somewhere between the both.

My goal in sending this was to check to see whether there was
consensus, say, for a client rejecting EE certs that were accompanied
by SCTs from name-redacted CAs, because in talking with various people
involved in the space, I was seeing conflicting answers about "what
the spec said".

Your interpretation is aligned with how I saw it - that client policy
dictates the acceptable form of SCTs - which, to me, also implies that
a client that only wishes to recognize EE SCTs does not even need to
parse/recognize such SCTs. That is, the spec describes the technical
means for it, but it's not mandatory for clients to accept/recognize
it as complying with policy. That's why I hoped that, if there's
consensus on that interpretation, it might be seen as a an opportunity
wording tweak that doesn't undermine consensus, rather than a more
significant action (like moving to a redaction spec)