On Wed, 2017-07-05 at 09:04 -0400, Nathaniel McCallum wrote: > 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 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 _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
