"jose" <[email protected]> wrote on 02/27/2019 09:36:13 AM:
> > 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. 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.
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
