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

On May 25, 2013 12:05 AM, "Anders Rundgren" <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> 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
> >>
> >>
> >
> >
>