Subject: Re: Interpreting Certificate Handling section 3.

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 1 May 2004 09:03:40 +0200

A part from the question you put it is interesting to note that
your e-mail certificate as well as mine follows the industry-
standard with respect to e-mail address representation.
That the S/MIME RFC "violates" the industry-standard is
IMHO an error that should be corrected.

/anders
----- Original Message ----- 
From: "Timothy J. Miller" <[email-masked]>
To: <[email-masked]>
Sent: Friday, April 30, 2004 22:09
Subject: Interpreting Certificate Handling section 3.

A question has arisen in the community I support regarding various 
implementer's interpretation of S/MIME Certificate Handling, section 3. 
  To quote:

"""
3. Using Distinguished Names for Internet Mail

End-entity certificates MAY contain an Internet mail address as
described in [RFC-2822]. The address must be an "addr-spec" as defined
in Section 3.4.1 of that specification. The email address SHOULD be in
the subjectAltName extension, and SHOULD NOT be in the subject
distinguished name.

[...]

Sending agents SHOULD make the address in the From or Sender header in
a mail message match an Internet mail address in the signer's
certificate. Receiving agents MUST check that the address in the From
or Sender header of a mail message matches an Internet mail address,
if present, in the signer's certificate, if mail addresses are present
in the certificate. A receiving agent SHOULD provide some explicit
alternate processing of the message if this comparison fails, which
may be to display a message that shows the recipient the addresses in
the certificate or other certificate details.
"""

Most popular S/MIME mail clients absolutely require that the signing 
cert include an email address, and several clients also absolutely 
require that the included email address match the sending account-- 
i.e., if the addresses don't match the clients refuse to send the mail 
signed.

At least one extremely popular client allows the checking of the cert 
email address against the sending account to be disabled.

It has been argued to me that the sending client's refusal to sign & 
send (as opposed an alterative like notifying the user and signing 
anyway) is a violation of the RFC because Sec. 3 does not specify what 
action the client should take when the addresses don't match.  Therefore 
(it is argued) not checking the addresses at all is actually better 
compliance than checking and refusing to send.

I have argued back in turn that the decision to send or not send is the 
implementer's, and the RFC is correctly silent on the issue.  IOW, 
refusal to send is not a divergence at all, just as it isn't a 
divergence to skip the check.

I'm curious whether there a consensus from the group on this subject.

-- 
-- Timothy J. Miller
    ( The MITRE Corporation )

---

From: "Sean P. Turner" <[email-masked]>
Date: Tue, 04 May 2004 11:30:04 -0400

Timothy J. Miller wrote:

> implementer's interpretation of S/MIME Certificate Handling, section 
> 3.  To quote:
>
> """
> action the client should take when the addresses don't match.  
> Therefore (it is argued) not checking the addresses at all is actually 
> better compliance than checking and refusing to send.

My first thought was "oh we could just put a line in about notifying the
user" and be done with it. But, if an sending agent's implemeter doesn't
support the check but does support a notice - it seems funny to present
the notice and then have the client not do anything about what the user
picks.  Then again if the people arguing the other side of the argument
might have some words - let them propose them (granted I'm sure we
hacked this out long ago).

>
> I have argued back in turn that the decision to send or not send is 
> the implementer's, and the RFC is correctly silent on the issue.  IOW, 

I think it's fine the way it is because there is no way (at present) to
keep the From and Sender headers from being changed (think of all the
mail lists). Therefore, it seems like a silly thing to force "sending"
implementations to do on outbound email messages.

spt