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

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.  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.

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

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.

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.

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 17:08:48 UTC