doc: Add RFC documents

1 files changed, 386 insertions, 0 deletions

diff --git a/doc/rfc/rfc8933.txt b/doc/rfc/rfc8933.txt
new file mode 100644
index 0000000..2a8ce3f
--- /dev/null
+++ b/doc/rfc/rfc8933.txt
@@ -0,0 +1,386 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        R. Housley
+Request for Comments: 8933                                Vigil Security
+Updates: 5652                                               October 2020
+Category: Standards Track                                               
+ISSN: 2070-1721
+
+
+     Update to the Cryptographic Message Syntax (CMS) for Algorithm
+                         Identifier Protection
+
+Abstract
+
+   This document updates the Cryptographic Message Syntax (CMS)
+   specified in RFC 5652 to ensure that algorithm identifiers in signed-
+   data and authenticated-data content types are adequately protected.
+
+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 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8933.
+
+Copyright Notice
+
+   Copyright (c) 2020 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
+   (https://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
+   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.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+   3.  Required Use of the Same Hash Algorithm
+     3.1.  RFC 5652, Section 5.3
+     3.2.  RFC 5652, Section 5.4
+     3.3.  RFC 5652, Section 5.6
+     3.4.  Backward Compatibility Considerations
+     3.5.  Timestamp Compatibility Considerations
+   4.  Recommended Inclusion of the CMSAlgorithmProtection Attribute
+     4.1.  RFC 5652, Section 14
+   5.  IANA Considerations
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Acknowledgements
+   Author's Address
+
+1.  Introduction
+
+   This document updates the Cryptographic Message Syntax (CMS)
+   [RFC5652] to ensure that algorithm identifiers in signed-data and
+   authenticated-data content types are adequately protected.
+
+   The CMS signed-data content type [RFC5652], unlike X.509 certificates
+   [RFC5280], can be vulnerable to algorithm substitution attacks.  In
+   an algorithm substitution attack, the attacker changes either the
+   algorithm identifier or the parameters associated with the algorithm
+   identifier to change the verification process used by the recipient.
+   The X.509 certificate structure protects the algorithm identifier and
+   the associated parameters by signing them.
+
+   In an algorithm substitution attack, the attacker looks for a
+   different algorithm that produces the same result as the algorithm
+   used by the originator.  As an example, if the signer of a message
+   used SHA-256 [SHS] as the digest algorithm to hash the message
+   content, then the attacker looks for a weaker hash algorithm that
+   produces a result that is of the same length.  The attacker's goal is
+   to find a different message that results in the same hash value,
+   which is called a cross-algorithm collision.  Today, there are many
+   hash functions that produce 256-bit results.  One of them may be
+   found to be weak in the future.
+
+   Further, when a digest algorithm produces a larger result than is
+   needed by a digital signature algorithm, the digest value is reduced
+   to the size needed by the signature algorithm.  This can be done both
+   by truncation and modulo operations, with the simplest being
+   straightforward truncation.  In this situation, the attacker needs to
+   find a collision with the reduced digest value.  As an example, if
+   the message signer uses SHA-512 [SHS] as the digest algorithm and the
+   Elliptic Curve Digital Signature Algorithm (ECDSA) with the P-256
+   curve [DSS] as the signature algorithm, then the attacker needs to
+   find a collision with the first half of the digest.
+
+   Similar attacks can be mounted against parameterized algorithm
+   identifiers.  When randomized hash functions are employed, such as
+   the example in [RFC6210], the algorithm identifier parameter includes
+   a random value that can be manipulated by an attacker looking for
+   collisions.  Some other algorithm identifiers include complex
+   parameter structures, and each value provides another opportunity for
+   manipulation by an attacker.
+
+   This document makes two updates to CMS to provide protection for the
+   algorithm identifier.  First, it mandates a convention followed by
+   many implementations by requiring the originator to use the same hash
+   algorithm to compute the digest of the message content and the digest
+   of signed attributes.  Second, it recommends that the originator
+   include the CMSAlgorithmProtection attribute [RFC6211].
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  Required Use of the Same Hash Algorithm
+
+   This section updates [RFC5652] to require the originator to use the
+   same hash algorithm to compute the digest of the message content and
+   the digest of signed attributes.
+
+3.1.  RFC 5652, Section 5.3
+
+   Change the paragraph describing the digestAlgorithm as follows:
+
+   OLD:
+
+   |  digestAlgorithm identifies the message digest algorithm, and any
+   |  associated parameters, used by the signer.  The message digest is
+   |  computed on either the content being signed or the content
+   |  together with the signed attributes using the process described in
+   |  Section 5.4.  The message digest algorithm SHOULD be among those
+   |  listed in the digestAlgorithms field of the associated SignerData.
+   |  Implementations MAY fail to validate signatures that use a digest
+   |  algorithm that is not included in the SignedData digestAlgorithms
+   |  set.
+
+   NEW:
+
+   |  digestAlgorithm identifies the message digest algorithm, and any
+   |  associated parameters, used by the signer.  The message digest is
+   |  computed on either the content being signed or the content
+   |  together with the signedAttrs using the process described in
+   |  Section 5.4.  The message digest algorithm SHOULD be among those
+   |  listed in the digestAlgorithms field of the associated SignerData.
+   |  If the signedAttrs field is present in the SignerInfo, then the
+   |  same digest algorithm MUST be used to compute both the digest of
+   |  the SignedData encapContentInfo eContent, which is carried in the
+   |  message-digest attribute, and the digest of the DER-encoded
+   |  signedAttrs, which is passed to the signature algorithm.
+   |  Implementations MAY fail to validate signatures that use a digest
+   |  algorithm that is not included in the SignedData digestAlgorithms
+   |  set.
+
+3.2.  RFC 5652, Section 5.4
+
+   Add the following paragraph as the second paragraph in Section 5.4.
+
+   ADD:
+
+   |  When the signedAttrs field is present, the same digest algorithm
+   |  MUST be used to compute the digest of the encapContentInfo
+   |  eContent OCTET STRING, which is carried in the message-digest
+   |  attribute and the digest of the collection of attributes that are
+   |  signed.
+
+3.3.  RFC 5652, Section 5.6
+
+   Change the paragraph discussing the signed attributes as follows:
+
+   OLD:
+
+   |  The recipient MUST NOT rely on any message digest values computed
+   |  by the originator.  If the SignedData signerInfo includes
+   |  signedAttributes, then the content message digest MUST be
+   |  calculated as described in Section 5.4.  For the signature to be
+   |  valid, the message digest value calculated by the recipient MUST
+   |  be the same as the value of the messageDigest attribute included
+   |  in the signedAttributes of the SignedData signerInfo.
+
+   NEW:
+
+   |  The recipient MUST NOT rely on any message digest values computed
+   |  by the originator.  If the SignedData signerInfo includes the
+   |  signedAttrs field, then the content message digest MUST be
+   |  calculated as described in Section 5.4 using the same digest
+   |  algorithm to compute the digest of the encapContentInfo eContent
+   |  OCTET STRING and the message-digest attribute.  For the signature
+   |  to be valid, the message digest value calculated by the recipient
+   |  MUST be the same as the value of the messageDigest attribute
+   |  included in the signedAttrs field of the SignedData signerInfo.
+
+3.4.  Backward Compatibility Considerations
+
+   The new requirement introduced above might lead to incompatibility
+   with an implementation that allowed different digest algorithms to be
+   used to compute the digest of the message content and the digest of
+   signed attributes.  The signatures produced by such an implementation
+   when two different digest algorithms are used will be considered
+   invalid by an implementation that follows this specification.
+   However, most, if not all, implementations already require the
+   originator to use the same digest algorithm for both operations.
+
+3.5.  Timestamp Compatibility Considerations
+
+   The new requirement introduced above might lead to compatibility
+   issues for timestamping systems when the originator does not wish to
+   share the message content with the Time Stamping Authority (TSA)
+   [RFC3161].  In this situation, the originator sends a TimeStampReq to
+   the TSA that includes a MessageImprint, which consists of a digest
+   algorithm identifier and a digest value.  The TSA then uses the
+   originator-provided digest in the MessageImprint.
+
+   When producing the TimeStampToken, the TSA MUST use the same digest
+   algorithm to compute the digest of the encapContentInfo eContent,
+   which is an OCTET STRING that contains the TSTInfo, and the message-
+   digest attribute within the SignerInfo.
+
+   To ensure that TimeStampToken values that were generated before this
+   update remain valid, no requirement is placed on a TSA to ensure that
+   the digest algorithm for the TimeStampToken matches the digest
+   algorithm for the MessageImprint embedded within the TSTInfo.
+
+4.  Recommended Inclusion of the CMSAlgorithmProtection Attribute
+
+   This section updates [RFC5652] to recommend that the originator
+   include the CMSAlgorithmProtection attribute [RFC6211] whenever
+   signed attributes or authenticated attributes are present.
+
+4.1.  RFC 5652, Section 14
+
+   Add the following paragraph as the eighth paragraph in Section 14:
+
+   ADD:
+
+   |  While there are no known algorithm substitution attacks today, the
+   |  inclusion of the algorithm identifiers used by the originator as a
+   |  signed attribute or an authenticated attribute makes such an
+   |  attack significantly more difficult.  Therefore, the originator of
+   |  a signed-data content type that includes signed attributes SHOULD
+   |  include the CMSAlgorithmProtection attribute [RFC6211] as one of
+   |  the signed attributes.  Likewise, the originator of an
+   |  authenticated-data content type that includes authenticated
+   |  attributes SHOULD include the CMSAlgorithmProtection attribute
+   |  [RFC6211] as one of the authenticated attributes.
+
+5.  IANA Considerations
+
+   This document has no IANA actions.
+
+6.  Security Considerations
+
+   The security properties of the CMS [RFC5652] signed-data and
+   authenticated-data content types are updated to offer protection for
+   algorithm identifiers, which makes algorithm substitution attacks
+   significantly more difficult.
+
+   For the signed-data content type, the improvements specified in this
+   document force an attacker to mount a hash algorithm substitution
+   attack on the overall signature, not just on the message digest of
+   the encapContentInfo eContent.
+
+   Some digital signature algorithms have prevented hash function
+   substitutions by including a digest algorithm identifier as an input
+   to the signature algorithm.  As discussed in [HASHID], such a
+   "firewall" may not be effective or even possible with newer signature
+   algorithms.  For example, RSASSA-PKCS1-v1_5 [RFC8017] protects the
+   digest algorithm identifier, but RSASSA-PSS [RFC8017] does not.
+   Therefore, it remains important that a signer have a way to signal to
+   a recipient which digest algorithms are allowed to be used in
+   conjunction with the verification of an overall signature.  This
+   signaling can be done as part of the specification of the signature
+   algorithm in an X.509v3 certificate extension [RFC5280] or some other
+   means.  The Digital Signature Standard (DSS) [DSS] takes the first
+   approach by requiring the use of an "approved" one-way hash
+   algorithm.
+
+   For the authenticated-data content type, the improvements specified
+   in this document force an attacker to mount a MAC algorithm
+   substitution attack, which is difficult because the attacker does not
+   know the authentication key.
+
+   The CMSAlgorithmProtection attribute [RFC6211] offers protection for
+   the algorithm identifiers used in the signed-data and authenticated-
+   data content types.  However, no protection is provided for the
+   algorithm identifiers in the enveloped-data, digested-data, or
+   encrypted-data content types.  Likewise, the CMSAlgorithmProtection
+   attribute provides no protection for the algorithm identifiers used
+   in the authenticated-enveloped-data content type defined in
+   [RFC5083].  A mechanism for algorithm identifier protection for these
+   content types is work for the future.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
+              "Internet X.509 Public Key Infrastructure Time-Stamp
+              Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
+              2001, <https://www.rfc-editor.org/info/rfc3161>.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, DOI 10.17487/RFC5652, September 2009,
+              <https://www.rfc-editor.org/info/rfc5652>.
+
+   [RFC6211]  Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm
+              Identifier Protection Attribute", RFC 6211,
+              DOI 10.17487/RFC6211, April 2011,
+              <https://www.rfc-editor.org/info/rfc6211>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+7.2.  Informative References
+
+   [DSS]      National Institute of Standards and Technology (NIST),
+              "Digital Signature Standard (DSS)", FIPS 186-4,
+              DOI 10.6028/NIST.FIPS.186-4, July 2013,
+              <https://doi.org/10.6028/NIST.FIPS.186-4>.
+
+   [HASHID]   Kaliski, B., "On Hash Function Firewalls in Signature
+              Schemes", DOI 10.1007/3-540-45760-7_1, Lecture Notes in
+              Computer Science, Volume 2271, February 2002,
+              <https://doi.org/10.1007/3-540-45760-7_1>.
+
+   [RFC5083]  Housley, R., "Cryptographic Message Syntax (CMS)
+              Authenticated-Enveloped-Data Content Type", RFC 5083,
+              DOI 10.17487/RFC5083, November 2007,
+              <https://www.rfc-editor.org/info/rfc5083>.
+
+   [RFC5280]  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, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC6210]  Schaad, J., "Experiment: Hash Functions with Parameters in
+              the Cryptographic Message Syntax (CMS) and S/MIME",
+              RFC 6210, DOI 10.17487/RFC6210, April 2011,
+              <https://www.rfc-editor.org/info/rfc6210>.
+
+   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
+              "PKCS #1: RSA Cryptography Specifications Version 2.2",
+              RFC 8017, DOI 10.17487/RFC8017, November 2016,
+              <https://www.rfc-editor.org/info/rfc8017>.
+
+   [SHS]      National Institute of Standards and Technology (NIST),
+              "Secure Hash Standard (SHS)", FIPS 180-4,
+              DOI 10.6028/NIST.FIPS.180-4, August 2015,
+              <https://doi.org/10.6028/NIST.FIPS.180-4>.
+
+Acknowledgements
+
+   Many thanks to Jim Schaad and Peter Gutmann; without knowing it, they
+   motivated me to write this document.  Thanks to Roman Danyliw, Ben
+   Kaduk, and Peter Yee for their careful review and editorial
+   suggestions.
+
+Author's Address
+
+   Russ Housley
+   Vigil Security, LLC
+   516 Dranesville Road
+   Herndon, VA 20170
+   United States of America
+
+   Email: housley@vigilsec.com