Re: slot attributes & last call
Nico Williams <nico@cryptonector.com> Wed, 17 December 2014 23:01 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 6CDD71A0024; Wed, 17 Dec 2014 15:01:57 -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 8_vL0NjMoGTZ; Wed, 17 Dec 2014 15:01:56 -0800 (PST)
Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 226081A000A; Wed, 17 Dec 2014 15:01:56 -0800 (PST)
Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id ED97D59805F; Wed, 17 Dec 2014 15:01:55 -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=o9YjJT8r372+fN 96MO0wkerhzac=; b=riRisKBavlDni7tp36gIq/sBUVdfl7ss/IOp3NLVSFoszm Wo3udC7dCbSOg64rXFNZ9EV4GCDmNEXQq6PNRe4/ye1CCiTQ8N1tVVCaJsSaLhmR uX+iaxKevcqD4z4qIQGchTgHPki6vaIeRua8eCg0Lr/xkSQ6SzdQHuHkfmB1s=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPA id 514B1598057; Wed, 17 Dec 2014 15:01:55 -0800 (PST)
Date: Wed, 17 Dec 2014 17:01:54 -0600
From: Nico Williams <nico@cryptonector.com>
To: Jaroslav Imrich <jaroslav.imrich@gmail.com>
Subject: Re: slot attributes & last call
Message-ID: <20141217230150.GB9443@localhost>
References: <alpine.GSO.2.00.1412161359100.4549@keflavik> <CAB6OCMvGxT99cGGBSBbz=XU2+F1xRzBa97z6dY-qPSJk1GWXyQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAB6OCMvGxT99cGGBSBbz=XU2+F1xRzBa97z6dY-qPSJk1GWXyQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/RgWEqzu1_U5fKodrKSIHVkwXpIM
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:01:57 -0000
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. > 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. I think the descriptions of these slot-specific attributes should be very explicit about their general unreliability, and they should explain when they can be useful. > > given that we already have attrs like "library-manufacturer" > > it may seem weird to have "token", "manufacturer", "model", and > > "serial" instead of "token-label", "token-manufacturer", > > "token-model", and "token-serial". However, we also have "object" and > > "type" instead of "object-label" and "object-type" and I think it's > > good to keep PKCS#11 URIs short and succinct. In other words, I plan > > to add the slot attributes above without changing other names. > > Please let me know if you see any issues with it. > > I'll share my latest experience with you. Few days ago I was writing simple > encryption application and I have decided to use PKCS#11 URIs to identify > encryption keys. Then I came to the point where I needed to write down URI > into the config file and I was stuck. I couldn't remember attribute names > even though in past I have implemented .NET library for PKCS#11 URI parsing > and building. Attributes like "token", "type" or "object" seem just > unnatural to me. I don't know maybe it is because I work with PKCS#11 at > programming level but I would never refer to the value of "CKA_LABEL" > attribute with other name than "label". However PKCS#11 URI uses "object" > attribute for object label. Maybe regular non-developer users find current > names suitable and easier to understand/remember but in my ideal world I > would change the attribute names to: Well, it's a bit late for this sort of change, as there are existing implementations, and the change is superficial. Otherwise I'd agree with you. > library-description > library-manufacturer > library-version > slot-description > slot-manufacturer > token-manufacturer instead of "manufacturer" > token-model instead of "model" > token-serial instead of "serial" > token-label instead of "token" > object-class instead of "type" > object-label instead of "object" > object-id instead of "id" > > I believe these names would be more appropriate for people who are already > familiar with PKCS#11 and the others would have to learn them anyway. But I > understand it may be too late for such a big change as there are already > widely used implementations of current I-D. Yes. Nico --
- Re: slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Nico Williams
- Re: slot attributes & last call Nico Williams
- Re: slot attributes & last call Nico Williams
- Re: slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Nikos Mavrogiannopoulos
- Re: [saag] PKCS#11 URI slot attributes & last call Stephen Farrell
- Re: slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: slot attributes & last call Darren J Moffat
- Re: PKCS#11 URI slot attributes & last call Darren J Moffat
- Re: slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: slot attributes & last call Jaroslav Imrich
- Re: slot attributes & last call Jaroslav Imrich
- Re: slot attributes & last call Nikos Mavrogiannopoulos
- Re: slot attributes & last call Jan Pechanec
- Re: [saag] PKCS#11 URI slot attributes & last call Henry B (Hank) Hotz, CISSP
- Re: [saag] PKCS#11 URI slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Nico Williams
- Re: [saag] PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Nico Williams
- Re: [saag] PKCS#11 URI slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Patrik Fältström
- Re: PKCS#11 URI slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Patrik Fältström
- NF* (Re: PKCS#11 URI slot attributes & last call) Nico Williams
- Re: NF* (Re: PKCS#11 URI slot attributes & last c… Patrik Fältström
- Re: NF* (Re: PKCS#11 URI slot attributes & last c… Nico Williams
- Re: NF* (Re: PKCS#11 URI slot attributes & last c… Patrik Fältström
- Re: NF* (Re: PKCS#11 URI slot attributes & last c… Nico Williams
- i18n requirements (was: Re: NF* (Re: PKCS#11 URI … John C Klensin
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Nico Williams
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: [saag] PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: [saag] PKCS#11 URI slot attributes & last call Nico Williams
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: [saag] PKCS#11 URI slot attributes & last call Jan Pechanec
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Nico Williams
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Patrik Fältström
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … John C Klensin
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Patrik Fältström
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Nico Williams
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Jan Pechanec
- Re: NF* (Re: PKCS#11 URI slot attributes & last c… Jan Pechanec
- Re: NF* (Re: PKCS#11 URI slot attributes & last c… Nico Williams
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Jan Pechanec
- Re: [saag] i18n requirements (was: Re: NF* (Re: P… Jan Pechanec
- RE: [saag] i18n requirements (was: Re: NF* (Re: P… Christian Huitema
- RE: [saag] i18n requirements (was: Re: NF* (Re: P… Jan Pechanec
- Re: [saag] i18n requirements (was: Re: NF* (Re: P… Jaroslav Imrich
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Jan Pechanec
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … Jan Pechanec
- Re: i18n requirements (was: Re: NF* (Re: PKCS#11 … John C Klensin
- My IESG Eval for draft-pechanec-pkcs11uri-19 (Was… Pete Resnick
- Re: My IESG Eval for draft-pechanec-pkcs11uri-19 … John C Klensin