Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT

[Stephen Kent <[e-mail]>]

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