On 3 Jan 2019, at 7:28, Russ Housley wrote:
I had a voice conversation with Paul Hoffman, and I think that I now
understand the things that he would like to see added to the document.
Essentially, the Hash Of Root Key certificate extension is a
commitment to the next generation public key and algorithm. Recall
that the hash covers the SubjectPublicKeyInfo, which is:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
So, a few things can go wrong after making this commitment. (Stephen
called it pinning.) The Root CA needs to choose a next generation
public key and algorithm that will be secure for the full lifetime.
Of course, a cryptoanalytic break through is very difficult to
predict, and if one happens before the new key is used, the Root CA
remains committed to the now broken key. The remedy is to deploy a
new public key and algorithm in the same manner as the initial Root CA
self-signed certificate. The benefits of automatic detection of the
new public key are lost, but that is a minor concern is the scope of a
cryptoanalytic break through.
In addition, from an operational perspective, the Root CA must
securely back up the yet-to-be-deployed key pair. If the Root CA
stores it in a hardware security module, and that module fails, the
Root CA remains committed to the now unavailable key. The remedy is
the same as above: deploy a new public key in the same manner as the
initial Root CA self-signed certificate.
Russ has issued an -03 that adds text about the commitment that comes
with using this extension. That alleviates my concern about a CA not
realizing that there is a risk in adding the extension to trust anchor
certificates.
--Paul Hoffman
