Dear Job, Thank you for your proposal on revoking non-functional Delegated RPKI CAs. I fully support the idea of introducing a lifecycle for this Delegate CA-s.
>From an operational perspective, there is a clear benefit in processing only valid RPKI data. As of today the RPKI validators software is already facing with a big volume of RPKI data that must be processed and validated, and it takes no less than 5-7 minutes to process the whole RPKI data set. Simply having a policy and revoking the above 30 broken MANIFEST entries will improve run times and performance of all validators in the world. The proposed 100-day threshold is a reasonable grace period to ensure that non-functional CAs will be treated as indeed non-functional and will not indefinitely remain in the system. On the other hand, operators should have the possibility to re-enable their CA-s if they wish to do so. Best regards, Fedor Am Di., 25. Feb. 2025 um 13:05 Uhr schrieb Job Snijders <[email protected]>: > Dear all, > > I'd like to propose a mechanism to automatically prune dead branches > in the RPKI directly subordinate to RIPE NCC. Below is the policy proposal > text that I have in mind. > > In short: RIPE NCC should revoke a Delegated CA's certificate when > absolutely > no "sign of life" (valid Manifest) has been observed for over a 100 days. > > It probably is good to have some discussion around: > > * should perpetually broken Delegated CA setups be culled at some point? > * is the continuous lack of a valid current manifest for a 100 day period > of time a good indicator for "Delegated CA brokenness"? > > Your feedback is most welcome! > > Kind regards, > > Job > > ------------------- > > Policy Proposal Name: > > Automatic Revocation of Persistently Non-functional Delegated RPKI > Certification Authorities > > Author: > a. name: Job Snijders > b. email: [email protected] > > Proposal Version: (to be assigned by the RIPE NCC) > > Submission Date: February 25th, 2025 > > Suggested RIPE WG for discussion and publication: RIPE Routing Working > Group > > Proposal Type: NEW > > Policy Term: Indefinite > > Summary of proposal: > > RIPE NCC offers users of its RPKI certification service two > deployment models: "Hosted CA setup" and "Delegated CA setup". > In the Hosted setup RIPE NCC is responsible for timely issuance > and publication of new RPKI Manifests and CRLs, but in the > Delegated setup users themselves manage their CA on their own > infrastructure. > > It is possible for Delegated CA infrastructure to be offline for > extended periods of time or for the contents of publication > repositories to become stale or otherwise invalid. This proposal > suggests to provide mandate to RIPE NCC to revoke resource > certificates associated with longtime non-functional CAs to > reduce Relying Party workload. > > This policy proposal targets only pathologically non-functional > CAs. An example of a situation considered out-of-scope for this > policy would be a publication repository service advertised to > also be available via IPv6 and RRDP but in practise only > reachable via IPv4 and Rsync: the associated CA would still be > considered functional (provided a valid and current Manifest > could somehow be retrieved and validated sometime in the > previous one hundred days). In other words: this policy proposal > isn't about CAs that didn't achieve 100% uptime, but about CAs > that are down all the time. > > Policy text: > > If RIPE NCC is unable to discover and validate a Delegated RPKI > Certification Authority's (CA's) current Manifest and CRL for > one hundred consecutive days, that Delegated CA's resource > certificate shall be revoked by the RIPE NCC. RIPE NCC shall > make reasonable efforts to discover new Manifests, for example, > by corroborating information from multiple vantage points. After > revocation, the Resource Holder may either reinitialize the > Delegated CA setup or choose the Hosted CA setup. > > Rationale: > a. Arguments supporting the proposal > > Persistently Non-functional Delegated CAs (PNDCs, for short) > have subtle effects within the RPKI ecosystem which may become > more pronounced over time. > > * PNDCs offer nothing of value to RPs (because without a current > valid Manifest any signed payloads are unavailable). > > * RP synchronisation becomes more economic with fewer > purposeless caRepositories to traverse. > > * PNDCs besmirch Relying Party (RP) syslog message archives and > waste RP CPU cycles and network traffic. > > * Automatic revocation is only a minor inconvenience for CAs > (that already were non-functional to begin with), but a big > deal for RPs - especially when taking into account many > future synchronisation attempts over long periods of time. > > b. Arguments opposing the proposal > > * Resource holders might require more than one hundred days to > complete the initial Delegated CA setup. > > (Counterpoints: initial setup procedures usually only takes a > few minutes. Resource holders are free to simply retry the > delegated CA setup procedure following automatic revocation.) > > Additional opposing arguments to be determined. > ----- > To unsubscribe from this mailing list or change your subscription options, > please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ > As we have migrated to Mailman 3, you will need to create an account with > the email matching your subscription before you can change your settings. > More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ >
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/routing-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
