[79574] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: BETA solution, Re: Failure of PKI in messaging

daemon@ATHENA.MIT.EDU (Guus Sliepen)
Fri Feb 16 17:18:12 2007

Date: Fri, 16 Feb 2007 18:19:02 +0100
From: Guus Sliepen <guus@sliepen.eu.org>
To: Cryptography <cryptography@metzdowd.com>
Mail-Followup-To: Guus Sliepen <guus@sliepen.eu.org>,
	Cryptography <cryptography@metzdowd.com>
In-Reply-To: <45D4E2E9.8040304@nma.com>


--PjJwPjbdn5RfZuWK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 incenti=
ve
> to actually do it, to reduce risk -- anyone breaking into any zmail serve=
r,
> 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 decrypt=
ed.

/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.

--=20
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus@sliepen.eu.org>

--PjJwPjbdn5RfZuWK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF1eeFAxLow12M2nsRAnOsAJ9eBMgpW93fbiCvusL2m8tFnhwzRACfVfh8
R+aL4VtCab6wvyyOtVCCcRs=
=+3Hq
-----END PGP SIGNATURE-----

--PjJwPjbdn5RfZuWK--

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

home help back first fref pref prev next nref lref last post