Re: [jose] JOSE and PKCS11

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

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


>
> On 27 Feb 2019, at 14:36, Nathaniel McCallum <[e-mail]>
wrote:
> >
> > On Wed, Feb 27, 2019 at 9:26 AM Neil Madden
> <[e-mail]> wrote:
> >>
> >> [snip]
>
> >> 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.
>
> If you need the kid to lookup the credentials, can you not also use
> it to lookup the PKCS#11 URI?
>
>
> > 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.
>
> 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.

>
> — Neil