diff options
Diffstat (limited to 'rpkid.without_tls/README')
| -rw-r--r-- | rpkid.without_tls/README | 351 |
1 files changed, 0 insertions, 351 deletions
diff --git a/rpkid.without_tls/README b/rpkid.without_tls/README deleted file mode 100644 index 2186c5db..00000000 --- a/rpkid.without_tls/README +++ /dev/null @@ -1,351 +0,0 @@ -$Id$ -*- Text -*- - -Python RPKI production tools. - -Requires Python 2.5. - -See doc/Installation for installation instructions and required -packages. - -The full manual is available in both PDF and HTML formats; the PDF is -in doc/manual.pdf, the HTML is in a compressed tarball -doc/manual.tar.gz. - - - -$Revision$ - -TO DO: - - * Rework handling of surprising responses to up-down requests. - Right now we get confused when we find that parent has issued - a cert that we don't remember requesting, even when we have - the ca_detail object in question sitting in our SQL as - pending. This can happen if we throw an exception later and - don't clean up properly -- which should never happen, but - let's try to be robust about this. - - So we need to be smarter about comparing our own state with - what we get back from our parent and figuring out what to do - next. We probably also need to commit changes to SQL earlier. - - In general we should never have more than one ca_detail in - state pending for a given ca, but the current code blindly - assumes that will never happen and never recovers if that - assumption has been violated. - - STATUS: Started, not complete. Internal tracking state for - whether objects have been published is in place, but there's - no code yet to force retry of failed publication. Some - support for cleaning up extraneous ca_detail objects, dunno - (yet) whether this is enough. - - TIME REQUIRED: One week (remaining). - - * Error handling: make sure that exceptions map correctly to - up-down error codes, flesh out left-right error codes. Note - that the same exception may produce different error codes - depending on which up-down PDU we're processing (sigh). - - Will require code audit for coherency, which is most of the work. - - TIME REQUIRED: Two weeks - - DEPENDS ON: almost everything else, as almost any code change - can raise new exceptions that we'd need to handle. - - STATUS: Not started - - * db.commit(), db.rollback(), code audit for data integrity - issues, fix any data integrity issues that turn up. Among - other issues, need to handle loss of connection to database - server and other MySQL errors. Need to be careful about - recovery action depending on whether we had uncommitted - changes. - - TIME REQUIRED (commit and rollback): 3-4 weeks - - TIME REQUIRED (data integrity audit): 1 week - - TIME REQUIRED (fix data integrity): Unknown, depends on code - audit and results of runtime testing. - - STATUS: Not started - - * Resource subsetting (req_* attributes in up-down protocol), - full implementation. Requires expanding SQL child_cert table - to hold subset masks and rewriting a fair amount of code. - - TIME REQUIRED: 3-4 weeks - - STATUS: Not started - - * Performance testing and profiling. Getting rid of tlslite was - a good first step, and RSA will always be slow without a HSM, - but last time I tried profiling I saw hints that the Python - ASN.1 may be a bottleneck. - - TIME REQUIRED: A few days to do profiling. What happens after - that depends on what profiling finds. - - DEPENDS ON: Serious load testing may require assistance from - others with larger test labs than I have directly available. - - STATUS: Barely started - - * Clean up rootd.py to be usable in a production system. Most - urgent issues are handling of private keys, publishing outputs - in pubd, and reissuing when details or keys change. May not - need much else, as this is not a high-traffic server. - - Alternatively, perhaps rootd's functionality should be merged - into rpkid after all, given that we now believe that anybody - who needs to certify private address space may need to run it. - - TIME REQUIRED: One week if just cleaning up rootd. 2-3 weeks - if folding rootd into rpkid. - - STATUS: Not started - - * Update internals docs (Doxygen). Mostly this means updating - function comments in the Python code, as the rest is - automatic. May require a bit more overview text to explain - the workings and usage of the code. - - TIME REQUIRED: One week. - - STATUS: Ongoing - - * Add HSM support. Architecture includes it, current code does - not. First step here would be talking to somebody with strong - understanding of PKCS# 11. - - TIME REQUIRED: Unknown - - STATUS: Not started - - * Tighten up syntax checking in left-right schema. - - TIME REQUIRED: One day. - - STATUS: Not started - - * rcynic handling of RPKI trust anchors does not yet support - draft-ietf-sidr-ta. Not needed for technical reasons - ("trust-anchor-uri-with-key" method is roughly equivilent and - much simpler), may be required for political reasons. - - TIME REQUIRED: Three days - - STATUS: Not started - - * Investigate using EKU (RFC 3280 4.2.1.13) as an alternative to - wiring in BPKI EE certs for left-right protocol. - - STATUS: Not started - - * Django web UI to RPKI code will require some back-end support, - not yet sure exactly how much. Current plan is that Django - tool just drops data into SQL, at which point it becomes my - problem; if we keep this model, semantics of the existing - command line tools should map fairly well, so this part will - just be a matter of performing essentially the same operations - that the command line UI does now, with SQL tables instead of - CSV files as the data store. - - TIME REQUIRED: Two weeks - - STATUS: Not started - - * Django Web UI to RPKI code as currently envisioned will (also) - require some additional data from rpkid and rcynic that is not - yet available in machine-parsable form, so that UI can report - on status of delegated resources and detailed validation - status. rpkid extensions for this should be relatively - simple, rcynic work may be a bit more complex, or at least - tedious, as it'll be C code generating XML. - - <list_received_resources/> was part of this. - - rcynic XML detail should describe entire certificate - validation chain and status of validation at each stage. - Given tree walk this is probably going to be some kind of - XML-representation tree structure, which i will probably - design as s-expressions first to keep my brain from exploding - with gratuitous XML syntax. - - TIME REQUIRED: 1-2 weeks. - - STATUS: <list_received_resources/> done. - rcynic work started along a different path (XML - reporting of validation failure events, mostly done, - still some corner cases); unclear whether this will - suffice or UI really needs tree structure per above. - - * At present there is no mechanism by which an IRBE could - request signing of objects other than ROAs. Eg, there has - been some discussion of signing S/MIME letters to humans - asking for routing, as an alternative to ROAs. If we decide - to support this at all, it turns into a generalization of the - ROA problem, and suggests that perhaps ROA generation should - be handled somewhere outside of rpkid and only passed to rpkid - for signing. This would be a significant change to the - architecture, as it would remove rpkid's responsibility for - keeping ROAs up to date. - - On further analysis: ROAs are different from S/MIME letters, - in that ROAs are something we want both published and - maintained on an ongoing basis until canceled, while S/MIME - letters are one-offs that probably are not published. So ROAs - need -something- to keep them current, and that something - might as well be rpkid unless we find a strong argument that - it should be something else. So the S/MIME letter - functionality probably stays a different mechanism from ROAs. - - TIME REQUIRED: One week (including deciding what left-right - protocol semantics for this should be) - - STATUS: Not started - - * There has been some discussion both in and out of the SIDR WG - on perhaps dropping TLS out of the up-down protocol, as it is - arguably not providing much that we can't do equally well with - CMS. Left-right and publication are currently not SIDR WG - docs, but presumably they would follow. Dunno where this is - going to go, but assuming for purposes of discussion that we - do drop TLS, we'll want to rip all that code out. This - includes revising BPKI, SQL, left-right and publication - protocols, and code using all of these both in daemons and UI - tools. - - TIME REQUIRED: Three weeks (very rough guess). - - DEPENDS ON: Decision whether to keep or drop TLS. - - STATUS: Not started - - * Integrate UI tools into main code base. Right now there's - this odd split, with the myrpki stuff off to one side, irdbd - (which is also a sample implementation, not a core tool) in - with rpkid, test code scattered hither and yon in all the - above places, and none of it set up nicely either for running - in place or installation. This all needs to be cleaned up, - most likely by reorganizing all of the Python (and POW) code. - - TIME REQUIRED: Two weeks. - - STATUS: Mostly done. POW is still hanging off to the side, - but the myrpki/ directory has now been merged into rpkid/, and - various other bits have been cleaned up. - - * Autoconf review. Right now we're making minimal use of - autoconf, just enough to get the code running on Mac OS and - clean up a few old annoyances. There are other things that - ought to be using autoconf, now that we're stuck with it. Eg, - installation scripts, the build code for POW, etc. In the - long run we might even want to check for usable system OpenSSL - code and libraries: the RFC 3779 code is still off by default - in all known public releases of OpenSSL, but the BPKI stuff - that myrpki does only requires CMS, not RFC 3779, so it may be - able to use the system openssl binary in many cases. - - TIME REQUIRED: One week for an initial pass. - - DEPENDS ON: Installation scripts. Not so much depends on, - really, as two aspects of one interrelated mess. - - STATUS: Not started - - * We need installation scripts. Right now the only thing we - install is rcynic, and that only on FreeBSD. - - TIME REQUIRED: One week, longer if installation for many platforms is - required - - STATUS: Not started - - * We need better and unified documentation. Right now doc is - scattered between rpkid core manual, various READMEs, internal - docuemntation in various tools, etcetera. This is not kind to - the user. Depending on how much hand-written (as opposed to - Doxygen-harvested) doc we end up with, might want to convert - overall to something like the Doxygen/Docbook combination that - the Boost project uses (Boostbook). - - TIME REQUIRED: At least two weeks, plus at least one more week - if making a serious change in doc tools (eg, Boostbook). - - DEPENDS ON: Portions of this would make sense to defer until - after whatever code reorg happens to integrate UI tools, etc. - Most of the hand-written content could be done right away, - might require minor edits later to track reorg changes. - - STATUS: Not started - - * Rewrite irbe_cli.py to use cmd module. Right now irbe_cli is - useful only as a debugging tool for its author, and the - interface is very clunky (even by comparision to other clunky - bits of code in this package). Rewriting to use cmd module - would be a major improvement; some minor challenges here - because irbe_cli integrates so tightly with the Python message - classes representing the left-right and publication protcols; - figuring out how to turn this into a cmd-based program without - massive (and fragile) duplication of code is probably good for - a few days of head scratching. - - TIME REQUIRED: Two weeks (including head scratching) - - STATUS: Not started - - * Clean up testbed tools. There's a collection of hacks that - have been evolving as we've been building the testbed, most of - which just grew as our needs evolved. The main scripts are - checked into the repository, but some of the minor stuff is - not, and some of the automation used in the testbed (cron - scripts, automated use of a version control system (currently - subversion) to archive changes to running data, etcetera) - might be useful to others, so it should be cleaned up and made - available as part of the package. - - TIME REQUIRED: One week - - STATUS: Moving target, but let's say "not started" for the - bits I'm thinking about as I type this. - - * Early (pseudo) operational testing has uncovered a conflict - between RIRs need not to be in the business of attesting to - identities and operators need to have -some- way of finding - out who to call when a RPKI cert is broken. Current proposal - is to allow signature and publication of blobs of whois-like - data; these would be signed by an EE cert using RFC 3779 - inheritance, and would in essence be a self-attestation (no - checking by others, no liability incurred by others, etc) as - to contact information one might use in case of a problem. - This would require a minor change to the rescert profile, so - the SIDR WG would need to sign off on this. As this data - would be published, presumably we would want rcynic to be able - to check it. - - TIME REQUIRED: One week to add to rpkid et al (very rough -- - includes design work to figure out exactly where this would - fit, actual coding probably relatively minor). Perhaps an - additional day or three to add to rcynic and write suitable - search and display tools. - - DEPENDS ON: Agreement to add this to rescert profile. - - STATUS: Not started - - * myrpki.py should have a command that summarizes current state - (data on file, actions it might make sense to take now, etc). - - TIME REQUIRED: A day or two - - STATUS: Not started - - * rcynic needs major rewrite to run multiple rsync processes in - background, to work around tarpit attack by evil publishers. - - TIME REQUIRED: Three weeks (wild guess) - - STATUS: Not started, byond some preliminary design thoughts. |