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

[Massimiliano Pala <[e-mail]>]

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
>