Subject: Re: [jose] PKCS#11 Support for JWKs

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 1 Jul 2017 21:02:25 +0200

On 30/06/17 22:17, Nathaniel McCallum wrote:
> On Fri, Jun 30, 2017 at 2:30 PM, Vladimir Dzhuvinov
> <[email-masked]> wrote:
>> I was unaware of this spec until you mentioned it here. I had a look at it
>> last night. Am I correct that the pkcs11 URIs are simply a representation of
>> the config parameters used for loading Cryptoki libs and modules?
>>
>> I'm unsure how much of a utility a p11 parameter can have. The p11 URIs seem
>> to contain a lot of details that are not about the key, but about drivers,
>> hardware, the OS. Also, parameters that can change, e.g. the HSM slots. We
>> have a machine with two HSMs, and after a reboot the HSMs can get a
>> different slot assigned, which can be nuisance.
> This doesn't really describe PKCS#11 URIs; or at least how they are
> used in practice. The URI standard itself is basically just a 1-to-1
> mapping of all possible metadata you can extract from PKCS #11. In
> that sense the standard is deficient in that it lets you generate URIs
> that can only work in certain contexts.
>
> However, in practice, implementations only use a reliable subset of
> properties*. So, for example, if you use p11tool -O, you do not
> receive slot identifiers (which, as you said, might change) in the
> generated URIs.  The resulting URIs will work on all OSes and HW
> configurations (so long as the same crypto hardware is used). Features
> like driver specification are relegated to the query string within the
> standard itself and are typically omitted in real world practice.
Thanks for the clarifications. I'm won over now :)

> It would be entirely possible (and, in fact, the default behavior of
> GNU TLS) for you to provide a URI that would match your HSM keys every
> time, reproducibly. This could be easily summed up in a new JWK
> standard which would recommend to avoid attributes that would make it
> difficult to match. (Again, this is not hard and is widely done
> already.)
>
> Yes, we could write a new standard URI that wouldn't have these
> caveats. But it would be much better to simply handles these cases
> within a "recommendations" section of a new JWK standard for the "p11"
> attribute.

+1 to keep that as a recommendations section. Doing a new standard for
the p11 URIs would be too much work.

>
>> When we used JWK sets backed by Cryptoki before we took the following
>> approach (in Java):
>>
>> Load PKCS#11 KeyStore.
>> Export the found PKCS#11 keys into a JWK set, where the key alias becomes
>> the JWK "kid", the certificate is included as an option; each JWK keeps a
>> reference to the private key in the store.
>> If the private key is needed, that same reference is used to get at it.
> This is precisely what we don't want to do: build custom code every
> time we want to access crypto hardware. Instead, we want the José[0]
> project to have exactly the same interface whether crypto hardware is
> used or the private key is in the JWK directly. For example:
>
>     $ jose jwe dec -i my.jwe -O plain.txt -k mykey.jwk
>     $ jose jwe dec -i my.jwe -O plain.txt -k myhwkey.jwk
>
> In the above case, it doesn't matter whether the private key material
> is in the JWK directly or only referenced to by the JWK. We would
> provide exactly the same interface from the C API as well.
>
> This is going to be made all the more crucial for us given our (Red
> Hat's) broader adoption of PKCS #11 as a system level interface. That
> is, PKCS #11 is going to be much more common, not less. GNOME already
> exports PKCS #11 interfaces for its keyring. GNU TLS and OpenSC's PKCS
> #11 Engine for OpenSSL do too. This will be extended to the system
> level as well (we have active internal projects ongoing). We are even
> exploring a TPM interface via PKCS #11. All of these are using the
> URIs.

Having PKCS#11 support across the board is good for all who want to take
an extra step to secure their keys.

I hope that the PKCS standard will eventually catch up with the recent
CFRG work.

> We want JOSE to be a first class citizen in this world. And that
> should not involve writing special-case hardware code. It should be a
> matter of generating a properly formatted, standardized JWK.
>
> [0]: https://github.com/latchset/jose
>
> * - For example, GNU TLS outputs the following parameters as the full
> path to an object: model, manufacturer, serial, token, id, object and
> type. These uniquely identify a PKCS #11 key object in any context.