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

On Tue, Jun 25, 2019 at 02:56:19PM -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.
> 
> No worries.  I moved a few months ago, no nearly as far as your move, and it was still quite disruptive.
> 
> 
> >>>> ----------------------------------------------------------------------
> >>>> 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.
> 
> 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.

Definitely.

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

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

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

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