Blake,
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
attribute:
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
here.
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
fails.
---------------------------------------------------------------------