Re: [pkix] New Version Notification for draft-seantek-certfrag-00.txt

[Sean Leonard <[e-mail]>]

On Nov 5, 2014, at 4:29 PM, Sean Turner <[e-mail]> wrote:

> Seems like a reasonable way to do what you’re trying to do, but I’ve got two questions:
> 
> 1) Do you really, really need the MUST?  If an implementation doesn’t follow the rules and instead uses “sN” for the serial number fragment it’s still going to work right because they’re case-insensitive?  If that’s the case then maybe you could just drop that bit.

Okay, maybe “MUST” is unduly harsh. However, I like to have consistent casing, even though it is case-insensitive. Is “SHOULD” appropriate? If not, I can drop the RFC 2119 key word and simply say “The fragments defined in the table above are case-insensitive; nevertheless for consistency, a generator is supposed to produce the fragment identifiers with the same casing as provided in this memo.”

> 
> 2) The second part of the text in the security considerations gave me pause:
> 
>   A certificate displaying
>   application might zoom in on that aspect of the certificate, while a
>   public key-processing application might use a fragment identifier
>   like "#spki" to extract the "SubjectPublicKeyInfo" structure for
>   further processing. 
> 
> Are you saying the spki would be extracted for processing from the identifier or from the certificate?  I’m hoping the later.

It’s the certificate. Proposed revised text:

   A certificate displaying
   application might zoom in on that aspect of the certificate, while a
   public key-processing application might use a fragment identifier
   like "#spki" to extract the "SubjectPublicKeyInfo” structure
   from the certificate for further processing.

Sean