[Top] [All Lists]

Re: Interpreting Certificate Handling section 3.

2004-05-01 00:04:54
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>
To: <ietf-smime(_at_)imc(_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. 
  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 

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>