Re: WebCrypto Target Audience?

Ryan,
I think you misunderstood what I was trying to say here.
The core message is that things like secure storage is generally an issuer question.

<UsedCarSalesmanMode>

Regarding SKS (which I didn't mention), it is not an attempt to create a
"One True Grand Unified Crypto API", it is an about establishing a standard [1]
for on-line-provisionable key-containers.

Since existing standards like ISO/IEC 24727 (which are based on intricate mapping
of moderately compatible properties), without exception have failed to get any
traction from the (US) platform vendors [2], I thought that it might be a good
idea trying something else.

Naturally such a proposal would (MUST actually..) be turned down by W3C's SysApps
and similar SDO efforts since it is incompatible with every existing key-container
out there.  Given the "success" rate for mapping schemes, I'm not overly concerned
about that :-)

For *using* keys SKS is as compatible with crypto APIs as anything else although
there (of course) is a native API which is more powerful than the mapped dittos.

The native API (for example) offers credential logotypes which I think is a valid
requirement these days.

</UsedCarSalesmanMode>

Anders

1] de-facto/industry ditto

2] it is virtually impossible for a platform vendor to test and support such designs

On 2012-08-10 19:58, Ryan Sleevi wrote:
> On Fri, Aug 10, 2012 at 12:29 AM, Anders Rundgren
> <anders.rundgren@telia.com> wrote:
>> I have seen references in the discussions to things like "more secure" key-storage like smart cards etc.
>> This is something 99% of all web users have no idea about.  Issuers surely do, but that's another thing which WebCrypto (in its current incarnation) doesn't address at all.
> 
> Such discussions about smart cards are an implementation detail, but
> one frequently used because within the WG, the constraints and
> behaviours of such are easily understood. Fundamentally, the topic at
> discussion is key storage - secure elements are just one of many
> possible facets. That we can have this discussion at all highlights
> that a wide variety of possible applications may use this API, with a
> wide variety of operational needs and constraints.
> 
> As shown with the ongoing chartering of the W3C SysApps WG, and the
> proliferation of many browser-specific extensions (which arguably
> themselves are user-agents in their own right), the use of W3C APIs
> extends beyond the singular scope of a web browser.
> 
> I realize that your particular model of "smart card" usage may or may
> not be addressible with this API. For example, complex provisioning
> protocols are intentionally out-of-scope. Even "traditional" usage
> scenarios may not fit into this API. To the degree possible with both
> consensus and vendor-and-implementation neutrality, we'd like to
> enable many of the fundamental usages, but I do not believe any of us
> are trying to define the One True Grand Unified Crypto API, and thus
> discussions about solutions that try to fit into that space (eg: SKS)
> are thus viewed as counter-productive.
> 
>>
>> If you do specific features for "security experts" I wouldn't be surprised if it will in the end only create problems for those who really need secure solutions, which IMO are those who don't care about security :-)
> 
> Thank you for your feedback.
> 
>>
>> In addition, I'm pretty sure that by the time WebCrypto is ready, all major platforms will have built-in security hardware so there is no distinction anymore.
> 
> That is part of why this API makes specific pains to not address
> cryptographic modules, but instead simply deal with opaque key storage
> and the events that are common between such key storage mechanisms. If
> an implementation wishes to take advantage of such integrated
> solutions, it should be possible. Equally, it should not be required
> that an implementation do so either.
> 
>>
>> Related:
>> Although I *may* qualify as a "security expert", I'm not able to tell if for example this scheme is secure or not:
>> http://googlecommerce.blogspot.co.uk/2012/08/use-any-credit-or-debit-card-with.html
>>
>> Anders
>>
> 
>

Received on Saturday, 11 August 2012 08:04:04 UTC