Subject: Re: [saag] [pkix] (it updates RFC 2585) New Version Notification for draft-seantek-certfrag-02.txt

From: Stephen Farrell <[email-masked]>
Date: Sat, 5 Sep 2015 15:23:30 +0100

Hi,

Sean has asked me if I'd be ok with AD sponsoring this one. While it
seems reasonable as a thing one might want to do, I haven't seen that
it is something anyone else wants to use so I'm not convinced for now.

If you would use this or especially if you would implement this, please
speak up now. If you think doing this is a bad plan, now is also a
fine time to speak up.

My plan is to decide in a couple of weeks (Sep 19th). The default if we
get silence is that I'd not be sponsoring this one. If the response is
that a bunch of folks would use or implement, I'd be fine with AD
sponsoring it.

Thanks,
S.

On 13/11/14 05:23, Sean Leonard wrote:
> draft-seantek-certfrag-02 has been posted.
> 
> Among other nits, I think that this draft needs to be Standards Track with IETF Consensus because it updates RFC 2585, which is Standards Track, and application/pkix-cert and application/pkix-crl are in the standards tree [RFC 6838].
> 
> (Thanks Sean T.)
> 
> Sean
> 
> Begin forwarded message:
> 
>> From: [email-masked]
>> Subject: New Version Notification for draft-seantek-certfrag-02.txt
>> Date: November 12, 2014 at 7:15:00 PM HST
> 
> A new version of I-D, draft-seantek-certfrag-02.txt
> has been successfully submitted by Sean Leonard and posted to the
> IETF repository.
> 
> Name:		draft-seantek-certfrag
> Revision:	02
> Title:		URI Fragment Identifiers for the application/pkix-cert Media Type
> Document date:	2014-11-12
> Group:		Individual Submission
> Pages:		4
> URL:            http://www.ietf.org/internet-drafts/draft-seantek-certfrag-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-seantek-certfrag/
> Htmlized:       http://tools.ietf.org/html/draft-seantek-certfrag-02
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-seantek-certfrag-02
> 
> Abstract:
>   This memo describes Uniform Resource Identifier (URI) fragment
>   identifiers for PKIX certificates, which are identified with the
>   Internet media type application/pkix-cert.
> 
> 
> The IETF Secretariat
> 
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Paul Lambert <[email-masked]>
Date: Tue, 8 Sep 2015 18:32:59 +0000

>it is something anyone else wants to use so I'm not convinced for now.

The application and semantics of this RFC is unclear.  The only text
describing a use case is:
	"For example, a user agent may wish to draw
	attention to the "notAfter" time for an
	expired certificate.²

This seems broken in that the semantics of any one field needs to include
a notion of the validity of the certificate.

	"A URI that identifies a certificate will likely be used by an
	application or user for some security-related service, such as to
	retrieve the certificate as part of a validation procedure.  When a
	fragment identifies a part of a certificate, the application will
	define the behavioral semantics. "

>that a bunch of folks would use or implement,

Not interested and usage appears to be potentially problematic.

Paul

>I'd be fine with AD
>> Among other nits, I think that this draft needs to be Standards Track
>>with IETF Consensus because it updates RFC 2585, which is Standards
>>Track, and application/pkix-cert and application/pkix-crl are in the
>>standards tree [RFC 6838].
>> 
>> (Thanks Sean T.)
>> 
>> Sean
>> 
>> Begin forwarded message:
>> 
>> URL:            
>>http://www.ietf.org/internet-drafts/draft-seantek-certfrag-02.txt
>> Diff:           
>>http://www.ietf.org/rfcdiff?url2=draft-seantek-certfrag-02
>> 
>> Abstract:
>saag mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/saag

---

From: Sean Leonard <[email-masked]>
Date: Wed, 9 Sep 2015 15:33:47 -0700

Hello:

> a notion of the validity of the certificate.

Not really, or at least, that was not the intent. notAfter is just a field in the certificate. The purpose of the example was to motivate a use case, namely, if the certificate is expired in some validation context, the user agent can generate a URI like:

view-source://internal/checkcert?cert=foo#na

so that the modular certificate viewing component can highlight that particular data field.

An equally potent example could be given if the certificate is valid, to highlight when the certificate expires. Yet another example could be given is nobody has done a validation check; the user agent just wants to point out the notAfter time.

To reduce confusion, I can change that sentence to:
“For example, a user agent may wish to draw attention to the "notAfter" field of a certificate.”

-Sean

---

From: Sean Leonard <[email-masked]>
Date: Tue, 29 Sep 2015 09:38:33 -0700

By the way:

I wanted to point out that this certfrag draft is sliced out of a much 
larger proposal, which is ways to uniquely and securely identify 
certificates in text strings (i.e., URIs / URNs) for storage and 
interchange. This was not just a proposal out of thin air or whatever. 
To the extent that a certificate is uniquely identified, it is just as 
useful to identify a specific part of the certificate of interest.

The certfrag portion came out of draft-seantek-certspec-03. 
draft-seantek-certspec-04 refers to this draft (draft-seantek-certfrag).

Since draft-seantek-certspec-04, the URN proposal has hit some snags, 
mainly due to the glacially slow (and occasionally retrograde) progress 
of the URNBIS WG. Therefore I am pursuing a different line of attack 
with that one. I am hoping that we can at least see progress on some of 
these parts. My main fear is becoming that the apps people don't see the 
security angles, and vice-versa.

Sean