diff options
Diffstat (limited to 'myrpki/README')
| -rw-r--r-- | myrpki/README | 660 |
1 files changed, 0 insertions, 660 deletions
diff --git a/myrpki/README b/myrpki/README deleted file mode 100644 index 3057fd0e..00000000 --- a/myrpki/README +++ /dev/null @@ -1,660 +0,0 @@ -$Id$ - -INTRODUCTION - -The design of rpkid and friends assumes that certain tasks can be -thrown over the wall to the registry's back end operation. This was a -deliberate design decision to allow rpkid et al to remain independent -of existing database schema, business PKIs, and so forth that a -registry might already have. All very nice, but it leaves someone who -just wants to test the tools or who has no existing back end with a -fairly large programming project. The tools in this directory attempt -to fill that gap. - -This is a basic implementation of what a registry back end would need -to use rpkid and friends. These tools do not use every available -option, nor are they necessarily as efficient as possible. Large -registries will almost certainly want to roll their own tools, perhaps -using these as a starting point. Nevertheless, we hope that these -tools will at least provide a useful example. - -The primary tools here consist of two Python programs: myrpki.py and -myirbe.py. The first is for use by any entity that needs resources -allocated via the RPKI system, the second is for use by entities that -actually run copies of rpkid and its several supporting programs. - -The basic idea here is that a user who has resources maintains a set -of .csv files containing a text representation of the data needed by -the back-end, along with a configuration file containing other -parameters. The intent is that these be very simple files that are -easy to generate either by hand or as a dump from relational database, -spreadsheet, awk script, whatever works in your environment. Given -these files, the user then runs the myrpki.py script to extract the -relevant information and encode everything about its back end state -into a single .xml file, which the script writes out to disk. The -user then conveys this .xml file via some convenient means (PGP-signed -mail, USB key, dog-sled) to the operator of the rpkid engine that will -perform RPKI services on behalf of the user. - -The rpkid operator collects these .xml files from all the resource -holders it hosts, and feeds them all into the myirbe.py script, which -uses the data in the .xml files to populate the IRDB, create objects -in rpkid and pubd via the left-right and publication protocols, -etcetera. The script rewrites its input .xml files to contain any -updated information (eg, PKCS #10 requests for business signing -context certificates), so that the .xml file once again contains -everything that must be communicated between the rpkid operator and -hosted resource holder. - -The rpkid operator ships the updated .xml back to the user, who then -runs the myrpki.py script again to perform any necessary actions (eg, -issuing business signing context certificates given the PKCS #10 -request sent by myirbe.py), resulting in another update to the .xml -file, which the user then ships back to the rpkid operator. This -cycle repeats until nothing further needs to be changed. - -Note that, as certificates and CRLs have expiration and nextUpdate -values, a low-level cycle of updates passing between resource holder -and rpkid operator will be necessary as a part of steady state -operation. [The current version of these tools does not yet -regenerate these expiring objects, but fixing this will be a -relatively minor matter.] - -Since we assume that anybody who bothers to run rpkid is also a -resource holder, myirbe.py and myrpki.py can use the same -configuration file, and myirbe.py will run myrpki.py automatically if -the [myrpki] section of the configuration file is present. - -The third important file in this system is the configuration file for -myrpki.py and myirbe.py. This contains a number of sections, some of -which are for these scripts, others of which are for the OpenSSL -command line tool, which these scripts use do most of the certificate -work. The examples/ subdirectory contains a commented version of the -configuration file that explains the various parameters. - -myrpki.py deliberately does not use any libraries other than the ones -that ship with Python 2.5; in particular, it does not require any of -the other Python RPKI code. This is intentional, to minimize -portability issues for hosted resource holders. It does require a -reasonably current version of the OpenSSL command line tool, but the -version that is built as a side effect of building the rcynic relying -party tool is adequate if the system copy of this tool isn't. - -The .csv files read by myrpki.py can be anything that the Python "csv" -library understands. By default, they're in tab-delimited format -(because the author finds this easier to read than the comma-delimited -format), but this can be changed to fit local needs. - -Please note: tab-delimited CSV is a format defined by a certain -popular spreadsheet program, and is *not* the same as -whitespace-separated text. Tab characters are *punctuation*, and each -tab character indicates the division between two columns. Two tab -characters in a row indicates a separator, a blank cell, and another -separator, not one separator. The upshot of all this is that -attempting to make your columns line up prettily will not work as you -expect, you will end up with too many cells, some of them empty. - -A number of the fields in the configuration or CSV files involve -certificates. Some of these are built automatically, others must be -imported so that the scripts can cross-certify them. The certificates -you need to import are all self-signed BPKI trust anchor certificates -generated by other entities; you import them by specifying the name of -a file where you stored the BPKI certificate in question (in OpenSSL -"PEM" format). - -Keep reading, and don't panic. - -The default configuration file name is myrpki.conf. - -See examples/myrpki.conf for details on the variables that you can -(and in some cases must) set. - -See examples/*.csv for commented examples of the several CSV files. -Note that the comments themselves are not legal CSV, they're just -present to make it easier to understand the examples. - -GETTING STARTED -- OVERVIEW - -As explained above, the two basic programs are myrpki.py (for resource -holders) and myirbe.py (for rpkid operators); myirbe.py runs myrpki.py -automatically for a rpkid operator's own resources if myirbe.py finds -a [myrpki] section in its configuration file. - -Which process you need to follow to get started depends on whether you -are running rpkid yourself or will be hosted by somebody else. We -call the first case "self-hosted", because the software treats running -rpkid to handle resources that you yourself hold as if you are an rpkid -operator who is hosting an entity that happens to be yourself. - -"$top" in the following refers to wherever you put the -subvert-rpki.hactrn.net code. Once we have autoconf and "make -install" targets, this will be some system directory or another; for -now, it's wherever you checked out a copy of the code from the -subversion repository or unpacked a tarball of the code. - -GETTING STARTED -- HOSTED CASE - -The basic steps involved in getting started for a resource holder who -is being hosted by somebody else are: - -1) Obtain contact information and BPKI trust anchors from RPKI parents - and an RPKI publication service (see below for details). - -2) Write a configuration file (copy $top/myrpki/examples/myrpki.conf - and edit as needed). You can skip the sections associated with the - various daemons and their runtime control tools ([myirbe], [rpkid], - [irdbd], [pubd], [rootd], [irbe_cli]). You *do* need to configure - the [myrpki] section. - -3) Using $top/myrpki/examples/*.csv as a guide, create a set of CSV - files representing RPKI parents, RPKI children, resources to be - assigned to RPKI children, and ROAs to be generated once the - necessary RPKI certificates are available. Most of these CSV files - can be empty while first getting started, the only file that - absolutely must be populated is the file describing parents. - - You may choose to place your configuration file (which we will - refer to here as myrpki.conf) and your CSV files in their own - directory. The software doesn't really care. If you use absolute - names for all the filename entries in the configuration file and - CSV files, you can put the files wherever you like; if you use - relative names, they will be interpreted relative to the directory - in which you run the program that reads the file. - - [At some future date we may provide a default directory for - relative filenames such as /usr/local/etc/rpki, but the above - description holds for now.] - -4) Run myrpki.py to generate a BPKI trust anchor and collect all the - data from the configuration file, CSV files, and newly created BPKI - into a single XML file which can be shipped to the rpkid operator - who is hosting your resources. - -5) Send the XML file generated in step (4) to your rpkid operator. - -6) Wait for your rpkid operator to ship you back an updated XML file - containing a PKCS #10 certificate request for the BPKI signing - context (BSC) created by rpkid. - -7) Run myrpki.py again with the XML file received in step (6), to - issue the BSC certificate and update the XML file again to contain - the newly issued BSC certificate. - -8) Send the updated XML file back to your rpkid operator. - -At this point you're done with initial setup. You will need to run -myrpki.py again whenever you make any changes to your configuration -file or CSV files. [Once myrpki.py knows how to update BPKI CRLs, you -will also need to run myrpki.py periodically to keep your BPKI CRLs up -to date.] Any time you run myrpki.py, you should send the updated XML -file to your rpkid operator, who will [generally?] send you a further -updated XML file in response. - -GETTING STARTED -- SELF-HOSTED CASE - -The first few steps involved in getting started for a self-hosted -resource holder (that is, a resource holder that runs its own copy of -rpkid) are the same as in the hosted case above; after that the -process diverges. - -[As of the time at which these instructions were written, it had -become clear that there really should be an additional setup script -which automates much of the following. That script hasn't been -written yet, so for the moment this documents the setup process as it -stands now. Once that setup script has been written, these -instructions will be updated to match. In the meantime, please accept -the author's apologies for the tedious nature of the current setup -process.] - -The [current] steps are: - -1) Obtain contact information and BPKI trust anchors from RPKI parents - and an RPKI publication service (see below for details). - -2) Write a configuration file (copy examples/myrpki.conf and edit as - needed). You need to configure the [myrpki] and [myirbe] sections - as well as the sections associated with the daemons you will be - running ([rpkid], [irdbd], [irbe_cli]). You only need to configure - the [pubd] section if you intend to run your own publication - service: in general this is not recommended, because each - additional publication service in the RPKI universe places a small - additional burden on every relying party, since every relying party - has to download data from every publication service. In general - it's better to use an existing publication service operated by - somebody else (eg, your RPKI parent) if you can. In general most - cases you can leave the [rootd] section alone, as in most cases you - should not be running rootd. - -3) Using $top/myrpki/examples/*.csv as a guide, create a set of CSV - files representing RPKI parents, RPKI children, resources to be - assigned to RPKI children, and ROAs to be generated once the - necessary RPKI certificates are available. Most of these CSV files - can be empty while first getting started, the only file that - absolutely must be populated is the file describing parents. - - You may choose to place your configuration file (which we will - refer to here as myrpki.conf) and your CSV files in their own - directory. The software doesn't really care. If you use absolute - names for all the filename entries in the configuration file and - CSV files, you can put the files wherever you like; if you use - relative names, they will be interpreted relative to the directory - in which you run the program that reads the file. - - [At some future date we may provide a default directory for - relative filenames such as /usr/local/etc/rpki, but the above - description holds for now.] - -4) See rpkid/doc/Installation, and follow the basic installation - instructions there to build the RFC-3779-aware OpenSSL code and - associated Python extension module. - -5) Next, you need to set up the MySQL databases that rpkid et al will - use. The MySQL database, username, and password values all need to - match the ones you specified in myrpki.conf. There are two - different ways you can do this: - - a) You can use the setup-sql.py script, which prompts you for your - MySQL root password then attempts to do everything else - automatically using values from myrpki.conf; or - - b) You can do it manually. - - The first approach is simple: - - $ python setup-sql.py - Please enter your MySQL root password: - - The script should tell you what databases it creates. You can use - the -v option if you want to see more details about what it's doing. - - If you'd prefer to do the SQL setup manually, perhaps because you - have valuable data in other MySQL databases and you don't want to - trust some random setup script with your MySQL root password, - you'll need to use the MySQL command line tool, as follows: - - $ mysql -u root -p - - mysql> CREATE DATABASE irdb_database; - mysql> GRANT all ON irdb_database.* TO irdb_user@localhost IDENTIFIED BY 'irdb_password'; - mysql> USE irdb_database; - mysql> SOURCE $top/rpkid/irdbd.sql; - mysql> CREATE DATABASE rpki_database; - mysql> GRANT all ON rpki_database.* TO rpki_user@localhost IDENTIFIED BY 'rpki_password'; - mysql> USE rpki_database; - mysql> SOURCE $top/rpkid/rpkid.sql; - mysql> COMMIT; - mysql> quit - - where "irdb_database", "irdb_user", "irdb_password", - "rpki_database", "rpki_user", and "rpki_password" are the - appropriate values from your configuration file. - - If you are running pubd and doing manual SQL setup, you'll also - have to do: - - $ mysql -u root -p - mysql> CREATE DATABASE pubd_database; - mysql> GRANT all ON pubd_database.* TO pubd_user@localhost IDENTIFIED BY 'pubd_password'; - mysql> USE pubd_database; - mysql> SOURCE $top/rpkid/pubd.sql; - mysql> COMMIT; - mysql> quit - -6) Run myirbe.py -b to set up the initial BPKI structure needed to run - your daemons: - - $ python $top/myrpki/myirbe.py -b - - The -b option tells myrpki.py that you want it to stop after the - initial BPKI setup, regardless of whether it thinks this is - necessary. If you have not done this before it should tell you - that it has updated the BPKI and that you need to (re)start daemons - now. - -7) If you are running your own publication repository (that is, if you - are running pubd), you will also need to set up an rsyncd server or - configure your existing one to serve pubd's output. There's a - sample configuration file in $top/myrpki/examples/rsyncd.conf, but - you may need to do something more complicated if you are already - running rsyncd for other purposes. See the rsync(1) and - rsyncd.conf(5) manual pages for more details. - -8) Start the daemons. You can use $top/myrpki/start-servers.py to do - this, or write your own script. - - If you intend to run pubd, you should make sure that the directory - you specified as publication-base in the [pubd] section exists and - is writable by the userid that will be running pubd, and should - also make sure to start rsyncd. - -9) Run myirbe.py again, twice, this time with no arguments. - - $ python $top/myrpki/myirbe.py - $ python $top/myrpki/myirbe.py - - The reason for running myirbe.py twice at this point is explained - in the Introduction section, above; in brief, the first run sets up - almost everything, but a second pass is required to generate the - BSC certificate. - -At this point, if everything went well, rpkid should be up, -configured, and starting to obtain resource certificates from its -parents, generate CRLs and manifests, and so forth. At this point you -should go figure out how to use the relying party tool, rcynic: see -$top/rcynic/README if you haven't already done so. - -If and when you change your CSV files, you should run myirbe.py again -to feed the changes into the daemons. - -GETTING STARTED -- HOSTING CASE - -If you are running rpkid not just for your own resources but also to -host other resource holders (see "HOSTED CASE" above), your setup will -be almost the same as in the self-hosted case (see "SELF-HOSTED CASE", -above), with one procedural change: you will need to tell myirbe.py to -process the XML files produced by the resource holders you are -hosting. You do this by specifying the names of all those XML files -on myirbe's command line. So, if you are hosting two friends, Alice -and Bob, then, everywhere the instructions for the self-hosted case -say to run myirbe.py with no arguments, you will instead run it with -the names of Alice's and Bob's XML files: - - $ python $top/myrpki/myirbe.py alice.xml bob.xml - -Note that myirbe.py sometimes modifies these XML files, in which case -it will write them back to the same filenames. While it is possible -to figure out the set of circumstances in which myirbe.py will modify -XML files (at present, this only happens when myirbe.py has to ask -rpkid to create a new BSC keypair and PKCS #10 certificate request), -it may be easiest just to ship back an updated copy of the XML file -after every you run myirbe.py. - -GETTING STARTED -- "PURE" HOSTING CASE - -In general we assume that anybody who bothers to run rpkid is also a -resource holder, but the software does not insist on this. If you are -running rpkid solely for others and have no resources of your own, the -process is almost identical to the "HOSTING CASE", above. The one -change is that you should *not* have a [myrpki] section in your -configuration file. - -A (perhaps) slightly-more-plausible use for this capability would be -if you are an rpkid-running resource holder who wants for some reason -to keep the resource-holding side of your operation completely -separate from the rpkid-running side of your operation. This is -essentially the pure-hosting model, just with an internal hosted -entity within a different part of your own organization. - -DATA YOU NEED FROM YOUR RPKI PARENT AND PUBLICATION SERVICE - -In order to connect to your RPKI parent, you will need to supply your -BPKI trust anchor to your parent and obtain four pieces of data from -your parent. - -Assuming that you are using something resembling the default -configuration, your BPKI trust anchor will be bpki.myrpki/ca.cer. -This is an OpenSSL "PEM" format file. You will need to provide this -to your RPKI parent. - -The data you need from your parent are: - -- The service URL for your entry point into your parent's rpkid. - Typically this will be a URL of the form: - - https://example.org:port/up-down/parenthandle/myhandle - - where "example.org" and "port" are the DNS name and TCP port of your - parent's rpkid service, "parenthandle" is your parent's name - (handle) for itself, and "myhandle" is your parent's name (handle) - for you; - -- Your parent's BPKI trust anchor for its resource-holding persona - (the entity represented by "parenthandle", above); - -- Your parent's BPKI trust anchor for daemons it operates; and - -- The handle by which your parent refers to you in its database, - generally the same as "myhandle" in the service URL. - -The need for two separate BPKI trust anchors for your parent is due to -a limitation of the HTTPS protocol; recent extensions to TLS provide a -way to work around this limitation, but at this point in time rpkid -can't assume support for the TLS extension in question. Roughly -speaking, the first BPKI trust anchor corresponds to the your parent -as a resource-holding entity, while the second corresponds to your -parent as an rpkid-operating entity. - -These four data correspond, in order, to the second, third, fourth, -and fifth columns in your parents.csv file. In most cases you will -have only one parent, so there will be only one line in that file. - -The first field in the parents.csv file is your name for your parent, -which can be any name you like so long as it doesn't conflict with -your name for another parent. - -The sixth field in the parents.csv file determines the base rsync URI -for objects signed by certificates issued by this parent. If you are -using an external publication service (recommended), your parent must -supply this URI as well; a typical value would be -rsync://example.org/Dad/Me/ or rsync://example.org/Grandma/Dad/Me/. - -If you are running your own copy of pubd, this URI should point to the -directory that corresponds to the publication-base setting in the -[pubd] section of your configuration file. - -If you are using an external publication service (which might be your -parent, grandparent, or any ancestor all the way up to the root), your -publication service will also need to tell you: - -- The service URL for the publication service (pubd_base parameter in - [myirbe] section of your configuration file); - -- The publication service's name for you (repository_handle field in - [myrpki] section of your configuration file); and - -- The BPKI trust anchor for the publication service - (repository_bpki_certificate field in [myrpki] section of your - configuration file). - -Note that the first of these three parameters only applies if you are -running rpkid, while the second and third apply even if your resources -are hosted on somebody else's rpkid. In effect, this means that all -the entities sharing a single rpkid must also share a single -publication service. This is a restriction of the myrpki/myirbe -software, not rpkid itself, so it could be removed if there were a -strong need to do so, but given that each additional publication -service imposes a small additional burden on every relying party in -the world, we do not view this restriction as a problem. - -DATA YOU NEED TO GIVE YOUR RPKI CHILDREN AND USERS OF YOUR PUBLICATION SERVICE - -First, read the previous section describing what children and -publication clients expect to receive. - -- The service URL for your rpkid will be an HTTPS URL of the form - - https://example.org:port/up-down/yourhandle/childhandle - - where "example.org" and "port" are the DNS name and TCP port of your - rpkid service ([rpkid] section of your configuration file), - "yourhandle" is the handle parameter from the [myrpki] section of - your configuration file, and "childhandle" is this child's handle as - it appears in the first columns of your children.csv, asns.csv, and - prefixes.csv files; - -- The BPKI trust anchor for your resource-holding persona is your - bpki.myrpki/ca.cer; - -- The BPKI trust anchor for daemons you operate is your - bpki.myirbe/ca.cer; and - -- The handle by which you refer to your child is the same as - "childhandle", above. - -If you are operating a publication service, you will also need to -supply: - -- Your pubd service URL, which will be an HTTPS URL of the form - - https://example.org:port/ - - where "example.org" and "port" are the server-host and server-port - parameters from the [pubd] section of your configuration file; - -- Your name for this publication client, which is the first column of - your pubclients.csv file (note that this can be a structured name - using "/" characters as a hierarchy delimiter); and - -- The BPKI trust anchor for the daemons you operate - (bpki.myirbe/ca.cer). - -Note that, if you are operating pubd, it's best for relying parties if -your children's publication points are underneath yours within the -publication hierarchy, to allow rsync to check for updates as -efficiently as possible. pubd's support for hierarchical client -handles is intended to simplify this: if you have a child Alice, who -has children Bob and Bill, and you, your children, and your -grandchildren will all be using your publication service, you might -assign <client_handle> and <sia_base> parameters (first and third -fields in pubclients.csv) as follows: - -Me rsync://rpki.example.org/Me/ -Me/Alice rsync://rpki.example.org/Me/Alice/ -Me/Alice/Bob rsync://rpki.example.org/Me/Alice/Bob/ -Me/Alice/Bill rsync://rpki.example.org/Me/Alice/Bill/ - -Note that you will need trust anchors for your children and any -publication clients. In both cases the trust anchor you need is the -child's or client's resource-holding BPKI trust anchor -(bpki.myrpki/ca.cer); who operates the rpkid that host your children -or publication clients is not strictly relevant to the authorization -model, what matters is who holds the resources and is authorized to -request and publish RPKI data derived from them. - -TROUBLESHOOTING - -If you run into trouble setting up this package, the first thing to do -is categorize the kind of trouble you are having. If you've gotten -far enough to be running the daemons, check their log files. If -you're seeing Python exceptions, read the error messages. If you're -getting TLS errors, check to make sure that you're using all the right -BPKI certificates and service contact URLs. - -TLS configuration errors are, unfortunately, notoriously difficult to -debug, because connections due to misconfiguration usually fail early, -deep in the guts of the OpenSSL TLS code, where there isn't enough -application context available to provide useful error messages. - -If you've completed the steps above, everything appears to have gone -OK, but nothing seems to be happening, the first thing to do is check -the logs to confirm that nothing is actively broken. rpkid's log -should include messages telling you when it starts and finishes its -internal "cron" cycle. It can take several cron cycles for resources -to work their way down from your parent into a full set of -certificates and ROAs, so have a little patience. rpkid's log should -also include messages showing every time it contacts its parent(s) or -attempts to publish anything. - -rcynic in fully verbose mode provides a fairly detailed explanation of -what it's doing and why objects that fail have failed. - -You can use rsync (sic) to examine the contents of a publication -repository one directory at a time, without attempting validation, by -running rsync with just the URI of the directory on its command line: - - $ rsync rsync://rpki.example.org/where/ever/ - -[Maybe there should be something here explaining how to use -irbe_cli.py for debugging, but the syntax is fairly obscure as it's -just a command line interface to the left-right and publication -protocols -- almost certainly want a friendlier tool for -troubleshooting.] - -KNOWN ISSUES - -The lxml package provides a Python interface to the Gnome libxml2 and -libxslt C libraries. This code has been quite stable for several -years, but initial testing with lxml compiled and linked against a -newer version of libxml2 ran into problems (specifically, gratuitous -RelaxNG schema validation failures). libxml2 2.7.3 worked; libxml2 -2.7.5 did not work on the test machine in question. Reverting to -libxml2 2.7.3 fixed the problem. Rewriting the two lines of Python -code that were triggering the lxml bug appears to have solved the -problem, so the code now works properly with libxml 2.7.5, but if you -start seeing weird XML validation failures, it might be another -variation of this lxml bug. - -An earlier version of this code ran into problems with what appears to -be an implementation restriction in the the GNU linker ("ld") on -64-bit hardware, resulting in obscure build failures. The workaround -for this required use of shared libraries and is somewhat less -portable than the original code, but without it the code simply would -not build in 64-bit environments with the GNU tools. The current -workaround appears to behave properly, but the workaround requires -that the pathname to the RFC-3779-aware OpenSSL shared libraries be -built into the _POW.so Python extension module. At the moment, in the -absence of "make install" targets for the Python code and libraries, -this means the build directory; eventually, once we're using autoconf -and installation targets, this will be the installation directory. If -necessary, you can override this by setting the LD_LIBRARY_PATH -environment variable, see the ld.so man page for details. This is a -relatively minor variation on the usual build issues for shared -libraries, it's just annoying because shared libraries should not be -needed here and would not be if not for this GNU linker issue. - - - -Sketch towards a simple description of the BPKI (sic). - -This started out as notes to myself during a redesign, and badly needs -rewriting. - -Hosted (myrpki) entity needs: - -- Self-signed BPKI root (doesn't really need to be self-signed, nobody - else will care, but self-signed is simplest for our purposes). This - is what we've been calling the "self" cert in testbed.py. - -- BSC EE issued by self-signed root. - -- Cross-certs of every foreign entity (parent, child, or pubd): these - are CA certs with pathLenConstraint 0. Input for this cross-cert is - self-signed (or whatever) from foreign entity, output is - pathLenConstraint 0 CA cert issued by myrpki entity's own - self-signed root. - -Hosting rpkid (myirbe) needs: - -- Self-signed BPKI root - -- BSC EE certs for rpkid, irdbd, irbe_cli, etc - -- For each hosted entity (including self-hosting): - - Cross-cert of hosted entity's root, issued by rpkid root: CA cert - with pathLenConstraint 1 - - In theory that's all that's required, everything else is handled - through the hosted entity's cert chain. - -pubd needs: - -- Self signed root (might share with rpkid but let's keep it separate - conceptually) - -- BSC EE certs for pubd and irbe_cli - -- For each client entity of pubd: - - Cross-cert of client entity's self cert (pathLenConstraint 0). - - This should allow pubd to verify clients' BSC EE certs without - getting into transitive CA relationships. - -rootd (when applicable at all) needs: - -- Self-signed root - -- BSC EE cert for talking up-down (server) with one and only child - -- Cross-cert (pathLenConstraint 0) of one and only child's self cert. |