draft-ietf-lamps-cms-update-alg-id-protect-01.txt   draft-ietf-lamps-cms-update-alg-id-protect-02.txt 
Network Working Group R. Housley Network Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Updates: 5652 (if approved) March 09, 2020 Updates: 5652 (if approved) May 28, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: September 10, 2020 Expires: November 29, 2020
Update to the Cryptographic Message Syntax (CMS) for Algorithm Update to the Cryptographic Message Syntax (CMS) for Algorithm
Identifier Protection Identifier Protection
draft-ietf-lamps-cms-update-alg-id-protect-01 draft-ietf-lamps-cms-update-alg-id-protect-02
Abstract Abstract
This document updates the Cryptographic Message Syntax (CMS) This document updates the Cryptographic Message Syntax (CMS)
specified in RFC 5652 to ensure that algorithm identifiers are specified in RFC 5652 to ensure that algorithm identifiers in signed-
adequately protected. data and authenticated-data content types are adequately protected.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Require use the same hash algorithm . . . . . . . . . . . . . 3 3. Require use the same hash algorithm . . . . . . . . . . . . . 3
3.1. RFC 5652, Section 5.3 . . . . . . . . . . . . . . . . . . 3 3.1. RFC 5652, Section 5.3 . . . . . . . . . . . . . . . . . . 3
3.2. RFC 5652, Section 5.4 . . . . . . . . . . . . . . . . . . 4 3.2. RFC 5652, Section 5.4 . . . . . . . . . . . . . . . . . . 4
3.3. RFC 5652, Section 5.6 . . . . . . . . . . . . . . . . . . 4 3.3. RFC 5652, Section 5.6 . . . . . . . . . . . . . . . . . . 4
3.4. Backward Compatibility Considerations . . . . . . . . . . 5 3.4. Backward Compatibility Considerations . . . . . . . . . . 5
3.5. Timestamp 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 4.1. RFC 5652, Section 14 . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
This document updates the Cryptographic Message Syntax (CMS) This document updates the Cryptographic Message Syntax (CMS)
[RFC5652] to ensure that algorithm identifiers are adequately [RFC5652] to ensure that algorithm identifiers in signed-data and
protected. 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 [RFC5280], can be vulnerable to algorithm substitution attacks. In
an algorithm substitution attack, the attacker changes either the an algorithm substitution attack, the attacker changes either the
algorithm identifier or the parameters associated with the algorithm algorithm identifier or the parameters associated with the algorithm
identifier to change the verification process used by the recipient. identifier to change the verification process used by the recipient.
The X.509 certificate structure protects the algorithm identifier and The X.509 certificate structure protects the algorithm identifier and
the associate parameters by signing them. the associate parameters by signing them.
In an algorithm substitution attack, the attacker looks for a In an algorithm substitution attack, the attacker looks for a
different algorithm that produces the same result as the algorithm different algorithm that produces the same result as the algorithm
used by the originator. As an example, if the signer of a message used by the originator. As an example, if the signer of a message
skipping to change at page 5, line 27 skipping to change at page 5, line 27
The new requirement introduced above might lead to compatibility with The new requirement introduced above might lead to compatibility with
an implementation that allowed different digest algorithms to be used an implementation that allowed different digest algorithms to be used
to compute the digest of the message content and the digest of signed to compute the digest of the message content and the digest of signed
attributes. The signatures produced by such an implementation when attributes. The signatures produced by such an implementation when
two different digest algorithms are used will be considered invalid two different digest algorithms are used will be considered invalid
by an implementation that follows this specification. However, most, by an implementation that follows this specification. However, most,
if not all, implementations already require the originator to use the if not all, implementations already require the originator to use the
same digest algorithm for both operations. 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 3.5. Timestamp Compatibility Considerations
The new requirement introduced above might lead to compatibility The new requirement introduced above might lead to compatibility
issues for timestamping systems when the originator does not wish to issues for timestamping systems when the originator does not wish to
share the message content with the Time Stamp Authority (TSA) share the message content with the Time Stamp Authority (TSA)
[RFC3161]. In this situation, the originator sends a TimeStampReq to [RFC3161]. In this situation, the originator sends a TimeStampReq to
the TSA that includes a MessageImprint, which consists of a digest the TSA that includes a MessageImprint, which consists of a digest
algorithm identifier and a digest value, then the TSA uses the algorithm identifier and a digest value, then the TSA uses the
originator-provided digest in the MessageImprint. originator-provided digest in the MessageImprint.
skipping to change at page 6, line 21 skipping to change at page 6, line 15
4.1. RFC 5652, Section 14 4.1. RFC 5652, Section 14
Add the following paragraph as the eighth paragraph in Section 14: Add the following paragraph as the eighth paragraph in Section 14:
ADD: ADD:
While no known algorithm substitution attacks are known at this While no known algorithm substitution attacks are known at this
time, the inclusion of the algorithm identifiers used by the time, the inclusion of the algorithm identifiers used by the
originator as a signed attribute or an authenticated attribute originator as a signed attribute or an authenticated attribute
makes such an attack significantly more difficult. Therefore, the 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 attributes SHOULD include the CMSAlgorithmProtection attribute
[RFC6211] as one of the signed attributes. Likewise, the [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 authenticated attributes SHOULD include the CMSAlgorithmProtection
attribute [RFC6211] as one of the authenticated attributes. attribute [RFC6211] as one of the authenticated attributes.
5. IANA Considerations 5. IANA Considerations
This document makes no requests of the IANA. This document makes no requests of the IANA.
6. Security Considerations 6. Security Considerations
The security considerations of [RFC5652] are updated ensure that The security considerations of [RFC5652] are updated ensure that
algorithm identifiers are adequately protected, which makes algorithm algorithm identifiers are adequately protected, which makes algorithm
substitution attacks significantly more difficult. substitution attacks significantly more difficult.
The CMSAlgorithmProtection attribute [RFC6211] offers protection the The CMSAlgorithmProtection attribute [RFC6211] offers protection for
algorithm identifiers used in the signed-data and authenticated-data the algorithm identifiers used in the signed-data and authenticated-
content types. There is not currently protection mechanism for the data content types. There is not currently protection mechanism for
algorithm identifiers used in the enveloped-data, digested-data, or the algorithm identifiers used in the enveloped-data, digested-data,
encrypted-data content types. Likewise there us not currently or encrypted-data content types. Likewise there is not currently a
protection mechanism for the algorithm identifiers used in the protection mechanism for the algorithm identifiers used in the
authenticated-enveloped-data content type defined in [RFC5083]. authenticated-enveloped-data content type defined in [RFC5083].
7. Acknowledgements 7. Acknowledgements
Many thanks to Jim Schaad and Peter Gutmann; without knowing it, they Many thanks to Jim Schaad and Peter Gutmann; without knowing it, they
motivated me to write this document. motivated me to write this document.
8. References 8. References
skipping to change at page 8, line 12 skipping to change at page 8, line 8
RFC 6210, DOI 10.17487/RFC6210, April 2011, RFC 6210, DOI 10.17487/RFC6210, April 2011,
<https://www.rfc-editor.org/info/rfc6210>. <https://www.rfc-editor.org/info/rfc6210>.
[SHS] National Institute of Standards and Technology (NIST), [SHS] National Institute of Standards and Technology (NIST),
"Secure Hash Standard", FIPS Publication 180-3, October "Secure Hash Standard", FIPS Publication 180-3, October
2008. 2008.
Author's Address Author's Address
Russ Housley Russ Housley
Vigil Security Vigil Security, LLC
516 Dranesville Road 516 Dranesville Road
Herndon, VA 20170 Herndon, VA 20170
US US
Email: housley@vigilsec.com Email: housley@vigilsec.com
 End of changes. 14 change blocks. 
27 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/