Re: slot attributes & last call

Nico Williams <nico@cryptonector.com> Thu, 18 December 2014 00:07 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 7E91D1A0045; Wed, 17 Dec 2014 16:07:44 -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 0XUxh00HAKEx; Wed, 17 Dec 2014 16:07:43 -0800 (PST)
Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AFDB81A0041; Wed, 17 Dec 2014 16:07:43 -0800 (PST)
Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 6C5963B805B; Wed, 17 Dec 2014 16:07:43 -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=c3jfm8YiIT5Mjp +N6gH0a94mFu4=; b=UeoKRYZ7cuKCu0BQMtc7tCA+1huRkZjGLlk8gTJfTla4ls 7X8jX1pOQuQXO2iIdvw+BmkBaawSDwq7hrdi3GMAGO0NQtYgVvYhvqu2/B669XF2 ZKlQHcnd5nDeBNZO3WTn65gNCfp70LuSMkfyzX/j+nyqOxvmNbRJFgejgywhE=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id C607D3B8059; Wed, 17 Dec 2014 16:07:42 -0800 (PST)
Date: Wed, 17 Dec 2014 18:07:42 -0600
From: Nico Williams <nico@cryptonector.com>
To: Jaroslav Imrich <jaroslav.imrich@gmail.com>
Subject: Re: slot attributes & last call
Message-ID: <20141218000736.GL9443@localhost>
References: <alpine.GSO.2.00.1412161359100.4549@keflavik> <CAB6OCMvGxT99cGGBSBbz=XU2+F1xRzBa97z6dY-qPSJk1GWXyQ@mail.gmail.com> <20141217230150.GB9443@localhost> <CAB6OCMvkPSfNYqftAgbcN5KrG7kxb5ooico205O6EffcsU8SwQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAB6OCMvkPSfNYqftAgbcN5KrG7kxb5ooico205O6EffcsU8SwQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/j1-_61wmwi_Ohmnb_m_CZlmH5l0
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, Stef Walter <stef@thewalter.net>, ietf@ietf.org, saag@ietf.org, Jan Pechanec <Jan.Pechanec@oracle.com>, 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: Thu, 18 Dec 2014 00:07:44 -0000

On Thu, Dec 18, 2014 at 12:57:16AM +0100, Jaroslav Imrich wrote:
> On Thu, Dec 18, 2014 at 12:01 AM, Nico Williams <nico@cryptonector.com>
> wrote:
> > If the provider includes access to slots/token types like: software
> > tokens, TPMs, and removable user tokens, and if any of the tokens
> > require login even to be able to list public objects[*], then picking a
> > slot and token carefully becomes critical to providing a user-friendly
> > experience, and even to avoiding accidental token lockout (which would
> > be really user-unfriendly).
> >
> > [*] I know, that would be rather surprising behavior, but there's at
> >     least one such non-removable token in use, as I recall.
> 
> OK but I still don't understand the role of slot-id attribute here. Could
> you please be more specific about the use case?
> 
> Are you trying to say there exists PKCS#11 implementation that always
> presents i.e. TPM as slot 0, OS wide software token as slot 1 and whatever
> removable token you can connect as slot 2? And that you need to access that

Yes.

> removable token and you cannot use slot-description, slot-manufacturer and
> neither of token attributes? So the only option left is: pkcs11:slot-id=2
> ???

I think so.  This is really for Jan to answer.  Maybe the Solaris
libpkcs11 should just ensure a meaningful (stable and distinct) slot
label.  If that could be done then slot-id could be excluded here.

Jan?

> > I agree that slot IDs are not reliable in general.  But specific
> > PKCS#11 provider libraries can arrange for them to be reliable.
> 
> Well exactly the same thing can be said about object IDs (i.e. signature
> key is always presented with objectId 1, encryption key with objectId 2)
> and yet they are not present in the I-D.

Yes, and it should be said (or object ID attribute not included).

Nico
--