Re: Crypto HW. Re: Web Cryptography Working Group scoping progressing...

Hey Harry,

I think that's about the right balance.  It seems like what this API should do is provide a set of primitives that can be provided by different types of cryptographic services:
-- The browser
-- The OS
-- A TPM
-- A smart card
-- An HSM
-- Etc.

The one thing that seems like it would be required, though, is some way for applications to choose between these options, or at least know which of them is providing its crypto.  This would seem to call for a way for these things to be identified, probably by time (e.g., in something like the above taxonomy) and by instance (e.g., some identifier for a smart card).  

Suggested text for an item in scope: "Identification of the hardware or software service that is providing cryptographic services".


On Nov 17, 2011, at 9:48 AM, Harry Halpin wrote:

>> IMO it doesn't make sense to include explicit support for Crypto HW
>> in a W3C WG.
>> Rationale: This is already a lost case since the smart card industry
>> haven't even begun thinking about this issue although quite a bunch
>> of their favorite customers including the financial sector and
>> Government actually do request solutions that allow them to get
>> away from all the proprietary plugins they currently use.
>> These guys have developed a "de jure" standard:
>> Nobody outside of their backyard cares about it.
>> BTW, I have yet to see a single proposal that bridges the gap
>> between the JS/JSON people and the ISO-7816/GP folks.  They have
>> probably never met :-)
>> Please don't take this as criticism, it is just a friendly advice.
> Currently the charter does not explicitly include smartcard support or
> reference to any of the ISO standards around smartcards.
> However, the charter does include "key storage on the device" but puts out
> of scope "device-specific access to keying material" [1]
> The idea is that through some platform-specific tool, it might be possible
> to load a key from a smartcard from the JS API, but that the API itself
> would not include "special smartcard" specific instructions. Thus, the
> burden of doing that would lie on the smartcard programmers, not the
> browsers.
> Is that enough? Is there any different terminology you would prefer?
>            cheers,
>                harry
> [1]
>> Anders

Received on Monday, 21 November 2011 14:09:42 UTC