Dump of rpki.net Wiki, to capture content not linked into the manual.

1 files changed, 106 insertions, 0 deletions

diff --git a/doc/wiki-dump/doc%2FRPKI%2FCA%2FBPKIModel b/doc/wiki-dump/doc%2FRPKI%2FCA%2FBPKIModel
new file mode 100644
index 00000000..e3c98cf5
--- /dev/null
+++ b/doc/wiki-dump/doc%2FRPKI%2FCA%2FBPKIModel
@@ -0,0 +1,106 @@
+= The BPKI model =
+
+[[TracNav(doc/RPKI/TOC)]]
+
+The "business PKI" (BPKI) is the PKI used to authenticate
+communication on the up-down, left-right, and publication protocols.
+BPKI certificates are //not// resource PKI (RPKI) certificates.  The
+BPKI is a separate PKI that represents relationships between the
+various entities involved in the production side of the RPKI system.
+In most cases the BPKI tree will follow existing business
+relationships, hence the "B" (Business) in "BPKI".
+
+Setup of the BPKI is handled by the back end; for the most part,
+rpkid and pubd just use the result.  The one place where the engines
+are directly involved in creation of new BPKI certificates is in the
+production of end-entity certificates for use by the engines.
+
+For the most part an ordinary user of this package need not worry
+about the details explained here, as the [[rpkic|rpkic tool]]
+takes care of all of this.  However, users who want to understand
+what's going on behind the scenes or who have needs too complex for
+the myrpki tool to handle might want to understand the underlying
+model.
+
+There are a few design principals that underly the chosen BPKI model:
+
+* Each engine should rely on a single BPKI trust anchor which is
+  controlled by the back end entity that runs the engine; all other
+  trust material should be cross-certified into the engine's BPKI
+  tree.
+
+* Private keys must never transit the network.
+
+* Except for end entity certificates, the engine should only have
+  access to the BPKI certificates; in particular, the private key for
+  the BPKI trust anchor should not be accessible to the engine.
+
+* The number of BPKI keys and certificates that the engine has to
+  manage should be no larger than is necessary.
+
+rpkid's hosting model adds an additional constraint: rpkid's BPKI
+trust anchor belongs to the entity operating rpkid, but the entities
+hosted by rpkid should have control of their own BPKI private keys.
+This implies the need for an additional layer of BPKI certificate
+hierarchy within rpkid.
+
+Here is a simplified picture of what the BPKI might look like for an
+rpkid operator that hosts two entities, "Alice" and "Ellen":
+
+[[Image(rpkid-bpki.png)]]
+
+Black objects belong to the hosting entity, blue objects belong to
+the hosted entities, red objects are cross-certified objects from
+the hosted entities' peers.  The arrows indicate certificate
+issuance: solid arrows are the ones that rpkid will care about
+during certificate validation, dotted arrows show the origin of the
+EE certificates that rpkid uses to sign CMS and TLS messages.
+
+The certificate tree looks complicated, but the set of certificates
+needed to build any particular validation chain is obvious.
+
+Detailed instructions on how to build a BPKI are beyond the scope of
+this document, but one can handle simple cases using the OpenSSL
+command line tool and cross_certify; the latter is a tool
+designed specifically for the purpose of generating the
+cross-certification certificates needed to splice foreign trust
+material into a BPKI tree.
+
+The BPKI tree for a pubd instance is similar to to the BPKI tree for
+an rpkid instance, but is a bit simpler, as pubd does not provide
+hosting in the same sense that rpkid does: pubd is a relatively
+simple server that publishes objects as instructed by its clients.
+
+Here's a simplified picture of what the BPKI might look like for a
+pubd operator that serves two clients, "Alice" and "Bob":
+
+[[Image(pubd-bpki.png)]]
+
+While it is likely that RIRs (at least) will operate both rpkid and
+pubd instances, the two functions are conceptually separate.  As far
+as pubd is concerned, it doesn't matter who operates the rpkid
+instance: pubd just has clients, each of which has trust material
+that has been cross-certified into pubd's BPKI.  Similarly, rpkid
+doesn't really care who operates a pubd instance that it's been
+configured to use, it just treats that pubd as a foreign BPKI whose
+trust material has to be cross-certified into its own BPKI.  Cross
+certification itself is done by the back end operator, using
+cross_certify or some equivalent tool; the resulting BPKI
+certificates are configured into rpkid and pubd via the left-right
+protocol and the control subprotocol of the publication protocol,
+respectively.
+
+Because the BPKI tree is almost entirely controlled by the operating
+entity, CRLs are not necessary for most of the BPKI.  The one
+exception to this is the EE certificates issued under the
+cross-certification points.  These EE certificates are generated by
+the peer, not the local operator, and thus require CRLs.  Because of
+this, both rpkid and pubd require regular updates of certain BPKI
+CRLs, again via the left-right and publication control protocols.
+
+Because the left-right protocol and the publication control
+subprotocol are used to configure BPKI certificates and CRLs, they
+cannot themselves use certificates and CRLs configured in this way.
+This is why the configuration files for rpkid and pubd require
+static configuration of the left-right and publication control
+certificates.