Re: Agenda: <keygen> being destroyed when we need it

On 2015-09-12 09:06, Alex Russell wrote:
> On 11 Sep 2015 7:29 pm, "Anders Rundgren" <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>  >
>  > On 2015-09-12 03:20, Alex Russell wrote:
>  >>
>  >>
>  >> Hi all,
>  >>
>  >> Apologies for the late response to this thread. I'm not sure that the
>  >
>  > > conversation has created much mutual understanding.
>  >
>  > No, it has not and that is because <keygen> only represents the tip of an ice-berg.
>  >
>  > The real issue is that Google have unilaterally decided that that non-origin-bound
>  > X.509 client certificates are incompatible with the Web for privacy, security, and
>  > usability reasons.
>
> That seems an unwarranted extrapolation.

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/pX5NbX0Xack/kmHsyMGJZAMJ

   "While a use case exists for provisioning TLS client certificates for authentication,
    such a use case is inherently user-hostile for usability, and represents an authentication
    scheme that does not work well for the web"

> Chrome continues to support client certs.

I know.

 > To the extent that <keygen> has overlap with client cert usecases, this is only about
 > provision, not use. And there are many ways to provision certs.

Not in a reasonable fashion for the use-cases they are _currently_ used for.

There are few motives for using certificates if they only work for one domain
except for enterprises.


> Provision directly from an origin to a non-origin-based keystore indeed raises privacy concerns.

Since keygen only generates random key data I don't understand what the privacy problem is.


>  > This position is (for example) in conflict with the eID (electronic ID) already used
>  > by millions of people in the EU.
>
> It's unclear to me how you've come to that view. Can you elaborate?

See first answer.


>  > If the problem was limited to <keygen> I'm sure it could and would be fixed.
>
> Fixing <keygen> is likely to cause it to stop doing the set of things may seem to want it to do.

Yes, because it all boils down to the fact that Google have downplayed/deprecated a since
20 years back establish use-case.

Anyway, I won't pursue this thread because it seems pointless; Google have already decided
that those who want use x.509 certificates (in the traditional way) should take the "App" path.
We are here talking about PKIs where for example China's will eventually reach more than 0.5 billion users.
Obviously on-line enrollment is a very important part of the plot.

The privacy and security concerns are out of proportion in the same way as FIDO's privacy
capabilities are greatly exaggerated (they can only be obtained in a laboratory setup).

Anders


>  > In all fairness, is worth mentioning that Microsoft have already removed their
>  > counterpart to <keygen> in their "Edge" browser.
>  >
>  > Anders
>  >
>  >
>  >
>  > > Perhaps it's worth trying to consider to following aspects separately:
>  >>
>  >>
>  >>   * The implementer consensus regarding <keygen>
>  >>   * Questions regarding the origin model and global modification of user systems without user interaction
>  >>   * User and developer needs for key generation and storage
>  >>
>  >>
>  >> Given the current proposal to deprecate <keygen> in Blink [1], it seems worth reiterating the broad consensus that <keygen>'s use of MD5 is fundamentally broken [2]. Some in the thread seem to misunderstand the impact of this brokenness, but rest assured, the only value a <keygen>-created challenge could provide is fundamentally suspect. This is in addition to long-standing objections by Microsoft that <keygen> isn't fit for purpose for other reasons [3]. Implementers have also identified core issues with <keygen>'s behavior that mean compatibility will suffer as issues are fixed.
>  >>
>  >> These concerns have reached a head with the proposal to deprecate. One might imagine repairing <keygen>, but this works against the extensibility principles the TAG encourages [4].
>  >>
>  >> A more extensible solution would be an API form of key generation. Interestingly, this now exists via Web Crypto (as was pointed out in the original Blink thread by Ryan [1]). These keys are not directly generated in the same key store used for client certificates, but page authors can work with generated keys, even allowing users to import them into keystores.
>  >>
>  >> Developers who want to persistent keys to the local system should acknowledge that this is an operation that lives outside the Same Origin Model. The inability to scope the use of keys added via <keygen> (via addition to the effective keychain) creates a major hole in our one workable security primitive. It's true that this isn't part of the <keygen> spec, but compatibility requirements have caused this to be true in practice. >From an architectural perspective, this alone should be enough to cause the TAG to recommend removal of <keygen> and replacement with a better, origin-scoped alternative.
>  >>
>  >> Lastly, I think it's important for us to take the need to generate keys seriously. We can do this without holding onto poorly designed and constructed features, however. I'd like to understand more deeply why key generation via Web Crypto isn't functional. Perhaps we can discuss that next week?
>  >>
>  >> Regards
>  >>
>  >> [1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack
>  >> [2] http://www.kb.cert.org/vuls/id/836068
>  >> [3] https://lists.w3.org/Archives/Public/public-html/2009Sep/0043.html
>  >> [4] https://extensiblewebmanifesto.org/
>  >>
>  >>
>  >> On Sat, Sep 5, 2015 at 5:05 AM, Henry Story <henry.story@co-operating.systems <mailto:henry.story@co-operating.systems <mailto:henry.story@co-operating.systems>>> wrote:
>  >>
>  >>
>  >>      > On 4 Sep 2015, at 14:54, Henry Story <henry.story@co-operating.systems> wrote:
>  >>      >
>  >>      >>
>  >>      >> On 2 Sep 2015, at 14:15, Wendy Seltzer <wseltzer@w3.org <mailto:wseltzer@w3.org> <mailto:wseltzer@w3.org <mailto:wseltzer@w3.org>>> wrote:
>  >>      >>
>  >>      >> On 09/02/2015 04:06 AM, Melvin Carvalho wrote:
>  >>      >>> On 1 September 2015 at 16:08, Tim Berners-Lee <timbl@w3.org <mailto:timbl@w3.org> <mailto:timbl@w3.org <mailto:timbl@w3.org>>> wrote:
>  >>      >>>
>  >>      >>>> Folks
>  >>      >>>>
>  >>      >>>> There is a strong move my Google chrome team followed by Firefox to remove
>  >>      >>>> the <keygen> tag from HTML5.   This has been done without an issue being
>  >>      >>>> raised in the WHATWG  or HTMLWG apparently.
>  >>      >>>>
>  >>      >>>> <keygen> is important because it allows authentication systems to be build
>  >>      >>>> in a distributed manner. It allows any Mom and Pop shop place to share
>  >>      >>>> public keys for people they trust.    For example, MIT uses it to create
>  >>      >>>> secure relationship with faculty and staff, and I use it for friends and
>  >>      >>>> family.
>  >>      >>>>
>  >>      >>>> Public key asymmetric crypto is generally so much stronger than the
>  >>      >>>> password-based authentication.  It requires certificate management code to
>  >>      >>>> be written.
>  >>      >>>>
>  >>      >>>
>  >>      >>> IMHO we need an area of the browser under a user's control
>  >>      >>
>  >>      >> That seems like a different, and more interesting requirement than
>  >>      >> "keygen."
>  >>      >>
>  >>      >> Keygen was a poorly designed, inconsistently implemented feature, that
>  >>      >> many sophisticated users and developers found confusing. If we can
>  >>      >> instead define what features we want to be able to build, and what they
>  >>      >> depend on that's not provided by WebCrypto, and think about how we can
>  >>      >> enable users to access these features without opening themselves up to
>  >>      >> be phished or tracked, that feels like a more productive avenue for
>  >>      >> discussion than "bring back keygen".
>  >>      >
>  >>      > I think this is much too harsh on keygen btw. What is happening may be
>  >>      > that the documentation in the HTML5 was not good enough at explaining how
>  >>      > it worked. After a discussion on the WhatWG where one key argument against
>  >>      > keygen turned out that it was insecure because of its use of MD5, and after an off
>  >>      > list pointer to what the aleged reason of the problem was I wrote a detailed
>  >>      > response to the WHATWG showing that MD5 has no effect on keygen, and
>  >>      > ansuggesting that improved wording of the spec may help diffuse this
>  >>      > misunderstanding.
>  >>      >
>  >>      > https://github.com/whatwg/html/issues/102
>  >>      >
>  >>      > This did not stop the issue being closed within 15 minutes of my opening the
>  >>      > issue. ( and I seem to be filterd now on the WHATWG mailing list ).
>  >>
>  >>     So yes the mail that referenced issue 102 linked to above was filtered and
>  >>     censored for reasons of "security". This is surreal. A decision for removing
>  >>     strong security from browsers is made on a mistaken understanding of how the
>  >>     feature works. Then showing that the alleged security hole is illusory is
>  >>     considered a potential security risk and is filtered. Here is the link to the
>  >>     mail:
>  >>
>  >> https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Sep/0027.html
>  >>
>  >>     I am sorry to mention it, but how can this not make one think of secret courts using secret evidence ( and even secret laws ) ? This requires everyone to completely trust the cryptography experts and makes it then impossible to bring to light the implicit assumptions that are guiding their thinking, and that would perhaps when brought out in the open allow new possibilities to emerge.
>  >>
>  >>     Henry
>  >>
>  >>     PS. I verified my position on the irrelevance of MD5 in keygen generated spkac with cryptography experts from openssl. It would be nice if some cryptography experts could at least confirm this here.
>  >>
>  >>      >
>  >>      > Henry
>  >>      >
>  >>      >
>  >>      >>
>  >>      >> --Wendy
>  >>      >>
>  >>      >>
>  >>      >> --
>  >>      >> Wendy Seltzer -- wseltzer@w3.org <mailto:wseltzer@w3.org> <mailto:wseltzer@w3.org <mailto:wseltzer@w3.org>> +1.617.715.4883 <tel:%2B1.617.715.4883> <tel:%2B1.617.715.4883> (office)
>  >>
>  >>      >> Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
>  >>      >> http://wendy.seltzer.org/ +1.617.863.0613 <tel:%2B1.617.863.0613> <tel:%2B1.617.863.0613> (mobile)
>  >>
>  >>
>  >>
>  >
>

Received on Saturday, 12 September 2015 08:05:05 UTC