Subject: Re: [jose] JOSE and PKCS11 & KMIP

From: "Stefan Berger" <[email-masked]>
Date: Tue, 26 Feb 2019 17:19:43 -0500

"jose" <[email-masked]> 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!

KMIP would be another protocol to support. One could use similar URIs like
those from pkcs11 since no standard exists in this area. I am rather
surprised that JOSE doesn't integrate hardware devices so far...

    Stefan

---

From: "Stefan Berger" <[email-masked]>
Date: Tue, 26 Feb 2019 18:29:26 -0500

> 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

---

From: Neil Madden <[email-masked]>
Date: Wed, 27 Feb 2019 08:18:51 +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 <[email-masked]> wrote:
> 
> RFC 7516 A.4.1 shows examples for encrypting the CEK with an RSA key and an AES key:
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: "Stefan Berger" <[email-masked]>
Date: Wed, 27 Feb 2019 09:13:59 -0500

"jose" <[email-masked]> wrote on 02/27/2019 03:18:51 AM:
> 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.

   Stefan

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

> https://urldefense.proofpoint.com/v2/url?
> u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwICAg&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=1v27re_HJcPTJPkwTHXQYpTrbS_E7w3vBoyF3b2lE60&m=hcjxN6seCKdLx-51bXrIjNi5rCoUdPYKWFw5f0e6jsY&s=nqP3lW0JzGxKmximnbh4msdvIc1qm6oJ9YOWfePUMcI&e=

---

From: Neil Madden <[email-masked]>
Date: Wed, 27 Feb 2019 14:26:50 +0000

On 27 Feb 2019, at 14:13, Stefan Berger <[email-masked]> wrote:
> 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.

— Neil

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 27 Feb 2019 09:36:13 -0500

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

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.

---

From: "Stefan Berger" <[email-masked]>
Date: Wed, 27 Feb 2019 09:36:39 -0500

"jose" <[email-masked]> wrote on 02/27/2019 09:26:50 AM:

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

I guess what I am missing then is an explicit mentioning of the format of
the kid field that would include those type of URI identifiers.

   Stefan

> u=https-3A__www.ietf.org_mailman_listinfo_jose&d=DwIGaQ&c=jf_iaSHvJObTbx-
>
siA1ZOg&r=1v27re_HJcPTJPkwTHXQYpTrbS_E7w3vBoyF3b2lE60&m=snNfNItnhX7ejU1KATGw4U6vL0-

> INT9vS6xZHLIqtZ0&s=2VtxKWnWFNWpTVQsBrtzM0_AX13Z77IhAwv67q90Z2c&e=
>

---

From: "Stefan Berger" <[email-masked]>
Date: Wed, 27 Feb 2019 09:57:23 -0500

"jose" <[email-masked]> wrote on 02/27/2019 09:36:13 AM:

> > > > I’m not sure I understand yet the issue that is being addressed
with
> > > > this work.
> > 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
> > 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.
>

For kmip support one could embed the uuid and an implementation that comes
across a kmip type of key would invoke a callback that requires the user to
create a key object that is configured with the credentials for accessing
the key, such as client certificate and private key and so on. These
parameters could be taken from a local configuration file. I suppose the
same would work for the PIN and other parameters for pkcs11 support.

---

From: Neil Madden <[email-masked]>
Date: Wed, 27 Feb 2019 15:09:11 +0000

On 27 Feb 2019, at 14:36, Nathaniel McCallum <[email-masked]> wrote:
>> [snip]

> access that key material. The "kid" may be needed to look up those

If you need the kid to lookup the credentials, can you not also use it to lookup the PKCS#11 URI?

> This is different than "kid" which is always presumed to be safe to

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

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 27 Feb 2019 10:50:42 -0500

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

> 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 th…

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

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.

---

From: "Stefan Berger" <[email-masked]>
Date: Wed, 27 Feb 2019 10:54:31 -0500

Neil Madden <[email-masked]> wrote on 02/27/2019 10:09:11 AM:

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

If the field 'kid' or some other field was directing me to use one of my
HSM keys, I would probably want to know what the format of this field is
supposed to be -- 'kid' so far seems to not have a format. Knowing this
helps me implement a library to direct my HSM decryption attempts to the
blob where I will be successful in decrypting and allow me to skip all the
other ones for which I don't have the key. I would expect to find some sort
of hint for whether this is a pkcs11 or kmip key for example.

---

From: Neil Madden <[email-masked]>
Date: Wed, 27 Feb 2019 17:07:15 +0000

> On 27 Feb 2019, at 15:50, Nathaniel McCallum <[email-masked]> wrote:
> 

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.

> over to the library and expect PKCS#11 to work (within a set of

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. 

> the specifics in the existing draft (including "p11" vs "kid"), I'm

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

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 27 Feb 2019 12:21:23 -0500

The relationship between Java and PKCS#11 is different than literally
every other language. :)