doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc3850.txt b/doc/rfc/rfc3850.txt
new file mode 100644
index 0000000..cdaa2ec
--- /dev/null
+++ b/doc/rfc/rfc3850.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                B. Ramsdell, Editor
+Request for Comments: 3850                                Sendmail, Inc.
+Obsoletes: 2632                                                July 2004
+Category: Standards Track
+
+
+   Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
+                          Certificate Handling
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document specifies conventions for X.509 certificate usage by
+   Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.  S/MIME
+   provides a method to send and receive secure MIME messages, and
+   certificates are an integral part of S/MIME agent processing.  S/MIME
+   agents validate certificates as described in RFC 3280, the Internet
+   X.509 Public Key Infrastructure Certificate and CRL Profile.  S/MIME
+   agents must meet the certificate processing requirements in this
+   document as well as those in RFC 3280.
+
+Table of Contents
+
+   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
+       1.1.  Definitions. . . . . . . . . . . . . . . . . . . . . . .  2
+       1.2.  Compatibility with Prior Practice of S/MIME. . . . . . .  3
+       1.3.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  3
+       1.4.  Changes Since S/MIME v3 (RFC 2632) . . . . . . . . . . .  3
+   2.  CMS Options. . . . . . . . . . . . . . . . . . . . . . . . . .  4
+       2.1 . CertificateRevocationLists . . . . . . . . . . . . . . .  4
+       2.2.  CertificateChoices . . . . . . . . . . . . . . . . . . .  4
+       2.3.  CertificateSet . . . . . . . . . . . . . . . . . . . . .  5
+   3. Using Distinguished Names for Internet Mail . . . . . . . . . .  6
+   4.  Certificate Processing . . . . . . . . . . . . . . . . . . . .  7
+       4.1.  Certificate Revocation Lists . . . . . . . . . . . . . .  8
+       4.2.  Certification Path Validation. . . . . . . . . . . . . .  8
+       4.3.  Certificate and CRL Signing Algorithms . . . . . . . . .  9
+
+
+
+Ramsdell                    Standards Track                     [Page 1]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+       4.4.  PKIX Certificate Extensions. . . . . . . . . . . . . . .  9
+   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 11
+   A.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+       A.1.  Normative References . . . . . . . . . . . . . . . . . . 13
+       A.2.  Informative References . . . . . . . . . . . . . . . . . 14
+   B.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
+   C.  Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 15
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
+
+1.  Overview
+
+   S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
+   [SMIME-MSG], provides a method to send and receive secure MIME
+   messages.  Before using a public key to provide security services,
+   the S/MIME agent MUST verify that the public key is valid.  S/MIME
+   agents MUST use PKIX certificates to validate public keys as
+   described in the Internet X.509 Public Key Infrastructure (PKIX)
+   Certificate and CRL Profile [KEYM].  S/MIME agents MUST meet the
+   certificate processing requirements documented in this document in
+   addition to those stated in [KEYM].
+
+   This specification is compatible with the Cryptographic Message
+   Syntax [CMS] in that it uses the data types defined by CMS.  It also
+   inherits all the varieties of architectures for certificate-based key
+   management supported by CMS.
+
+1.1.  Definitions
+
+   For the purposes of this document, the following definitions apply.
+
+   ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.208
+   [X.208-88].
+
+   Attribute Certificate (AC): An X.509 AC is a separate structure from
+   a subject's public key X.509 Certificate.  A subject may have
+   multiple X.509 ACs associated with each of its public key X.509
+   Certificates.  Each X.509 AC binds one or more Attributes with one of
+   the subject's public key X.509 Certificates.  The X.509 AC syntax is
+   defined in [ACAUTH].
+
+   Certificate:  A type that binds an entity's name to a public key with
+   a digital signature.  This type is defined in the Internet X.509
+   Public Key Infrastructure (PKIX) Certificate and CRL Profile [KEYM].
+   This type also contains the distinguished name of the certificate
+   issuer (the signer), an issuer-specific serial number, the issuer's
+   signature algorithm identifier, a validity period, and extensions
+   also defined in that document.
+
+
+
+
+Ramsdell                    Standards Track                     [Page 2]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+   Certificate Revocation List (CRL): A type that contains information
+   about certificates whose validity an issuer has prematurely revoked.
+   The information consists of an issuer name, the time of issue, the
+   next scheduled time of issue, a list of certificate serial numbers
+   and their associated revocation times, and extensions as defined in
+   [KEYM].  The CRL is signed by the issuer.  The type intended by this
+   specification is the one defined in [KEYM].
+
+   Receiving agent: software that interprets and processes S/MIME CMS
+   objects, MIME body parts that contain CMS objects, or both.
+
+   Sending agent: software that creates S/MIME CMS objects, MIME body
+   parts that contain CMS objects, or both.
+
+   S/MIME agent: user software that is a receiving agent, a sending
+   agent, or both.
+
+1.2.  Compatibility with Prior Practice of S/MIME
+
+   S/MIME version 3.1 agents should attempt to have the greatest
+   interoperability possible with agents for prior versions of S/MIME.
+   S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive
+   and S/MIME version 3 is described in RFC 2630 through RFC 2634
+   inclusive.  RFC 2311 also has historical information about the
+   development of S/MIME.
+
+1.3.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [MUSTSHOULD].
+
+1.4.  Changes Since S/MIME v3 (RFC 2632)
+
+   Version 1 and Version 2 CRLs MUST be supported.
+
+   Multiple CA certificates with the same subject and public key, but
+   with overlapping validity periods, MUST be supported.
+
+   Version 2 attribute certificates SHOULD be supported, and version 1
+   attributes certificates MUST NOT be used.
+
+   The use of the MD2 digest algorithm for certificate signatures is
+   discouraged and security language added.
+
+   Clarified use of email address use in certificates.  Certificates
+   that do not contain an email address have no requirements for
+   verifying the email address associated with the certificate.
+
+
+
+Ramsdell                    Standards Track                     [Page 3]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+   Receiving agents SHOULD display certificate information when
+   displaying the results of signature verification.
+
+   Receiving agents MUST NOT accept a signature made with a certificate
+   that does not have the digitalSignature or nonRepudiation bit set.
+
+   Clarifications for the interpretation of the key usage and extended
+   key usage extensions.
+
+2.  CMS Options
+
+   The CMS message format allows for a wide variety of options in
+   content and algorithm support.  This section puts forth a number of
+   support requirements and recommendations in order to achieve a base
+   level of interoperability among all S/MIME implementations.  Most of
+   the CMS format for S/MIME messages is defined in [SMIME-MSG].
+
+2.1.  CertificateRevocationLists
+
+   Receiving agents MUST support the Certificate Revocation List (CRL)
+   format defined in [KEYM].  If sending agents include CRLs in outgoing
+   messages, the CRL format defined in [KEYM] MUST be used.  In all
+   cases, both v1 and v2 CRLs MUST be supported.
+
+   All agents MUST be capable of performing revocation checks using CRLs
+   as specified in [KEYM].  All agents MUST perform revocation status
+   checking in accordance with [KEYM].  Receiving agents MUST recognize
+   CRLs in received S/MIME messages.
+
+   Agents SHOULD store CRLs received in messages for use in processing
+   later messages.
+
+2.2.  CertificateChoices
+
+   Receiving agents MUST support v1 X.509 and v3 X.509 identity
+   certificates as profiled in [KEYM].  End entity certificates MAY
+   include an Internet mail address, as described in section 3.
+
+   Receiving agents SHOULD support X.509 version 2 attribute
+   certificates.  See [ACAUTH] for details about the profile for
+   attribute certificates.
+
+2.2.1.  Historical Note About CMS Certificates
+
+   The CMS message format supports a choice of certificate formats for
+   public key content types: PKIX, PKCS #6 Extended Certificates [PKCS6]
+   and PKIX Attribute Certificates.
+
+
+
+
+Ramsdell                    Standards Track                     [Page 4]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+   The PKCS #6 format is not in widespread use.  In addition, PKIX
+   certificate extensions address much of the same functionality and
+   flexibility as was intended in the PKCS #6.  Thus, sending and
+   receiving agents MUST NOT use PKCS #6 extended certificates.
+
+   X.509 version 1 attribute certificates are also not widely
+   implemented, and have been superseded with version 2 attribute
+   certificates.  Sending agents MUST NOT send version 1 attribute
+   certificates.
+
+2.3.  CertificateSet
+
+   Receiving agents MUST be able to handle an arbitrary number of
+   certificates of arbitrary relationship to the message sender and to
+   each other in arbitrary order.  In many cases, the certificates
+   included in a signed message may represent a chain of certification
+   from the sender to a particular root.  There may be, however,
+   situations where the certificates in a signed message may be
+   unrelated and included for convenience.
+
+   Sending agents SHOULD include any certificates for the user's public
+   key(s) and associated issuer certificates.  This increases the
+   likelihood that the intended recipient can establish trust in the
+   originator's public key(s).  This is especially important when
+   sending a message to recipients that may not have access to the
+   sender's public key through any other means or when sending a signed
+   message to a new recipient.  The inclusion of certificates in
+   outgoing messages can be omitted if S/MIME objects are sent within a
+   group of correspondents that has established access to each other's
+   certificates by some other means such as a shared directory or manual
+   certificate distribution.  Receiving S/MIME agents SHOULD be able to
+   handle messages without certificates using a database or directory
+   lookup scheme.
+
+   A sending agent SHOULD include at least one chain of certificates up
+   to, but not including, a Certificate Authority (CA) that it believes
+   that the recipient may trust as authoritative.  A receiving agent
+   MUST be able to handle an arbitrarily large number of certificates
+   and chains.
+
+   Agents MAY send CA certificates, that is, certificates which can be
+   considered the "root" of other chains, and which MAY be self-signed.
+   Note that receiving agents SHOULD NOT simply trust any self-signed
+   certificates as valid CAs, but SHOULD use some other mechanism to
+   determine if this is a CA that should be trusted.  Also note that
+   when certificates contain DSA public keys the parameters may be
+   located in the root certificate.  This would require that the
+   recipient possess both the end-entity certificate as well as the root
+
+
+
+Ramsdell                    Standards Track                     [Page 5]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+   certificate to perform a signature verification, and is a valid
+   example of a case where transmitting the root certificate may be
+   required.
+
+   Receiving agents MUST support chaining based on the distinguished
+   name fields.  Other methods of building certificate chains MAY be
+   supported.
+
+   Receiving agents SHOULD support the decoding of X.509 attribute
+   certificates included in CMS objects.  All other issues regarding the
+   generation and use of X.509 attribute certificates are outside of the
+   scope of this specification.  One specification that addresses
+   attribute certificate use is defined in [SECLABEL].
+
+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.  Agents are allowed to provide an alternative
+   mechanism for associating an email address with a certificate that
+   does not contain an email address, such as through the use of the
+   agent's address book, if available.  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 }
+
+   Note that this attribute MUST be encoded as IA5String.
+
+   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.
+
+
+
+
+
+
+Ramsdell                    Standards Track                     [Page 6]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+   A receiving agent SHOULD display a subject name or other certificate
+   details when displaying an indication of successful or unsuccessful
+   signature verification.
+
+   All subject and issuer names MUST be populated (i.e., not an empty
+   SEQUENCE) in S/MIME-compliant X.509 identity certificates, except
+   that the subject DN in a user's (i.e., end-entity) certificate MAY be
+   an empty SEQUENCE in which case the subjectAltName extension will
+   include the subject's identifier and MUST be marked as critical.
+
+4.  Certificate Processing
+
+   A receiving agent needs to provide some certificate retrieval
+   mechanism in order to gain access to certificates for recipients of
+   digital envelopes.  There are many ways to implement certificate
+   retrieval mechanisms.  X.500 directory service is an excellent
+   example of a certificate retrieval-only mechanism that is compatible
+   with classic X.500 Distinguished Names.  Another method under
+   consideration by the IETF is to provide certificate retrieval
+   services as part of the existing Domain Name System (DNS).  Until
+   such mechanisms are widely used, their utility may be limited by the
+   small number of correspondent's certificates that can be retrieved.
+   At a minimum, for initial S/MIME deployment, a user agent could
+   automatically generate a message to an intended recipient requesting
+   that recipient's certificate in a signed return message.
+
+   Receiving and sending agents SHOULD also provide a mechanism to allow
+   a user to "store and protect" certificates for correspondents in such
+   a way so as to guarantee their later retrieval.  In many
+   environments, it may be desirable to link the certificate
+   retrieval/storage mechanisms together in some sort of certificate
+   database.  In its simplest form, a certificate database would be
+   local to a particular user and would function in a similar way as an
+   "address book" that stores a user's frequent correspondents.  In this
+   way, the certificate retrieval mechanism would be limited to the
+   certificates that a user has stored (presumably from incoming
+   messages).  A comprehensive certificate retrieval/storage solution
+   may combine two or more mechanisms to allow the greatest flexibility
+   and utility to the user.  For instance, a secure Internet mail agent
+   may resort to checking a centralized certificate retrieval mechanism
+   for a certificate if it can not be found in a user's local
+   certificate storage/retrieval database.
+
+   Receiving and sending agents SHOULD provide a mechanism for the
+   import and export of certificates, using a CMS certs-only message.
+   This allows for import and export of full certificate chains as
+   opposed to just a single certificate.  This is described in [SMIME-
+   MSG].
+
+
+
+Ramsdell                    Standards Track                     [Page 7]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+   Agents MUST handle multiple valid Certification Authority (CA)
+   certificates containing the same subject name and the same public
+   keys but with overlapping validity intervals.
+
+4.1.  Certificate Revocation Lists
+
+   In general, it is always better to get the latest CRL information
+   from a CA than to get information stored away from incoming messages.
+   A receiving agent SHOULD have access to some certificate revocation
+   list (CRL) retrieval mechanism in order to gain access to certificate
+   revocation information when validating certification paths.  A
+   receiving or sending agent SHOULD also provide a mechanism to allow a
+   user to store incoming certificate revocation information for
+   correspondents in such a way so as to guarantee its later retrieval.
+
+   Receiving and sending agents SHOULD retrieve and utilize CRL
+   information every time a certificate is verified as part of a
+   certification path validation even if the certificate was already
+   verified in the past.  However, in many instances (such as off-line
+   verification) access to the latest CRL information may be difficult
+   or impossible.  The use of CRL information, therefore, may be
+   dictated by the value of the information that is protected.  The
+   value of the CRL information in a particular context is beyond the
+   scope of this specification but may be governed by the policies
+   associated with particular certification paths.
+
+   All agents MUST be capable of performing revocation checks using CRLs
+   as specified in [KEYM].  All agents MUST perform revocation status
+   checking in accordance with [KEYM].  Receiving agents MUST recognize
+   CRLs in received S/MIME messages.
+
+4.2.  Certification Path Validation
+
+   In creating a user agent for secure messaging, certificate, CRL, and
+   certification path validation SHOULD be highly automated while still
+   acting in the best interests of the user.  Certificate, CRL, and path
+   validation MUST be performed as per [KEYM] when validating a
+   correspondent's public key.  This is necessary before using a public
+   key to provide security services such as: verifying a signature;
+   encrypting a content-encryption key (ex: RSA); or forming a pairwise
+   symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt a
+   content-encryption key.
+
+   Certificates and CRLs are made available to the path validation
+   procedure in two ways: a) incoming messages, and b) certificate and
+   CRL retrieval mechanisms.  Certificates and CRLs in incoming messages
+   are not required to be in any particular order nor are they required
+   to be in any way related to the sender or recipient of the message
+
+
+
+Ramsdell                    Standards Track                     [Page 8]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+   (although in most cases they will be related to the sender).
+   Incoming certificates and CRLs SHOULD be cached for use in path
+   validation and optionally stored for later use.  This temporary
+   certificate and CRL cache SHOULD be used to augment any other
+   certificate and CRL retrieval mechanisms for path validation on
+   incoming signed messages.
+
+4.3.  Certificate and CRL Signing Algorithms
+
+   Certificates and Certificate Revocation Lists (CRLs) are signed by
+   the certificate issuer.  A receiving agent MUST be capable of
+   verifying the signatures on certificates and CRLs made with
+   id-dsa-with-sha1 [CMSALG].
+
+   A receiving agent MUST be capable of verifying the signatures on
+   certificates and CRLs made with md5WithRSAEncryption and
+   sha1WithRSAEncryption signature algorithms with key sizes from 512
+   bits to 2048 bits described in [CMSALG].
+
+   Because of the security issues surrounding MD2 [RC95], and in light
+   of current use, md2WithRSAEncryption MAY be supported.
+
+4.4.  PKIX Certificate Extensions
+
+   PKIX describes an extensible framework in which the basic certificate
+   information can be extended and how such extensions can be used to
+   control the process of issuing and validating certificates.  The PKIX
+   Working Group has ongoing efforts to identify and create extensions
+   which have value in particular certification environments.  Further,
+   there are active efforts underway to issue PKIX certificates for
+   business purposes.  This document identifies the minimum required set
+   of certificate extensions which have the greatest value in the S/MIME
+   environment.  The syntax and semantics of all the identified
+   extensions are defined in [KEYM].
+
+   Sending and receiving agents MUST correctly handle the basic
+   constraints, key usage, authority key identifier, subject key
+   identifier, and subject alternative names certificate extensions when
+   they appear in end-entity and CA certificates.  Some mechanism SHOULD
+   exist to gracefully handle other certificate extensions when they
+   appear in end-entity or CA certificates.
+
+   Certificates issued for the S/MIME environment SHOULD NOT contain any
+   critical extensions (extensions that have the critical field set to
+   TRUE) other than those listed here.  These extensions SHOULD be
+   marked as non-critical unless the proper handling of the extension is
+
+
+
+
+
+Ramsdell                    Standards Track                     [Page 9]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+   deemed critical to the correct interpretation of the associated
+   certificate.  Other extensions may be included, but those extensions
+   SHOULD NOT be marked as critical.
+
+   Interpretation and syntax for all extensions MUST follow [KEYM],
+   unless otherwise specified here.
+
+4.4.1.  Basic Constraints Certificate Extension
+
+   The basic constraints extension serves to delimit the role and
+   position that an issuing authority or end-entity certificate plays in
+   a certification path.
+
+   For example, certificates issued to CAs and subordinate CAs contain a
+   basic constraint extension that identifies them as issuing authority
+   certificates.  End-entity certificates contain an extension that
+   constrains the certificate from being an issuing authority
+   certificate.
+
+   Certificates SHOULD contain a basicConstraints extension in CA
+   certificates, and SHOULD NOT contain that extension in end entity
+   certificates.
+
+4.4.2.  Key Usage Certificate Extension
+
+   The key usage extension serves to limit the technical purposes for
+   which a public key listed in a valid certificate may be used.
+   Issuing authority certificates may contain a key usage extension that
+   restricts the key to signing certificates, certificate revocation
+   lists and other data.
+
+   For example, a certification authority may create subordinate issuer
+   certificates which contain a key usage extension which specifies that
+   the corresponding public key can be used to sign end user
+   certificates and sign CRLs.
+
+   If a key usage extension is included in a PKIX certificate, then it
+   MUST be marked as critical.
+
+   S/MIME receiving agents MUST NOT accept the signature of a message if
+   it was verified using a certificate which contains the key usage
+   extension without either the digitalSignature or nonRepudiation bit
+   set.  Sometimes S/MIME is used as a secure message transport for
+   applications beyond interpersonal messaging.  In such cases, the
+   S/MIME-enabled application can specify additional requirements
+   concerning the digitalSignature or nonRepudiation bits within this
+   extension.
+
+
+
+
+Ramsdell                    Standards Track                    [Page 10]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+   If the key usage extension is not specified, receiving clients MUST
+   presume that the digitalSignature and nonRepudiation bits are set.
+
+4.4.3.  Subject Alternative Name Extension
+
+   The subject alternative name extension is used in S/MIME as the
+   preferred means to convey the RFC-2822 email address(es) that
+   correspond(s) to the entity for this certificate.  Any RFC-2822 email
+   addresses present MUST be encoded using the rfc822Name CHOICE of the
+   GeneralName type.  Since the SubjectAltName type is a SEQUENCE OF
+   GeneralName, multiple RFC-2822 email addresses MAY be present.
+
+4.4.4.  Extended Key Usage Extension
+
+   The extended key usage extension also serves to limit the technical
+   purposes for which a public key listed in a valid certificate may be
+   used.  The set of technical purposes for the certificate therefore
+   are the intersection of the uses indicated in the key usage and
+   extended key usage extensions.
+
+   For example, if the certificate contains a key usage extension
+   indicating digital signature and an extended key usage extension
+   which includes the email protection OID, then the certificate may be
+   used for signing but not encrypting S/MIME messages.  If the
+   certificate contains a key usage extension indicating digital
+   signature, but no extended key usage extension then the certificate
+   may also be used to sign but not encrypt S/MIME messages.
+
+   If the extended key usage extension is present in the certificate
+   then interpersonal message S/MIME receiving agents MUST check that it
+   contains either the emailProtection or the anyExtendedKeyUsage OID as
+   defined in [KEYM].  S/MIME uses other than interpersonal messaging
+   MAY require the explicit presence of the extended key usage extension
+   or other OIDs to be present in the extension or both.
+
+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
+
+
+
+Ramsdell                    Standards Track                    [Page 11]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+   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 noticeable 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.
+
+   At the Selected Areas in Cryptography '95 conference in May 1995,
+   Rogier and Chauvaud presented an attack on MD2 that can nearly find
+   collisions [RC95].  Collisions occur when one can find two different
+   messages that generate the same message digest.  A checksum operation
+   in MD2 is the only remaining obstacle to the success of the attack.
+   For this reason, the use of MD2 for new applications is discouraged.
+   It is still reasonable to use MD2 to verify existing signatures, as
+   the ability to find collisions in MD2 does not enable an attacker to
+   find new messages having a previously computed hash value.
+
+   It is possible for there to be multiple unexpired CRLs for a CA.  If
+   an agent is consulting CRLs for certificate validation, it SHOULD
+   make sure that the most recently issued CRL for that CA is consulted,
+   since an S/MIME message sender could deliberately include an older
+   unexpired CRL in an S/MIME message.  This older CRL might not include
+   recent revoked certificates, which might lead an agent to accept a
+   certificate that has been revoked in a subsequent CRL.
+
+   When determining the time for a certificate validity check, agents
+   have to be careful to use a reliable time.  Unless it is from a
+   trusted agent, this time MUST NOT be the SigningTime attribute found
+   in an S/MIME message.  For most sending agents, the SigningTime
+   attribute could be deliberately set to direct the receiving agent to
+
+
+
+
+Ramsdell                    Standards Track                    [Page 12]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+   check a CRL that could have out-of-date revocation status for a
+   certificate, or cause an improper result when checking the Validity
+   field of a certificate.
+
+A.  References
+
+A.1.  Normative References
+
+   [ACAUTH]     Farrell, S. and R. Housley, "An Internet Attribute
+                Certificate Profile for Authorization", RFC 3281, April
+                2002.
+
+   [CMS]        Housely, R., "Cryptographic Message Syntax (CMS)", RFC
+                3852, July 2004.
+
+   [CMSALG]     Housley, R., "Cryptographic Message Syntax (CMS)
+                Algorithms", RFC 3370, August 2002.
+
+   [KEYM]       Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+                X.509 Public Key Infrastructure Certificate and
+                Certificate Revocation List (CRL) Profile", RFC 3280,
+                April 2002.
+
+   [KEYMALG]    Bassham, L., Polk, W., and R. Housley, "Algorithms and
+                Identifiers for the Internet X.509 Public Key
+                Infrastructure Certificate and Certificate Revocation
+                List (CRL) Profile", RFC 3279, April 2002.
+
+   [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [PKCS9]      Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
+                Classes and Attribute Types Version 2.0", RFC 2985,
+                November 2000.
+
+   [RFC-2822],  Resnick, P., "Internet Message Format", RFC 2822, April
+                2001.
+
+   [SMIME-MSG]  Ramsdell, B., Ed., "S/MIME Version 3.1 Message
+                Specification", RFC 3851, July 2004.
+
+   [x.208-88]   ITU-T. Recommendation X.208: Specification of Abstract
+                Syntax Notation One (ASN.1). 1988.
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 13]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+A.2.  Informative References
+
+   [CERTV2]     Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
+                "S/MIME Version 2 Certificate Handling", RFC 2312, March
+                1998.
+
+   [PKCS6]      RSA Laboratories, "PKCS #6: Extended-Certificate Syntax
+                Standard", November 1993.
+
+   [RC95]       Rogier, N. and Chauvaud, P., "The compression function
+                of MD2 is not collision free," Presented at Selected
+                Areas in Cryptography '95, May 1995.
+
+   [SECLABEL]   Nicolls, W., "Implementing Company Classification Policy
+                with the S/MIME Security Label", RFC 3114, May 2002.
+
+   [X.500]      ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997,
+                Information technology - Open Systems Interconnection -
+                The Directory:  Overview of concepts, models and
+                services.
+
+   [X.501]      ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997,
+                Information technology - Open Systems Interconnection -
+                The Directory:  Models.
+
+   [X.509]      ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997,
+                Information technology - Open Systems Interconnection -
+                The Directory:  Authentication framework.
+
+   [X.520]      ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997,
+                Information technology - Open Systems Interconnection -
+                The Directory:  Selected attribute types.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 14]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+B.  Acknowledgements
+
+   Many thanks go out to the other authors of the S/MIME v2 RFC: Steve
+   Dusse, Paul Hoffman and Jeff Weinstein.  Without v2, there wouldn't
+   be a v3.
+
+   A number of the members of the S/MIME Working Group have also worked
+   very hard and contributed to this document.  Any list of people is
+   doomed to omission and for that I apologize.  In alphabetical order,
+   the following people stand out in my mind due to the fact that they
+   made direct contributions to this document.
+
+   Bill Flanigan
+   Trevor Freeman
+   Elliott Ginsburg
+   Paul Hoffman
+   Russ Housley
+   David P. Kemp
+   Michael Myers
+   John Pawling
+   Denis Pinkas
+   Jim Schaad
+
+C.  Editor's Address
+
+   Blake Ramsdell
+   Sendmail, Inc.
+   704 228th Ave NE #775
+   Sammamish, WA  98074
+
+   EMail: blake@sendmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 15]
+
+RFC 3850            S/MIME 3.1 Certificate Handling            July 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 16]
+