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).
Olaf
Reply to: