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

From: Massimiliano Pala <[email-masked]>
Date: Fri, 27 Mar 2015 18:43:33 -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 
> 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:
>> On 25/03/15 14:20, Sean Leonard wrote:
>>> On Mar 18, 2015, at 2:10 AM, Peter Gutmann 
>>> <[email-masked]> wrote:
>>>
>>>> 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*.
>>>
>>> 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
>>
>
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Melinda Shore <[email-masked]>
Date: Fri, 27 Mar 2015 19:03:17 -0500

> the document - this is *completely wrong*! Private OIDs should not be

It's fine while the document is in development.  New OIDs
will be requested before the document exits wg last call, but
it's one of a number of things in a draft that changes as
the document progresses.  You're correct that the IANA
considerations section will need to be updated, though.

Melinda

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 27 Mar 2015 19:31:25 -0500

Hi Melinda,

I am sorry but I disagree. This should have been fixed long time ago - 
no Google private OIDs should have been put in a WG document in the 
first place.

Cheers,
Max

On 3/27/15 7:03 PM, Melinda Shore wrote:
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 28 Mar 2015 03:58:39 +0000

OID's are just distributed opaque identifiers.  Doesn't bother me, but if the WG wants to change OID's and break deployed software, go for it

It will might be hard to get a PKIX arc.  A Trans arc under IETF seems more feasible.

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Massimiliano Pala <[email-masked]>
Date: Sat, 28 Mar 2015 00:14:08 -0500

Hi Rich,

I do not think there is any precedence about using private OIDs for I-Ds 
- the use of Google's OIDs is ok at Google, not for a standard. The 
first reason is because Google's controls its own sub-tree and can 
change the sub tree at any time - not appropriate for an RFC. The second 
reason is that, since the document is defining extensions for 
certificates and OCSP messages (both under PKIX), the natural place is 
actually under PKIX.

I also want to point out that OIDs are not just opaque identifiers - if 
that was the case, we would not use a hierarchical structure. The 
sub-tree where the OID is is actually important.

This said, I have two questions for you:

 1. Why this would not be the appropriate base OID ?
 2. Which base OID are you referring to when you say "under IETF" ?

Cheers,
Max

On 3/27/15 10:58 PM, Salz, Rich wrote:
>
> OID’s are just distributed opaque identifiers.  Doesn’t bother me, but 
> if the WG wants to change OID’s and break deployed software, go for it
>

---

From: Leif Johansson <[email-masked]>
Date: Sat, 28 Mar 2015 10:14:03 -0500

> 27 mar 2015 kl. 18:43 skrev Massimiliano Pala <[email-masked]>:
> 
> 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.
> 

sais who?

> 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:
> 
> P.S.: Cross posting this message to the TRANS ml so that the WG can consider these issues in the I-D.
> 
> 
>> 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.
>> 
>>    embed a "SignedCertificateTimestampList" directly.  Instead, we have
>> 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).
>> 
>> 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.
>> 
>>>> On Mar 18, 2015, at 2:10 AM, Peter Gutmann <[email-masked]> wrote: 
>>>> 
>>>>>> 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 
>>>>> 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 
>>>> 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

---

From: Massimiliano Pala <[email-masked]>
Date: Sat, 28 Mar 2015 11:29:05 -0500

Hi Leif, all,

On 3/28/15 10:14 AM, Leif Johansson wrote:
> 27 mar 2015 kl. 18:43 skrev Massimiliano Pala <[email-masked] 
> <mailto:[email-masked]>>:
>
>> 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.
>>
>
> sais who?
Well, in this case, until we have an official position from IETF, me. I 
might be wrong, but it is evident that this is not a standard approach 
followed as common practice in the past.

However, my concerns are based on organizational and engineering 
considerations.

First of all, I have not seen this approach taken anywhere else - raw 
values within the document. We defined many OIDs in the past in the 
security area, and I do not recall this approach to ever been taken or 
allowed (with exceptions, I agree, but very limited and definitely not 
in recent years).

Second, I think that allowing the use of OIDs from different sub-trees 
for extending PKIX protocols and structures is not a good idea - we have 
a tree structure for a reason: be able to group together what belong 
together. Otherwise, let's just use random numbers, why bothering with a 
structure for OIDs?

Third, I have my concerns in adopting OIDs from a private sub-tree given 
the decentralized nature of the OIDs (what is the ownership of OIDs in a 
private sub-branch?)

I hope this clarifies my position.

Cheers,
Max

---

From: Melinda Shore <[email-masked]>
Date: Sat, 28 Mar 2015 12:15:18 -0500

The oddest thing, I think, about this discussion is the
apparent expectation that working group drafts be adopted
in final shape.  That's not what happens.  Indeed, if
it were, we wouldn't need working groups in the first place.

Melinda

---

From: Russ Housley <[email-masked]>
Date: Sun, 29 Mar 2015 12:00:45 -0400

In this case, the document was published with OIDs from a non-IETF OID arc long ago.  I see no reason to disrupt those implementations, and in fact, having two OIDs with exactly the same semantics is confusing.

If new OIDs are needed, we ought to assign them from an IETF arc managed by IANA.

Russ

On Mar 28, 2015, at 1:14 AM, Massimiliano Pala wrote:

> Hi Rich,
> 
> I do not think there is any precedence about using private OIDs for I-Ds - the use of Google's OIDs is ok at Google, not for a standard. The first reason is because Google's controls its own sub-tree and can change the sub tree at any time - not appropriate for an RFC. The second reason is that, since the document is defining extensions for certificates and OCSP messages (both under PKIX), the natural place is actually under PKIX.
> 
> I also want to point out that OIDs are not just opaque identifiers - if that was the case, we would not use a hierarchical structure. The sub-tree where the OID is is actually important.
> 
> Why this would not be the appropriate base OID ?
> Which base OID are you referring to when you say "under IETF" ?
> Cheers,
> Max
> 
> 
>> OID’s are just distributed opaque identifiers.  Doesn’t bother me, but if the WG wants to change OID’s and break deployed software, go for it
>>

---

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

RFC6962 defines 4 OIDs under Google's OID arc.

1.3.6.1.4.1.11129.2.4.3 (the Precertificate Poison certificate 
extension) and 1.3.6.1.4.1.11129.2.4.4 (the Precertificate Signing 
Certificate EKU OID) are both no longer required, due to the 
Precertificate format change.  They've both been removed from 6962-bis.

That leaves us with 1.3.6.1.4.1.11129.2.4.2 (the 
SignedCertificateTimestampList certificate extension) and 
1.3.6.1.4.1.11129.2.4.5 (the SignedCertificateTimestampList OCSP 
Response extension).
Ticket #10 (see comments 6 and 8) intends to extend and merge these two 
extensions into one new extension with a new OID.

I see no reason why we shouldn't use an OID from an IETF OID arc, as I 
wrote in ticket #10 comment 9.

6962-bis currently defines 1.3.6.1.4.1.11129.2.4.6 (the Redacted Labels 
certificate extension) and 1.3.6.1.4.1.11129.2.4.7 (the certificate 
extension to permit a Name-constrained intermediate CA certificate to be 
logged in place of end-entity certificates).
I see no reason why we shouldn't reassign these from an IETF OID arc too.

I am working on the assumption that "Russ, we're gonna need some OIDs 
for some cert/OCSP extensions - please can you assign some now, even 
though we haven't finished specifying the contents of these extensions 
yet?" would be greeted by a firm "No".  Hence why the draft is still 
using OIDs under Google's OID arc.

[1] http://trac.tools.ietf.org/wg/trans/trac/ticket/10

On 29/03/15 16:00, Russ Housley wrote:
> In this case, the document was published with OIDs from a non-IETF OID
> arc long ago.  I see no reason to disrupt those implementations, and in
> fact, having two OIDs with exactly the same semantics is confusing.
>
>> I do not think there is any precedence about using private OIDs for
>> I-Ds - the use of Google's OIDs is ok at Google, not for a standard.
>> The first reason is because Google's controls its own sub-tree and can
>> change the sub tree at any time - not appropriate for an RFC. The
>> second reason is that, since the document is defining extensions for
>> I also want to point out that OIDs are not just opaque identifiers -
>> if that was the case, we would not use a hierarchical structure. The
>>> OID’s are just distributed opaque identifiers.  Doesn’t bother me,
>>> but if the WG wants to change OID’s and break deployed software, go
>>> for it
>>>

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

---

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

The assignment of OIDs is handled by IANA.  See RFC 7299 for the official handover from the PKIX WG to IANA, which provides the policy for new OIDs in each part of the PKIX arc.

In addition, RFC 7120 provides the procedure for early assignments of IANA code points.  This applies to lots of different code points, not just OIDs in the PKIX arc.

Russ

On Mar 30, 2015, at 4:55 AM, Rob Stradling wrote:

> I am working on the assumption that "Russ, we're gonna need some OIDs for some cert/OCSP extensions - please can you assign some now, even though we haven't finished specifying the contents of these extensions yet?" would be greeted by a firm "No".  Hence why the draft is still using OIDs under Google's OID arc.

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Mar 2015 10:40:08 -0500

There is nothing wrong with non-SDO OIDs in Internet-Drafts, certainly.

But also: there is nothing wrong with the use of non-SDO OIDs in RFCs
either.  (For the reasons that others have stated, namely, that the
assigning organization gives up control when the arc is assigned.)

Nico
--

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 30 Mar 2015 16:18:46 +0000

> I am sorry but I disagree. This should have been fixed long time ago - no
> Google private OIDs should have been put in a WG document in the first
> place.

Are you also bothered by the OID's in CMS S/MIME and other pkcs-derived RFC's?

At any rate,  Russ has already responded on the issue of existing OID's: leave as-is to avoid confusion and disrupting implementations.

	/r$

---

From: Warren Kumari <[email-masked]>
Date: Mon, 30 Mar 2015 11:35:58 -0500

> Are you also bothered by the OID's in CMS S/MIME and other pkcs-derived RFC's?

... and the other N RFCs:
wkumari-macbookpro1:rfc-mirror wkumari$ grep '1.3.6.1.4' * | awk
'{print $1}' | sed 's/:.*//' | sort | uniq | wc -l
      99

Sure, some of those include lists of assigned numbers, but we also
have things like:
RFC2079 - Definition of an X.500 Attribute Type and an Object Class to
Hold Uniform Resource Identifiers (URIs) (umichAttributeType.57)
RFC2601 - ILMI-Based Server Discovery for ATMARP (ATM Forum Service
Registry - atmfSrvcRegATMARP)
RFC4511 - Lightweight Directory Access Protocol (LDAP): The Protocol
(using 1.3.6.1.4.1.1466.1.2.3 - The description for 1.3.6.1.1466 says:
"This is an OID assignment to the person Mark Wahl. Many of the LDAPv3
OIDs are assigned below this point.")

We have a history of doing this. World hasn't ended yet...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf