Daniel Dreymann wrote, On 2007-12-15 17:26: > The token includes a hash of the message (submitted to us by the > sender), hence each the token is unique and valid for one specific > message only.
I see. So it's also a form of rate control, traffic shaping. > The entire body and selected headers are signed. Very much like DKIM. > CertifiedEmail 2.0 will be using DKIM for the signature layer but will > include all the security mechanism inherent to CE 1.0. The main thing > to grok here is that it's a third-party signature done on a per- > message basis. That's useful info. Thanks. > No: it mainly offers protection to the RECIPIENT, who can't trust a > message just because somebody unknown (or "known" through a Cert) > signed it. If getting an EV Cert would guarantee senders unlimited > delivery with impunity, senders (incl. legit ones) would buy one and > spam freely. I think not. In a world where non-signed email is discarded, and all spam is signed, the verified sender identity becomes a basis for the user to impose reputation filters of their own. Spam me, and I filter out all future emails you send. As an EV sender, you won't be able to morph identities as rapidly as you can without verified identity. > One of the differences here is the reputation monitoring: send too > many unwanted messages and we revoke your privileges in real- time. This says that, unlike (most) other CAs, who certify only signer identity, you're also effectively certifying something more, though it's not clear (to me) what that is, exactly. You're saying that your signature implies more goodness (of some sort) than merely not being a fly-by-night identity (the chief value of EV, as I see it). Perhaps it would be useful to know more about what those additional qualifications of sender goodness are. You wrote that the recipient will be able to "trust" a message. That suggests that you are measuring the sender's trustworthiness in some manner. Please elaborate. > The simple answer is that S/MIME buys them nothing. When we certify > their messages, they are guaranteed: a) delivery, b) trust icon in the > UI, c) images and links not suppressed, d) delivery reports. Guaranteed? The webmail user no longer will have the choice to suppress the display of images in incoming mails? Will the webmail user be able to filter out messages from these CE senders? As an occasional web mail user, I'd dump any provider in a heartbeat that took away my control to suppress the display of images in remote emails, or to suppress emails from certain senders. > [...] the breakthrough here is the business processes and the > agreements we tie between senders and receivers: unlike non-Certified > messages which are delivered on a best-effort basis, here there's an > explicit agreement (through a trusted intermediary) between the sender > of the message and the receiving mailbox providers. This raises a question. Please don't think it impertinent. In this business model, do the mailbox providers receive "consideration" for agreeing to this? Are they being paid to do this? Obviously, no standard alone can provide the incentive that payment does. > We needed to invent a protocol for the sender to submit a token > request and for us to grant it. But more importantly, we can't afford > the CE icon to be showed next to messages that are not certified by us > (or by another authority adhering to the same per-message > certification mechanism) but simply self-signed by anybody who owns a > cert. So clearly whatever built-in support for S/MIME you have in MUAs > doesn't really help. You really don't trust your business clients to sign their own emails. That's a new and surprising (to me) element to this design, one I'd not heard expressed in other designs before. You want to manage sender reputation, rather than allowing the recipient to do so, I gather. > [...] we will be finalizing the specs for CE 2.0 early > next year (which we'll probably make available for download on our > website). Thanks. I look forward to seeing that. Thanks very much for your candid replies. Regards, /Nelson Bolyard _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
