Re: rough sketch of a potential solution

> > only example.com can really say who [email protected] is;
> > example.com is free to change this binding anyway. so any
> > certificate from an external CA that makes assertions about who
> > [email protected] is is meaningless.
> 
> But a certificate from example.com is also meaningless if example.com
> is some podunk domain with no reputation. 

Perhaps, but it's more meaningful than a certificate by anybody else.
If you attach value to the name "example.com" or to an email address
defined at that domain, you're inherently investing some trust in the
entity to which the name "example.com" was assigned.  If you choose not
to invest any trust, then "example.com" is meaningless to you.


> Let's remember what James said: an email address is not an identity. 
> It would be closer to the truth to say that a public key is an
> identity(which ignores the possibility of a person having multiple
> public keys, but if they do, it's probably because they want to act as
> multiple personas anyway, so let's go ahead and ignore that case).

People do use email addresses as identities, just as they use their
given names, nicknames, and random other strings (like Amateur Radio
callsigns).  We can say that email addresses are not intended to be
used as identities, but the reality is that naming is slippery and 
people do not restrict how they use names according to the intent
(or even wishes) of the designers of the name space.  Email addresses
can and are used as identifiers that are simultaneously associated with
both people and their public keys.

> 
> We're trying to use an email address as an identifier for a public
> key, because email addresses are easier to remember/type than public
> keys, and because email addresses help us actually communicate with
> the owner of the public key.
> 
> In order to believe that a given email address is an identifier for a
> given public key, you need to see some convincing testimony (or set of
> testimonies) that the address is bound to that key *and no other key*.

It's clearly possible (and reasonable, even necessary) to have multiple
keys associated with an identifier, or a person.  For instance, a person
can use multiple PK cryptosystems each with its own key; he can have 
different keys for different purposes; he can have different keys with
different validity lifetimes (say, as one key is nearing expiration
and another key is being phased in).

> I don't know how that would work, but if you can trust a given CA to
> cooperate with other CAs and take the necessary steps to verify that
> an email address is not already bound (by itself or any other
> cooperative CA) before issuing a certificate that binds the address,
> then you can accept certificates from that CA for any email address.

A CA can certainly do this.  Whether the CA's word is worth the bits it
is written on is a different question.  But personally I would never
trust the assertions of a CA that didn't have an explicit relationship
with  example.com, to make assertions about email addresses in
example.com.

> An alternative is not to use CAs at all, and instead keep your own
> local mapping of email addresses to public keys.  That's what PGP
> does, right?
> 
> Either way, if several addresses (possibly in different domains) are
> convincingly bound to the same public key, then the addresses are
> interchangeable.

Perhaps for your purposes.  Not for mine, and not in general.  If you
want to configure your MUA to trust VeryScrawl's certs that say that
[email protected] and  [email protected] is equivalent, that's your business, but to provide
users in general with assurance that they can trust the assertions of
CAs about the  relationship of email addresses that are unrelated to
each other is, as far as I can tell, well beyond the present
state-of-the-art.  Heck, nobody has figured out how to make a simple
trust hierarchy work in the real world on any scale, and you're saying
we should expect users to accept arbitrary  transitive trust
relationships between parties that can't be shown to have any
relationship whatsoever.  To be meaningful trust in cryptosystems needs 
to reflect the structures that humans use to establish trust, and it's
hard to see how to make your proposal fit those structures.

Anyway, that's why this is not in scope for my proposal.  

> So if someone wants to have alternate addresses and
> wants to sign a message, the signature should include whatever bundle
> of evidence is needed to convince the recipient that all the addresses
> are bound to the public key that verifies the signature.

I don't think that's necessary.  The recipient's MUA can say "this
message is signed by [email protected] who also claims to be the author of the
message" as long as there's a certificate binding [email protected] to the public
key, and as long as [email protected] is listed in the message as any one of the
alternatives for the author's address.  What the MUA shouldn't do is say
"this message is signed by [email protected]" if the public key is only known to be
associated with [email protected], even if the  message claims that [email protected] and [email protected]
are equivalent, and even if [email protected] is the address that is most easily
readable by the recipient. 

Now if the message from [email protected] / [email protected] is signed using a key for which
there is a cert that binds both of those addresses to the public key,
AND if the recipient has determined that it can trust the CA to make
assertions on behalf of both b.c and e.f AND if the recipient has
configured the MUA to recognize that trust, then the MUA can display
either [email protected] or [email protected] (or both) as the party who signed the message. 
But without all of these conditions being true, the MUA should ignore
any equivalence claimed in the message between [email protected] and [email protected] and
simply display whatever address appears in the From field.

> I don't see how restricting alternate addresses to the same domain
> helps us.  Either it's possible to convincingly bind an address to a
> public key, or it's not.  If it's not possible, then the whole idea of
> signed email is a farce.  If it is possible, then it's possible for
> multiple addresses in multiple domains to be convincingly bound to the
> same public key.  Maybe the single-certificate idea won't work as well
> as we hoped, but there must be a way.

You're thinking in terms of using signatures, and I'm thinking in terms
of having this work without requiring signatures.  If the address mapping
server that's bound using a DNS SRV record to example.com wants to make
assertions about example.com, well, that's about as trustworthy as anything
else in the current mail system.  And it's already the case that the
sender can lie about whatever addresses are in the message's header -
he can make bogus claims about who sent the message, where the message
was sent, the names associated with those addreses, etc.  Allowing the 
sender to lie about address equivalence doesn't really change that.  
And for that matter any unsigned message could be altered in transit,
or completely forged.

But allowing the address mapping service to make assertions about the
equivalence of addresses in different domains (that aren't controlled
by the same party) would not only degrade the already-weak assurance we
have from the email system (because it would allow yet another party
to interfere with the communication) - even among trustworthy parties
it introduces the potential for synchronization errors, mapping loops,
etc.  And it's not necessary to support arbitrary cross-domain 
equivalences to make the system work.  So why make life harder than
necessary?

You also seem to be thinking in terms of sender addresses, when I'm
also thinking in terms of recipient addresses.   The sender might have
a cert that binds several of his addresses to one key;  it's less
likely that he has a cert that binds several recipient addresses 
together.

> 
> > > 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.
> >
> > we can do that if we have a way to declare that the two IDNs are
> > equivalent. what we don't want to do is build a mechanism that can
> > map an arbitrary email address onto another arbitrary email address.
> 
> I don't understand the importance of the distinction.  Is there any
> way to declare two arbitrary IDNs equivalent except by building a
> mapping mechanism?  And if we can map arbitrary IDNs onto each other,
> how is mapping arbitrary email addresses different in any significant
> way? 

If a.b and c.d are equivalent to each other (meaning they're run by the
same party and that party asserts that [email protected] and [email protected] are equivalent
for all x), that's fairly easy to indicate via a combination of DNS
and the mapping protocol - and the DNS records can even be signed,
for what good that will do.  And once we know that those two domains are
equivalent, we can then ask the domain mapping server for a.b/c.d 
whether x and y are equivalent.  That's very easy.

It's much harder to make tracable assertions that arbitary email 
addresses are equivalent, and furthermore, it doesn't seem to be 
necessary.

> The relationship between [email protected] and bar.example.net
> is pretty much the same as the relationship between bar.example.net
> and example.net; the at-sign signifies the same sort of delegation of
> naming authority as a dot.

Not necessarily.  Chances are there's a big difference between the 
relationship between a.com and b.com and the relationship between 
a.example.com and b.example.com. 

> 
> > > 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.
> >
> > It's not the originator fields that are the problem so much as the
> > recipient fields.  A's MUA needs the address mapping service to
> > obtain alternative addresses for B and C so that each address will
> > be maximally transcribable by all recipients.
> 
> Okay, and when A sends the message, it can put whatever it wants
> in the To/Cc fields.  If you're willing to trust that A put the
> "right" addresses in the To/Cc fields (and that they were uncorrupted
> in transit), then you might as well trust that A put the "right"
> addresses (the ones obtained from the address-mapping service) in the
> alternate-addresses field too (and that they too were uncorrupted in
> transit).  And if you're willing to trust the domains appearing in the
> addresses in the To/Cc fields to route mail properly and not divert
> it, then you might as well trust them to have given A legitimate
> alternate addresses when A performed the lookup.  Therefore there is
> no need for A to look up the alternate addresses and verify the
> symmetry.  No new opportunities for mail diversion are created if A
> forgoes the extra lookups.

For that matter, A could certainly look up the equivalent addresses 
and then lie about them.

The purpose of the address mapping service is not to try to keep A
from misrepresenting who it sent the message to, but to make it easy
for A to get the equivalences for his recipients right even though 
A doesn't necessarily know all of the recipients personally.
So A is trusting the address mapping service to not lie.

The purpose of not allowing the address mapping service to make
arbitrary assertions about equivlances between addresses is  to
minimize the potential for harm if A trusts that mapping service -
it limits the degree to which the mapping service can betray A's
trust, and it also minimizes the potential for problems due to 
lack of synchronization between the mapping service for example.com
and the SMTP server for example.com that has to be aware of those
equivalences in order to deliver mail properly.  In other words,
it makes the mapping service somewhat more trustworthy than it
would otherwise be.

Keith