I agree. Please see my other reply to Simo for more details. On Mon, Jul 3, 2017 at 9:20 AM, Vladimir Dzhuvinov <[email protected]> wrote: > > 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
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
