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

Massimiliano Pala <> Fri, 27 March 2015 23:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4FAE41A0264 for <>; Fri, 27 Mar 2015 16:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yqgwtBF5hleA for <>; Fri, 27 Mar 2015 16:43:54 -0700 (PDT)
Received: from ( [IPv6:2001:4830:1600:2f4::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0739F1A0262 for <>; Fri, 27 Mar 2015 16:43:53 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DFD304125C for <>; Sat, 28 Mar 2015 00:43:50 +0100 (CET)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 23C56154CB92 for <>; Fri, 27 Mar 2015 23:43:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Balj3pRxBhT for <>; Fri, 27 Mar 2015 19:43:40 -0400 (EDT)
Received: from iMassi.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 2B667154B38A for <>; Fri, 27 Mar 2015 19:43:40 -0400 (EDT)
Message-ID: <>
Date: Fri, 27 Mar 2015 18:43:33 -0500
From: Massimiliano Pala <>
Organization: OpenCA Labs
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020202050409080602080802"
Archived-At: <>
Subject: Re: [Trans] [pkix] a question of cert (and OCSP) extension syntax
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Mar 2015 23:43:59 -0000

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 

For example:

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


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 
>>> <> wrote:
>>>> Melinda Shore <> 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] 
>>   Sections 3.4.2 and
> _______________________________________________
> pkix mailing list