Subject: [Trans] Compatibility of name redaction and EV

From: Ben Laurie <[email-masked]>
Date: Tue, 12 Aug 2014 18:18:13 -0700

Some people may be interested in a discussion I have just initiated on
the Chromium ct-policy mailing list on name redaction and EV
certificates:

https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/_p8zRz5Em3s

Since this is a relatively new and low-volume list, I thought it best
to point it out...

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Aug 2014 15:55:31 -0400

Ben,

Thanks for the analysis you performed to start the discussion on
https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/_p8zRz5Em3s.

However, I believe that this discussion should move to the
TRANS list, since it addresses a topic that is squarely within
the scope of the CT standard, right?

Do you disagree?

Steve

---

From: Ben Laurie <[email-masked]>
Date: Mon, 18 Aug 2014 13:07:15 -0700

> the scope of the CT standard, right?

I am not against there being a discussion in TRANS, but I think there
are two interlinked issues:

1. What signals CT provides for what kinds of certs.

2. What Chrome does in response to those signals.

Each has its own appropriate venue.

I am also mildly confused about how an RFC interacts with standards
that are not controlled by the IETF (i.e. the Base Requirements and
the Extended Validation requirements).

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Aug 2014 16:46:08 -0400

Ben,

> Each has its own appropriate venue.
I agree that these are separate topics. But the overall question of whether
the proposal for redacted certs, as part of 6962-bis, is "safe" for both
DV and EV certs, is appropriate for this list. (It's the subject of an
issue tracker entry that I submitted.)

The topic of how a CT-compliant TLS client deals with a redacted cert, 
of any type,
is within scope for TRANS.

What Chrome does is not a subject for TRANS, since you have already stated
that Chrome will do whatever Google decides, irrespective of any TRANS 
RFCs :-).

> the Extended Validation requirements).

Well, RFC 6125 is an example of a standards track RFC that talks about EV
certs in the TLS context, so there is a precedent.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 19 Aug 2014 11:06:31 -0700

> issue tracker entry that I submitted.)

Sure, that makes sense to me.

> The topic of how a CT-compliant TLS client deals with a redacted cert, of
> any type,
> that Chrome will do whatever Google decides, irrespective of any TRANS RFCs
> :-).

Google is obviously not unique in this regard - it's true of all
software, right?

> certs in the TLS context, so there is a precedent.

As far as I can see only to say its out of scope.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Aug 2014 14:36:35 -0400

Ben,

> ...
It's rather unusual for an author of an RFC to publicly state that he plans
to ignore the RFC if it doesn't match his implementation plans.
> As far as I can see only to say its out of scope.

Only the first mention of EV certs appears in the section "labelled "out 
of scope."
The reference to EV certs in Section 2.3.1 says that the RFC prefers use 
of the
Subject Alt Name over the Common name for representing certain classes 
of IDs, but
acknowledges that use of the CN-ID construct is OK for backward 
compatibility with
"deployed infrastructure", citing EV certs.  In Section 7.2, there is 
another reference
to EV certs, in the context of wildcard use. In that instance the RFC 
suggests that
the guidelines published in 2009 allowed wildcards, whereas the RFC 
argued against their
use except in one specific location.

So, I see the RFC as an example of how an IETF standard can choose to 
accommodate, or
reject, guidelines from outside the IETF. There are other RFCs that deal 
with this topic
very directly, e.g., in the MPLS space. The bottom line is that the IETF 
can choose to
view non-IETF standards as off limits, or can reinforce support for 
them, or reject them
in the IETF context. I'm pretty sure we can find examples of all of 
these ways of dealing
with other standards in the RFC collection. I suspect Russ Housely is 
especially well suited
to cite examples based on his experience as IETF Chair.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 19 Aug 2014 11:59:09 -0700

On 19 August 2014 11:36, Stephen Kent <[email-masked]> wrote:
>>> RFCs

As you are fond of pointing out, I am not the author, I am one of the
editors. I am perhaps overly honest in stating up front that I will
not unconditionally follow the consensus decisions of the WG, but
surely this is far from being a unique stance.

> Only the first mention of EV certs appears in the section "labelled "out of
> scope."
> The reference to EV certs in Section 2.3.1 says that the RFC prefers use of
> the
> Subject Alt Name over the Common name for representing certain classes of
> IDs, but
> the guidelines published in 2009 allowed wildcards, whereas the RFC argued
> against their

It would be interesting to know if this is why EV now disallows wildcards.

> very directly, e.g., in the MPLS space. The bottom line is that the IETF can
> choose to
> view non-IETF standards as off limits, or can reinforce support for them, or
> reject them
> in the IETF context. I'm pretty sure we can find examples of all of these
> ways of dealing

OK.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Aug 2014 16:42:44 -0400

Ben,

> surely this is far from being a unique stance.
I don't recall making that observation about your role in generating
this doc. Can you point to a message from me that made that statement,
i.e., that you are an editor, not a doc author? I just don't recall.

I agree that it is common to speak of doc editors, especially when the
content is derived from many sources, e.g., WG list discussions. In this 
case,
the source for the initial doc material was very narrow, and I believe
Eran said that you are the one responsible for making edits to address 
issues.
So, forgive my choice of words to describe your role.

As for a public statement wrt ignoring WG consensus (in an implementation)
by a doc "editor" it strikes me as very unusual, if not unique, based on
my 28 years of IETF participation.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 19 Aug 2014 14:02:42 -0700

> i.e., that you are an editor, not a doc author? I just don't recall.

I thought that was the gist of several of your comments wrt to
consensus in the last WG meeting, but I could be misrepresenting you.
If so, my apologies.

> my 28 years of IETF participation.

But that's not what I'm saying - what I'm saying is I can't say in
advance that this standard is one I want to implement, given that I
don't know what it says yet. I think it would be pretty crazy to say
otherwise.

I am not saying this is a _likely_ outcome, just that its a possible one.

It doesn't seem like a point worth dwelling on.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 19 Aug 2014 22:47:41 +0100

> On 19 August 2014 11:36, Stephen Kent <[email-masked]> wrote:
<snip>
>> In Section 7.2, there is another reference to EV certs, in the context of
>> wildcard use. In that instance the RFC suggests that the guidelines
>> published in 2009 allowed wildcards, whereas the RFC argued against their

I agree that the last sentence of RFC6125 section 7.2 does seem to imply 
that EV Guidelines v1.2 permits wildcards.  This implication is incorrect.

> It would be interesting to know if this is why EV now disallows wildcards.

It isn't.  The EV Guidelines have never permitted wildcards.  CABForum 
made that decision that all by itself.

EV Guidelines v1.0, published 2007, says "Wildcard certificates are not 
allowed for EV certificates".  v1.2, cited by RFC6125, says the same 
thing.  The current version, v1.4.5, says it twice!

EV Guidelines v1.0 predated the CERTID non-WG (which produced RFC6125) 
by several years.

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 19 Aug 2014 20:46:18 -0800

> my 28 years of IETF participation.

This has not been an issue yet, and to be honest I do not anticipate
that it will become one.  We will deal with should it come up, but
I'd rather go forward with a minimum of antagonism and with a continued
focus on moving the document along.

Melinda

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Aug 2014 10:58:13 -0400

Ben,
> don't know what it says yet. I think it would be pretty crazy to say
What you said above is fine. However, it is in contrast to what
yo said at the TRANS meeting with regard to one of the suggested
changes to the doc.
> It doesn't seem like a point worth dwelling on.
OK, I'll stop.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Aug 2014 11:11:05 -0400

Rob,

Thanks for the clarification.

Perhaps you should submit an errata for 6125.

Steve