Last Call Review of draft-ietf-lamps-hash-of-root-key-cert-extn-03
review-ietf-lamps-hash-of-root-key-cert-extn-03-genart-lc-halpern-2019-01-04-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lamps-hash-of-root-key-cert-extn-03
Reviewer: Joel Halpern
Review Date: 2019-01-04
IETF LC End Date: 2019-01-10
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is nearly ready for publication as an Informational RFC.

Major issues: N/A

Minor issues:
    The explanation at the end of section 5 about the remedy for losing access
    to the new root key left me confused.
It looks like the situation is that there is a certificate out there, with the
hash of root key extensions. The certificate owner loses access to the new key
pair underlying the hash. The certificate owner clearly has to issue a new key
pair.  So far, so good.

What the text seems to say is to simply issue a new self-signed certificate. 
There are two possibilities for what is intended. I think the idea is that the
new certificate will use the existing key pair (not the promised one, nor
another new one) for its own signature, and include a new hash of root key for
the newly generated pair.  If the certificate owner can do that (I have not
dived into the rest of the certificate operations to figure out if that is
legal) then it works.  Please add some words explaining that better. If the
certificate owner can not simply issue a new self-signed certificate with the
existing key pair, then I am lost.  It appears that the text says that the
certificate owner issues a new self-signed certificate using a new key pair. 
But that will fail the check against the previous certificate hash of root key.
I am hoping that it is the first of these alternatives, and all that is needed
is clearer explanatory text stating that the new cert uses the existing key
pair, and includes a new hash of root key promise.

Nits/editorial comments:  N/A