W3C home > Mailing lists > Public > public-html@w3.org > September 2009

RE: <keygen> element

From: Adrian Bateman <adrianba@microsoft.com>
Date: Tue, 8 Sep 2009 20:29:40 +0000
To: Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>, "Henri Sivonen" <hsivonen@iki.fi>
CC: HTML WG <public-html@w3.org>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB038AE8@TK5EX14MBXC138.redmond.corp.microsoft.com>
On Monday, September 07, 2009 5:59 PM, Jonas Sicking wrote:
> On Sat, Sep 5, 2009 at 9:22 PM, Maciej Stachowiak<mjs@apple.com> wrote:
> > What marking it obsolete would do is result in a conformance error on
> > every page using it - this seems orthogonal to Microsoft's concern,
> > and at least to me it seems unhelpful. But perhaps you have some
> > different concerns that would be addressed by making keygen obsolete.
> 
> My thinking was that marking it obsolete or deprecated would give
> microsoft a pretty good story to their customers for not implementing it.
> 
> However marking it optional would be even more explicit so that seems
> good to me.

I don't think obsolete or deprecated yet still required really helps us. Our
goal is a spec that helps us all be interoperable. Optional would be a
possibility but I worry about complicating this spec with features of a
different status. I'd personally prefer the spec to stick to things that
are requirements (even if obsolete) for all user agents.

On Monday, September 07, 2009 5:26 AM, Henri Sivonen wrote:
> It seems to me that the least damaging solution to avoiding requiring
> things that a vendor has vetoed would be keeping <keygen> conforming and
> in the HTML5 spec but making implementing it optional in the sense that
> it must parse the same way in all UAs but whether it on layers above the
> parser acts as HTMLKeygenElement or as HTMLUnknownElement is up to the
> implementation.

I'm not sure being in the spec or defined elsewhere affects this since all
unknown elements should parse in the same way in a conforming UA.

On Sunday, September 06, 2009 7:06 PM, Maciej Stachowiak wrote:
> If we had a superior cross-browser solution ready, then obsoleting would
> undoubtedly be the right way to go. I hope Mozilla and Microsoft strongly
> consider making some proposals in this area, since they have the
> experience of deploying extended crypto APIs in the browser. I can get
> Apple security experts to review proposed APIs, but we're do not have the
> expertise or bandwidth to design a brand new API from scratch.

One of the problems with <keygen> is that an API is insufficient to satisfy
the requirements for its use case. When Netscape created <keygen>, it was
part of an overall protocol and it just so happened that some of the protocol
was surfaced through an element behaviour.

The current work in producing an interoperable solution for this problem is
being done with some kind of web-based service protocol, perhaps a standard
Web Service. I am waiting for more feedback from our security team about the
status of this. I think that a JavaScript API over this service model
would be a reasonable approach once a common protocol is agreed.

Cheers,

Adrian.
Received on Tuesday, 8 September 2009 20:50:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:48 GMT