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

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

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

Let's look at this use-case the other way around. What is missing is a
simple enrollment application which does noting but
- (optionally) obtain policy parameters from a CA[1]
- generate a private key 
- generating a cert request
- submit that cert request to the CA[2]
- package a received cert along with the private key into a PKCS12 container
Steps [1] and [2] would need a standardized protocol (not HTML forms).

Why that way? Reading an argument that the browser is "secure
infrastructure" and "audited code" makes me shudder (sorry).  I'd rather
prefer a specialized app for that purpose, which is small, self-contained
and _can_ be audited.  Not another key-generation-bug or
insertion-of-malicious-javascript disaster waiting around the corner (for
the latter reason, nobody should ever do key generation via a web page which
requires Javascript, anyway!)

So while not knowing the whole discussion at all, I can very easily see a
security argument for deprecating browser-based key generation.  The
downside is that it does need a new application which (to my knowledge)
isn't there already.  But the building blocks are there (I once wrote a
self-signed-certificate generator, took me at most 20 lines of Java plus
another 100 or so lines for the GUI).


Reply to: