Re: [jose] JOSE and PKCS11

Nathaniel McCallum <> Wed, 27 February 2019 15:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4EF1130FDB for <>; Wed, 27 Feb 2019 07:50:57 -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=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NrkkVOKvqPcI for <>; Wed, 27 Feb 2019 07:50:54 -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 A47281200B3 for <>; Wed, 27 Feb 2019 07:50:54 -0800 (PST)
Received: by with SMTP id p196so13851916iod.9 for <>; Wed, 27 Feb 2019 07:50:54 -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=OW8MYm3k5vmLqNwct8iKYkmthyvMluzEcUH6M9wkVU0=; b=J1/mwcNjiLH6VG8Cd3ZjmDWlKuCIL2wZXzrwTCrDQNrEucCZQxiyj6LUuFabm358Tn ihu3DG3qeoSXqJEDSMZtfbA0cN+6MgjzQo3AcrrEyQp8EdDNPLEQDCGtYhsaLbeerVl/ y69j9h3N/lO3d0g3Zrp7GOrEPka48zxm0APFG+AYIgSi4yjFEWCf2zHw1XuuX1w6idSO gZVBLbySZ+vRUM72Dy+k51HwObdiYOlRkwq4LLuCEvdpZZd2mFW9YaUncAPHpDf+Xh+o LYkw4u/t3Xc38ARPLQjkLps1FAwNyr5kwz4HHXA5g3JfBr7yg2prfy14wihNCMDuk7yU tgFA==
X-Gm-Message-State: APjAAAXVJNrMtd7aV2KGoiLALEUd8j1Xzl/DTexaVWBcd2kjKjmPm9pY vdSzKhaudxIr9me5VnJeF9Y4SEX2sgVTtCBGgiGhRQ==
X-Google-Smtp-Source: APXvYqxwgtmj6pWu9cTa3D0YAcby80gUH6rnihgezKjPV+bD9KHZzHcvaQ+PEFJKwvt04sUvL/hX4Ke0Kw5qygStOfM=
X-Received: by 2002:a6b:8d55:: with SMTP id p82mr2343440iod.171.1551282653465; Wed, 27 Feb 2019 07:50:53 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Nathaniel McCallum <>
Date: Wed, 27 Feb 2019 10:50:42 -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 15:50:58 -0000

On Wed, Feb 27, 2019 at 10:09 AM Neil Madden <> wrote:
> On 27 Feb 2019, at 14:36, Nathaniel McCallum <> wrote:
> >
> > On Wed, Feb 27, 2019 at 9:26 AM Neil Madden <> 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?

You *may* need the kid to look up the credentials. You might also need
it for other reasons, like looking up usage policy or other things
unrelated to PKCS#11. The important bit here is that this is optional.

I chose the "p11" assertion precisely because I don't want to consume
"kid" with this information. In practice, libraries will handle "p11"
and applications will handle "kid". That, to me, justifies having two.

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

First, PKCS#11 is a general purpose crypto API. HSMs are the
predominant, but not only, use case.

Second, PKCS#11 URIs are generally safe to disclose given the right
handling. Security is not black and white. This is precisely why the
Security Considerations section of IETF standards exist: to discuss
the details. These details are enough to justify a standard.

Third, there is a clear interoperability issue here: JOSE libraries.
Applications aren't going to be doing PKCS#11 directly (it is,
frankly, too hard). They're going to use JOSE libraries. So even if
the protocol between them is proprietary, they are going to hand a JWK
over to the library and expect PKCS#11 to work (within a set of

Please keep this in mind: the JOSE WG is closed. This standard will
probably end up as an individual submission. I'm doing most of the
work. Implementers, including me, are finding value in it. I plan to
continue this work. However, if you would like to have discussion over
the specifics in the existing draft (including "p11" vs "kid"), I'm
glad to do so.