-*- Text -*- $Id$ plan for new myrpki setup tools. need better name for them, among other things. - dig out old proposed better names for myrpki and myirbe, use those. bpki.myrpki => bpki.resources (or perhaps bpki/resources) bpki.myirbe => bpki.servers bpki.resources is used for tls client and all cms in up-down and object publication. bpki.servers is used for all tls server certs, and is also used for tls client and all cms in left-right and publication control. had proposed new names for .py scripts, dig those out but will also be creating a bunch of new scripts here to confuse the issue. - for the moment i'm completely ignoring security of the new setup protcol. this clearly will not fly even in the short run, but let's start by figuring out who needs to do what to whom before worrying about how to prove that everybody is who they claim to be. - need a script to create new self (resource holding identity). this creates bpki.resources, takes that and [myrpki]handle variable, packages that as an xml blob. - send self xml blob to parent, current theory seems to be upload to a web form. parent responds with a lot of the stuff currently in parents.csv, and perhaps also with a hint about where to publish, all packaged as an xml blob. well, maybe (also?) a link to publication service that i can click on? current fields in parents.csv: # Syntax: is a private matter, that probably turns into name of the parent xml blob when i store it on disk, nobody else's business what i call it and are supplied by parent, based on whatever name parent uses for itself and what name it uses for me. i've told it what i call myself, but parent probably has its own name for me. and parent just supplies, nothing complex there (well, except for boostrap process for rootd, but that's a separate mess). still makes my head hurt. not just me. - also send self xml blob to hosting, who may or may not be another aspect of myself. hosting entity supplies (new? update of mine?) xml blob containing bpki.servers and rpkid service url ([myirbe]rpkid_base url value). will need to supply all of this to any children. [myirbe]pubd_base makes my head hurt. why is in parents.csv while pubd_base is in [myirbe] ? gah.... along with everything else, this seems like really weird db normalization. kind of seems like goes with [myirbe]pubd_base and both really need to be supplied by resource holder via negotiation with a publication service. - a lot of the data for rpkid and pubd operator can be pulled from config file, no need for separate configuration. perhaps in this brave new world we lock people using this ui into one big config file for everything so we can avoid making them type everything three times? still some icky stuff with [rpkid], [irdbd], etc sections linking to each other, not immediately obvious how to fix that without losing generality in core daemons, but maybe inspect these sections again and there will be some simple approach. - when answering setup request from child, we need to save xml blob they sent us as replacement for a line that's now in children.csv. well, but we also need expiration date, how fun. # Syntax: becomes name of xml blob file: children/foo.xml or whatever. it's a private matter except that we have to tell the child what we picked so they can use it in up-down protocol. this same name goes into service url we cons up for this child. we need to deduce, invent, or look up, somehow. in real production we would have this on file as it's tied to contract expiration. in testing we've just been saying "one year from today". is the child's bpki.resources cert, which they just handed us, yay. - when answering setup request from publication client, we need to save xml blob, same as parent saving child. # Syntax: is what we call this client, name of xml blob file we save, we get to chose it but we have to tell client what we chose so they can use it. this same name goes into service url we cons up for this client. is the client's bpki.resources cert, which they just handed us, yay. is making my head hurt yet again. this time it is what we will allow this client to use, so it'd better not conflict with any other publication client. oh, wait, i said this was zero security at the moment, ok. - i should write converters from the current parents.csv, children.csv, and pubclients.csv into the new format, both to simplify migration and also as a clue as to what i've forgotten. - the above story is weak on publication setup. among other things, the linkage between parent and repository that publishes things that come from classes derived from that parent is weak, perhaps because that linkage doesn't make any particular sense outside of rpkid's object model. the real restriction in rpkid is that all the resource classes derived from a single parent object share a repository object. - oh yeah, and, unrelated to any of the above, i should check the syntax restrictions on up-down resource class names, and perhaps replace the numeric (last vestige of sql-derived identifiers) resource class names we're using with resource class names extruded from irdb. which might involve hacking left-right protocol, and might create a uniqueness problem when publishing children under self, but would be nice to get rid of the sql-derived ids. To: RPKI Testbed Subject: plan for new rpki setup tools From: Rob Austein X-Original-To: sra@cyteen.hactrn.net Delivered-To: sra@cyteen.hactrn.net Date: Sat, 30 Jan 2010 02:00:02 -0500 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Message-Id: <20100130070003.7706715F382@angband.hactrn.net> per findings of the tokyo rpki workshop, here's an outline of the current plan for revised setup tools for the rpki code. step 1: user run a new "initialize" script. this reads the .conf file and creates the resource-holding "self" bpki identity (what we've been calling bpki.myrpki/ca.cer, although that name should change and the user shouldn't need to know it anymore). if the .conf file says that this user will be running any servers at all (rpkid, irdbd, pubd, rootd), this script also creates what we've been calling bpki.myirbe/ca.cer and issues bpki ee certificates for all the servers we will be running. it bundles up the "self" identity (bpki.myrpki/ca.cer and the "handle" value from the [myrpki] section of the .conf file) as an xml blob, which it writes out to some filename (call it me.xml for now). the general idea here is to start with all the setup that we can do based just on the .conf file without talking to anybody else. step 2: user sends me.xml to parent, who saves it in a file children/foo.xml (where foo is the parent's name for this child). parent also feeds this file and and parent's own me.xml into another new script (call it "setup_child" for now, since the parent uses it to set up its child). this script writes out a customized parent record (another xml blob) tailored to this particular child (service url including parent's and child's names, parent's rpkid server bpki cert, etc -- most of the data that goes into a line in parents.csv now). this xml blob can (and usually does) also include either an offer of publication service (if the parent runs pubd and is willing to act as repository for this child) or a hint pointing to some other repository (probably the one the parent itself uses). the distinction between offer and hint here is that the parent can only offer a pubd server it runs; for anything else it can only hint. parent sends this xml result blob back to child, who stores at in a parents/ directory with a name corresponding to the current parent_handle (ie, the filename is the child's name for the parent, eg, arin.xml). step 3: user sends me.xml to a publication service (probably the one offered or hinted by the parent); publication service feeds that and its own me.xml into yet another new script (call it "setup_client") for now. this script does essentially the same for things for the publication service as the setup_child script does for the parent: it generates a customized xml blob to be returned to the client, telling the client what service url, pubd bpki cert, etc to use when talking to this repository. step 4: user sends all of the stuff collected so far to whatever entity is going to host it (run rpkid for it), who then runs a "setup_hosting" script; in the common case where this user hosts itself, this just means that the user runs setup_hosting for itself. in either case, this fills in the last missing bits (service url and bpki cert for children of this user to use when talking to its rpkid, etc). result of this is an updated me.xml file. step 2 repeats for multiple parents. in theory, step 3 could repeat for multiple publication services, in practice that's less likely after performing the above steps, the user should have all the data necessary to start running the current my{rpki,irbe} scripts. we'll probably want to integrate all off this a bit better with the current code (which will need some rewriting in any case). rootd is a special case, in this as in all else. when we're running rootd, the initalize script should probably just create everything needed for rootd and for rpkid to know about rootd as its parent. rootd is always operated by the same entity as the rpkid that uses this rootd as its parent, so this is a bit tedious but should be straightforward. similarly, i think it's ok for us to insist that the operator running rootd must also run its own pubd. the sequence of events in the numbered steps above matters: we have nothing to talk about until we create our own identity, and we don't know which publication service to talk to until we have talked to our parent. it may not be necessary to postpone hosting setup until last, but it's probably harmless and may make it easier to merge all or part of this last step into the my{rpki,irbe} dialog. i don't really know yet whether all of the new scripts above are really new scripts or are calls to a smaller number of scripts with more arguments. don't feel strongly about it, most important criterion is to minimize user confusion. comments welcome. i may not get to them for a few weeks, as it's ski season :) To: RPKI Testbed Subject: Re: renaming some of the obscure bits of myrpki From: Rob Austein X-Original-To: sra@cyteen.hactrn.net Delivered-To: sra@cyteen.hactrn.net Date: Sun, 04 Oct 2009 16:34:57 -0400 In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Message-Id: <20091004203457.740F822807@thrintun.hactrn.net> briefly going back to the original topic of this thread (before randy hijacked it to beat me up about missing documentation :) At Sun, 04 Oct 2009 05:49:38 +0900, Randy Bush wrote: > > > bpki.myrpki/ => bpki.resources/ > > bpki.myirbe/ => bpki.daemons/ > > make sense > > > myrpki.py => update_resources.py > > update which resources? mine by fetching from parent? > > > myirbe.py => update_daemons.py > > get new code from svn repository? how about: myrpki.py => configure_resources.py myirbe.py => configure_daemons.py ? per yesterday's conversation, there are a couple of missing scripts, perhaps with names like: do_initial_setup.py run_servers.py thrintun.hactrn.net:/u/sra/rpki/subvert-rpki.hactrn.net/myrpki.rototill/PLAN, 26-Feb-2010 16:03:29, sra Current theory on out-of-band XML-based setup protocol. Step 1: initialize.py generates lots of stuff (see previous pages), writes initial self.xml containing handle and bpki/myrpki/ca.cer Step 2: setup_child.py ... and sends back xml containing: parent's bpki/myrpki/ca.cer parent's (or parent's host's) bpki/myirbe/ca.cer service url, up-down sender/recipient names and either: A publication offer, which contains just the service url (because server ca is same as rpkid's? i think so. not allowed to offer when we're not running pubd. well, ok, i suppose we could be running pubd without running rpkid, kind of perverse but if it should be legal we need to pass back the bpki/myirbe/ca.cer in this case); or A publication hint, which would include the bpki/myirbe/ca.cer of the publication server and a signed (cms blob wrapping something) authorization for publication server to grant part of parent's publication space to child (which would also need to identify the child, so would need to include child bpki/myrpki/ca.cer). This does kind of sound like we should just always include publication server's bpki/myirbe/ca.cer and not worry about optimizing that. From parent's point of view, an offer could just be a referral that the parent knows it's willing to accept, but maybe the distinction matters to the child. Semantics should probably follow biz practice rather than implemntation arcana, and in biz practice there certainly is a difference between and offer and a hint to use a third party, so keep distinction. Step 3: setup_client.py (icky name) reads, um, self.xml and parent's response (from step 2) and spits out, um, just contact URL I think, as client appears to have bpki/myirbe/ca.cer already. Step 4: Have not yet completely worked out whether publication data from step 3 becomes part of self.xml object. Perhaps.