Rob,
...
<silliness>
How about we base64-encode the SCT and put it in a PrintableString
instead? ;-)
</silliness>
and then we specify delivery only via IP over avian carrier, as per RFC
1149 :-).
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.
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.
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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
