--- 1/draft-ietf-lamps-hash-of-root-key-cert-extn-01.txt	2018-12-27 09:13:18.648913197 -0800
+++ 2/draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt	2018-12-27 09:13:18.668913677 -0800
@@ -1,18 +1,18 @@
 
 Network Working Group                                         R. Housley
 Internet-Draft                                            Vigil Security
-Intended status: Informational                         November 07, 2018
-Expires: May 11, 2019
+Intended status: Informational                         December 27, 2018
+Expires: June 30, 2019
 
                  Hash Of Root Key Certificate Extension
-             draft-ietf-lamps-hash-of-root-key-cert-extn-01
+             draft-ietf-lamps-hash-of-root-key-cert-extn-02
 
 Abstract
 
    This document specifies the Hash Of Root Key certificate extension.
    This certificate extension is carried in the self-signed certificate
    for a trust anchor, which is often called a Root Certification
    Authority (CA) certificate.  This certificate extension unambiguously
    identifies the next public key that will be used by the trust anchor
    at some point in the future.
 
@@ -24,21 +24,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 May 11, 2019.
+   This Internet-Draft will expire on June 30, 2019.
 
 Copyright Notice
 
    Copyright (c) 2018 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
@@ -120,25 +120,29 @@
       C2 = Self-signed certificate for R2, which contains H3
 
    This is an iterative process.  That is, R4 and H4 are generated when
    it is time for C3 to replace C2.  And so on.
 
    The successors to the Root CA self-signed certificate can be
    delivered by any means.  Whenever a new Root CA certificate is
    received, the recipient is able to verify that the potential Root CA
    certificate links back to a previously authenticated Root CA
    certificate with the hashOfRootKey certificate extension.  That is,
-   validate the self-signed signature and verify that the hash of the
-   DER-encoded SubjectPublicKeyInfo from the potential Root CA
-   certificate matches the value from the HashOfRootKey certificate
-   extension of the current Root CA certificate.  If the signature does
-   not validate or the hash values do not match, then potential Root CA
+   verify the signature on the self-signed certificate and verify that
+   the hash of the DER-encoded SubjectPublicKeyInfo from the potential
+   Root CA certificate matches the value from the HashOfRootKey
+   certificate extension of the current Root CA certificate.  Checking
+   the self-signed certificate signature ensures that the certificate
+   contains the subject name that the key owner intends, which is
+   important for path validation.  Checking the hash of the
+   SubjectPublicKeyInfo ensures that the certificate contains the
+   intended public key.  If either check fails, then potential Root CA
    certificate is not a valid replacement, and the recipient continues
    to use the current Root CA certificate.
 
 3.  Hash Of Root Key Certificate Extension
 
    The HashOfRootKey certificate extension MUST NOT be critical.
 
    The following ASN.1 [X680][X690] syntax defines the HashOfRootKey
    certificate extension:
 
@@ -168,21 +172,21 @@
 
    This document makes no requests of the IANA.
 
 5.  Operational Considerations
 
    Guidance on the transition from one trust anchor to another is
    available in [RFC2510].  In particular, the oldWithNew and newWithOld
    advice ensures that relying parties are able to validate certificates
    issued under the current Root CA certificate and the next generation
    Root CA certificate throughout the transition.  Further, this
-   technique ovoids the need for all relying parties to make the
+   technique avoids the need for all relying parties to make the
    transition at the same time.
 
 6.  Security Considerations
 
    The security considerations from [RFC5280] apply, especially the
    discussion of self-issued certificates.
 
    The Hash Of Root Key certificate extension facilitates the orderly
    transition from one Root CA public key to the next by publishing the
    hash value of the next generation public key in the current