Subject: Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT

From: Stephen Kent <[email-masked]>
Date: Tue, 03 Mar 2015 10:26:31 -0500

Erwann,

Thanks for the pointers to the IEEE work; we'll see how that progresses
and whether the PKI aspects of it transition to the IETF.

Also thanks for the acknowledgement that ASN.1 is considered
the preferred syntax for X.509 extensions.

Steve
> Bonsoir Stephen,
>
> 2015-02-27 22:16 GMT+01:00 Stephen Kent <[email-masked] 
> <mailto:[email-masked]>>:
>
>     Erwann,
>
>         The "TLS" syntax/notation is also used to describe
>         certificates and messages in ITS world. It's very bad, but
>         that's not RFC5246 authors's fault.
>
>     What is the "ITS" world? And is it under the IETF standards
>     umbrella? if not, then this is
>     not a good rationale for veering from the statement in 5246.
>
>
> "Intelligent Transport System". Cars, trucks, motorbikes, tramways, 
> trains, road equipment, ... See IEEE1609.2 and ETSI TS103097 if you're 
> curious :)
> That's not (yet) under IETF umbrella. Point taken.
>
>         X.509 permits the inclusion of anything in an extension, as
>         long as it's enclosed in something that has an ASN.1+DER
>         representation, whence the double OCTET STRING sometimes
>         found. That's not new to CT.
>
>     True, but I think that is not commonly done in standard
>     extensions. Do you have some examples
>     that counter my perception? In my experience, people developing
>     extensions for
>     X.509 usually try to avoid cramming arbitrary data into an OCTET
>     string.
>
>
> You're right again. I can't think of a single extension except 
> SignedCertificateTimestampList defined in anything other than ASN.1. 
> When working around X.509, ASN.1 is natural.
>
> Going back into "silent lurker" mode...
>
> -- 
> Erwann.
>
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Russ Housley <[email-masked]>
Date: Tue, 3 Mar 2015 11:02:45 -0500

Melinda:

> First, I need to apologize for being largely checked out the
> past while - I've been down with a particularly virulent flu
> and am still largely flattened by it.  I'll do better.

I'm sorry you were stricken, but I'm glad to hear you are feeling much better.

> Second, taking my chair hat off, a couple of comments on the
> syntax question: I'm not sure that there have been any
> technical arguments made for why either approach must be
> excluded, which would be the first place to start, I think.
> 5246 definitely does not say that that syntax must not be used
> for anything else, ever.  What it says is:
> 
> "The purpose of this presentation language is to document TLS only; it
> has no general application beyond that particular goal."
> 
> Because you've wanted to treat this legalistically I think it's
> reasonable to point out that the phrase "has no general application"
> does not exclude the use of the same syntax to describe what
> are TLS-coupled data structures, unless you're arguing that
> CT logging of TLS certs would be a "general application."  Even so,
> you don't have to look through many IETF specifications to find
> instances of later protocols violating some of the constraints written
> into earlier specifications - for example, in RSVP-TE extensions to
> RSVP.  So, I think that's a tough path to follow.
> 
> Frankly, in the absence of compelling technical arguments either
> way, my personal inclination is to privilege implementation.  Again,
> that's my *personal* inclination.  In the meantime, if there's a
> compelling technical argument against this encoding, it's definitely
> time to make it.  We do need to make progress and not keep
> going over the same ground and arriving at same outcomes.

At the time that certificate extensions were invented, the OCTET STRING wrapper was used so that the ASN.1 decode would not fail if an unsupported extension was encountered.  Some people complained about the performance hit that that additional wrapper imposed on universally supported extensions, but this is the syntax that was chosen by ITU-T in X.509 version 3.  I do not recall any discussion at that time about allowing the OCTET String to contain anything other than an ASN.1 DER encoded structure.

RFC 2459, section 4.2 says:  "Each extension includes an OID and an ASN.1 structure."  That remains in RFC 5280.

Russ

---

From: Rob Stradling <[email-masked]>
Date: Wed, 04 Mar 2015 11:11:07 +0000

On 03/03/15 16:02, Russ Housley wrote:
<snip>
> RFC 2459, section 4.2 says:  "Each extension includes an OID and an ASN.1 structure."  That remains in RFC 5280.

Russ, this is how X.680 defines the OCTET STRING type:

   "3.8.55  octetstring type: A simple type whose distinguished values
            are an ordered sequence of zero, one or more octets, each
            octet being an ordered sequence of eight bits.
    ...
    23.1  The octetstring type (see 3.8.55) shall be referenced by the
          notation "OctetStringType":
            OctetStringType ::= OCTET STRING"

It seems clear to me that an OCTET STRING can contain absolutely 
anything.  (If an OCTET STRING could only contain ASN.1 object(s), then 
surely that would defeat the whole point of having the OCTET STRING type 
in the first place?)

Regarding your quote from RFC2459/5280:
Is "ASN.1 structure" defined somewhere?  Does "structure" imply that it 
MUST be a constructed type such as a SEQUENCE or SET (rather than a 
primitive type such as OCTET STRING or INTEGER)?
I presume not, because RFC5280 also says:

   "Extension  ::=  SEQUENCE  {
         extnID      OBJECT IDENTIFIER,
         critical    BOOLEAN DEFAULT FALSE,
         extnValue   OCTET STRING
                     -- contains the DER encoding of an ASN.1 value
                     -- corresponding to the extension type identified
                     -- by extnID
         }"

Surely an OCTET STRING _is_ "an ASN.1 value"?

BTW, the clarifications proposed by this ticket might be relevant to 
this discussion:
http://trac.tools.ietf.org/wg/trans/trac/ticket/14

P.S. At least we're not trying to embed an MPEG video of a cat into a 
certificate field that you might expect to contain ASN.1 object(s).  ;-)
http://www.cypherpunks.to/~peter/T2a_X509_Certs.pdf (page 9)

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Ben Laurie <[email-masked]>
Date: Wed, 4 Mar 2015 11:42:15 +0000

On 3 March 2015 at 16:02, Russ Housley <[email-masked]> wrote:

> At the time that certificate extensions were invented, the OCTET STRING
> wrapper was used so that the ASN.1 decode would not fail if an unsupported
> extension was encountered.  Some people complained about the performance
> hit that that additional wrapper imposed on universally supported
> extensions, but this is the syntax that was chosen by ITU-T in X.509
> version 3.  I do not recall any discussion at that time about allowing the
> OCTET String to contain anything other than an ASN.1 DER encoded structure.
>

6962 and 6962-bis are compliant with 5280. The ASN.1 structure that is
included is an OCTET STRING. The value of that OCTET STRING is the TLS
structure.

The alternatives are:

a) Encode SCTs different ways for different contexts. This seems like
pointless complexity.

b) Change SCTs to ASN.1 structures, and wrap these in a TLS opaque when
presented in a TLS extension. This is exactly analogous to the current
situation, and analogous arguments can be made for/against it.

I hope no-one is arguing for a), leaving us with b), and no convincing
reason to choose it over the current format on the basis of what the
standards say (or vice versa), as far as I can see.

Given that since Jan 1 2015 significant numbers of certificates have been
deployed using the existing format, I suggest that the appropriate
resolution is to continue with the format that is already deployed.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Mar 2015 11:31:41 -0400

Ben,

> included is an OCTET STRING. The value of that OCTET STRING is the TLS 
the use of OCTET STRING is only superficially compliant; 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. Rob's observation about what X.680 says is not 
relevant to this debate:
the issue is not what an OCTET STRING is allowed to contain in general, 
but what is the syntax
of an X.509 extension.
> a) Encode SCTs different ways for different contexts. This seems like 
to me it seems entirely appropriate.
>
> b) Change SCTs to ASN.1 structures, and wrap these in a TLS opaque 
> when presented in a TLS extension. This is exactly analogous to the 
> current situation, and analogous arguments can be made for/against it.
I agree that this is unattractive.
> standards say (or vice versa), as far as I can see.
I am arguing for a).
> Given that since Jan 1 2015 significant numbers of certificates have 
> been deployed using the existing format, I suggest that the 
> appropriate resolution is to continue with the format that is already 
> deployed.
Experience gained with 6269 is relevant, as it presumably shows that 
implementers have been
able to make the current syntax work. But, an experimental RFC represent 
does not establish
a precedent relevant to a standards track RFC that precedes it. In many 
(most?) cases
Experimental RFCs receive little review before being published. If the 
IETF were to agree that
implementations based on such RFCs establish design precedents for 
standards track RFCs,
especially when they conflict with existing, standards track RFCs, this 
would encourage publication
of experimental RFCs as a way to game the system.

Steve

---

From: Rob Stradling <[email-masked]>
Date: Wed, 11 Mar 2015 17:18:50 +0000

On 11/03/15 15:31, Stephen Kent wrote:
> the use of OCTET STRING is only superficially compliant;

<silliness>
How about we base64-encode the SCT and put it in a PrintableString 
instead?  ;-)
</silliness>

> 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?

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?

> Rob's observation about what X.680 says is not relevant to this debate:
> but what is the syntax of an X.509 extension.
>>
>> The alternatives are:
>>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Mar 2015 17:30:29 +0000

Hi Steve,

> the issue is not what an OCTET STRING is allowed to contain in general,

Point of information. I remember talking with Hoyt about this
back before X.509v3 was started (Hoyt was the editor of X.509
then as you know) and in that conversation we concluded that
using OCTET STRING was better than ANY for exactly the reason
that someone might have a good reason to not use ASN.1 for an
extension value. (That was back during the UK MoD sponsored
sostdp pre-cursor to PKIX, I guess in '94 or early '95.)

That said, I can't think of any RFC that does that other than
6962.

But on the 3rd hand - 6962 hasn't broken anything that we know
of, so it's probably not incredibly dangerous.

And lastly, I don't believe we have any written down guidance
with IETF rough consensus on whether or not the OCTET STRING
has to be decodable using ASN.1.

So, my take as AD, is that the WG have the freedom to choose
what they want here and it's up to the WG chairs to figure
out where the rough consensus lies.

That said, if you separately wanted to discuss the point on (one
of) the saag or pkix lists, that might be useful since we may
find that values such as are proposed here work just fine or
break something or that there are other cases like this. If that
discussion turns up something we can always factor that in later,
so a separate discussion on this elsewhere shouldn't need to hold
up the trans WG.

Cheers,
S.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Mar 2015 17:31:16 -0400 (EDT)

> That said, I can't think of any RFC that does that other than

I looked for this and found a few examples:

RFC 3709 https://tools.ietf.org/html/rfc3709#section-4.1

HashAlgAndValue ::= SEQUENCE {
    hashAlg         AlgorithmIdentifier,
    hashValue       OCTET STRING }

RFC 3126 https://tools.ietf.org/html/rfc3126#section-3.2

   The data content type is intended to refer to arbitrary octet
    strings, such as ASCII text files; the interpretation is left to the
    application.  Such strings need not have any internal structure
    (although they could have their own ASN.1 definition or other
    structure).

RFC 5652 https://tools.ietf.org/html/rfc5652#section-4

  The data content type is intended to refer to arbitrary octet
    strings, such as ASCII text files; the interpretation is left to the
    application.  Such strings need not have any internal structure
    (although they could have their own ASN.1 definition or other
    structure).

Paul

---

From: Stephen Kent <[email-masked]>
Date: Thu, 12 Mar 2015 10:45:44 -0400

Rob,

> How about we base64-encode the SCT and put it in a PrintableString 
and then we specify delivery only via IP over avian carrier, as per RFC 
1149 :-).
> 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.
> coming up with a different "pure ASN.1" format for encoding the 
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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 12 Mar 2015 10:46:11 -0400

Stephen,
> sostdp pre-cursor to PKIX, I guess in '94 or early '95.)
I was party to that conversation, and although I've known
Hoyt for many years, I don't recall him every suggesting this
as a rationale.
> That said, I can't think of any RFC that does that other than
at least we agree on that :-).
> of, so it's probably not incredibly dangerous.
This gets to my point of why it is inappropriate to cite a
design decision of an Experimental RFC as an alternative to
existing Standards. The fact that a small group of implementers
elected to use a questionable encoding for a cert extension
does not, per se, justify perpetuating that.
> has to be decodable using ASN.1.
true. In my 17 years as PKIX co-chair this topic was never
considered, so there was no need to document this.
> out where the rough consensus lies

As per your suggestion, I will raise the topic on the PKIX list,
and bring it to the attention of the current X.509 editors.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Mar 2015 14:50:30 +0000

On 12/03/15 14:46, Stephen Kent wrote:
> existing Standards. 

No, we currently have no existing standard or bcp that
says the OCTET STRING value has to be decodable as ASN.1.
So this is not a question of an alternative to an existing
standard but is only about a new standard.

> The fact that a small group of implementers

Well, the above is clearly coming at the issue from only
one point of view, and "small group", "questionable" and
"perpetuating" are all pejorative terms when looked at
from the point of view of those who have running code.

S.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 16 Mar 2015 12:15:26 +0000

On 12/03/15 14:45, Stephen Kent wrote:
<snip>
> way to accommodate this data.
>

Steve, Russ,

"If it could be defined in ASN.1, then it MUST be defined in ASN.1".

Does that accurately capture what you're both saying?

URIs are strings, but they have structure (see RFC3986 Appendix A). 
Therefore, an alternative way to represent URIs could have been defined 
in ASN.1 [*].  RFC5280 and its predecessors did not do this.  Why not?

If URIs didn't have to be (re-)defined in ASN.1 so that they could be 
included in certs, then why should the 6962-bis structs be (re-)defined 
in ASN.1 so that they can be included in certs?

[*] For example...

    URI           = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

...could be represented in ASN.1 as...

    URI  ::=  SEQUENCE {
       scheme     PrintableString,
       hier_part  HierPart,
       query      PrintableString  OPTIONAL,
       fragment   PrintableString  OPTIONAL
   }

...etc, etc.

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 Mar 2015 12:56:53 -0400

> Does that accurately capture what you're both saying?

I'm saying that certificate extensions are OCTET STRING wrapped ASN.1 structures.  That is what RFC 2459, RFC 3280, and RFC 5280 all say.

The SubjectAltName extension includes a choice for URI, and it is carried in a single string, not broken into the ABNF parts.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Mar 2015 13:33:44 -0400

Rob,

> Does that accurately capture what you're both saying?
I can't speak for Russ, but for me, not exactly. Looking beyond the hack of
putting data in an OCTET STRING to circumvent the obvious intention of 
5280, I'd
say that if the data types in an extension are readily represented in 
ASN.1, then
the extension SHOULD be structured as ASN.1. The SCT meets that criteria.

A few folks have argued that experience with 6269 shows that it is possible
to make the current definition work. I don't dispute that. However, it 
sets a bad
precedent to endorse this approach to cert extension definitions, 
established
via Experimental RFC. I suspect that if 6962 had gone through the 
reviews required
for a Standards Track RFC, this topic would have been raised much 
earlier, and I
suspect that the proposed syntax would have been rejected. This sets a 
bad precedent
in terms of the use of Experimental track RFCs as well, IMHO.
> Therefore, an alternative way to represent URIs could have been 
> defined in ASN.1 [*].  RFC5280 and its predecessors did not do this.  
> Why not?
I am not an author of 5280, so I defer to Russ on this. But, as PKIX 
co-chair, my view was
precisely what I said earlier, i.e., a URI is a string, so mapping it to 
PrintableString
seems reasonable. I have not argued that one has to delve into the 
structure of a string
to beak it into a more fine grained ASN.1 object.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 17 Mar 2015 04:53:00 +0000

On 16 March 2015 at 16:56, Russ Housley <[email-masked]> wrote:

> I'm saying that certificate extensions are OCTET STRING wrapped ASN.1
> structures.  That is what RFC 2459, RFC 3280, and RFC 5280 all say.
>

Once more, the 6962 and 6962-bis extensions are OCTET STRING wrapped ASN.1
structures.

>
> The SubjectAltName extension includes a choice for URI, and it is carried
> in a single string, not broken into the ABNF parts.
>
> Russ
>

---

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

Stephen,
> standard but is only about a new standard.
I assume your comment is meant to apply to cert extensions.
In that context I agree. Suggesting that we create a new standard that
endorses using an OCTET STRING as a catch-all for X.509 is precisely the
sort or precedent setting that should be viewed from an architectural
perspective, not from the perspective of expedience.
> from the point of view of those who have running code.
The set of CAs and the one browser vendor that is known to have
implemented this represents a "small group" relative to the
set of folks who deal with certs overall. Because you agree
that this is a precedent-setting issue, it may ultimately affect
certs used in other contexts, so "small" seems very accurate.

I stand by my choice of the term "questionable" as well. Most folks
who I contacted see this as a hack, even if it is not expressly a violation
of 5280 or x.509.

Steve

---

From: Melinda Shore <[email-masked]>
Date: Fri, 20 Mar 2015 10:48:01 -0800

As I've said several times, unless there's new information, we're
done discussing this.

Melinda

---

From: Russ Housley <[email-masked]>
Date: Sun, 22 Mar 2015 13:14:28 -0400

Stephen Farrell and I discussed this today.  When this document reaches IETF Last Call, I will raise this question from two perspectives.  First, ask if others agree with my interpretation that the use of a structure other that ASN.1 is  prohibited by RFC 2459, RFC 3280, and RFC 5280.  Second, ask if this decision will break any certificate processing software.  

Russ