Hi, On 15.10.2015 18:08, Thijs Kinkhorst wrote:
> While we make use of that tag (e.g. in the TERENA Personal Certificate > Service that some academics may know), the browser developers may have a > point that there are other ways to implement the enrolment step. People > can generate a certificate locally with openssl or other tools, through > HTML5 or JS. I've posted a statement to the list, but it got stuck in moderation. Basically, the main difficulty is that any enrollment process would need to be simple for users to follow, ideally not require additional software even on Windows, and not require security compromises. From what I've gathered, they want to deprecate storing private keys without associated certificates, which would be really bad. There is an audited infrastructure for key generation and storage, including smartcard support, and adding a requirement that keys may only be added together with a certificate would lead to a situation where I'd have to generate a private key outside the secure infrastructure and keep it outside until my certificate is ready, at which point I can finally transfer it to the audited code for safekeeping. This would also mean that key generation would have to happen outside the audited code. This opens a lot of potential to get things wrong somewhere and compromise system security because of it. If I can continue to generate a key inside the crypto module and leave it there until a certificate becomes available to attach it to, I don't see a huge problem with deprecating the existing API, given that it is browser specific anyway (although this introduces JavaScript as an additional dependency into the enrollment process, where we had no need for a Turing-complete language before). > Especially for tech-savvy use cases the in-browser generation should not > be essential. So I'm not sure that Debian would have a strong point in > this discussion. Neither Debian's users nor non-packaging contributors are necessarily tech-savvy -- and I don't think knowledge of the intricacies of OpenSSL should be a requirement either, so I think this weakens our position much. > I'm emailing to check if indeed you're referring only to removal of the > <keygen> tag, not the entire X.509 client certificate support from > browsers. If the latter discussions are happening, I'd love a link to > those. I'm not sure there is much discussion going on at all, at least I can't see it in their public archives. For your delectation and amusement, I've attached the mail I sent. Simon
--- Begin Message ---Hi, sorry for warming up this topic, I've just been pointed here. Am Donnerstag, 30. Juli 2015 01:35:49 UTC+2 schrieb David Keeler: > Ryan Sleevi recently announced the pre-intention to deprecate and > eventually remove support for the <keygen> element and special-case > handling of the application/x-x509-*-cert MIME types from the blink > platform (i.e. Chrome). [...] > I therefore propose we follow suit and begin the process of deprecating > and removing these features. The intention of this post is to begin a > discussion to determine the feasibility of doing so. A common setup I build for small companies and organizations uses a simple local CA and a web page containing a form with a <keygen> and a password. Enrollment works by 1. Phone call or physical presence of applicant, CA administrator authenticates applicant. 2. Administrator starts enrollment process, one time password in generated and given to applicant 3. Applicant uses the <keygen> and the one time password to send a signing request to the CA server 4. CA server replies with new client certificate For simple setups, this is a really easy way to deploy certificates -- really, the hardest part is copying the certificate from Firefox to Thunderbird if it is to be used for SMTP relay authentication as well. Removing <keygen> obviously breaks this workflow, but I think it can be replaced with JavaScript -- this adds an extra step for organizations that do not enable JS by default, but I think that would be manageable. In any case, however the key store would still need to be able to store keys that are not associated with a certificate yet, or we're losing key generation capability completely (well, theoretically we could generate keys in JS and keep the private key material in DOM storage until the certificate is ready, but I doubt anyone wants that). Is there still an API left that allows me to easily deploy client certificates in such a setting? Simon
signature.asc
Description: OpenPGP digital signature
--- End Message ---
signature.asc
Description: OpenPGP digital signature
