The PKCS #11 URI Scheme
draft-pechanec-pkcs11uri-21

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

(Richard Barnes; former steering group member) (was Discuss) Yes

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; former steering group member) Yes

(Adrian Farrel; former steering group member) No Objection

(Alia Atlas; former steering group member) No Objection

(Barry Leiba; former steering group member) No Objection

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?

(Benoît Claise; former steering group member) No Objection

(Brian Haberman; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

(Joel Jaeggli; former steering group member) No Objection

(Kathleen Moriarty; former steering group member) (was Discuss) No Objection

Thanks for answering my questions on the PKCS#11 reference.

(Martin Stiemerling; former steering group member) No Objection

(Pete Resnick; former steering group member) (was Discuss) No Objection

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.

(Spencer Dawkins; former steering group member) No Objection

(Ted Lemon; former steering group member) No Objection