Subject: [saag] nitpicks about draft-pechanec-pkcs11uri-14.txt

From: Petr Spacek <[email-masked]>
Date: Fri, 25 Jul 2014 15:24:19 +0200

Hello,

I'm implementing draft-pechanec-pkcs11uri-14 for FreeIPA project and during 
that work I have found two nits on draft-pechanec-pkcs11uri-14:

On http://tools.ietf.org/html/draft-pechanec-pkcs11uri-14#page-6:

I would propose to split/reformulate the paragraph starting with:
"The path component attribute "token" represents a token label and corresponds 
to the "label" member of the CK_TOKEN_INFO structure" ...

The first sentence (enumeration) spans over 15 lines and I personally find it 
difficult to read. Maybe a table would be better:
"
    The path component attributes and their mapping to PKCS#11 data structures:
    ---------------------|---------------------------------------------------
    token                | "label" member of the CK_TOKEN_INFO structure
    manufacturer         | "manufacturerID" member of CK_TOKEN_INFO structure
    serial               | "serialNumber" member of CK_TOKEN_INFO structure
    model                | "model" member of CK_TOKEN_INFO structure
    library-manufacturer | "manufacturerID" member of the CK_INFO structure
    library-description  | "libraryDescription" member of CK_INFO structure
    library-version      | "libraryVersion" member of CK_INFO structure
    object               | "CKA_LABEL" object attribute
    type                 | "CKA_CLASS" object attribute
    id                   | "CKA_ID" object attribute
    ---------------------|---------------------------------------------------

    The query component attributes:
    ------------|------------------------------------------------------------
    pin-source  | Specifies where the application or library
                | should find the normal user's token PIN.
    pin-value   | Provides the normal user's PIN value directly, if needed.
    module-name | Modifies default settings for accessing PKCS#11 providers.
    module-path | modifies default settings for accessing PKCS#11 providers.
    ------------|------------------------------------------------------------
    For the definition of a "normal user", see [pkcs11_spec].
"

The other nit is more rhetorical question: "Why CKA_LABEL is represented by 
string 'object'?" I find it a bit confusing... However I understand that it 
might be too late for this change.

Have a nice day!

Petr Spacek  @  Red Hat

On 21.7.2014 19:56, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>          Title           : The PKCS#11 URI Scheme
>          Authors         : Jan Pechanec
>                            Darren J. Moffat
> 	Filename        : draft-pechanec-pkcs11uri-14.txt
> 	Pages           : 15
> 	Date            : 2014-07-21
>
> Abstract:
>     This memo specifies a PKCS#11 Uniform Resource Identifier (URI)
>     Scheme for identifying PKCS#11 objects stored in PKCS#11 tokens, for
>     identifying PKCS#11 tokens themselves, or for identifying PKCS#11
>     libraries.  The URI is based on how PKCS#11 objects, tokens, and
>     libraries are identified in the PKCS#11 Cryptographic Token Interface
>     Standard.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-pechanec-pkcs11uri/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-pechanec-pkcs11uri-14
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-pechanec-pkcs11uri-14
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/

---

From: Jan Pechanec <[email-masked]>
Date: Fri, 25 Jul 2014 12:51:56 -0700 (PDT)

> Hello,

	hi Petr,

> difficult to read. Maybe a table would be better:
<...>

	thanks for the feedback, it's much appreciated.  I will see what 
I can do about this one.

> might be too late for this change.

	we assume that most users might know close to nothing about the 
actual specification and how the URI attributes map to it, and that the 
"object" attribute name might be easier for them to use to identify the 
storage object in the token.  We also use "type" for CKA_CLASS instead 
of "class" since we assume that users mostly think about types of 
objects instead of classes.

	there is another label we use, from the CK_TOKEN_INFO structure, 
and again we call it "token" instead of "token-label" or something else.  
We were making a necessary compromise between how precisely are the URI 
attribute names mapped to the names in the spec and the ease of use of 
the URI scheme.

	regards, Jan.

-- 
Jan Pechanec <[email-masked]>