diff options
| -rw-r--r-- | docs/Makefile | 9 | ||||
| -rw-r--r-- | docs/bpki-asymmetric.dot (renamed from docs/bpki.dot) | 53 | ||||
| -rw-r--r-- | docs/bpki-asymmetric.pdf | bin | 0 -> 5150 bytes | |||
| -rw-r--r-- | docs/bpki-symmetric.dot | 59 | ||||
| -rw-r--r-- | docs/bpki-symmetric.pdf | bin | 0 -> 4586 bytes | |||
| -rw-r--r-- | docs/bpki.pdf | bin | 7456 -> 45973 bytes | |||
| -rw-r--r-- | docs/bpki.tex | 78 |
7 files changed, 145 insertions, 54 deletions
diff --git a/docs/Makefile b/docs/Makefile index 1524df0a..c352212a 100644 --- a/docs/Makefile +++ b/docs/Makefile @@ -2,10 +2,17 @@ all: rpki-db-schema.pdf sample-irdb.pdf repository-engine-objects.pdf bpki.pdf -.SUFFIXES: .pdf .sql .dot +bpki.pdf: bpki-symmetric.pdf bpki-asymmetric.pdf + +.SUFFIXES: .pdf .sql .dot .tex .sql.pdf: sh ../scripts/graphviz-sql.sh $< .dot.pdf: dot -Tps2 $< | ps2pdf - $@ + +.tex.pdf: + pdflatex $< + pdflatex $< + rm -f $*.log $*.aux diff --git a/docs/bpki.dot b/docs/bpki-asymmetric.dot index d2cc8424..9497b27e 100644 --- a/docs/bpki.dot +++ b/docs/bpki-asymmetric.dot @@ -1,10 +1,5 @@ // $Id$ // -// Pictures to show why I prefer the symmetric BPKI model. As far as -// I can tell, the asymmetric model is every bit as complex for me as -// the symmetric model; the only difference is the added annoyance of -// having to keep track of a larger number of BSC EE certificates. -// // Color code: // Black: Hosting entity // Blue: Hosted entity @@ -15,54 +10,6 @@ // Diamond: CA // Record: EE -digraph bpki_symmetric { - rotate = 90; size = "11,8.5"; splines = true; ratio = fill; - - // Hosting entity - node [ color = black, shape = record ]; - TA [ shape = octagon ]; - rpkid [ label = "rpkid|{HTTPS server|HTTPS left-right client|CMS left-right}" ]; - irdbd [ label = "irdbd|{HTTPS left-right server|CMS left-right}" ]; - irbe [ label = "IRBE|{HTTPS left-right client|CMS left-right}" ]; - - // Hosted entities - node [ color = blue, fontcolor = blue ]; - Alice_CA [ shape = diamond ]; - Alice_EE [ label = "Alice\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; - Ellen_CA [ shape = diamond ]; - Ellen_EE [ label = "Ellen\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; - - // Peers - node [ color = red, fontcolor = red, shape = diamond ]; - Bob_CA; - Carol_CA; - Dave_CA; - Frank_CA; - Ginny_CA; - Harry_CA; - - edge [ color = black, style = solid ]; - TA -> Alice_CA; - TA -> Ellen_CA; - - edge [ color = black, style = dashed ]; - TA -> rpkid; - TA -> irdbd; - TA -> irbe; - - edge [ color = blue, style = solid ]; - Alice_CA -> Bob_CA; - Alice_CA -> Carol_CA; - Alice_CA -> Dave_CA; - Ellen_CA -> Frank_CA; - Ellen_CA -> Ginny_CA; - Ellen_CA -> Harry_CA; - - edge [ color = blue, style = dashed ] - Alice_CA -> Alice_EE; - Ellen_CA -> Ellen_EE; -} - digraph bpki_asymmetric { rotate = 90; size = "11,8.5"; splines = true; ratio = fill; diff --git a/docs/bpki-asymmetric.pdf b/docs/bpki-asymmetric.pdf Binary files differnew file mode 100644 index 00000000..cf444ab2 --- /dev/null +++ b/docs/bpki-asymmetric.pdf diff --git a/docs/bpki-symmetric.dot b/docs/bpki-symmetric.dot new file mode 100644 index 00000000..968715d9 --- /dev/null +++ b/docs/bpki-symmetric.dot @@ -0,0 +1,59 @@ +// $Id$ +// +// Color code: +// Black: Hosting entity +// Blue: Hosted entity +// Red: Cross-certified peer +// +// Shape code: +// Octagon: TA +// Diamond: CA +// Record: EE + +digraph bpki_symmetric { + rotate = 90; size = "11,8.5"; splines = true; ratio = fill; + + // Hosting entity + node [ color = black, shape = record ]; + TA [ shape = octagon ]; + rpkid [ label = "rpkid|{HTTPS server|HTTPS left-right client|CMS left-right}" ]; + irdbd [ label = "irdbd|{HTTPS left-right server|CMS left-right}" ]; + irbe [ label = "IRBE|{HTTPS left-right client|CMS left-right}" ]; + + // Hosted entities + node [ color = blue, fontcolor = blue ]; + Alice_CA [ shape = diamond ]; + Alice_EE [ label = "Alice\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; + Ellen_CA [ shape = diamond ]; + Ellen_EE [ label = "Ellen\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; + + // Peers + node [ color = red, fontcolor = red, shape = diamond ]; + Bob_CA; + Carol_CA; + Dave_CA; + Frank_CA; + Ginny_CA; + Harry_CA; + + edge [ color = black, style = solid ]; + TA -> Alice_CA; + TA -> Ellen_CA; + + edge [ color = black, style = dashed ]; + TA -> rpkid; + TA -> irdbd; + TA -> irbe; + + edge [ color = blue, style = solid ]; + Alice_CA -> Bob_CA; + Alice_CA -> Carol_CA; + Alice_CA -> Dave_CA; + Ellen_CA -> Frank_CA; + Ellen_CA -> Ginny_CA; + Ellen_CA -> Harry_CA; + + edge [ color = blue, style = dashed ] + Alice_CA -> Alice_EE; + Ellen_CA -> Ellen_EE; +} diff --git a/docs/bpki-symmetric.pdf b/docs/bpki-symmetric.pdf Binary files differnew file mode 100644 index 00000000..22b1bbe3 --- /dev/null +++ b/docs/bpki-symmetric.pdf diff --git a/docs/bpki.pdf b/docs/bpki.pdf Binary files differindex c85acb29..c5d272d3 100644 --- a/docs/bpki.pdf +++ b/docs/bpki.pdf diff --git a/docs/bpki.tex b/docs/bpki.tex new file mode 100644 index 00000000..e941948a --- /dev/null +++ b/docs/bpki.tex @@ -0,0 +1,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 relationships between EE keys and certificates used +when my engine signs something. ``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 +assymetric case. + +\end{document} |