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

Reply via email to