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

On 2015-09 -12, at 02:20, Alex Russell <slightlyoff@google.com> wrote:

> 
> Hi all,
> 
> Apologies for the late response to this thread. I'm not sure that the conversation has created much mutual understanding. 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].


Here they are from [3] pasted in as a quote:

> <<<<<
> 1. <keygen> typically requires the user to select the appropriate key length from a list. Most users are not equipped to make this decision. In general, the server should be able to indicate what type of key pair it wants including acceptable key length, algorithm, etc. For example, RSA 512 may not be something a bank wants to deal with. <keygen> doesn't support this.

Agreed. Though the browser should not support short key lengths anyway.  Though in practice the web page says "bigger keys are better." 

> 2. Creating the key pair (with <keygen>) and then having a certificate returned from the server to be installed on the client appear to the user as two separate actions. This is a poor user experience and there is no way to avoid this with <keygen>. A better approach would have the key submission and certificate response integrated into the same control.


May be a good  idea yes.  The problem at the moment people tell me is that you don't get an event you can listen for when the point where the user has now got the cert.

> 3. <keygen> does not provide a mechanism for managing certificate expiry. This forces the user to repeat the initial key creation process whenever certificates expire.

Yes, you have to use you existing identity and create a new key pair for it.
Mind you already the certificate management could flag it when the user has certs which are about to expire instead of when they have.

> 
> 4. The format used by <keygen> is not standard and only provides a subset of already established protocols like PKCS10 (
> http://tools.ietf.org/html/rfc2986), CMC (http://tools.ietf.org/html/rfc5272), and CRMF (http://tools.ietf.org/html/rfc4211
> ). This prevents <keygen> from supporting non-RSA based certificates, extensions for additional client information, and key escrow.
> >>>>>


Well it seems to work within a scope which is useful?
Would it be a good idea to extend it?  I can imagine that.

All in all, a list of issue about improving keygen functionality.   You can read it: Microsoft want a better keygen.  But not reasons to abandon keygen, just to fix it. Yes, we could redesign a better way of doing the same thing.
But while Microsoft seem here to be "This isn't as good a way as we can think of for going that", the Chrome team seem to be saying "The whole reason for keygen, to allow the user to mind their own key pair in a global context, is considered bad".

> Implementers have also identified core issues with <keygen>'s behavior that mean compatibility will suffer as issues are fixed.

I would like an argument tree to be presented.  We have seen arguments presented that keygen can in fact do things like provision parts of the mobile phone system and should not -- well, fine, turn those bits off.

> 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]. 

Extensibility principles do not require that when fixing a broken feature you should throw it out especially when no alternative exists.

The Extensible Web principles in general are that within the browser everything should be replaceable by developer javascript, and I think there is a good case herethat the opposite is the case.  The security of the system requires a bowser-controlled non-developer-fakable secure UI.  Just as the happy green https splash is not available to the developer via CSS, so the cert management has to be a layer clearly separate from the web page.

> 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.

Page authors will have access then to the user's private keys?  Yes anyone can make a system where I in the web page or in the server mint you a nice key pair and I send it to you but that defaults the whole purpose of PRIVATE key crypto. Or did you mean that the private keys would be indeed stored by the OS/Browser in a secret way -- in which case you are reinventing keygen.

> 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.


The webid use-cases for keygen include one in which an identity provider provides me with a public identity which many different origins can recognize, and use in their authorization systems.  This is not the same origin model.   The requirement is that the user ha a well-defined public identity which is re-usable in different origins.  Think about the logic of a big site being spread between different websites and pulled together in the browser javascript.    That isn't really the same origin model.  Maybe the underlying problem with keygen detractors really don't want to see use-cases like that work?

> 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?

I think the core answer is that anything generated by web crypto is hostage to the web page developer.  Passwords and keys have to be stored in a space which the developer does not have access to.  If web-crypto acquires keygen functionality, to have the browser/os generate a new key pair and store the private key securely away form anyone except the user, then this would be fine.   We all recognize that keygen is a pain to use (though maybe not as much as pain as MS-specific ActiveX API).    Moving to a nice new JS API would be great so long as the browser (delegating through the OS to an extent) managed the keys in a way the web page developer could not pry into or fake.    Sure lets introduce that and use instead of keygen in new browsers, but keep an improved keygen for an overlap time.

> 
> 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> 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> wrote:
> >>
> >> On 09/02/2015 04:06 AM, Melvin Carvalho wrote:
> >>> On 1 September 2015 at 16:08, Tim Berners-Lee <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 +1.617.715.4883 (office)
> >> Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
> >> http://wendy.seltzer.org/        +1.617.863.0613 (mobile)
> 
> 
>

Received on Saturday, 12 September 2015 14:39:09 UTC