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

Jan Pechanec <jan.pechanec@oracle.com> Tue, 30 December 2014 07:13 UTC

Return-Path: <jan.pechanec@oracle.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B2D1A8F40; Mon, 29 Dec 2014 23:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.31
X-Spam-Level:
X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08ZsXAzi17Ph; Mon, 29 Dec 2014 23:13:37 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB4F1A901D; Mon, 29 Dec 2014 23:13:37 -0800 (PST)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sBU7DOdT025059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Dec 2014 07:13:24 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sBU7DLBK004709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 30 Dec 2014 07:13:21 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sBU7DKw3007759; Tue, 30 Dec 2014 07:13:20 GMT
Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 29 Dec 2014 23:13:20 -0800
Date: Mon, 29 Dec 2014 23:13:18 -0800 (PST)
From: Jan Pechanec <jan.pechanec@oracle.com>
X-X-Sender: jpechane@keflavik
To: Nico Williams <nico@cryptonector.com>
Subject: Re: [saag] PKCS#11 URI slot attributes & last call
In-Reply-To: <alpine.GSO.2.00.1412192326150.22104@keflavik>
Message-ID: <alpine.GSO.2.00.1412292240250.1509@keflavik>
References: <20141218000736.GL9443@localhost> <alpine.GSO.2.00.1412171614240.4549@keflavik> <CAB6OCMsAdTarz5XBHgTnU=v9qweS5B6mk-tb7Gbf7kwkDFBDMg@mail.gmail.com> <20141218004717.GN9443@localhost> <alpine.GSO.2.00.1412171704530.4549@keflavik> <20141218012300.GP9443@localhost> <alpine.GSO.2.00.1412172154150.14405@rejewski> <1418900792.7577.5.camel@gnutls.org> <5492B941.3030408@Oracle.COM> <30738721-F5A2-4485-84AC-573AD9113699@oxy.edu> <20141220000456.GC12662@localhost> <alpine.GSO.2.00.1412192326150.22104@keflavik>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-620685175-1419923600=:1509"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/kKe-4rtOduDGNIt2cjDAiAHT61I
X-Mailman-Approved-At: Wed, 31 Dec 2014 21:32:39 -0800
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, Stef Walter <stef@thewalter.net>, Jaroslav Imrich <jaroslav.imrich@gmail.com>, ietf@ietf.org, Shawn Emery <shawn.emery@oracle.com>, saag@ietf.org, "Henry B \(Hank\) Hotz, CISSP" <hbhotz@oxy.edu>, Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Dec 2014 07:13:45 -0000

On Fri, 19 Dec 2014, Jan Pechanec wrote:

>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
>>flexible.
>>
>>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
>>not.
>>
>>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.

	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.

	similarly with a token.  To uniquely identify a token (either 
to refence it by itself or because I have objects of the same name in 
multiple tokens), manufacturer and serial number should be used but 
again, I'd rather use the token (name) attribute unless I have 
multiple tokens of the same name.  What is more, if the token is not 
guaranteed unique then I may need library attributes (say for soft 
tokens in multiple libraries).  And even that may not be sufficient if 
I link to the same libraries from different file paths in which case 
the module attributes may be needed.  Again, I'd want to use all these 
attributes only when such a situation arises.

	if the consensus is that I should provide a paragraph that 
would summarize ideally in a more succint way what I've been saying 
above (or whether I should do something else) I will try to come up 
with a reasonable text but at this point I still don't think it is 
necessary.

	thank you, Jan.

-- 
Jan Pechanec <jan.pechanec@oracle.com>