W3C home > Mailing lists > Public > public-web-security@w3.org > January 2015

Re: [W3C Web Crypto WG] Rechartering discussion

From: Ryan Sleevi <sleevi@google.com>
Date: Thu, 8 Jan 2015 00:51:32 -0800
Message-ID: <CACvaWvZACzsfoy7PjYctT8JSUdGhUBswFV1fBVZ65yYN9MUm-g@mail.gmail.com>
To: Colin Gallagher <colingallagher.rpcv@gmail.com>
Cc: Wendy Seltzer <wseltzer@w3.org>, Maxwell Krohn <themax@gmail.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, GALINDO Virginie <Virginie.Galindo@gemalto.com>, Harry Halpin <hhalpin@w3.org>, "public-web-security@w3.org" <public-web-security@w3.org>, Chris Coyne <ccoyne77@gmail.com>, Richard Barnes <rlb@ipv.sx>
It would help to keep the discussion productive if you avoid such
inflammatory accusations of hidden motives that seek to harm security.

If you have reached that conclusion, then my best faith guess is that you
have not participated in this group for the past two years, nor read the
archives - or, at the least, the meeting minutes - in which it is
repeatedly described the complete, abject, and total failure for security
that every proposed solution has been, and that every legacy secure element
is. Despite being averse to the idea of absolutes, I feel extremely
confident in suggesting that there is no usable means to bring the legacy
solutions into the web in a way that can meaningfully convince browsers and
users of the security AND actually deliver on those promises. This is why
solutions such as FIDO exist - whose security is precisely derived because
it does NOT try to be a generic crypto API.

These sorts of underhanded accusations are neither productive nor welcome.
Concrete proposals are, and will be evaluated on the merit of their
security first and foremost.
On Jan 7, 2015 6:32 PM, "Colin Gallagher" <colingallagher.rpcv@gmail.com>

> Hello,
> As a participant in the Sept. 10-11, 2014 Web Crypto Next Steps
> http://www.w3.org/2012/webcrypto/webcrypto-next-workshop/
> (and as a person who had a paper (however brief) accepted for that
> workshop),
> --
> It sounds as though there is an effort underway to limit the scope of what
> this group will be discussing, in such a manner that would not include
> user-managed storage of keys, and that would attempt to diminish the
> importance of trustless systems while encouraging users to place more trust
> in exchange for convenience in various ways with a variety of services, but
> where this group for rechartering as has been proposed above, would only
> focus on "rechartering discussions in specific and narrow scopes if such
> proposals have consensus (in particular, from user agents)" uh-huh.
> At least, that's what the drift of it sounds like to me, and I don't like
> the sound of that.  I sense this strange struggle where:
> tl'dr"  some people don't want users to be in control of their keys, and
> would rather info dump into the vast ether of FISA, business records, 3rd
> party cromnibus, etc., because hey, it's important to make sure that you
> squeeze all the profit you can out the users before discarding them, right?
> or,
> other people, perhaps wanting to give the users a better chance, try to
> give the users more of a choice in where they will store their keys and
> what happens next (thanks maxwell and chris and those at keybase, as
> examples).
> Please advise what is the course of the group.  Thank you.  I just don't
> want to be here if the basic course is "oh let's um narrow it and try to
> throw people to the wolves but pretend we're not"
> tl'dr:  Change course.
> -c
> On Wed, Jan 7, 2015 at 4:31 PM, Richard Barnes <rlb@ipv.sx> wrote:
>> On Wed, Jan 7, 2015 at 7:43 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>> As noted during the F2F during the 2014 TPAC, it's unlikely we would
>>> be able to support such a rechartering.
>>> In the goals, only the first goal is something that aligns with our
>>> interest.
>>> In the scope, we are explicitly not interested in "user managed"
>>> storage and "web certificate management". Further, we don't believe
>>> this group is the appropriate venue for the discussion of Web
>>> Authentication - that would be better for WebApps or WebAppSec.
>>> WebAppSec already has proposals for dealing with credentials -
>>> http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0141.html
>>> Put differently, for a rechartering, the only effort we'd likely
>>> support support is the maintenance and exploration of algorithms.
>>> Any other chartering discussions should follow the highly productive
>>> workmodes of WebApps and WebAppSecs - that is, concrete, defined
>>> proposals being brought forth and holding rechartering discussions in
>>> specific and narrow scopes if such proposals have consensus (in
>>> particular, from user agents).
>> Reserving the right to disagree with Ryan on the particular scoping
>> above, I strongly agree with the above paragraph.  None of the proposed
>> work items to date has been defined in enough scope to make it clear what a
>> WG would do.
>> --Richard
>>> On Wed, Jan 7, 2015 at 1:48 AM, GALINDO Virginie
>>> <Virginie.Galindo@gemalto.com> wrote:
>>> > Dear all,
>>> >
>>> >
>>> >
>>> > Web Crypto WG charter [1] will end by the end of March. We need to
>>> prepare
>>> > the next charter of Web Crypto.
>>> >
>>> >
>>> >
>>> > As a reminder, the conversation has started on this page :
>>> > https://www.w3.org/Security/wiki/IG/webcryptonext_draft_charter
>>> >
>>> > Feel free to add you ideas and suggestions on the wiki and/or expose
>>> your
>>> > opinion and question on the public-webcrypto@w3.org or
>>> > public-webcrypto-comment@w3.org (for non W3C Web Crypto WG members).
>>> >
>>> >
>>> >
>>> > Regards,
>>> >
>>> > Virginie
>>> >
>>> >
>>> >
>>> > [1] http://www.w3.org/2011/11/webcryptography-charter.html
>>> >
>>> >
>>> >
>>> > ________________________________
>>> > This message and any attachments are intended solely for the
>>> addressees and
>>> > may contain confidential information. Any unauthorized use or
>>> disclosure,
>>> > either whole or partial, is prohibited.
>>> > E-mails are susceptible to alteration. Our company shall not be liable
>>> for
>>> > the message if altered, changed or falsified. If you are not the
>>> intended
>>> > recipient of this message, please delete it and notify the sender.
>>> > Although all reasonable efforts have been made to keep this
>>> transmission
>>> > free from viruses, the sender will not be liable for damages caused by
>>> a
>>> > transmitted virus.
Received on Thursday, 8 January 2015 08:54:47 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 8 January 2015 08:54:47 UTC