Re: rough sketch of a potential solution

Keith Moore <[email protected]> wrote:

> 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.  Why should I believe anything
example.com says?  Why should I doubt that example.com has taken a bribe
to issue a second certificate for [email protected] to someone else with
a different public key?

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

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

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

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

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

AMC