[whatwg] [foaf-protocols] keygen substitute for Windows?

[Story Henry]

> Hello,
> 
> Apologies for the late participation on this topic. I've been working on 
> FOAF+SSL with Henry Story (who advocated a few months ago the 
> introduction of <keygen> in HTML 5 for this purpose).
> I've only just found the time to investigate the certificate generation 
> issue on Windows/Internet Explorer (using ActiveX, XEnroll and 
> CertEnroll). I've updated this wiki page accordingly: 
> 
> http://esw.w3.org/topic/foaf%2Bssl

Thanks for this great investigative work.

> 
> Whilst I'm very supportive of having a key-generation mechanism in the 
> browser, I'm now not entirely sure the <keygen> tag, at least as a 
> legacy of the Netscape <keygen> tag, is the correct approach.

I think that part of the html5 goals is to describe how browsers actually work, without going into endless debates about how they SHOULD work. Given that Netscape, Firefox, Opera and Safari implement the <keygen> tag - and have done so for a very long time - it seems quite reasonable to describe that behaviour in html5. 

Once this is described it is then possible to find ways either to extend on the current behaviour or to find ways to improve it. Until now this topic was only something a few people could discuss.

> More specifically:
> 
> 1. The more modern APIs (generateCRMFRequest [1] on Firefox or 
> CertEnroll/XEnroll on Internet Explorer [2]) appear to offer more 
> options in general, for example, where to store the private key, is it 
> exportable, etc. (I haven't looked in details, but I suspect it could be 
> envisaged to use some existing key material from a software store or 
> smartcard too, for example.)
> This raises the question as to whether a tag is sufficient or 
> appropriate to express what's required for a CA, or if an API (and more 
> programming) is required.

I think there should be a strong preference for declarative ways of doing things if possible, ie to use HTML tags. Moving over to javascript has always seemed to me to be breaking one foundational element of the web.

As proof of the advantage of this way of working: the keygen tag has functioned across browser generations without change (I think).

Microsoft's ActiveX component on the other hand (as I understand required the calling of a Windows specific binary technology! The naming of a dll. This meant that when they changed the dll code that was written for browsers also had to change!

http://msdn.microsoft.com/en-us/library/bb931379%28VS.85%29.aspx

[[
Prior to Windows Vista, the Certificate Enrollment Control was implemented in Xenroll.dll. The Xenroll.dll library has been removed from the operating system and replaced by CertEnroll.dll.]]

The web is described with no reference to CPU architecture. I am seriously against bringing such low level aspects into day to day web programming. 

> 
> 2. The SPKAC format seems to be a legacy format. It doesn't really allow 
> to convey much information that CAs would expect, unlike other formats 
> used by the more modern APIs [3][4]. Perhaps it would be better to use 
> one of the newer formats instead. This might break the compatibility 
> with the pre-HTML 5 use of <keygen> (maybe another name than <keygen> in 
> HTML5 would be better?).

Perhaps extensions to keygen would be an interesting idea. 
At least it is document now.

> 
> Of course, the other big question is whether it's worth trying to 
> standardise this <keygen> tag if there's no intent of support from major 
> browser vendors (I have IE in mind here).

There are 3 browser vendors that have implemented it. That is enough of a precedent to standardise. If one browser vendor requires people to use binaries that tie people to their platform, it seems that it is quite clear what the reasons for that may be, and those reasons have in the past been deemed legally condemnable by both US and EU courts. Let us rather assume that that vendor decided to pursue that activity due to lack of standardisation in this space. 

Henry

> 
> Best wishes,
> 
> Bruno.
> 
> 
> [1] https://developer.mozilla.org/en/GenerateCRMFRequest
> [2] http://msdn.microsoft.com/en-us/library/aa374863%28VS.85%29.aspx
> [3] http://tools.ietf.org/html/rfc2986
> [4] http://tools.ietf.org/html/rfc4211