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

[Russ Housley <[e-mail]>]

Paul:

>>> This extension seems useful to CAs that understand the increased risks that using it incurs, but those risks are not mentioned in the document.
>>> 
>>> The document implicitly assumes that the CA will in fact use the key named in the extension next. Using this extension increases the risk of a bad trust anchor rollover at the same time that it makes good rollover more secure. If the key listed in this extension cannot be used when the CA eventually changes the trust anchor, relying parties will mistrust the new trust anchor. There are many reasons why a CA might think they know the next key but cannot use that key when they change trust anchors, such as if the HSM that holds the next key fails or is destroyed. Given the last sentence in Section 2, this could mean that a CA might never be able to issue a new trust anchor, even if the key for its current trust anchor is compromised.
>>> 
>>> Given the severity of the new risks of using this extension, they need to be introduced at the beginning of the document and then discussed in more detail in the Security Considerations. Note that this risk affects the last paragraph of the Security Considerations section as well.
>> 
>> The point is to facilitate the transition from one Root CA certificate to the next.
> 
> To be clear, the transition is from one public key to the next, not from one certificate to the next. But, more importantly, the point of this extension is to facilitate the transition from one Root CA certificate to what is supposed to be the next key. However, if that next key is not seen by every relying party during the transition, the extension prevents the CA from ever making the transition for the relying parties that do not see the new key in a revised trust anchor.

This is not correct.  The public key in the next self-signed certificate is identified by the hash of the public key that will appear in the subsequent certificate.  At the time of the actual transition, the recipient has the original self-signed certificate and the subsequent one.  Thus, the recipient has both in hand.

All replying parties will not see the subsequent self-signed certificate at the same time, but that is not a concern,  The old-in-new and new-in-old technique described in RFC 2510 (and referenced in Section 5) keeps all subordinate certificates valid until they expire.

> This seems like a huge restriction that is only mentioned in the document in exactly one sentence:

I think that the Abstract as reworded is pretty clear.

I will make a similar adjustment to the Introduction.

>> The last sentence in Section 2 says:
>> 
>>   If either check fails, then potential Root CA
>>   certificate is not a valid replacement, and the recipient continues
>>   to use the current Root CA certificate.
>> 
>> Indeed, these check are necessary to make sure that the relying party makes the transition to the proper replacement.  Any failure of the checks leave the trust anchor unchanged, which seems like the right result to me.
> 
> It seems right to me as well, but it still seems to be wholly insufficient to not talk about the risks of using the extension early in the document.
> 
>> Recall the definition of trust anchor from RFC 5280, Section 6.1.1:
>> 
>>      (d)  trust anchor information, describing a CA that serves as a
>>           trust anchor for the certification path.  The trust anchor
>>           information includes:
>> 
>>         (1)  the trusted issuer name,
>> 
>>         (2)  the trusted public key algorithm,
>> 
>>         (3)  the trusted public key, and
>> 
>>         (4)  optionally, the trusted public key parameters associated
>>              with the public key.
>> 
>> The checks make sure that the replacement self-signed certificate contains the intended information.
> 
> That is all fine, but it does not address the significant risk a CA is undertaking by promising what the next key will be.

That is not a significant risk. In fact, the LAMPS WG had a fairly lengthy discussion on that point at IETF 101.  The conclusion from that discussion is summarized in the Security Considerations.  That is, if the Root CA decides that the committed public key is no longer the desire destination, then two transition done fairly quickly can sort it out.

I observe that standing up a new Root CA from scratch would likely be harder than two quick transitions.


>>> Editorial:
>>> 
>>> The abstract says:
>>>  This document specifies the Hash Of Root Key certificate extension.
>>>  This certificate extension is carried in the self-signed certificate
>>>  for a trust anchor, which is often called a Root Certification
>>>  Authority (CA) certificate.  This certificate extension unambiguously
>>>  identifies the next public key that will be used by the trust anchor
>>>  at some point in the future.
>>> The term "trust anchor" is used as the concept, not the bits in the certificate. As such, the last sentence is confusing because the trust anchor will change when the key changes. A possible fix is to replace "will be used by the trust anchor at some point in the future" with "will be used in a trust anchor at some point in the future".
>> 
>> I think I understand your point.  Does this text resolve the concern?
>> 
>>   This document specifies the Hash Of Root Key certificate extension.
>>   This certificate extension is carried in the self-signed certificate
>>   for a trust anchor, which is often called a Root Certification
>>   Authority (CA) certificate.  This certificate extension unambiguously
>>   identifies the next public key that will be used at some point in the
>>   future as the next Root CA certificate, replacing the current one.
> 
> Not really. A key will not be used as a certificate: it is just a key. A key might be used as the signing key for a certificate, but not as the certificate itself. Maybe instead: "will be used to sign a trust anchor at some point in the future"?

The public key is identified by the hash value.  The public key that matches the hash value will appear in a self-signed certificate in the future.  All four of the components of the trust anchor (listed above) that are replaced, not just the public key.

Russ