On 2 Jul 2017 15:49, Ilari Liusvaara <[email protected]> wrote: > > 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.
I see most value in using the p11 parameter for the private key only. This is after all the main reason for people to consider a PKCS#11 store. The existing JWK parameters for the public bits is the most portable approach. It is simple and should always work. If there is value in using a PKCS#11 URI for the public key, or even as a certificate reference, why not define separate p11 params for that? With separate, dedicated parameters we'll also do away with the need to perform correlation behind the scenes. Vladimir _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
