Re: PKCS#11 URI slot attributes & last call

Jan Pechanec <> Wed, 17 December 2014 23:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 572881A000F; Wed, 17 Dec 2014 15:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ExU7SRPK1USl; Wed, 17 Dec 2014 15:34:24 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8400C1A000D; Wed, 17 Dec 2014 15:34:24 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sBHNYLAh029461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Dec 2014 23:34:22 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id sBHNYKl3021194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 Dec 2014 23:34:21 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id sBHNYKED021183; Wed, 17 Dec 2014 23:34:20 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Dec 2014 15:34:20 -0800
Date: Wed, 17 Dec 2014 15:34:19 -0800 (PST)
From: Jan Pechanec <>
X-X-Sender: jpechane@keflavik
To: Jaroslav Imrich <>
Subject: Re: PKCS#11 URI slot attributes & last call
In-Reply-To: <>
Message-ID: <alpine.GSO.2.00.1412171517460.4549@keflavik>
References: <alpine.GSO.2.00.1412161359100.4549@keflavik> <>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Source-IP: []
X-Mailman-Approved-At: Thu, 18 Dec 2014 08:24:58 -0800
Cc: Darren J Moffat <>, Stef Walter <>,,, Nikos Mavrogiannopoulos <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Dec 2014 23:34:29 -0000

On Wed, 17 Dec 2014, Jaroslav Imrich wrote:

>>         given that we already have attrs like "library-manufacturer"
>> it may seem weird to have "token", "manufacturer", "model", and
>> "serial" instead of "token-label", "token-manufacturer",
>> "token-model", and "token-serial".  However, we also have "object" and
>> "type" instead of "object-label" and "object-type" and I think it's
>> good to keep PKCS#11 URIs short and succinct.  In other words, I plan
>> to add the slot attributes above without changing other names.
>> Please let me know if you see any issues with it.
>I'll share my latest experience with you. Few days ago I was writing simple
>encryption application and I have decided to use PKCS#11 URIs to identify
>encryption keys. Then I came to the point where I needed to write down URI
>into the config file and I was stuck. I couldn't remember attribute names
>even though in past I have implemented .NET library for PKCS#11 URI parsing
>and building. Attributes like "token", "type" or "object" seem just
>unnatural to me. I don't know maybe it is because I work with PKCS#11 at
>programming level but I would never refer to the value of "CKA_LABEL"
>attribute with other name than "label". However PKCS#11 URI uses "object"
>attribute for object label. Maybe regular non-developer users find current
>names suitable and easier to understand/remember but in my ideal world I
>would change the attribute names to:

	Jaroslav, I think that most of the users of the URI may be 
quite ignorant about the PKCS#11 spec.  I don't think they will know 
about CKA_LABEL attribute, for example.  The thing was to come up with 
some "compromise between how precisely are the URI attribute names 
mapped to the names in the specification and the ease of use and 
understanding of the URI scheme", as stated in the ID.  I think it's 
much easier to use and read:


	rather than:


	where the use of "label" looks quite redundant.  Please note 
that it's about general usability and ease of use of the URI, not how 
precisely it is mapped to the actual spec.

	that why we also chose "type" over less understandable "class" 
which is btw also used in the spec in text:

	"CK_OBJECT_CLASS is a value that identifies the classes (or 
types) of objects that Cryptoki recognizes."


Jan Pechanec <>