- From: Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk>
- Date: Fri, 15 Jan 2010 16:59:01 +0000
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 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. 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. 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?). 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). 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
Received on Friday, 15 January 2010 08:59:01 UTC