--- 1/draft-ietf-lamps-rfc7030est-clarify-07.txt	2020-07-06 12:13:09.817120537 -0700
+++ 2/draft-ietf-lamps-rfc7030est-clarify-08.txt	2020-07-06 12:13:09.845121248 -0700
@@ -1,49 +1,49 @@
 
 LAMPS Working Group                                        M. Richardson
 Internet-Draft                                  Sandelman Software Works
 Updates: 7030 (if approved)                                    T. Werner
 Intended status: Standards Track                                 Siemens
-Expires: December 18, 2020                                        W. Pan
+Expires: January 7, 2021                                          W. Pan
                                                      Huawei Technologies
-                                                           June 16, 2020
+                                                           July 06, 2020
 
    Clarification of Enrollment over Secure Transport (EST): transfer
                           encodings and ASN.1
-                 draft-ietf-lamps-rfc7030est-clarify-07
+                 draft-ietf-lamps-rfc7030est-clarify-08
 
 Abstract
 
    This document updates RFC7030: Enrollment over Secure Transport (EST)
-   to resolve some errata that was reported, and which has proven to
+   to resolve some errata that were reported, and which has proven to
    cause interoperability issues when RFC7030 was extended.
 
    This document deprecates the specification of "Content-Transfer-
    Encoding" headers for EST endpoints.  This document fixes some
-   syntactical errors in ASN.1 that was presented.
+   syntactical errors in ASN.1 that were presented.
 
 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 December 18, 2020.
+   This Internet-Draft will expire on January 7, 2021.
 
 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
@@ -149,57 +149,54 @@
    CRLF, while the "base64" used in MIME [RFC2045] does.  This
    specification clarifies that despite [RFC2616], that white space
    including CR, LF, spaces (ASCII 32) and, tabs (ASCII 9) SHOULD be
    tolerated by receivers.  Senders are not required to insert any kind
    of white space.
 
 3.2.  Changes sections 4 of RFC7030
 
 3.2.1.  Section 4.1.3
 
-   In the paragraph reading:
+   Replace:
 
    A successful response MUST be a certs-only CMC Simple PKI Response,
    as defined in [RFC5272], containing the certificates described in the
    following paragraph.  The HTTP content-type of
    "application/pkcs7-mime" is used.  The Simple PKI Response is sent
    with a Content-Transfer-Encoding of "base64" [RFC2045].
 
-   Replace:
-
-      The Simple PKI Response is sent
-      with a Content-Transfer-Encoding of "base64" [RFC2045].
-
    with:
 
-      The CMC Simple PKI Response is encoded in base64 [RFC4648].
+   A successful response MUST be a certs-only CMC Simple PKI Response,
+   as defined in [RFC5272], containing the certificates described in the
+   following paragraph.  The HTTP content-type of
+   "application/pkcs7-mime" is used.  The CMC Simple PKI Response is
+   encoded in base64 [RFC4648].
 
 3.2.2.  Section 4.3.1
 
-   In the paragraph reading:
+   Replace:
 
     If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
     server MUST reject the message.  The HTTP content-type used is
     "application/pkcs7-mime" with an smime-type parameter "CMC-request",
     as specified in [RFC5273].  The body of the message is the binary
     value of the encoding of the PKI Request with a
     Content-Transfer-Encoding of "base64" [RFC2045].
 
-   Replace:
-
-      The body of the message is the binary
-      value of the encoding of the PKI Request with a
-      Content-Transfer-Encoding of "base64" [RFC2045].
-
    with:
 
-      The body of the message is encoded in base64 [RFC4648].
+    If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
+    server MUST reject the message.  The HTTP content-type used is
+    "application/pkcs7-mime" with an smime-type parameter "CMC-request",
+    as specified in [RFC5273].  The body of the message is encoded
+    in base64 [RFC4648].
 
 3.2.3.  Section 4.3.2
 
    Replace:
 
     The body of the message is the binary value of the encoding of the
     PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045].
 
    with:
 
@@ -365,21 +362,21 @@
 
    with:
 
        If the content-type is not set, the response data must be a
        plaintext human-readable error message.
        Servers MAY use the "text/plain" content-type [RFC2046]
        for human-readable errors.
 
 6.  Privacy Considerations
 
-   This document does not disclose any additional identifies to either
+   This document does not disclose any additional identities to either
    active or passive observer would see with [RFC7030].
 
 7.  Security Considerations
 
    This document clarifies an existing security mechanism.  It does not
    create any new protocol mechanism.
 
 8.  IANA Considerations
 
    The ASN.1 module in Appendix A of this document makes use of object