Re: [Trans] Compatibility of name redaction and EV

[Stephen Kent <[e-mail]>]

Ben,

> ...
>> 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
>> :-).
> Google is obviously not unique in this regard - it's true of all
> software, right?
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.
>
>>> 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).
>>
>> 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.
> 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