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

Nico Williams <nico@cryptonector.com> Tue, 30 December 2014 08:14 UTC

Return-Path: <nico@cryptonector.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 373D11ACEE7; Tue, 30 Dec 2014 00:14:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.234
X-Spam-Level:
X-Spam-Status: No, score=0.234 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 DZXEgEjiqiWa; Tue, 30 Dec 2014 00:14:22 -0800 (PST)
Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 836961ACDC3; Tue, 30 Dec 2014 00:14:22 -0800 (PST)
Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 5D91220058D84; Tue, 30 Dec 2014 00:14:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=8uFjCmVwgBI/te 4T+YS+9GflRF4=; b=ytHrg6L16aEjaE7Z8J7MSQq/8hKkIp3FT33Nk1O2YaHOht KvjNGMrcYYMsybhiTRPkLZnFtEvuhKBvP397xUe7DgBrgVmJeLsXzvVsD4ZIszzZ ZA5jrVThANd+3fn5BCqpw3zRaBdN9JwMh1LAZ4AgOpSLcMM2Eo4L0y0E1kkXE=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id 942F720058D83; Tue, 30 Dec 2014 00:14:21 -0800 (PST)
Date: Tue, 30 Dec 2014 02:14:21 -0600
From: Nico Williams <nico@cryptonector.com>
To: Jan Pechanec <jan.pechanec@oracle.com>
Subject: Re: [saag] PKCS#11 URI slot attributes & last call
Message-ID: <20141230081415.GH24442@localhost>
References: <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> <alpine.GSO.2.00.1412292240250.1509@keflavik>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.GSO.2.00.1412292240250.1509@keflavik>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/ibumjpmvSKCF9BAiRA8Z7z72QW0
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 08:14:23 -0000

On Mon, Dec 29, 2014 at 11:13:18PM -0800, Jan Pechanec wrote:
> On Fri, 19 Dec 2014, Jan Pechanec wrote:
> >On Fri, 19 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.

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.

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 don't think we could say much more without gaining experience with
deployment.

Caveat emptor: I'm not too conversant with URI templating, so I don't
know how to phrase this correctly...

Nico
--