FR-10 Manage Certificate Revocations

[danisoler-charin]

Description:
The system shall provide a mechanism for revoking or deleting certificates, and for distributing this revocation status to all ecosystem participants in a secure and timely manner.
Use Case:
A certificate is revoked or deleted due to compromise, expiration, or operational decision, and other parties must be made aware to avoid trusting or using it further.
Current Status
This requirement is flagged as possible in OPNC v1.0. Mechanisms for revocation are already included in: the PCP and the CCP
Additionally:
Each pool is expected to check validity of certificates when processing requests.

Comments / Open Points
Who performs the revocation?

• Typically the issuer (e.g., an OEM or EMSP) or a governance-approved entity.
• Some use cases (e.g., user request or system compromise) may require clarification on revocation authority.
  Are periodic validity checks enforced?
• This seems to rely on each pool querying or verifying certificates at runtime.
• The group may want to define recommended intervals or events triggering revalidation.
  Message improvements needed?
• Some suggested that the revocation/deletion message type could be made more specific, for example: Separate status codes for revokedByIssuer, deletedByUser, expired, etc.

Discussion Points

• Should OPNC define standard status values for certificate checks beyond Valid/Revoked/Expired?
• Should we define minimum expectations for how often or when pools should revalidate certs?
• Should there be logging or notification requirements when a revocation occurs?
• Could this be handled mostly through spec improvement and testing coverage, rather than code changes?

[danisoler-charin]

Update due to Aug 6th discussion:
Current understanding:

• OPNC includes a revocation service in the PKI API (added at the end of v1) alongside certificate enrollment.
• An actor (e.g. EMSP) can request revocation of a contract/provisioning certificate via the API, and the pool operator can process it.
• PCP and CCP already define revocation and deletion processes.

Main open point:

• Notification and awareness – while revocation can be performed, there is no clearly defined, standardised way for all other relevant pools to be informed promptly.
• Today, notification is pool-to-client and relies on each pool querying/checking certificate validity “at runtime” before responding to requests.
• This works, but it may be inefficient and risks some actors holding outdated validity data.

Questions raised:

• Who should be authorised to revoke? Typically the issuer or a governance-approved entity, but some use cases may differ.
• Should OPNC enforce runtime validity checks as part of the protocol?
• Could we define recommended intervals or triggering events for revocation checks (to avoid excessive polling while ensuring freshness)?
• How do we ensure cross-pool notification in a peer-to-peer scenario, especially if data has been shared between pools?

Conclusion:

• Keep the requirement open as “possible in OPNC v1.0, but process definition needed.”
• Tag all pool operators to provide input on how they currently manage revocation awareness and if a common mechanism should be standardised. @guillaumeFRANCOIS @steffenrhinow @thesimmermon