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 . 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