[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help needed talking to upstream browser developers about Debian SSO

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

Attachment: signature.asc
Description: OpenPGP digital signature


--- End Message ---

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: