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
|
% $Id$
%
\documentclass[11pt]{article}
\usepackage[pdftex]{graphicx}
\usepackage{palatino}
\usepackage{color}
\DeclareGraphicsExtensions{.pdf}
\setlength{\topmargin}{0in}
\setlength{\headheight}{0in}
\setlength{\headsep}{0in}
\setlength{\oddsidemargin}{0in}
\setlength{\evensidemargin}{0in}
\setlength{\textheight}{9in}
\setlength{\textwidth}{6.5in}
\setlength{\parskip}{2ex}
\setlength{\parindent}{0in}
\hyphenpenalty=5000
\tolerance=1000
\hbadness=9999
\sloppy
\pagestyle{plain}
%
\begin{document}
\section*{Implementation experience with the two BPKI models}
Having recently converted my code base to the single-trust-anchor
model Russ recommended, I thought it might be useful to share what
I've learned. This may not apply to all implementations, but it does
apply to mine, and given what I understand of RIPE's business model,
it will probably apply to RIPE's implementation as well.
In spite of a strong desire to do so, I was not able to use exactly
the same BPKI keys and certificates for HTTPS and CMS. The reason for
this is simple: each hosted entity in my engine has its own BPKI, as
does the hosting entity, but the HTTPS listener is shared. The only
ways I know of to avoid this would be to use separate listeners for
each hosted entity, which scales poorly, or to rely on the TLS
``Server Name Indication'' extension (RFC 4366 3.1) which is not yet
widely implemented.
Here's my engine's view of the BPKI tree in the symmetric model
(explanation follows):
\begin{center}
\includegraphics[width = 6.5in]{bpki-symmetric}
\end{center}
Black objects belong to the hosting entity, blue objects belong to the
hosted entities, red objects are cross-certified objects from peers.
The arrows indicate certificate issuance: solid arrows are the ones
that my own RPKI engine will care about during certificate validation,
dashed arrows show the origin of EE certificates my engine uses to
sign things. ``BSC'' stands for ``business signing context,'' which
is a database object in my implementation representing the context
needed to sign a CMS message or TLS session.
Other than the above-mentioned annoyance with the HTTPS server
certificate, the ``symmetric'' BPKI model worked out pretty much as
expected here. The certificate tree looks complicated, but the set of
certificates needed to build a particular validation chain is obvious,
again excepting the HTTPS server case, where client certificate is the
first hint that the engine has of the client's identity, so the server
must be prepared to accept any current client certificate.
Here's my engine's view of the BPKI tree in the asymmetric model:
\begin{center}
\includegraphics[width = 6.5in]{bpki-asymmetric}
\end{center}
Note that not much has changed here from the symmetric case. As far
as I can tell, the asymmetric model is just as complex for my engine
as the symmetric model; the only real difference is that the engine
has to keep track of a larger number of BSC EE certificates in the
asymmetric case.
\end{document}
|
