On 12/03/15 14:45, Stephen Kent wrote:
<snip>
How does putting an RFC5246-encoding-rules SCT into an OCTET STRING
violate the sanctity of ASN.1 any more than the RFC5280 practice of
putting an RFC3986 URI into an IA5String does?
A URI is a string. there is no base data type for URI, so printable string
was the closest native ASN.1 base data type. That's a very reasonable
way to accommodate this data.
Or, to put it another way, why didn't the RFC5280 authors insist on
coming up with a different "pure ASN.1" format for encoding the
components of a URI?
Because, as I said above, a URI is a string.
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?
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?
If URIs didn't have to be (re-)defined in ASN.1 so that they could be
included in certs, then why should the 6962-bis structs be (re-)defined
in ASN.1 so that they can be included in certs?
[*] For example...
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
...could be represented in ASN.1 as...
URI ::= SEQUENCE {
scheme PrintableString,
hier_part HierPart,
query PrintableString OPTIONAL,
fragment PrintableString OPTIONAL
}
...etc, etc.
In contrast, the major elements of an SCT are a version # (integer), a
time value
(for which there are 2 base ASN.1 data types), a key ID (bit string), a
cert or TBS cert (which are already ASN.1), and the TBD CtExtensions
(which could, plausibly, be
designated as an OCTET STRING.
The vast majority of ASN.1 knowledgeable folks I know would find it easy
and obvious to encode an SCT in ASN.1.
Steve
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
