> On 1 Nov 2014, at 8:06 am, Sandra Murphy <[email protected]> wrote: > > speaking as regular ol' member > > On Oct 30, 2014, at 11:59 AM, Geoff Huston <[email protected]> wrote: > >> >>> On 29 Oct 2014, at 10:17 am, John Curran <[email protected]> wrote: >>> >>> On Aug 11, 2014, at 11:58 AM, Tim Bruijnzeels <[email protected]> wrote: >>>> … > > To be honest, I get a bit confused as to whether we are considering the case > of planned transfer actions, or some unanticipated reduction in a > certificate's resources. > > If we're talking about the planned case, then: >> >> If I understand your note here, you are suggesting that the CA issues a new >> cert for the to-be-transferred resource and revokes and reissues the >> original "omnibus" cert to have all the resources minus the >> to-be-transferred resource. Yes? > > Or, as another idea, leave the original certificate in place but also issue > two certificates, one for the retained space, one for the transfer space. >
I'm sorry, but I don't understand how this ameliorates the issues in any way. Now lets assume that the two new certificates are indeed "new" and neither "overwrites the "original certificate (with all its subordinate certs). If that's the case then the CA now has to issue new subordinate certs using each of the new CA certificates - right? So will these subordinate certificates overwrite the existing subordinate certificates, or are they entirely new (new subject name, etc)? In the former case the problem of subordinate certificate overclaiming is still a possibility given that the CA cert used to issue these certificates is now missing the to-be-transferred resource, and in the latter case then each of these subordinate CAs has to in turn perform a full reissuance, which is a huge amount of ripple down work all the way to the end leaf points in the hierarchy. Or, to quote from the draft document itself which describes pretty much exactly the case you are informally describing above: It is possible for the common registry to issue a certificate to the "sending" registry with the reduced resource set at any time, but it should not revoke the previously issued certificate, nor overwrite this previously issued certificate in its repository publication point without specific coordination. Only when the common registry is assured that the top down certificate issuance process to the receiving registry CA chain has been completed can the common registry commence the revocation of the original certificate for the sending registry, However, it should not so until it is assured that the immediate subordinate registry CA in the path to the sending registry has issued a certificate with a reduced resource set, and so on. This implies that on the sending side the certificate issuance and revocation is a "bottom up" process. If this process is not carefully followed, then the risk is that some or all or the subordinate certificates of this common registry CA will be unable to be validated until the entire process of certificate issuance and revocation has been completed. While this sequenced process is intended to preserve validity of certificates in the RPKI, it is a complex, fragile and operationally cumbersome process.. The underlying consideration here is that the operational coordination of these certificate issuance and revocation actions to effect a smooth resource transfer across registries is mandated by the nature of the particular choice of certificate validation process described in [RFC6487]. regards, Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
