- From: Richard L. Barnes <rbarnes@bbn.com>
- Date: Mon, 6 Jun 2011 12:26:07 -0400
- To: David Dahl <ddahl@mozilla.com>
- Cc: public-web-security@w3.org
>> I understand that DOMCrypt is for the web. But the crypto stuff is going to be provided somehow, either from a library (e.g., OpenSSL), an OS API (e.g., the MS CryptoAPI), or a hardware device. The latter sector has long standardized on PKCS11 as an interface. The OpenDNSSEC crowd also have a software crypto library that offers a PKCS11 interface: > <http://trac.opendnssec.org/wiki/SoftHSM> > So the idea would be to "sniff" for a crypto device and use the key stored therein for all crypto operations? I wasn't even thinking of anything that complicated. The browser could choose the crypto implementation being used (S/W, H/W, etc.); the web app would just know what keys and functions were available to it. >> More so than the specific API format, there are design patterns that PKCS11 encourages, e.g., the generation and keeping of keys within the crypto system, as opposed to feeding them in from outside (i.e., from the application). I think this is what Stephen was referring to. > Yes, I am aware of these patterns now, as Brian Smith (Mozilla Security) has been giving me additional feedback on how NSS works in FIPS mode, etc. Great. That's sort of where I was headed. --Richard
Received on Monday, 6 June 2011 16:26:36 UTC