The PKCS #11 URI Scheme
draft-pechanec-pkcs11uri-21
Yes
(Stephen Farrell)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Ted Lemon)
Note: This ballot was opened for revision 19 and is now closed.
Richard Barnes Former IESG member
(was Discuss)
Yes
Yes
(2015-02-04 for -20)
Unknown
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 IESG member
Yes
Yes
(for -19)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -19)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -19)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2015-01-26 for -19)
Unknown
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 IESG member
No Objection
No Objection
(for -19)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -19)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -19)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -19)
Unknown
Kathleen Moriarty Former IESG member
(was Discuss)
No Objection
No Objection
(2015-02-04 for -19)
Unknown
Thanks for answering my questions on the PKCS#11 reference.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -19)
Unknown
Pete Resnick Former IESG member
(was Discuss)
No Objection
No Objection
(2015-02-10 for -20)
Unknown
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 IESG member
No Objection
No Objection
(for -19)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(for -19)
Unknown