Re: [jose] JOSE and PKCS11

"Stefan Berger" <stefanb@us.ibm.com> Wed, 27 February 2019 15:54 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 364E913106B for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 07:54:39 -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 OKDVV7ysJ_jC for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 07:54:37 -0800 (PST)
Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 BFE4713104E for <jose@ietf.org>; Wed, 27 Feb 2019 07:54:37 -0800 (PST)
Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1RFpV4e094956 for <jose@ietf.org>; Wed, 27 Feb 2019 10:54:37 -0500
Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.81]) by mx0a-001b2d01.pphosted.com with ESMTP id 2qwupbeydg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <jose@ietf.org>; Wed, 27 Feb 2019 10:54:36 -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 15:54:34 -0000
Received: from us1a3-smtp05.a3.dal06.isc4sb.com (10.146.71.159) by smtp.notes.na.collabserv.com (10.106.227.88) with smtp.notes.na.collabserv.com ESMTP; Wed, 27 Feb 2019 15:54:30 -0000
Received: from us1a3-mail155.a3.dal06.isc4sb.com ([10.146.38.88]) by us1a3-smtp05.a3.dal06.isc4sb.com with ESMTP id 2019022715542996-688149 ; Wed, 27 Feb 2019 15:54:29 +0000
MIME-Version: 1.0
In-Reply-To: <93ACE34C-E89F-4EC5-AD7D-89A85B530A56@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 10:54:31 -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> <93ACE34C-E89F-4EC5-AD7D-89A85B530A56@forgerock.com>
X-KeepSent: 0E92CB5A:855DDB95-002583AE:00569B94; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0.1FP10 SHF68 March 06, 2018
X-LLNOutbound: False
X-Disclaimed: 49243
X-TNEFEvaluated: 1
x-cbid: 19022715-7093-0000-0000-00000A50D53F
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.163730
X-IBM-SpamModules-Versions: BY=3.00010674; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000281; SDB=6.01167164; UDB=6.00609729; IPR=6.00947775; 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.00025768; XFM=3.00000015; UTC=2019-02-27 15:54:33
X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused
X-IBM-AV-VERSION: SAVI=2019-02-27 15:40:52 - 6.00009637
x-cbparentid: 19022715-7094-0000-0000-000070E8FEE1
Message-Id: <OF0E92CB5A.855DDB95-ON002583AE.00569B94-852583AE.005763AA@notes.na.collabserv.com>
Content-type: multipart/alternative; boundary="0__=8FBB093DDFC51D048f9e8a93df938690918c8FBB093DDFC51D04"
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/Tf-tV3Lxaozpv3sdVHwTDzAnOBk>
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 15:54:45 -0000

Neil Madden <neil.madden@forgerock.com> wrote on 02/27/2019 10:09:11 AM:


>
> On 27 Feb 2019, at 14:36, Nathaniel McCallum <npmccallum@redhat.com>
wrote:
> >
> > On Wed, Feb 27, 2019 at 9:26 AM Neil Madden
> <neil.madden@forgerock.com> wrote:
> >>
> >> [snip]
>
> >> 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.
>
> If you need the kid to lookup the credentials, can you not also use
> it to lookup the PKCS#11 URI?
>
>
> > 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.
>
> Again, this comes back to use cases. If the PKCS#11 URI is not safe
> to disclose then why do you want to expose it in a JWK? I know that
> JWK allows private key material to be represented, because this is
> sometimes useful to allow transmitting that key material. But with a
> PKCS#11 URI it is not key material, but instead a reference to key
> material in a locally/network-attached HSM, so presumably you are
> only sending it to yourself or another party locally connected to
> the same HSM? I’m struggling to see the interoperability requirement
> that would need this to be standardised.

If the field 'kid' or some other field was directing me to use one of my
HSM keys, I would probably want to know what the format of this field is
supposed to be -- 'kid' so far seems to not have a format. Knowing this
helps me implement a library to direct my HSM decryption attempts to the
blob where I will be successful in decrypting and allow me to skip all the
other ones for which I don't have the key. I would expect to find some sort
of hint for whether this is a pkcs11 or kmip key for example.

>
> — Neil