Last Call Review of draft-ietf-lamps-hash-of-root-key-cert-extn-03

Request Review of draft-ietf-lamps-hash-of-root-key-cert-extn
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-01-10
Requested 2018-12-27
Authors Russ Housley
Draft last updated 2019-01-04
Completed reviews Secdir Last Call review of -03 by Adam Montville (diff)
Genart Last Call review of -03 by Joel Halpern (diff)
Genart Telechat review of -05 by Joel Halpern (diff)
Secdir Telechat review of -05 by Adam Montville (diff)
Assignment Reviewer Joel Halpern
State Completed
Review review-ietf-lamps-hash-of-root-key-cert-extn-03-genart-lc-halpern-2019-01-04
Reviewed rev. 03 (document currently at 07)
Review result Almost Ready
Review completed: 2019-01-04


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