On Sat, Jul 01, 2017 at 08:42:22AM -0400, Nathaniel McCallum wrote: > On Sat, Jul 1, 2017 at 4:00 AM, Simo Sorce <[email protected]> wrote: > > On Fri, 2017-06-30 at 17:33 -0400, Nathaniel McCallum wrote: > >> I have prepared an initial stab at a draft for offloading JWK private > >> key data to PKCS #11. > >> > >> You can find the document here: > >> https://www.ietf.org/id/draft-mccallum-jose-pkcs11-jwk-00.txt > > > > 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 ..." > > If we downgrade this recommendation, then we probably need to discuss > how implementations would correlate public key and private key object > URIs. That is, "p11" refers only to the private key. For public key > crypto operations, we need a URI that refers to the public key. Thus, > we would need a way to either:
One another thing to note is that some pieces of codebases can easily work with external private keys but not external public keys. That is, those pieces of code expect to work with private keys using signer interface (which can easily encapsulate PKCS#11 operation), but deal with public keys directly (so PKCS#11 there would be a major change). Some codebases even expect to be able to directly load the public key parts. -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
