Re: [jose] JOSE and PKCS11

Neil Madden <neil.madden@forgerock.com> Wed, 27 February 2019 15:09 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 93391130E71 for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 07:09:17 -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=unavailable 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 HvQe0MFv2J5B for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 07:09:14 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 78875130FCF for <jose@ietf.org>; Wed, 27 Feb 2019 07:09:14 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id z84so5904939wmg.4 for <jose@ietf.org>; Wed, 27 Feb 2019 07:09:14 -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=xKgblhk6yfPY+KnXeTESZtT/NWgWbaVw+eGe7kQx3g4=; b=IR5FVgzEX4zxus5icvqh4MLQ7XIB+aL64VNR2gBZnrCKlKEsVkpv+bSdJoAX5lwkJc sl4d2R1OLfDw6EoKLN0S3y9Ds3ogABAtPF33ZJFRW4LWVdAkEg8nvYPXMgu3wI1hfqC+ l9b/epHY0cCSuX4OotC4VAz9GEib162xZLEAU=
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=xKgblhk6yfPY+KnXeTESZtT/NWgWbaVw+eGe7kQx3g4=; b=sMYUYz3p0jkismdwCuy7rpepaPT+/12kiGVc+8fyyeT0SoD41sR/4cmCFcTKvCLJTB IlLc8ICdBA7TTmif0cQttfzJnq6H/kbo29y8lLNwTB5jkhJi3nxpWP6Znx/XiXVI7tG3 rvUSlJXohX5dagrXhz0pFSY8YcBLXGRKB9PpTdhBFq/X/Ju2JQtyah1Z1vk+5gTv1dx1 5Qt43lS2XURTEkIn5px0u1y7RmfMTQbpsIJzghgE9JmQPpfwUYIGzBQ1z3Nm5AkCSnSq hmgQ807sDtW78UB7yjgzG+dNT+zjOPc88GPwAhgh4fLjCSN3SUYVmFP5+PUCVnQgwq4Z d7ag==
X-Gm-Message-State: AHQUAuac0xH0Y55PCcYOzf1dGBeUxhEfoH9rRjJDLKkXGRTrP4WGwDye ddAz7auJ+K4ZnrXZ+H/HYCz/Dg==
X-Google-Smtp-Source: AHgI3Ia2M+f/fH0Slw6yqsKAgu2Q+AkTxBzm+pIMg9a88h2wbNaQV2Ybq/4CBhqn1efn/sK89EASzA==
X-Received: by 2002:a05:600c:210b:: with SMTP id u11mr2615960wml.11.1551280152749; Wed, 27 Feb 2019 07:09:12 -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 x12sm25884478wrs.84.2019.02.27.07.09.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 07:09:12 -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: <CAOASepNpA8Mcj983ZSnZ7Pi1OZocT=sFap5Me_PtikzELGtJuw@mail.gmail.com>
Date: Wed, 27 Feb 2019 15:09:11 +0000
Cc: Stefan Berger <stefanb@us.ibm.com>, jose <jose-bounces@ietf.org>, jose@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <93ACE34C-E89F-4EC5-AD7D-89A85B530A56@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>
To: Nathaniel McCallum <npmccallum@redhat.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/A-LO4nmgYFVDPhemRZIwFoq3ItA>
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 15:09:18 -0000

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?


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

— Neil