On Sat, 2017-07-01 at 08:42 -0400, Nathaniel McCallum wrote: > > > 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: > > 1. Store the public key URI. > 2. Transmute the private key URI into a public key URI implicitly.
PKCS#11 mentions the following: "The CKA_ID attribute is intended as a means of distinguishing multiple public-key/private-key pairs held by the same subject (whether stored in the same token or not)." That field is also expected to match a certificate's subject key identifier field: "Note that with the version 3 extensions to X.509 certificates, the key identifier may be carried in the certificate. It is intended that the CKA_ID value be identical to the key identifier in such a certificate extension, although this will not be enforced by Cryptoki." Thus you can certainly rely on that, and if you have control on how the public/private key pair is generated, you can require this field to adhere to the above properties. regards, Nikos _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
