Re: Genart last call review of draft-ietf-lamps-hash-of-root-key-cert-extn-03

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Joel:

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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux