On Wed, 2012-07-25 at 08:33 +0200, Anders Rundgren wrote: > I think the lack of progress [*] here has a lot to do with the fact that > there's really nothing to gather around. Making security solutions > for security-conscious people is probably quite fun but since this > only addresses a tiny fraction of the market the urge for consolidation > seems pretty limited.
I think that's a cop-out, and it's not even true for the specific case I'm focusing on first. I care about *CA* certs for now, not private keys. All I want to do, to start with, is have a coherent way of managing trusted CAs across the system, and across all applications used by a given user. The NSS shared system database *almost* gives us that... or would if anyone actually used it properly. That *is* something that all sensible Linux distributions will care about doing; it's not just about finding security-conscious end-users. Debian has its 'update-ca-certificates' tool which addresses *part* of the problem, but only for SSL libraries which use flat PEM files; it doesn't affect NSS users. So you can do 'apt-get install cacert-ca-certificates' and have it work in *some* applications... but not all. Perhaps not even the majority. And it still doesn't handle the case of a *user's* own trusted CAs. > The "Gold Standard" for Internet-payments is still after more than > 15 years with on-line banking using Card Numbers and CCVs printed > in clear on plastic cards. Banks are irrelevant. Most of them don't even bother to *sign* their outbound email, thus actively *training* their customers to succumb to phishing fraud. They are not what we're talking about here. It's too early in the day, and I'm too sober, to be contemplating the horrendous and egregious stupidity of the banking system. Try me some other time. > IMO, the only way to change this would be to introduce secure key-store > primitives in the CPU; then there would finally be something to focus on! Maybe not in the CPU, but the TPM was close enough. And nobody bothered to use it. But we digress. Hardware key storage *is* possible, is relatively standardised through PKCS#11, and initiatives like p11-kit and http://tools.ietf.org/html/draft-pechanec-pkcs11uri-06 are making it easier to use. On modern Linux distributions we even have GUI tools for managing tokens and selecting keys from them (see seahorse, and for UI developers http://developer.gnome.org/gcr/3.4/ ). That isn't the problem I'm trying to solve today. > *] For the *NIX community it might be reassuring to know that not even > the latest Android- and iOS-releases support deployment of two-factor > authentication tokens. Nobody (AFAIK at least) use the built-in > enrollment solutions for mobile banking As I understand it, PKCS#11 token support was actually *removed* from the Keychain in the latest versions of OSX, and is now a third-party add-on? -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
