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

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

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.

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

--Paul Hoffman