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

Tue Jan 19 09:26:31 PST 2010

Hello Henry,

Story Henry wrote:
>> 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. 

As far as I understand, <keygen> was, if not officially deprecated, at 
least not recommended in Firefox, since the introduction of 
generateCRMFRequest.

I wouldn't say <keygen> is greatly implemented, even in Firefox.
Consider the following HTML document:

<html>
<head>
<script type="text/javascript">
function writeTagName() {
   document.getElementById("title").appendChild(
       document.createTextNode(document.getElementById("keygen").tagName));
}
</script>
</head>
<body onload="writeTagName()">
<h1 id="title"></h1><keygen id="keygen" />
</body>
</html>

In Firefox, this prints "SELECT": <keygen> is transformed on the fly 
into <select>, which breaks DOM usage. This is something that Opera and 
Safari don't do.

Even across Firefox, Opera and Safari, the behaviour of keygen isn't 
uniform.
The choice of "High grade" and "Low grade" is left to the appreciation 
of Firefox, whereas a proper CA would certainly require a bit more 
precision. In contrast, Opera offers a much longer list of key sizes, 
defaulting somewhere around 1500 bits (I don't have Opera on this machine).

One of the other points (which I think I've seen mentioned on this 
mailing list) is that <keygen> doesn't really fit as a form element. 
There's a number of parameters that can be set to generate a pair of 
keys. Why assume that the keysize (and only the keysize) is to be chosen 
by the user while all the others are set within the page? It might make 
sense, in some circumstances to have it all fixed on the page (by the 
service provider) or to let the user also chose whether to use RSA or 
RSA for example. (Along the same argument, why assume 
'md5WithRSAEncryption' and not SHA-1?)
It just looks like it doesn't belong in a form this way.

I'd go even further that this in fact: why always *generate* a key-pair?
Whether it's used for an PKIX CA or FOAF+SSL, why not let the option to 
use an existing pair of key available in whatever key store the browser 
has access to? (That would in fact be quite useful for FOAF+SSL 
applications.)
If I send a CSR to a CA for signing, does it (even can it) know where 
those keys have been generated? Perhaps it might make more sense in some 
cases to re-use an existing pair of keys available in a smart-card or 
even some software key store.

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

The problem is that there's only so much one can do declaratively in 
this field, precisely because some of this involves the security 
architecture of the overall system in which the browser runs, which by 
essence will have parts that do not belong within the browser, or at 
least ought to be outside the direct reach of what HTML can do (Windows 
certificate store, Apple Keychain...).

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

Well, I haven't followed the complete history of generateCRMFRequest, 
but there must be a reason why it was invented as a successor of 
<keygen>. I have no idea what the ratio of modern CAs that still use 
<keygen> vs. those that use generateCRMFRequest is. The one I use 
regularly seems to use generateCRMFRequest.

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

As Adrian Bateman from Microsoft said in [5]: "We are prepared to 
consider creating common APIs that allow interoperability across 
browsers and also address customers' real needs either in a future 
version of the spec or as a separate work item."

Perhaps that's the way to go, having a common API similar to what's done 
for XMLHttpRequest.

While I must admit it took me a while to figure out how to write [6] for 
CertEnroll.dll, this wasn't infeasible. Perhaps a similar example on 
MSDN would have helped.

The change you're talking about isn't just a change of DLL, it's a more 
fundamental change in the handling of certificate in the overall 
infrastructure of the operating system. (Yes, a common API with sensible 
default values and what needs to be OS-specific customised there would 
help.)

You could say that Safari handles both <keygen> and the OSX's Keychain 
infrastructure, but this seems to come at the expense of certificates 
being almost unusable in the current implementation [7].

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

I think it probably shouldn't be. Having a separate effort along the 
lines of that for XMLHttpRequest, involving CA implementors and security 
experts sounds like a better plan, rather than crippling HTML 5 with 
something that not quite fit for purpose.

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

I think you completely misunderstand the XEnroll vs. CertEnroll issue. 
This isn't about "binaries that tie people to their platform", this is 
about a change of API that reflects new capabilities offered by the 
platforms. The introduction of more flexibility in CertEnroll may 
reflect some actual user requirements, rather than an evil will to tie 
users to the platform. Again, according to [5], MS doesn't seem against 
a standardisation effort in that domain.

(Talking about API evolution, as far as FOAF+SSL is concerned, if 
CertEnroll was able to generated a suitable key-pair produce a 
self-signed certificate with the attributes we want, that would be a 
more convenient way than the <keygen>/pseudo-CA approach.)

Whilst, like many others, I have expressed frustration with Internet 
Explorer's own interpretation of various web standards, I can't really 
blame MS on this one. I mostly agree with Adrian Bateman's comments in 
[5], in fact.
You had written down the ActiveX mechanism as a "hack" for MSIE on the 
ESW wiki page before I edited it, but frankly, I'd consider Netscape's 
<keygen> to be as much as a hack, just made by IE's competitor. I might 
get it wrong, but considering the earliest mention of PKCS#10 I've seen 
dates from 1993 [8] and the earliest mention of <keygen> seems to be in 
the 1998 Netscape doc [9], time by which PKCS#10 was in an RFC [10], 
perhaps Netscape could have followed that standard at the time too 
instead of using SPKAC. I'm not aware of the full history of these 
standards, but I find it hard to make a judgement on who's right and 
who's wrong here.
If IE doesn't support <keygen>, it would just be too easy to be anti-MS 
and claim "they don't support standards as usual" once this <keygen> is 
in HTML 5.

I'm quite happy to have <keygen> now, since it helps demonstrate our 
FOAF+SSL work works across browsers, but I have reservations regarding 
its appropriateness as a general certificate request tool for the HTML 
of the future.

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

[5] http://lists.w3.org/Archives/Public/public-html/2009Sep/0043.html
[6] 
http://github.com/harbulot/keygenapp/blob/master/samplewebapp/src/main/webapp/crosskeygen.js
[7] http://lists.apple.com/archives/apple-cdsa/2009/Apr/msg00041.html
[8] http://www.rsa.com/rsalabs/node.asp?id=2132
[9] 
http://devedge-temp.mozilla.org/library/manuals/1998/htmlguide/tags10.html#1615503
[10] http://tools.ietf.org/html/rfc2314