Re: [jose] JOSE and PKCS11

"Stefan Berger" <stefanb@us.ibm.com> Wed, 27 February 2019 14:14 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 2CF64130DE7 for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 06:14:26 -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 kVZcfiH8wIlz for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 06:14:24 -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 3E100130FCA for <jose@ietf.org>; Wed, 27 Feb 2019 06:14:24 -0800 (PST)
Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x1REEEbj027178 for <jose@ietf.org>; Wed, 27 Feb 2019 09:14:23 -0500
Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.90]) by mx0a-001b2d01.pphosted.com with ESMTP id 2qwuwjgud3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <jose@ietf.org>; Wed, 27 Feb 2019 09:14:18 -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:14:15 -0000
Received: from us1a3-smtp05.a3.dal06.isc4sb.com (10.146.71.159) by smtp.notes.na.collabserv.com (10.106.227.141) with smtp.notes.na.collabserv.com ESMTP; Wed, 27 Feb 2019 14:13:57 -0000
Received: from us1a3-mail155.a3.dal06.isc4sb.com ([10.146.38.88]) by us1a3-smtp05.a3.dal06.isc4sb.com with ESMTP id 2019022714135670-559805 ; Wed, 27 Feb 2019 14:13:56 +0000
In-Reply-To: <E824FA9C-1E86-4B6A-909B-4EF7875C9BE9@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:13:59 -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>
X-KeepSent: B3CFC7BB:B88F2A57-002583AE:004D3EAD; type=4; name=$KeepSent
X-Mailer: IBM Notes Release 9.0.1FP10 SHF68 March 06, 2018
X-LLNOutbound: False
X-Disclaimed: 39471
X-TNEFEvaluated: 1
x-cbid: 19022714-9717-0000-0000-00000B307F05
X-IBM-SpamModules-Scores: BY=0.019546; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.394815; ST=0; TS=0; UL=0; ISC=; MB=0.000041
X-IBM-SpamModules-Versions: BY=3.00010674; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000281; SDB=6.01167133; UDB=6.00609709; IPR=6.00947741; 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:14:12
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-000043CC975A
Message-Id: <OFB3CFC7BB.B88F2A57-ON002583AE.004D3EAD-852583AE.004E2F43@notes.na.collabserv.com>
Content-type: multipart/alternative; boundary="0__=8FBB093DDFDEB83D8f9e8a93df938690918c8FBB093DDFDEB83D"
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/WPLh_j43e5N1OL-dPgnTNb2WCQI>
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:14:26 -0000

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

   Stefan

>
> — Neil
>
> On 26 Feb 2019, at 23:29, Stefan Berger <stefanb@us.ibm.com> wrote:

> Nathaniel McCallum <npmccallum@redhat.com> wrote on 11/01/2018 07:07:55
PM:
>
> >
> > https://tools.ietf.org/html/draft-mccallum-jose-pkcs11-jwk-00
> >
> > I plan to update this in the upcoming months and publish it as an
> > independent draft. Likewise, we are implementing it here:
> >
> > https://github.com/latchset/jose
> >
> > Your contributions are welcome!
> >
>
> RFC 7516 A.4.1 shows examples for encrypting the CEK with an RSA key
> and an AES key:
>
>    {"alg":"RSA1_5","kid":"2011-04-29"}
>
>   and
>
>   {"alg":"A128KW","kid":"7"}
>
> https://tools.ietf.org/html/rfc7516#appendix-A..4.1
>
>
> Would one add a p11 field for pkcs11 support in this case? Would kid
> still have a meaning here? Or could one encode the pkcs11 URI in the
> kid field? Similarly, one could come up with a kmip URI (missing any
> standard for it) and put that into the kid, like this :  "kid":
> "kmip:uuid=<uuid>".. An implementation would have to have some sort
> of configuration file to look up the credentials to access the
> server where the key with that UUID is located.
>
>    Stefan
>
>

> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://urldefense.proofpoint.com/v2/url?
> u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=1v27re_HJcPTJPkwTHXQYpTrbS_E7w3vBoyF3b2lE60&m=hcjxN6seCKdLx-51bXrIjNi5rCoUdPYKWFw5f0e6jsY&s=nqP3lW0JzGxKmximnbh4msdvIc1qm6oJ9YOWfePUMcI&e=