Smart Card support. Re: Request for feedback: DOMCrypt API proposal

On 2011-06-06 17:29, Richard L. Barnes wrote:
> 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>
> The idea would be to simplify exposing these existing crypto functions to the web.
> 
> 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.

Although I'm not a DOMCrypt champion, I think this is where DOMCrypt
shouldn't go.  PKCS #11 and Smart Cards are very complex and unsuitable
for web programming.  The biggest smart card maker Gemalto launched a
web-interface for smart cards a few years back called SCConnect.

http://www.smartcardalliance.org/articles/2007/11/13/gemalto-receives-best-software-sesames-award-with-sconnect

It has not gained any traction AFAICT.  Although not (at all) a PKCS #11
I think it shows how difficult it gets when untrusted code is supposed
to talk to hardware in the platform.

In addition, I would like to mention that RedHat which is supporting
NSS and PSS (Mozilla Crypto), do not use PKCS #11 in their DogTag
Card Management System.  The reason for that is that PKCS #11 is
very poor for provisioning keys.

Just to make things even more fun, both myself and Microsoft are
working with new smart card interfaces to the web.  MSFT's is
currently secret but mine is not:

http://webpki.org/auth-token-4-the-cloud.html

I have taken this idea a bit further and thus mandate a specific
"Web Token" architecture.

Anders

> 
> --Richard
> 
> 
> 
> On Jun 6, 2011, at 10:10 AM, David Dahl wrote:
> 
>> Richard:
>>
>> This API is a pure web application API. I would like to study how we can extend this API for use with smart cards as there are a few use cases here as well. I would really like for someone with experience writing code for smart cards to help me figure this out.
>>
>> Cheers,
>>
>> David
>>
>> ----- Original Message -----
>> From: "Richard L. Barnes" <rbarnes@bbn.com>
>> To: "David Dahl" <ddahl@mozilla.com>
>> Cc: public-web-security@w3.org
>> Sent: Sunday, June 5, 2011 8:45:34 PM
>> Subject: Re: Request for feedback: DOMCrypt API proposal
>>
>> I apologize if this question is obvious; I haven't had a chance to read the document yet.
>>
>> Is there any notion of how this document relates to the PKCS11 standard for interfacing to crypto devices?  
>> <http://en.wikipedia.org/wiki/PKCS11>
>>
>> PKCS11 clearly has more things than the DOMCrypt API would require (e.g., the ability to select and log into different devices).   But it seems like it would simplify implementation for browsers if they could just present a script with something logically equivalent to a virtual PKCS11 device, probably one per origin.  Especially given that at least one browser (Firefox) can use PKCS11 to talk to hardware devices.
>>
>> --Richard
>>
> 
> 
>

Received on Monday, 6 June 2011 16:17:03 UTC