Draft: draft-schaad-rfc5751-bis

Commentary: Get the files correct get references working better play with the file
This specification defines how to create a MIME body part that has
been cryptographically enhanced according to the Cryptographic
Message Syntax (CMS) RFC 5652 [CMS], which is derived from PKCS #7
[PKCS-7].  This specification also defines the application/pkcs7-mime
media type that can be used to transport those body parts.
This document also discusses how to use the multipart/signed media
type defined in [MIME-SECURE] to transport S/MIME signed messages.
multipart/signed is used in conjunction with the application/pkcs7-
signature media type, which is used to transport a detached S/MIME
signature.
In order to create S/MIME messages, an S/MIME agent MUST follow the
specifications in this document, as well as the specifications listed
in the Cryptographic Message Syntax document [CMS], [CMSALG],
[RSAPSS], [RSAOAEP], and [CMS-SHA2].
This specification defines how to create a MIME body part that has
been cryptographically enhanced according to the Cryptographic
Message Syntax (CMS) RFC 5652 [CMS], which is derived from PKCS #7
RFC2315.  This specification also defines the application/pkcs7-mime
media type that can be used to transport those body parts.
This document also discusses how to use the multipart/signed media
type defined in RFC1847 to transport S/MIME signed messages.
multipart/signed is used in conjunction with the application/pkcs7-
signature media type, which is used to transport a detached S/MIME
signature.
In order to create S/MIME messages, an S/MIME agent MUST follow the
specifications in this document, as well as the specifications listed
in the Cryptographic Message Syntax document [CMS], RFC3370, RFC4056,
RFC3560, and RFC5754.
Abstract Syntax Notation One, as defined in ITU-T Recommendation
X.680 [X.680].
Basic Encoding Rules for ASN.1, as defined in ITU- T
Recommendation X.690 [X.690].
Distinguished Encoding Rules for ASN.1, as defined in ITU-T
Recommendation X.690 [X.690].
Abstract Syntax Notation One, as defined in ITU-T Recommendation
X.680 X.680.
Basic Encoding Rules for ASN.1, as defined in ITU- T
Recommendation X.690 X.690.
Distinguished Encoding Rules for ASN.1, as defined in ITU-T
Recommendation X.690 X.690.
CMS allows for a wide variety of options in content, attributes, 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.  [CMSALG] and
[CMS-SHA2] provides additional details regarding the use of the
cryptographic algorithms.  [ESS] provides additional details
regarding the use of additional attributes.
Sending and receiving agents MUST support SHA-256 [CMS-SHA2] and
SHOULD- support SHA-1 [CMSALG].  Receiving agents SHOULD- support MD5
[CMSALG] for the purpose of providing backward compatibility with
MD5-digested S/MIME v2 SignedData objects.
CMS allows for a wide variety of options in content, attributes, 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.  RFC3370 and
RFC5754 provides additional details regarding the use of the
cryptographic algorithms.  [ESS] provides additional details
regarding the use of additional attributes.
Sending and receiving agents MUST support SHA-256 RFC5754 and SHOULD-
support SHA-1 RFC3370.  Receiving agents SHOULD- support MD5 RFC3370
for the purpose of providing backward compatibility with MD5-digested
S/MIME v2 SignedData objects.
MUST support RSA Encryption, as specified in [CMSALG].
SHOULD+ support RSAES-OAEP, as specified in [RSAOAEP].
SHOULD- support DH ephemeral-static mode, as specified in [CMSALG]
and [SP800-57].
When DH ephemeral-static is used, a key wrap algorithm is also
specified in the KeyEncryptionAlgorithmIdentifier [CMS].  The
underlying encryption functions for the key wrap and content
encryption algorithm ([CMSALG] and [CMSAES]) and the key sizes for
the two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
with AES-128 content encryption algorithm).  As AES-128 CBC is the
mandatory-to-implement content encryption algorithm, the AES-128 key
wrap algorithm MUST also be supported when DH ephemeral-static is
used.
MUST support RSA Encryption, as specified in RFC3370.
SHOULD+ support RSAES-OAEP, as specified in RFC3560.
SHOULD- support DH ephemeral-static mode, as specified in RFC3370
and SP800-57.
When DH ephemeral-static is used, a key wrap algorithm is also
specified in the KeyEncryptionAlgorithmIdentifier [CMS].  The
underlying encryption functions for the key wrap and content
encryption algorithm (RFC3370 and RFC3565) and the key sizes for the
two algorithms MUST be the same (e.g., AES-128 key wrap algorithm
with AES-128 content encryption algorithm).  As AES-128 CBC is the
mandatory-to-implement content encryption algorithm, the AES-128 key
wrap algorithm MUST also be supported when DH ephemeral-static is
used.
MUST support encryption and decryption with AES-128 CBC [CMSAES].
SHOULD+ support encryption and decryption with AES-192 CBC and
AES-256 CBC [CMSAES].
SHOULD- support encryption and decryption with DES EDE3 CBC,
hereinafter called "tripleDES" [CMSALG].
MUST support encryption and decryption with AES-128 CBC RFC3565.
SHOULD+ support encryption and decryption with AES-192 CBC and
AES-256 CBC RFC3565.
SHOULD- support encryption and decryption with DES EDE3 CBC,
hereinafter called "tripleDES" RFC3370.
The reader of this section is expected to understand MIME as
described in [MIME-SPEC] and [MIME-SECURE].
The reader of this section is expected to understand MIME as
described in [MIME-SPEC] and RFC1847.
The most common and important canonicalization is for text, which is
often represented differently in different environments.  MIME
entities of major type "text" MUST have both their line endings and
character set canonicalized.  The line ending MUST be the pair of
characters <CR><LF>, and the charset SHOULD be a registered charset
[CHARSETS].  The details of the canonicalization are specified in
[MIME-SPEC].
The most common and important canonicalization is for text, which is
often represented differently in different environments.  MIME
entities of major type "text" MUST have both their line endings and
character set canonicalized.  The line ending MUST be the pair of
characters <CR><LF>, and the charset SHOULD be a registered charset
CHARSETS.  The details of the canonicalization are specified in
[MIME-SPEC].
RFC1847 prohibits an agent from changing the transfer encoding of the
first part of a multipart/signed message.  If a compliant agent that
cannot transmit 8-bit or binary data encounters a multipart/signed
message with 8-bit or binary data in the first part, it would have to
return the message to the sender as undeliverable.
This format is a clear-signing format.  Recipients without any S/MIME
or CMS processing facilities are able to view the message.  It makes
use of the multipart/signed media type described in [MIME-SECURE].
The multipart/signed media type has two parts.  The first part
contains the MIME entity that is signed; the second part contains the
"detached signature" CMS SignedData object in which the
encapContentInfo eContent field is absent.
This format is a clear-signing format.  Recipients without any S/MIME
or CMS processing facilities are able to view the message.  It makes
use of the multipart/signed media type described in RFC1847.  The
multipart/signed media type has two parts.  The first part contains
the MIME entity that is signed; the second part contains the
"detached signature" CMS SignedData object in which the
encapContentInfo eContent field is absent.
This section describes the format for compressing a MIME entity.
Please note that versions of S/MIME prior to version 3.1 did not
specify any use of CompressedData, and will not recognize it.  The
use of a capability to indicate the ability to receive CompressedData
is described in [CMSCOMPR] and is the preferred method for
compatibility.
This section describes the format for compressing a MIME entity.
Please note that versions of S/MIME prior to version 3.1 did not
specify any use of CompressedData, and will not recognize it.  The
use of a capability to indicate the ability to receive CompressedData
is described in RFC3274 and is the preferred method for
compatibility.
A receiving agent MUST provide some certificate retrieval mechanism
in order to gain access to certificates for recipients of digital
envelopes.  This specification does not cover how S/MIME agents
handle certificates, only what they do after a certificate has been
validated or rejected.  S/MIME certificate issues are covered in
[CERT32].
A receiving agent MUST provide some certificate retrieval mechanism
in order to gain access to certificates for recipients of digital
envelopes.  This specification does not cover how S/MIME agents
handle certificates, only what they do after a certificate has been
validated or rejected.  S/MIME certificate issues are covered in
RFC5750.
All generated key pairs MUST be generated from a good source of non-
deterministic random input [RANDOM] and the private key MUST be
protected in a secure fashion.
For 512-bit RSA with SHA-1 see [CMSALG] and [FIPS186-2] without
Change Notice 1, for 512-bit RSA with SHA-256 see [CMS-SHA2] and
[FIPS186-2] without Change Notice 1, and for 1024-bit through
2048-bit RSA with SHA-256 see [CMS-SHA2] and [FIPS186-2] with Change
Notice 1.  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 [CMSALG] and [FIPS186-2] without
Change Notice 1, for 512-bit DSA with SHA-256 see [CMS-SHA2] and
[FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
[CMSALG] and [FIPS186-2] with Change Notice 1, for 1024-bit and above
DSA with SHA-256 see [CMS-SHA2] and [FIPS186-3].  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].  For 1024-bit DH, see
[CMSALG].  For 1024-bit and larger DH, see [SP800-56A]; regardless,
use the KDF, which is from X9.42, specified in [CMSALG].  For RSAES-
OAEP, see [RSAOAEP].
All generated key pairs MUST be generated from a good source of non-
deterministic random input RFC4086 and the private key MUST be
protected in a secure fashion.
For 512-bit RSA with SHA-1 see RFC3370 and FIPS186-2 without Change
Notice 1, for 512-bit RSA with SHA-256 see RFC5754 and FIPS186-2
without Change Notice 1, and for 1024-bit through 2048-bit RSA with
SHA-256 see RFC5754 and FIPS186-2 with Change Notice 1.  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 RFC3370 and FIPS186-2 without Change
Notice 1, for 512-bit DSA with SHA-256 see RFC5754 and FIPS186-2
without Change Notice 1, for 1024-bit DSA with SHA-1 see RFC3370 and
FIPS186-2 with Change Notice 1, for 1024-bit and above DSA with
SHA-256 see RFC5754 and FIPS186-3.  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 RFC4056.  For 1024-bit DH, see
RFC3370.  For 1024-bit and larger DH, see SP800-56A; regardless, use
the KDF, which is from X9.42, specified in RFC3370.  For RSAES- OAEP,
see RFC3560.
The Million Message Attack described in RFC 3218 [MMA].
The Diffie-Hellman "small-subgroup" attacks described in RFC 2785
[DHSUB].
The attacks against hash algorithms described in RFC 4270 [HASH-
ATTACK].
The Million Message Attack described in RFC 3218 RFC3218.
The Diffie-Hellman "small-subgroup" attacks described in RFC 2785
RFC2785.
The attacks against hash algorithms described in RFC 4270 RFC4270.
The choice of 2048 bits as the RSA asymmetric key size in this
specification is based on the desire to provide at least 100 bits of
security.  The key sizes that must be supported to conform to this
specification seem appropriate for the Internet based on [STRENGTH].
Of course, there are environments, such as financial and medical
systems, that may select different key sizes.  For this reason, an
implementation MAY support key sizes beyond those recommended in this
specification.
The choice of 2048 bits as the RSA asymmetric key size in this
specification is based on the desire to provide at least 100 bits of
security.  The key sizes that must be supported to conform to this
specification seem appropriate for the Internet based on RFC3766.  Of
course, there are environments, such as financial and medical
systems, that may select different key sizes.  For this reason, an
implementation MAY support key sizes beyond those recommended in this
specification.
If an implementation is concerned about compliance with National
Institute of Standards and Technology (NIST) key size
recommendations, then see [SP800-57].
If an implementation is concerned about compliance with National
Institute of Standards and Technology (NIST) key size
recommendations, then see SP800-57.
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].
S/MIME (Secure/Multipurpose Internet Mail Extensions) v3.2, described
in RFC5751, 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 RFC5280.  S/MIME agents MUST meet the
certificate processing requirements documented in this document in
addition to those stated in RFC5280.
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.
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 RFC5755.
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 RFC5280.
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].
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
RFC5280.  The CRL is signed by the issuer.  The type intended by this
specification is the one defined in RFC5280.
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].
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 RFC2119.
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].
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.
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 RFC5751.
Receiving agents MUST support the Certificate Revocation List (CRL)
format defined in RFC5280.  If sending agents include CRLs in
outgoing messages, the CRL format defined in RFC5280 MUST be used.
In all cases, both v1 and v2 CRLs MUST be supported.
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.
Receiving agents SHOULD support X.509 version 2 attribute
certificates.  See [ACAUTH] for details about the profile for
attribute 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.
Receiving agents MUST support v1 X.509 and v3 X.509 certificates as
profiled in RFC5280.  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 RFC5755 for details about the profile for
attribute 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.
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].
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 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 RFC3114.
End-entity certificates MAY contain an Internet mail address as
described in RFC5280, Section 4.2.1.6.  The email address SHOULD be
in the subjectAltName extension, and SHOULD NOT be in the subject
distinguished name.
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.
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 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].
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 RFC5751.
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.
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 RFC5280 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.
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].
For 512-bit RSA with SHA-1 see RFC3279 and FIPS186-2 without Change
Notice 1, for 512-bit RSA with SHA-256 see RFC4055 and FIPS186-2
without Change Notice 1, for 1024-bit through 3072-bit RSA with
SHA-256 see RFC4055 and FIPS186-2 with Change Notice 1, and for
4096-bit RSA with SHA-256 see RFC4055 and RFC3447.  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 RFC3279 and FIPS186-2 without Change
Notice 1, for 512-bit DSA with SHA-256 see RFC5758 and FIPS186-2
without Change Notice 1, for 1024-bit DSA with SHA-1 see RFC3279 and
FIPS186-2 with Change Notice 1, for 1024-bit through 3072 DSA with
SHA-256 see RFC5758 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 RFC4056.
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
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].
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
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 RFC5280.
Interpretation and syntax for all extensions MUST follow [KEYM],
unless otherwise specified here.
Interpretation and syntax for all extensions MUST follow RFC5280,
unless otherwise specified here.
As per [KEYM], certificates MUST contain a basicConstraints extension
in CA certificates, and SHOULD NOT contain that extension in end-
entity certificates.
As per RFC5280, certificates MUST contain a basicConstraints
extension in CA certificates, and SHOULD NOT contain that extension
in end- entity certificates.
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.
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 RFC5280, Section 4.2.1.6.  Since the SubjectAltName type
is a SEQUENCE OF GeneralName, multiple email addresses MAY be
present.
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.
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 RFC5280.  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.
In addition to the Security Considerations identified in [KEYM],
In addition to the Security Considerations identified in RFC5280,
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.
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
RFC5751 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.