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

[Russ Housley <[e-mail]>]

Ben:

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

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.

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

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.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 1.1
> 
> Please use the boilerplate from RFC 8174 (yes, I read the shepherd writeup).

Already fixed in my edit buffer.

> Section 1.2
> 
> side note: this claim about "always encoded with DER" seems a bit
> 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.

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

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.

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

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.

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

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.

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

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