[Reviewing old list mail en route to Maastricht, I see a few I should have answered, this is one of them]
At Tue, 06 Jul 2010 15:42:10 +0200, Tim Bruijnzeels wrote: ... > Currently our software implements key roll-overs using the following > approach: > - it uses stable publication directory for a 'logical CA' > - a 'logical' CA publishes CRLs and manifests for *each* of its keys > - but it only publishes child objects for the 'active' key > - old keys only publish a CRL and a manifest containing just this CRL > - child certificates have a stable URI based on their public key This is essentially the same approach that I took. > We do plan to implement support for remote child CAs using the up-down > protocol in the near future. And when we do we will no longer be able to > trigger a re-issuance request for the child CA. I see two possible > approaches: > > A) The parent CA re-issues anyway based on the last known request > without informing the child CA -- there is no way to tell the child > using up-down. This is what I do -- reissue with the same child key as the previous child certificate. The child will find out about that its certificate has been reissued the next time it polls its parent. The child has to expect the possibility of this sort of thing anyway, as there are other reasons why the parent might unilaterally reissue, eg, the child's resources might shrink, in which case the parent pretty much has to revoke the old (now overclaiming) child certificate, which in turn means that the parent has to issue a new child certificate unless it wants to leave the child dead in the water. Waiting for the child to get around to asking the parent for a new certificate that shrinks the child's resources sounds like a (very) bad plan, so this pretty much has to be a unilateral action on the part of the parent. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
