Re: removing keygen from HTML

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