- From: Da Cruz Pinto, Juan M <juan.m.da.cruz.pinto@intel.com>
- Date: Wed, 30 May 2012 19:37:33 +0000
- To: Eric Rescorla <ekr@rtfm.com>
- CC: David McGrew <mcgrew@cisco.com>, "Richard L. Barnes" <rbarnes@bbn.com>, Anil Saldhana <Anil.Saldhana@redhat.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
That's correct. HSM vendors do provide custom APIs that behave like PKCS#11 modules (but do not comply to the PKCS#11 standard) for more current protocols. Marcelo. -----Original Message----- From: Eric Rescorla [mailto:ekr@rtfm.com] Sent: Wednesday, May 30, 2012 16:12 To: Da Cruz Pinto, Juan M Cc: David McGrew; Richard L. Barnes; Anil Saldhana; public-webcrypto@w3.org Subject: Re: ECC vs RSA, and Similar Conflicts On Wed, May 30, 2012 at 12:06 PM, Da Cruz Pinto, Juan M <juan.m.da.cruz.pinto@intel.com> wrote: > Keep in mind that PKCS#11 defines an API for accessing crypto operations, one which does not require the caller to have direct access to key material. For instance, most HSM (Hardware Security Modules) vendors provide a PKCS#11 library for developers to integrate with. > > This means that if you are using a PKCS#11 module, then you don't really need to have safe/unsafe sections of the API when using ,e.g., RSA. Moreover, if you are using a smartcard thru a PKCS#11 module, then you most probably will not be able to access the key material at all. This is only true because PKCS #11 has been adjusted to provide a number of specialized pieces of keying material manipulation as required by current protocols. If, for instance, I decided to invent a new KDF for use with DH (as SSL/TLS did) I would not be able to use it with existing PKCS #11. -Ekr
Received on Thursday, 31 May 2012 12:22:58 UTC