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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 29 May 2019 15:44:06 -0700

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.

---

From: Russ Housley <[email-masked]>
Date: Fri, 31 May 2019 13:03:07 -0400

I think that the document is fairly clear that there can be some failure if there is not a repository or directory service.  However, while thinking about this over night, I realized that we could also point to the the Subject Information Access certificate extension in RFC 5280, Section 4.2.2.2.

   The id-ad-caRepository OID is used when the subject is a CA that
   publishes certificates it issues in a repository.  The accessLocation
   field is defined as a GeneralName, which can take several forms.

   ...

   Where the information is available via HTTP or FTP, accessLocation
   MUST be a uniformResourceIdentifier and the URI MUST point to either
   a single DER encoded certificate as specified in [RFC2585] or a
   collection of certificates in a BER or DER encoded "certs-only" CMS
   message as specified in [RFC2797].

I am willing to RECOMMEND the inclusion of this extension and posting the oldWithNew and newWithOld so that they can be fetched using the "certs-only" (simple PKI response).  This format would allow certificates to be added and removed from the bag of certificates over time.

> quite enough there to connect the dots.

CTIA allocated the OID for the ASN.1 module and the OID for the certificate extension from their arc.  In response to Alissa's comment, I suggested an additional sentence for the Acknowledgements to make this clear.

Already fixed in my edit buffer.

> optimistic unless scoped down to a specific context.

X.509 and RFC 5280 require the DER encoding for the signature computation and the signature validation.  If someone uses a different encoding somewhere along the way, it needs to be put back in DER form for the signature to validate.

How about:

   Certificates [RFC5280] use ASN.1 [X680]; Distinguished Encoding Rules
   (DER) [X690] are REQUIRED for certificate signing and validation.

> private key to sign certificates to make a certification of the old key

This is a statement about when to stop using the old private key.  But, indeed, you are correct:

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

> recipient's duty to check for unexpected changes?

This was a recommendation from DKC in the thread that you reference in your DISCUSS comments.  I do not know of any relying part software that keeps the audit log of changes to the trust store.  Many software update programs, for example, update the trust anchor store without creating such an audit.  I am not sure that building further on this concept is desirable.

> chosen initially) seems to be in order.

How about adding this sentence to the end of that paragraph:

   If the employed hash function is broken after the Root CA publishes
   the self-signed certificate with the HashOfRootKey certificate
   extension, an attacker would be able to trick the recipient into
   installing the incorrect next generation certificate in the trust
   anchor store.

> of the RFC 4210 transition process), but understand that such guidance

I do not have great advice, but there is a hint:

  Queries for the CRLs associated with certificates that are
   subordinate to the self-signed certificate can give some
   indication for the number of relying parties that are still
   actively using the self-signed certificates.

Russ