On Wed, 2017-07-05 at 10:45 -0400, Nathaniel McCallum wrote: > I believe that this will work in most, but not all, situations. The > correlation of keys using the id= parameter is only a recommendation.
I think it is ok to rely on the recommendation and fail otherwise, all JWK libraries must be prepared to handle public keys on their own anyway, so they can always just do that. Simo. > 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
