Re: Forcing RPKI revoke/rekey in left-right protocol

[Rob Austein <sra@hactrn.net>]

[More old mail]

At Wed, 18 Apr 2007 10:59:42 +0200, Róbert Kisteleki wrote:
> 
> [In the following I assume that we don't want data to flow from the RE 
> to the BE about CAs, classes and such.]

Right.

> My feeling is that the problem can be solved with a set of commands 
> (BE->RE), please check:
> 
> 
> 1. Ask for rekey on CAs tied to a parent
> (rekey-cas-from-parent :self-id 42
>                         :parent ripe)
> => ()
> 
> This is supposed to iterate through classes (CAs) from that parent, 
> generate new keys, and send them to be certified. After certification, 
> it activates the new key, but still keeps the old. From this point on, 
> all issuances should use the new key.
> :parent could be optional/unused, see above.
> 
> 2. Ask for reissuance of children with the latest CA key
> (reissue-children :self-id 42
>                    :parent ripe
>                    :child dexter)
> => ()
> 
> :parent could be optional/unused, see above.
> 
> :child can be optional (if specified, then only that child is reissued, 
> potentially only from a specific parent). I'd really, really like to 
> have such a message, since it solves another issue we had inside RIPE 
> (namely the potential to instruct the RE to issue a cert to a child, 
> whenever the BE feels like it).
> 
> 
> 3. Ask for revocation of certs issued by an "old key" (all old keys, if 
> there are more than one)
> (revoke-oldkey-certs :self-id 42
>                       :parent ripe)
> => ()
> This is essentially a preparation for shutting down an old key.
> :parent could be optional/unused, see above.
> 
> 
> 4. Drop old keys
> (drop-old-keys :self-id :42
>                 :parent ripe)
> => ()
> Get rid of old CA keys, potentially only for that :parent.
> This command may also trigger the previous one (3), just to be sure.
> :parent could be optional/unused, see above.

I'm not certain that we need all of these operations, but I think the
general approach here is reasonable, at least in terms of making
good use of the handles we have available.

I am not sure why I would ever call (4) without also calling (3), so I
would probably make them a single operation.

I'm not sure we need (2) but I see that you think RIPE does.  It's not
really in the rekey/revoke space, it's closer to the
(please-run-this-self-id-now) operation that we already have.

> I have one issue still: how is the BE supposed to know if the rekey 
> succeeded or not?

Rekey operation throws an error (immediate response) or calls an error
callback (asynchronous response), I would think.

> We may want to introduce a "current key generation" value associated
> with :self (or :self+:parent) that the BE keeps track of, so it
> knows if the RE has successfully rekeyed, thus child reissuance can
> begin.

This seems more complicated than necessary.

> Otherwise, at first it seems to me that this could be enough. Do you agree?

Good start, anyway.