I believe that this will work in most, but not all, situations. The correlation of keys using the id= parameter is only a recommendation.
On Wed, Jul 5, 2017 at 10:26 AM, Simo Sorce <[email protected]> wrote: > 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 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". > > I do not think we need to explicitly add a p11public parameter. > As Nikos noted (unless I misunderstood) implementations can infer the > public key from the private one. So implementations may chose to use > the corresponding public key via pkcs11 if they so desire. Otherwise > they can use the current stuff which is just fine. > > Simo. _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
