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
99
100
101
102
103
104
105
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.
|
