Subject: [Acme] Certificate chains including roots

From: Hugo Landau <[email-masked]>
Date: Mon, 12 Mar 2018 12:25:14 +0000

The current specification seems a bit ambiguous regarding whether a PEM
certificate chain includes the root CA certificate.

Most of the time the root CA shouldn't be included in a certificate
chain sent by a TLS server. However, there are circumstances in which it
is essential; namely, when DANE is used. As such, it's essential that a
client have some way to get the root certificate. Since the current
certificate retrieval protocol no longer uses link rel=up, the only way
with the specification as it stands is to always include the root
certificate in the chain.

Options:

  1. Clarify the specification to state that the root certificate must
     always appear in the chain at the end. Clients should be advised to
     pop the root certificate if they are procuring certificate chains
     for non-DANE applications only. Failure to do so will result in
     unnecessary but harmless transmission of the root certificate
     during TLS handshakes.

  2. Don't include the root certificate but provide a way to retrieve it,
     e.g. via a Link header.

  3. Clarify the specification to state that the root certificate must
     not appear in the chain, and that roots must be retrieved using the
     AIA URL inside the final certificate in the chain if it is needed.
     This minimises the chance of clients for non-DANE applications
     messing up and provides a viable method for discovery of the root
     CA for applications which need it.

I'd support option 1 or option 3 equally. Either way, I think this
should be clarified.

Thoughts?

---

From: Jörn Heissler <[email-masked]>
Date: Mon, 12 Mar 2018 15:56:56 +0100

> I'd support option 1 or option 3 equally. Either way, I think this

There's one more option which I'd actually prefer.

  4. Root certificate does not appear in the chain but it's expected
     that clients already know it. E.g. look in /etc/ssl/certs/.

Rationale is that the client shouldn't blindly trust that the chain
received by the acme server is valid.

---

From: Philipp Junghannß <[email-masked]>
Date: Mon, 12 Mar 2018 16:01:24 +0100

But isn't the point of this proposal that the client CANNOT be expected
knowing the root like with DANE/TLSA'd servers with a custom root or
whatever?

Am 12.03.2018 15:57 schrieb "Jörn Heissler" <[email-masked]>:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Jörn Heissler <[email-masked]>
Date: Mon, 12 Mar 2018 16:14:12 +0100

> knowing the root like with DANE/TLSA'd servers with a custom root or

I must admit that I'm not very familiar with DANE.

What would be a typical use case where you use ACME but you don't
already know the root cert?

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Mar 2018 15:26:21 +0000

The usage model I think we should aim for is where chains are used
as-is.  For instance, the chain is fed straight to the HTTPS server.
There is reasonably strong advice against sending trust anchor
certificates over the wire, and most software simply spools out
everything it is given.

I thought that we already had this discussion and concluded that roots
wouldn't be included.  That's consistent with the above.

Obviously that would leave this open to some discretion, but that's
OK.  For instance, during the period that a new CA has a
cross-signature on their root, they might include their own anchor for
maximum compatibility, but they might phase that out over time.  But
the CA is in a reasonable position to know when to move, and it isn't
as though this would prevent clients from adding or removing as they
see fit.

---

From: Hugo Landau <[email-masked]>
Date: Wed, 14 Mar 2018 17:52:47 +0000

> certificates over the wire, and most software simply spools out
I agree, but it's impossible to make this work for every case. Most of
the time the root certificate shouldn't be served. Sometimes it
absolutely must be.
> as though this would prevent clients from adding or removing as they
Not including the root certificate in the chain seems reasonable to me,
so long as a means is provided to discover it. Not imposing an absolute
MUST NOT prohibiting including the root certificate in the chain so as
to allow CA discretion also seems reasonable. I'd argue a SHOULD NOT is
warranted here, though.

As for requiring a client to enumerate the system trust store to match
up certificates, this is problematic because a client may not have a
portable way to enumerate the system trust store, even if it has a
portable way to make HTTPS requests for the purposes of accessing the
ACME API. It also creates a dependency between the system trust store
and what CA issues the certificates one is acquiring, which creates
another thing which can go wrong.

The use of the AIA extension in intermediates is, AFAIK common and is
used by Let's Encrypt, so this seems like a good vehicle for
autodiscovery. Use of AIA could be RECOMMENDED. A Link header would also
do (and is AFAIK exposed when content negotiation negotiates DER, so as
this stands it's a bit inconsistent).

To summarise, I think the standard should recommend that root
certificates not be included but also guarantee a viable method for
discovery.

---

From: Hugo Landau <[email-masked]>
Date: Wed, 14 Mar 2018 17:57:43 +0000

> received by the acme server is valid.
See my other reply. But to respond to this specifically, can you explain
what threat model is mitigated
by distrusting the chain served by the ACME server?

So far in my client I've explicitly avoided doing any actual
trust-anchor-based validation of the returned chain, and it's unclear to
me what the value of it would be for the complexity (and reliance on
system trust stores and their potential variability) it introduces.

---

From: Hugo Landau <[email-masked]>
Date: Wed, 14 Mar 2018 18:11:45 +0000

> already know the root cert?
Where DANE is used, a trust anchor is referenced by a hash of its public
key or certificate, which is placed in a DNSSEC-secured DNS record. This
trust anchor isn't necessarily one already known to the client
connecting to a TLS server, since the whole idea is that DANE/DNSSEC is
the real trust anchor and whatever CA is used for the TLS server
certificate is trusted by virtue of being referenced by hash.

Because of this, where DANE is used, the trust anchor must be served by
the TLS server in the certificate chain. This is a waste of bandwidth
but otherwise harmless where DANE is not used, but is critical when
supporting DANE.

An ACME setup shouldn't be expected to know the root certificate because
it may change over time. For example, currently Let's Encrypt serves
certificates using the IdenTrust cross-signed intermediates. It could at
some point switch to using its own ISRG root, once it has sufficient
prevalence in trust stores; if an ACME setup makes assumptions about
what root an ACME server issues using, breakage would result when this
happens. Moreover root certificates do have an eventual expiry date and
need to be swapped out. (Or acquired CAs could desire to switch to a new
root without breaking servers, or so on, and so forth.)

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Wed, 14 Mar 2018 15:21:16 -0500

One fine point here:

You assert that an ACME setup should not require knowledge of the root certificate because it may change over time, but if we extend that to a complicated trust chain, that logic doesn’t necessarily work.

For example:

For ISRG/Let’s Encrypt, the system certainly knows the ICA it’s issuing from (generally Let’s Encrypt X3…)  The server produces the certificate and the “full chain” is the certificate plus the issuing CA.

But what if Let’s Encrypt's (or any other organization’s) issuing certificate trust chain were more complicated.

Imagine that there’s a “Let’s Encrypt BR Compliant WebPKI Server Certificate CA” which is signed by an Identrust Root and this offline CA has further signed two subordinate issuing CAs (X3 and X4).  In this instance, the “full chain” returned by the ACME server should include both the issuing ICA certificate AND the parent certificate of that, as it is that parent which chains directly to a trust anchor.

So you either have to have the ACME server discern that via explicit config or AIA for any complicated cases.

Imagine some branch of the US Government implementing an ACME server inside the massive and complex Federal PKI.  Producing that “full chain” less trust anchor is no more or less difficult than producing it with the trust anchor.

> On Mar 14, 2018, at 1:11 PM, Hugo Landau <[email-masked]> wrote:
> 
>

---

From: Jörn Heissler <[email-masked]>
Date: Wed, 14 Mar 2018 21:25:31 +0100

> by distrusting the chain served by the ACME server?

It's certainly far-fetched: Assume you've currently got a valid
certificate installed. It will expire in 3 Weeks, so you're going to
renew it. The CDN in front of the ACME server, or your
enterprise MitM appliance, could send you a broken certificate. If you
blindly install it, your website will be down immediately. If you verify
the cert+chain and thus notice the problem, you've got three Weeks to address
the problem.
So it mitigates a possible DoS by a malicious party or simply some
malfunction somewhere.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 14 Mar 2018 16:27:12 -0400

This matches my understanding.  ACME cannot be prescriptive on this, not
least because the notion of a "root certificate" is not well defined for
the server -- the server doesn't know what the client does or does not
trust.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 14 Mar 2018 14:23:49 -0700

>      CA for applications which need it.
This seems fine to me.

To push a little more on why it's required, though: In DANE, you might
indicate a trust anchor in your records. Presumably that trust anchor
could be either a self-signed root, or an intermediate issuer
certificate, right?

The reason to prefer putting a root in DNS rather than an issuer is
generally that the root won't change as often, right? But if you're
automating DANE updates based on the returned certificate chain, why not
just use the issuer, and update the trust anchor record every time a new
certificate is issued?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Mar 2018 21:52:05 +0000

>>      CA for applications which need it.

MUST NOT is too strong.  Advise against it in the same way that TLS
does.  Even point to TLS.

Adding a note that when intended for a particular use (such as for
securing HTTPS), the chain that is provided should be directly usable
in that context and might need some assumptions about what relying
parties in that context need.

Don't require AIA or even use it.  It's a mess and not widely
deployed.  It's mostly just a waste of bytes - it's not like you can
remove it from a certificate once added (sure, if your intermediate
has it, then that's fine, but I'd content that this is a mistake).
You could use an "up" link relation (or whatever we decided works for
that) on the response if you feel that providing a link to the root is
necessary.

> could be either a self-signed root, or an intermediate issuer

DANE adds a whole new dimension to this problem.  I think that if the
expectation is that DANE is used, then the server will need to be told
about this so that it can adjust as needed.  Often that means a
shorter chain.  However, I think that this sort of optimization is an
extension and doesn't really belong in the core spec (i.e., ship the
damned thing already and stop messing with it).

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 14 Mar 2018 15:22:54 -0700

> MUST NOT is too strong.  Advise against it in the same way that TLS
Good point, I'd missed that the above could be normative language. I
agree we shouldn't be more restrictive than TLS on this issue.