Re: [jose] PKCS #11 for JWK

[Vladimir Dzhuvinov <[e-mail]>]

On 2 Jul 2017 15:49, Ilari Liusvaara <[e-mail]> wrote:
>
> On Sat, Jul 01, 2017 at 08:42:22AM -0400, Nathaniel McCallum wrote: 
> > On Sat, Jul 1, 2017 at 4:00 AM, Simo Sorce <[e-mail]> wrote: 
> > > On Fri, 2017-06-30 at 17:33 -0400, Nathaniel McCallum wrote: 
> > >> I have prepared an initial stab at a draft for offloading JWK private 
> > >> key data to PKCS #11. 
> > >> 
> > >> You can find the document here: 
> > >>    https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt 
> > > 
> > > Later on you talk about performance penalty and say: 
> > > 
> > >    Implementations SHOULD perform public 
> > >    key operations, such as asymmetric signature verification or 
> > >    asymmetric encryption, without using PKCS #11 
> > > 
> > > I think this should be at most a MAY. If I wanted to be more pedantic I 
> > > would say you should take in consideration there may be PKCS#11 modules 
> > > that are already smart enough to implement such functions in software 
> > > so that they do not incur in performance penalties, so the whole this 
> > > would have to be wrapped in something like: 
> > >  "If the PKCS#11 implementation perform public key operation in hardare 
> > > that may result in poor performance then implementations MAY perfrom 
> > > public ..." 
> > 
> > If we downgrade this recommendation, then we probably need to discuss 
> > how implementations would correlate public key and private key object 
> > URIs. That is, "p11" refers only to the private key. For public key 
> > crypto operations, we need a URI that refers to the public key. Thus, 
> > we would need a way to either: 
>
> One another thing to note is that some pieces of codebases can easily 
> work with external private keys but not external public keys. 
>
> That is, those pieces of code expect to work with private keys using 
> signer interface (which can easily encapsulate PKCS#11 operation), but 
> deal with public keys directly (so PKCS#11 there would be a major 
> change). Some codebases even expect to be able to directly load the 
> public key parts.

I see most value in using the p11 parameter for the private key only. This is after all the main reason for people to consider a PKCS#11 store.

The existing JWK parameters for the public bits is the most portable approach. It is simple and should always work.

If there is value in using a PKCS#11 URI for the public key, or even as a certificate reference, why not define separate p11 params for that? With separate, dedicated parameters we'll also do away with the need to perform correlation behind the scenes.

Vladimir