doc: Add RFC documents

1 files changed, 1179 insertions, 0 deletions

diff --git a/doc/rfc/rfc5750.txt b/doc/rfc/rfc5750.txt
new file mode 100644
index 0000000..64c3e00
--- /dev/null
+++ b/doc/rfc/rfc5750.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       B. Ramsdell
+Request for Comments: 5750                              Brute Squad Labs
+Obsoletes: 3850                                                S. Turner
+Category: Standards Track                                           IECA
+ISSN: 2070-1721                                             January 2010
+
+
+   Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
+                          Certificate Handling
+
+Abstract
+
+   This document specifies conventions for X.509 certificate usage by
+   Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 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 5280, 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 5280.  This document obsoletes
+   RFC 3850.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by
+   the Internet Engineering Steering Group (IESG).  Further
+   information on Internet Standards is available in Section 2 of
+   RFC 5741.
+
+   Information about the current status of this document, any
+   errata, and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5750.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+
+
+
+Ramsdell & Turner            Standards Track                    [Page 1]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Definitions ................................................3
+      1.2. Conventions Used in This Document ..........................4
+      1.3. Compatibility with Prior Practice S/MIME ...................4
+      1.4. Changes from S/MIME v3 to S/MIME v3.1 ......................5
+      1.5. Changes since S/MIME v3.1 ..................................5
+   2. CMS Options .....................................................6
+      2.1. Certificate Revocation Lists ...............................6
+      2.2. Certificate Choices ........................................6
+      2.3. CertificateSet .............................................7
+   3. Using Distinguished Names for Internet Mail .....................8
+   4. Certificate Processing ..........................................9
+      4.1. Certificate Revocation Lists ..............................10
+      4.2. Certificate Path Validation ...............................11
+      4.3. Certificate and CRL Signing Algorithms and Key Sizes ......11
+      4.4. PKIX Certificate Extensions ...............................12
+   5. Security Considerations ........................................15
+   6. References .....................................................17
+      6.1. Reference Conventions .....................................17
+      6.2. Normative References ......................................17
+      6.3. Informative References ....................................19
+   Appendix A. Moving S/MIME v2 Certificate Handling to Historic
+               Status.................................................21
+   Appendix B. Acknowledgments........................................21
+
+
+
+
+
+
+
+
+
+Ramsdell & Turner            Standards Track                    [Page 2]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+1.  Introduction
+
+   S/MIME (Secure/Multipurpose Internet Mail Extensions) v3.2, 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) RFC 5652 [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.680
+   [X.680].
+
+   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.
+
+   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].
+
+
+
+
+
+Ramsdell & Turner            Standards Track                    [Page 3]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   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.  Conventions Used in This Document
+
+   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].
+
+   We define some additional terms here:
+
+   SHOULD+    This term means the same as SHOULD.  However, the authors
+              expect that a requirement marked as SHOULD+ will be
+              promoted at some future time to be a MUST.
+
+   SHOULD-    This term means the same as SHOULD.  However, the authors
+              expect that a requirement marked as SHOULD- will be
+              demoted to a MAY in a future version of this document.
+
+   MUST-      This term means the same as MUST.  However, the authors
+              expect that this requirement will no longer be a MUST in a
+              future document.  Although its status will be determined
+              at a later time, it is reasonable to expect that if a
+              future revision of a document alters the status of a MUST-
+              requirement, it will remain at least a SHOULD or a
+              SHOULD-.
+
+1.3.  Compatibility with Prior Practice S/MIME
+
+   S/MIME version 3.2 agents ought to 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
+   [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634
+   inclusive and RFC 5035 [SMIMEv3], and S/MIME version 3.1 is described
+   in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1].
+   RFC 2311 also has historical information about the development of
+   S/MIME.
+
+
+
+
+
+
+
+Ramsdell & Turner            Standards Track                    [Page 4]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+1.4.  Changes from S/MIME v3 to S/MIME v3.1
+
+   Version 1 and version 2 CRLs MUST be supported.
+
+   Multiple certification authority (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 was 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.
+
+   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.
+
+1.5.  Changes since S/MIME v3.1
+
+   Conventions Used in This Document: Moved to Section 1.2. Added
+   definitions for SHOULD+, SHOULD-, and MUST-.
+
+   Section 1.1:   Updated ASN.1 definition and reference.
+
+   Section 1.3:   Added text about v3.1 RFCs.
+
+   Section 3:     Aligned email address text with RFC 5280.  Updated
+                  note to indicate emailAddress IA5String upper bound is
+                  255 characters.  Added text about matching email
+                  addresses.
+
+   Section 4.2:   Added text to indicate how S/MIME agents locate the
+                  correct user certificate.
+
+
+
+
+
+
+
+
+Ramsdell & Turner            Standards Track                    [Page 5]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   Section 4.3:   RSA with SHA-256 (PKCS #1 v1.5) added as MUST; DSA
+                  with SHA-256 added as SHOULD+; RSA with SHA-1, DSA
+                  with SHA-1, and RSA with MD5 changed to SHOULD-; and
+                  RSASSA-PSS with SHA-256 added as SHOULD+.  Updated key
+                  sizes and changed pointer to PKIX RFCs.
+
+   Section 4.4.1: Aligned with PKIX on use of basic constraints
+                  extension in CA certificates.  Clarified which
+                  extension is used to constrain end entities from using
+                  their keys to perform issuing authority operations.
+
+   Section 5:     Updated security considerations.
+
+   Section 7:     Moved references from Appendix B to Section 6.
+                  Updated the references.
+
+   Appendix A:    Moved Appendix A to Appendix B.  Added Appendix A to
+                  move S/MIME v2 Certificate Handling to Historic
+                  Status.
+
+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.  Certificate Revocation Lists
+
+   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.  Certificate Choices
+
+   Receiving agents MUST support v1 X.509 and v3 X.509 certificates as
+   profiled in [KEYM].  End-entity certificates MAY include an Internet
+   mail address, as described in Section 3.
+
+
+
+Ramsdell & Turner            Standards Track                    [Page 6]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+Ramsdell & Turner            Standards Track                    [Page 7]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   A sending agent SHOULD include at least one chain of certificates up
+   to, but not including, a certification 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, cross-certificates, self-
+   issued certificates, and self-signed certificates.  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 Digital Signature Algorithm (DSA) public keys
+   the parameters may be located in the root certificate.  This would
+   require that the recipient possess both the end-entity certificate
+   and the root 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 [KEYM], Section 4.2.1.6.  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 }
+
+
+
+
+
+Ramsdell & Turner            Standards Track                    [Page 8]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   Note that this attribute MUST be encoded as IA5String and has an
+   upper bound of 255 characters.  The right side of the email address
+   SHOULD be treated as ASCII-case-insensitive.
+
+   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.
+
+   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 certificates, except that the
+   subject distinguished name (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
+
+   S/MIME agents need 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 the
+   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 the
+   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
+
+
+
+Ramsdell & Turner            Standards Track                    [Page 9]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   "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 cannot 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].
+
+   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 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.
+
+
+
+
+
+Ramsdell & Turner            Standards Track                   [Page 10]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+4.2.  Certificate 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 (e.g., RSA), or forming a
+   pairwise symmetric key (e.g., 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
+   (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.
+
+   When verifying a signature and the certificates that are included in
+   the message, if a signingCertificate attribute from RFC 2634 [ESS] or
+   a signingCertificateV2 attribute from RFC 5035 [ESS] is found in an
+   S/MIME message, it SHALL be used to identify the signer's
+   certificate.  Otherwise, the certificate is identified in an S/MIME
+   message, either using the issuerAndSerialNumber, which identifies the
+   signer's certificate by the issuer's distinguished name and the
+   certificate serial number, or the subjectKeyIdentifier, which
+   identifies the signer's certificate by a key identifier.
+
+   When decrypting an encrypted message, if a
+   SMIMEEncryptionKeyPreference attribute is found in an encapsulating
+   SignedData, it SHALL be used to identify the originator's certificate
+   found in OriginatorInfo.  See [CMS] for the CMS fields that reference
+   the originator's and recipient's certificates.
+
+4.3.  Certificate and CRL Signing Algorithms and Key Sizes
+
+   Certificates and Certificate Revocation Lists (CRLs) are signed by
+   the certificate issuer.  Receiving agents:
+
+    - MUST support RSA with SHA-256
+
+    - SHOULD+ support DSA with SHA-256
+
+
+
+Ramsdell & Turner            Standards Track                   [Page 11]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+    - SHOULD+ support RSASSA-PSS with SHA-256
+
+    - SHOULD- support RSA with SHA-1
+
+    - SHOULD- support DSA with SHA-1
+
+    - SHOULD- support RSA with MD5
+
+   The following are the RSA and RSASSA-PSS key size requirements for
+   S/MIME receiving agents during certificate and CRL signature
+   verification:
+
+           key size <= 1023 : MAY  (see Section 5)
+   1024 <= key size <= 4096 : MUST (see Section 5)
+   4096 <  key size         : MAY  (see Section 5)
+
+   The following are the DSA key size requirements for S/MIME receiving
+   agents during certificate and CRL signature verification:
+
+            key size <= 1023 : MAY  (see Section 5)
+    1024 <= key size <= 3072 : MUST (see Section 5)
+
+   For 512-bit RSA with SHA-1 see [KEYMALG] and [FIPS186-2] without
+   Change Notice 1, for 512-bit RSA with SHA-256 see [RSAOAEP] and
+   [FIPS186-2] without Change Notice 1, for 1024-bit through 3072-bit
+   RSA with SHA-256 see [RSAOAEP] and [FIPS186-2] with Change Notice 1,
+   and for 4096-bit RSA with SHA-256 see [RSAOAEP] and [PKCS1].  In
+   either case, the first reference provides the signature algorithm's
+   object identifier and the second provides the signature algorithm's
+   definition.
+
+   For 512-bit DSA with SHA-1 see [KEYMALG] and [FIPS186-2] without
+   Change Notice 1, for 512-bit DSA with SHA-256 see [KEYMALG2] and
+   [FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
+   [KEYMALG] and [FIPS186-2] with Change Notice 1, for 1024-bit through
+   3072 DSA with SHA-256 see [KEYMALG2] and [FIPS186-3].  In either
+   case, the first reference provides the signature algorithm's object
+   identifier and the second provides the signature algorithm's
+   definition.
+
+   For RSASSA-PSS with SHA-256 see [RSAPSS].
+
+4.4.  PKIX Certificate Extensions
+
+   PKIX describes an extensible framework in which the basic certificate
+   information can be extended and describes 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
+
+
+
+Ramsdell & Turner            Standards Track                   [Page 12]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   extensions that 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 that 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
+   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
+
+   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 the key usage
+   extension that restrains end entities from using the key when
+   performing issuing authority operations (see Section 4.4.2).
+
+   As per [KEYM], certificates MUST 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.
+
+
+
+Ramsdell & Turner            Standards Track                   [Page 13]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   For example, a certification authority may create subordinate issuer
+   certificates that contain a key usage extension that 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 that 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.
+
+   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
+
+   The subject alternative name extension is used in S/MIME as the
+   preferred means to convey the email address(es) that correspond(s) to
+   the entity for this certificate.  Any email addresses present MUST be
+   encoded using the rfc822Name CHOICE of the GeneralName type as
+   described in [KEYM], Section 4.2.1.6.  Since the SubjectAltName type
+   is a SEQUENCE OF GeneralName, multiple 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 that
+   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.
+
+
+
+
+
+
+Ramsdell & Turner            Standards Track                   [Page 14]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   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
+   to handle such failures.  Just because the methods to handle the
+   failures have 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 match 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
+
+
+
+
+
+
+
+Ramsdell & Turner            Standards Track                   [Page 15]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   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.
+
+   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
+   recently 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
+   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.
+
+   In addition to the Security Considerations identified in [KEYM],
+   caution should be taken when processing certificates that have not
+   first been validated to a trust anchor.  Certificates could be
+   manufactured by untrusted sources for the purpose of mounting denial
+   of service or other attacks.  For example, keys selected to require
+   excessive cryptographic processing, or extensive lists of CRL
+   Distribution Point (CDP) and/or Authority Information Access (AIA)
+   addresses in the certificate, could be used to mount denial-of-
+   service attacks.  Similarly, attacker-specified CDP and/or AIA
+   addresses could be included in fake certificates to allow the
+   originator to detect receipt of the message even if signature
+   verification fails.
+
+   The 4096-bit RSA key size requirement for certificate and CRL
+   verification is larger than the 2048-bit RSA key sizes for message
+   signature generation/verification or message encryption/decryption in
+   [SMIME-MSG] because many root CAs included in certificate stores have
+   already issued root certificates with the 4096-bit key.  The standard
+   that defines comparable key sizes for DSA is not yet available.  In
+   particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes
+   between 512 and 1024 bits, [FIPS186-2] with Change Notice 1 only
+   allowed DSA key sizes of 1024 bits, and [FIPS186-3] allowed DSA key
+   sizes from 1024 to 3072 bits.  Further, 4096-bit keys are normally
+   only used by Root certificates and not by subordinate CA
+   certificates, thereby lengthening the root CA certificate's validity
+   period.
+
+
+
+Ramsdell & Turner            Standards Track                   [Page 16]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   RSA and DSA keys of less than 1024 bits are now considered by many
+   experts to be cryptographically insecure (due to advances in
+   computing power), and should no longer be used to sign certificates
+   or CRLs.  Such keys were previously considered secure, so processing
+   previously received signed and encrypted mail may require processing
+   certificates or CRLs signed with weak keys.  Implementations that
+   wish to support previous versions of S/MIME or process old messages
+   need to consider the security risks that result from accepting
+   certificates and CRLs with smaller key sizes (e.g., spoofed
+   certificates) versus the costs of denial of service.  If an
+   implementation supports verification of certificates or CRLs
+   generated with RSA and DSA keys of less than 1024 bits, it MUST warn
+   the user.  Implementers should consider providing a stronger warning
+   for weak signatures on certificates and CRLs associated with newly
+   received messages than the one provided for certificates and CRLs
+   associated with previously stored messages.  Server implementations
+   (e.g., secure mail list servers) where user warnings are not
+   appropriate SHOULD reject messages with weak cryptography.
+
+   If an implementation is concerned about compliance with National
+   Institute of Standards and Technology (NIST) key size
+   recommendations, then see [SP800-57].
+
+6.  References
+
+6.1.  Reference Conventions
+
+   [CMS] refers to [RFC5652].
+
+   [ESS] refers to [RFC2634] and [RFC5035].
+
+   [SMIMEv2] refers to [RFC2311], [RFC2312], [RFC2313], [RFC2314], and
+   [RFC2315].
+
+   [SMIMEv3] refers to [RFC2630], [RFC2631], [RFC2632], [RFC2633],
+   [RFC2634], and [RFC5035].
+
+   [SMIMv3.1] refers to [RFC2634], [RFC3850], [RFC3851], [RFC3852], and
+   [RFC5035].
+
+6.2.  Normative References
+
+   [ACAUTH]     Farrell, S., Housley, R., and S. Turner, "An Internet
+                Attribute Certificate Profile for Authorization", RFC
+                5755, January 2010.
+
+   [RFC2634]    Hoffman, P., Ed., "Enhanced Security Services for
+                S/MIME", RFC 2634, June 1999.
+
+
+
+Ramsdell & Turner            Standards Track                   [Page 17]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   [RFC5035]    Schaad, J., "Enhanced Security Services (ESS) Update:
+                Adding CertID Algorithm Agility", RFC 5035, August 2007.
+
+   [RFC5652]    Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+                5652, September 2009.
+
+   [FIPS186-2]  National Institute of Standards and Technology (NIST),
+                "Digital Signature Standard (DSS)", FIPS Publication
+                186-3, January 2000. [With Change Notice 1]
+
+   [FIPS186-3]  National Institute of Standards and Technology (NIST),
+                FIPS Publication 186-3: Digital Signature Standard, June
+                2009.
+
+   [KEYM]       Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+                Housley, R., and W. Polk, "Internet X.509 Public Key
+                Infrastructure Certificate and Certificate Revocation
+                List (CRL) Profile", RFC 5280, May 2008.
+
+   [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.
+
+   [KEYMALG2]   Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
+                Polk, "Internet X.509 Public Key Infrastructure:
+                Additional Algorithms and Identifiers for DSA and
+                ECDSA", RFC 5758, January 2010.
+
+   [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [PKCS1]      Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+                Standards (PKCS) #1: RSA Cryptography Specifications
+                Version 2.1", RFC 3447, February 2003.
+
+   [PKCS9]      Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
+                Classes and Attribute Types Version 2.0", RFC 2985,
+                November 2000.
+
+   [RSAPSS]     Schaad, J., "Use of the RSASSA-PSS Signature Algorithm
+                in Cryptographic Message Syntax (CMS)", RFC 4056, June
+                2005.
+
+
+
+
+
+
+
+
+Ramsdell & Turner            Standards Track                   [Page 18]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   [RSAOAEP]    Schaad, J., Kaliski, B., and R. Housley, "Additional
+                Algorithms and Identifiers for RSA Cryptography for use
+                in the Internet X.509 Public Key Infrastructure
+                Certificate and Certificate Revocation List (CRL)
+                Profile", RFC 4055, June 2005.
+
+   [SMIME-MSG]  Ramsdell, B. and S. Turner, "Secure/Multipurpose
+                Internet Mail Extensions (S/MIME) Version 3.2 Message
+                Specification", RFC 5751, January 2010.
+
+   [X.680]      ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.
+                Information Technology - Abstract Syntax Notation One
+                (ASN.1):  Specification of basic notation.
+
+6.3.  Informative References
+
+   [PKCS6]      RSA Laboratories, "PKCS #6: Extended-Certificate Syntax
+                Standard", November 1993.
+
+   [SECLABEL]   Nicolls, W., "Implementing Company Classification Policy
+                with the S/MIME Security Label", RFC 3114, May 2002.
+
+   [RFC2311]    Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
+                L. Repka, "S/MIME Version 2 Message Specification", RFC
+                2311, March 1998.
+
+   [RFC2312]    Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
+                "S/MIME Version 2 Certificate Handling", RFC 2312, March
+                1998.
+
+   [RFC2313]    Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC
+                2313, March 1998.
+
+   [RFC2314]    Kaliski, B., "PKCS #10: Certification Request Syntax
+                Version 1.5", RFC 2314, March 1998.
+
+   [RFC2315]    Kaliski, B., "PKCS #7: Cryptographic Message Syntax
+                Version 1.5", RFC 2315, March 1998.
+
+   [RFC2630]    Housley, R., "Cryptographic Message Syntax", RFC 2630,
+                June 1999.
+
+   [RFC2631]    Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
+                2631, June 1999.
+
+   [RFC2632]    Ramsdell, B., Ed., "S/MIME Version 3 Certificate
+                Handling", RFC 2632, June 1999.
+
+
+
+
+Ramsdell & Turner            Standards Track                   [Page 19]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+   [RFC2633]    Ramsdell, B., Ed., "S/MIME Version 3 Message
+                Specification", RFC 2633, June 1999.
+
+   [RFC3850]    Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
+                Extensions (S/MIME) Version 3.1 Certificate Handling",
+                RFC 3850, July 2004.
+
+   [RFC3851]    Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
+                Extensions (S/MIME) Version 3.1 Message Specification",
+                RFC 3851, July 2004.
+
+   [RFC3852]    Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+                3852, July 2004.
+
+   [SP800-57]   National Institute of Standards and Technology (NIST),
+                Special Publication 800-57: Recommendation for Key
+                Management, August 2005.
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell & Turner            Standards Track                   [Page 20]
+
+RFC 5750             S/MIME 3.2 Certificate Handling        January 2010
+
+
+Appendix A.  Moving S/MIME v2 Certificate Handling to Historic Status
+
+   The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document)
+   are backwards compatible with the S/MIME v2 Certificate Handling
+   Specification [SMIMEv2], with the exception of the algorithms
+   (dropped RC2/40 requirement and added DSA and RSASSA-PSS
+   requirements).  Therefore, it is recommended that RFC 2312 [SMIMEv2]
+   be moved to Historic status.
+
+Appendix B.  Acknowledgments
+
+   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, v3.1, or v3.2.
+
+   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 because they made direct
+   contributions to this document.
+
+   Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Alfred Hoenes, Paul
+   Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling,
+   Denis Pinkas, and Jim Schaad.
+
+Authors' Addresses
+
+   Blake Ramsdell
+   Brute Squad Labs, Inc.
+
+   EMail: blaker@gmail.com
+
+
+   Sean Turner
+   IECA, Inc.
+   3057 Nutley Street, Suite 106
+   Fairfax, VA 22031
+   USA
+
+   EMail: turners@ieca.com
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell & Turner            Standards Track                   [Page 21]
+