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

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 26 Sep 2016 18:57:20 -0700

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.

Pull request: https://github.com/ietf-wg-acme/acme/pull/194

---

From: Hugo Landau <[email-masked]>
Date: Tue, 27 Sep 2016 06:14:53 +0100

> aligns the easiest thing with the most correct thing.

- What happens to Link rel=up? You've left it in.

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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 26 Sep 2016 22:27:33 -0700

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