Draft: draft-schaad-rfc5751-bis

Commentary: Use a reference for the reference group concept coming in xml2rfc  but using the annotations to make it work . This has a problem in that we need to fix xml2rfc to work correctly when generating HTML output but it does the right thing for text files .
This document describes a protocol for adding cryptographic signature
and encryption services to MIME data.  The MIME standard [MIME-SPEC]
provides a general structure for the content of Internet messages and
allows extensions for new content-type-based applications.
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 describes a protocol for adding cryptographic signature
and encryption services to MIME data.  The MIME standard MIME-SPEC
provides a general structure for the content of Internet messages and
allows extensions for new content-type-based applications.
This specification defines how to create a MIME body part that has
been cryptographically enhanced according to the Cryptographic
Message Syntax (CMS) RFC 5652 RFC5652, 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.
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.
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 RFC5652, RFC3370,
RFC4056, RFC3560, and RFC5754.
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.
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.
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.
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.
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.
When DH ephemeral-static is used, a key wrap algorithm is also
specified in the KeyEncryptionAlgorithmIdentifier RFC5652.  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.
Further, receiving agents SHOULD be able to handle zero or one
instance of the signingCertificate and signingCertificatev2 signed
attributes, as defined in Section 5 of RFC 2634 [ESS] and Section 3
of RFC 5035 [ESS].
Further, receiving agents SHOULD be able to handle zero or one
instance of the signingCertificate and signingCertificatev2 signed
attributes, as defined in Section 5 of RFC 2634 ESS and Section 3 of
RFC 5035 ESS.
This section describes the S/MIME message formats and how they are
created.  S/MIME messages are a combination of MIME bodies and CMS
content types.  Several media types as well as several CMS content
types are used.  The data to be secured is always a canonical MIME
entity.  The MIME entity and other data, such as certificates and
algorithm identifiers, are given to CMS processing facilities that
produce a CMS object.  Finally, the CMS object is wrapped in MIME.
The Enhanced Security Services for S/MIME [ESS] document provides
descriptions of how nested, secured S/MIME messages are formatted.
ESS provides a description of how a triple-wrapped S/MIME message is
formatted using multipart/signed and application/pkcs7-mime for the
signatures.
This section describes the S/MIME message formats and how they are
created.  S/MIME messages are a combination of MIME bodies and CMS
content types.  Several media types as well as several CMS content
types are used.  The data to be secured is always a canonical MIME
entity.  The MIME entity and other data, such as certificates and
algorithm identifiers, are given to CMS processing facilities that
produce a CMS object.  Finally, the CMS object is wrapped in MIME.
The Enhanced Security Services for S/MIME ESS document provides
descriptions of how nested, secured S/MIME messages are formatted.
ESS provides a description of how a triple-wrapped S/MIME message is
formatted using multipart/signed and application/pkcs7-mime for the
signatures.
The reader of this section is expected to understand MIME as
described in [MIME-SPEC] and RFC1847.
The reader of this section is expected to understand MIME as
described in MIME-SPEC and RFC1847.
The procedure for preparing a MIME entity is given in [MIME-SPEC].
The same procedure is used here with some additional restrictions
when signing.  The description of the procedures from [MIME-SPEC] is
repeated here, but it is suggested that the reader refer to that
document for the exact procedure.  This section also describes
additional requirements.
The procedure for preparing a MIME entity is given in MIME-SPEC.  The
same procedure is used here with some additional restrictions when
signing.  The description of the procedures from MIME-SPEC is
repeated here, but it is suggested that the reader refer to that
document for the exact procedure.  This section also describes
additional requirements.
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.
The carried CMS object always contains a MIME entity that is prepared
as described in Section 3.1 if the eContentType is id-data.  Other
contents MAY be carried when the eContentType contains different
values.  See [ESS] for an example of this with signed receipts.
The carried CMS object always contains a MIME entity that is prepared
as described in Section 3.1 if the eContentType is id-data.  Other
contents MAY be carried when the eContentType contains different
values.  See ESS for an example of this with signed receipts.
The MIME entity and other required data is processed into a CMS
object of type EnvelopedData.  In addition to encrypting a copy of
the content-encryption key for each recipient, a copy of the
content-encryption key SHOULD be encrypted for the originator and
included in the EnvelopedData (see [CMS], Section 6).
The MIME entity and other required data is processed into a CMS
object of type EnvelopedData.  In addition to encrypting a copy of
the content-encryption key for each recipient, a copy of the
content-encryption key SHOULD be encrypted for the originator and
included in the EnvelopedData (see RFC5652, Section 6).
S/MIME v2 [SMIMEv2] specified a method for "registering" public keys
with certificate authorities using an application/pkcs10 body part.
Since that time, the IETF PKIX Working Group has developed other
methods for requesting certificates.  However, S/MIME v3.2 does not
require a particular certificate request mechanism.
S/MIME v2 SMIMEv2 specified a method for "registering" public keys
with certificate authorities using an application/pkcs10 body part.
Since that time, the IETF PKIX Working Group has developed other
methods for requesting certificates.  However, S/MIME v3.2 does not
require a particular certificate request mechanism.
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.
This specification is compatible with the Cryptographic Message
Syntax (CMS) RFC 5652 RFC5652 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.
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.
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.
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 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.
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 RFC5652 for the CMS fields that
reference the originator's and recipient's certificates.