The PKCS #11 URI Scheme
RFC 7512

Note: This ballot was opened for revision 19 and is now closed.

(Richard Barnes) (was Discuss) Yes

Comment (2015-02-04 for -20)
No email
send info
I appreciate the spirit of this draft, and I think I might actually have an immediate use for it (configuring a CA).  In particular, the text on security of "pin-value" is brief but good.  There are several points, however, where this spec is unnecessarily restrictive or complex. 

Section 3.3: "However, the PKCS#11 URI notation does not impose such limitations..."
It seems like what you're trying to do here is defer to PKCS#11.  I would suggest being a little stronger here, e.g., "The syntax of the PKCS#11 URI does not impose such limitations.  However if the consumer of a URI encounters values that would not be accepted by PKCS#11, it MUST consider the URI invalid."

Section 3.3: "depricated"

Section 3.3: "object ... "CKA_LABEL""
Why not use "label" for the attribute name here?

Section  3.3: "duplicate (vendor) attributes MAY be present"
Please clarify whether attributes defined in this specification MAY be duplicated.  It seems like it could be useful for some of them to be repeated.  For example, module-name / module-path could be used to enable a consumer to search multiple libraries for the desired token / object.

Section 3.4: "If a URI contains both "pin-source" and "pin-value" query attributes the URI SHOULD be refused as invalid."
Why does a URI with both "pin-source" and "pin-value" have to be invalid?  It seems like a consumer could try the provided PIN, and if that's invalid, try to use the PIN from "pin-source".

Section 3.4: "the URI consumer MAY refuse to accept either of the attributes"
Rejecting the URI seems unnecessarily intolerant.  Do you mean that implementations MAY ignore these attributes and fetch the module from elsewhere?  That seems like the more charitable thing to do.

Section 3.4: "a URI MUST NOT contain multiple module attributes of the same name."
As above, this seems unnecessarily strict.

(Stephen Farrell) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2015-01-26 for -19)
No email
send info
In Section 4:

   An empty PKCS#11 URI might be useful to PKCS#11 consumers.  See
   Section 3.5 for more information on semantics of such a URI.

I see nothing in Section 3.5 that gives any information about semantics of the URI "pkcs11:".  Can you quote it, so I can find it?

(Ted Lemon) No Objection

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2015-02-04 for -19)
No email
send info
Thanks for answering my questions on the PKCS#11 reference.

(Pete Resnick) (was Discuss) No Objection

Comment (2015-02-10 for -20)
No email
send info
I think what you have in 3.3 is reasonable, but I think the reader might get lost about which encoding to do. I think you could clarify it a bit by simply repeating the bit about the "id" attribute in both places. Here's my suggestion:

OLD
   The PKCS#11 URI is a sequence of attribute value pairs separated by a
   semicolon that form a one level path component, optionally followed
   by a query.  In accordance with Section 2.5 of [RFC3986], the textual
   data SHOULD first be encoded as octets according to the UTF-8
   character encoding [RFC3629]; then only those octets that do not
   correspond to characters in the unreserved set or to permitted
   characters from the reserved set should be percent-encoded.  The only
   PKCS#11 URI attribute defined in this document which MAY contain non-
   textual data is the "id" attribute, as stated later in this section.
   When working with UTF-8 strings with characters outside the US-ASCII
   character sets, see important caveats in Section 3.5 and Section 6.
NEW
   The PKCS#11 URI is a sequence of attribute value pairs separated by a
   semicolon that form a one level path component, optionally followed
   by a query.  These attribute value pairs and query components (except
   for the value of the "id" attribute defined later in this section)
   are composed of entirely of textual data and therefore SHOULD all
   first be encoded as octets according to the UTF-8 character encoding
   [RFC3629], in accordance with Section 2.5 of [RFC3986]; then only
   those octets that do not correspond to characters in the unreserved
   set or to permitted characters from the reserved set should be
   percent-encoded.  (Because the value of the "id" attribute can
   contain non-textual data, it SHOULD NOT be encoded as UTF-8, but
   instead the entire value of the "id" component SHOULD be
   percent-encoded.) See important caveats in Section 3.5 and Section 6
   regarding working with UTF-8 strings containing characters outside
   the US-ASCII character set.

Then, below:

OLD
   The whole value of the "id" attribute SHOULD be percent-encoded since
   the corresponding PKCS#11 "CKA_ID" object attribute can contain
   arbitrary binary data.
NEW
   As stated earlier in this section, because the value of the "id"
   attribute can contain non-textual data, because the corresponding
   PKCS#11 "CKA_ID" object attribute can contain arbitrary binary data,
   the whole value of the "id" attribute SHOULD be percent-encoded.

It's a bit wordier, but the reader is far less likely to miss it when implementing. Entirely up to you whether to make the change; the specification as you have it is correct. Mine is only (hopefully) a clarification.

Thanks for addressing my other comments.

(Martin Stiemerling) No Objection