Timothy J. Miller wrote:
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.
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,
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.
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