W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > October 2012

Re: Pre-provisioned Key-access Proposal - Privacy Consideration Update

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 31 Oct 2012 13:31:03 -0700
Message-ID: <CACvaWva79cG2bkMMGRX5kDm+gPG+UFwPkZNoBb52=h07iw_t=A@mail.gmail.com>
To: Anders Rundgren <anders.rundgren@telia.com>
Cc: Mountie Lee <mountie.lee@mw2.or.kr>, "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
On Wed, Oct 31, 2012 at 10:08 AM, Anders Rundgren
<anders.rundgren@telia.com> wrote:
> On 2012-10-31 07:26, Mountie Lee wrote:
>> on the model of http://webpki.org/papers/PKI/pki-webcrypto.pdf <http://webpki.org/papers/PKI/pki-webcrypto.pdf>
>> I feel "Signed-JS" is important.
>>
>> but I'm not clear how we verify signed-JS in UA.
>>
>> current webcrypto API is mainly focusing signing/verifying DATA not for JS code itself.
>>
>> this can be the replacement of pluging(java applet, activeX) code signing.
>>
>> also Trusted CA can has it's role for it.
>
> Mountie,
>
> Since I'm not representing a browser-vendor I do not have full insight in
> how browsers are architected but I did the assumption that they can separate
> (in run-time) code originating from different domains.

That's not a correct assumption, at least for the general web security
model. While there is a 'main' origin associated with the current
Browsing Context (see relevant HTML specs to understand what a
browsing context is), subresource script loads are evaluated in the
context of the requesting origin and have full access to it. This is
part of the general security model being discussed, and is not in
scope to change or be rearchitected by our working group. While
technologies such as CORS and CSP can reduce the risk, the notion that
the provenance of a given script (especially when prototype chains can
be dynamically altered and affect how subsequent scripts evaluate and
work) is not a notion available under the web platform.

>  A piece of signed
> java-script should be possible to treat like a domain.
>
> Anyway, the proposed scheme is derived from how various plugins that I have
> seen (and actually used as well) appears to work.  I say "appears" because
> the majority are proprietary.  One thing is pretty universal and that is
> that the plugin only "sees" keys associated with the plugin which is due
> to the fact that most of the plugins come with their own keystore etc.

This is also not an accurate position. For the European middleware
(Sweden, Estonia, Spain, Belgium, Portugal, Norway all come to mind),
an NPAPI plugin or ActiveX control makes use of the either the PC/SC
interface of Windows (WinSCard), which gives them access to all smart
cards and key stores, or makes use of custom CSPs / KSPs, which give
them *technical* access to all available keys. While they may be only
*interested* in certain keys, the plugin sees (and typically, exposes,
whether intentional or not) all available keys and/or cards.

Under the Korean/Chinese/Japanese cases, at least as far as I can
tell, there is less actual security and more security theater, making
use of PKCS#12 files with some form of visual pin entry (rather than
using CSPs/KSPs), and so while it's certainly accurate to suggest they
come with their own keystore, such security is typically so
non-existant in the existing implementations that I don't feel this is
a particularly compelling case to support and/or encourage.

>
> That plugins usually provide is a nice and customized user-interface is
> also a factor to consider.

Agreed. And as has been discussed on the list in the past there are
provisions to this that do not require any such custom schemes.

>
> My interest in Web Crypto is targeting universal keystores like featured
> in browsers for use with HTTPS.  I don't believe that users are able
> assigning permissions to arbitrary software to use specific keys.
> It would be like if you put a payment card in a payment terminal and
> the terminal would ask if you trust the payment terminal for using
> your card.  Most users would only be worried by such a question.
>

And yet many users are being asked to make that exact decision today
in the real world, to variable success. My local gas (petrol) station
just had a sign up reminding customers to beware of card skimmers,
having recently been exploited.

Just search "card skimmer" in your favourite news search engine, order
by date/time, and you'll see constant instances of card skimming.

Even the desktop model is increasingly moving towards per-app grants
for keys and passwords, a model that Apple has successfully deployed
for several years with respect to Keychain and codesigning.

While I am painfully aware of the general concern over security
usability and the importance of considering the user interface, I'm
also not willing to say "This is doomed, because we don't have a
*perfect* UI". Security through iteration is a better approach than
paralysis through contemplation.


> So I thought that a workable option could be letting the *issuer* of a
> key decide what software is allowed with the key.  Unlike traditional
> code-signing schemes, the signed-JS does only have to be trusted by
> the key (ACL), not by the platform.  This is quite important for the
> scalability of the scheme.  In addition, it relieves users from
> trust-decisions like ("do you accept this software etc etc") which
> they typically don't have much clue about.

Which is, to a degree, somewhat user hostile. This spec has been about
balancing the security benefits of users without necessarily endorsing
user-hostile actions.

That said, the very notion of an issuer being pre-authorized for a key
is a concept this group has explored, mentioned, and documented for
months, so there is nothing particularly new or novel in this
proposal. In the past, you can see I referred Mountie to web intents,
but there are *many* ways in the web platform that can exist as the
glue between a trusted, origin-authorized key holder (pre-provisioned
OR generated) and a "relying" web application.

So again, there's nothing new or special being proposed here - and
this is the exact same thing that has been discussed as a long term
option.

While we're mentioning things that have been discussed, but perhaps
not yet understood, is that it IS NOT the position of the WG that such
things are issues we don't want to touch, but it IS the position (at
least, so far) that these are NOT issues to focus on YET. It's a
matter of prioritization of effort and resources.

If you would like to see these issues discussed, then it would be more
helpful to the overall group if we could focus on the existing,
*identified* issues that MUST be resolved.

>
> Like most real-world schemes this idea have certain drawbacks as well.
> If the drawbacks are reasonable is of course for others to tell.
>
> An obvious hurdle is that *existing keys cannot be used* which is one
> reason why I have dived pretty deep into enrollment schemes as well.
>
> "The key is the key" is the new mantra? :-)
>
> Regards,
> Anders
>
>>
>> regards
>> mountie.
>>
>> On Tue, Oct 30, 2012 at 2:04 PM, Mark Watson <watsonm@netflix.com <mailto:watsonm@netflix.com>> wrote:
>>
>>
>>     On Oct 30, 2012, at 1:16 PM, Anders Rundgren wrote:
>>
>>     > On 2012-10-30 12:13, Mark Watson wrote:
>>     > <snip>
>>     >>> For practical comments, I feel that the current doc is full of
>>     >>> hand-wavey ideas that provide no guidance or actual APIs that show how
>>     >>> many of these concepts are to work or be used. I also think that,
>>     >>> absent formal membership, the IPR policies likely prevent this being
>>     >>> something that the WG could adopt.
>>     >>
>>     >> +1
>>     >
>>     > Mark, it would be interesting hearing Netflix' take on WebCrypto access to
>>     > pre-provisioned keys that are not bound to any particular domain.  Think credit-cards.
>>
>>     My +1 was to support the preference for proposals from WG members and the caution about proposals from outside, not a comment on the merits of the proposal.
>>
>>     I'm not well-placed to comment on credit cards. Obviously, things which make it easier and safer to use credit cards on the web are welcome,
>>
>>     ůMark
>>
>>     >
>>     > Anders
>>     >
>>     >
>>     >>
>>     >>>
>>     >>>>
>>     >>>> I have updated the document with a privacy consideration section.
>>     >>>>
>>     >>>> The scheme offers no privacy silver bullet but maybe a "workable solution".
>>     >>>>
>>     >>>> A generic Web Crypto issue seems to be that either you end-up with a standardized "key-picker" (probably pretty difficult to define) which would mark the selected key as usable by the application to use with the Web Crypto API, or you leave this responsibility to the [presumably well-written] application.   The described solution bets on the latter because this is much more flexible and may even turn out to be a prerequisite for market acceptance.  However, this introduces a potential privacy risk, since there's no platform-provided protection against key "misuse".
>>     >>>>
>>     >>>> BTW, I have recently been experimenting with the extension-scheme used by for example Google to access the Android Play-store which is based on stand-alone handlers for unique protocols like "market://".  This is a strong challenger to Web Crypto solutions for pre-provisioned keys.  This scheme also fits quite nicely with the described solution.
>>     >>>>
>>     >>>> -- Anders
>>     >>>>
>>     >>>>
>>     >>>
>>     >>>
>>     >>
>>     >>
>>     >>
>>     >
>>     >
>>
>>
>>
>>
>>
>> --
>> Mountie Lee
>>
>> PayGate
>> CTO, CISSP
>> Tel : +82 2 2140 2700
>> E-Mail : mountie@paygate.net <mailto:mountie@paygate.net>
>>
>> =======================================
>> PayGate Inc.
>> THE STANDARD FOR ONLINE PAYMENT
>> for Korea, Japan, China, and the World
>>
>>
>>
>>
>
>
Received on Wednesday, 31 October 2012 20:31:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 31 October 2012 20:31:32 GMT