Re: Additional use cases

Ryan
I agree. I agree that every deployment comes with its own risks, and people come up with ways to mitigate them.
In the Web Crypto case, it looks like the (strong) recommendations we make for deployments generating signatures are


  1.  store keys with PIN (no way to automatically load them)
  2.  Instruct your users to enter PIN only on sites using TLS with (EV) validated certificates

Thanks,
Seetharama

On 5/7/13 11:48 AM, "Ryan Sleevi" <sleevi@google.com<mailto:sleevi@google.com>> wrote:

On Tue, May 7, 2013 at 8:14 AM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com<mailto:S.Durbha@cablelabs.com>> wrote:
With the ownership of the key based on SOP that is not cognizant of
tampering (as of now), I am afraid that any discussion of signatures will be
futile, they cannot be used for non-repudiation, at the end of the day.

http://lists.w3.org/Archives/Public/public-webcrypto/2013Apr/0247.html

I don't see why you equate the discussion of ownership at all with
tampering/proof.

Further, I don't know if your claims are entirely justified to say
"They cannot be used for non-repudiation".

A quick example of the many attack vectors that exist in today's
applications - and yet are still somehow acceptable for
non-repudiation:
1) Native executables may or may not be code-signed.
2) There is no way for native executables to verify that they have
been properly code-signed with no malicious code injected. If
malicious code was injected, it would just lie.
3) There is no way for smart cards to know whether or not the calling
application is "legitimate". For example, it's not at all uncommon to
see malware hijack smart cards (eg: see Sykipot)

There are two realities here - the technical reality and the political
reality. The political reality of non-repudiation likes to believe
that today's solutions are acceptable - even though the technical
reality is flawed.

If these arguments all sound familiar, well, it's because I said the
exact same thing in September - see the thread
http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0156.html
(and don't forget Anders' comments on public-webcrypto-comments at
http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Sep/0010.html
)

This disconnect has nothing to do with the ownership model of the key
- either you accept some technical realities or not.

For example, in the native code, you have no assurances that hostile
code/malware is not running on the users machine. A PIN or password do
nothing to mitigate this threat. If you accept those signatures, then
WebCrypto should be the same. Your "code signature" is handled via TLS
- and your signature verification can be bolstered via means such as
pinning. Either you trust that code or you don't - no different (nor
more flawed) than native.

I'm sympathetic for those who want "more" assurances - but I want to
make sure it's recognized how fundamentally flawed the argument is
when compared to the already deployed, politically accepted reality of
general purpose computing. If we're going to try and improve things,
we must set reasonable expectations about what the real threats are
and what the benefits are.

If the only security guarantees for the Web API can be realized when
on a fully restricted, user-hostile machine (eg: not the general
purpose machine that the browser vendors represented here develop
for), then I'm more inclined to suggest that it belongs elsewhere -
such as SysApps or somewhere else - because it doesn't reflect a
general pattern for an open Web.