On 19 August 2014 11:36, Stephen Kent <[email protected]> wrote: > 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.
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. >>>> 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. It would be interesting to know if this is why EV now disallows wildcards. > 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. OK. _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
