On 2 Jan 2019, at 11:57, Russ Housley wrote:
On Jan 2, 2019, at 1:26 PM, Paul Hoffman <paul.hoffman@xxxxxxxx>
wrote:
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 seems like a
huge restriction that is only mentioned in the document in exactly one
sentence:
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.
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 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.
Yes, adding this clarifies how all the trust anchor information is
linked through the validation process. This is a good addition.
--Paul Hoffman
