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

[Rob Stradling <[e-mail]>]

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

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