Re: [jose] JOSE and PKCS11

"Stefan Berger" <stefanb@us.ibm.com> Wed, 27 February 2019 14:57 UTC

Return-Path: <stefanb@us.ibm.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F200130FCF for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 06:57:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 e-1bKbsRvK4c for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 06:57:29 -0800 (PST)
Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4789C12008A for <jose@ietf.org>; Wed, 27 Feb 2019 06:57:29 -0800 (PST)
Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1REnd66086210 for <jose@ietf.org>; Wed, 27 Feb 2019 09:57:27 -0500
Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.93]) by mx0b-001b2d01.pphosted.com with ESMTP id 2qwuva3b5c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <jose@ietf.org>; Wed, 27 Feb 2019 09:57:27 -0500
Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for <jose@ietf.org> from <stefanb@us.ibm.com>; Wed, 27 Feb 2019 14:57:26 -0000
Received: from us1a3-smtp01.a3.dal06.isc4sb.com (10.106.154.95) by smtp.notes.na.collabserv.com (10.106.227.39) with smtp.notes.na.collabserv.com ESMTP; Wed, 27 Feb 2019 14:57:21 -0000
Received: from us1a3-mail155.a3.dal06.isc4sb.com ([10.146.38.88]) by us1a3-smtp01.a3.dal06.isc4sb.com with ESMTP id 2019022714572073-639756 ; Wed, 27 Feb 2019 14:57:20 +0000
MIME-Version: 1.0
In-Reply-To: <CAOASepNpA8Mcj983ZSnZ7Pi1OZocT=sFap5Me_PtikzELGtJuw@mail.gmail.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Cc: jose@ietf.org, jose <jose-bounces@ietf.org>, Neil Madden <neil.madden@forgerock.com>
From: "Stefan Berger" <stefanb@us.ibm.com>
Date: Wed, 27 Feb 2019 09:57:23 -0500
References: <OF5CBAD5FA.DA05866D-ON00258338.007B994B-00258338.007BD260@notes.na.collabserv.com> <CAOASepMU3waryT=TKpw7sKFw-FT+JE3h-3xWUS7AZQwGgp8X5A@mail.gmail.com> <OF2BF5119B.748538F2-ON002583AD.007FDFBF-852583AD.0081099B@notes.na.collabserv.com> <E824FA9C-1E86-4B6A-909B-4EF7875C9BE9@forgerock.com> <OFB3CFC7BB.B88F2A57-ON002583AE.004D3EAD-852583AE.004E2F43@notes.na.collabserv.com> <48AE6835-F622-43AE-A1EA-23C3546B7DB8@forgerock.com> <CAOASepNpA8Mcj983ZSnZ7Pi1OZocT=sFap5Me_PtikzELGtJuw@mail.gmail.com>
X-KeepSent: 6F824C21:3D0C2D7C-002583AE:0051A3DF; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0.1FP10 SHF68 March 06, 2018
X-LLNOutbound: False
X-Disclaimed: 21119
X-TNEFEvaluated: 1
x-cbid: 19022714-1799-0000-0000-00000A959592
X-IBM-SpamModules-Scores: BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.417846; ST=0; TS=0; UL=0; ISC=; MB=0.019452
X-IBM-SpamModules-Versions: BY=3.00010674; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000281; SDB=6.01167146; UDB=6.00609718; IPR=6.00947756; BA=6.00006243; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00025765; XFM=3.00000015; UTC=2019-02-27 14:57:25
X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused
X-IBM-AV-VERSION: SAVI=2019-02-27 08:55:38 - 6.00009636
x-cbparentid: 19022714-1800-0000-0000-0000FDFAB8DD
Message-Id: <OF6F824C21.3D0C2D7C-ON002583AE.0051A3DF-852583AE.00522873@notes.na.collabserv.com>
Content-type: multipart/alternative; boundary="0__=8FBB093DDFC2254F8f9e8a93df938690918c8FBB093DDFC2254F"
Content-Disposition: inline
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-27_10:, , signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/epuA-44UCbF_FJGVwUJ_YOTo9Dk>
Subject: Re: [jose] JOSE and PKCS11
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 14:57:31 -0000

"jose" <jose-bounces@ietf.org> wrote on 02/27/2019 09:36:13 AM:

>
> On Wed, Feb 27, 2019 at 9:26 AM Neil Madden <neil.madden@forgerock.com>
wrote:
> >
> > On 27 Feb 2019, at 14:13, Stefan Berger <stefanb@us.ibm.com> wrote:
> > >
> > > "jose" <jose-bounces@ietf.org> wrote on 02/27/2019 03:18:51 AM:
> > > >
> > > > I’m not sure I understand yet the issue that is being addressed
with
> > > > this work.
> > > >
> > > > Certainly many JOSE libraries already support HSMs. We have
> > > > customers using HSMs with our JOSE library via PKCS#11. But most of
> > > > our use-cases typically only ever publish public keys as JWKs.
> > > >
> > > > You can already encode an identifier for a local private key using
> > > > the key id (kid) header, so it’s not clear to me why you would need
> > > > anything else if no actual key material is being transported. So
> > > > what are the actual use-cases that need to be solved? Presumably
> > > > some sort of communication between two parties that share access to
> > > > the same HSM?
> > >
> > > Does the format of the kid need to be specified so that an
> implementation would react to it?
> > >
> > > A use case would be that one gets several public keys from
> different people to encrypt some data. I have several keys and I
> would like to avoid decryption by trial and error, which becomes
> more time consuming when network devices are involved, so I send the
> public key in JWE format and it contains the URI (pkcs11 or kmip)
> for the key to use for decryption. The encryptor embeds this key
> identifier in the recipients section so that I know which section is
> for me and which key to use for decrypting.
> >
> > That already works just fine. Set the “kid” claim in your public
> JWK to the pkcs11/kmip URI and then make sure the client sends you
> the same value in the “kid” header of the encrypted JWE. This is
> precisely what the “kid” JWK claim and header are for.
> >
> > Depending on the sensitivity of the information in the URI, you
> may want to either encrypt it or replace it with an opaque
> identifier that you store in a local lookup table.
>
> The "kid" claim is not a good fit for this.
>
> First, "kid" may need to be used in conjunction with "p11". For
> example, where "p11" replaces key material, the URI only refers to how
> to find the key material. But it does not provide credentials to
> access that key material. The "kid" may be needed to look up those
> credentials.
>
> Second, "p11" needs to have its own well-defined security
> considerations. There are security implications of using a PKCS#11 URI
> in publicly disclosed fields. These need to be carefully outlined.
> This is different than "kid" which is always presumed to be safe to
> disclose.

For kmip support one could embed the uuid and an implementation that comes
across a kmip type of key would invoke a callback that requires the user to
create a key object that is configured with the credentials for accessing
the key, such as client certificate and private key and so on. These
parameters could be taken from a local configuration file. I suppose the
same would work for the PIN and other parameters for pkcs11 support.