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
ietf@xxxxxxxx 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
