Description
The Certificate Revocation List (CRL) is a fundamental component of the Public Key Infrastructure (PKI) employed within 3GPP systems for security management. It functions as a digitally signed list, issued by a Certification Authority (CA), enumerating the serial numbers of certificates that have been revoked and are no longer considered valid. The list includes the revocation date and often the reason for revocation (e.g., key compromise, CA compromise, affiliation changed, cessation of operation, certificate hold). The CRL's signature ensures its authenticity and integrity, allowing relying parties to trust its contents.
In the 3GPP architecture, CRLs are utilized by various network functions and user equipment (UE) to perform certificate validation during security procedures. For instance, when a UE authenticates to the network via the Authentication and Key Agreement (AKA) framework enhanced with certificate-based methods, or when network functions mutually authenticate each other (e.g., in SBA - Service-Based Architecture), the presented certificates must be validated. This validation process involves checking the certificate's signature chain, validity period, and its revocation status by consulting the relevant CRL. The CRL can be distributed via specific protocols or fetched from a pre-configured distribution point (CRL Distribution Point - CDP) often embedded within the certificate itself.
The management and distribution of CRLs involve several key entities: the Certification Authority (CA) that issues and signs the CRL, the Repository that stores and disseminates the CRL, and the Relying Party (e.g., UE, AMF, SMF) that retrieves and processes it. The process works by the CA periodically generating and publishing updated CRLs. Relying parties must then obtain these updates, typically over HTTP/LDAP protocols, to maintain an up-to-date view of the revocation status. The frequency of CRL issuance (the CRL issuance period) is a critical parameter balancing security freshness against network load and client processing. A relying party caches a CRL until its "nextUpdate" time, after which it must fetch a newer version to ensure continued accurate validation.
CRLs play a vital role in the overall security posture of 3GPP networks by enabling the timely invalidation of credentials that should no longer be trusted. This is essential for mitigating risks associated with stolen private keys, compromised network functions, or mis-issued certificates. Without an effective revocation mechanism like CRL, even expired certificates or those associated with breached entities could potentially be used in attacks, undermining the trust model of the entire PKI. Therefore, CRL validation is an integral step in certificate path validation procedures specified in 3GPP security specifications.
Purpose & Motivation
The CRL technology exists to address the critical problem of credential invalidation within a Public Key Infrastructure (PKI). Digital certificates, which bind an entity's identity to a public key, have a long validity period (often months or years). If a corresponding private key is compromised, the entity is no longer authorized, or the certificate was issued in error, it is imperative to invalidate that certificate immediately rather than waiting for its natural expiration. The CRL provides a standardized, scalable method to disseminate this revocation information to all relying parties across the network.
Historically, without a revocation mechanism, once a certificate was issued, it remained technically valid until its expiry date, creating a significant security window of vulnerability. The creation of CRLs was motivated by the need to close this window and provide a means for a Certification Authority to assert which certificates are no longer trustworthy. In 3GPP networks, as services evolved from 4G to 5G and adopted more cloud-native, service-based architectures with increased use of certificate-based authentication (e.g., for network function service communication, IoT device onboarding), the reliable and efficient management of certificate lifecycles, including revocation, became even more paramount.
The CRL solves the limitations of previous ad-hoc or non-existent revocation methods by providing an authenticated, periodically updated list. It addresses the challenge of scale by allowing distribution via standard web protocols. While alternative mechanisms like the Online Certificate Status Protocol (OCSP) offer real-time checks, CRLs remain a fundamental, widely supported, and sometimes preferred method due to their simplicity, ability to work offline once cached, and suitability for environments where constant online queries are not feasible or desired, forming a cornerstone of 3GPP's certificate validation framework.
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (24 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-16.
In Release 16, the updates to the Certificate Revocation List (CRL) function primarily involved refining the certificate profile for Service-Based Architecture (SBA) Network Functions. Specifically, the NF instance identifier within the SBA certificate profile was made mandatory to support proper identification, and corrections were applied to the format of the `apiRoot` field within the NF certificate profile. These changes were part of a broader effort to update the overall certificate and CRL profile for the architecture.
In Release 17, the enhancements to the CRL function primarily involved corrections and clarifications to specific Network Function certificate profiles, including for the SCP and SEPP, and the formal referencing of GSMA profiles for interdomain certificates. The release also introduced a dedicated X.509 Certificate Extension for identifying 5G Network Function Types and removed the keyEncipherment KeyUsage from Service-Based Architecture certificates. These updates provided more precise guidance for certificate handling and validation within the 5G core network's security framework.
- [5GMS3, TEI17] Correction of Server Certificate handling TS 26.512CR0060
- Correct NF certificate profile TS 33.310CR0143
- Correction of the format of the URN string in the NF certificate profile TS 33.310CR0126
- Clarification on CN-ID when it is presented in the certificate TS 33.310CR0128
- Clarification on the format of callback URI in the NF certificate profile TS 33.310CR0132
- Clarification on the certificate profile for SCP TS 33.310CR0134
+ 5 more changes
In Release 18, the CRL function saw updates focused on refining certificate management procedures for 5GC Network Functions (NFs) and the Service-Based Architecture (SBA). Specifically, enhancements were made to the validation of X.509 certificate usage and to the inter-domain certificate profiles for the Security Edge Protection Proxy (SEPP). Additionally, corrections and clarifications were provided for SBA TLS certificates and the UUID examples within them.
In Release 19, the CRL function was enhanced with updates to the SBA certificate profile and a correction to the validation procedure for the usage of X.509 certificates. The release also introduced support for an Automatic Certificate Management Environment (ACME) for the Service Based Architecture and automated the addition of root CA certificates using CMP.
- Automated additions of root CAs certificates using CMP TS 33.310CR0198
- Automatic Certificate Management Environment (ACME) for the Service Based Architecture (SBA) TS 33.310CR0215
- Correction to validation of usage of X.509 certificate procedure TS 33.310CR0202
- Updates to the SBA certificate profile TS 33.310CR0204
Explore further
Broader topics and technologies where CRL plays a role.
Defining Specifications
3GPP specifications that define or reference CRL, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.057 vj00 | Mobile Execution Environment (MExE) Specification | Rel-19 |
| TS 26.512 vj10 | 5G Media Streaming Protocols & APIs | Rel-19 |
| TS 32.808 v1800 | Common User Profile Storage Framework | Rel-8 |
| TS 33.310 vj50 | 3GPP Authentication Framework for Network Nodes | Rel-19 |
| TS 33.320 vj00 | H(e)NB Subsystem Security Architecture | Rel-19 |
| TS 33.401 vj10 | EPS Security Architecture | Rel-19 |
| TR 33.876 vi01 | Technical Report on Certificate Management | Rel-18 |
| TS 33.885 ve10 | Security Study for V2X Services | Rel-14 |