RFC 2632bis: Using Distinguished Names for Internet Mail

"David P. Kemp" <dpkemp@missi.ncsc.mil> Wed, 28 August 2002 22:50 UTC

Received: from above.proper.com (mail.proper.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23325 for <smime-archive@lists.ietf.org>; Wed, 28 Aug 2002 18:50:29 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7SMT7D09739 for ietf-smime-bks; Wed, 28 Aug 2002 15:29:07 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil []) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7SMT6209734 for <ietf-smime@imc.org>; Wed, 28 Aug 2002 15:29:06 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g7SMTXT23125 for <ietf-smime@imc.org>; Wed, 28 Aug 2002 18:29:33 -0400 (EDT)
Message-ID: <200208282229.g7SMTWS23121@stingray.missi.ncsc.mil>
Date: Wed, 28 Aug 2002 18:25:09 -0400
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-smime@imc.org
Subject: RFC 2632bis: Using Distinguished Names for Internet Mail
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit


Section 3 ("Using Distinguished Names for Internet Mail") of the
Certificate Handling I-D (2632bis draft -01) is unchanged from RFC2632
(except for inclusion of the PKCS #9 email attribute).

It should be obvious that the WG made a conscious and deliberate
decision to change the handling of rfc822 email addresses between
S/MIME V2 and V3:

    RFC 2312 (S/MIME V2) says: "End-entity certificates MUST
    contain an Internet mail address ..."

    RFC 2632 (S/MIME V3) says: "End-entity certificates MAY
    contain an Internet mail address ..." and "Receiving agents
    MUST check that the address ... matches ... if mail addresses
    are present in the certificate."

However, in communications with our PKI development organization,
one large user agent developer has quoted other sentences from
RFC 2632 out of context to claim that V3 user agents must refuse
to accept certificates that do not contain rfc822 addresses.
In order to avoid such misinterpretation,  RFC 2632bis could use
a little explicit, though perhaps redundant, clarification.

Four suggested additions to sections 3 and 5 are shown below,
highlighted *** thus ***:


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.

*** Receiving agents MUST recognize and accept certificates that
contain no email address. ***
Receiving agents MUST recognize email addresses in the subjectAltName
field. Receiving agents MUST recognize email addresses in the
Distinguished Name field in the PKCS #9 [PKCS9] emailAddress

pkcs-9-at-emailAddress OBJECT IDENTIFIER ::=
  {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 }

Sending agents SHOULD make the address in the From or Sender header in
a mail message match an Internet mail address
***, if present, *** 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 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.
*** A receiving agent SHOULD display a subject name or other certificate
details when displaying an indication of successful or unsuccessful
signature verification. ***


5. Security Considerations

All of the security issues faced by any cryptographic application must
be faced by a S/MIME agent. Among these issues are protecting the
user's private key, preventing various attacks, and helping the user
avoid mistakes such as inadvertently encrypting a message for the
wrong recipient. The entire list of security considerations is beyond
the scope of this document, but some significant concerns are listed

When processing certificates, there are many situations where the
processing might fail. Because the processing may be done by a user
agent, a security gateway, or other program, there is no single way to
handle such failures. Just because the methods to handle the failures
has not been listed, however, the reader should not assume that they
are not important. The opposite is true: if a certificate is not
provably valid and associated with the message, the processing
software should take immediate and noticable steps to inform the end
user about it.

Some of the many places where signature and certificate checking might
fail include:

- no Internet mail addresses in a certificate matches the sender of a
  message *** ,if the certificate contains at least one mail address ***
- no certificate chain leads to a trusted CA
- no ability to check the CRL for a certificate
- an invalid CRL was received
- the CRL being checked is expired
- the certificate is expired
- the certificate has been revoked

There are certainly other instances where a certificate may be
invalid, and it is the responsibility of the processing software to
check them all thoroughly, and to decide what to do if the check