diff options
| -rw-r--r-- | scripts/README | 52 |
1 files changed, 46 insertions, 6 deletions
diff --git a/scripts/README b/scripts/README index f43ac9b8..c5485470 100644 --- a/scripts/README +++ b/scripts/README @@ -53,13 +53,13 @@ pure Python and only 2% about any kind of crypto. Current TO DO list: -- Client side of expiration: how do we decide when to ask for a new - cert from our parent? Tunable (preference, if so)? Waiting for - the old one to die is not good. Reissue automatically when IRDB - valid_until changes? +- Client side of expiration now assumes that parent will reissue when + its IRDB changes. Not yet tested. - Parent side of revocation (child_cert objects) and CRL generation - implemented but not yet tested. + implemented. Not yet tested. + +- Parent side of expiration implemented. Not yet tested. - Child side of revocation...Common Management Tasks page in the APNIC Wiki shows some states where revocation is triggered by the child @@ -82,7 +82,8 @@ Current TO DO list: until we can get rid of it entirely, or something like that. For that matter, how do we, as child, even find out that a cert has - been revoked? + been revoked? In the up-down protocol we just see a new cert, we + don't know what happened to the old one. Either: a) We asked to have it revoked, duh. @@ -93,6 +94,23 @@ Current TO DO list: the old cert is no good anymore. In either case we're done with the old cert once it's been revoked. + Since we don't find out about that directly, we're done with it when + the parent issues a new cert. + + This suggest that we don't need the client "revoked" state at all, + and the client "deprecated" state should only occur when there's + also a timer set to make it go away. + + Common Management Tasks has a delay between receipt of a new cert by + the child and that cert going active. Neither Randy nor I sees a + need for this delay, but if we need to implement it we do so using + the new cert's timer (ie, timer is on pending -> active transition), + so active -> deprecated transition for old cert happens as side + effect of activation of the new cert. + + Need logic to decide whether to revoke when timer goes off to remove + from deprecated state. Is the test just whether the cert that's + going away has the same key as the active cert? - Publication protocol and implementation thereof. Defer until core functionality in the main engine is done. @@ -109,6 +127,28 @@ Current TO DO list: - Withdrawal of any of the above + Currently some of the hooks are in the wrong places. + + There's a three-way tradeoff lurking here: + + 1) Consistancy issues for relying parties (eg, don't want to + withdraw something that's still listed in the manifest); + + 2) Efficiency issues for the RPKI engine (eg, generating a new + manifest for each individual change during a batch run could be + expensive, would prefer to batch up the changes into a single + manifest run); and + + 3) Coherency issues for the RPKI engine (don't want to defer things + that could result in loss of state if something bad happens). + + Considerations (1) and (3) have to dominate, which may mean we take + a hit on (2). + +- More dumb little methods missing: objects on the many side of a + one-to-many relationship should have convenience methods for + retrieving their parents. Too many explicit calls to sql_fetch(). + - Logging subsystem, including syslog support. - Child batch processing loop, eg, regeneration or removal of expired |