Re: what can go in root.crt ?

On Fri, Jun 12, 2020 at 04:17:56PM -0400, Chapman Flack wrote:
> On 06/12/20 15:13, Bruce Momjian wrote:
> > Without that ability, every client would need be changed as soon as the
> > server certificate was changed.  Allowing intermediate certificates to
> > function as root certificates would fix that problem.  When the
> > non-trusted CA changes your certificate, you are going to have the same
> > problem updating everything at once.
> 
> There seems to be a use of language here that works to make the picture
> muddier rather than clearer.
> 
> I mean the use of "trusted"/"non-trusted" as if they somehow mapped onto
> "self-signed"/"not self-signed" (unless you had some other mapping in mind
> there).

I meant you trust your local/intermediate CA, but not the root one. 

> That's downright ironic, as a certificate that is self-signed is one that
> carries with it the absolute minimum grounds for trusting it: precisely
> zero. There can't be any certificate you have less reason to trust than
> a self-signed one.

Self-signed certs can certainly be trusted by the creator. Organizations
often create self-signed certs that are trusted inside the organization.

> As far as the TLS client is concerned, the endorsement that counts is
> still the local one, that it has been placed in the local file by the
> admin responsible for deciding what this client should trust. The fact
> that somebody else vouched for it too is no reason for this client
> to trust it, but is also no reason for this client not to trust it.
> It is certainly in no way less to be trusted than a cert signed only
> by itself.

Yes, I see your point in that the intermediate has more validity than a
self-signed certificate, though that extra validity is useless in the
use-case we are describing.

> But once you have followed those steps and arrived at a cert that
> was placed in your trust store by the admin, it's unnecessary and
> limiting to insist arbitrarily on other properties of the cert you
> found there.

Well, I can see the use-case for what you are saying, but I also think
it could lead to misconfiguration.  Right now, Postgres uses the client
root.cert, which can contain intermediates certs, and the
server-provided cert, which can also contain intermediates shipped to
the client, to try to check for a common root:

    https://www.postgresql.org/docs/13/ssl-tcp.html

What you are suggesting is that we take the server chain and client
chain and claim success when _any_ cert matches between the two, not
just the root one.

I can see that working but I can also imagine people putting only
intermediate certs in their root.cert and not realizing that they are
misconfigured since they might want to expire the intermediate someday
or might want to trust a different intermediate from the same root. 
Frankly, we really didn't even documention how to handle intermediate
certificates until 2018, which shows how obscure this security stuff can
be:

    https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=815f84aa16

Do we want to allow such cases, or is the risk of misconfiguration too
high?  I am thinking it is the later.  I think we could have a libpq
parameter that allowed it, but is there enough demand to add it since it
would be a user-visible API?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee