Re: [saag] PKCS#11 URI slot attributes & last call
Jan Pechanec <jan.pechanec@oracle.com> Tue, 30 December 2014 23:07 UTC
Return-Path: <jan.pechanec@oracle.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 2DB061A899F; Tue, 30 Dec 2014 15:07:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 7bFVyQiF6znr; Tue, 30 Dec 2014 15:07:27 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7D21A899C; Tue, 30 Dec 2014 15:07:27 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sBUN7J9d002364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Dec 2014 23:07:20 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sBUN7IoM026269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Dec 2014 23:07:19 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id sBUN7HEh017519; Tue, 30 Dec 2014 23:07:18 GMT
Received: from keflavik.us.oracle.com (/10.132.148.214) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 30 Dec 2014 15:07:17 -0800
Date: Tue, 30 Dec 2014 15:07:15 -0800
From: Jan Pechanec <jan.pechanec@oracle.com>
X-X-Sender: jpechane@keflavik
To: Nico Williams <nico@cryptonector.com>
Subject: Re: [saag] PKCS#11 URI slot attributes & last call
In-Reply-To: <20141230081415.GH24442@localhost>
Message-ID: <alpine.GSO.2.00.1412301453260.4549@keflavik>
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> <20141230081415.GH24442@localhost>
User-Agent: Alpine 2.00 (GSO 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/KSo6WfUxt3fbZsDQkd-3gO1JohA
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 23:07:29 -0000
On Tue, 30 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. yes, and I think it will be important to state in the text that the choice of exact set of attributes is context specific. >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. I'd say it does not matter much whether it's the same application which is gonna use the generated URI or not, it's all about the context - if it's enough or not. >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 like the use of the templates. I just quickly read through the RFC. It looks that, for example, when generating a key pair, the application could support a default template with empty variables which would be used to optionally list a URI based on the CK_OBJECT_HANDLE of the generated key pair. And it could accept a different one to override the default. As mentioned above, I'd like to explicitly express that URI list is context specific. I slightly modified the paragraph above: When listing URIs of PKCS#11 resources the exact set of attributes used in a URI is inherently context specific. A PKCS#11 URI template [RFC6570] support MAY be provided by a URI generating application to list URIs to access the same resource(s) again if the template captured the necessary context. I think we wouldn't need to say more about the matter. thank you, J. >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 > -- Jan Pechanec <jan.pechanec@oracle.com>
- 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