Re: [jose] JOSE and PKCS11

Neil Madden <neil.madden@forgerock.com> Wed, 27 February 2019 14:26 UTC

Return-Path: <neil.madden@forgerock.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 6792B130FCA for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 06:26:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
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 Lz_rbh25XUNl for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 06:26:54 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AAC130E6F for <jose@ietf.org>; Wed, 27 Feb 2019 06:26:53 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id z84so5766935wmg.4 for <jose@ietf.org>; Wed, 27 Feb 2019 06:26:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lClwDeKh8VQ5C3nEDy9pVC2iE/MiFcsEqWOFD83j29U=; b=dC3O4V6z2LiFOZKlCDmOVFERDDBN+4um+N+AJmUbaXN6Tu9GuzD7lNeKpgZDuwN8Zc yFM74ECURzfenGPZFajjJmxHj9bkAqdroioRDM4MOJ7YsRptXytnB5eiRRfvp36D5qlP ++8BT9V8thNme4PhEMG2IStVC2QVaU3gq4SUE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lClwDeKh8VQ5C3nEDy9pVC2iE/MiFcsEqWOFD83j29U=; b=FNzHKTcEol5AqnqgF5bVv2L1i6eiIjo1s+qoyBJ7oDipgRk7UPNqLl3iyWP57GGJdU eb2oH7C8oDMIyRgOwsgrbhLH+wnIardxekZF/EJY9pwj5i1punl0NmYYzYTgM420R+g1 GpjSzQGgTWeHUDpr7nca8gqyDYFvjVu4Ilt7rCUkfHbVudTjMBma/aPVqGExEbLXwB3K bMzBf7l9aHY3I/f6GaMfMJOwS5keFUHAkMAcOh0BOgZxzdamvxvGVeCtzFqxAjMMyQb5 i0x8tUm3A4KfcdAfhNohIlx72yuaB0eDI61KBIA+Maz32NmZZsVCXB2pkIfM17A2YyHe Zstg==
X-Gm-Message-State: APjAAAW5NDCTC6QQ5zlLyzE9K8iVuTPao+sUd/BSIbLMVrbx9nPlyvmd dSnwbMvna6jgi7exc+XyeZt5MQ==
X-Google-Smtp-Source: AHgI3IYMJboeNVYzSYrHj/bbEsFgxpWfG3pnsYT9WBx1sz+CI61zQMU8eOtw9onEwbI1zjFdNUwnNw==
X-Received: by 2002:a1c:4155:: with SMTP id o82mr2433409wma.122.1551277612242; Wed, 27 Feb 2019 06:26:52 -0800 (PST)
Received: from guest2s-mbp.lan (173.132.93.209.dyn.plus.net. [209.93.132.173]) by smtp.gmail.com with ESMTPSA id h13sm13232594wrs.42.2019.02.27.06.26.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 06:26:51 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Neil Madden <neil.madden@forgerock.com>
In-Reply-To: <OFB3CFC7BB.B88F2A57-ON002583AE.004D3EAD-852583AE.004E2F43@notes.na.collabserv.com>
Date: Wed, 27 Feb 2019 14:26:50 +0000
Cc: Nathaniel McCallum <npmccallum@redhat.com>, jose <jose-bounces@ietf.org>, jose@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <48AE6835-F622-43AE-A1EA-23C3546B7DB8@forgerock.com>
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>
To: Stefan Berger <stefanb@us.ibm.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/JuTFjtW5h8vJ0vUS1p3tkT_pPrU>
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:26:56 -0000

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.

— Neil