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

From: "Peter Yee" <[email-masked]>
Date: Mon, 30 Mar 2015 21:09:21 -0700

We've been doing ASN.1 for more than 20 years.  Is it really that hard to
encode things as ASN.1?  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.

		-Peter

> From: Russ Housley <[email-masked]>
> Date: March 30, 2015 11:21:37 AM EDT
> To: Rob Stradling <[email-masked]>
> Cc: IETF PKIX <[email-masked]>
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 31 Mar 2015 09:48:11 +0100

Hi Peter,

On 31/03/15 05:09, Peter Yee wrote:
> 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

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.

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
> 
>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 31 Mar 2015 07:56:33 -0700

> We've been doing ASN.1 for more than 20 years.  Is it really that hard to

If it means that the system doing the encoding has to add ASN.1 code just to do the encoding, yes. There are few ASN.1 libraries, and they are only lightly maintained. You are asking for security applications to carry around additional code that would otherwise be unnecessary.

If it was assumed that all PKIX-processing software would need to descend into this extension, there might be a better argument, but they don't.

--Paul Hoffman

---

From: Russ Housley <[email-masked]>
Date: Tue, 31 Mar 2015 11:03:25 -0400

> If it was assumed that all PKIX-processing software would need to descend into this extension, there might be a better argument, but they don't.

ASN.1 processing is needed to get the value of the OCTET STRING from the extension, so I do not understand the point you are trying to make.

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 31 Mar 2015 08:18:36 -0700

> ASN.1 processing is needed to get the value of the OCTET STRING from the extension, so I do not understand the point you are trying to make.

At the beginning of the thread, it seemed like the issue was *encoding* the values, not decoding them. If the application has a PKIX decoder that can extract an extension, that does not mean that it already has an ASN.1 encoder. However, I'm not actively following TRANS so I might be missing something.

--Paul Hoffman

---

From: Melinda Shore <[email-masked]>
Date: Tue, 31 Mar 2015 07:51:41 -0800

On 3/31/15 7:18 AM, Paul Hoffman wrote:
>> ASN.1 processing is needed to get the value of the OCTET STRING
>> from the extension, so I do not understand the point you are trying
>> to make.
> 
> At the beginning of the thread, it seemed like the issue was
> *encoding* the values, not decoding them. 

Right, but there seems to be some suggestion that there is
certificate processing software out there that tries to decode
the contents of an extension it doesn't recognize or
understand.  I'm hopeful that people raising this concern can
be more specific and point out what software it is.  *That*
would be a pretty good example of the new information we've
been asking for.

Melinda

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 31 Mar 2015 16:10:23 +0000

Melinda,

I am in the camp that believes 6962 does not need to change in this regard.

So, even if we got the information you are seeking below, I hope the first try will be to tell that software developer that they are doing this wrong.  They should not try to decode an extension they do not understand.

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Tuesday, March 31, 2015 11:52 AM
To: [email-masked]
Subject: Re: [pkix] a question of cert (and OCSP) extension syntax

On 3/31/15 7:18 AM, Paul Hoffman wrote:
>> ASN.1 processing is needed to get the value of the OCTET STRING from 
>> the extension, so I do not understand the point you are trying to 
>> make.
> 

Right, but there seems to be some suggestion that there is certificate processing software out there that tries to decode the contents of an extension it doesn't recognize or understand.  I'm hopeful that people raising this concern can be more specific and point out what software it is.  *That* would be a pretty good example of the new information we've been asking for.

Melinda

---

From: Peter Yee <[email-masked]>
Date: Tue, 31 Mar 2015 13:20:56 -0700

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 <[email-masked]> wrote:

Hi Peter,

S.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 31 Mar 2015 12:49:09 -0800

On 3/31/15 12:20 PM, Peter Yee wrote:
> 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. 

It's not being made in trans.

Melinda