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: job@sobornost.net

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/