On Dec 15, 3:37 pm, Nelson Bolyard <[EMAIL PROTECTED]> wrote: > Daniel Dreymann wrote, On 2007-12-14 14:41: > > > The embedded certificate is only a tool. CertifiedEmail is a third- > > party signature system. First we accredit senders to establish wether > > they are good players with a good email reputation. Then, once they > > are accredited, we certify *individual* messages, i.e. senders request > > a "token" which includes our signature for every message they desire > > to send. > > So, you do not sign the actual messages they generate, but only your own > tokens, which are not computed as functions of their emails?
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. > > This provides us with real-time control which is necessary to > > ensure CertifiedEmail is not abused. These tokens are > > cryptographically checked by the recipient and matched to the message. > > Contrast that with ordinary verification of standards-based S/MIME > signed emails. When a recipient verifies a signature, are there any > parts of the email that are verified in S/MIME but not in your scheme, > or conversely, any parts of the email that are verified in your scheme > and not in S/MIME? 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. > > Contrast that with a CA who vets a sender *once* and grants them a > > certificate that would allow them to sign as many messages as they > > want for a year. CertifiedEmail has built-in real-time security > > mechanisms not available to a bless-and-forget CA. > > I guess that offers protection for the senders who cannot trust > themselves to sign only the mails they legitimately want to send? 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. One of the differences here is the reputation monitoring: send too many unwanted messages and we revoke your privileges in real- time. > Seriously, I see how that offers you a feeling of having more control > than an ordinary CA has, but how do your customers (the message senders) > benefit from your extra level of control, as compared to what they would > gen with ordinary S/MIME signatures? 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. > > Mailbox providers who use CertifiedEmail and control the UI (e.g. > > webmail) show a CE trust icon next to CE messages. > > Yes, The reason for my interest in your "system" is the (reported) fact > that you've gotten a bunch of major web mail providers to sign up to > deploy it. Those providers have not previously provided any support for > any signed email of any kind, not even for verifying received > signatures. So, you have made a major accomplishment by getting them to > adopt this. > > But for some reason, rather than adopting the IETF standards (e.g. > S/MIME) for signed emails, that already are widely implemented in MUA > products, you've implemented a new non-standard format. I'm sure that's > good for your business, but the advantage to others is less clear to me. I love standards but S/MIME was inappropriate for our needs and when we developed CE 1.0, DKIM (or even DK) didn't exist. Now that DKIM is an IETF standard, we will rev CE to 2.0 and we'll use DKIM for the signature layer. But please realize that the signing technology is just a tool: 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. > > We will release > > next year a plug-in for Outlook Express that does the same. We will > > support an open source effort to develop a similar plug-in for > > Thunderbird. > > Outlook Express and Thunderbird both already offer full support for IETF > standard S/MIME signed email. So, why invent Yet Another format? > Why not use the existing standard? How is support for your private > signature system preferable to the existing support for standards based > signatures to the users of those MUA products? > > As I understand it, you desired to have some additional controls that > other CAs don't have, giving you the ability to approve each individual > message, rather than giving blanket approval to the businesses that are > your customers. Surely you could have achieved that without needing to > invent a new signed message format/protocol. 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. > IMO, the achievement of getting Webmail hosts to support signature > verification would be so much greater if it had the ability to verify > IETF standard signed emails from any source. The special recognition > that is given to signatures from your company could still be > differentiated, without necessitating new non-standard signature > verification, nor precluding standard signature verification. You are right. But we go to DKIM, not S/MIME. > > I'm happy to answer any questions here. > > Is there an open specification for your new signed email message format? > Is it possible for others to analyze and vet (or not :) your new design > without doing reverse engineering? The design has been vetted by Cryptography Research (Paul Kocher), by ISE (Avi Rubin) and of course by the security folks at AOL, Yahoo! and our other partners. I'm not interested in widespread distribution of the CE 1.0 docs as we will be finalizing the specs for CE 2.0 early next year (which we'll probably make available for download on our website). Having said that, if you want a copy of the doc and promise not to further distribute, ping me off-list and I'll email you a copy. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
