Re: rough sketch of a potential solution

Email address is nice. But it is a bad idea to believe Email Address = 
Online identity. It is not.

It is only an identifier for an identity (role) you choose to associate 
yourself with others.

-James Seng

Adam M. Costello wrote:
> 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
> 
>