Re: WebCrypto Target Audience?

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 Friday, 10 August 2012 17:59:00 UTC