Hi Tim, Alex, On Wed, Jun 05, 2024 at 11:28:28AM +0200, Tim Bruijnzeels wrote: > On 5 Jun 2024, at 10:33, Alex Band <[email protected]> wrote: >> Apologies for the delayed reply. Tim wanted to respond to this >> email, but then realised he was not subscribed to this list with >> his current email address.
No worries, thanks for this. >> On 30 May 2024, at 01:30, Tom Harrison via RPKI <[email protected]> >> wrote: >>> At APNIC, we are currently testing how Krill handles the expiry of >>> BPKI TA material (i.e. RFC 8183's parent_response.parent_bpki_ta >>> and repository_response.repository_bpki_ta CA certificates). It >>> appears that Krill will not accept either a parent_response or a >>> repository_response if the CA certificate in that response is >>> expired, which makes sense. However, if the CA certificate >>> expires later, it appears that Krill will continue to successfully >>> make use of the relevant service notwithstanding the expiry. >>> Assuming that's correct, is this behaviour that we can rely on >>> into the future, or is there a chance that this will change such >>> that the expiry of the CA certificate causes subsequent service >>> interactions to fail? > > Indeed, right or wrong, the TA certificate in the XML is validated > at the time of exchange to prove holdership of the private key > pertaining to listed public key, but from that point on the public > key is accepted for validation of the RFC 8181 / 6492 CMS EE > certificates. That's great, thanks for confirming. >>> Separately, it is not clear how a delegated CA operator should >>> update its repository details to account for the BPKI TA expiry >>> event. On calling "krillc repo configure" with updated >>> repository_response XML, Krill prints the error "CA '...' already >>> uses this repository". (The corresponding "krillc parents add" >>> update operation works as expected, though.) What does a >>> delegated CA operator need to do (if anything) to handle the >>> expiry of the repository_response BPKI TA? > > So, because the public key is still accepted there is no need to > update the repository_response BPKI TA. > > This being said, this is possible for w.r.t. the BPKI TA used by a > parent or a child and it would be good if the same would be true for > the repository. > > The reason that it is not supported is that there is a wrong > assumption in the code that updating the repository implies that a > different repository server is going to be used. And this triggers a > repository migration process that utilizes a key rollover to publish > all content under the new key in the new repository before removing > the content in (and relationship with) the old repository. > > Btw, I described that process here: > https://datatracker.ietf.org/doc/draft-timbru-sidrops-change-pubserver/ > > This is an expired individual submission - perhaps it would be good > to renew it and seek official standardization of the publication > server migration process as it’s something that is useful for > delegated CAs especially that want to change from using their > self-hosted RPKI repository to one that is provided by their RIR, or > vice versa (less recommended), or from one RIR to another. > > In any case, Krill could be modified to recognize that the intent is > not to migrate to another repository server, but instead update the > TA certificate, key, or service URI for the current server. But this > would be a fair amount of work and perhaps it would be better to > look into supporting planned key rollovers in a standard way for RFC > 6492/8181 first? We have had some discussions about that as well, > perhaps it’s time to follow up with a draft. Yep, I think that doing some work here to document/standardise provisioning/publication server transition operations would be useful. -Tom -- RPKI mailing list [email protected] https://lists.nlnetlabs.nl/mailman/listinfo/rpki
