Re: [jose] PKCS #11 for JWK

[Nikos Mavrogiannopoulos <[e-mail]>]

On Wed, 2017-07-05 at 09:04 -0400, Nathaniel McCallum wrote:
> On Sat, Jul 1, 2017 at 4:00 AM, Simo Sorce <[e-mail]> wrote:
> > 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 ..."
> 
> I did some reflection on this over the long weekend. If we wanted to
> support offloading public key operations to PKCS #11, we'd need to
> have a "p11pub" JWK property which defines the URI to the public key
> to perform the operation on. This duplicates the existing public key
> information in the JWK.
> 
> We could allow three modes:
> 1. pubkey-only; no PKCS #11
> 2. URI-only; PKCS #11
> 3. both; optional PKCS #11
> 
> In mode #3, there is a possibility for public key mismatch. However,
> no attacks exist which don't also exist for mode #1.
> 
> My worry is that this is a lot of complexity for minimal gain. JOSE
> implementations already have to support #1. At best, mode #2 is going
> to be as fast as #1. I just don't see any compelling reason to
> support public key URIs. Do you?

As long as you have the tooling to extract that public key/cert from
the HSM, I can think of no reason using the HSM for public key
operations.

regards,
Nikos