Re: WebCrypto Key Discovery Draft

On Sun, Apr 21, 2013 at 8:58 PM, Jeffrey Walton <noloader@gmail.com> wrote:

> On Sun, Apr 21, 2013 at 11:29 PM, Anders Rundgren
> <anders.rundgren@telia.com> wrote:
> > http://www.w3.org/TR/2013/WD-webcrypto-key-discovery-20130108/
> >
> > Since there are no standards for provisioning "named origin-specific
> keys", this draft relies on specifically adapted UAs.
> > There's absolutely nothing wrong with that but I honestly do not see
> that you need a _standard_ for such use-cases.
>

Anders - I think Jeff's questions below provide some reasons why a standard
is useful.


> >...
>
> *****
>
> This is troubling (use of the word MAY):
>
> Blocking access to named origin-specific pre-provisioned keys
>
>     User agents may restrict access to
>     named origin-specific pre-provisioned
>     keys to scripts originating at the domain
>     of the top-level document of the browsing
>     context, for instance returning empty key
>     search results for pages from other
>     domains running in iframes.


> Under what conditions/circumstances may it (or may it not) restrict
> access? HTTPONLY flag? Should there be another flag?


The text is adapted from that in the Web Storage specification (
http://www.w3.org/TR/webstorage/#privacy), including the MAY.


> Should key
> operations only be available on HTTPS connections?


Since the keys are origin-specific, and origin includes protocol, HTTP or
HTTPS, then a given key can be restricted to being available only to
https://netflix.com and not to http://netflix.com.


> How would a site
> takes a defensive posture so the key is only available on the login
> page, but not other pages (once the key is used to authenticate)?


I don't think we have that capability in the spec now. How do you think it
could be achieved ?


> Or
> can the key be used for authorization at the transaction level?
>

The key can be used any time by the origin it was provisioned for. In our
application we use it rarely, to establish session keys which are then used
to secure transactions. The session keys are renewed, using the
pre-provisioned key, every few hours.


>
> Why is it pre-provisioned keys? Wouldn't the concerns (and abuses)
> apply to other UA reachable keys as well?
>

The text refers to pre-provisioned keys only because the scope of this
specification is only pre-provisioned keys. Considerations applying to all
kinds of keys should be in the main WebCrypto specification.


>
> *****
>
> What doe STRONGLY mean?
>
> Treating named origin-specific pre-provisioned keys as cookies
>
>     User agents should present the named
>     origin-specific pre-provisioned keys
>     feature to the user in a way that associates
>     it strongly with HTTP session cookies.
>
>
The text was adapted from from Web Storage (
http://www.w3.org/TR/webstorage/#privacy). This is a recommendation about
the user interface and so its not clear that a definition of "strongly" -
other than the dictionary one - is necessary. Short of mandating specific
UI design features anything we way will be open to interpretation by UA
implementors anyway.


> *****
>
> This does not work in practice. The user will not make an informed
> decision:
>
> Origin-tracking of named origin-specific pre-provisioned keys
>
>     ... If this information is then used t
>      present a view of pre-provisioned keys
>     to the user, it would allow the user to
>      make informed decisions about
>      authorizing sites to make use of keys.
>
>
Again, the text was adapted from from Web Storage (
http://www.w3.org/TR/webstorage/#privacy).

I agree with the problem of (truely) informed privacy decisions being
elusive (I mean the fact that "informed choice" is different from "making a
choice after being informed". We can ensure the latter, but the former
requires that the information provided is actually read, understood and
used by the user when making the choice and we can't coerce this). It's a
big problem applying to many things outside this draft and I don't have
solution to it. If it can be solved, it should be solved more generally
than this very specific pre-provisioned key case.


> *****
>
> Need to hear more about the blacklists.... Is it used in place of
> explicit expiration or revocation? What's its format? How is the info
> shared?
>

Again, the material is adapted from Web Storage and these issues are mostly
up to UAs, we are just providing recommendations here. IIUC, the blacklist
refers to the UA keeping a record of origins for which the user has denied
access to the pre-provisioned keys and applying the same policy without
user interaction when the user re-visits that origin. Exactly how that
works, it's format etc. are UA implementation issues.

...Mark


>
> Jeff
>
>