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

2015-10-17 Thread Simon Richter
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

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

2015-10-15 Thread Thijs Kinkhorst
Hi Enrico, On Sun, October 11, 2015 20:50, Enrico Zini wrote: > However, there is discussion in the Chrome[5] and Mozilla[6] communities > about deprecating client certificate authentication. In those threads, > > I don't quite mind if is removed, as long as there would be a > replacement that

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

2015-10-15 Thread Olaf Titz
> 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

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

2015-10-15 Thread Simon Richter
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

Help needed talking to upstream browser developers about Debian SSO

2015-10-11 Thread Enrico Zini
Hello, I need help to make our SSO use case for client certificates known in the upstream browser development communities. Here is the story. At DebConf we deployed a new experimental single signon system based on ssl client certificates[1], and it works quite nicely. In particular, it allows