1 files changed, 98 insertions, 0 deletions
diff --git a/doc/wiki-dump/doc%2FRPKI%2FCA%2FBPKIModel.md b/doc/wiki-dump/doc%2FRPKI%2FCA%2FBPKIModel.md
new file mode 100644
index 00000000..acfe557e
--- /dev/null
+++ b/doc/wiki-dump/doc%2FRPKI%2FCA%2FBPKIModel.md
@@ -0,0 +1,98 @@
+# The BPKI model
+
+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 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":
+
+[![No image "rpkid-bpki.png" attached to doc/RPKI/CA/BPKIModel][1]][2]
+
+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":
+
+[![No image "pubd-bpki.png" attached to doc/RPKI/CA/BPKIModel][3]][4]
+
+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.
+
+   [1]: /chrome/common/attachment.png (No image "rpkid-bpki.png" attached to
+doc/RPKI/CA/BPKIModel)
+
+   [2]: /attachment/wiki/doc/RPKI/CA/BPKIModel/rpkid-bpki.png
+
+   [3]: /chrome/common/attachment.png (No image "pubd-bpki.png" attached to
+doc/RPKI/CA/BPKIModel)
+
+   [4]: /attachment/wiki/doc/RPKI/CA/BPKIModel/pubd-bpki.png
+