On 30/06/17 22:17, Nathaniel McCallum wrote: > On Fri, Jun 30, 2017 at 2:30 PM, Vladimir Dzhuvinov > <[email protected]> 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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
