Stephen,
On 12/03/15 14:46, Stephen Kent wrote:
This gets to my point of why it is inappropriate to cite a
design decision of an Experimental RFC as an alternative to
existing Standards.
No, we currently have no existing standard or bcp that
says the OCTET STRING value has to be decodable as ASN.1.
So this is not a question of an alternative to an existing
standard but is only about a new standard.
I assume your comment is meant to apply to cert extensions.
In that context I agree. Suggesting that we create a new standard that
endorses using an OCTET STRING as a catch-all for X.509 is precisely the
sort or precedent setting that should be viewed from an architectural
perspective, not from the perspective of expedience.
The fact that a small group of implementers
elected to use a questionable encoding for a cert extension
does not, per se, justify perpetuating that.
Well, the above is clearly coming at the issue from only
one point of view, and "small group", "questionable" and
"perpetuating" are all pejorative terms when looked at
from the point of view of those who have running code.
The set of CAs and the one browser vendor that is known to have
implemented this represents a "small group" relative to the
set of folks who deal with certs overall. Because you agree
that this is a precedent-setting issue, it may ultimately affect
certs used in other contexts, so "small" seems very accurate.
I stand by my choice of the term "questionable" as well. Most folks
who I contacted see this as a hack, even if it is not expressly a violation
of 5280 or x.509.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
