doc/wiki-dump/doc%2FRPKI%2FCA%2FBPKIModel.md


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
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]
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]
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)
[3]: /chrome/common/attachment.png (No image "pubd-bpki.png" attached to
doc/RPKI/CA/BPKIModel)