Date: Mon, 23 Oct 2017 07:56:33 -0400 From: Eric McCorkle <eric@metricspace.net> To: freebsd-arch@freebsd.org, freebsd-arch@freebsd.org, "freebsd-hackers@freebsd.org" <freebsd-hackers@FreeBSD.org> Subject: Re: Trust system write-up Message-ID: <cd7d0bfa-d620-1382-3ce6-28db874e6049@metricspace.net> In-Reply-To: <20171023071120.GA72383@blogreen.org> References: <1a9bbbf6-d975-0e77-b199-eb1ec0486c8a@metricspace.net> <20171023071120.GA72383@blogreen.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/23/2017 03:11, Romain Tartière wrote: > Hello Eric, > > On Sun, Oct 22, 2017 at 06:14:40PM -0400, Eric McCorkle wrote: >> The following is a write-up of my current design for a public-key trust >> system: >> >> https://www.metricspace.net/files/freebsd_trust.pdf > > Two minor things while reading: > 1. p2: from a end-user perspective, `trustctl` expects DER encoded > certificates and CRL; while `certs` and `rootcerts` outputs PEM > encoded certificates… So the formats are not the same, and maybe > consistency would be advisable here; There's a reason for that. The binary DER encoding is very easy to parse, and is far less likely to end up with vulnerabilities. Prior to learning about the discussion surrounding BearSSL, I had been working on a minimal PKI implementation which only parsed binary DER because it confers a number of advantages. Each element has a length, so it's easy to detect malicious or bad data and avoid overruns. Also, you can easily skip over data you don't need (such as the complex distinguished name structures), and since it's a distinguished encoding, you can treat any element as an opaque byte pointer for comparison purposes. All this closes off a number of attack vectors. PEM encoding is what applications use, and it's much easier to generate than to parse. Generating it is straightforward if you have the DER-encoded data lying around, whereas parsing introduces a number of possible errors. > 2. p3: 'the preferred configuration' is said to be the most used one, > but as described it only includes a single crt+key and does not look > suitable for distributing upgrades with freebsd-update(8). > Unless I missed something, I guess it's just the way it is described > that needs disambiguation: The idea is that you'd sign FreeBSD's vendor certificate with the local system key and add this to your intermediate certificates that get loaded at boot time. The installer would probably generate a local keypair, install it as a root trust certificate, then sign the FreeBSD vendor certificate and install it as an intermediate trust certificate. This would be enough to get an initial system up and running. Users that don't want to trust the FreeBSD cert could then do a buildworld and delete the signed FreeBSD cert from the intermediate certificate store. > Hybrid systems can be built by having more than one root node: > - "preferred configuration" have a local key+crt (as an local node) > AND the FreeBSD's project crt. > So these nodes can run FreeBSD's code and their own code. > - "standard FreeBSD images" as described have the FreeBSD's project > crt. When installing, they generates a local key+crt and add them > with the FreeBSD crt to the new system's trust store. So these > images have the "high-security institutions" scheme, and install > systems in the "preferred configuration" scheme. That is also an option; however, I prefer the configuration where only the local system key is a root and everything else is an intermediate, as each root key represents a source of trust that is hard to revoke (you have to power-cycle). It's almost always better to have a single root, and make everything else an intermediate, though I'm not sure enough of that to bake it into the specification.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cd7d0bfa-d620-1382-3ce6-28db874e6049>