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

Steve,

I don't think it's an unreasonable argument to make. And I should have been clearer below. Having sat through a week of ASN.1-bashing/text-encoding-glorifying in Dallas, my point is simply that the alleged difficulty in handling ASN.1 is overblown and should not be used in making the argument against using an ASN.1 encoding of the extension value. Perhaps I'm overly sensitive to the implication that ASN.1 is too difficult. I buy Russ's argument regarding the encoding, but I will admit that there are many larger points to be decided in the IETF. :-).

                               -Peter

On Mar 31, 2015, at 1:48 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi Peter,

> On 31/03/15 05:09, Peter Yee wrote:
> We've been doing ASN.1 for more than 20 years.  Is it really that hard to
> encode things as ASN.1?  

But that's not the question. The question is whether or not it is
reasonable for the IETF to object if someone (or some wg) has chosen
to use another encoding style for an X.509 extnValue?

> I understand that text encoding is readable and
> even fashionable, but it's not like ASN.1 is the bugbear it's made out to
> be.

In the case in hand in trans, we're not dealing with text encoding
but with TLS style encoding, since trans has to use both forms, they
have chosen to use the TLS style for an X.509 extension value. In
other words, this is not an ASN.1 hate situation.

If one wanted to generalise from the trans case, I think you'd ask
the question this way: when defining an X.509 extension for protocol
foo, is it reasonable that the extnValue uses the encoding style
of protocol foo, (wrapped in an OCTET STRING)?

S.

> 
>       -Peter
> 
>> From: Russ Housley <housley@vigilsec.com>
>> Date: March 30, 2015 11:21:37 AM EDT
>> To: Rob Stradling <rob.stradling@comodo.com>
>> Cc: IETF PKIX <pkix@ietf.org>
>> Subject: Re: [pkix] a question of cert (and OCSP) extension syntax
>> 
>> Rob:
>> 
>>> 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.
>> 
>> Russ
> 
> 
> 
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix