Re: [whatwg] deprecating <keygen>

On 3 September 2015 at 20:21, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 2 Sep 2015, henry.story@bblfish.net wrote:
> > >
> > > The spec just reflects implementations. The majority of
> > > implementations of <keygen> (by usage) have said they want to drop it,
> >
> > There was a lot of pushback on those lists against dropping it, and no
> > clear arguments have been made for dropping keygen there.
>
> That's debatable (see foolip's e-mail), but more to the point, it's
> irrelevant. We're not trying to reflect consensus here. We're trying to
> reflect reality. That's why the spec still has <keygen>, but why it warns
> that browsers are planning on dropping it.
>
>
> > > and the other major implementation has never supported it.
> >
> > You mean IE? IE has always had something that did the same:
> >
> > https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx
> >
> > It is not idea, and it is easy to use both.
>
> I'm not really sure what you're trying to argue here. Are you saying we
> should specify this API? Are other browsers planning on implementing it?
>
>
> > To replace it with what? That is the problem that needs discussing and
> > not partially across twenty lists where the issues are only ever half
> > addressed.
>
> Again, the point of the spec here is just to reflect reality; if browser
> vendors say they want to drop something, then we have to reflect that,
> even if they don't plan on replacing it with anything. Otherwise, our spec
> is just rather dry science fiction.
>
> Having said that, it's my understanding that there are replacement APIs
> being developed. I'm not personally familiar with that work so I can't
> comment on it. Should the authors of a cryptography specification that
> browser vendors want to implement be interested in publishing their work
> through the WHATWG, I'm sure that could be arranged, and at that point
> this list would make for a very relevant place to discuss those
> technologies.
>
>
> > Indeed: they seem to be working as one would expect where one thinking
> > that forces that don't like asymetric key cryptography to be widely
> > deployed were trying to remove that capability as far as possible. The
> > manner of doing this - by secret evidence, and pointers to closed non
> > deployed standards - seems to be very much the way of doing of
> > organisations that like to keep things secret and closed.
>
> Asymetric key cryptography forms the basis of the entire Web's security
> system. It's pretty much the only possible way to have solid security in
> an environment where you don't trust the carrier. I doubt it's going
> anywhere anytime soon, unless we suddenly get a supply of securely-
> sharable one-time-pads...
>
> The post foolip pointed to points out that <keygen> is actually rather
> insecure (e.g. using MD5). One could argue that _keeping_ <keygen> is
> actually more harmful to asymetric-key cryptography than removing it...
>

Im not an expert here, but my understanding from reading some wikipedia
articles was that a preimage attack on md5 was 2^123.  If so, isnt that
pretty secure?  I asked on the blink thread why md5 was thought to be
insecure, but no one was able to answer, or point to a reference.  It would
be great to understand if there is a feasible attack here.

Looking at:

SignedPublicKeyAndChallenge ::= SEQUENCE {
    publicKeyAndChallenge PublicKeyAndChallenge
<http://www.w3.org/html/wg/drafts/html/master/semantics.html#publickeyandchallenge>,
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING
}


http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-keygen-element

There appears to be a field signatureAlgorithm.  Does that not suggest that
switching away from MD5 is future proofed?

>
>
>
> > The case has been made that things should go the other way around: the
> > problems should be brought up, and then improvements or replacements
> > found. When those are found and are satisfactory ( as evaluated against
> > a wider set of values that take the whole web security into account )
> > then one moves forward.
>
> I certainly encourage people to follow such a pattern, but when they
> don't, we can't just ignore reality.
>
> I encourage you to read our FAQ. The WHATWG has a much more pragmatic
> approach than other standards organisations you may be more familiar with.
>
>    https://whatwg.org/faq
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Thursday, 3 September 2015 18:34:12 UTC