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

Jan Pechanec <> Sat, 20 December 2014 07:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 564191A1A59; Fri, 19 Dec 2014 23:30:32 -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 XZe3JekpeFuw; Fri, 19 Dec 2014 23:30:31 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 168A11A004D; Fri, 19 Dec 2014 23:30:31 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sBK7UP44019245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Dec 2014 07:30:28 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id sBK7UNQn029218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 20 Dec 2014 07:30:24 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id sBK7UNtM021842; Sat, 20 Dec 2014 07:30:23 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Dec 2014 23:30:23 -0800
Date: Fri, 19 Dec 2014 23:30:21 -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: <20141220000456.GC12662@localhost>
Message-ID: <alpine.GSO.2.00.1412192326150.22104@keflavik>
References: <20141218000736.GL9443@localhost> <alpine.GSO.2.00.1412171614240.4549@keflavik> <> <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>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1215378052-1419060623=:22104"
X-Source-IP: []
X-Mailman-Approved-At: Mon, 22 Dec 2014 07:59:55 -0800
Cc: Darren J Moffat <>, "Henry B \(Hank\) Hotz, CISSP" <>,,, Stef Walter <>
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: Sat, 20 Dec 2014 07:30:32 -0000

On Fri, 19 Dec 2014, Nico Williams wrote:

>On Fri, Dec 19, 2014 at 03:19:00PM -0800, Henry B (Hank) Hotz, CISSP wrote:
>> Does this ID, in fact, define an API which is sufficient to support
>> realistic, interoperable code across a significant range of libraries
>> and platforms? Is there a unique way to reference the authentication
>> credential on my guaranteed-unique government-issued smart card
>> regardless of which reader on which platform it’s plugged into?
>Excellent questions.
>As to the first: it's a rather abstract API.  I'm a bit concerned about
>some of the semantics, that we might need to make matching a bit more
>IIRC there's a token that requires a login even to see public objects.
>I might want to have a way to say "match public objects that don't
>require login".
>Or, I might want to provide slot/token attributes as hints, but not as
>required attributes, that match preferentially but which are ignored if
>Abstract operations that I think should be described:
> - given a PKCS#11 URI, return a PKCS#11 provider (e.g., a handle
>   returned by dlopen()/LoadLibrary*(), or a v-table, or whatever is
>   appropriate in the caller's given programming language);
>   This is described, actually.
> - given a PKCS#11 URI (and, optionally, a PKCS#11 provider) return a
>   PKCS#11 provider and relevant PKCS#11 handles (token, session,
>   object);
>   This is also described.
> - given a PKCS#11 URI return a list of URIs for all matching tokens
>   and/or objects;
>   This is not described.
>   E.g., given "pkcs11:" output a list of all {provider, slot},
>   {provider, slot, token}, {provider, slot, token, public object} URIs
>   for actual slots, tokens, public objects.
>   E.g., given "pkcs11:" and a PKCS#11 session return all {provider,
>   slot, token, object} URIs for actual objects reachable via that
>   session.
> - given a PKCS#11 provider and handle of some sort, return a URI for
>   it, with an option to include or exclude slot/token matching
>   attributes.
>   This is also not described, IIRC.

	so, as well as we have "PKCS#11 URI Matching Guidelines" 
section, we might need "PKCS#11 URI Generation Guidelines" to discuss 
these things about "reverse mapping".  I will take a look at it.


>> Since I did not involve myself in the process, I do not know if those
>> goals were excluded for some legitimate reason, but the discussion
>> preceding makes it sound like they were not met.
>They weren't.  And the I-D covers semantics in such a way that it
>defines an abstract API, but perhaps it needs to be made more explicit.

Jan Pechanec <>