Subject: Re: [Uri-review] PKCS#11 URI registration request review

From: Jan Pechanec <[email-masked]>
Date: Fri, 8 Feb 2013 17:28:59 -0800 (PST)

On Sat, 26 Jan 2013, Jan Pechanec wrote:

	hi, the section 5.2 of RFC 4395 notes "Allow a reasonable time 
for discussion and comments. Four weeks is reasonable for a permanent 
registration requests."

	I will wait for two more weeks if there is any feedback (which 
would be greatly appreciated) to make it 4 weeks in total, and if there 
is none I will continue with the next step, which is the submission to 
[email-masked].

	regards, Jan.

>	hello,
>
>	in accordance with section "5.2. Registration Procedures" of RFC 
>4395 "Guidelines and Registration Procedures for New URI Schemes", I 
>respectfully request a review for our planned permanent registration 
>request of the PKCS#11 URI as specified in the following I-D:
>
>	http://tools.ietf.org/html/draft-pechanec-pkcs11uri-08
>
>	the registration template is attached.
>
>	best regards, Jan Pechanec
>
>

-- 
Jan Pechanec
http://blogs.oracle.com/janp

---

From: Ted Hardie <[email-masked]>
Date: Mon, 11 Feb 2013 09:14:50 -0800

Hi Jan,

Some comments on a quick review:

In the examples you use newlines to make things more readable, and I
think that's
reasonable, but your justification says:

   Note that in some of the following examples,
   newlines and spaces were inserted for better readability which is
   allowed by [RFC3986].

I think that's a bit confusing.  If I understand you, what you mean to
say is that the
3986 allows you to use newlines in example text, not that it allows you to use
newlines and spaces "for better readability" in the actual URI.  Some re-wording
may be in order.

I also believe you may wish to make explicit statements about where on the
3986 ladder of comparison you intend for these attribute-value pairs
to fall.  As
it stands, some of the text about Library version indicates that you expect a
semantic comparison, but it is usual in cryptographic contexts to require
something that has much less wiggle room.   Explicit text on this would help
the reader understand what it is expected

regards,

Ted Hardie

On Fri, Feb 8, 2013 at 5:28 PM, Jan Pechanec <[email-masked]> wrote:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review

---

From: Larry Masinter <[email-masked]>
Date: Mon, 11 Feb 2013 15:07:23 -0800

It's completely unclear to me what advantage you get from having this stuff packed into a URI rather than some XML/JSON data structure, which would more easily address the I18N and other issues.
It seems like the applicability of this "scheme" is to fit into a "URI" slot in some protocol that doesn't need to be a URI but just some other kind of Identifier.

I'm willing to believe there's a justification and that the document just doesn't give it.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jan Pechanec
> Sent: Friday, February 08, 2013 5:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Uri-review] PKCS#11 URI registration request review
>

---

From: Darren J Moffat <[email-masked]>
Date: Tue, 12 Feb 2013 10:12:11 +0000

> It seems like the applicability of this "scheme" is to fit into a "URI" slot in some protocol that doesn't need to be a URI but just some other kind of Identifier.

A URI is easily specified in a configuration file or a configuration 
property of something else.

We already use the PKCS#11 URI syntax in Solaris in a number of places.

Our PKCS#11 OpenSSL ENGINE uses it for locating RSA/DSA priviate keys in 
PKCS#11 tokens.

You can use a PKCS#11 URI as the location of a wrapping key in a ZFS 
dataset property.  XML/JSON would be highly in appropriate there. eg:

  # zfs create -o encryption=on \
    -o keysource=raw,pkcs11:token=KMS;object=MyKey

Admins aren't going to hand craft XML/JSON in either of these cases.

-- 
Darren J Moffat

---

From: Jan Pechanec <[email-masked]>
Date: Tue, 12 Feb 2013 08:48:03 -0800 (PST)

On Mon, 11 Feb 2013, Larry Masinter wrote:

>It's completely unclear to me what advantage you get from having this 
>stuff packed into a URI rather than some XML/JSON data structure, which 
>would more easily address the I18N and other issues. It seems like the 
>applicability of this "scheme" is to fit into a "URI" slot in some 
>protocol that doesn't need to be a URI but just some other kind of 
>Identifier.

	 hi, while we don't want to limit its use, the primary objective 
is to use it as a simple string-based user-defined public/private key or 
an X.509 certificate identifier directly used by an application 
supporting PKCS#11 tokens. I can see that Darren already gave an example 
of its use in ZFS crypto in his reply.

	to address the I18N concern, the PKCS#11 specification allows 
UTF8 in most of the fields used in the scheme so we must support it, and 
while it would be easier to deal with it in XML/JSON, experience shows 
that it's not much of a concern as plain ASCII is being used while users 
benefit from the simple string format.
	
	I expect that the most common use of the identifier will be as a 
parameter value on a command line. To give you an idea what applications 
(and libraries) have already adopted it and use it as defined in the 
draft, there is a list of those I know of:

GnuTLS
	- GNU Transport Layer Security Library
	- www.gnutls.org
Gnome
	- by gnome-keyring since version 3.3.5
	- http://developer.gnome.org/gck/3.6/gck-PKCS11-URIs.html
p11-kit
	- kit for unification of PKCS#11 modules
	- http://cgit.freedesktop.org/p11-glue/p11-kit
OpenSC
	- tools and libraries for smart cards
	- https://www.opensc-project.org/opensc
	- via p11-kit
Solaris 11
	- for referencing keys in ZFS filesystem encryption
	- SunSSH to reference keys/certs used in the X.509 based 
	  authentication
OpenConnect
	- client for Cisco's AnyConnect SSL VPN
	- http://www.infradead.org/openconnect/
	- via pk11-kit

	Google search shows other communities or projects discussing or 
planning to use the scheme:

Fedora
	https://fedoraproject.org/wiki/PackagingDrafts/PKCS11
GnuPG
	via GnuTLS
	
>I'm willing to believe there's a justification and that the document 

	please let me know if the explanation above answers the concerns 
you raised and whether you think I need to update the draft accordingly.

	regards, Jan.

-- 
Jan Pechanec <[email-masked]>

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 13 Feb 2013 00:01:52 -0800 (PST)

On Mon, 11 Feb 2013, Ted Hardie wrote:

>say is that the 3986 allows you to use newlines in example text, not 
>that it allows you to use newlines and spaces "for better readability" 
>in the actual URI.  Some re-wording may be in order.

	hi Ted, I agree it is confusing, thanks for bringing it up. I'd 
like to change it to:

   This section contains some examples of how PKCS#11 token objects,
   PKCS#11 tokens, and PKCS#11 libraries can be identified using the
   PKCS#11 URI scheme.  Note that in some of the following examples,
   newlines and spaces were inserted for better readability.  As
   specified in Appendix C of [RFC3986], whitespace should be ignored
   when extracting the URI.  Also note that all spaces as part of the
   URI are percent-encoded, as specified in Appendix A of [RFC3986].

>I also believe you may wish to make explicit statements about where on 
>the 3986 ladder of comparison you intend for these attribute-value 
>pairs to fall.  As it stands, some of the text about Library version 
>indicates that you expect a semantic comparison, but it is usual in 
>cryptographic contexts to require something that has much less wiggle 
>room.  Explicit text on this would help the reader understand what it 
>is expected

	it sounds very reasonable and I'd like to add a new paragraph at 
the end of Section 3:

   As ordering of attributes in the PKCS#11 URI is not significant,
   comparison of URIs should be performed on a per-attribute basis after
   the URI itself is normalized as explained in Section 6 of [RFC3986].
   Caution should excercised when comparing the "id" attributes as their
   values may not be fully percent-encoded.  Library version ".N" should
   be interpreted as "0" for the major and "N" for the minor version of
   the library.  Library version "M" should be interpreted as "M" for
   the major and "0" for the minor version of the library.

	does it look OK to you?

	thanks a lot for your feedback.

	regards, Jan.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 Feb 2013 09:38:40 -0800

On Wed, Feb 13, 2013 at 12:01 AM, Jan Pechanec <[email-masked]> wrote:
Howdy,
>    URI are percent-encoded, as specified in Appendix A of [RFC3986].

This looks much better, thanks.

>    the major and "0" for the minor version of the library.
So, I think you are mixing the comparison of the values encoded in the
URI with the comparison of the URI itself.  If the typical mode of
employment is to deconstruct the URI into a set of attribute/value
pairs, it's fine for the using application to treat the result as
unordered.  But this may mean that there is no reasonable comparison
to be done here at the URI level.  You can be sure that two URIs match
if they are bit-for-bit identical, but there are lots of other
conditions in which they *may* be equivalent.

Do you expect people to actually compare at the URI level at all?

Ted

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 13 Feb 2013 23:26:01 -0800 (PST)

On Wed, 13 Feb 2013, Ted Hardie wrote:

	hello Ted,

>Do you expect people to actually compare at the URI level at all?

	no, I don't expect that. I have checked some recent RFCs 
defining URIs and it seems to me that those that do not expect to be 
compared do not deal with comparison at all (for example, "mailto" and 
"tn3270" RFCs).

	my intention above was that if I specify how to compare URIs 
then it also specifies how to compare values, too. I understand that's 
probably not the best way to do it. On the other hand, we don't know how 
PKCS#11 URI might be used so it may be worth to specify that.

	I'm not sure what would be the best here. I could just take the 
explanation of how library-version value should be read and move it out 
of the Example section, or I could put together a small section on URI 
comparison, explicitly stating how to do that (as in RFC 5870 on geo 
URI, for example).

	would you suggest me to write a section on comparision of URIs 
when we don't expect people to do it?

	regards, Jan.

---

From: Jan Pechanec <[email-masked]>
Date: Sun, 17 Feb 2013 13:02:49 -0800 (PST)

>compared do not deal with comparison at all (for example, "mailto" and

	hi Ted, after putting some more thought to it, given that we do 
not expect PKCS#11 URIs to be compared, I just extended the last 
paragraph of the section "3.3.  PKCS#11 URI Scheme Syntax" on the 
information how to interpret values for the library-version attribute:

<t>It is recommended to percent-encode the whole value of the "id"
attribute which is supposed to be handled as arbitrary binary data.
Value "M" of the "library-version" attribute should be interpreted as
"M" for the major and "0" for the minor version of the library.
Library version ".N" should be interpreted as "0" for the major and
"N" for the minor version of the library.</t>

	please let me know if that is not enough. If comparison is still 
needed, additional information on comparison ladder from RFC 3986 should 
be enough since no other attribute values are special and the section in 
RFC 3986 covers it.

	regards, Jan

---

From: Larry Masinter <[email-masked]>
Date: Mon, 18 Feb 2013 09:29:28 -0800

> when we don't expect people to do it?

I don't think looking at other registrations and doing the minimum is not a good guideline.

a) is it easy to say something about comparison? 
b) is it useful?

with mailto: it would be useful, but I imagine it's difficult.
with tn3270:, it isn't very useful

in this case, it seems like there's some expectation that you WILL compare the URIs, so it would be useful to say.

And the design should make it easy.

Larry

---

From: Ted Hardie <[email-masked]>
Date: Tue, 19 Feb 2013 11:32:49 -0800

> PKCS#11 URI might be used so it may be worth to specify that.

I think the safest thing to do is to specify a conservative comparison at the
URI registration level (like bit-for-bit equality) but note that
applications consuming
them will likely use different comparison algorithms once the values have
been pulled from the URI for use.

Just a personal opinion, though; I'm not sure that there is a single
right answer here.

regards,

Ted

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 20 Feb 2013 21:35:17 -0800 (PST)

On Mon, 18 Feb 2013, Larry Masinter wrote:

>in this case, it seems like there's some expectation that you WILL 
>compare the URIs, so it would be useful to say.
>

	hello Larry, after I tried to put together the rules I agree it 
will be useful. I suggest to add the following section to the draft:

3.4.  PKCS#11 URI Comparison

   Comparison of two URIs is a way of determining whether the URIs are
   equivalent without comparing the actual resource the URIs point to.
   The comparison of URIs aims to minimize false negatives while
   strictly avoiding false positives.

   Two PKCS#11 URIs are said to be equal if URIs as character strings
   are identical as specified in Section 6.2.1 of [RFC3986], or if both
   following rules are fulfilled:

   o  set of attributes present in the URI is equal.  Note that the
      ordering of attributes in the URI string is not significant for
      the mechanism of comparison.

   o  values of respective attributes are equal based on rules specified
      below

   The rules for comparing values of respective attributes are:

   o  values of attributes "token", "manufacturer", "serial", "model",
      "library-manufacturer", "library-description", "object", and
      "object-type" must be compared using simple string comparison
      (Section 6.2.1 of [RFC3986]) after the case and the percent-
      encoding normalization are both applied as specified in Section
      6.2.2 of [RFC3986]

   o  value of attribute "id" must be compared using simple string
      comparison after all bytes are percent-encoded using uppercase
      letters for digits A-F

   o  value for attribute "pin-source", if deemed containing the
      filename with the PIN value, must be compared using the simple
      string comparison after the full syntax based normalization as
      specified in Section 6.2.2 of [RFC3986] is applied.  If value of
      the "pin-source" attribute is believed to be overloaded it is
      recommended to perform case and percent-encoding normalization
      before the values are compared but the exact mechanism of
      comparison is left to the application.

   o  value of attribute "library-version" must be processed as a
      specific scheme-based normalization permitted by Section 6.2.3 of
      [RFC3986].  Each value must be split into a major and minor
      version with character "." (dot) serving as a delimiter.  Library
      version "M" must be treated as "M" for the major version and "0"
      for the minor version.  Library version ".N" must be treated as
      "0" for the major version and "N" for the minor version.
      Resulting minor and major version numbers must be then separately
      compared numerically.

	regards, Jan

---

From: Jan Pechanec <[email-masked]>
Date: Wed, 20 Feb 2013 21:50:51 -0800 (PST)

>Just a personal opinion, though; I'm not sure that there is a single

	hi Ted, I think that in this case the simple string comparison 
would probably not work great since multiple attributes will be commonly 
used in URI instances and different ordering would result in many false 
negatives.

	I've just replied to Larry's email and I included a suggested 
new section which provides a set of quite strict rules as an alternative 
to the simple comparison. I understand that applications may always use 
different algorithms so I'm convinced now that giving easy to follow 
rules may decrease the number of ad-hoc algorithms that would be 
otherwise used.

	thanks a lot for the feedback, Jan