If the new self-signed cert uses a new key, wouldn't that be rejected as violating the promise in the current cert? I am missing something.
Thanks,
Joel
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: Russ Housley <housley@xxxxxxxxxxxx>
Date: 1/4/19 17:57 (GMT-05:00)
To: Joel Halpern <jmh@xxxxxxxxxxxxxxx>
Cc: IETF Gen-ART <gen-art@xxxxxxxx>, spasm@xxxxxxxx, draft-ietf-lamps-hash-of-root-key-cert-extn.all@xxxxxxxx, IETF <ietf@xxxxxxxx>
Subject: Re: Genart last call review of
draft-ietf-lamps-hash-of-root-key-cert-extn-03
Thanks for the review.
> 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.
Joel, the Root CA want to start using a different key par, but they have lost access to the one that was previously generated for that purpose. So, the remedy is to create a new self-signed certificate with a newly generated key.
Does that help? If so, what would make the paragraph more clear?
Russ
