ietf-smime
[Top] [All Lists]

Interpreting Certificate Handling section 3.

2004-04-30 13:09:16
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 )

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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