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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
