[Top] [All Lists]

E-mail address validation

2000-02-15 17:50:53
Paul and Bartley make a good point regarding who the reply should be sent to.
Although this a second order problem, it still appears to be a problem.

The first issue is what should be displayed as the confirmed originator/signer
of the message. and I think we are beginning to get a handle on that problem.

The second issue is one of routing the reply, and here there are so many 
differences in the way replies are handled that I'm not even sure I understand 
all of the problems, much less the solutions.

I do know that mail lists frequently mangle the From address, putting the 
of the mail list in the cc list, etc., etc. 

Likewise, people that have multiple accounts for a number of different reasons
often use a single Reply-To address to consolidate responses.

And if the reply is encrypted, it seems a bit much to ask the sender to somehow 
read my mind as to which processor containing which certificate/key I am going 
to use to decrypt the response.

And finally, if this is a really serious security issue, which I'm not quite 
that it is, what should be done about all of the other To, Cc, and Bcc 

So let me take a stab at a revised solution that includes both problems, 
although this may turn out to be only half-baked.

1.  The UI for a signed message SHOULD display the originator's "real" common 
name, which may be further qualified, if desired.  The originator's RFC822 
from the certificate should also be displayed, and the DN as well, in that 
order of 
preference if those fields are all supplied, but it must be recognized that 
may be missing.

2.  The UI SHOULD attempt to match the originator's RFC822 addr-spec address 
the certificate to the From address of the message, and SHOULD flag a mismatch,
but MUST NOT require that the RFC822 name be present in the certificate.

3.  In the event of an encrypted message, including a reply to a From or 
address, the To, Cc, and Bcc addresses SHOULD all be matched against the 
RFC822 address in that user's certificate, HOWEVER THAT CERTIFICATE
WAS SELECTED, and SHOULD flag any mismatch with a warning message.

Does this take care of the problem?  Do we need to say something about 
checking the outgoing From or Reply-to addresses in the case of a signed message
to make sure they conform to the user's certificate?  If so, which certificate 
-- the 
signing certificate, or the encryption certificate?

Hmm. This gets more and more complicated.


<bartley.o'malleyy(_at_)citicorp(_dot_)com> 02/15/00 03:29AM >>>
Just to play Devils advocate...
There is a third address to be considered, the Reply-to. This is a specific 
request from the originator of the message to reply to another address. If it 
is present we ought not reply to either of the other 2 addresses.


Bartley O'Malley
Citibank NA
Lewisham House
25 Molesworth Street
SE13 7EX

Tel +44-020-7500-6473
Fax +44-020-7500-8880

-----Original Message-----
From: phoffman [SMTP:phoffman(_at_)imc(_dot_)org] 
Sent: Tuesday, February 15, 2000 12:01 AM
To: ietf-smime
Cc: phoffman
Subject: Re: Problem for public CAs

At 04:10 PM 2/14/00 -0700, Bob Jueneman wrote:
Instead, in the case of a signed message the From address should be viewed
as secondary, and the certificate contents the primary information.

 From a security standpoint, this is right. From a UI standpoint, it might 
not be. Assume I have a different email address in my cert than in the 
From: header of a message I send you, that your S/MIME client has informed 
you of that, and you agreed. Now you want to reply to my message. You 
probably don't want to reply to the email address in my cert, but you 
might. There are essentially two From vales: the certificate one and the 
insecure-and-possibly-altered one.

Of course, we have to face the fact that NEITHER the DN nor the RFC822 address
may be particularly relevant or informative.

Exactly right.

And, no, I'm not proposing a solution here.

--Paul Hoffman, Director
--Internet Mail Consortium

<Prev in Thread] Current Thread [Next in Thread>