Subject: Re: [Acme] Default to PEM with chain for certificates

From: Richard Barnes <[email-masked]>
Date: Sun, 2 Oct 2016 11:49:47 -0400

This change seems to suppose that there is One True Cert Chain, and the CA
is the one to provide it.  Clearly neither of these is true.

On Tue, Sep 27, 2016 at 1:27 AM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> On 09/26/2016 10:14 PM, Hugo Landau wrote:
> >> One of the most common ACME deployment failures observed in practice is
> >> for servers to be configured to serve only the end-entity certificate,
> >> without the intermediate certificates. This is a particularly pernicious
> >> problem because some browsers will still trust the resulting
> >> one-certificate chain, due to caching or fetching of URLs from Authority
> >> Information Access. But other browsers will not, resulting in a "works
> >> on my computer" problem.
> >>
> >> Arguably this configuration is the result of incorrect clients, but we
> >> should expect that most clients will do the easiest thing. This change
> >> aligns the easiest thing with the most correct thing.
> > - What happens to Link rel=up? You've left it in.
> Good question. I left it in mainly for the DER form, since DER can only
> contain a single certificate.
>
> A couple of options:
>  - Link rel=up exists only when requesting DER
>  - Keep Link rel=up for PEM, and specify that each href is an issuer
> certificate for the end-entity certificate. There would be some
> potential redundancy here but it offers a lot of expressive power.
>  - Specify a new Link rel=alternate, that would provide alternate fully
> built PEM chains. This would address your question about expressing a
> reverse tree of signers, below.
>
> > - What about certificates signed by an intermediate with multiple
> >   signers, and thus multiple actual intermediate certificates for the
> >   same intermediate Subject/public key? I'm not sure but I think there
> >   was some discussion on the list about using multiple Link rel=up
> >   headers to express a reverse tree
> >   (end entity -> { intermediate-signer1 -> signer1
> >                  | intermediate-signer2 -> signer2 }.)
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Andrew Ayer <[email-masked]>
Date: Sun, 2 Oct 2016 18:15:31 -0700

On Sun, 2 Oct 2016 11:49:47 -0400
Richard Barnes <[email-masked]> wrote:

> This change seems to suppose that there is One True Cert Chain, and
> the CA is the one to provide it.  Clearly neither of these is true.

I disagree.  The One True Cert Chain is the shortest chain that will be
trusted by the most platforms, weighted by the platforms' market
shares.  Building this certificate chain is complicated and requires
knowledge of PKI and access to every platform's trust store.  Clients
and their implementers shouldn't be expected to have either, but the CA
certainly has both.

A small minority of people may require a different chain (e.g. they're
willing to forgo some platforms to get a smaller TLS handshake, or they
need a different cross-sign so they can support a platform that didn't
make the cut for the default chain).  Those users can request the DER
version and use rel=up to construct their own chain.  I think it's
reasonable to use multiple rel=up links if there is more than one issuer
certificate.

A CA-provided default chain will save clients a lot of work and prevent
a lot of errors.  +1 for Jacob's change.

Regards,
Andrew

---

From: Richard Barnes <[email-masked]>
Date: Mon, 3 Oct 2016 08:00:38 -0400

I appreciate the sentiment.  It seems morally right that the PKI should be
that simple.  But in practice, it's not.  That's why the world needs tools
like Ubiquity that have full scoring algorithms:

https://godoc.org/github.com/cloudflare/cfssl/ubiquity

---

From: Andrew Ayer <[email-masked]>
Date: Mon, 3 Oct 2016 07:47:32 -0700

On Mon, 3 Oct 2016 08:00:38 -0400
Richard Barnes <[email-masked]> wrote:

> I appreciate the sentiment.  It seems morally right that the PKI
> should be that simple.  But in practice, it's not.  That's why the
> world needs tools like Ubiquity that have full scoring algorithms:
> 

Right, and it's the CA that should be integrating something like
Ubiquity in order to determine the default chain.  The CLI tool for
Ubiquity supports an option called "ubiquitous", which according to the
documentation generates "a bundle of most widely acceptance across
different browsers and OS platforms."[1]  How often do you think clients
would not want "ubiquitous"?  Enough to make every single client depend
on Ubiquity or a library of similar complexity?

Regards,
Andrew

[1] https://github.com/cloudflare/cfssl/blob/master/README.md

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 12 Oct 2016 15:22:27 -0700

On 10/02/2016 08:49 AM, Richard Barnes wrote:
> This change seems to suppose that there is One True Cert Chain

It does not suppose that. It supposes most CAs will offer One
Recommended Cert Chain that is "best" for most of their customers. And
in fact that is the best common practice today.

Alternate chains can be offered with the Link rel=alternate that I
mentioned on-list (but haven't yet incorporated into the PR). What do
you think of that approach?

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 25 Oct 2016 18:11:34 -0700

I've updated https://github.com/ietf-wg-acme/acme/pull/194 to reflect
the Link: rel="alternate" concept. Are there any further comments on
this change? I'd like to get it merged by the Monday draft deadline.