W3C home > Mailing lists > Public > public-web-security@w3.org > June 2011

Re: Request for feedback: DOMCrypt API proposal

From: David Dahl <ddahl@mozilla.com>
Date: Mon, 6 Jun 2011 09:21:25 -0700 (PDT)
To: "Richard L. Barnes" <rbarnes@bbn.com>
Cc: public-web-security@w3.org
Message-ID: <907624077.125197.1307377285198.JavaMail.root@zimbra1.shared.sjc1.mozilla.com>
----- Original Message -----
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: "David Dahl" <ddahl@mozilla.com>
Cc: public-web-security@w3.org
Sent: Monday, June 6, 2011 10:29:17 AM
Subject: Re: Request for feedback: DOMCrypt API proposal

> 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?

> The idea would be to simplify exposing these existing crypto functions to the web.
I will need to do some more reading on how these devices work.

> 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.
Received on Monday, 6 June 2011 16:21:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 June 2011 16:21:55 GMT