> 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
