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

[Massimiliano Pala <[e-mail]>]

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 
>>> <[e-mail]> wrote:
>>>
>>>> Melinda Shore <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix