Re: what can go in root.crt ?

On 06/12/20 16:17, Chapman Flack wrote:
> reason. Typically that reason is that it has been placed in a file that
> can only be edited by the admin who decides what certs to trust. By
> editing it into that file, that responsible person has vouched for it,
> and /that/ is why the TLS client should trust it.

In order to wave my hands less, and map more easily onto the RFCs,
I ought to start saying these things:

Relying Party       when I mean libpq in its role of validating a server

Trust Anchor Store  when I mean libpq's root.crt file

Trust Anchor Manager  when I mean me, putting a thing into root.crt

Trust Anchor        when I mean a thing I put into root.crt

Target Certificate  the one the Relying Party wants to validate; in this
                    case, the end-entity cert assigned to the pgsql server

Certification Path Validation   the algorithm in RFC 5280 sec. 6

Certification Path Building     the task described in RFC 4158



RFC 5280 expresses the Path Validation algorithm as starting from
a Trust Anchor and proceeding toward the Target Certificate. In this
thread so far I've been waving my hands in the other direction, but
that properly falls under Path Building.

If your Trust Anchor Store contains only one Trust Anchor, then the
Path Validation algorithm is all you need. If there may be multiple
Trust Anchors there, Path Building is the process of enumerating
possible paths with a Trust Anchor at one end and the Target Certificate
at the other, in the hope that Path Validation will succeed for at least
one of them.

RFC 4158 isn't prescriptive: it doesn't give one way to build paths, but
a smörgåsbord of approaches. Amusingly, what it calls "forward path
building" is when you start from the Target Certificate and search toward
a Trust Anchor (same way I've been waving my hands, but reversed w.r.t.
Path Validation), and what it calls "reverse path building" is when you
start with your Trust Anchors and search toward the Target Certificate
(the same direction as Path Validation).

RFC 4158 has an extensive gallery of ASCII art showing what the PKI
can end up looking like in some large enterprises.  :O



Initial inputs to Path Validation include a distinguished name and
a public key, optionally with some constraints, and those things come
from a Trust Anchor. There is no requirement that a Trust Anchor be
a cert, signed, self-signed, or otherwise. The certificate format has
often been used as a Trust Anchor container format because, hey, it
holds a distinguished name and a public key and constraints, and if
you're writing a path validator, you already have a parser for it.

Other things that happen to be present in a certificate-as-Trust-Anchor,
such as an issuer name, key, and signature, are non-inputs to the path
validation algorithm and have no effect on it.

Disappointingly, common implementations have tended also to ignore
constraints held in a certificate-as-Trust-Anchor, even though they
correctly apply constraints in other certs encountered along the path,
and initial constraints are supposed to be inputs to the algorithm.
It is the point of RFC 5937 to fix that.

'Constraints' in this context are limits such as "this cert is for
identifying servers" or "this is a CA cert but only allowed to sign
certs for *.example.com". The RFCs plainly anticipate that I might
want to put new constraints on a Trust Anchor, say to use the cert
of a CA that has other customers, without implying a trust relationship
with their other customers.

For that purpose, the historical 'convenience' of using certificates
as Trust Anchor containers is a genuine hindrance, because of course
certificates are cryptographically signed objects so editing their
constraints can't be easily done.[1]

The Trust Anchor Format (cited in [1] as "in progress" but since published
as RFC 5914) therefore proposes a couple alternatives to the use of a
certificate as an ersatz Trust Anchor container.

RFC 6024, Trust Anchor Management Requirements, sets out the considerations
RFC 5914 and RFC 5934 were to address. (In classic see-I-did-it-perfectly
fashion, it was published after they were.)


So, if libpq had a Trust Anchor Store that worked as described in these
RFCs, my use case would be trivial to set up.

I guess the next question is to what extent recent OpenSSL groks those,
or how far back was the first version that did (these RFCs are from 2010),
and what would be entailed in taking advantage of that support if it's
present.

Regards,
-Chap


[1] https://dl.acm.org/doi/10.1145/1750389.1750403