Re: [jose] JOSE and PKCS11

["Stefan Berger" <[e-mail]>]

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

>
> On Wed, Feb 27, 2019 at 9:26 AM Neil Madden <[e-mail]>
wrote:
> >
> > On 27 Feb 2019, at 14:13, Stefan Berger <[e-mail]> wrote:
> > >
> > > "jose" <[e-mail]> 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.