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

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


On 15.10.2015 22:04, Olaf Titz wrote:

> Why that way? Reading an argument that the browser is "secure
> infrastructure" and "audited code" makes me shudder (sorry).

There is a standard for security modules, which can be dedicated
hardware, or the fallback "software security module". These have been
audited, and the interface is designed so that it can be implemented

The interface standard specifies that the security module is responsible
for key generation, because in the case of a hardware module, there is
no way the key could be generated anywhere else; the generated key then
takes up a key slot on the device, a certificate signing request for
that key can be generated from that, and once the certificate is
created, it can be stored to a certificate slot in the security module.

The main problem Mozilla has with this approach is that they never had a
proper user interface for key management, so key slots are invisible to
the user, and the UI presents keys as part of the user's certificates --
so specifically keys cannot be deleted or retained independently.

The current API to interface the security module from HTML/HTTP consists of

1. a nonstandard HTML tag that resolves to a form element,
2. an implicit convention that keys generated during form submission are
retained in the security module, even if inaccessible otherwise
3. a MIME handler that handles incoming certificates by searching the
certificate storage for a matching key, storing the certificate in a
certificate slot, and binding the key slot to the certificate slot.

This is basically a good implementation, as it does not require any
scripting to work, is easy to use and difficult to get wrong, but it is
a crude hack nonetheless, and I can see the desire to get rid of it.

The question is what will replace it.

Exposing the security module interface to JavaScript could work, as it
would allow a more sophisticated UI to be developed outside the secure
core; but that still introduces a new dependency on JavaScript.

Wrapping the security module interface to present an interface similar
to the certificate management dialog would *not* work, because it breaks
smartcards and really any enrollment process where the key material is
hidden from the user interface, as it should be in a well-defined system.

I could certainly see gpg-agent providing a security module at some
point, allowing reuse of OpenPGP keys as X.509 keys or vice versa, and
generally unifying key handling in a single place.

> I'd rather
> prefer a specialized app for that purpose, which is small, self-contained
> and _can_ be audited.

As said, that already exists. This app does not even do any parsing of
the command line or files, but expects to be given input in an easily
verifiable format that can be verified on the fly by a generated parser,
further minimizing potential for errors. Fully functional
implementations of this self-contained module exist on smartcards.

> 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!)

That is precisely our concern. The current implementation is a nasty
hack, but it does allow key generation without JavaScript, and
integrates smartcards.

The entire reason we're having this debate is that it would be bad to
lose existing functionality as people may have come to depend on it; on
the other hand, it would be good to have a standard that is not
implementation dependent, and ideally allows better control over key
storage, for example integrating the Windows and MacOS integrated key


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: