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

[Benjamin Kaduk <[e-mail]>]

Hi Russ,

On Tue, Jun 11, 2019 at 12:34:35PM -0400, Russ Housley wrote:
> Ben:
> 
> I have not heard back from you.  Please let me know if the proposed way forward would resolve your DISCUSS position.

Sorry; it was a busy couple weeks for my personal life.

> Russ
> 
> 
> > On May 31, 2019, at 1:03 PM, Russ Housley <[e-mail]> wrote:
> > 
> > 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.

I don't really feel like that clear picture is getting conveyed, though.
(Which is not to say that adding text about this extension is a bad idea,
of course!)

Focusing on the Operational Considerations, and taking an example:

   Guidance on the transition from one trust anchor to another is
   available in Section 4.4 of [RFC4210].  In particular, the oldWithNew
   and newWithOld advice ensures that relying parties are able to
   validate certificates issued under the current Root CA certificate
   and the next generation Root CA certificate throughout the
   transition.  [...]

To me, this comes across as saying that the existence of oldWithNew and
newWithOld takes care of everything and "ensures that relying parties are
able to validate certificates".  Perhaps the subtlety lies in the
definition of "relying party" -- RFC 4210 is of course pretty well steeped
in the repository/directory service setup.  It's also interesting to me to
note, though, that RFC 4120 talks about the entities that need to worry
about getting the CA public keys as being the entities that themselves have
certificates (e.g., "typically be easily achieved when these end entities'
certificates expire").  While that's a valid use case, it does seem a bit
divorced from the (e.g., Web) case where the entity that needs the CA
public key does not have a certificate, such as when it's a browser.

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

That does seem worth doing.

I think what would best help move the document forward right now would be
for you to point me at the existing text that is "fairly clear that there
can be some failure if there is not a repository or directory service.",
since I seem to have missed it.  Text that matches that description should
be enough to resolve the Discuss point -- we don't need to bend over
backwards to satisfy the Web PKI case when the mechanism works fine as-is
in other use cases.

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

I did see that after I balloted; it looks great.

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

That avoids the issue I was worried about, though at the risk of using
normative language to restate a normative requirement from a different
document.

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

I'm happy to leave this alone.

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

Wonderful; thanks!

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

Ah, that is fairly clever.

Thanks,

Ben