Revocation of Persistently Non-functional Delegated RPKI CAs

Summary of proposal:

This proposal suggests providing a mandate to the RIPE NCC to revoke resource certificates associated with longtime non-functional CAs to reduce Relying Party workloads.

Abstract:

The RIPE NCC offers users of its RPKI certification service two deployment models: "Hosted CA setup" and "Delegated CA setup".

In the Hosted setup the RIPE NCC is responsible for timely issuance and publication of new RPKI Manifests and CRLs, but in the Delegated setup resource holders 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 providing a mandate to the 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 practice 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 three months). 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 the RIPE NCC is unable to discover and validate a Delegated RPKI Certification Authority's (CA's) current Manifest and Certification Revocation List (CRL) for more than three months, that Delegated CA's resource certificate shall be revoked by the RIPE NCC.

The RIPE NCC shall make reasonable efforts to discover new Manifests, to notify the Delegated CA operator if a current Manifest and CRL cannot be validated, and to notify the operator if the delegation is revoked.

Rationale:

a. Arguments supporting the proposal

Persistently Non-functional Delegated CAs have subtle adverse effects within the RPKI ecosystem which may become more pronounced over time.

• Non-functional CAs offer nothing of value to validators (without a current and valid Manifest, signed payloads are unavailable).
• Validator synchronisation becomes more economic with fewer purposeless publication points to traverse.
• Non-functional CAs besmirch RPKI validator syslog message archives and waste CPU cycles and network traffic.
• Revocation is only a minor inconvenience for non-functional CAs (the configuration already was broken for an extensive period of time), but a big deal for any Relying Party (RP) - especially when taking into account the many synchronisation attempts made over long periods of time.
• This policy doesn't affect many resource holders; there only is a small group of persistently non-functional CAs, some of which have been non-functional for more than 2 years already. An overview is available here: https://console.rpki-client.org/nonfunc.html

b. Arguments opposing the proposal

• Resource holders might require more than 3 months to complete the initial Delegated CA setup.
  
  [Counterpoint to the above: initial setup procedures usually only takes a few minutes. Resource holders of course are free to simply retry the delegated CA setup procedure following revocation. The goal of this policy is NOT to permanently bar resource holders from setting up Delegated CAs, but to curb persistently non-functional delegations. Aka, "come back when you are ready".]

Note: The RIPE NCC impact analysis below provides additional information related to the proposal. The projections presented in this analysis are based on existing data and should only be viewed as an indication of the possible impact the policy might have if the proposal is accepted and implemented.

A. RIPE NCC's Understanding of the Proposed Policy

It is the RIPE NCC’s understanding that this proposal, if accepted, will require the RIPE NCC to revoke the RPKI certificate for any Delegated Certification Authorities (CAs) that have not updated their manifest and/or Certification Revocation List (CRL) for longer than three months.

Because months do not have a constant length, the RIPE NCC will use 90 days as a threshold rather than three months.

From this, the RIPE NCC interprets that if the RIPE NCC is unable to discover and validate a Delegated CA's current Manifest and CRL for more than 90 days, that Delegated CA will be removed as a child, and its resource certificate will be revoked by the RIPE NCC parent CA.

While not required by the policy, it would be beneficial to send an automated email to inactive Delegated CA SSO accounts before taking these steps. This provides them with an opportunity to resolve issues before the CA is revoked.

Once a Delegated CA has been revoked, it can be recreated through the normal set up process in the RPKI Dashboard. There is no restriction preventing a previously removed Delegated CA from recreating their Certification Authority.

Finally, it is the RIPE NCC’s understanding that the revocation process as described above will not invalidate a Delegated CA’s RPKI objects and in particular ROAs. This is because the CRL and manifest in the publication point of the CA would have expired long before the 90 day period had passed.

B. Impact of Policy on Registry and Addressing System

• Address/Internet Number Resource Consumption:
  The RIPE NCC does not anticipate any impact on number resource consumption.
• Fragmentation/Aggregation:
  The RIPE NCC does not anticipate any impact on routing fragmentation and aggregation as this revocation does not result in invalidating any RPKI objects that are valid at the moment of revocation.

C. Impact of Policy on RIPE NCC Operations/Services

• Software Engineering:
  Software development will update our systems to:
  • Consider Delegated CAs out of scope if set up under the RIPE NCC, have not requested a certificate, and are invisible to RPKI RP software
  • Monitor Manifests and CRLs published by each Delegated CA on a daily basis, at least
  • Keep track of the most recent valid CRLs and Manifests found
  • If the RIPE NCC is unable to discover and validate a Delegated CA's current Manifest and CRL for more than 90 days, that Delegated CA will be removed as a child, and its resource certificate will be revoked by the RIPE NCC parent CA
  • Before removing the Delegated CA in this way, the RIPE NCC will send warning emails to known contacts of the Delegated CA
• Registration Services:
  The RIPE NCC anticipates a slightly higher number of requests from non-functional CA operators, asking for clarifications

D. Legal Impact of Policy

If this policy proposal is accepted, the RIPE NCC will be required to revoke certificates of certificate holders who chose the Delegated CA setup in cases where their manifest and CRL have not been updated for a period of longer than 90 days.

The RIPE NCC will need to update the RIPE NCC Certification Practice Statement (CPS) for the Resource Public Key Infrastructure (RPKI) and the relevant legal framework such as the RIPE NCC Certification Service Terms and Conditions in order to cover this case. Existing certificate holders will be notified of the amended legal-framework.

E. Implementation

With the information currently available, it is expected that the implementation of the proposal will have a medium impact in terms of software development needed to facilitate the policy changes in the RIPE NCC’s internal systems. Internal and external processes and documentation, including material for training and exams, would also need to be updated and approved internally for publication.