On 2009-06-21 03:24 PDT, Ian G wrote: > On 19/6/09 15:36, Jean-Marc Desperrier wrote: >> Nelson B Bolyard wrote: >>> if you send an encrypted message to someone from whom you have never >>> received a signed S/MIME message, you will use weak encryption. > > Does this assume LDAP for acquiring the certificate without a signed > S/MIME message? (So it is only relevant in corporate setting?)
No. There are many ways to get a cert for an email correspondent. There is only one way to get that correspondent's email capabilities in a form that Mozilla mail clients can understand, and that is to receive a signed email. >> Thank you for this useful description. >> >> I feel it would make sense to open a bug to change this default. That would be bug 84213, 8 years old this month. >> Rational : If someone went the hassle of doing everything it requires >> to send an encrypted mail, he needs his message to be encrypted more >> than he needs it to be 100% compatible with everybody. I guess Jean-Marc was saying that it is more important that the message be encrypted than that the intended recipient can decrypt it. That's the issue here. The S/MIME standards (of 1999) defined a minimum set of crypto capabilities that must be implemented by any product that claims compliance with those standards. Those standards provide that, if you don't know the specific capabilities of your correspondent, then you send the message using only those minimum capabilities, because that way you are sure that your correspondent will be able to decrypt your message. If you send it using some optional set of capabilities, your recipient may not be able to decrypt it. Interoperability is the whole point. Actually, the 1999 standards defined two different sets of minimum capabilities, one of which was legally exportable from the US at that time, and one which was not. Since NSS and the S/MIME component of the Mozilla email client were being developed for use world-wide, we chose the legally exportable minimum set. Two years later, when the export rules had changed, we agreed that it should be changed, but by then, the S/MIME capabilities of Mozilla's mail client were already orphaned. > S/MIME is pretty much broken as a design. S/MIME's protection of message authenticity, integrity and confidentiality are unbroken and unsurpassed. It is implemented in most Windows, Mac and Linux email MUA's today. But only a small minority of mail users use MUAs that reside on their own computers today. Webmail rules, and entrusting your private key to your free webmail provider makes no sense at all. The biggest impediment to secure email today is the existence and popularity of webmail. In Mozilla terms, the biggest impediment to Thunderbird today is Firefox. > Old topic. The flaw that was introduced was two-fold. One was the old > ITAR crypto regulations (as Kyle mentioned), Agreed. That was probably the biggest road block and its effects persist today, long after it changed. > and the other was a sort of mad-scientist principle of "crypto agility" > which allowed people to be incompatible with each other and software to > be confusingly complicated. Do you remember what happened to MD5? Without crypto agility, the only solution would have been an "Internet flag day", on which the whole world obsoleted and replaced its old MD5 stuff with some newer hash. Crypto agility allowed a smooth effortless migration for all but a few stragglers. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
