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. — Neil _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
