The relationship between Java and PKCS#11 is different than literally every other language. :)
On Wed, Feb 27, 2019 at 12:07 PM Neil Madden <[email protected]> wrote: > > > > > On 27 Feb 2019, at 15:50, Nathaniel McCallum <[email protected]> wrote: > > > > 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. > > I think I see where we are missing each other. I tend to think about JWK > mostly in cases where they are communicated over a network, as in the > jwks_uri usage in OpenID Connect. As I understand it, with this draft you are > thinking about JWK as a standard way for an application to represent key > material to a JOSE library that it is interacting with locally? If so, it > might be worth spelling that out in the draft to clarify the use case being > addressed. > > > > >>> 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). > > I think this is why I struggled to understand the use-case. As my employer's > JOSE library is written in Java, we take as input an opaque Java Key object > rather than a JWK. This allows us to transparently use PKCS#11 HSMs via the > Java Cryptography APIs that abstract over the details of PKCS#11 and instead > deal with Java KeyStore and Key objects. As far as I am aware, most Java JOSE > libraries operate the same way (or support both options), and most Java > application developers would expect that. > > > 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. > > OK, that wasn’t clear to me as there has been discussion about potentially > re-opening this WG or a related one some time ago on this list. > > — Neil > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
