Stephen,
Hi Steve,
On 11/03/15 15:31, Stephen Kent wrote:
the use of OCTET STRING is only superficially compliant; it is
inconsistent with all of the
prior X.509 extensions of which I am aware, and with the text that Russ
Housley cited in
his message on 3/3. Rob's observation about what X.680 says is not
relevant to this debate:
the issue is not what an OCTET STRING is allowed to contain in general,
but what is the syntax
of an X.509 extension.
Point of information. I remember talking with Hoyt about this
back before X.509v3 was started (Hoyt was the editor of X.509
then as you know) and in that conversation we concluded that
using OCTET STRING was better than ANY for exactly the reason
that someone might have a good reason to not use ASN.1 for an
extension value. (That was back during the UK MoD sponsored
sostdp pre-cursor to PKIX, I guess in '94 or early '95.)
I was party to that conversation, and although I've known
Hoyt for many years, I don't recall him every suggesting this
as a rationale.
That said, I can't think of any RFC that does that other than
6962.
at least we agree on that :-).
But on the 3rd hand - 6962 hasn't broken anything that we know
of, so it's probably not incredibly dangerous.
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. 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.
And lastly, I don't believe we have any written down guidance
with IETF rough consensus on whether or not the OCTET STRING
has to be decodable using ASN.1.
true. In my 17 years as PKIX co-chair this topic was never
considered, so there was no need to document this.
So, my take as AD, is that the WG have the freedom to choose
what they want here and it's up to the WG chairs to figure
out where the rough consensus lies
That said, if you separately wanted to discuss the point on (one
of) the saag or pkix lists, that might be useful since we may
find that values such as are proposed here work just fine or
break something or that there are other cases like this. If that
discussion turns up something we can always factor that in later,
so a separate discussion on this elsewhere shouldn't need to hold
up the trans WG.
As per your suggestion, I will raise the topic on the PKIX list,
and bring it to the attention of the current X.509 editors.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
