Re: [jose] JOSE and PKCS11

"Stefan Berger" <stefanb@us.ibm.com> Wed, 27 February 2019 14:37 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 A8003130FE9 for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 06:37:37 -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=unavailable 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 BUPLJcQGUG47 for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 06:37:35 -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 CAB25130E71 for <jose@ietf.org>; Wed, 27 Feb 2019 06:37:35 -0800 (PST)
Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1REYqq2030317 for <jose@ietf.org>; Wed, 27 Feb 2019 09:37:30 -0500
Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.90]) by mx0b-001b2d01.pphosted.com with ESMTP id 2qwu08cuhb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <jose@ietf.org>; Wed, 27 Feb 2019 09:37:30 -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:37:29 -0000
Received: from us1a3-smtp04.a3.dal06.isc4sb.com (10.106.154.237) by smtp.notes.na.collabserv.com (10.106.227.141) with smtp.notes.na.collabserv.com ESMTP; Wed, 27 Feb 2019 14:36:37 -0000
Received: from us1a3-mail155.a3.dal06.isc4sb.com ([10.146.38.88]) by us1a3-smtp04.a3.dal06.isc4sb.com with ESMTP id 2019022714363689-594005 ; Wed, 27 Feb 2019 14:36:36 +0000
In-Reply-To: <48AE6835-F622-43AE-A1EA-23C3546B7DB8@forgerock.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: jose@ietf.org, jose <jose-bounces@ietf.org>, Nathaniel McCallum <npmccallum@redhat.com>
From: Stefan Berger <stefanb@us.ibm.com>
Date: Wed, 27 Feb 2019 09:36:39 -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>
X-KeepSent: C4EC42A4:2B72A293-002583AE:00502754; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0.1FP10 SHF68 March 06, 2018
X-LLNOutbound: False
X-Disclaimed: 5735
X-TNEFEvaluated: 1
x-cbid: 19022714-9717-0000-0000-00000B309092
X-IBM-SpamModules-Scores: BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.394815; ST=0; TS=0; UL=0; ISC=; MB=0.000047
X-IBM-SpamModules-Versions: BY=3.00010674; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000281; SDB=6.01167141; UDB=6.00609714; IPR=6.00947749; 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:37:26
X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused
X-IBM-AV-VERSION: SAVI=2019-02-27 09:10:04 - 6.00009636
x-cbparentid: 19022714-9718-0000-0000-000043CCAE9E
Message-Id: <OFC4EC42A4.2B72A293-ON002583AE.00502754-852583AE.0050429C@notes.na.collabserv.com>
Content-type: multipart/alternative; boundary="0__=8FBB093DDFC3A1C48f9e8a93df938690918c8FBB093DDFC3A1C4"
Content-Disposition: inline
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-27_09:, , signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/lJtgaX-BXmY51WtJ6aUFfyqehKo>
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:37:38 -0000

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

>
> 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.

I guess what I am missing then is an explicit mentioning of the format of
the kid field that would include those type of URI identifiers.

   Stefan

>
> — Neil
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://urldefense.proofpoint.com/v2/url?
> u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwIGaQ&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=1v27re_HJcPTJPkwTHXQYpTrbS_E7w3vBoyF3b2lE60&m=snNfNItnhX7ejU1KATGw4U6vL0-

> INT9vS6xZHLIqtZ0&s=2VtxKWnWFNWpTVQsBrtzM0_AX13Z77IhAwv67q90Z2c&e=
>