Re: slot attributes & last call

Jaroslav Imrich <jaroslav.imrich@gmail.com> Wed, 17 December 2014 23:57 UTC

Return-Path: <jaroslav.imrich@gmail.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 7A9A21A007A; Wed, 17 Dec 2014 15:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 2oymZ0tPMWXE; Wed, 17 Dec 2014 15:57:17 -0800 (PST)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09FB1A0067; Wed, 17 Dec 2014 15:57:16 -0800 (PST)
Received: by mail-ig0-f174.google.com with SMTP id hn15so9692956igb.13; Wed, 17 Dec 2014 15:57:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PiJ9pRkKg+lq1nkcRL7WCeADmyGhw2fR3mgaX0cVs6Y=; b=c1L/O7S1G6G4T/MI9g2+3xjqiYYczAHVvRILfC/nOMoTNLd89xXUIncmVjOY3ECT12 KxH139xdF5buqu8kzw9jmHjCAEFvaPsiigpvZiwlK6FmEUNg5tRwuyJjN7UKyByuAQB2 jpzVwjFXOhJHNDVDkNp7e5mXqSKKFD4QJgQPi9686k0GIk+5MCzUfIbi+NlhhNOWTE5C jCelU84V0poLapfw5l19IQIBfLI0WjMpJVRQmKHV4G5XVqcWc8bGCsltuUovx0123TvK P1Gj3UMepm0g6dqvo1v/9FMlpd5qfZQ6gl0m2YyJE+XVLBvJf5LQHfFFHxXsY0XBAiz9 CVcw==
MIME-Version: 1.0
X-Received: by 10.107.6.34 with SMTP id 34mr41684342iog.88.1418860636110; Wed, 17 Dec 2014 15:57:16 -0800 (PST)
Received: by 10.50.122.104 with HTTP; Wed, 17 Dec 2014 15:57:16 -0800 (PST)
In-Reply-To: <20141217230150.GB9443@localhost>
References: <alpine.GSO.2.00.1412161359100.4549@keflavik> <CAB6OCMvGxT99cGGBSBbz=XU2+F1xRzBa97z6dY-qPSJk1GWXyQ@mail.gmail.com> <20141217230150.GB9443@localhost>
Date: Thu, 18 Dec 2014 00:57:16 +0100
Message-ID: <CAB6OCMvkPSfNYqftAgbcN5KrG7kxb5ooico205O6EffcsU8SwQ@mail.gmail.com>
Subject: Re: slot attributes & last call
From: Jaroslav Imrich <jaroslav.imrich@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=001a113f9b743389a0050a723c4b
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/3L8i_k_aZeWNB46dZ7t-x_LUET4
X-Mailman-Approved-At: Thu, 18 Dec 2014 08:27:02 -0800
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: Wed, 17 Dec 2014 23:57:19 -0000

On Thu, Dec 18, 2014 at 12:01 AM, Nico Williams <nico@cryptonector.com>
wrote:
>
> On Wed, Dec 17, 2014 at 11:44:57PM +0100, Jaroslav Imrich wrote:
> > I am CC-ing saag@ietf.org mailing list as it seems to be correct public
> > list to discuss I-D for PKCS#11 URIs.
>
> For an I-D in IETF LC that should be ietf@ietf.org.  Cc'ing it (and not
> trimming any quotes).
>
> > On Tue, Dec 16, 2014 at 11:29 PM, Jan Pechanec <Jan.Pechanec@oracle.com>
> > wrote:
> > >         hi all, the draft is in the middle of the last call with
> > > comments to be sent till Dec 29.  There are a few nits to be fixed but
> > > we also got two independent inquiries about adding slot attributes.
> > > One is internal to Solaris, another is from an engineer who would like
> > > to replace some pam_pkcs11 module config attributes with one PKCS#11
> > > URI.  One of the attributes there is "slot_description" and apparently
> > > it's useful and being used there.
> > >
> > >         I think that having slot attributes is useful.
> > >
> > >         obvious choice is this:
> > >
> > > pk11-slot-desc        = "slot-description" "=" *pk11-pchar
> > > pk11-slot-manuf       = "slot-manufacturer" "=" *pk11-pchar
> > > pk11-slot-id          = "slot-id" "=" 1*DIGIT
> > >
> >
> > I don't mind adding "slot-description" and "slot-manufacturer" if someone
> > finds them useful but I can't recommend adding "slot-id". I personally
>
> The cases I've seen where this is useful are ones where the PKCS#11
> provider library provides unified access to multiple types of
> slots/tokens, and the application is trying to obtain user credentials
> from a user's removable token (smartcard).
>
> 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
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
???



> > consider referencing slot/token by its internal slotId to be a very bad
> > habit. Nikos has already mentioned that it is "just a meaningless number,
> > it is not guaranteed to stay the same across reboots or program
> restarts",
> > "its value is implementation-specific" and I fully agree with him. SlotId
> > happens to be unsigned long in cryptoki API but it could also be a handle
> > or pointer without changing its meaning. I believe that
> "slot-description"
> > and "slot-manufacturer" along with other token identifying path
> attributes
> > should cover most use cases. But maybe you know some specific use case
> that
> > explicitly requires "slot-id"? Could you please describe it in more
> detail?
>
> 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.


Regards, Jaroslav