diff options
28 files changed, 0 insertions, 843 deletions
diff --git a/presentations/070523.lacnic-pki.pdf b/presentations/070523.lacnic-pki.pdf Binary files differdeleted file mode 100644 index 5ab83fa3..00000000 --- a/presentations/070523.lacnic-pki.pdf +++ /dev/null diff --git a/presentations/100503-ripe-rpki+origin.pdf b/presentations/100503-ripe-rpki+origin.pdf Binary files differdeleted file mode 100644 index 07b9e284..00000000 --- a/presentations/100503-ripe-rpki+origin.pdf +++ /dev/null diff --git a/presentations/Makefile b/presentations/Makefile deleted file mode 100644 index a568b5e4..00000000 --- a/presentations/Makefile +++ /dev/null @@ -1,15 +0,0 @@ -# $Id$ - -all: repository-engine-objects.pdf bpki.pdf - -bpki.pdf: bpki-symmetric.pdf bpki-asymmetric.pdf - -.SUFFIXES: .pdf .dot .tex - -.dot.pdf: - dot -Tps2 $< | ps2pdf - $@ - -.tex.pdf: - pdflatex $< - pdflatex $< - rm -f $*.log $*.aux diff --git a/presentations/README b/presentations/README deleted file mode 100644 index 6ff000fc..00000000 --- a/presentations/README +++ /dev/null @@ -1,21 +0,0 @@ -$Id$ - -Ok, there's getting to be enough stuff in this directory to be -confusing. - -README This file - -070523.lacnic-pki.pdf A presentation from LACNIC, May 2007 - -bpki.pdf Old discussion of a design choice - between two slightly different - business PKI (BPKI) architectures - -entity-decompose.pdf An overview presentation - -images Some old pictures - -repository-engine-objects.dot Objects in the RPKI engine (PDF) -repository-engine-objects.pdf Graphviz source for " - -repository-structure.txt Old notes on repository structure diff --git a/presentations/apnic30-rpki.pdf b/presentations/apnic30-rpki.pdf Binary files differdeleted file mode 100644 index 929fee26..00000000 --- a/presentations/apnic30-rpki.pdf +++ /dev/null diff --git a/presentations/apnic30-rpki.zip b/presentations/apnic30-rpki.zip Binary files differdeleted file mode 100644 index 60e562e0..00000000 --- a/presentations/apnic30-rpki.zip +++ /dev/null diff --git a/presentations/big-picture.dot b/presentations/big-picture.dot deleted file mode 100644 index 9da4cc2e..00000000 --- a/presentations/big-picture.dot +++ /dev/null @@ -1,61 +0,0 @@ -// $Id$ -// -// First cut at a lame picture showing how all the tools fit together. -// -// Client -> server -// Blue = read-only -// Red = read-write -// Diamond = program -// Oval = disk - -digraph big_picture { - rotate=90; size="11,8.5"; splines=true; ratio=fill; - - node [shape = diamond]; - - rpkid -> irdbd [color = blue]; - rpkid -> pubd [color = red]; - myrpki -> rpkid [color = red]; - myrpki -> pubd [color = red]; - gui -> myrpki [color = red]; -// myrpki -> mysqld [color = red]; -// rpkid -> mysqld [color = red]; -// irdbd -> mysqld [color = blue]; -// pubd -> mysqld [color = red]; - rpkid -> rootd [color = red]; - pubd -> repository [color = red, arrowhead = none]; - rsyncd -> repository [color = blue, arrowhead = none]; - rcynic -> rsyncd [color = blue]; - cache -> rcynic [color = blue, arrowhead = none]; - rpki_rtr -> cache [color = blue]; - roa_to_irr -> cache [color = blue]; - - repository [shape = oval]; - cache [shape = oval]; - - subgraph cluster_irbe { - label = "IR Back End"; - irdbd; - myrpki; - gui; - } - - subgraph cluster_generation { - label = "Generation"; - rpkid; - rootd; - } - - subgraph cluster_publication { - label = "Publication"; - pubd; - repository; - rsyncd; - } - - subgraph cluster_validator { - label = "Validator"; - rcynic; - cache; - } -} diff --git a/presentations/big-picture.pdf b/presentations/big-picture.pdf Binary files differdeleted file mode 100644 index 9704dd63..00000000 --- a/presentations/big-picture.pdf +++ /dev/null diff --git a/presentations/bpki-asymmetric.dot b/presentations/bpki-asymmetric.dot deleted file mode 100644 index 739cd6ee..00000000 --- a/presentations/bpki-asymmetric.dot +++ /dev/null @@ -1,84 +0,0 @@ -// $Id$ -// -// Color code: -// Black: Hosting entity -// Blue: Hosted entity -// Red: Cross-certified peer -// -// Shape code: -// Octagon: TA -// Diamond: CA -// Record: EE - -digraph bpki_asymmetric { - 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 ]; - Ellen_CA [ shape = diamond ]; - - // Peers - node [ color = red, fontcolor = red, shape = diamond ]; - Bob_CA; - Carol_CA; - Dave_CA; - Frank_CA; - Ginny_CA; - Harry_CA; - - // EE certs issued to us by peers - node [ color = red, fontcolor = red, shape = record ]; - Alice_Bob_EE [ label = "Alice-Bob\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; - Alice_Carol_EE [ label = "Alice-Carol\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; - Alice_Dave_EE [ label = "Alice-Dave\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; - Ellen_Frank_EE [ label = "Ellen-Frank\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; - Ellen_Ginny_EE [ label = "Ellen-Ginny\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; - Ellen_Harry_EE [ label = "Ellen-Harry\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; - Bob_EE [ label = "Bob\nEE|{HTTPS up-down|CMS up-down}" ]; - Carol_EE [ label = "Carol\nEE|{HTTPS up-down|CMS up-down}" ]; - Dave_EE [ label = "Dave\nEE|{HTTPS up-down|CMS up-down}" ]; - Frank_EE [ label = "Frank\nEE|{HTTPS up-down|CMS up-down}" ]; - Ginny_EE [ label = "Ginny\nEE|{HTTPS up-down|CMS up-down}" ]; - Harry_EE [ label = "Bob\nEE|{HTTPS up-down|CMS up-down}" ]; - - edge [ color = black, style = solid ]; - TA -> Alice_CA; - TA -> Ellen_CA; - - edge [ color = black, style = dotted ]; - 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 = red, style = dotted ]; - Bob_CA -> Alice_Bob_EE; - Carol_CA -> Alice_Carol_EE; - Dave_CA -> Alice_Dave_EE; - Frank_CA -> Ellen_Frank_EE; - Ginny_CA -> Ellen_Ginny_EE; - Harry_CA -> Ellen_Harry_EE; - - edge [ color = red, style = solid ]; - Bob_CA -> Bob_EE; - Carol_CA -> Carol_EE; - Dave_CA -> Dave_EE; - Frank_CA -> Frank_EE; - Ginny_CA -> Ginny_EE; - Harry_CA -> Harry_EE; -} diff --git a/presentations/bpki-asymmetric.pdf b/presentations/bpki-asymmetric.pdf Binary files differdeleted file mode 100644 index fbd0362d..00000000 --- a/presentations/bpki-asymmetric.pdf +++ /dev/null diff --git a/presentations/bpki-symmetric.dot b/presentations/bpki-symmetric.dot deleted file mode 100644 index 48e89483..00000000 --- a/presentations/bpki-symmetric.dot +++ /dev/null @@ -1,74 +0,0 @@ -// $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; - node [ shape = record ]; - Bob_EE [ label = "Bob\nEE|{HTTPS up-down|CMS up-down}" ]; - Carol_EE [ label = "Carol\nEE|{HTTPS up-down|CMS up-down}" ]; - Dave_EE [ label = "Dave\nEE|{HTTPS up-down|CMS up-down}" ]; - Frank_EE [ label = "Frank\nEE|{HTTPS up-down|CMS up-down}" ]; - Ginny_EE [ label = "Ginny\nEE|{HTTPS up-down|CMS up-down}" ]; - Harry_EE [ label = "Bob\nEE|{HTTPS up-down|CMS up-down}" ]; - - edge [ color = black, style = solid ]; - TA -> Alice_CA; - TA -> Ellen_CA; - - edge [ color = black, style = dotted ]; - 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 = dotted ]; - Alice_CA -> Alice_EE; - Ellen_CA -> Ellen_EE; - - edge [ color = red, style = solid ]; - Bob_CA -> Bob_EE; - Carol_CA -> Carol_EE; - Dave_CA -> Dave_EE; - Frank_CA -> Frank_EE; - Ginny_CA -> Ginny_EE; - Harry_CA -> Harry_EE; -} diff --git a/presentations/bpki-symmetric.pdf b/presentations/bpki-symmetric.pdf Binary files differdeleted file mode 100644 index 9db46451..00000000 --- a/presentations/bpki-symmetric.pdf +++ /dev/null diff --git a/presentations/bpki.pdf b/presentations/bpki.pdf Binary files differdeleted file mode 100644 index 979c1380..00000000 --- a/presentations/bpki.pdf +++ /dev/null diff --git a/presentations/bpki.tex b/presentations/bpki.tex deleted file mode 100644 index c07c6534..00000000 --- a/presentations/bpki.tex +++ /dev/null @@ -1,80 +0,0 @@ -% $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. - -\begin{figure}[hbp] -\includegraphics[width = 6.5in]{bpki-symmetric} -\caption{Symmetric BPKI model} -\label{bpki-symmetric} -\end{figure} - -Figure \ref{bpki-symmetric} shows my engine's view of the BPKI tree in -the symmetric model. 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, dotted 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. - -\begin{figure}[hbp] -\includegraphics[width = 6.5in]{bpki-asymmetric} -\caption{Asymmetric BPKI model} -\label{bpki-asymmetric} -\end{figure} - -Figure \ref{bpki-asymmetric} shows my engine's view of the BPKI tree -in the asymmetric model. 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} diff --git a/presentations/entity-decompose.pdf b/presentations/entity-decompose.pdf Binary files differdeleted file mode 100644 index afde3c27..00000000 --- a/presentations/entity-decompose.pdf +++ /dev/null diff --git a/presentations/images/key-rollover.dot b/presentations/images/key-rollover.dot deleted file mode 100644 index 9b74ad30..00000000 --- a/presentations/images/key-rollover.dot +++ /dev/null @@ -1,124 +0,0 @@ -// $Id$ -// -// A pictoral attempt to explain how key rollover works. - -digraph step0 { - rotate=90; size="11,8.5"; splines=true; ratio=fill; - alice [ shape = record, label = "{Issuer key whatever|Subject key Alice}" ]; - bob1 [ shape = record, label = "{Issuer key Alice|Subject key Bob1}" ]; - carol1 [ shape = record, label = "{Issuer key Bob1|Subject key Carol}" ]; - claire1 [ shape = record, label = "{Issuer key Bob1|Subject key Claire}" ]; - charlie1 [ shape = record, label = "{Issuer key Bob1|Subject key Charlie}" ]; - dave [ shape = record, label = "{Issuer key Carol|Subject key Dave}" ]; - danny [ shape = record, label = "{Issuer key Carol|Subject key Danny}" ]; - dale [ shape = record, label = "{Issuer key Claire|Subject key Dale}" ]; - donald [ shape = record, label = "{Issuer key Claire|Subject key Donald}" ]; - doug [ shape = record, label = "{Issuer key Charlie|Subject key Doug}" ]; - drew [ shape = record, label = "{Issuer key Charlie|Subject key Drew}" ]; - alice -> bob1; - bob1 -> carol1; - bob1 -> claire1; - bob1 -> charlie1; - carol1 -> dave; - carol1 -> danny; - claire1 -> dale; - claire1 -> donald; - charlie1 -> doug; - charlie1 -> drew; -} - -digraph step1 { - rotate=90; size="11,8.5"; splines=true; ratio=fill; - alice [ shape = record, label = "{Issuer key whatever|Subject key Alice}" ]; - bob1 [ shape = record, label = "{Issuer key Alice|Subject key Bob1}" ]; - bob2 [ shape = record, label = "{Issuer key Alice|Subject key Bob2}" ]; - carol1 [ shape = record, label = "{Issuer key Bob1|Subject key Carol}" ]; - claire1 [ shape = record, label = "{Issuer key Bob1|Subject key Claire}" ]; - charlie1 [ shape = record, label = "{Issuer key Bob1|Subject key Charlie}" ]; - dave [ shape = record, label = "{Issuer key Carol|Subject key Dave}" ]; - danny [ shape = record, label = "{Issuer key Carol|Subject key Danny}" ]; - dale [ shape = record, label = "{Issuer key Claire|Subject key Dale}" ]; - donald [ shape = record, label = "{Issuer key Claire|Subject key Donald}" ]; - doug [ shape = record, label = "{Issuer key Charlie|Subject key Doug}" ]; - drew [ shape = record, label = "{Issuer key Charlie|Subject key Drew}" ]; - alice -> bob1; - alice -> bob2; - bob1 -> carol1; - bob1 -> claire1; - bob1 -> charlie1; - carol1 -> dave; - carol1 -> danny; - claire1 -> dale; - claire1 -> donald; - charlie1 -> doug; - charlie1 -> drew; -} - -digraph step2 { - rotate=90; size="11,8.5"; splines=true; ratio=fill; - alice [ shape = record, label = "{Issuer key whatever|Subject key Alice}" ]; - bob1 [ shape = record, label = "{Issuer key Alice|Subject key Bob1}" ]; - bob2 [ shape = record, label = "{Issuer key Alice|Subject key Bob2}" ]; - carol1 [ shape = record, label = "{Issuer key Bob1|Subject key Carol}" ]; - carol2 [ shape = record, label = "{Issuer key Bob2|Subject key Carol}" ]; - claire1 [ shape = record, label = "{Issuer key Bob1|Subject key Claire}" ]; - claire2 [ shape = record, label = "{Issuer key Bob2|Subject key Claire}" ]; - charlie1 [ shape = record, label = "{Issuer key Bob1|Subject key Charlie}" ]; - charlie2 [ shape = record, label = "{Issuer key Bob2|Subject key Charlie}" ]; - dave [ shape = record, label = "{Issuer key Carol|Subject key Dave}" ]; - danny [ shape = record, label = "{Issuer key Carol|Subject key Danny}" ]; - dale [ shape = record, label = "{Issuer key Claire|Subject key Dale}" ]; - donald [ shape = record, label = "{Issuer key Claire|Subject key Donald}" ]; - doug [ shape = record, label = "{Issuer key Charlie|Subject key Doug}" ]; - drew [ shape = record, label = "{Issuer key Charlie|Subject key Drew}" ]; - alice -> bob1; - alice -> bob2; - bob1 -> carol1; - bob1 -> claire1; - bob1 -> charlie1; - bob2 -> carol2; - bob2 -> claire2; - bob2 -> charlie2; - carol1 -> dave; - carol1 -> danny; - claire1 -> dale; - claire1 -> donald; - charlie1 -> doug; - charlie1 -> drew; - carol2 -> dave; - carol2 -> danny; - claire2 -> dale; - claire2 -> donald; - charlie2 -> doug; - charlie2 -> drew; -} - -digraph step3 { - rotate=90; size="11,8.5"; splines=true; ratio=fill; - alice [ shape = record, label = "{Issuer key whatever|Subject key Alice}" ]; - bob2 [ shape = record, label = "{Issuer key Alice|Subject key Bob2}" ]; - carol2 [ shape = record, label = "{Issuer key Bob2|Subject key Carol}" ]; - claire2 [ shape = record, label = "{Issuer key Bob2|Subject key Claire}" ]; - charlie2 [ shape = record, label = "{Issuer key Bob2|Subject key Charlie}" ]; - dave [ shape = record, label = "{Issuer key Carol|Subject key Dave}" ]; - danny [ shape = record, label = "{Issuer key Carol|Subject key Danny}" ]; - dale [ shape = record, label = "{Issuer key Claire|Subject key Dale}" ]; - donald [ shape = record, label = "{Issuer key Claire|Subject key Donald}" ]; - doug [ shape = record, label = "{Issuer key Charlie|Subject key Doug}" ]; - drew [ shape = record, label = "{Issuer key Charlie|Subject key Drew}" ]; - alice -> bob2; - bob2 -> carol2; - bob2 -> claire2; - bob2 -> charlie2; - carol2 -> dave; - carol2 -> danny; - claire2 -> dale; - claire2 -> donald; - charlie2 -> doug; - charlie2 -> drew; -} - - -// Local Variables: -// compile-command: "dot -Tps2 key-rollover.dot | ps2pdf - key-rollover.pdf" -// End: diff --git a/presentations/images/key-rollover.pdf b/presentations/images/key-rollover.pdf Binary files differdeleted file mode 100644 index 1fb0d633..00000000 --- a/presentations/images/key-rollover.pdf +++ /dev/null diff --git a/presentations/images/prague-whiteboard-2007-03-21-02-29-14.jpg b/presentations/images/prague-whiteboard-2007-03-21-02-29-14.jpg Binary files differdeleted file mode 100644 index 79c0a807..00000000 --- a/presentations/images/prague-whiteboard-2007-03-21-02-29-14.jpg +++ /dev/null diff --git a/presentations/images/prague-whiteboard-2007-03-22-21-50-26.jpg b/presentations/images/prague-whiteboard-2007-03-22-21-50-26.jpg Binary files differdeleted file mode 100644 index 4c3c828d..00000000 --- a/presentations/images/prague-whiteboard-2007-03-22-21-50-26.jpg +++ /dev/null diff --git a/presentations/images/prague-whiteboard-2007-03-22-23-15-01.jpg b/presentations/images/prague-whiteboard-2007-03-22-23-15-01.jpg Binary files differdeleted file mode 100644 index 7b973ab0..00000000 --- a/presentations/images/prague-whiteboard-2007-03-22-23-15-01.jpg +++ /dev/null diff --git a/presentations/images/repository-structure.dot b/presentations/images/repository-structure.dot deleted file mode 100644 index 7154202d..00000000 --- a/presentations/images/repository-structure.dot +++ /dev/null @@ -1,42 +0,0 @@ -// $URL$ -// $Id$ -// -// Pictures to go with repository-structure.txt. First picture is rekeying b with -// a g(ski)/g(ski)/g(ski).cer model, second is with stable meaningless identifiers. - -graph rekeying_ski { - rotate=90; size="11,8.5"; splines=true; ratio=fill; - node [ shape=box ]; - a [ color=black, label="rsync://host/foo/g(ski(a)).cer" ] - b [ color=red, label="rsync://host/foo/g(ski(a))/g(ski(b)).cer" ] - c [ color=red, label="rsync://host/foo/g(ski(a))/g(ski(b))/g(ski(c)).cer" ] - d [ color=red, label="rsync://host/foo/g(ski(a))/g(ski(b))/g(ski(c))/g(ski(d)).cer" ] - a -- b [ color=red ]; - b -- c [ color=red ]; - c -- d [ color=red ]; - b_ [ color=green, label="rsync://host/foo/g(ski(a))/g(ski(b')).cer" ] - c_ [ color=green, label="rsync://host/foo/g(ski(a))/g(ski(b'))/g(ski(c)).cer" ] - d_ [ color=green, label="rsync://host/foo/g(ski(a))/g(ski(b'))/g(ski(c))/g(ski(d)).cer" ] - a -- b_ [ color=green ]; - b_ -- c_ [ color=green ]; - c_ -- d_ [ color=green ]; -} - -graph rekeying_gensym { - rotate=90; size="11,8.5"; splines=true; ratio=fill; - node [ shape=box ]; - a [ color=black, label="rsync://host/foo/g(ski(a)).cer" ] - b [ color=red, label="rsync://host/foo/G001/g(ski(b)).cer" ] - c [ color=black, label="rsync://host/foo/G001/G002/g(ski(c)).cer" ] - d [ color=black, label="rsync://host/foo/G001/G002/G003/g(ski(d)).cer" ] - a -- b [ color=red ]; - b -- c [ color=red ]; - c -- d [ color=black ]; - b_ [ color=green, label="rsync://host/foo/G001/g(ski(b')).cer" ] - a -- b_ [ color=green ]; - b_ -- c [ color=green ]; -} - -// Local Variables: -// compile-command: "dot -Tps2 repository-structure.dot | ps2pdf - repository-structure.pdf" -// End: diff --git a/presentations/images/repository-structure.pdf b/presentations/images/repository-structure.pdf Binary files differdeleted file mode 100644 index 0fcc7615..00000000 --- a/presentations/images/repository-structure.pdf +++ /dev/null diff --git a/presentations/images/whiteboard-object-model.dot b/presentations/images/whiteboard-object-model.dot deleted file mode 100644 index 3c61f3ab..00000000 --- a/presentations/images/whiteboard-object-model.dot +++ /dev/null @@ -1,65 +0,0 @@ -// $URL$ -// $Id$ - -// This is an attempt to capture -// http://subvert-rpki.hactrn.net/docs/prague-whiteboard-2007-03-22-23:15:01.jpg - -// {arrowhead,arrowtail} shapes to use for database object relationships: -// 1- none -// m- crow -// Color code: -// Blue: visible in left-right protocol -// Green: created on the fly - -// Explanation for many-many mapping beween CA and child objects -// (courtesy of RobL): Each child is an entity; each CA can have -// multiple children, and each child can hold certs from multiple CAs. - -digraph rpki_engine_objects { - rotate=90; size="11,8.5"; splines=true; ratio=fill; - node [ shape=record ]; - - // Objects visible in left-to-right protocol - node [ color=blue ]; - self [ label="Self|{Preferences}" ]; - parent [ label="Parent|{URI|TA}" ]; - repo [ label="Repository|{URI|TA}" ]; - child [ label="Child|{TA}" ]; - biz_sign [ label="Business\nSigning Context|{Keypair|CertChain}" ]; - - // Objects created on the fly by the RPKI engine - node [ color=green ]; - ca [ label="CA|{CRL #|Last Issued Serial #}" ]; - child_cert [ label="Child Certificate" ]; - ee_cert [ label="EE Certificate|{ROA}" ]; - ca_key_pair [ label="CA Key Pair|{Latest CA Certificate|Latest CRL}" ]; - - // One-many mappings - edge [ color=blue, arrowtail=none, arrowhead=crow ]; - biz_sign -> child; - biz_sign -> parent; - biz_sign -> repo; - self -> child; - self -> parent; - repo -> parent; - - // Many-many mappings - edge [ color=green, arrowtail=crow, arrowhead=crow ]; - ca -> child; - - // One-many mappings - edge [ color=green, arrowtail=none, arrowhead=crow ]; - ca -> ca_key_pair; - child -> child_cert; - self -> ca; - parent -> ca; - - // Weird one-many - edge [ color=green, arrowtail=none, arrowhead=crow, style=dashed ]; - ca_key_pair -> child_cert; - ca_key_pair -> ee_cert; -} - -// Local Variables: -// compile-command: "neato -Tps2 whiteboard-object-model.dot | ps2pdf - whiteboard-object-model.pdf" -// End: diff --git a/presentations/images/whiteboard-object-model.pdf b/presentations/images/whiteboard-object-model.pdf Binary files differdeleted file mode 100644 index 9b7da850..00000000 --- a/presentations/images/whiteboard-object-model.pdf +++ /dev/null diff --git a/presentations/repository-engine-objects.dot b/presentations/repository-engine-objects.dot deleted file mode 100644 index 24abc8dd..00000000 --- a/presentations/repository-engine-objects.dot +++ /dev/null @@ -1,86 +0,0 @@ -// $URL$ -// $Id$ -// -// {arrowhead,arrowtail} shapes indicate database object relationships: -// 1- none -// m- crow -// -// Color code: -// Blue: visible in left-right protocol -// Green: created on the fly - -digraph rpki_engine_objects { - rotate=90; size="11,8.5"; splines=true; ratio=fill; - node [ shape=record ]; - - // Objects visible in left-to-right protocol - node [ color=blue ]; - self [ label="Self|{Preferences}" ]; - parent [ label="Parent|{URI|TA|SIA Base}" ]; - repo [ label="Repository|{URI|TA}" ]; - child [ label="Child|{TA}" ]; - biz_sign [ label="Business\nSigning Context|{Keypair|CertChain}" ]; - route_origin [ label="Route\nOrigin|{AS Number}" ]; - - // Objects which left-right protocol sees as part of other - // objects but which SQL needs to be separate for - // normalization. - - addr_set [ label="Address\nPrefix", color=purple ]; - - // Objects created on the fly by the RPKI engine - node [ color=green ]; - ca [ label="CA|{Last CRL #|Next CRL Date|Last Issued Serial #|Last Manifest #|Next Manifest Date|SIA URI}" ]; - ca_detail [ label="CA Detail|{CA Private Key Handle|CA Public Key|Latest CA Certificate|Manifest EE Private Key Handle|Manifest EE Public Key|Latest Manifest EE Certificate|Latest Manifest|Latest CRL}" ]; - - // Some question whether these objects need to be in database - // per se or are just properties hanging on some other object - // like ca or ca_detail. For manifests, we need last serial, - // same as for CRL. - roa [ label="ROA|{EE Certificate|ROA}" ]; - - // This one is a table of everything we have ever issued to - // this child, not to be confused with what's -currently- - // issued to this child. Some question whether this hangs off - // ca or ca_detail, but we -think- hanging off of ca_detail is - // correct because certificates are issued by a particular - // keypair. - - child_cert [ label="Child CA Certificate" ]; - - // One-many mappings - edge [ color=blue, arrowtail=none, arrowhead=crow ]; - self -> biz_sign; - biz_sign -> child; - biz_sign -> parent; - biz_sign -> repo; - self -> child; - self -> parent; - repo -> parent; - self -> route_origin; - - route_origin -> addr_set [ color=purple, arrowtail=none, arrowhead=crow ]; - - // This is many-many because each child is an entity, each CA - // can have multiple children, and each child can hold certs - // from multiple CAs (thanks, RobL). - // - ca -> child [ color=green, arrowtail=crow, arrowhead=crow ]; - - // One-many mappings - edge [ color=green, arrowtail=none, arrowhead=crow ]; - ca -> ca_detail; - child -> child_cert; - parent -> ca; - ca_detail -> child_cert; - ca_detail -> roa; - - // One-one mapping -- separate object to highlight dynamic nature - edge [ color=green, arrowtail=none, arrowhead=none, style=solid ]; - route_origin -> roa; - -} - -// Local Variables: -// compile-command: "dot -Tps2 repository-engine-objects.dot | ps2pdf - repository-engine-objects.pdf" -// End: diff --git a/presentations/repository-engine-objects.pdf b/presentations/repository-engine-objects.pdf Binary files differdeleted file mode 100644 index 68c6d2d6..00000000 --- a/presentations/repository-engine-objects.pdf +++ /dev/null diff --git a/presentations/repository-structure.txt b/presentations/repository-structure.txt deleted file mode 100644 index 327663b7..00000000 --- a/presentations/repository-structure.txt +++ /dev/null @@ -1,111 +0,0 @@ -$Id$ - -Copyright (C) 2007--2008 American Registry for Internet Numbers ("ARIN") - -Permission to use, copy, modify, and distribute this software for any -purpose with or without fee is hereby granted, provided that the above -copyright notice and this permission notice appear in all copies. - -THE SOFTWARE IS PROVIDED "AS IS" AND ARIN DISCLAIMS ALL WARRANTIES WITH -REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY -AND FITNESS. IN NO EVENT SHALL ARIN BE LIABLE FOR ANY SPECIAL, DIRECT, -INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM -LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE -OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR -PERFORMANCE OF THIS SOFTWARE. - - -This note is an attempt to write up the conclusions that several of us -came to at the RPKI meeting in Prague, March 2007. - -We currently have two examples of possible repository structure, -neither of which is quite what at least some of us think we want yet. - -APNIC's hierarchy of directories named by the g(SKI) function applied -to the public keys has some nice properties: in particular, the -hierarchical structure (subjects being stored underneath their issuers -when sharing a repository) has very nice scaling properties with -rsync. With this structure, a top-down walk such as rcynic uses will -pick up an entire tree as a side effect of fetching the top-most -issuer's SIA collection. Combined with a trivial memory cache to let -rcynic keep track of which URIs it has already fetched, this speeds up -rcynic's runtime by nearly two orders of magnitude in testing late -last year. The reason for this turns out to be simple: rsync is a -reasonably fast protocol, so one rsync connection to fetch an SIA -collection that hasn't changed takes approximately 500ms on not -terribly exciting hardware -- but in a system with more than 40,000 -objects, the cumulative total of all those half-second rsync -connections becomes significant. - -There is, however, one problem with the current APNIC structure: the -g(SKI) naming scheme means that the URIs associated with every -decendent of a particular node in the tree will change when that -node's key changes. This means that a key rollover event near the -root of the tree (eg, when APNIC's own key changes) will require a -painfully large number of certificates to be reissued. NB: only one -key is rolling in this scenario, the rest of the certificates are -being reissued with the same key, and the only reason why they need to -be reissued at all is that the path has changed. - -At the same time, the g(SKI) naming scheme has good properties for -naming certificates and CRLs, as it means that we can perform "make -before break" rollovers, leaving the old certificate path in place -until the new one is fully operational. - -So the goal here is to preserve the nice hierarchical structure of -APNIC's model, and preserve the nice properties of the g(SKI) naming -for certificates and CRLs, while avoiding the need to reissue every -desendent after a key rollover. We think that we can do this by using -static names for the directories and g(SKI)-based names for the files. - -This immediately begs the question of what the static names should be. -Some of us were tempted to make them organization names, but others of -us felt strongly that they should be completely meaningless, as they -only need to be unique within a particular parent directory and as we -really want to avoid all the "identity" issues that we have thus far -carefully avoided. We did not achieve consensus on this point, but I -(sra) am firmly in the meaningless name camp on this one. - -The upshot of all this is that I expect to be using URIs like: - - rsync://hostname/g0001/g0002/g0003/ - rsync://hostname/g0001/g0002/g0003/g(ski).cer - rsync://hostname/g0001/g0002/g0003/g(ski).crl - -where "gNNNN" indicates a generated symbol with no significance other -than that it is unique enough to avoid collisions. In this particular -case, the scope in which the symbol must be unique is just the -directory in which it appears. - -We haven't yet discussed how to name ROAs, but since we expect ROAs to -be tied to particular single-use EE certs, my guess is that a g(SKI) -name based on the key of the EE cert would be appropriate, so either -of the following forms would probably work: - - rsync://hostname/g0001/g0002/g0003/g0004/g(ski).roa - rsync://hostname/g0001/g0002/g0003/g(ski)/g(ski).roa - -The latter violates the rule of only using g(SKI) names for files, -never for directories, but in this case it'd probably be ok. - -This assumes that we're generating a new key for each ROA; if we're -reusing keys (dunno), we'd need a naming scheme like: - - rsync://hostname/g0001/g0002/g0003/g(ski)/g0004.roa - -For those unfamiliar with the notation (borrowed from Lisp): g0001 etc -are just "gensym" symbols, ie, the output of some function whose sole -purpose is to generate meaningless symbols. - -See images/repository-structure.pdf for an illustration of the problem -and solution. - -There may be compromise-driven rollover cases in which we will need to -reissue all of the children of a node whose key has been compromised. -Whether or not this is necessary depends on whether the master copy of -the authoritative data is safe somewhere else; if it is, and the -resource certificates are just a signed representation of an -authoritative database that has not been compromised, reissuing all of -the descendants may not be necessary, but if the resource certificates --are- the database, and one level in it has been compromised, it's -probably advisable to reissue all the descendants. diff --git a/presentations/sample-irdb-data.sql b/presentations/sample-irdb-data.sql deleted file mode 100644 index df24b48f..00000000 --- a/presentations/sample-irdb-data.sql +++ /dev/null @@ -1,80 +0,0 @@ --- $Id$ - --- Copyright (C) 2007-2008 American Registry for Internet Numbers ("ARIN") --- --- Permission to use, copy, modify, and distribute this software for any --- purpose with or without fee is hereby granted, provided that the above --- copyright notice and this permission notice appear in all copies. --- --- THE SOFTWARE IS PROVIDED "AS IS" AND ARIN DISCLAIMS ALL WARRANTIES WITH --- REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY --- AND FITNESS. IN NO EVENT SHALL ARIN BE LIABLE FOR ANY SPECIAL, DIRECT, --- INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM --- LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE --- OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR --- PERFORMANCE OF THIS SOFTWARE. - -INSERT INTO registrant (IRBE_mapped_id) VALUES ('ARIN'); -INSERT INTO registrant (IRBE_mapped_id) VALUES ('TIER1_ISP1'); -INSERT INTO registrant (IRBE_mapped_id) VALUES ('TIER1_ISP2'); -INSERT INTO registrant (IRBE_mapped_id) VALUES ('JOES_PIZZA'); - -INSERT INTO resource_class (subject_name, valid_until, registrant_id) -SELECT 'All ARIN resources', '2099-12-31', registrant_id -FROM registrant WHERE IRBE_mapped_id = 'ARIN'; - -INSERT INTO resource_class (subject_name, valid_until, registrant_id) -SELECT 'Tier 1 ISP foo subject name', '2008-12-31', registrant_id -FROM registrant WHERE IRBE_mapped_id = 'TIER1_ISP1'; - -INSERT INTO resource_class (subject_name, valid_until, registrant_id) -SELECT 'Tier 1 ISP foo subject name', '2009-06-30', registrant_id -FROM registrant WHERE IRBE_mapped_id = 'TIER1_ISP1'; - -INSERT INTO resource_class (subject_name, valid_until, registrant_id) -SELECT 'Tier 1 ISP bar subject name', '2007-07-31', registrant_id -FROM registrant WHERE IRBE_mapped_id = 'TIER1_ISP2'; - -INSERT INTO resource_class (subject_name, valid_until, registrant_id) -SELECT 'arbitrary characters', '2007-12-31', registrant_id -FROM registrant WHERE IRBE_mapped_id = 'JOES_PIZZA'; - -INSERT INTO net (start_ip, end_ip, version, resource_class_id) -SELECT 'DEAD:BEEF:0000:0000:0000:0000:0000:0000', 'DFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF', 6, resource_class_id -FROM resource_class WHERE subject_name = 'All ARIN resources'; - -INSERT INTO net (start_ip, end_ip, version, resource_class_id) -SELECT 'DEAD:BEEF:FACE:0000:0000:0000:0000:0000', 'DEAD:BEEF:FACE:FFFF:FFFF:FFFF:FFFF:FFFF', 6, resource_class_id -FROM resource_class WHERE subject_name = 'TIER 1 ISP foo subject name' AND valid_until = '2009-06-30'; - -INSERT INTO net (start_ip, end_ip, version, resource_class_id) -SELECT 'DEAD:BEEF:FACE:FADE:0000:0000:0000:0000', 'DEAD:BEEF:FACE:FADE:FFFF:FFFF:FFFF:FFFF', 6, resource_class_id -FROM resource_class WHERE subject_name = 'arbitrary characters' AND valid_until = '2007-12-31'; - -INSERT INTO net(start_ip, end_ip, version, resource_class_id) -SELECT '010.000.000.000', '010.255.255.255', 4, resource_class_id -FROM resource_class WHERE subject_name = 'All ARIN resources'; - -INSERT INTO net(start_ip, end_ip, version, resource_class_id) -SELECT '010.128.000.000', '010.191.255.255', 4, resource_class_id -FROM resource_class WHERE subject_name = 'Tier 1 ISP foo subject name' AND valid_until = '2009-06-30'; - -INSERT INTO net(start_ip, end_ip, version, resource_class_id) -SELECT '010.000.000.000', '010.063.255.255', 4, resource_class_id -FROM resource_class WHERE subject_name = 'Tier 1 ISP foo subject name' AND valid_until = '2009-06-30'; - -INSERT INTO net(start_ip, end_ip, version, resource_class_id) -SELECT '010.128.000.000', '010.191.255.255', 4, resource_class_id -FROM resource_class WHERE subject_name = 'arbitrary characters'; - -INSERT INTO asn(start_as, end_as, resource_class_id) -SELECT 12345, 12345, resource_class_id -FROM resource_class WHERE subject_name = 'Tier 1 ISP foo subject name' AND valid_until = '2009-06-30'; - -INSERT INTO asn(start_as, end_as, resource_class_id) -SELECT 23456, 23457, resource_class_id -FROM resource_class WHERE subject_name = 'Tier 1 ISP foo subject name' AND valid_until = '2009-06-30'; - -INSERT INTO asn(start_as, end_as, resource_class_id) -SELECT 34567, 34567, resource_class_id -FROM resource_class WHERE subject_name = 'Tier 1 ISP foo subject name' AND valid_until = '2008-12-31'; |
