W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2013

Re: Additional use cases

From: Ryan Sleevi <sleevi@google.com>
Date: Tue, 7 May 2013 10:48:46 -0700
Message-ID: <CACvaWvYOKqo9cJfsZ-c=2BCNGMsciRMx=+Le=u5fvPtzxbiAXw@mail.gmail.com>
To: Seetharama Rao Durbha <S.Durbha@cablelabs.com>
Cc: Lu HongQian Karen <karen.lu@gemalto.com>, Arun Ranganathan <arun@mozilla.com>, "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
On Tue, May 7, 2013 at 8:14 AM, Seetharama Rao Durbha
<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

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
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
(and don't forget Anders' comments on public-webcrypto-comments at

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.
Received on Tuesday, 7 May 2013 17:49:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:17 UTC