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

Nico Williams <nico@cryptonector.com> Sat, 20 December 2014 00:05 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 5B61B1A90E5; Fri, 19 Dec 2014 16:05:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xRzANN6ERQN3; Fri, 19 Dec 2014 16:05:19 -0800 (PST)
Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDB81A8A3B; Fri, 19 Dec 2014 16:05:01 -0800 (PST)
Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id D0BAE20047B83; Fri, 19 Dec 2014 16:05:00 -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:content-transfer-encoding; s= cryptonector.com; bh=wTjkOASKjyxqRW1QnCdTn+XRKhw=; b=IyfaC24Gs0P FUMN+Xu1bBZ1rYF81gGDOK95shnvNrXfLEGueEK677N+KOOCRFOdAbzYfJwMAltu NgmoOGfThx1r5HNc2PSUZxJyRE3DnLAORBbUUFTx26s0ifZIoLoH42/nmcMaI2xF aRUvEhHYL3okoWi6mwc9FYDhANUuL5M4=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id 4EBB920047B82; Fri, 19 Dec 2014 16:05:00 -0800 (PST)
Date: Fri, 19 Dec 2014 18:04:59 -0600
From: Nico Williams <nico@cryptonector.com>
To: "Henry B (Hank) Hotz, CISSP" <hbhotz@oxy.edu>
Subject: Re: [saag] PKCS#11 URI slot attributes & last call
Message-ID: <20141220000456.GC12662@localhost>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <30738721-F5A2-4485-84AC-573AD9113699@oxy.edu>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/NVRwZys1YXGdoV1Ca4lOnzO4wN0
Cc: Darren J Moffat <Darren.Moffat@Oracle.COM>, Stef Walter <stef@thewalter.net>, ietf@ietf.org, Jan Pechanec <jan.pechanec@Oracle.COM>, saag@ietf.org
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: Sat, 20 Dec 2014 00:05:20 -0000

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.

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

Nico
--