[Top] [All Lists]

Re: E-mail address validation

2000-02-16 08:35:57

From: "Bob Jueneman" <BJUENEMAN(_at_)novell(_dot_)com>


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.


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 
the certificate to the From address of the message, and SHOULD flag a 
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 
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.


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.

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