--- 1/draft-ietf-lamps-cms-aes-gmac-alg-04.txt	2021-04-02 07:13:27.228336186 -0700
+++ 2/draft-ietf-lamps-cms-aes-gmac-alg-05.txt	2021-04-02 07:13:27.248336683 -0700
@@ -1,18 +1,18 @@
 
 Network Working Group                                         R. Housley
 Internet-Draft                                            Vigil Security
-Intended status: Standards Track                            8 March 2021
-Expires: 9 September 2021
+Intended status: Standards Track                            2 April 2021
+Expires: 4 October 2021
 
 Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS)
-                  draft-ietf-lamps-cms-aes-gmac-alg-04
+                  draft-ietf-lamps-cms-aes-gmac-alg-05
 
 Abstract
 
    This document specifies the conventions for using the AES-GMAC
    Message Authentication Code algorithms with the Cryptographic Message
    Syntax (CMS) as specified in RFC 5652.
 
 Status of This Memo
 
    This Internet-Draft is submitted in full conformance with the
@@ -21,21 +21,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 9 September 2021.
+   This Internet-Draft will expire on 4 October 2021.
 
 Copyright Notice
 
    Copyright (c) 2021 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
@@ -51,21 +51,21 @@
    3.  Message Authentication Code Algorithms  . . . . . . . . . . .   2
      3.1.  AES-GMAC  . . . . . . . . . . . . . . . . . . . . . . . .   2
    4.  Implementation Considerations . . . . . . . . . . . . . . . .   3
    5.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . . . .   4
    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
    7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
    8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
    9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
      9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
      9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8
 
 1.  Introduction
 
    This document specifies the conventions for using the AES-GMAC
    [AES][GCM] Message Authentication Code (MAC) algorithm with the
    Cryptographic Message Syntax (CMS) [RFC5652].
 
 2.  Terminology
 
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@@ -224,20 +224,25 @@
 
    Within the scope of any content-authentication key, the AES-GMAC
    nonce value MUST be unique.  Use of a nonce value more than once
    allows an attacker to generate valid AES-GMAC authentication codes
    for arbitrary messages, resulting in the loss of authentication as
    described in Appendix A of [GCM].
 
    Within the scope of any content-authentication key, the
    authentication tag length (MACLength) MUST be fixed.
 
+   If AES-GMAC is used as a building block in another algorithm (e.g.,
+   as a pseudo-random function), AES-GMAC MUST be used only one time by
+   that algorithm.  For instance, AES-GMAC MUST NOT be used as the
+   pseudo-random function for PBKDF2.
+
    When IV lengths other than 96 bits are used, the GHASH function is
    used to process the provided IV, which introduces a potential of IV
    collisions.  However, IV collisions are not a concern with CMS
    AuthenticatedData because a fresh content-authentication key is
    usually generated for each message.
 
    The probability of a successful forgery is close to 2^(-t), where t
    is the number of bits in the authentication tag length (MACLength*8).
    This nearly ideal authentication protection is achieved for CMS
    AuthenticatedData when a fresh content-authentication key is
@@ -259,23 +264,23 @@
    weaker with time.  As new cryptanalysis techniques are developed and
    computing performance improves, the work factor to break a particular
    cryptographic algorithm will reduce.  Therefore, cryptographic
    algorithm implementations should be modular allowing new algorithms
    to be readily inserted.  That is, implementers should be prepared to
    regularly update the set of algorithms in their implementations.
    More information is available in BCP 201 [RFC7696].
 
 8.  Acknowledgements
 
-   Many thanks to Quynh Dang, Roman Danyliw, Tim Hollebeek, Ben Kaduk,
-   Mike Ounsworth, and Magnus Westerlund for their careful review and
-   thoughtful improvements.
+   Many thanks to Hans Aschauer, Hendrik Brockhaus, Quynh Dang, Roman
+   Danyliw, Tim Hollebeek, Ben Kaduk, Mike Ounsworth, and Magnus
+   Westerlund for their careful review and thoughtful improvements.
 
 9.  References
 
 9.1.  Normative References
 
    [AES]      National Institute of Standards and Technology (NIST),
               "Advanced Encryption Standard (AES)", FIPS
               Publication 197, November 2001.
 
    [GCM]      Dworkin, M., "Recommendation for Block Cipher Modes of