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

From: Peter Gutmann <[email-masked]>
Date: Wed, 18 Mar 2015 03:28:57 +0000

Stephen Kent <[email-masked]> writes:

>Since the bulk of the data items have an obvious ASN.1 representation, and
>the certificate or TBS certificate are native ASN.1 structures, we feel that
>the decision to stuff all of the data items into an OCTET STRING is
>inappropriate, and that it sets a bad precedent for others developing
>certificate (and OCSP) extensions in the future

I'd already discussed this in private with some of the folks involved, my
reasoning was exactly the same as yours, if you want this to be able to be
processed by anything that uses certs then it has to be compatible with
standard PKI software, which means encoding it in a form that PKI software can
work with it.  Their response was that it was only intended for use in TLS so
having it as an opaque (outside of TLS) blob wasn't a problem.  I didn't agree
with that because it's either going to fail and sink without a trace, or
succeed and end up being used in lots of places that aren't TLS, neither of
which are compatible with the TLS-only view.

The impression I got was that the decision to use the TLS encoding was a
foregone conclusion and there wasn't much chance of changing it.

Peter.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 17 Mar 2015 22:22:44 -0800

> foregone conclusion and there wasn't much chance of changing it.

It's not so much that it's a foregone conclusion but rather that it's
what's in the document until someone can either point to some normative
specification that it violates or can point to something that actually
would break.  Finding it distasteful is not sufficient.  Unfortunately
none of the parties on either side of the discussion have shown even
a passing interest in compromise, I feel very strongly that chairs
should not be making unilateral decisions about technical content, and
there's implementation experience and running code based on 6962.  I
don't think the conditions for changing the encoding are particularly
onerous.  So, here we are.

Melinda

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Mar 2015 14:10:50 -0400

Melina did not mention that 6962 is an experimental RFC.

I am most concerned by the precedent this sets, both in terms
of stuffing data that has a natural ASN.1 representation into
an OCTET STRING and the notion of using an experimental RFC
as a basis for establishing such a precedent.

Steve
> what's in the document until someone can either point to some 
> normative specification that it violates or can point to something 
> that actually would break. Finding it distasteful is not sufficient. 
> Unfortunately none of the parties on either side of the discussion 
> have shown even a passing interest in compromise, I feel very strongly 
> that chairs should not be making unilateral decisions about technical 
> content, and there's implementation experience and running code based 
> on 6962. I don't think the conditions for changing the encoding are 
> particularly onerous. So, here we are. Melinda