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

[Robert Kisteleki <robert@ripe.net>]

Rob Austein wrote:
> http://subvert-rpki.hactrn.net/docs/repository-engine-objects.pdf
> http://subvert-rpki.hactrn.net/docs/left-right-protocol
>
> Unfinished item that has me confused: how do we force a rekey (RPKI
> keys and certs, not business keys and certs) in the left-right
> protocol?  Sounds simple, but in the current model the IRBE doesn't
> know about individual CAs or keypairs, it only knows about <self>,
> <parent>, and <child> objects.

Out of these, a combination of <self> and <parent> looks appealing to 
me. As the IRBE does not know about individual resource classes received 
from a <parent>, this has the side effect that the rekey will apply to 
all CAs associated to the <parent> with no option to refer to a specific 
class (CA).

Alternatively, this could be <self>. The rationale behind this would be 
that one usually has a real reason for rekeying, like a suspected key 
compromise. In this case, you want to rekey all your CAs (parents), not 
just one. Therefore, there might not be a point in rekeying only one 
parent - you want to do all of them at once.

> The only thing I can think of at the moment is a set of operations to
> force rekey of whatever CAs are associated with a particular <child>
> (or <parent>? or <self>?).  This seems wrong, but I can't figure out a
> better way as long as we're constructing the CAs and keypairs on the
> fly to handle multiple classes signaled through the up-down protocol.

[In the following I assume that we don't want data to flow from the RE 
to the BE about CAs, classes and such.]

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 have one issue still: how is the BE supposed to know if the rekey 
succeeded or not? 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.

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


Robert


> Side question: does anybody remember why the object picture has a
> direct link from <self> to <ca>?  I'm guessing that it has to do with
> the RIR/IANA special case where there is no parent.