Rob,
Steve, Russ,
"If it could be defined in ASN.1, then it MUST be defined in ASN.1".
Does that accurately capture what you're both saying?
I can't speak for Russ, but for me, not exactly. Looking beyond the hack of
putting data in an OCTET STRING to circumvent the obvious intention of
5280, I'd
say that if the data types in an extension are readily represented in
ASN.1, then
the extension SHOULD be structured as ASN.1. The SCT meets that criteria.
A few folks have argued that experience with 6269 shows that it is possible
to make the current definition work. I don't dispute that. However, it
sets a bad
precedent to endorse this approach to cert extension definitions,
established
via Experimental RFC. I suspect that if 6962 had gone through the
reviews required
for a Standards Track RFC, this topic would have been raised much
earlier, and I
suspect that the proposed syntax would have been rejected. This sets a
bad precedent
in terms of the use of Experimental track RFCs as well, IMHO.
URIs are strings, but they have structure (see RFC3986 Appendix A).
Therefore, an alternative way to represent URIs could have been
defined in ASN.1 [*]. RFC5280 and its predecessors did not do this.
Why not?
I am not an author of 5280, so I defer to Russ on this. But, as PKIX
co-chair, my view was
precisely what I said earlier, i.e., a URI is a string, so mapping it to
PrintableString
seems reasonable. I have not argued that one has to delve into the
structure of a string
to beak it into a more fine grained ASN.1 object.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
