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

Please reread this thread.
On May 25, 2013 10:59 PM, "Anders Rundgren" <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>> 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>> 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
> >> >>
> >> >>
> >> >
> >> >
> >>
> >
>
>