$Id$ -*- Text -*- Python RPKI production tools. Requires Python 2.5. See doc/Installation for installation instructions and required packages. $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: Not started. * Use a ticket system instead of trying to track work items in this README file and archived messages from the testbed list? STATUS: I have a trac instance, Randy has an RT instance, just need to decide whether to do something about this, pick one, and move on. * 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. DEPENDS ON: async tasking model rollback. 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. Some very preliminary tests show a hotspot in the TLS code, but further testing will be needed, particularly after the async tasking model change. 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. TIME REQUIRED: One week 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 * Installation packaging, so that rpkid can be built and installed like a normal package. TIME REQUIRED: One week, longer if installation for many platforms is required 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 match most recent agreement by design team. Currently waiting for an OID assignment for the CMS-wrapped indirection format that the design team settled on. TIME REQUIRED: Three days DEPENDS ON: OID assignment STATUS: Not started * Publication protocol ACL checking may need revisiting. Tricky bit is making sure that repository receives enough information to know whether parent has authorized child to use parent's namespace in nesting case; in theory this is straightforward but requires careful checking. Current implementation just uses a configured path check and does not attempt to trace back to permission from parent in nested publication case. Class and method design is intended to make it easy to drop in additional checks if needed. STATUS: Trivial version (required path check) done. * 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 * Testing of this by anybody but the author and a few friends is going to require some kind of user interface. Python based web UI is probably the most cost effective approach, Django might be a good base for this. Some of the operations suggested in an initial brainstorming session on this are outside the scope of what rpkid currently knows how to do (eg, signing S/MIME "please route" messages), so one of the tasks here is to see if trying to write a user interface sheds light on required features that are currently missing. STATUS: CSV file based UI done and documented, perhaps usable. Django web UI for hosted case under development by a friendly Django wizard, current design has it just doing UI and I/O with its own SQL data, so will need a tool to sit between Django's SQL and our code. * 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. STATUS: Not started