What Is a Certificate Revocation List?

Certificate Revocation List (CRL) is one of two commonly used methods to access the server using a public key structure in the network.

With the rapid development of the Internet, especially e-commerce and e-government, how to effectively protect the confidentiality, integrity, authenticity and undeniability of information in an open network environment has attracted much attention. Public Key Infrastructure (PKI) is recognized as an effective solution to solve information security problems in large network environments. PKI is a standard-compliant key management platform. It can transparently provide the key and certificate management necessary for the use of cryptographic services such as encryption and digital signatures to achieve and manage trust relationships between different entities. Certificate revocation information distribution is a key operation in PKI, and it is also a major challenge for PKI. A report provided by MITRE pointed out that the distribution of certificate revocation information is the most costly part of operating a large PKI system. Since then, many certificate revocation information distribution mechanisms have been proposed. The X.509 standard adopts two types based on Certificate Revocation List (CRL) and based on Online Certificate Status Protocol (OCSP).

In the Compact CRL solution, on the one hand, some options of the CRL that are not commonly used in the actual operation of the PKI are filtered; on the other hand, the CRL revocation certificate entry fields are re-encoded, and the status of each digital certificate issued by the CA corresponds to the CRL. A bit of the certificate entry is revoked. This greatly reduces the size of the CRL and saves the bandwidth required for certificate revocation information distribution ^[1]

As with all kinds of identity documents in daily life, digital certificates may become invalid before their expiration, which may be due to loss of key media or change of user identity. The CA needs to process the revocation of such certificates in a timely manner and put the revocation certificate in the CRL for publication so that users can check the validity of the certificate. When a user receives a digital certificate, he must check whether the digital certificate has been revoked or suspended. The frequency of certificate revocation information update and release is very important. If a certificate has been revoked and users continue to use it, it will cause great security risks. The interval between the two certificate revocation information releases is called the revocation delay, and the revocation delay is specified in the certificate policy. There are two main methods for certificate revocation information distribution: one method is to use periodic release mechanisms, such as CRL, segmentation, and CRLDeltaCRL, etc .; the other method does not involve CRLs, such as OCSP and chain hash methods ^[1] .

CRL Certificate revocation list CRL

A CRL is a time stamped list of all digital certificate information that has been revoked or suspended. The CRL contains two fields: the current update date and the next update date. The user can use these two date information to determine whether the currently owned CRL is the latest and manage the CRL buffer (that is, before the next CRL update, the user can (Always use the original CRL buffer). Because the CRL contains the digital signature of the CA, the CRL can be stored at any node on the network.

In the CRL scheme, the updated CRL is regularly published to the LDAP directory server so that the relying party can learn the current status of the certificate. The relying party judges whether the certificate is valid or revoked based on whether the CRL contains a certificate to be verified. ). This process is divided into 3 steps:

• Get the corresponding CRL

• Verify that the digital signature of the CA on the CRL is valid

• Check whether the certificate to be verified is in the CRL.

In the case of a small network and a low certificate revocation rate, CRL is a simple and effective method. However, the CRL method has the following inherent disadvantages:

• First of all, since the certificate revocation information must exist throughout the life cycle of the certificate, the size of the CRL will become very large with the increase of the certificate revocation information. If the relying party needs to verify a certain certificate, it must download the entire CRL to the CA directory server, which will cause a lot of network resources consumption, increase the burden on the server, and may cause network congestion and prevent customers from obtaining CRL information;

• Secondly, because the CRL is announced by the CA cycle, the revocation delay will inevitably bring losses to the user. It is always contradictory to reduce the revocation delay and reduce the occupied bandwidth, which leads to CRL (unreliable and cannot reflect the certificate revocation information in time) And server performance bottlenecks Each time a certificate on the certificate chain is verified, the corresponding CRL must be downloaded).

• Furthermore, because the CRL is too large, the relying party is inefficient in finding the certificate revocation status information in the CRL. In order to make up for the shortcomings of CRL, improved methods have been proposed to limit the size of CRL or increase the efficiency of CRL checking, such as the DeltaCRL method and the segmented CRL method.

DeltaCRL Certificate Revocation List DeltaCRL

The basic idea of DeltaCRL is that it does not need to generate a complete and potentially larger CRL each time a certificate is revoked. A base CRL (baseCRL) contains all the certificate information that has been revoked in a certain period ( T). , And issue a DeltaCRL at a short time interval ( t), which includes only the revocation certificate information added since the release of the benchmark CRL. Therefore, the size of DeltaCRL is much smaller than the benchmark CRL, so that the release frequency of DeltaCRL can be much higher than the benchmark CRL, which increases the timeliness of certificate revocation information release. The DeltaCRL method reduces large CRLs and reduces the average bandwidth consumed. However, if a relying party is to verify a digital certificate, it must check the benchmark CRL in the most recent period and all DeltaCRLs since the benchmark CRL was issued. Once a DeltaCRL is lost, the relying party needs to resynchronize with the server to update its CRL cache. And the size of DeltaCRL also changes with the number of digital certificates revoked in t time. DeltaCRL cannot reduce the peak bandwidth.

CRL Certificate Revocation List Segment CRL

In order to control the size of the CRL, the method of dividing the revocation certificate information issued by the CA into several CRL segments for distribution is called a segmented CRL method. The segmentation strategy can be based on different factors, such as the range of the certificate serial number, the reason for certificate revocation, the type of certificate, etc. The segmented CRL method is usually combined with the CRL issuing point extension option of digital certificates. Compared with the CRL method, the segmented CRL method has two advantages: first, the revocation certificate information can be divided into several controllable fragments to avoid the growth of a large CRL; second, the CRL issuing point extension option in the digital certificate can determine the Where the revocation information for digital certificates is stored. However, the size of the segmented CRL also changes, and the peak request rate of the CRL is not affected by the number of CRL segments, and the average request rate increases with the increase of the number of segments.

OCSP Certificate revocation list OCSP

In OCSP, the certification of certificate revocation information is entrusted to the OCSP responder. The certification of certificate revocation information is not directly guaranteed by the digital signature of the CA, but is generated by the CA and / or the OCSP responder trusted by the relying party. Signature to guarantee. The CA issues a CRL (by CA) digital signature to the internal database of the OCSP responder. When the relying party needs to verify the status of the certificate, it submits the query service request information (OCSPRequest) to the OCSP responder, and the OCSP responder queries its internal CRL database. , And then digitally sign the current latest certificate status information (OCSPResponse) and send it to the relying party. The disadvantage of the OCSP method is that the OCSP responder must be trusted, and because the OCSP response must be digitally signed to ensure integrity, it will have a certain impact on performance and even cause a denial of service attack.

New distribution of certificate revocation lists

Figure

Shows a CRL file structure for X.509CRLV1. The CRL file includes a general section and a certificate revocation list section. The general part consists of the version number of the encoded CRL, the distinguished name of the issuer of the CRL, the effective date, the next update time, and the digital signature algorithm identifier. The certificate revocation list part consists of the serial number of the revoked digital certificate and the revocation date. In X.509CRLV2, the revocation list section can also include some extended options, such as certificate revocation reason codes, pending instruction codes, expiration dates, and certificate issuers. In addition, several CRL extensions are defined on the basis of each CRL, such as agency key identifiers, issuer aliases, CRL numbers, DeltaCRL indicators, and issuing distribution points. In the CRL, the space required for the certificate revocation list is directly proportional to the number of certificate revocations. As the number of revocation certificates increases, the size of the entire CRL file depends entirely on the size of the certificate revocation list section. In X.509CRLV1, a revocation certificate entry requires 30B of space (where 16B describes the certificate serial number and 14B describes the revocation date). For large PKI systems, the CRL file can become quite large, for example, a CRL file with 100,000 revoked certificates can be as high as 24MB. For a relying party with a bandwidth of only 33.6 kbps, it takes at least 12 minutes to download the entire CRL file.

In order to reduce the size of the CRL, a new certificate revocation scheme, Compact CRL, is proposed.

. Since the relying party generally checks whether the digital certificate is currently revoked when checking the CRL, it does not care about the revocation date of the digital certificate. For this reason, in the Compact CRL, the revoked digital certificate entry only includes the serial number of the revoked certificate, and no longer contains the digital certificate revocation date. At the same time, the serial number of the revoked digital certificate is re-encoded. Instead of simply adding the serial number of the digital certificate to be revoked to the CRL, a bit sequence is used to indicate the revocation status of each digital certificate issued by the CA. Each bit in the bit sequence represents the revocation status of a digital certificate. If the bit is 1, then the digital certificate of the corresponding serial number is revoked. If the bit is 0, the digital certificate of the corresponding serial number is not revoked. . In this way, X.509CRLV1 needs 30B to describe a revoked digital certificate entry. In the Compact CRL1 scheme, only one bit is required to indicate the revocation status of a digital certificate, which greatly reduces the size of the CRL.