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

From: Peter Gutmann <[email-masked]>
Date: Wed, 18 Mar 2015 07:10:11 +0000

Melinda Shore <[email-masked]> writes:

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

This isn't a case of standards rules-lawyering though (in any case the PKIX
spec is flexible enough that you can stuff anything you want into a
certificate if you interpret things just right, see the famous MPEG-of-cat
quote), it's that this is creating a situation where an *X.509 standards-
compliant certificate* contains data that can't be processed by an *X.509
standards-compliant certificate application*.

Peter.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 18 Mar 2015 09:32:03 +0000

> standards-compliant certificate application*.

Peter, are you saying that _all_ X.509 standards-compliant certificate 
applications MUST be able to process _all_ data in _all_ certificates?

That would make it impossible to define any new certificate extensions 
in the future, because existing software cannot possibly already support 
extensions that haven't even been defined yet!

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

---

From: Sean Leonard <[email-masked]>
Date: Wed, 25 Mar 2015 09:20:47 -0500

> standards-compliant certificate application*.

I agree with Peter. Keep the encoding as ASN.1 for this extension. It is not particularly onerous, and it preserves compatibility for other applications.

+1

Sean

---

From: Rob Stradling <[email-masked]>
Date: Wed, 25 Mar 2015 14:44:23 +0000

> I agree with Peter. Keep the encoding as ASN.1 for this extension. It is not particularly onerous, and it preserves compatibility for other applications.

How exactly might the certificate extension we're talking about [1] 
break compatibility with other applications?

The Subject Key Identifier extension uses the exact same ASN.1 syntax 
(the content of the extension is a plain OCTET STRING).  RFC5280 does 
not require applications to recognize this extension.

I'm not aware of any applications that choke on the Subject Key 
Identifier extension, so why should we expect any to choke on the 
6962-bis extension?

[1] 
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/?include_text=1
   Sections 3.4.2 and 3.4.2.2

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 26 Mar 2015 11:24:37 -0400

Any views on the attached contribution on
the subject new ITU-T Recommendation for
the upcoming SG17 meeting is appreciated.
The existing draft text from early last year is
provided to understand the context.

Otherwise it can be regarded as FYI for the
related communities that intersect at PKIX.

--tony

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 26 Mar 2015 16:42:38 +0100

Tony on the war path again. What would the life be without some
entertainment.

I certainly valuate any comments from the PKIX experts. However, I do not
believe the work has progressed sufficiently to bother the PKIX experts.
Later, I will certainly ask for the views of the many PKI experts on the
PKIX list (with or without the help from Tony). 

Regards,

Erik 

-----Oprindelig meddelelse-----
Fra: pkix [mailto:[email-masked]] På vegne af Tony Rutkowski
Sendt: 26. marts 2015 16:25
Til: IETF PKIX
Emne: [pkix] update on ITU-T Public-key infrastructure: Profile

Any views on the attached contribution on the subject new ITU-T
Recommendation for the upcoming SG17 meeting is appreciated.
The existing draft text from early last year is provided to understand the
context.

Otherwise it can be regarded as FYI for the related communities that
intersect at PKIX.

--tony

---

From: George Michaelson <[email-masked]>
Date: Thu, 26 Mar 2015 10:42:44 -0500

did I mis read something, or does one of these documents seriously propose
we move to using the ISO3166 aligned 3char economy codes?

thats going to be interesting.

also, SNI and wildcard is 'TBD' -so a fairly important thing we're dealing
with, lacks definitional quality

On Thu, Mar 26, 2015 at 10:24 AM, Tony Rutkowski <[email-masked]> wrote:

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

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 27 Mar 2015 12:44:52 -0500

Hi Rob, all,

coming to your question: the extension /*will not break compatibility as 
long as it is not marked critical*/. However, there might be some 
aspects you want to think a bit more deeply about before taking a decision.

This said, I think that the text written in section 3.4.2 is wrong and 
needs to be replaced.

In particular, the argument about the encoding is weird - from the I-D:

        One or more SCTs can be embedded in an X.509v3 extension that is
        included in a certificate or an OCSP response.  Since RFC5280
        requires the "extnValue" field (an OCTET STRING) of each X.509v3
        extension to include the DER encoding of an ASN.1 value, we cannot
        embed a "SignedCertificateTimestampList" directly.  Instead, we have
        to wrap it inside an additional OCTET STRING (see below), which we
        then put into the "extnValue" field.

In my opinion, this text should be removed (trying to justify the use of 
a data type in the encoding because you do not want to define the 
required structure in ASN.1 does not really look.. good in an I-D, I am 
surprised it is even there).

However, more considerations are required here. If you want the 
extension to have a non-ASN.1 structure it is fine, but that will have 
implication over the (format) compliance of data in the certificate. 
This was marginally mentioned in previous posts, but it seems it 
requires a more explicit explanation since it was not well understood.

In particular, from a parsing perspective, when using the proposed 
encoding, the client will not perform any validation over the contents 
of the extension since this is just a blob. Usually this type of 
encoding is used for binary contents that have no internal structure 
(e.g., a value of a key or a digest), but it is usually avoided for 
complex types (again, to provide format validation of the contents).

The real question here is: are you willing to live with not validating 
the format of the content of the extension when the extension is 
actually parsed? Are you considering the possible attack vectors that 
can derive from that (i.e. allowing custom contents in the extension)? I 
hope you already discussed these aspects before proposing the extension. 
If not, my suggestion is to go back to the drawing board and seriously 
considering these aspects. If you go ahead with the current choice, I 
would suggest to remove the 3.4.2 text and add some considerations about 
it in the security considerations section (although, in that case I 
would STRONGLY suggest to revisit your choice).

This is usually a good rule of thumb when it comes to adding extensions.

Another operational consideration that was pointed out is about 
debugging the bits on the wire. If you use ASN.1 structures, standard 
network tools can parse the extension properly - however, again, this 
will not be the case for OCTET STRING blobs. Thus, debugging of the 
extension (in case of issues) can only happen at the end points (where 
the extension parser is available), not on the wire.

I hope this helps clarifying the issues with the current proposal.

Just my 2 cents.

Cheers,
Max

On 3/25/15 9:44 AM, Rob Stradling wrote:
>> I agree with Peter. Keep the encoding as ASN.1 for this extension. It 
>> is not particularly onerous, and it preserves compatibility for other 
>> applications.
>

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 27 Mar 2015 13:23:04 -0500

Hi Rob, all,

last consideration about the I-D - there are a bunch of OID values that 
are used throughout the document that are using PRIVATE (Google) OIDs in 
the document - this is *completely wrong*! Private OIDs should not be 
used for I-Ds.

The authors should request a new OID assigned for trans under (most 
probably) the id-pkix OID and then define the required OIDs in that 
space. This should also be reflected, I think, in the IANA consideration 
section.

For example:

     id-trans             OBJECT IDENTIFIER ::= { id-pkix  XX }
     id-trans-xxxx   OBJECT IDENTIFIER ::= { id-trans   1 }
     ...

Cheers,
Max

P.S.: Cross posting this message to the TRANS ml so that the WG can 
consider these issues in the I-D.

On 3/27/15 12:44 PM, Massimiliano Pala wrote:
> Hi Rob, all,
>
> coming to your question: the extension /*will not break compatibility 
> as long as it is not marked critical*/. However, there might be some 
> In my opinion, this text should be removed (trying to justify the use 
> of a data type in the encoding because you do not want to define the 
> required structure in ASN.1 does not really look.. good in an I-D, I 
> am surprised it is even there).
>
> can derive from that (i.e. allowing custom contents in the extension)? 
> I hope you already discussed these aspects before proposing the 
> extension. If not, my suggestion is to go back to the drawing board 
> and seriously considering these aspects. If you go ahead with the 
> current choice, I would suggest to remove the 3.4.2 text and add some 
> considerations about it in the security considerations section 
> (although, in that case I would STRONGLY suggest to revisit your choice).
>
>>> I agree with Peter. Keep the encoding as ASN.1 for this extension. 
>>> It is not particularly onerous, and it preserves compatibility for 
>>> other applications.
>>

---

From: Rob Stradling <[email-masked]>
Date: Mon, 30 Mar 2015 08:16:56 +0000

> Hi Rob, all,

Hi Max.

> long as it is not marked critical*/.

Exactly.

> However, there might be some

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.

> surprised it is even there).

This text was added because some folks found the description in RFC6962 
to be unclear.

See http://trac.tools.ietf.org/wg/trans/trac/ticket/14

> extension to have a non-ASN.1 structure it is fine,

Great.

> but that will have
> actually parsed?

Yes (for applications that don't recognize the extension).

Applications that do recognize the extension will validate the 
(non-ASN.1) format and verify the SCT's signature.

> Are you considering the possible attack vectors that

Such as?

> I hope you already discussed these aspects before proposing the extension.

Because the feature set of "standard network tools" is fixed forever?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Mar 2015 07:08:00 -0700

On Mar 30, 2015, at 1:16 AM, Rob Stradling <[email-masked]> wrote:
> 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.

Excellent summary! +1.

--Paul Hoffman

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 30 Mar 2015 11:10:49 -0400

This text is scheduled for adoption at
the upcoming ITU-T SG17 meeting.
It would be useful for those reviewing
the adoption to get any proffered PKIX
suggestions.

thanks,
--tony

---

From: Russ Housley <[email-masked]>
Date: Mon, 30 Mar 2015 11:21:37 -0400

> 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: Paul Hoffman <[email-masked]>
Date: Mon, 30 Mar 2015 08:40:39 -0700

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

--Paul Hoffman

---

From: Russ Housley <[email-masked]>
Date: Mon, 30 Mar 2015 11:46:50 -0400

> 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.  The non-ASN.1 structure is easily represented as an ASN.1 structure, which would allow one of the OCTET STRING wrappings to be removed.  This just seems much cleaner to me.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 30 Mar 2015 11:50:10 -0400

I think that the S/MIME mail list is the more appropriate place to discuss this topic. I have started a thread over there.

Russ

On Mar 30, 2015, at 11:10 AM, Tony Rutkowski wrote:

> <T13-SG17-150408-TD-PLEN-1697!!MSW-E.doc>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Mar 2015 20:23:43 +0300

> On Mar 30, 2015, at 6:46 PM, Russ Housley <[email-masked]> wrote:
> 
> Paul:
> 
> 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.

I realize that for a public part of a diffie-hellman exchange there is a natural ASN.1 structure (a sequence of two integers or a boolean and an integer), but we could dream up something like that for an email address as well.

Yoav

[1] http://tools.ietf.org/html/rfc5280#section-4.2.1.6

---

From: Sean Leonard <[email-masked]>
Date: Mon, 30 Mar 2015 12:09:19 -0700

> 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