| | | | | | | | |
|
|
|
You're here: Home |
Rob Austein wrote:
[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.
We can always collapse two or more operations into one if we think they will always be used together.
I am not sure why I would ever call (4) without also calling (3), so I would probably make them a single operation.
Good point. I made them separate because they have different scopes (one deals with certificates issued by a CA, the other is an operation on the CA itself).
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.
It's true that it's close to the rerun-self. OTOH you'll need such an (RE internal) operation anyway if you want to make the transition to a the new CA key. And this operation fits another need (resissue on will) too.
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.
Immediate response can only be given if sneaker-net is not used. A callback takes time, and during that time the BE is in a limbo on whether the operation succeeded or not. But having said this, I don't think we can do better than these.
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.
That may be, but the problem still exists: the BE somehow needs to know if the rekey process has finished or not. Or would you like to keep this internal to the RE ("I heard you BE, I'm on it, will be done ASAP")?
Otherwise, at first it seems to me that this could be enough. Do you agree?Good start, anyway.
OK. The functionality is needed, and we can/have to refine the protocol. Robert
