Re: removing keygen from HTML

On Mon, May 30, 2016 at 6:36 AM, Graham Leggett <minfrin@sharp.fm> wrote:

> On 30 May 2016, at 4:14 PM, Harry Halpin <hhalpin@ibiblio.org> wrote:
>
> > Some folks are using <keygen>, although I think everyone has been
> notified of the upcoming deprecation quite a while ago and so hopefully are
> preparing for a post-<keygen> world if they use client certs in the browser
> outside of TLS (such as for authentication). One deployment, MIT is working
> to moving to OpenID with Duo two-factor.
> >
> > It has been requested not to remove it until the replacement is ready,
> and I think WebAuthn fulfils the requirements in a way that is coherent
> with the Web Security Model.
>
> I urge the working group to engage the crypto community and let the crypto
> community decide on what is or isn’t a replacement for keygen. No “proxy
> auth” based system like OpenID is able to replace the capabilities of
> client certificates.
>

I think you are confusing authorization with authentication. Authorization
is done by OpenID. MIT uses two-factor authentication (mandatory by June
15), and will likely move to Web Authentication when the code is in
browsers. Any other legacy deployments of client certificates for
authentication should probably also start working on upgrading their
systems to use another authentication protocol. The argument for holding
till October is that by then the organizations using client certificates
for authentication could upgrade to the Web Authentication API.

The crypto community is already engaged in FIDO and Web Authentication and
the general work has gone through the peer review process (see publications
by Dirk Balfanz, etc.). Although if you find any more cryptographers or
security experts, it would be great if they would join the Working Group as
an Invited Experts.

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



>
> > Here's the WebAuthn schedule - so thus, one-factor cryptographic
> authentication should be working across most browsers later in the year, as
> early as October. So far, the Working Group has been moving very fast.
>
> I would also urge the working group to treat any attempt at rushing this
> issue with a significant amount of skepticism.
>


Note that the general scheme has been under development for several years
before the Working Group so the Web Authentication Working Group is not
rushing. The general scheme is used internally at Google and many other
large organizations, so it makes sense to make it more widely available.

        cheers,
             harry







>
> Regards,
> Graham
> —
>
>