path: root/myrpki.rototill/PLAN

-*- 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: <parent_handle> <service_uri> <cms_bpki_cert_filename> <https_bpki_cert_filename> <myhandle> <sia_base>

  <parent_handle> 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

  <service_uri> and <myhandle> 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.

  <cms_bpki_cert_filename> and <https_bpki_cert_filename> parent just
  supplies, nothing complex there (well, except for boostrap process
  for rootd, but that's a separate mess).

  <sia_base> 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 <sia_base> 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 <sia_base> 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: <child_handle> <validitydate> <bpki_cert_filename>

  <child_handle> 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.

  <validitydate> 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".

  <bpki_cert_filename> 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: <client_handle> <bpki_cert_filename> <sia_base>

  <client_handle> 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.
  
  <bpki_cert_filename> is the client's bpki.resources cert, which they
  just handed us, yay.

  <sia_base> 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 <rpki@rpki.net>
Subject: plan for new rpki setup tools
From: Rob Austein <sra@hactrn.net>
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 <rpki@rpki.net>
Subject: Re: renaming some of the obscure bits of myrpki
From: Rob Austein <sra@hactrn.net>
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: <m2eipknqxp.wl%randy@psg.com>
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.