--- 1/draft-ietf-lamps-cms-update-alg-id-protect-01.txt 2020-05-28 12:13:03.409088046 -0700 +++ 2/draft-ietf-lamps-cms-update-alg-id-protect-02.txt 2020-05-28 12:13:03.429088562 -0700 @@ -1,43 +1,43 @@ Network Working Group R. Housley Internet-Draft Vigil Security -Updates: 5652 (if approved) March 09, 2020 +Updates: 5652 (if approved) May 28, 2020 Intended status: Standards Track -Expires: September 10, 2020 +Expires: November 29, 2020 Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection - draft-ietf-lamps-cms-update-alg-id-protect-01 + draft-ietf-lamps-cms-update-alg-id-protect-02 Abstract This document updates the Cryptographic Message Syntax (CMS) - specified in RFC 5652 to ensure that algorithm identifiers are - adequately protected. + 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 10, 2020. + This Internet-Draft will expire on November 29, 2020. 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 @@ -50,37 +50,37 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Require use the same hash algorithm . . . . . . . . . . . . . 3 3.1. RFC 5652, Section 5.3 . . . . . . . . . . . . . . . . . . 3 3.2. RFC 5652, Section 5.4 . . . . . . . . . . . . . . . . . . 4 3.3. RFC 5652, Section 5.6 . . . . . . . . . . . . . . . . . . 4 3.4. Backward Compatibility Considerations . . . . . . . . . . 5 3.5. Timestamp Compatibility Considerations . . . . . . . . . 5 - 4. Recommend inclusion of the CMSAlgorithmProtection attribute . 6 + 4. Recommend inclusion of the CMSAlgorithmProtection attribute . 5 4.1. RFC 5652, Section 14 . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction This document updates the Cryptographic Message Syntax (CMS) - [RFC5652] to ensure that algorithm identifiers are adequately - protected. + [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 + 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 associate 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 @@ -207,27 +207,20 @@ The new requirement introduced above might lead to compatibility 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. - READER: - - If you have an implementation that allows different digest - algorithms to be used to compute the digest of the message content - and the digest of signed attributes, please tell us on the - spasm@ietf.org mail list. - 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 Stamp 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, then the TSA uses the originator-provided digest in the MessageImprint. @@ -250,42 +243,42 @@ 4.1. RFC 5652, Section 14 Add the following paragraph as the eighth paragraph in Section 14: ADD: While no known algorithm substitution attacks are known at this time, 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 + 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 + 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 makes no requests of the IANA. 6. Security Considerations The security considerations of [RFC5652] are updated ensure that algorithm identifiers are adequately protected, which makes algorithm substitution attacks significantly more difficult. - The CMSAlgorithmProtection attribute [RFC6211] offers protection the - algorithm identifiers used in the signed-data and authenticated-data - content types. There is not currently protection mechanism for the - algorithm identifiers used in the enveloped-data, digested-data, or - encrypted-data content types. Likewise there us not currently + The CMSAlgorithmProtection attribute [RFC6211] offers protection for + the algorithm identifiers used in the signed-data and authenticated- + data content types. There is not currently protection mechanism for + the algorithm identifiers used in the enveloped-data, digested-data, + or encrypted-data content types. Likewise there is not currently a protection mechanism for the algorithm identifiers used in the authenticated-enveloped-data content type defined in [RFC5083]. 7. Acknowledgements Many thanks to Jim Schaad and Peter Gutmann; without knowing it, they motivated me to write this document. 8. References @@ -336,16 +329,16 @@ RFC 6210, DOI 10.17487/RFC6210, April 2011, . [SHS] National Institute of Standards and Technology (NIST), "Secure Hash Standard", FIPS Publication 180-3, October 2008. Author's Address Russ Housley - Vigil Security + Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 US Email: housley@vigilsec.com