Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection
draft-ietf-lamps-cms-update-alg-id-protect-02

Housley                 Expires November 29, 2020               [Page 4]
Internet-Draft     CMS Algorithm Identifier Protection          May 2020

      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, using the same digest
      algorithm to compute the digest of the 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 signedAttributes of the SignedData
      signerInfo.

3.4.  Backward Compatibility Considerations

   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.

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.

   When producing the TimeStampToken, the TSA MUST use 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 TSTTokenInfo.

4.  Recommend 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.

Housley                 Expires November 29, 2020               [Page 5]
Internet-Draft     CMS Algorithm Identifier Protection          May 2020

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
      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 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 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

8.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>.

Housley                 Expires November 29, 2020               [Page 6]
Internet-Draft     CMS Algorithm Identifier Protection          May 2020

   [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>.

8.2.  Informative References

   [DSS]      National Institute of Standards and Technology (NIST),
              "Digital Signature Standard (DSS)", FIPS
              Publication 186-3, June 2009.

   [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>.

   [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>.

   [SHS]      National Institute of Standards and Technology (NIST),
              "Secure Hash Standard", FIPS Publication 180-3, October
              2008.

Housley                 Expires November 29, 2020               [Page 7]
Internet-Draft     CMS Algorithm Identifier Protection          May 2020

Author's Address

   Russ Housley
   Vigil Security, LLC
   516 Dranesville Road
   Herndon, VA  20170
   US

   Email: housley@vigilsec.com

Housley                 Expires November 29, 2020               [Page 8]