Re: [jose] JOSE and PKCS11

Neil Madden <neil.madden@forgerock.com> Wed, 27 February 2019 08:18 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 9145D130E79 for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 00:18:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 QCEFVR8lYf6N for <jose@ietfa.amsl.com>; Wed, 27 Feb 2019 00:18:55 -0800 (PST)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 7DA0F130E9F for <jose@ietf.org>; Wed, 27 Feb 2019 00:18:55 -0800 (PST)
Received: by mail-wr1-x433.google.com with SMTP id r5so16813916wrg.9 for <jose@ietf.org>; Wed, 27 Feb 2019 00:18:54 -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=bwBbqFoZ1gtI5rC1E1sw1KshHSc/07kamZ9CoB4SQpE=; b=E4EpGniPKRYG2SffoeRlxPLF8zUAr68PJF20xkeEcqfIs8aiVB2Es+OV8kHRhCpu4e HtTpkVToYiReBB3ANJyAMluulgtQhgbQbBokM4nUyUrdNVxjiABZWoTAs9+zsWalREzc 6IGY1R0/Xhb22MbDOzZARGMv5bg2rK8MBZzzw=
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=bwBbqFoZ1gtI5rC1E1sw1KshHSc/07kamZ9CoB4SQpE=; b=tDkjoks1DsLgoMiUlTaMuHO83vbuPz+tYeOBE4WlGQm3gv92ludQKLdvVrMO41proE xfcqh9y7oV8QZT8w6ZMilC9z1Bv+XPqGsQ1nD0n/Ti5pIzuHf2FWvnDjRHe4021w1I6u v0EgKz2JupiuBE+zaDaBo7ZRwCdCXqrqnfarBMVNIAb5Pypv6zPGtjriY25JKnLGaNTC Yfz9KWGfiGrAB7DCatYpJFM46/34wDBmwDdZQ1w8MHVW9FUbauWjO5YAg9M/gVW2qKM0 DtnzPhEIpvxeOqbmOxBwRJxkYWoBTRtOJaCu4xgdUovlxwL25vnRWlAQ/YTHBBVIaPj8 6n5A==
X-Gm-Message-State: APjAAAXcIx/6ryMeBeRO1kILjftoc6S7DajP2YpL63TY/EHdq3ERmYDh MWqqEQqNXI4nRj05OauF6vWW5g==
X-Google-Smtp-Source: APXvYqyPzRbW/v7rc/dHUAnqOf+UoBIIhw8POlaBTw/IjYJFezAgORlHW9f1Y6kNBYrwcjoODlB+ww==
X-Received: by 2002:adf:f410:: with SMTP id g16mr1419916wro.246.1551255533104; Wed, 27 Feb 2019 00:18:53 -0800 (PST)
Received: from [192.168.1.65] (173.132.93.209.dyn.plus.net. [209.93.132.173]) by smtp.gmail.com with ESMTPSA id e23sm1064982wme.15.2019.02.27.00.18.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 00:18:52 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-3A52DF36-82CC-45D0-A453-EB552EF1ED91
Mime-Version: 1.0 (1.0)
From: Neil Madden <neil.madden@forgerock.com>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <OF2BF5119B.748538F2-ON002583AD.007FDFBF-852583AD.0081099B@notes.na.collabserv.com>
Date: Wed, 27 Feb 2019 08:18:51 +0000
Cc: Nathaniel McCallum <npmccallum@redhat.com>, jose@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <E824FA9C-1E86-4B6A-909B-4EF7875C9BE9@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>
To: Stefan Berger <stefanb@us.ibm.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/rWl85B2Rn4emySivrvVyOPFeUvA>
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 08:18:59 -0000

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?

— Neil

> On 26 Feb 2019, at 23:29, Stefan Berger <stefanb@us.ibm.com> wrote:
> 
> Nathaniel McCallum <npmccallum@redhat.com> wrote on 11/01/2018 07:07:55 PM:
> 
> > 
> > https://tools.ietf.org/html/draft-mccallum-jose-pkcs11-jwk-00
> > 
> > I plan to update this in the upcoming months and publish it as an 
> > independent draft. Likewise, we are implementing it here:
> > 
> > https://github.com/latchset/jose
> > 
> > Your contributions are welcome!
> > 
> 
> RFC 7516 A.4.1 shows examples for encrypting the CEK with an RSA key and an AES key:
> 
>    {"alg":"RSA1_5","kid":"2011-04-29"}
> 
>   and
> 
>   {"alg":"A128KW","kid":"7"}
> 
> https://tools.ietf.org/html/rfc7516#appendix-A..4.1
> 
> 
> Would one add a p11 field for pkcs11 support in this case? Would kid still have a meaning here? Or could one encode the pkcs11 URI in the kid field? Similarly, one could come up with a kmip URI (missing any standard for it) and put that into the kid, like this :  "kid": "kmip:uuid=<uuid>".. An implementation would have to have some sort of configuration file to look up the credentials to access the server where the key with that UUID is located.
> 
>    Stefan
> 
> 
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose