On Wed, Feb 27, 2019 at 10:09 AM Neil Madden <[email protected]> wrote: > > On 27 Feb 2019, at 14:36, Nathaniel McCallum <[email protected]> wrote: > > > > On Wed, Feb 27, 2019 at 9:26 AM Neil Madden <[email protected]> > > 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?
You *may* need the kid to look up the credentials. You might also need it for other reasons, like looking up usage policy or other things unrelated to PKCS#11. The important bit here is that this is optional. I chose the "p11" assertion precisely because I don't want to consume "kid" with this information. In practice, libraries will handle "p11" and applications will handle "kid". That, to me, justifies having two. > > 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. First, PKCS#11 is a general purpose crypto API. HSMs are the predominant, but not only, use case. Second, PKCS#11 URIs are generally safe to disclose given the right handling. Security is not black and white. This is precisely why the Security Considerations section of IETF standards exist: to discuss the details. These details are enough to justify a standard. Third, there is a clear interoperability issue here: JOSE libraries. Applications aren't going to be doing PKCS#11 directly (it is, frankly, too hard). They're going to use JOSE libraries. So even if the protocol between them is proprietary, they are going to hand a JWK over to the library and expect PKCS#11 to work (within a set of constraints). Please keep this in mind: the JOSE WG is closed. This standard will probably end up as an individual submission. I'm doing most of the work. Implementers, including me, are finding value in it. I plan to continue this work. However, if you would like to have discussion over the specifics in the existing draft (including "p11" vs "kid"), I'm glad to do so. _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
