Re: Last Call: <draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt> (Hash Of Root Key Certificate Extension) to Informational RFC

["Paul Hoffman" <[e-mail]>]

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