Re: rough sketch of a potential solution

> > Well, we've already got the capability for multiple From addresses,
> > and now we'll have a situation where each of those From addresses
> > can have multiple representations.  So we inherently have a
> > situation where the parties who sign a message may not match the
> > list of addresses in the From field.  The only question is how the
> > recipient's MUA should represent this situation to the recipient.  
> > It can say "message is signed but the signature doesn't match the
> > From addresses" (which is misleading), or it can say "signature
> > invalid" (which is worse), or it can say "message is signed by
> > [email protected]".
> 
> It only has to match one of the representations.

Then (unless the mappings are signed by the domain) you permit a rogue 
third-party to add additional headers that say "my.new.address@domain 
is equivalent to the From address" and sign the message with 
my.new.address@domain - making it appear that the (perhaps altered) 
message was signed by the From address, when it wasn't.

> Sigh ... to be fair, this is somewhat of a misnomer.   IFF MUA's
> provided some really obvious and user friendly means of saying "this
> content was issued by this signer" then it wouldn't matter.
> 
> But.
> 
> Most (every MUA that matters) only sign messages, not parts of
> messages.  Most verify/validate that the From address (usually
> singular) matches the email address in the signing cert.   If they
> don't, then you get the big black screen of uninformed user panic
> "There is something wrong with this message".   It is difficult to
> argue that this isn't a good policy if signing always occurs in the
> real world at the top MIME level -- which it does.

I don't have any trouble at all arguing that this isn't a good policy.
Basically, it sucks.  Who knows, maybe crap like this (error indications
when there's really no error, or a mismatch between what people need and
what S/MIME wants to impose) is part of the reason that S/MIME hasn't
been widely adopted.

People don't have any trouble grasping the idea that the person who
notarizes a piece of paper isn't necessarily the same as the person or
people who signed that piece of paper.  This concept is no more
difficult.

> So, at least, we really SHOULD NOT do more to damage the already
> precarious usage issues with S/MIME processing. 

Or maybe, we really SHOULD NOT let S/MIME brain-damage get in this
group's way.  In the Real World (tm), some people have multiple names in
different languages.  Let S/MIME succeed or fail on its own merits,
including how well it matches what people need to do in the Real World
(tm).  

OTOH it's appears possible to develop an interim profile that allows use
of S/MIME with this scheme.  Everyone who uses S/MIME would define his
keys in  terms of his fallback address.  And unless/until a better
interface were developed, MUAs that support S/MIME would need to display
the sender's fallback address from signed mail (rather than the
recipient's perferred form) as "who authored/signed the message".

The address mapping service could even be used to supply the S/MIME keys
(along with certificates, of course) for recipients that accept
encrypted mail.

>  A definition for "proper" security
> processing is well beyond the scope of this group, but we definitely
> need to take existing practice into account. 
> 
> > But now I remember another one of the reasons for allowing the
> > mapping service to sign address mappings (and to include those
> > signatures in the address mapping header extensions) - it was so
> > that if a message were signed by [email protected] but shown to the
> > recipient as if it were from [email protected], it would be possible for
> > the recipient's MUA to verify that the two addresses really were
> > equivalent.
> 
> Interesting.   
> 
> Whatever comes of imaa will seriously need to be discussed in the
> S/MIME working group so that some definition of the right way to do
> address matching is well defined enough that even MS can get it right.

You're making two huge assumptions:

- it's possible for the S/MIME group to agree on the "right" way to do
  something in finite time
- it's possible for MS to do anything "right" at all

(sorry, couldn't resist)