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

[Sean Turner <[e-mail]>]

On Nov 06, 2014, at 03:13, Sean Leonard <[e-mail]> wrote:

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

I’d just drop the 2119 language entirely and not try to use language based on RFC6919.  I really like to lock things down when you can but in this case if there’s clearly no interop issue, I’d go for less characters in the draft ;)

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

How about:

… , while a public key-processing application might use a fragment identifier like "#spki" to chose which certificate from which to extract the "SubjectPublicKeyInfo” structure for further processing.

It might also be worth adding a security consideration that the values in the fragment identifier shouldn’t be used in lieu of the values they’re supposed to be identifying because they’re not part of the actual certificate - or something like that.

Then, I think you’re done.

spt