On Thu, Mar 26, 2009 at 6:12 PM, Eddy Nigg <eddy_n...@startcom.org> wrote: > On 03/27/2009 03:58 AM, Ian G: >> >> Encryption would give more privacy of emails, where otherwise there was >> less privacy. >> > > S/MIME encryption without assuring the email address is security theater. > What you suggest would be even counter-productive since it would give the > wrong impression of encryption (security) without actually being able to do > so. There is nothing different as with web sites, hence Mozilla has such a > requirement for S/MIME certificates in its CA Policy. It's there fore a > reason, not because it's fun imposing requirements on CAs.
I'd rather have security theater -- where everyone gets practice playing their role -- than the all-or-nothing lack of security we have now. > What I thought interesting at the initial idea is to cut certain steps short > without compromising the basic security of the users. I think you'd have to > make your mind up what's more important - improvements with the basic > security requirements taken care of or perhaps no improvement at all. My thought was designed to reduce the barrier to entry to the CA-managed PKI. (Class 0: no verification performed, SSC. Class 1: CA has verified that the holder of the private key that corresponds to the public key in the certificate can read emails sent to the email address. Eddy, what are the definitions of Class 2 and Class 3 that Startcom applies, as relate to its S/MIME offerings?) By the way, I'm *absolutely disgusted* by seeing the CN field be "Startcom Free Certificate Member". If software is supposed to display the CN, then the email address needs to be in the CN -- regardless of what PKIX specifies. (I would actually go so far as to suggest making the self-signed certificates have the email address in the CN, Ian.) It makes it DAMNABLY difficult to determine whether I have a certificate for a given email address when I have some umpteen number of subjects, all with the same Common Name but different Emails, when I have to go into each one individually. "Ease of entry, ease of use, minimal day-to-day administration", people. This has to be the mantra. Rather than focusing on the Assumptions that the CAs and Mozilla and everyone have already made, let's try looking at it from the user experience. We have a decade and a half of experience now. Let's actually *use* it. Let's try figuring out what can be salvaged from the current system, what can be improved, and what should be scrapped and replaced with something that does the job in a more simple manner. -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
