Re: [jose] PKCS #11 for JWK

[Nathaniel McCallum <[e-mail]>]

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 an aside, I do see value in exporting X.509 material from
certificate URIs and placing them in the already established JWK
parameters. However, I do not think standardization is required to
support this; implementations can do this in a compatible way without
any new RFCs once they have "p11".