Re: [jose] JOSE and PKCS11

Neil Madden <neil.madden@forgerock.com> Wed, 27 February 2019 17:07 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 7B8ED130EE5 for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 09:07:21 -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 HiazjDEncPdk for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 09:07:19 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 140D812F1AB for <jose@ietf.org>; Wed, 27 Feb 2019 09:07:19 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id d17so18773385wre.10 for <jose@ietf.org>; Wed, 27 Feb 2019 09:07:18 -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=FhMGYToc4CNdlwnxsk2WGoxZ9ioKXODU0vpKmvCWkic=; b=Medmcjf4yS+x+xVEDkSUQYymj1YmI/HVq9jk6pynwulKOogZD2BwGBYstQVLotU7fR 75kS9KkJyKhTEkYREamjJc74UfyCe22teSAH1bGuVWEO5n+ZkbphrYKe8u+ugbqLOjB5 DmXi32t+2RWthTO/ADvfGJ106btNX6DJ0y/T0=
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=FhMGYToc4CNdlwnxsk2WGoxZ9ioKXODU0vpKmvCWkic=; b=tejk6QWoCCYBVkHmAZlgeYCUNbZi0QFEv6FQ8A+ExybMQO8D+k7irueSEKiOoUbWNd tgslZUVBozT2XqcQYtsHZMwuZ22NAXsFk58lIYeuKcM60n3hlLwJnLHRi0MvAhRqf3Eq RC/P6pHhegU7lx7F61hKQtpJ04eNXJQq8rtlwN+owPLcyZ3QK7pGjO7K0pQOjo8K4kva XGXCiCxUPBWPALpUiaoIUzXFHnllQ0DFdXsBW8IHI7sEjSouMqTbf6vA3thhpkmYHw8M 5C7wk06LNxGnlnqIq1nZfsLGy1YnRvEOUCMoA2vHdjy6cBGgbRrFGAoU5OpxvCTNyEgU ns9A==
X-Gm-Message-State: APjAAAU2vMwzI5uEbCNSCX9lZa77zN2fRyc+hxZahKU2o4if02rwC2sZ LdMsnVbd7idD1X/5xhO1MEvKrA==
X-Google-Smtp-Source: APXvYqxV/GtheWjVIYuOe0G1W/9d0eiBBshsJ3mKamUynn2GjP22PUB+IpfBPrUiHNfxmA1FW7LxQQ==
X-Received: by 2002:a05:6000:50:: with SMTP id k16mr3248778wrx.153.1551287237273; Wed, 27 Feb 2019 09:07:17 -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 n26sm2773698wmk.29.2019.02.27.09.07.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 09:07:16 -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: <CAOASepP0+kFaaJ59VQ4bf+GD_YsSFkY22Q-x39Y8tN27H1xxqg@mail.gmail.com>
Date: Wed, 27 Feb 2019 17:07:15 +0000
Cc: Stefan Berger <stefanb@us.ibm.com>, jose@ietf.org, jose <jose-bounces@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF6DA68E-20CA-4F5B-B3EE-95FADCFE537E@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> <48AE6835-F622-43AE-A1EA-23C3546B7DB8@forgerock.com> <CAOASepNpA8Mcj983ZSnZ7Pi1OZocT=sFap5Me_PtikzELGtJuw@mail.gmail.com> <93ACE34C-E89F-4EC5-AD7D-89A85B530A56@forgerock.com> <CAOASepP0+kFaaJ59VQ4bf+GD_YsSFkY22Q-x39Y8tN27H1xxqg@mail.gmail.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/uIjBvpUIYMPMRpA1jVyj2c0iqew>
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 17:07:22 -0000


> On 27 Feb 2019, at 15:50, Nathaniel McCallum <npmccallum@redhat.com> wrote:
> 
> On Wed, Feb 27, 2019 at 10:09 AM Neil Madden <neil.madden@forgerock.com> wrote:
>> 
>> 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?
> 
> 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.

I think I see where we are missing each other. I tend to think about JWK mostly in cases where they are communicated over a network, as in the jwks_uri usage in OpenID Connect. As I understand it, with this draft you are thinking about JWK as a standard way for an application to represent key material to a JOSE library that it is interacting with locally? If so, it might be worth spelling that out in the draft to clarify the use case being addressed.

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

I think this is why I struggled to understand the use-case. As my employer's JOSE library is written in Java, we take as input an opaque Java Key object rather than a JWK. This allows us to transparently use PKCS#11 HSMs via the Java Cryptography APIs that abstract over the details of PKCS#11 and instead deal with Java KeyStore and Key objects. As far as I am aware, most Java JOSE libraries operate the same way (or support both options), and most Java application developers would expect that. 

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

OK, that wasn’t clear to me as there has been discussion about potentially re-opening this WG or a related one some time ago on this list.

— Neil