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

[Rob Stradling <[e-mail]>]

On 27/03/15 17:44, Massimiliano Pala wrote:
> Hi Rob, all,

Hi Max.

> coming to your question: the extension /*will not break compatibility as
> long as it is not marked critical*/.

Exactly.

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

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.

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

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

> However, more considerations are required here. If you want the
> extension to have a non-ASN.1 structure it is fine,

Great.

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

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
> can derive from that (i.e. allowing custom contents in the extension)?

Such as?

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

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

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

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: [phone]
Office Fax: [phone]
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.