Re: [jose] JOSE and PKCS11

Nathaniel McCallum <> Wed, 27 February 2019 14:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18761130F21 for <>; Wed, 27 Feb 2019 06:36:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HAtl6Dt4yZBE for <>; Wed, 27 Feb 2019 06:36:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF9CE130EA2 for <>; Wed, 27 Feb 2019 06:36:24 -0800 (PST)
Received: by with SMTP id v10so13670867iop.4 for <>; Wed, 27 Feb 2019 06:36:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wYgS/MaPbBfGGBRiiaIrA526q0W3p3WV78e3rurbLdY=; b=ZhV9lvpOqQJhR4jWULbVCWoKkRdc+bcjIJKoW3VFvyr189Ij1bF4g1ZTV53YvkBQ4A fxABpRMrS5jO6BUOKlpZ9jfAYLfRHrjMxpVlABBXTz17772flqaQ5nr81aIpmpB8FoCR LFAUVEbeTJYD+zFi2wvZU1vSbhSE0AUx138hCxQS4ahe7ktIusrPfuvR50OAICrxhzNv vtBQpl2h5gQQEqjEISaRbu6TOfGNxQ/hdaP1fc3Xh20fXuSASyE/wi8h7l7aIoJMs2bb wIMjFoRGG592Vlu6IIUp8rqEY7Y9+hZEeh/Uwx596BY2RbbO2aAkW08JjPjGMFfOXHdw yu4w==
X-Gm-Message-State: APjAAAULrCLiegC6nCEHlnIeqNaPn1GTlrPHAtnlgmt+WqTPl1WleanQ dTwAvR+8tRJBfhLQhnefcgx+4SwWOSJznaeCq9wvkw==
X-Google-Smtp-Source: APXvYqz4fMZvp3wnvPlcTUZNvefURANPb2AjKvrGrDElQKiaQ2u6v/++G5unvI96egndBlQIAEWfPNk74QNs92DzUQk=
X-Received: by 2002:a6b:f716:: with SMTP id k22mr2213531iog.110.1551278183832; Wed, 27 Feb 2019 06:36:23 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Nathaniel McCallum <>
Date: Wed, 27 Feb 2019 09:36:13 -0500
Message-ID: <>
To: Neil Madden <>
Cc: Stefan Berger <>, jose <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [jose] JOSE and PKCS11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Feb 2019 14:36:28 -0000

On Wed, Feb 27, 2019 at 9:26 AM Neil Madden <> wrote:
> On 27 Feb 2019, at 14:13, Stefan Berger <> wrote:
> >
> > "jose" <> 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

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