On Wed, Feb 27, 2019 at 9:26 AM Neil Madden <[email protected]> wrote: > > On 27 Feb 2019, at 14:13, Stefan Berger <[email protected]> wrote: > > > > "jose" <[email protected]> wrote on 02/27/2019 03:18:51 AM: > > > > > > 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? > > > > 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.
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. _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
