Re: [saag] PKCS#11 URI slot attributes & last call

Jan Pechanec <> Tue, 30 December 2014 23:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2DB061A899F; Tue, 30 Dec 2014 15:07: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 7bFVyQiF6znr; Tue, 30 Dec 2014 15:07:27 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F7D21A899C; Tue, 30 Dec 2014 15:07:27 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sBUN7J9d002364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Dec 2014 23:07:20 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id sBUN7IoM026269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2014 23:07:19 GMT
Received: from ( []) by (8.14.5+Sun/8.14.4) with ESMTP id sBUN7HEh017519; Tue, 30 Dec 2014 23:07:18 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 30 Dec 2014 15:07:17 -0800
Date: Tue, 30 Dec 2014 15:07:15 -0800 (PST)
From: Jan Pechanec <>
X-X-Sender: jpechane@keflavik
To: Nico Williams <>
Subject: Re: [saag] PKCS#11 URI slot attributes & last call
In-Reply-To: <20141230081415.GH24442@localhost>
Message-ID: <alpine.GSO.2.00.1412301453260.4549@keflavik>
References: <20141218004717.GN9443@localhost> <alpine.GSO.2.00.1412171704530.4549@keflavik> <20141218012300.GP9443@localhost> <alpine.GSO.2.00.1412172154150.14405@rejewski> <> <5492B941.3030408@Oracle.COM> <> <20141220000456.GC12662@localhost> <alpine.GSO.2.00.1412192326150.22104@keflavik> <alpine.GSO.2.00.1412292240250.1509@keflavik> <20141230081415.GH24442@localhost>
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: Wed, 31 Dec 2014 21:32:39 -0800
Cc: Darren J Moffat <>, Stef Walter <>, Jaroslav Imrich <>,, Shawn Emery <>,, "Henry B \(Hank\) Hotz, CISSP" <>, 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: Tue, 30 Dec 2014 23:07:29 -0000

On Tue, 30 Dec 2014, Nico Williams wrote:

>> >> [discussion about an abstract "list PKCS#11 resource URIs"
>> >> operation elided.]
>> 	I've been thinking about this for the past days and I'm not 
>> sure if such guidelines should be provided since it very much depends 
>> on how a URI will be used and in what scenarios.
>> 	for example, if referencing a key pair, an "id" attribute is 
>> there to distinguish multiple public-key/private-key pairs held by the 
>> same subject.  However, I think that if used on a command line to 
>> provide an access to the key pair, it would be used only if there 
>> really were multiple keys of the same name.  And that information I 
>> may acquire only when I try not to use those attributes when I get an 
>> error message about multiple key pairs - which may or may not be 
>> acceptible.  On the other hand, it may be a good idea to use it always 
>> if such a URI would be provided in a long lived configuration file, 
>> for example.
>Which attributes to use for the listing would have to be
>context-specific.  Most apps/users would never want to match on slot
>attributes, but some might.  We can't say much about that.

	yes, and I think it will be important to state in the text 
that the choice of exact set of attributes is context specific.

>Users will mostly not be writing PKCS#11 URIs, that's for sure.  PKCS#11
>is not very user-friendly...
>Where a PKCS#11 URI is used, I suspect it will be produced by an
>application, and then cut-n-pasted around as necessary by the user.
>Do we have to say much about how the app should go about forming a URI
>for a PKCS#11 resource?  It depends.
>If the same app will consume the same URI, then we need not say
>anything.  If a different app will consume the same URI then we might
>have to.  This is about inter-app interoperation.

	I'd say it does not matter much whether it's the same 
application which is gonna use the generated URI or not, it's all 
about the context - if it's enough or not.

>As to how to say anything about this, here's what comes to mind:
>   Given a PKCS#11 URI template [RFC6570], an application MAY support
>   listing URIs of PKCS#11 resources such that the resulting URIs can
>   later be used to access the same resources if the template captured
>   the necessary context.

	I like the use of the templates.  I just quickly read through 
the RFC.  It looks that, for example, when generating a key pair, the 
application could support a default template with empty variables 
which would be used to optionally list a URI based on the 
CK_OBJECT_HANDLE of the generated key pair.  And it could accept a 
different one to override the default.  As mentioned above, I'd like 
to explicitly express that URI list is context specific.  I slightly 
modified the paragraph above:

	When listing URIs of PKCS#11 resources the exact set of 
	attributes used in a URI is inherently context specific.  A 
	PKCS#11 URI template [RFC6570] support MAY be provided by a 
	URI generating application to list URIs to access the same
	resource(s) again if the template captured the necessary

	I think we wouldn't need to say more about the matter.

	thank you, J.

>I don't think we could say much more without gaining experience with
>Caveat emptor: I'm not too conversant with URI templating, so I don't
>know how to phrase this correctly...

Jan Pechanec <>