diff options
| -rw-r--r-- | rpkid/README | 257 |
1 files changed, 93 insertions, 164 deletions
diff --git a/rpkid/README b/rpkid/README index 822c5ed2..0864cddf 100644 --- a/rpkid/README +++ b/rpkid/README @@ -27,22 +27,7 @@ External Python packages required: FreeBSD: /usr/ports/security/py-tlslite -- Cryptlib, at the moment just to support TLSlite but may end up using - it for other things later. - - http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ - - FreeBSD: /usr/ports/security/cryptlib - - ...but the FreeBSD port doesn't (yet?) install the Python bindings, - sigh, so at the moment you have to do that by hand: - - # cd /usr/ports/security/cryptlib - # make install - # cd work/bindings - # python setup.py install - # cd ../.. - # make clean +- Cryptlib is no longer required. - Eventually I expect that this will require an event-handling package like Twisted, but I'm not there yet. @@ -67,13 +52,103 @@ $Revision$ TO DO: +- Update biz trust anchor model to what we came up with in Amsterdam. + This was a direct result of security review by Kent and Housley. + + This has been waiting for work we hope RobK is doing. This is + probably not a lot of coding, probably a few extra cert fields in + the self object which we then need to toss into the + rpki.x509.X509_chain objects before verifying CMS or TLS, and + perhaps the existing TA fields in various objects become pairs of + certs instead of a single TA, but this is mostly just generalization + and reuse of existing code, no bold new adventures. + + Discussion in Philadelphia revealed that this is not yet a done + deal. Housley, RobK, and I all seem to be on the same page, and we + think that what we're proposing will make sense to APNIC once we + explain it properly, but overall we have not yet converged. + + PRIORITY: Required (security issue) + + STATUS: Not started + +- rcynic handling of RPKI trust anchors needs updating. Discussions + over last N months of how RPKI trust anchors work, how we package + them, and how we roll them over. The last (TA rollover) is the + driver for this. + + APNIC has apparently moved on from their proposal to use CMS-signed + OpenSSL "PEM" format, they're now proposing a CMS-signed ASN.1 + SEQUENCE OF something. Precise details of APNIC's new model not yet + known. Need to do analysis to make sure this is adaquate for our + needs, if so just use it. This would involve minor changes to + rcynic. + + PRIORITY: Required (usability issue for relying parties) + + STATUS: Not started + +- Publication protocol and implementation thereof. Protocol design + started, Randy had comments that sent me back to the drawing board + (he was right). Next step is to integrate Randy's advice, which + probably means picking up more of the left-right protocol framework. + + Desirable although not strictly required that protcol be agreed upon + among the RIRs. Might not be practical given how long it takes + group to decide anything. + + 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. + + ARIN can't host output of non-hosted RPKI engines without this, and + that's critical both to the security model as discussed with ARIN + staff in late 2006, so I believe we need this capability even as + part of the initial limited test. + + PRIORITY: Required + + depending on how much of the protocol and implementation I can steal + from the existing left-right protocol. + + STATUS: Started + +- ROA generation. We have a bunch of the primitives for this but we + aren't yet generating the ROAs themselves. + + For reasons that presumably made sense at the time, the left-right + protocol for route_origin objects allows ranges as well as prefixes, + and the SQL for stores everything as ranges, which is nice and + general...except that ROAs can only hold prefixes. So left-right + should only allow prefixes, and SQL should only store prefixes. + + Initial pass at ROA generation is done, not usable yet: ROA + maintenance (after initial generation) not done, and the current CRL + mechanism needs revision as it's too closely tied to child_cert + objects. Need to rewrite with a separate CRL table hanging off the + ca_detail object, then clean up excess baggage that currently hangs + off the child_cert object. + + PRIORITY: Required + + STATUS: Started + +- rcynic does not yet handle manifests. This is both a real problem + (manifests were added to plug a security hole) and a user acceptance + problem (without manifest support rcynic checks old certs that are + supposed to fail because they've been revoked, resulting in what + appear to be spurious errors, which just annoy the user). + + PRIORITY: Required + + STATUS: Not started + - Scripted tests to grow and shrink and revoke and .... See testbed.*.yaml, but more systematic testing needed. PRIORITY: Required - TIME REQUIRED: open-ended - STATUS: Ongoing - Randy's "user validation tool" (fetch and validate certs and @@ -91,8 +166,6 @@ TO DO: DEPENDS ON: ROA generation - TIME REQUIRED: three days - STATUS: Not started - Common protocol dump format with APNIC and other implementors so we @@ -103,8 +176,6 @@ TO DO: PRIORITY: Desirable - TIME REQUIRED: one day - STATUS: Not started - Clean unused cruft out of left-right protocol, or at least have @@ -117,37 +188,8 @@ TO DO: PRIORITY: Required - TIME REQUIRED: Less than one day - STATUS: Error signalling done -- Publication protocol and implementation thereof. Protocol design - started, Randy had comments that sent me back to the drawing board - (he was right). Next step is to integrate Randy's advice, which - probably means picking up more of the left-right protocol framework. - - Desirable although not strictly required that protcol be agreed upon - among the RIRs. Might not be practical given how long it takes - group to decide anything. - - 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. - - ARIN can't host output of non-hosted RPKI engines without this, and - that's critical both to the security model as discussed with ARIN - staff in late 2006, so I believe we need this capability even as - part of the initial limited test. - - PRIORITY: Required - - TIME REQUIRED: 1-2 weeks for implementation once protocol settled, - depending on how much of the protocol and implementation I can steal - from the existing left-right protocol. - - STATUS: Started - - Subsetting (req_* attributes in up-down protocol) Minimal implementation would be to recognize this as correct @@ -159,10 +201,6 @@ TO DO: PRIORITY: Required - TIME REQUIRED (minimal version): One day - - TIME REQUIRED (real version): 1-2 weeks - STATUS: Not started - Error handling: make sure that exceptions map correctly to up-down @@ -174,8 +212,6 @@ TO DO: PRIORITY: Required - TIME REQUIRED: four days - DEPENDS ON: almost everything else, as almost any code change can raise new exceptions that we'd need to handle. @@ -192,13 +228,6 @@ TO DO: PRIORITY: Required - TIME REQUIRED (commit and rollback): Two weeks - - TIME REQUIRED (data integrity audit): Three days - - TIME REQUIRED (fix data integrity): Unknown, depends on code audit - and results of runtime testing. - DEPENDS ON: async tasking model, sort of -- could do it first, but tasking change will affect the exception handling that triggers rollback. @@ -215,10 +244,6 @@ TO DO: PRIORITY: Highly desirable - TIME REQUIRED (setup): One day to convert Tim's data to YAML - - TIME REQUIRED (testing): Unknown, depends on what we turn up - STATUS: Not started - Clean up rootd.py to be usable in a production system. Most urgent @@ -227,8 +252,6 @@ TO DO: PRIORITY: Highly desirable (not strictly needed for limited testing) - TIME REQUIRED: Two days - STATUS: Not started - Test framework, multiple self-instances per engine-instance (single @@ -238,8 +261,6 @@ TO DO: DEPENDS ON: async tasking model. - TIME REQUIRED: One week - STATUS: Not started - tlslite code seems flakey under heavy use, and doesn't support all @@ -256,99 +277,21 @@ TO DO: PRIORITY: Required (cert checking is a security issue). - TIME REQUIRED: Two weeks. - DEPENDS ON: Async tasking model. STATUS: Not started -- ROA generation. We have a bunch of the primitives for this but we - aren't yet generating the ROAs themselves. - - For reasons that presumably made sense at the time, the left-right - protocol for route_origin objects allows ranges as well as prefixes, - and the SQL for stores everything as ranges, which is nice and - general...except that ROAs can only hold prefixes. So left-right - should only allow prefixes, and SQL should only store prefixes. - - Initial pass at ROA generation is done, not usable yet: ROA - maintenance (after initial generation) not done, and the current CRL - mechanism needs revision as it's too closely tied to child_cert - objects. Need to rewrite with a separate CRL table hanging off the - ca_detail object, then clean up excess baggage that currently hangs - off the child_cert object. - - PRIORITY: Required - - TIME REQUIRED: Three days - - STATUS: Started - - Make rpkid fully event-driven (async tasking model), except for SQL queries. This probably involves the "twisted" framework. PRIORITY: Required (to implement hosting model) - TIME REQUIRED: one week. - - STATUS: Not started - -- Update biz trust anchor model to what we came up with in Amsterdam. - This was a direct result of security review by Kent and Housley. - - This has been waiting for work we hope RobK is doing. This is - probably not a lot of coding, probably a few extra cert fields in - the self object which we then need to toss into the - rpki.x509.X509_chain objects before verifying CMS or TLS, and - perhaps the existing TA fields in various objects become pairs of - certs instead of a single TA, but this is mostly just generalization - and reuse of existing code, no bold new adventures. - - Discussion in Philadelphia revealed that this is not yet a done - deal. Housley, RobK, and I all seem to be on the same page, and we - think that what we're proposing will make sense to APNIC once we - explain it properly, but overall we have not yet converged. - - PRIORITY: Required (security issue) - - TIME REQUIRED: One week. - STATUS: Not started - Performance testing STATUS: Not started -- rcynic handling of RPKI trust anchors needs updating. Discussions - over last N months of how RPKI trust anchors work, how we package - them, and how we roll them over. The last (TA rollover) is the - driver for this. - - APNIC has apparently moved on from their proposal to use CMS-signed - OpenSSL "PEM" format, they're now proposing a CMS-signed ASN.1 - SEQUENCE OF something. Precise details of APNIC's new model not yet - known. Need to do analysis to make sure this is adaquate for our - needs, if so just use it. This would involve minor changes to - rcynic. - - PRIORITY: Required (usability issue for relying parties) - - TIME REQUIRED: Three days. - - STATUS: Not started - -- rcynic does not yet handle manifests. This is both a real problem - (manifests were added to plug a security hole) and a user acceptance - problem (without manifest support rcynic checks old certs that are - supposed to fail because they've been revoked, resulting in what - appear to be spurious errors, which just annoy the user). - - PRIORITY: Required - - 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 of overview text to explain the workings of the code, @@ -357,8 +300,6 @@ TO DO: PRIORITY: Desirable - TIME REQUIRED: Two days - STATUS: Ongoing - Reorganize code (directory names, module names, which objects are in @@ -370,8 +311,6 @@ TO DO: STATUS: File renaming mostly done, other stuff not started - TIME REQUIRED: two days - PRIORITY: Highly desirable (to preserve programmers' and maintainers' sanity, if nothing else) @@ -381,8 +320,6 @@ TO DO: STATUS: Not started - TIME REQUIRED: Unknown - PRIORITY: Desirable. Am guessing ARIN does not require this for initial test @@ -391,16 +328,12 @@ TO DO: STATUS: Not started - TIME REQUIRED: Three days - PRIORITY: Desirable - Tighten up syntax checking in left-right schema. STATUS: Not started - TIME REQUIRED: Less than a day - PRIORITY: Desirable - Rethink exposing SQL primary indices in protocols. Right now, we @@ -418,7 +351,6 @@ TO DO: STATUS: Not started - TIME REQUIRED: Two or three days to evaluate. Implementation time if we decide to make a change unknown, but probably on the order of a few days. @@ -435,8 +367,6 @@ TO DO: PRIORITY: Minimal, IETF feeping creaturism - TIME REQUIRED: Unknown - - Deaddrop of incoming messages, for audit. Absent a better theory, steal existing tech for this: preface with minimal RFC 2822 header and drop it into a Maildir folder using built-in Python Maildir @@ -446,7 +376,6 @@ TO DO: Priority: Desirable, trivial to implement. - TIME REQUIRED: One day |