[RPKI] BPKI TA expiry handling

[Tom Harrison]

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 <alex at nlnetlabs.nl> 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 <rpki at lists.nlnetlabs.nl> 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