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

From: Russ Housley <[email-masked]>
Date: Sat, 1 Nov 2014 12:22:41 -0400

I took a look at the draft, and is seems like a reasonable way to address the stated problem.

Russ

On Oct 26, 2014, at 11:35 AM, Sean Leonard wrote:

> Just wanted to follow up on this request for feedback/review for draft-seantek-certfrag, which defines fragment identifiers for certificates.
> 
> This is a short draft (just four pages--and the fourth page is just the author info). If you read it and don't find any issues, please let me know as well.
> 
> Thanks,
> 
> Sean
> 
> On 9/8/2014 12:58 PM, Sean Leonard wrote:
> 
> Hello PKIX and SAAG lists:
> 
> Based on discussions had at IETF 90, I have written up a new Internet-Draft to define URI fragment identifiers for certificates. The proposal is very simple, as there are only a limited number of well-defined PKIX certificate parts.
> 
> This text is a spinoff of draft-seantek-certspec, since the fragment definitions depend on the media type (application/pkix-cert), not on the URI scheme or other parts.
> 
> Feedback is appreciated.
> 
> Sean
> 
> *************************
> 
> A new version of I-D, draft-seantek-certfrag-00.txt
> has been successfully submitted by Sean Leonard and posted to the
> IETF repository.
> 
> Name:        draft-seantek-certfrag
> Revision:    00
> Title:        URI Fragment Identifiers for the application/pkix-cert Media Type
> Document date:    2014-09-08
> Group:        Individual Submission
> Pages:        4
> URL: http://www.ietf.org/internet-drafts/draft-seantek-certfrag-00.txt
> Status: https://datatracker.ietf.org/doc/draft-seantek-certfrag/
> Htmlized: http://tools.ietf.org/html/draft-seantek-certfrag-00
> 
> 
> Abstract:
>   This memo describes Uniform Resource Identifier (URI) fragment
>   identifiers for PKIX certificates, which are identified with the
>   Internet media type application/pkix-cert.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Sean Turner <[email-masked]>
Date: Wed, 5 Nov 2014 19:29:15 -0500

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.

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.

spt

---

From: Sean Leonard <[email-masked]>
Date: Thu, 6 Nov 2014 00:13:50 -0800

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

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

> 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

---

From: Sean Turner <[email-masked]>
Date: Thu, 6 Nov 2014 13:36:32 -0500

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

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

>   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