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]>]

> On Jan 2, 2019, at 1:26 PM, Paul Hoffman <[e-mail]> wrote:
> 
> On 27 Dec 2018, at 14:13, The IESG wrote:
> 
>> The IESG has received a request from the Limited Additional Mechanisms for
>> PKIX and SMIME WG (lamps) to consider the following document: - 'Hash Of Root
>> Key Certificate Extension'
>>  <draft-ietf-lamps-hash-of-root-key-cert-extn-02.txt> as Informational RFC
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits final
>> comments on this action. Please send substantive comments to the
>> [e-mail] mailing lists by 2019-01-10.
> 
> 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.

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.

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.


> 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.

> The first list in Section 2 would be clearer if the order was R1, R2, H2, C1; this would also then match the order in the second list.

Okay.  I changed that in my edit buffer.

> Later in Section 2, a sentence appears to be missing its subject. "That is, verify the signature on the self-signed certificate..." should probably be "That is, the recipient verifies the signature on the self-signed certificate...".

Okay.  I changed that in my edit buffer.

In addition, I added a bit more detail about the relationship to certification path validation, which I hope adds clarity around your first comment.  It now reads:

   The successor to the Root CA self-signed certificate can be
   delivered by any means.  Whenever a new Root CA certificate is
   received, the recipient is able to verify that the potential Root CA
   certificate links back to a previously authenticated Root CA
   certificate with the hashOfRootKey certificate extension.  That is,
   the recipient verifies the signature on the self-signed certificate
   and verifies that the hash of the DER-encoded SubjectPublicKeyInfo
   from the potential Root CA certificate matches the value from the
   HashOfRootKey certificate extension of the current Root CA
   certificate.  Checking the self-signed certificate signature ensures
   that the certificate contains the subject name, public key algorithm
   identifier, and public key algorithm parameters intended by the key
   owner intends; these are important inputs to certification path
   validation as defined in Section 6 of [RFC5280].  Checking the hash
   of the SubjectPublicKeyInfo ensures that the certificate contains the
   intended public key.  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.

Russ