BETA solution, Re: Failure of PKI in messaging

Guus Sliepen guus at
Fri Feb 16 12:19:02 EST 2007

On Thu, Feb 15, 2007 at 02:47:05PM -0800, Ed Gerck wrote:

> Zmail actually reduces the amount of trust by not storing your usercode,
> password, or keys anywhere. This makes sense for zmail, and is an incentive
> to actually do it, to reduce risk -- anyone breaking into any zmail server,
> even physically, will not find any key or credential material for any user
> and, hence, cannot decrypt any user area (the user area keeps the address book
> and contact keys, all encrypted using the user keys that are not there), or
> user messages collected from ISPs.

Where are the usercode, password and keys stored then?

> This will actually be available in v3.x, with an option for client-based
> super-encryption. If you are concerned about zmail peeking into the raw
> message, which zmail does not do, you can simply agree with your message
> partner on an out-of-band passphrase and use it in your client (without
> zmail access) to encrypt. Your recipient can do the same to decrypt. What
> you get from zmail is the secure routing and distribution -- for example,
> you can require the recipient to login, allow the recipient to prevent
> phishing, and expire the message in 7 days. You can also request a return
> receipt telling you when, where, how, and by whom the message was decrypted.

/If/ I trust ZMail (the people behind it and the X.509 stuff that
secures the website) then yes, this is functionality not offered by SMTP
and PGP or S/MIME. But I don't see this replacing PGP or S/MIME. I also
still don't see how this improves the trust model.

Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus at>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <>

More information about the cryptography mailing list