On 06/07/2010, at 11:42 PM, Tim Bruijnzeels wrote: > - Key roll-over algorithm > > Our software currently implements a specific way to do roll-overs. At > the time we implemented this it wasn't 100% clear to us how this > *should* be done, and indeed whether there should be some prescribed way > to do this. > > So, when we build this we thought that our implementation did not > conflict with any drafts (as known at that time). Having said that our > software can be changed if it turns out that it's wrong in general, or > just not in line with a prescribed way to approach this problem. > However, we are not likely to change anything as long as the prescribed > way to do this remains a moving target. > > I would like to submit to the wg how we currently implement these > roll-overs. This is not the only possible approach and maybe not the > best, but hopefully it's useful input when considering a draft. > > > 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 >
As far as I can tell this matches the procedure described in the res-certs document. > I guess the big assumptions here are: > a) It's okay that two keys share a publication directory. The manifest > for a key (using a strict filename pattern: keyhash.mnf*) tells you what > to expect for the specific key. > > *: we plan to change the extenstion .mnf to .mft as specified by the > latest repos draft later.. This was implemented before the draft > contained this recommendation.. > I share this understanding (thats its okay to have two manifests and two CRLs in the same repository publication point within the scope of this key rollover procedure). > b) It's okay for a key pair to *not* publish *all* valid objects issued > by it... This eliminates the need that the child certificate should have > a different publication point for the new key. Again, I share this understanding. The procedure described in the draft for key rollover allows the CA with the new key to issue and publish subordinate objects that have precisely the same publication point as the comparable subordinate object that was issued by the CA with the old key. This deliberate overwriting of the published object implies that the CA with the old key has, at this point, extant valid subordinate objects that are not published. > > So, consider this starting situation: > > rsync://repo/TA > CN=RTA,O=RIPE%20NCC,C=NL.cer <- Trust Anchor > CN=RTA,O=RIPE%20NCC,C=NL.crl > CN=RTA,O=RIPE%20NCC,C=NL.mnf > CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert > > rsync://repo/PARENT_CA > jfS24_B5Z9BWbbRSbBxRvGOYtbM.crl > jfS24_B5Z9BWbbRSbBxRvGOYtbM.mnf > xSDgrpWpxMdHx-9tHN7QKtlILFw.cer <- Child key1 cert > AIA -> jfs24...cer > CRL -> jfs24...crl > > rsync://repo/CHILD_CA > xSDgrpWpxMdHx-9tHN7QKtlILFw.crl > xSDgrpWpxMdHx-9tHN7QKtlILFw.mnf > ITg3GhNYIyZQ78D5Zt3sXJkmeLc.roa EE-AIA -> xSD..cer > EE-CRL -> xSD..crl > > Now we perform a key roll-over for the PARENT_CA. When this happens our > system triggers a new certificate request one level down for the > CHILD_CA. The repositories now look like this: > > rsync://repo/TA > CN=RTA,O=RIPE%20NCC,C=NL.cer <- Trust Anchor > CN=RTA,O=RIPE%20NCC,C=NL.crl > CN=RTA,O=RIPE%20NCC,C=NL.mnf > CN=jfS24_B5Z9BWbbRSbBxRvGOYtbM.cer <- Parent key1 cert > CN=FrN8YYiB-9CUT_B833qvigzedIc.cer <- Parent key2 cert > > So, our offline TA now certifies two keys for our production parent CA > > rsync://repo/PARENT_CA > jfS24_B5Z9BWbbRSbBxRvGOYtbM.crl <- Key1 crl > jfS24_B5Z9BWbbRSbBxRvGOYtbM.mnf <- Key1 manifest > FrN8YYiB-9CUT_B833qvigzedIc.crl <- Key2 crl > FrN8YYiB-9CUT_B833qvigzedIc.mnf <- Key2 manifest > xSDgrpWpxMdHx-9tHN7QKtlILFw.cer <- Child key1 cert > AIA -> FrN8..cer > CRL -> FrN8..crl > > These keys (certificates) use the same publication point. We have a CRL > and manifest for each key. Furthermore the Child-Key1.cer is re-issued > under the new 'active' key. It is now pointing to the new, 'active', > key's certificate and CRL. > > The old key no longer publishes any new objects. It just maintains a CRL > and manifest that contains just the CRL file so that it can still revoke > previously issued certificates should there ever be any reason. > > rsync://repo/CHILD_CA > xSDgrpWpxMdHx-9tHN7QKtlILFw.crl > xSDgrpWpxMdHx-9tHN7QKtlILFw.mnf > _jrinG02UFGiBXx1wgiQDJo0uww.roa EE-AIA -> xSD..cer > EE-CRL -> xSD..crl > > Upon receiving a new certificate a new ROA object is generated. Strictly > speaking this is not necessary, but currently our software is not doing > smart enough checks to determine this. It assumes that a new certificate > means more resources or a different validity time, so a new ROA object > is generated automatically. > > The old ROA object is no longer published, but it still validates for > people that downloaded it and use the AIA pointers to construct a > validation chain -- as our validator does. There was no reason to revoke > the old EE, and its parent certificate is updated to use the new chain. > > > One thing to note is that our implementation is using a fully hosted > model for the moment. So child CAs are _hosted_ and live in the same > environment as our production CA. That means that we can actually > trigger the child CA to request a new certificate, and perform triggered > effects for itself like re-issuing a ROA object, when the parent has its > new key 'activated'. > > 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 the procedure described in the res-cert draft relating to key rollover - i.e. the entity can complete a key rollover without having to await child entities undertaking a reissuance request against the CA with the new CA. > > B) The old key remains active for *this* child CA, until it requests on > its own initiative. When it does the new key becomes active for this > child as well. And the system keeps track of this internally.. One issue here is that in such a case the old key is kept active for an indeterminate period. If this old key has been compromised, then is it really appropriate to keep this key in an active state? If the CA wants to retire the old key, why should it be held up awaiting an action by the child that may not occur for weeks, months,...? > > I think option B is the more elegant of the two in that this offers the > least surprises to the child. On the other hand option A has a possible > use case for un-planned roll-overs. It allows for a re-key followed by > revocation of the old production key. In principle this should not > affect the child unless the child is using its old certificate out of band. > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
