On Sat, Jul 1, 2017 at 4:00 AM, Simo Sorce <[email protected]> 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". _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
