- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Sat, 25 May 2013 09:05:44 +0200
- To: Ryan Sleevi <sleevi@google.com>
- CC: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, GALINDO Virginie <Virginie.GALINDO@gemalto.com>
On 2013-05-24 19:06, Ryan Sleevi wrote: > On Fri, May 24, 2013 at 9:33 AM, Anders Rundgren > <anders.rundgren@telia.com> wrote: >> Well, you asked for input... Ryan, 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. Anders > >> >> Cheers, >> Anders >> >> > >
Received on Saturday, 25 May 2013 07:06:19 UTC