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

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

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Tue, 30 Oct 2012 13:04:26 +0100
Message-ID: <508FC24A.1070003@telia.com>
To: Ryan Sleevi <sleevi@google.com>
CC: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
On 2012-10-30 12:02, Ryan Sleevi wrote:
> On Tue, Oct 30, 2012 at 2:24 AM, Anders Rundgren
> <anders.rundgren@telia.com> wrote:
>> Although I haven't received that much feedback on
>>
>>    http://webpki.org/papers/PKI/pki-webcrypto.pdf
> 
> There are a lot of documents and submissions for the WG to review.
> This has been constantly mentioned in the past. While submissions from
> non-members are valuable and considered, it may be more fruitful to
> consider formally joining the WG (including IPR policy agreements) and
> making a formal member submission (eg: a spec) that provides a
> practical API, rather than describing the high-level objectives
> without any implementation guidance or concerns.

The WG is free inviting anybody they feel useful as an expert.

There is AFAICT one specified API-method .

Anyway, if the WG isn't interested in discussing or considering the
core principle behind this proposal it would be a waste of time going
further.


> However, as has been mentioned several times, the focus and priority
> of this WG has been to resolve the low-level API issues.

Key access control is IMHO a low-level API issue.


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

It has at least a reasonably well-defined trust-model and you essentially
only need a single API method.

The number and types of key-attributes are of secondary importance.  The
representation of ACLs or exactly how signed web-code is packaged are details
that for sure are important, but the concept should be understandable anyway.

In case somebody have specific questions, feel free to ask them anytime!
Even objections are welcome because they often result in improved specs.


>I also think that, absent formal membership, the IPR policies likely
> prevent this being something that the WG could adopt.

I don't know anything about the IPR situation, the described concept may
very well already be patented by somebody.

I don't expect the WG to adopt this proposal since it is incompatible with
most (if not all) existing platforms.  So why did I post it?  To possibly
at least get some feedback for *my* work :-)  You have slashed the proposal
but my contacts in the financial sector aren't equally categorical; they kind
of like the idea that they can discriminate access to "their" keys.

That the key access control scheme isn't limited to WebCrypto is also a plus.

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
>>
>>
> 
> 
Received on Tuesday, 30 October 2012 12:05:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 30 October 2012 12:05:07 GMT