>> Have you ever tried that phrase on consumers? They don't know what a >> CA is and I hope they never will.
>Ah, then apparently you hope consumers will never get certs. Maybe you are not familiar with consumer/citizen PKIs in the EU? They are mostly designed for on-line services. For such services you don't need any client-level CA support for EE-certs like you don't need VISA's license in order to use a VISA credit-card. It is enough to recognize the logo so you don't use your library card. Because it is a human-to-service operation where the service is usually fully automatic,. That is, consumers may know the brand of certificate but not the terms CA, trust anchors etc. In the EU it is called eID and that's about it. >Thanks for clarifying your position. This in not my "position", I'm merely trying to make people understand that even if S/MIME and on-line use PKI, their requirements are different. In the Mozilla camp these differences have not [yet] been acknowledged. >> Note. I'm not talking about S/MIME because S/MIME is a marginal technology >> that has no validity whatsoever in the consumer space. >Why do you keep saying that? A lot of people agree with me but they [usually] express it differently: http://middleware.internet2.edu/pki06/proceedings/hallam-baker-email_usability.ppt SSL and S/MIME were created a decade back or so. Server-side SSL is currently used by the entire Internet community while maybe 1% use signed e-mail and probably only 0.01% use encrypted e-mail. It is the latter thing which is the biggest problem. >Trolling? >Hoping to provoke NSS developers? >Trying to make friends in the mozilla community by belittling its capabilities? >Trying to persuade TBird users to stop using it? What could I possibly gain by doing that? It is good enough that very few governments and probably not a single bank use or intend to use S/MIME on *major* scale for *external communication*. Web-based services have compelling advantages such as: - No client to install - No encryption keys to backup or escrow - Interactive services are more useful than async e-mail - No encryption key lookup issues Due to this, it does not matter how much energy the Mozilla community put into the TBird S/MIME, it will not change the core issue which simply is "usability". Mozilla could rather spend this energy on on-line signatures because these are more in demand, at least in the EU. signText is not good enough. Secure e-mail in a G2C (Government to Citizen) has recently begun to be realized using web-based "mail-boxes" to which you login using client-SSL-auth. e-mail is used as a notification option. Encryption is for free. Who could ask for more? I know that the US government loves S/MIME but OTOH after a decade of Fed-PKIing you still can't send an encrypted e-mail to a government agency like IRS, and it is really the S/MIME.*architecture* that is the culprit. My "I hate S/MIME" rant: It is really the security architecture of e-mail, the extremely hard-to-deploy S/MIME mechanism that is the primary reason to why our mail-boxed are flooded with spam, phishing and viruses. If the people who created secure e-mail had understood the difference between a community and the internet, they would have designed a system that as a minimum would secure messages at the mail-server level. This is not end-to-end security but it is affordable, implementable and scalable. Consequently the financial sector only use such solutions, otherwise international and cross-bank payments would still be manual. Using such a scheme encryption and message signing becomes default. Anders _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
