Re: Key Discovery / W3C Web Crypto WG - our next adhoc call on monday 27th of May @ 20:00 UTC

On 2013-05-24 19:06, Ryan Sleevi wrote:
> On Fri, May 24, 2013 at 9:33 AM, Anders Rundgren
> <> wrote:
>> Well, you asked for input...


If I understood it correctly (?) you have dismissed the "eID" use-case
altogether so therefore the discussion below is sort of redundant.
For "completeness" I will anyway try to comment to the best of my ability.

A reason why the Web Crypto WG should reconsider this issue is that the
current WG position may lead to fragmentation with respect to platform
crypto support including proprietary extensions to cope with eID-like scenarios.

>> I believe that Samuel Erdtman's excellent idea: Optionally adding an
>> "Origin Tag" to keys provisioned through other means than Web Crypto,
> This is not necessary - it's already implied. Mark's made it clear
> from past conversations that at least one embodiment includes allowing
> any origin to access request to certain "named" keys and either
> generating them on the fly or sharing their key material.

Yes, but that's Mark's KD specification.  This is another KD proposal
which addresses similar needs but building on a different concept.

In the Netflix use-case keys are embedded in the platform during a
device personalization process in a platform-dependent way.

Question: why do we need a standard for non-standard features including "implied" origins?

In the eID use-case keys are provided in smart cards or are on-line
provisioned using existing mechanisms.  eIDs would in this KD proposal
require an upgrade with an X.509 extension holding an _explicit_ origin.

Your comparison with domain "A" being a counterpart to a trusted provider
of software is highly relevant. This KD proposal is supposed to create a
"bridge" between Web Crypto and keys provisioned in other ways. That's all.

> There is no spec change needed to support such a use case.

Does the current KD draft support the eID use-case or not?

If it does I would be happy to get a few lines describing how
Google would implement this in Chrome.

>> in conjunction with a revamped Key Discovery draft offering
>> _Key_Enumeration_ (for keys with a matching origin tag) and
>> _Key_Attribute_Retrieval_ (for discovered keys) could easily
>> support Netflix' _and_ the "eID community's" use-cases.
>> Named keys as specified in the current Key Discovery draft wouldn't
>> work for eID since every individual presumably have a unique name.
> This is not accurate.
> An eID key might be named "Sweden-eID", as a hypothetical example.

Key Enumeration + Key Attribute Retrieval + Optional User Selection
is the established way of selecting keys for cryptographic operations.

> There is absolutely nothing requiring the names be globally unique -
> indeed, there is strong incentive that they NOT be unique, and instead
> represent 'simple' names that can be agreed upon.

Since all major providers including Google use globally unique e-mail
addresses as login IDs, this discussion seems to belong to another forum.

>> Key Discovery should of course continue to be an add-on specification
>> so that browser vendors wouldn't have to implement it in order to be
>> Web Crypto compliant.
> Can you explain the value then? Who do you see as implementing the
> "eID community's" spec, if not browsers?

Presumably Google would vote NO to the inclusion of eID support.
To not leave the core in pieces I felt that it would be a better idea
making this optional.  The market will then decide.  Enabling of the
KD option could even be a part of "Settings" in a browser.


>> Cheers,
>> Anders

Received on Saturday, 25 May 2013 07:06:19 UTC