Hi, 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 securely. 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 stores. Simon
Attachment:
signature.asc
Description: OpenPGP digital signature