Re: [pkix] a question of cert (and OCSP) extension syntax

[Sean Leonard <[e-mail]>]

On Mar 30, 2015, at 10:23 AM, Yoav Nir <[e-mail]> wrote:

> 
>> On Mar 30, 2015, at 6:46 PM, Russ Housley <[e-mail]> wrote:
>> 
>> Paul:
>> 
>>>>> I think it's only "wrong" and "weird" if you take the view that "if it could conceivably be constructed in ASN.1, then it MUST be constructed in ASN.1".  I don't take that view.
>>>> 
>>>> Certificates are ASN.1, and RFC 5280 (and its predecessors) say that extensions are OCTET STRING wrapped ASN.1 structures.  From section 4.2 of RFC 2459:
>>>> 
>>>> 	Each extension includes an OID and an ASN.1 structure.
>>> 
>>> I always interpreted the "an ASN.1 structure" there as meaning that any structure was acceptable, whether it was SEQUENCE or INTEGER or OCTET STRING or whatever.
>> 
>> The usage in this case is a non-ASN.1 structure shoved into an OCTET STRING and then wrapped in an OCTET STRING.
> 
> That is not without precedent.  A subject alternative name ([1]) of type rfc822Name is required to be formatted according to section 4.1.2 of RFC 2821, and that’s not ASN-1 formatted.

The counterpoint is that rfc822Names (e-mail addresses) are human-readable and usually transmitted in that exact format, namely in protocols where it has to be unpacked into local-part and domain components, such as RFC 5322 (e-mail format) and RFC 5321 (SMTP), as well as in prose text. The same logic applies to dNSNames.

The sequence of data at issue here is not human-readable, certainly not in the same way as those examples.

Sean