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? > 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? > 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? 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? > 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. > 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. 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. > 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? > Daniel Dreymann > CEO & Co-Founder, Goodmail Systems /Nelson Bolyard _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
