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

From: Russ Housley <[email-masked]>
Date: Tue, 11 Jun 2019 12:34:35 -0400

Ben:

I have not heard back from you.  Please let me know if the proposed way forward would resolve your DISCUSS position.

Russ

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 14 Jun 2019 16:26:37 -0500

Hi Russ,

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

> > 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 coul…

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.

> > 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 al…

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.

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

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

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

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

I'm happy to leave this alone.

> >   installing the incorrect next generation certificate in the trust

Wonderful; thanks!

> >   actively using the self-signed certificates.

Ah, that is fairly clever.

Thanks,

Ben

---

From: Russ Housley <[email-masked]>
Date: Tue, 25 Jun 2019 14:56:19 -0400

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

No worries.  I moved a few months ago, no nearly as far as your move, and it was still quite disruptive.

> public key does not have a certificate, such as when it's a browser.

Two paragraphs later the document talk about the distribution of the certificates:

   Some enterprise and application-specific environments offer a
   directory service or certificate repository to make certificate and
   CRLs available to relying parties.  Section 3 in [RFC5280] describes
   a certificate repository.  When a certificate repository is
   available, the oldWithNew and newWithOld certificates SHOULD be
   published before the successor to the current Root CA self-signed
   certificate is released.  Recipients that are able to obtain the
   oldWithNew certificate SHOULD immediately remove the old Root CA
   self-signed certificate from the trust anchor store.

I believe that covers the case where there is a repository.

I propose to replace the paragraph after that with one that handles the non-repository case and points out that the Wen PKI falls in that case.  See below.

> backwards to satisfy the Web PKI case when the mechanism works fine as-is

Here is the proposed text for the non-repository case.  The first paragraph offers guidance to the Root CA, and the next one offers guidance to recipients:

   In environments without such a directory service or repository, like
   the Web PKI, recipients need a way to obtain the oldWithNew and
   newWithOld certificates.  The Root CA SHOULD include the subject
   information access extension [RFC5280] with the accessMethod set to
   id-ad-caRepository and the assessLocation set to the HTTP URL that
   can be used to fetch a DER-encoded "certs-only" (simple PKI response)
   message as specified in [RFC5272].  The Root CA SHOULD post the
   "certs-only" message with the oldWithNew certificate and the
   newWithOld certificate before the current Root CA self-signed
   certificate is released.  The "certs-only" message format allows
   certificates to be added and removed from the bag of certificates
   over time, so the same HTTP URL can be used throughout the lifetime
   of the Root CA.

   In environments without such a directory service or repository,
   recipients SHOULD keep both the old and replacement Root CA self-
   signed certificates in the trust anchor store for some amount of time
   to ensure that all end-entity certificates can be validated until
   they expire.  The recipient MAY keep the old Root CA self-signed
   certificate until all of the certificates in the local cache that are
   subordinate to it have expired.

I have trimmed the rest of the message because those points have been resolved.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 27 Jun 2019 19:22:09 -0500

> I believe that covers the case where there is a repository.

Definitely.

>    certificate is released.  The "certs-only" message format allows

I might be confused, but if "the current Root CA self-signed certificate is
released" means that people are using the current root, then this doesn't
seem to make much sense -- that requires using the next key to sign
OldWithNew before the current key is usable, which seems counter to the
point of the flow here.  So I think this maybe was supposed to be
"successor" instead of "current"?

>    subordinate to it have expired.

Modulo the above comment, this should be enough to resolve the Discuss.

I think I'm still left a bit unsatisfied by the document since I don't get
a clear picture of what roles "recipients" take.  Presumably this is to
some extent intentional, so as to be relevant in many use cases and not
have to finesse distinctions such as the Web PKI's TLS client and
end-entity server, but my current understanding still includes different
recipients using the root CA for different purposes and getting it in
different ways, and there's something of an impedance mismatch between the
text of the document and my understanding.  I admit the possibility that
the document is fine and my understanding wrong, so I don't want to stand
in the way of the document moving forward.

Thanks,

Ben

---

From: Russ Housley <[email-masked]>
Date: Fri, 28 Jun 2019 12:34:40 -0400

Ben:

Dropping parts where we have reached agreement ...

> "successor" instead of "current"?

You are not confused.  The original self-signed certificate and the successor self-signed certificate should contain the same URL for the "certs-only" message.  This way, a replying party will find the certificate that is needed no matter which trust anchor they are using.  So, yes, you are right the update the "certs-only" message should happen before the successor self-signed certificate is released.  Here is the corrected text:

   In environments without such a directory service or repository, like
   the Web PKI, recipients need a way to obtain the oldWithNew and
   newWithOld certificates.  The Root CA SHOULD include the subject
   information access extension [RFC5280] with the accessMethod set to
   id-ad-caRepository and the assessLocation set to the HTTP URL that
   can be used to fetch a DER-encoded "certs-only" (simple PKI response)
   message as specified in [RFC5272] in all of their self-signed
   certificates.  The Root CA SHOULD publish the "certs-only" message
   with the oldWithNew certificate and the newWithOld certificate before
   the subsequent Root CA self-signed certificate is released.  The
   "certs-only" message format allows certificates to be added and
   removed from the bag of certificates over time, so the same HTTP URL
   can be used throughout the lifetime of the Root CA.

> Modulo the above comment, this should be enough to resolve the Discuss.

I believe that is sorted by the above text.

> in the way of the document moving forward.

There are many ways that the successor self-signed certificate might "become available" (the words used in the Introduction).  A protocol could be used to push it out, or the recipient could simply process a certification path that includes it.  Flexibility is intentional; the answer may be very different in a private PKI and the Web PKI.  The experimental RFC specifying the syntax of the extension should not need to cover all of the possible use cases.

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 28 Jun 2019 11:57:03 -0500

> I believe that is sorted by the above text.

I do, too -- thanks.

> There are many ways that the successor self-signed certificate might "become available" (the words used in the Introduction).  A protocol could be used to push it out, or the recipient could simply…

All true.  Let's move forward with this, then -- please publish the new rev
and I can clear.

-Ben

---

From: Russ Housley <[email-masked]>
Date: Fri, 28 Jun 2019 13:44:49 -0400

Ben:

> Let's move forward with this, then -- please publish the new rev
> and I can clear.

Done.

https://www.ietf.org/id/draft-ietf-lamps-hash-of-root-key-cert-extn-06.txt

Russ