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.
----- Original Message -----
From: "Timothy J. Miller" <tmiller(_at_)mitre(_dot_)org>
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.
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
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
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 )
Description: S/MIME cryptographic signature