Subject: Re: E-mail address validation

From: "David P. Kemp" <[email-masked]>
Date: Wed, 16 Feb 2000 10:37:01 -0500 (EST)

> From: "Bob Jueneman" <[email-masked]>
>
>  [...]
> 
> 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 address
> 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 some 
> may be missing.

Bob,

I'm unconvinced that X.509/PKIX/SMIME should define an extension or
GeneralName field to contain a "real" common name.  That would create
more problems than it solves.  Yes, there are unusual directory schemas
out there, including within the DoD, and they have a substantial amount
of inertia.  But if there is a corporate policy determination that the
"real" common name should be contained in PKI certificates, then it
unquestionably would be easier to place it in the CN field of the DN
than to procure CAs, directories, and applications with support for an
as-yet-undefined field or extension.

My stab is that by default the UI should display the Subject CN
(always) and the rfc822 address (if present in the cert), with a way
for the user to display the full Subject DN or the full cert.  If the
CN is a bit cryptic, it's up to the organization's CIO to change the
schema or leave it as is.  Regardless of whether the DN is cryptic or
clear, the address book nickname for that cert will always be displayed.

> 2.  The UI SHOULD attempt to match the originator's RFC822 addr-spec address from
> 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 Reply-to 
> 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.
> 
> Bob

Don't forget that a single S/MIME message can have multiple nested
encryptedData and signedData layers, and that a single signedData can
have multiple SignerInfos.  Makes the Reply-to, CC, and BCC questions
sound simple :-).

Paul makes a distinction between the "security standpoint" and the
"UI standpoint".  I agree with Paul that from the UI standpoint a cert
address is not the primary source of return address information.  I
don't agree that the "security standpoint" is different - if you want a
secure Reply-to field, then use signed rfc822 headers, not the contents
of the signing cert.

My bank will accept a check with my signature without caring whether it
entered the postal system from my home address, even though the address
is imprinted.  The imprinted address serves to identify me, but doesn't
limit where I can send or receive snail mail.

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 16 Feb 2000 12:55:52 -0700

David, the syntax for subjectAltName already includes directoryName,
so no architectural extension is required.  And multiple subjectAltNames
are also allowed, explicitly, so no extension is required there either.

Now, how many of the existing mail clients support this is a different 
question, as is the issue of how many CAs support it. Probably none, in
fact.

But that's to be expected, especially in a standards group. We are trying to 
decide where we need to go -- if we limit ourselves to existing products and 
procurement questions, the game is already over.

Naturally, I would like to see CIOs change their directory structure to be more 
accommodating to what certificates need in terms of conveying useful information
to relying parties.

The problem is, having observed this phenomenon for nearly 10 years now, I 
haven't seen any movement in that direction at all, and it isn't just
intransigence -- there are copious real reasons why directory schemas are 
what they are, and they aren't terribly likely to change, I'm afraid.

So I'm not trying to reinvent the wheel, just trying to take advantage of the
wheels that already exist.

Your point about message enveloping is quite valid, and tends to make the 
address comparison issue even more complicated.

Bob

>>> "David P. Kemp" <[email-masked]> 02/16/00 08:37AM >>>

Bob,

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 16 Feb 2000 13:07:59 -0700

Piers, I certainly agree that the IETF is primarily concerned with protocols, 
and not APIs and even less issues of look and feel.

However, what we are trying to do is to establish an infrastructure for _secure_
communications, and to a very large extent that security is quite literally in 
the eye of the beholder.

To my mind, S/MIME today 'works" but is not "workable", in part because of the 
difficulty in setting up the infrastructure, but in part because of trying to get these kinds
of nuances right.

it could be argued that address verification isn't even necessary -- the user 
could check the certificate whenever it seemed necessary.

But what I really don't want to see is a case where a naive user is tricked into 
accepting a signed message from "President William C. Clinton" ..............<[email-masked]> 
just because [email-masked] had previously been validated in a different context.

So, I believe, the human factors issue is important, and at least as relevant to
this WG as any other standards issue where the word "SHOULD" is used.

Obviously Novell could go off and do its own thing in this space -- the Internet
police aren't going to prevent it if we support an additional user name in a subjectAltName
in the certificate, and choose to display it in GroupWise.  But I'm trying to raise all of the
boats, by making sure that the PKI and S/MIME products not only interoperate, but
actually do something useful, and don't mislead people.

My two cents, anyway.

Bob

>>> "Piers Chivers" <[email-masked]> 02/16/00 03:27AM >>>
Bob,
I thought this group was concerned about protocol whereas what you are
describing is largely human-machine-interface issues.  If we are going to
get into that arena I could argue that all signed receipts should be
displayed as green.  I expect that suggestion would be unacceptable to those
who like red!

Having said that, I think the addressing issues need to be clarified.  We
have the added complication of combining SMIME and X.400 where there are
both P1 and P2 addresses.

I mostly agree with your suggestions below but think they need to be worked
upon to become definitive.  I'm not sure if this WG is the right forum for
that discussion?

The most difficult approach is to educate users that who routed the message
(the envelope addressees) is not necessarily the same as who generated the
content.  Perhaps our UIs should improve to make this distinction more
explicit.

Piers

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On 
Behalf Of Bob Jueneman
Sent: 16 February 2000 00:53
To: [email-masked] 
Subject: E-mail address validation

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
address
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
convinced
that it is, what should be done about all of the other To, Cc, and Bcc
addressees?

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
address
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
some
may be missing.

2.  The UI SHOULD attempt to match the originator's RFC822 addr-spec address
from
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
Reply-to
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?

Bob

>>> <[email-masked]> 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.

Regards,

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

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

-----Original Message-----
From: phoffman [SMTP:[email-masked]] 
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