--- 1/draft-ietf-lamps-cms-update-alg-id-protect-00.txt	2020-03-09 10:18:25.192080003 -0700
+++ 2/draft-ietf-lamps-cms-update-alg-id-protect-01.txt	2020-03-09 10:18:25.632091174 -0700
@@ -1,20 +1,20 @@
 
 Network Working Group                                         R. Housley
 Internet-Draft                                            Vigil Security
-Updates: 5652 (if approved)                             January 21, 2020
+Updates: 5652 (if approved)                               March 09, 2020
 Intended status: Standards Track
-Expires: July 24, 2020
+Expires: September 10, 2020
 
      Update to the Cryptographic Message Syntax (CMS) for Algorithm
                          Identifier Protection
-             draft-ietf-lamps-cms-update-alg-id-protect-00
+             draft-ietf-lamps-cms-update-alg-id-protect-01
 
 Abstract
 
    This document updates the Cryptographic Message Syntax (CMS)
    specified in RFC 5652 to ensure that algorithm identifiers are
    adequately protected.
 
 Status of This Memo
 
    This Internet-Draft is submitted in full conformance with the
@@ -23,21 +23,21 @@
    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 July 24, 2020.
+   This Internet-Draft will expire on September 10, 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,27 +50,27 @@
 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 .   5
+   4.  Recommend inclusion of the CMSAlgorithmProtection attribute .   6
      4.1.  RFC 5652, Section 14  . . . . . . . . . . . . . . . . . .   6
    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
    6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
      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.
 
    The CMS Signed-data Content Type [RFC5652], unlike X.509 certificates
@@ -221,24 +221,32 @@
       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 digest
-   in the MessageImprint.  As a result, the signature algorithm used by
-   the TSA needs to be compatible with the digest algorithm selected by
-   the originator for the MessageImprint.
+   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.
 
 4.1.  RFC 5652, Section 14
 
    Add the following paragraph as the eighth paragraph in Section 14: