- From: Anders Rundgren <anders.rundgren@telia.com>
- Date: Mon, 27 May 2013 13:56:46 +0200
- To: Ryan Sleevi <sleevi@google.com>
- CC: public-webcrypto-comments@w3.org, GALINDO Virginie <Virginie.GALINDO@gemalto.com>
On 2013-05-26 09:01, Ryan Sleevi wrote: > Please reread this thread. Ryan, Since the eID/Smart card/Certificate use-cases have been discussed on the primary mailing list with few if any references to the Key Discovery draft, I must unfortunately confess that I'm indeed rather confused. Hopefully today's call will clarify everything! Although nobody has requested it I take the liberty outlining how a slightly souped-up version of Samuel's KD solution could be implemented in for example Firefox: When the key discovery method is called, the certificates associated with Tools->Options->Advanced->Encryption->View Certificates->Your Certificates would be scanned. Identifiers to certificates having a specific X.509 extension holding an origin object matching the caller's origin would be returned as a list of sub-classed "Key" objects. The actual identifiers would preferably not be discoverable/exposed. Before using a discovered key, attributes could be retrieved with something like key.getAttribute (uri) where at least one URI would be pre-defined for accessing a "Certificate" attribute/object. This object would in turn support a number of methods and properties for finding out subject and issuer names, extensions, key usage, etc. Supporting Netflix would probably require an additional scan over some other key-store using another origin-attribute but the exact details I leave to the streaming-media community to define. The same syntax should apply anyway. Anders > > On May 25, 2013 10:59 PM, "Anders Rundgren" <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>> wrote: > > Ryan, > > That the existing KD draft supports the eID use-case is at least news to me. > > Would it be possible for you and Mark doing a minimal write-up on the > official mailing list providing some details on what modifications that > may have to be performed on the eIDs side in order to be compliant? > > Anders > > > > On 2013-05-25 14:41, Ryan Sleevi wrote: > > > > On May 25, 2013 12:05 AM, "Anders Rundgren" <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com> <mailto:anders.rundgren@telia.com <mailto:anders.rundgren@telia.com>>> wrote: > >> > >> On 2013-05-24 19:06, Ryan Sleevi wrote: > >> > On Fri, May 24, 2013 at 9:33 AM, Anders Rundgren > >> > <anders.rundgren@telia.com <mailto:anders.rundgren@telia.com> <mailto:anders.rundgren@telia.com <mailto: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. > > > > Anders, > > > > The point of a use case in a spec is to demonstrate a possible implementation - not to restrict its usage to only that implementation, as you have suggested. > > > > I have already shown you how it could support different use cases - such as eid. > > > > You seem to be confusing the need to standardize the browser behaviour *as visible to content scripts* with your desire to standardize other aspects of the smart card industry or particular implementations, but the latter is both inappropriate and unnecessary for this WG. Such conversations continue to be detrimental to the productivity of the WG, not to mention clearly out of scope on the charter. > > > > The only reason I feel compelled to reply is that I fear your reply contains such fundamental misunderstanding, but stated with such black and white terms, that other participants may be mislead into thinking it represents a WG position. > > > > I provided examples as a thought exercise to show that the spec is hardly as limited as you claim. I do not claim it is a complete solution to every single member's use case, but do believe it is far less limited than you have asserted. > > > > Regardless of this flexibility, it would be germane to continue such discussions elsewhere - or recognise that as non-chartered work, it reflects neither the WG position nor requires response from any WG member, nor or are your claims about members' positions representative. > > > >> > >> > >> >> 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. > > > > Please reread my reply, in which I clearly established key names are not email addresses. > > > >> > >> > >> >> 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 Monday, 27 May 2013 11:57:23 UTC