[whatwg] The <keygen> element

On Sun, 12 Apr 2009, Nelson B Bolyard wrote:
> Yngve Nysaeter Pettersen wrote:
> >>
> >> The default format, introduced by Netscape, is the SPKAC format, see 
> >> the above link, and includes the public key and the Keygen challenge 
> >> attribute, and is signed by the private key.
> >>
> >> The actual standardized format is PKCS #10, in form a more advanced 
> >> and flexible version of SPKAC (it is the format used to request 
> >> certificates for webservers), and I am not sure if this is now used 
> >> by default in some clients. In Opera this format can be selected by 
> >> using a type="pkcs10" attribute in the keygen tag.
> 
> That's an interesting idea.  But PKCS#10 is like a self-signed 
> certificate. It has a full-blown X.500 Directory Name in it, just like a 
> certificate, and the KEYGEN tag doesn't provide the input for that.  I 
> guess the browser could prompt the user, perhaps using a form something 
> like:
> 
> http://mxr.mozilla.org/security/source/security/nss/cmd/certcgi/main.html
> 
> But heaven help the user to fill that in! :-/
> 
> Also like a real certificate, a PKCS#10 certificate request may have 
> extensions.  This is the way that a cert requester requests that 
> particular extensions be put into his cert.  Again, the keygen tag has 
> no way of specifying these.  But the browser could use a form like:
> 
> http://mxr.mozilla.org/security/source/security/nss/cmd/certcgi/stnd_ext_form.html
> 
> There's one other problem with PKCS#10 (and SPKAC too) that I mentioned 
> before: it only works with public keys that can be used for signing. If 
> you have an "encryption only" key, you can't request a cert for it with 
> PKCS#10 because doing so requires generating a signature with it.
> 
> To solve these and other problems, an alternative protocol named CRMF 
> (the "Certificate Request Message Format") was created.  Mozilla 
> supports that with the crypto.generateCRMFRequest method.  If we're 
> really going to standardize something like a keygen tag, we should 
> design it to be able to do the things that can be done with 
> crypto.generateCRMFRequest, too. That should not be difficult.  See
> 
> https://developer.mozilla.org/En/JavaScript_crypto/GenerateCRMFRequest

I agree that standardising this would be a good idea; I recommend 
approaching the public-webapps WG at the W3C to do this.


> > I haven't added this, because right now the only browser I could find 
> > which supports more than one algorithm is Firefox, and it just has two 
> > (RSA and ECs, as far as I could tell).
> 
> And DSA.

The DSA code doesn't appear to be hooked up.


> > I haven't added ECs to HTML5 since I couldn't find any documentation 
> > on it (the above isn't updated yet). Also, I omitted DSA support which 
> > is claimed to be supported on the above page, because as far as I can 
> > tell nobody actually supports it.
> 
> It's not popular in the commercial world, but I think a certain 
> government still likes it. :)

I'm definitely not adding features to HTML5 for a single vendor, even if 
that vendor has an army.


> Which is more likely to be adopted as a cross browser standard? A new 
> html tag? or a new JavaScript object/method?

It would presumably depend on how it is to be used. If it's for form 
submission, then an element would make more sense. If it's for 
applications, then an API would be better.


On Mon, 13 Apr 2009, Anders Rundgren wrote:
> 
> On-line provisioning of PKI is rather little used because the big users 
> of PKI (banks and governments), prefer using physical token distribution 
> like for PIV/CAC/eID.
> 
> What those large users have not bothered much with to date is how they 
> are going to use PKI in the most popular IT-device there is, the mobile 
> phone. IMHO the availability of trusted HW at a very small premium 
> motivates a completely new key-generation scheme, presumably based on 
> TPM 1.2 or enhanced TPM-schemes.
> 
> Regarding the <keygen> tag itself, I personally don't see that such 
> mechanisms need any explicit links to an HTML page, at least none of the 
> alternatives including generateCRMFRequest and CertEnroll do, they are 
> just APIs.
> 
> To give you an indication of that key-generation standards is not an 
> easy task, IETF's KEYPROV has been running for almost three years!
> 
> My own contribution to this field, KeyGen2, requires not less than six 
> message rounds compared to <keygen>'s three.  Take a peek at the [beta] 
> XML Schema at: http://keycenter.webpki.org/resources in case you are 
> interested....

Thanks for the info!


On Fri, 17 Apr 2009, Anders Rundgren wrote:
>
> I understand what you are saying, but without a "buy-in" from Microsoft 
> there is little point in elevating <keygen> to some kind of standard 
> since it will fail in the majority of cases.

Even if IE's market share stops dropping (which it shows no signs of 
doing), I believe that getting interop amongst three browser vendors is an 
important enough goal that it is still worth standardising even if 
Microsoft never implement <keygen>.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 3 June 2009 15:31:02 UTC