RE: Additional use cases

Would it be beneficial to add an optional "key owner" authenticator that was stored with the key material?

This would mean that a simple structured clone of the Key Object or cross-origin messaging (postMessage) would be blocked unless the authenticator was also made available.

So, the key creation methods would need a nullable parameter added and the sign and decrypt would need the same.

The authenticator could either be sent direct from the server, entered on the page, or entered in the UA.

Regards,
	Michael

> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Tuesday, May 07, 2013 4:00 PM
> To: Seetharama Rao Durbha
> Cc: Lu HongQian Karen; Arun Ranganathan; public-webcrypto@w3.org Working
> Group
> Subject: Re: Additional use cases
> 
> On Tue, May 7, 2013 at 1:35 PM, Seetharama Rao Durbha
> <S.Durbha@cablelabs.com> wrote:
> > 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
> >
> > store keys with PIN (no way to automatically load them) Instruct your
> > users to enter PIN only on sites using TLS with (EV) validated
> > certificates
> >
> >
> > Thanks,
> > Seetharama
> >
> 
> I'm not sure how you reach those conclusions. It seems like it would be
> useful for Arun's documentation to explain the rationale.
> 
> The first assumption is we're talking about origin-bound keys - eg:
> what the core spec declares, not about any other aspect or future work. If
> you're thinking about smart cards or other keys, then our assumptions
> about the security model are entirely different, and thus an entirely
> different set of assumptions need to documented before we can reasonably
> discuss the use case that explains the assumptions.
> 
> With such per-origin keys, why can the origin not prompt (through its web
> UI under the web applications control) a "PIN" prompt. What assurances do
> you expect to realize if the "PIN prompt" is implemented in browser-chrome
> versus in the web page.
> 
> How does this compare with middleware prompting - which itself is "as
> insecure" as having the webpage prompt.
> 
> Also, note again, keys are per-*origin*. That means the HTTP version of a
> site can never access the HTTPS keys - and vice versa.
> 
> As for EV, that provides no added security value in practice, so it's not
> worth mentioning.
> 
> > On 5/7/13 11:48 AM, "Ryan Sleevi" <sleevi@google.com> wrote:
> >
> > 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
> > 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.
> >

Received on Tuesday, 7 May 2013 21:18:22 UTC