Re: rough sketch of a potential solution

Thomas Roessler <[email protected]> wrote:

> The proposed logic here seems to boil down to something like this:
> 
> 	   (Mallory signs message) && (Mallory signs "I'm Alice")
> 	   	=> Alice has signed message.
> 
> This is flawed -- anyone could send signed messages on anyone else's
> behalf with this scheme.

Oops, duh.

Keith Moore <[email protected]> wrote:

> it's more like
> 
> ([email protected] signs message) &&
> (example.com signs "[email protected] and [email protected] are the 
> same")
> => [email protected] as signed message

You almost had me believing that.  Suppose Alice and Mallory are two
unrelated people.  Alice gets an email account from example.com,
and gets a certificate from some CA.  She doesn't trust example.com
nearly as much as she trusts the CA, but example.com is limited to
denial-of-service attacks; it can divert her incoming or outgoing mail,
but because it doesn't know her private key, it can't forge signed mail
from her, and it can't read encrypted mail to her, so she's willing to
use an email account from this not-really-trusted entity.

Meanwhile, Mallory gets an email account from example.com, and gets a
certificate from the CA.  If MUAs use the logic quoted above, Mallory
and example.com can collude to forge signed mail from Alice.

Maybe there's a way to fix this, but I think we're all leaning toward
the multiple-addresses-in-the-certificate approach anyway.

Steve Hole <[email protected]> wrote:

> Use certificates the way they were meant to be used and make sure
> that equivalent names are certified as equivalent.  Many MUAs will
> probably treat this properly right now ... I know mine would.  It does
> constrain equivalent addresses to be issued in the same domain, but I
> think that is a good restriction anyway.

When you say "issued in the same domain", do you mean that the addresses
have the same domain-part (the part after the at-sign)?  Or are you
referring to some PKI-related concept of "domain"?

If you mean that the addresses have the same domain-part, I think that
restriction would destroy our whole motivation for alternate addresses.
The point is to have one address that's memorable for users of one
script, and another address that's memorable for users of another
script.  The two addresses will obviously contain distinct IDNs.

Keith Moore <[email protected]> wrote:

> we want people to be able to transcribe the addresses that are
> displayed to them, or use the addresses stored in their address books,
> which in either case may be alternate addresses rather than fallback
> addresses.

Agreed.

> So we want to ensure that sending to an alternate address has exactly
> the same result as sending to a fallback address.

But I still don't see a need to do more than one lookup in the address
mapping service.  When I send mail, I can put whatever address I like in
the From field and the Reply-To field.  When I tell you my address is
[email protected], I'm telling you that I trust one.example not to divert
my mail, because one.example has the power to divert my mail to any
mailbox in the world.

If you're willing to believe that mail to [email protected] will reach
me, and if one.example tells you that [email protected] is an alternate
for [email protected], then you have nothing to lose by believing that
mail to [email protected] will reach me.  Your willingness to believe does
not create any additional risk that my mail will be diverted, because
one.example already had 100% control over where my mail goes anyway.
So there is no need to look up [email protected] in the address mapping
service.

AMC