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.
When we used JWK sets backed by Cryptoki before we took the following
approach (in Java):
1. Load PKCS#11 KeyStore.
2. 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.
3. If the private key is needed, that same reference is used to get at it.
On 28/06/17 23:00, Nathaniel McCallum wrote:
> Correct. This parameter can be consulted for private key operations
> when the private key material is unavailable.
>
> On Wed, Jun 28, 2017 at 4:46 PM, Vladimir Dzhuvinov
> <[email protected]> wrote:
>> Hi Nathaniel,
>>
>> So what you wish to propose is a new "p11" parameter which is a PKCS#11
>> URI (RFC 7512)?
>>
>> Vladimir
>>
>>
>> On 28/06/17 22:23, Nathaniel McCallum wrote:z
>>> We're using a JWK with a "p11" property because the public key
>>> material is still usable without the private key. For example,
>>> verification of signatures or encrypting data. So, for example:
>>>
>>> $ jose jwk gen -o test.jwk -i '{"p11":"pkcs11:..."}'
>>> $ cat test.jwk
>>> {"crv":"P-256","kty":"EC","p11":"pkcs11:...","x":"...","y":"..."}
>>>
>>> This JWK can be passed directly to most JOSE implementations and be
>>> successfully used for encryption or verification and the "p11"
>>> property will be ignored (or it can be stripped before sharing the
>>> key). For implementations that support PKCS#11, they can detect the
>>> absence of a private key during signing or decryption and fall back to
>>> evaluating the "p11" property.
>>>
>>> That is to say, PKCS#11 is not a replacement for a JWK but for the
>>> missing private (or symmetric) key.
>>>
>>> On Wed, Jun 28, 2017 at 2:22 PM, Jim Schaad <[email protected]> wrote:
>>>> I am not aware of any work being done for that purpose. I am not sure why
>>>> you would use a JWK rather than a URI, but I can see some possibilities.
>>>>
>>>> Jim
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: jose [mailto:[email protected]] On Behalf Of Nathaniel McCallum
>>>> Sent: Wednesday, June 28, 2017 5:41 AM
>>>> To: [email protected]
>>>> Subject: [jose] PKCS#11 Support for JWKs
>>>>
>>>> Has there been any interest in standardizing this?
>>>>
>>>> The Jose project[0] has some initial working code (not yet published).
>>>> We are using the (new, standardized) "p11" attribute in JWKs to replace the
>>>> absence of private key material. The value of this attribute is the URI to
>>>> the key as defined by p11-kit[1].
>>>>
>>>> Thus, when a JWK which lacks private key material but contains "p11"
>>>> is used for a decryption or signing process, we forward this request to the
>>>> PKCS#11 module.
>>>>
>>>> Does anyone have interest in working with me on a standard for this (or
>>>> something similar)?
>>>>
>>>> Nathaniel
>>>>
>>>> [0]: https://github.com/latchset/jose
>>>> [1]: https://github.com/p11-glue/p11-kit
>>>>
>>>> _______________________________________________
>>>> jose mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>
>>>> _______________________________________________
>>>> jose mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/jose
>>> _______________________________________________
>>> jose mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/jose
>> _______________________________________________
>> jose mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
