Hi! > On 5 Jun 2024, at 10:33, Alex Band <[email protected]> wrote: > > Hi Tom, > > 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.
Indeed, for a while my old email address forwarded here so I did not notice. > > I’m including the list to keep the thread and context intact. > > Cheers, > > Alex > >> On 30 May 2024, at 01:30, Tom Harrison via RPKI <[email protected]> >> wrote: >> >> Hi, >> >> 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. >> 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. Tim >> >> -Tom >> -- >> RPKI mailing list >> [email protected] >> https://lists.nlnetlabs.nl/mailman/listinfo/rpki > -- RPKI mailing list [email protected] https://lists.nlnetlabs.nl/mailman/listinfo/rpki
