- From: Daniel Appelquist <dan@torgo.com>
- Date: Tue, 31 May 2016 13:43:14 +0000
- To: Eric Mill <eric@konklone.com>, Harry Halpin <hhalpin@ibiblio.org>
- Cc: Chaals McCathie Nevile <chaals@yandex-team.ru>, Graham Leggett <minfrin@sharp.fm>, Reto Gmür <reto@gmuer.ch>, Travis Leithead <Travis.Leithead@microsoft.com>, "www-tag@w3.org" <www-tag@w3.org>
- Message-ID: <CALiHrg=LKxsd6UkSpCHiuQYWWDPvQ=YH=tavaQi1bzdG6MUNLg@mail.gmail.com>
Hi Folks - the TAG (in the person of Travis) has written on this topic: https://w3ctag.github.io/client-certificates/#replacing-keygen As noted, it represents the rough consensus of the TAG on this issue. Dan On Tue, 31 May 2016 at 13:33 Eric Mill <eric@konklone.com> wrote: > The original email said: "Since the TAG, or its members, appear to have > opinions about our spec, we'd be grateful to hear them." It'd be most > productive for this thread's discussion to at least be initiated by a > member of the TAG. > > -- Eric > > On Tue, May 31, 2016 at 8:12 AM, Harry Halpin <hhalpin@ibiblio.org> wrote: > >> >> >> On Tue, May 31, 2016 at 1:40 AM, Reto Gmür <reto@gmuer.ch> wrote: >> >>> On Tue, 31 May 2016, at 10:04, Harry Halpin wrote: >>> >>> I do not know anyone from the cryptographic or security community that >>> would support keeping <keygen>. Indeed, the default response from the >>> security/crypto community would be to drop <keygen> due to legacy usage of >>> MD5 and violation of security boundaries (SOP). >>> >>> That would also be my response if I was employed by the NSA and wanted >>> to prevent technologies that allow user controlled strong cryptography and >>> decentralized networks of trust (as enabled by webId). >>> >>> >> >> Reto, >> >> That was both an idiotic and offensive statement. Can you explain how >> amateur crypto and home-brewed protocols that no-one in the security or >> crypto community reviewed or supports is the way to fight the NSA? >> >> Myself and many others support strong cryptography and decentralized >> networks of trust, and fully support that effort. Rather than attribute the >> use of broken technology to protocols to NSA, it's also possibly due to >> lack of education. >> >> Thus, you may want to look at: >> >> 1) MD5 security issues are well-known and documented: >> http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf >> >> 2) In practice, the WebID+TLS community should use modern crypto and the >> Web Security model rather than attempt to build on top of an broken, >> obscure, and unstandardised browser behaviour. If you want to fight the NSA >> by building new protocols on the Web, I recommend taking a class that >> explains how Web security works. Videos are available from this MIT course >> explain modern Web Security, including the Same Origin Policy: >> https://www.youtube.com/watch?v=_1C62Twf0vs >> >> Hopefully others will be more reasonable, but you may wish to familiarize >> yourself with this thread rather than endlessly repeat it. >> >> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack >> >> Note that we're just modernizing with W3C Web Authentication secure and >> modern cryptographic one-factor authentication to use modern primitives and >> respect user privacy. You are more than welcome to join the Working Group >> as an Invited Expert, although an expert should be aware of the basics of >> security. >> >> Although there are a number of inaccuracies in this report in terms of >> WebCrypto, it's pretty clear Web Authentication matches all requirements in >> Section 6 here: >> http://w3ctag.github.io/client-certificates/ >> >> Thus, it makes sense to hold off and deprecate <keygen> after the fall of >> this year, when Web Authentication is deployed in browsers. As stated >> earlier, the "WebID" community can simply use Web Authentication rather >> than client certs for authentication. >> >> That being said, since the only browser that supports <keygen> currently >> is Mozilla, who plans to deprecate regardless of what the TAG says, then it >> can also be justified to remove from the standard today as there is no >> interoperability. >> >> cheers, >> harry >> >> >> >> >>> Cheers, >>> Reto >>> >>> >>> >> >> > > > -- > konklone.com | @konklone <https://twitter.com/konklone> >
Received on Tuesday, 31 May 2016 13:43:59 UTC