[lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lamps-hash-of-root-key-cert-extn-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

After further reflection, I think we need to resurrect the discussion
sparked by DKG's last-call review.  Specifically, in Section 5 when we
consider the case that there is not a directory service/repository
available, we give guidance to "the recipient" and "recipients".  But in
at least some cases, there are two tiers of recipients/relying parties,
that have different properties, as in the web PKI situation.
Specifically, web server operators rely on root CAs to certify the
certificates that they present to TLS clients.  But we also consider the
TLS clients themselves, which may not have a direct path to receiving
the updated root CA self-signed certificate, and because of the
different ways these different types of recipient rely on root CA
information, the order in which they update can cause breakage.  We do
not necessarily need to present a clear solution that will always avoid
this breakage, but I do think we need to at least discuss the
possibility of such scenarios.

To consider a concrete case, consider a system with a TLS client ("A"),
a TLS server ("B"), and the root CA ("C").  C issues (potentially via
intermediates) an end-entity certificate for B, and we consider a case
where A initiates TLS connections to B.  Initially, C has the root
CA/key at C1, and is initiating a transition to C2; before the
transition both A and B have C1 in their trusted store.  When A receives
C2, it can perform the requisite validation and add C2 to its trust
store for use potentially validating incoming certificate chains.  When
B receives C2, it can similarly perform the requisite validation and add
C2 to its trust store, but B's trust store is used for validating
*outgoing* certificate chains, not (just) incoming ones.  If B were to
keep C2 in its trust store and construct an outgoing certificate chain
based on C2 (and omitting oldWithNew and newWithOld), before A has
received C2, then the TLS handshake fails!

If A had access to C2, or to oldWithnew/NewWithOld, then it would still
be able to validate B's certificate chain, but this document (and RFC
4210) do not give guidance that B should transmit newWithOld to A,
leaving open this scenario for breakage.

My current inclination is to add some text to this document acknowleding
the potential for a chain of relying parties, and recommending that the
"intermediate parties" in the scenario make newWithOld/oldWithNew available until
the notAfter time from oldWithNew, but I am of course open to further
discussion/suggestions.


Separately, I just want to quickly check that the id-ce-hashOfRootKey
OID has been properly allocated and recorded, as I couldn't find
evidence to indicate that in a quick search.  I assume this is the
origin of the CTIA acknowledgment that Alissa mentions, but there's not
quite enough there to connect the dots.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1.1

Please use the boilerplate from RFC 8174 (yes, I read the shepherd writeup).

Section 1.2

side note: this claim about "always encoded with DER" seems a bit
optimistic unless scoped down to a specific context.

Section 5

   After issuing the oldWithNew and newWithOld certificates, the Root CA
   MUST stop using the old private key to sign certificates.

Isn't this only relevant for newWithOld?  We don't need to use the old
private key to sign certificates to make a certification of the old key
signed by the new key.

   Changing names from one generation to another can lead to confusion
   when reviewing the history of a trust anchor store.  To assist with
   such review, a recipient MAY create an audit entry to capture the old
   and replacement self-signed certificates.

It seems like there may be non-name changes that might also cause
confusion (or worse); do we want to mention this possibility and/or the
recipient's duty to check for unexpected changes?

Section 6

I think some explicit guidance is needed about there being a critical
operational issue in the (unexpected) case of the cryptographic
breakdown of the hash function used to compute HashedRootKey.  The
current discussion of needing a hash function that is preimage-resistant
is good, of course, but some indication of the consequences if a has
function becomes bad during the course of use (or a bad hash function is
chosen initially) seems to be in order.

I also agree with the secdir reviewer that some guidance about how to
know that the first trasition is complete would be nice (in the absence
of the RFC 4210 transition process), but understand that such guidance
is hard to give.