WO2023023959A1

WO2023023959A1 - Digital certificate revocation

Info

Publication number: WO2023023959A1
Application number: PCT/CN2021/114401
Authority: WO
Inventors: Qiming Li; Sandeep TAMRAKAR; Gang LIAN; Chibin LIU; Tailiang Hong
Original assignee: Huawei Technologies Co.,Ltd.
Priority date: 2021-08-24
Filing date: 2021-08-24
Publication date: 2023-03-02

Abstract

A method and system for managing certificates in a public key infrastructure (PKI) are provided. The method comprises, at a first entity in the PKI: partitioning a set of certificates into a plurality of subsets generating, for each subset of the plurality of subsets, a certificate revocation list comprising a list of revoked certificates in the respective subset, receiving notification that a certificate has been revoked by a certificate authority in the PKI, identifying a subset containing the revoked certificate from the plurality of subsets and updating the certificate revocation list for the subset.

Description

DIGITAL CERTIFICATE REVOCATION

TECHNICAL FIELD

The present disclosure relates to methods and systems for managing certificates in a public key infrastructure (PKI) .

BACKGROUND

Digital certificates are used in Public Key Infrastructure (PKI) to support user authentication, network or server authentication, transaction signing digital rights management and a variety of other use cases. Each certificate carries a proof that the issuing party, such as a Certificate Authority (CA) , vouches for the identity or the authenticity of another entity, such as another CA, a computing device, or an end user. Each party generates a key pair comprising a public and private key and each certificate contains the public key of the entity being certified. The certificate is cryptographically signed by the private key of the issuer.

Certificates may have an expiry date after which time the certificate is no longer valid. In some cases certificates may be revoked before their expiry date. This may be due to a security breach such as a cryptographic key leakage. In other cases certificates are revoked due to membership changes, identity changes or other changes that affect the validity of the certificate.

SUMMARY

It is an object of the invention to provide a method for managing certificates in a public key infrastructure.

The foregoing and other objects are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to a first aspect, a method for managing certificates in a public key infrastructure (PKI) is provided. The method comprises, at a first entity in the PKI: partitioning a set of certificates into a plurality of subsets, generating, for each subset of the plurality of subsets, a certificate revocation list comprising a list of revoked certificates in the respective subset, receiving notification that a certificate has been revoked by a certificate authority in the PKI, identifying a subset containing the revoked certificate from the plurality of subsets and updating the certificate revocation list for the subset.

The method according to the first aspect provides a method for generating and maintaining revocation lists of certificates in a PKI. This method may be used in conjunction with other methods described to provide anonymous and efficient querying of the revocation statuses of certificates.

In a first implementation form of the method according to the first aspect, partitioning the set of certificates into a plurality of subsets comprises partitioning the set of certificates based on identification data associated to each certificate.

In a second implementation form the identification data comprises a first portion and a second portion and the first portion is common to all of the certificates in a subset.

In a third implementation form, respective first portions of the identification data comprise a sub-portion identifying the certificate authority that issued the respective certificate.

In a fourth implementation form for each certificate in a subset of certificates, the respective second portion of the identification data identifies the certificate from other certificates in the subset.

In a fifth implementation form the method comprises encoding the revocation status of the certificates of a subset as a vector of data values.

In a sixth implementation form respective second portions of the identification data of each certificate is used as an index for respective entries of the vector, and wherein respective entries of the vector encode a revocation status of the certificate with the corresponding index.

In a seventh implementation form each data value of the vector comprises a binary value.

In an eighth implementation form the method comprises applying a lossless compression algorithm to the vector.

The method according to the fifth, sixth, seventh and eight implementation forms enable responses to revocation status queries to be small.

According to a second aspect a method is provided. The method comprises receiving, at a first entity in a public key infrastructure (PKI) , a certificate from a second entity in the PKI, extracting a first portion of identification data from the certificate, the identification data comprising a first portion and a second portion, the first portion identifying a subset in a collection of subsets of certificates, the subset containing the certificate, communicating the first portion to a third entity in the PKI, receiving, in response to communication the first portion to the third entity, a certificate revocation list for the subset and determining the revocation status of the certificate on the basis of the revocation list.

The method according to the second aspect provides a method for efficiently querying the revocation status of a certificate in a PKI in an anonymous manner using a single query.

According to a third aspect a computing system is provided. The computing system comprises a processor and a memory coupled to the processor. The memory stores instructions that when implemented by the processor, cause the processor to partition a set of certificates of a public key infrastructure (PKI) into a plurality of subsets, generate, for each subset of the plurality of subsets, a certificate revocation list comprising a list that identifies revoked certificates in the respective subset, receive notification that a certificate has been revoked by a certificate authority in the PKI, identify the subset containing the revoked certificate in the plurality of subsets and update the certificate revocation list of the subset.

These and other aspects of the invention will be apparent from and the embodiment (s) described below.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

Figure 1 is a simplified schematic diagram showing a digital certificate, according to an example.

Figure 2 is a simplified schematic diagram showing a hierarchy of certificate authorities, according to an example.

Figure 3 is a simplified schematic diagram certificate groups, according to an example.

Figure 4 is a simplified schematic diagram showing identification data of a digital certificate, according to an example.

Figure 5 is a simplified schematic diagram showing a workflow for managing certificate revocation lists, according to an example.

Figure 6 is a simplified schematic diagram showing a certificate revocation hierarchy, according to an example.

Figure 7 shows a block diagram of a method for managing digital certificates, according to an example.

Figure 8 shows a simplified schematic diagram of a computer system, according to an example.

DETAILED DESCRIPTION

Example embodiments are described below in sufficient detail to enable those of ordinary skill in the art to embody and implement the systems and processes herein described. It is important to understand that embodiments can be provided in many alternate forms and should not be construed as limited to the examples set forth herein.

Accordingly, while embodiments can be modified in various ways and take on various alternative forms, specific embodiments thereof are shown in the drawings and described in detail below as examples. There is no intent to limit to the particular forms disclosed. On the contrary, all modifications, equivalents, and alternatives falling within the scope of the appended claims should be included. Elements of the example embodiments are consistently denoted by the same reference numerals throughout the drawings and detailed description where appropriate.

The terminology used herein to describe embodiments is not intended to limit the scope. The articles “a, ” “an, ” and “the” are singular in that they have a single referent, however the use of the singular form in the present document should not preclude the presence of more than one referent. In other words, elements referred to in the singular can number one or more, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises, ” “comprising, ” “includes, ” and/or “including, ” when used herein, specify the presence of stated features, items, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, items, steps, operations, elements, components, and/or groups thereof.

Unless otherwise defined, all terms (including technical and scientific terms) used herein are to be interpreted as is customary in the art. It will be further understood that terms in common usage should also be interpreted as is customary in the relevant art and not in an idealized or overly formal sense unless expressly so defined herein.

Figure 1 is a simplified schematic diagram of a digital certificate 100, according to an example. The digital certificate 100 shown in Figure 1 is an example of a certificate chain.

The certificate chain comprises a first certificate 110 which is a self-signed certificate issued by Root Certificate Authority (CA) .

The chain further comprises a second certificate 120 and a third certificate 130 which are intermediate certificates that vouch for the identities of intermediate CAs. The second certificate 120 is issued and signed by the Root CA and vouches for the identity of a first intermediate CA also referred to herein as a ‘level 1’ CA. The third certificate 130 is issued and signed by the first intermediate CA and vouches for the identity of a second intermediate CA, also referred to herein as a ‘level 2’ CA. A fourth certificate 140 is issued and signed by the second intermediate CA and vouches for the identity of an entity such as an end user, device or another CA. The fourth certificate 140 may be referred to as an entity certificate.

A receiver of the digital certificate 100 is able to verify the identity of the entity associated to certificate 140 as well as all the intermediate CAs by validating the certificates. The digital certificate 100 shown in Figure 1 is an example of a certificate chain and other certificate chains may comprise more or less intermediate certificates.

Figure 2 is a simplified schematic diagram showing a hierarchy of CAs 200, according to an example. In Figure 2 the Root CA 210 may generate and self-sign a certificate vouching for their own identity. The hierarchy 200 comprises two level 1

CAs

220, 230. The identities of each of the level one

CAs

220, 230 is vouched for by the Root CA which issues and signs certificates for each of

CAs

220, 230. The next level comprises two level 2

CAs

240, 250. The level 1 CA 220 issues and signs certificates for each of the level 2

CAs

240, 250. The lowest level of the hierarchy 200 comprises two

entities

260, 270. The identity of each of the

entities

260, 270 is vouched for by the level 2 CA 250, which issues and signs certificates for the

entities

260, 270. The resulting certificate chain for each of

entities

260, 270 is similar to the example 100 shown in Figure 1.

In some cases a certificate issued by a CA will remain valid for a time period. After this time period has elapsed the certificate may no longer be used to verify the identity of the associated entity. In some cases certificates may be revoked before the period of validity has expired. There are multiple reasons why a certificate may be revoked. For example, revocation may be occasioned by a change of identity or membership to a particular group. In other cases a certificate may be revoked due to a security issue such as leakage of a private key.

According to examples a certificate may contain information that enables the revocation status of the certificate to be determined. For example, in some cases a Certificate Revocation List (CRL) may be provided with the certificate. The CRL may comprise a list of certificates that have not expired but which have been revoked. Each revoked certificate in the CRL is identified by its serial number with a timestamp that identifies the time of revocation. The CRL may also specify the time at which the list is issued, and the time the next update will be issued. The CRL may also be signed by a trusted issuer, such as a CA. When an entity wishes to verify a certificate, they may retrieve the latest CRL from a CRL distribution point to determine whether the certificate has been revoked.

CRLs they may be unsuitable for certain applications and scenarios. For example, in Internet-of-Things (IoT) settings the number of devices is typically very large. If a certificate is issued for each IoT device, the size of a CRL may grow too large to be handled in any practical way. Other methods and protocols for certificate revocation status querying have similar issues and, in some cases, have further issues such as compromising the privacy and anonymity of users.

The methods and systems described herein provide anonymous and efficient certificate revocation status querying. A query for a full certificate chain may be executed with a limited number of individual queries. Furthermore, the size of the query response is small and the query does not contain any traceable information which could lead to deanonymization of the querier.

The methods described herein are executed between a query client and query responder. The query client may be an application or a computing device that wishes to query the revocation status of a certificate or a certificate chain. The query responder is a server that provides a status query service. The query responder is responsible for sending responses to query clients based on a certificate revocation hierarchy. According to examples the server is associated with a query service endpoint, such as a Uniform Resource Locator (URL) .

According to examples disclosed herein, certificates are partitioned into subsets of certificates referred to herein as Virtual Certificate Groups (VCG) . Each VCG is associated with an Extended Certificate Revocation List (ECRL) comprising all the revoked certificates in the VCG.

The grouping of certificates into VCGs may be done in such a way that each group has the same number of certificates and each certificate belongs to exactly one group. An identifier for the group may be encoded into the certificate. An ECRL is empty if none of the certificates in the VCG have been revoked.

Figure 3 is a simplified schematic diagram 300 showing three

VCGs

310, 320, 330 and associated ECRLs. In Figure 3 the first VCG 310 is associated with a first ECRL 340. None of the certificates in the second VCG 320 have been revoked and therefore the revocation list associated to the second group is empty. The third VCG 330 is associated with a ECRL 350 comprising an indication revoked certificates from the third VCG 330.

Examples of the methods and systems described herein may utilize a construction of VCGs based on serial numbers associated to the certificates in the groups. Each certificate may be associated with a unique serial number. The serial number is a positive integer represented by at most 20 octets (20 bytes) .

In the example described herein, it is assumed that all serial numbers are of the same length L and the first N bytes form a unique identifier of an issuing CA. This is a realistic assumption where all CAs under consideration are known and customizations can be made. For example, in the case of device certificates provisioned to IoT devices manufactured by a number of different IoT vendors only a handful of CAs are needed in the deployment, and reserving, for example, two bytes is sufficient for a unique CA identifier.

For each VCG, M bytes are reserved such that all the certificates in a VCG share the same (L-M) byte prefix. For example, if L = 20 and M = 2, this means that all the certificates belonging to the same VCG have the same 18-byte prefix in their serial numbers. In this case, the size of the group at each leaf node of the certificate revocation hierarchy is 2 ¹⁶ = 65, 536, which is sufficient to protect the user privacy in many use cases.

Figure 4 shows an example 400 of a serial number 410 for a certificate. In the example 400 shown in Figure 4, N = 2 and L = 20. In this case, the serial number 410 comprises an 18-byte prefix 420 that is used an identifier of the VCG and a 2-byte suffix 430.

Upon receiving a certificate chain, a query client may extract the identifier of the VCG from the entity certificate in the chain, and send the identifier to a query responder. The query responder locates and returns the revocation list corresponding to the VCG. In some cases the query client may send multiple VCG identifiers in the same query. In that case, query responder may reply with a response that contains all the revocation lists of all the VCGs identified by the identifiers.

Figure 5 is a simplified schematic diagram showing a workflow 500 for managing ECRLs, according to an example. In the example shown in Figure 5 an extended revocation list (ECRL) generator 510 is shown. The ECRL generator 510 may be an application executed on a server or other device. The ECRL generator 510 is responsible for maintaining a Certificate Revocation Hierarchy.

The ECRL generator 510 is integrated with existing PKI in the manner shown in the example of Figure 5. In Figure 5, a Root CA 520, intermediate CA 530 and device CA 540 each publish a CRL. These CRLs are accessible via CRL distribution points 550, 560, 570. These distribution points may accessed via URLs across a network. The ECRL generator 510 fetches CRLs from the CRL distribution points 550, 560, 570. The ECRL generator 510 uses the information from the CRLs to generate and maintain ECRLs for VCGs 580.

In some examples, the ERCL generator 510 may update an ECRL for one of VCGs 580 in response to an explicit certificate revocation event from a trusted party. This allows the ECRL generator 510 to update the ECRL without waiting for

CAs

520, 530, 540 to publish updates to CRLs.

The ECRLs may also be signed by the ECRL generator 510. When validating the integrity of the ECRLs, a client device may have the public key of the generator 510 pinned to the device. In some cases, another certificate may be issued to the ECRL generator 510 itself by a CA. In this scenario the validity of the ECRL generator certificate is checked as part of a validation procedure.

According to one example, to support queries based on VCG identifiers, information relating to how to make queries along with VCG parameters and query service endpoints may be published in protocol documentation or on a service provider or vendor website. In another example VCG parameters and query service endpoints are encoded into certificates as certificate extensions.

When aggregating the CRLs, the ECRL generator 510 fetches CRLs periodically from all the CAs relevant for the intended use cases, and generates, compresses and signs the ECRLs. To query about the revocation status of a certificate chain, a query client obtains information about the query service endpoints and the VCG parameters. If using the scheme based on serial numbers described in relation to Figure 4, the query client extracts serial numbers from the certificates in the certificate chain. For the CA certificates in the chain, the serial numbers are taken as-is, but for the entity certificate, the last M bytes are removed from the serial number. These serial numbers or prefixes of these numbers are then sent to a query service endpoint.

The certificates in a VCG are naturally ordered by the M-byte suffix of their serial numbers, when these M byte suffixes are interpreted as integers ranging from 0 to 2 ^8M –1. For example, when M = 2, certificates may be numbered from 0 to 65, 535.

According to one example the revocation status of these certificates may be represented efficiently using a bitmap of 2 ^8M bits, where the k-th bit is set to 1 if and only if the certificate with the suffix k has been revoked. For example, for M = 2, such a bitmap would contain 2 ¹⁶ = 65, 536 bits i.e. 8 kilobytes (KB) . Such a bitmap may be compressed using existing lossless data compression technique. Compression may be especially useful where the number of revoked certificates within the same group is very small, or very large. In other words, where the bitmap contains mostly zeroes or mostly 1 s. For example, where 1%of the certificates are revoked, an 8KB bitmap may be compressed to 145 bytes. In a second example where 0.1%of the certificates are revoked it may be compressed to 45 bytes. Some forms of data compression allow checking of bit values without decompression, but others forms may require decompression before checking.

According to examples described herein, instead of having a flat structure for the VCGs, sometimes it is desirable to build a hierarchical structure to facilitate flexible querying.

From the basic parameters L, N, M (e.g., L = 20, N = 2 and M = 2) , the remaining L –N –M (= 16 bytes) may further be divided for specific purposes such as to encode information relating to a vendor, the product category and the product model. This may form a complete hierarchy.

Figure 6 is a schematic diagram showing a hierarchy for VCGs 600 according to an example. In Figure 6 the block 610 corresponds to a vendor. The

blocks

620 and 630 correspond to product categories.

Blocks

640 and 650 correspond to product model.

Blocks

660, 670 correspond to VCGs and block 680 is an ECRL for the VCG 660. Thus, for example, all devices in the

VCG groups

660 and 670 correspond to the same product model 650 and this is encoded in the serial number.

In a further example, rather than using serial numbers for VCG identifiers, other data fields may be used in the certificate. For example, it is possible to include a serial number in a subject field of an X. 509 certificate. It other examples, other information in the Subject field such as country, organization, organization unit, common name, pseudonym and may be used for a VCG identifier.

Similar to the example shown a Figure 6 a hierarchical structure may be built naturally in these fields as well. In this case, to ensure privacy, queries are adapted so that these identifiers are used for the entity certificate instead of serial numbers. Queries relating to CA certificates may continue to use serial numbers as there is no privacy concern.

If the VCG identifier is not based on the serial numbers of the certificates, the grouping of certificates and aggregation of CRLs is adapted accordingly. For example, if the VCGs are built on top of the subject field (or part of it) , the Extended Revocation List Generator is either notified explicitly about the subjects of the revoked certificates, or it fetches such information from other CAs when updating the ECRLs.

VCGs using alternative fields give implementers more choices to meet their business requirements. For example, requiring VCG IDs on top of certificate serial numbers may involve CA customization. Such customization may be difficult and can be avoided by using a serial number in the subject field, since the subject field is an input to the CA when enrolling certificates. By having a hierarchical structure on top of VCGs, more flexible queries are allowed, with a trade-off for the response size.

Figure 7 is a block diagram of a method for managing certificates in a public key infrastructure (PKI) . The method 700 may be used in conjunction with other methods and systems described herein. In particular the method 700 may be implemented by the ECRL generator 510 shown in Figure 5 to generate the VCG grouping and maintain the ECRs of the VCGs 580.

At block 710 the method comprises partitioning a set of certificates into a plurality of subsets. According to an example partitioning the set of certificates into a plurality of subsets comprises partitioning the set of certificates based on identification data., such as a serial number associated to each certificate. In some cases the identification data comprises a first portion and a second portion and wherein the first portion is common to all of the certificates in a subset as shown in the serial number 410 shown in Figure 4. In some cases, the first portion of the identification data comprise a sub-portion identifying the certificate authority that issued the certificate. According to examples, the second portion of the identification data identifies the certificate from others of the certificates in the subset.

At block 720, the method 700 comprises generating, for each subset of the plurality of subsets, a certificate revocation list comprising a list of revoked certificates in the respective subset. At block 730 the method 700 comprises receiving notification that a certificate has been revoked by a certificate authority in the PKI. At block 740 the method comprises identifying a subset containing the revoked certificate from the plurality of subsets. At block 750 the method 700 comprises updating the certificate revocation list for the subset.

The present disclosure is described with reference to flow charts and/or block diagrams of the method, devices and systems according to examples of the present disclosure. Although the flow diagrams described above show a specific order of execution, the order of execution may differ from that which is depicted. Blocks described in relation to one flow chart may be combined with those of another flow chart. In some examples, some blocks of the flow diagrams may not be necessary and/or additional blocks may be added. It shall be understood that each flow and/or block in the flow charts and/or block diagrams, as well as combinations of the flows and/or diagrams in the flow charts and/or block diagrams can be realized by machine readable instructions.

The machine-readable instructions may, for example, be executed by a general-purpose computer, a special purpose computer, an embedded processor or processors of other programmable data processing devices to realize the functions described in the description and diagrams. In particular, a processor or processing apparatus may execute the machine-readable instructions. Thus, modules of apparatus may be implemented by a processor executing machine-readable instructions stored in a memory, or a processor operating in accordance with instructions embedded in logic circuitry. The term 'processor' is to be interpreted broadly to include a CPU, processing unit, logic unit, or programmable gate set etc. The methods and modules may all be performed by a single processor or divided amongst several processors. Such machine-readable instructions may also be stored in a computer readable storage that can guide the computer or other programmable data processing devices to operate in a specific mode.

Such machine-readable instructions may also be loaded onto a computer or other programmable data processing devices, so that the computer or other programmable data processing devices perform a series of operations to produce computer-implemented processing, thus the instructions executed on the computer or other programmable devices provide an operation for realizing functions specified by flow (s) in the flow charts and/or block (s) in the block diagrams.

Figure 8 is a block diagram of a computing system 800 that may be used for implementing the methods disclosed herein. Specific devices may utilize all of the components shown or only a subset of the components, and levels of integration may vary from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc. The computing system 800 includes a processing unit 802. The processing unit includes a central processing unit (CPU) 814, a graphics processing unit (GPU) 816, a memory 808, and may further include a mass storage device 804, a video adapter 810, and an I/O interface 812 connected to a bus 818.

The bus 818 may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, or a video bus. The CPU 814 and GPU 816 may comprise any type of electronic data processors. The memory 808 may comprise any type of non-transitory system memory such as static random access memory (SRAM) , dynamic random access memory (DRAM) , synchronous DRAM (SDRAM) , read-only memory (ROM) , or a combination thereof. In an embodiment, the memory 808 may include ROM for use at boot-up, and DRAM for program and data storage for use while executing programs.

The mass storage 804 may comprise any type of non-transitory storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via the bus 818. The mass storage 804 may comprise, for example, one or more of a solid state drive, hard disk drive, a magnetic disk drive, or an optical disk drive.

The video adapter 810 and the I/O interface 812 provide interfaces to couple external input and output devices to the processing unit 802. As illustrated, examples of input and output devices include a display 820 coupled to the video adapter 810 and a mouse, keyboard, or printer 822 coupled to the I/O interface 812. Other devices may be coupled to the processing unit 802, and additional or fewer interface cards may be utilized. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide an interface for an external device.

The processing unit 802 also includes one or more network interfaces 806, which may comprise wired links, such as an Ethernet cable, or wireless links to access nodes or different networks. The network interfaces 806 allow the processing unit 802 to communicate with remote units via the networks. For example, the network interfaces 806 may provide wireless communication via one or more transmitters/transmit antennas and one or more receivers/receive antennas. In an embodiment, the processing unit 802 is coupled to a local-area network 824 or a wide-area network for data processing and communications with remote devices, such as other processing units, the Internet, or remote storage facilities.

Although the present disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the disclosure as defined by the appended claims.

The present inventions can be embodied in other specific apparatus and/or methods. The described embodiments are to be considered in all respects as illustrative and not restrictive. In particular, the scope of the invention is indicated by the appended claims rather than by the description and figures herein. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

A method for managing certificates in a public key infrastructure (PKI) , the method comprising, at a first entity in the PKI:

partitioning a set of certificates into a plurality of subsets;

generating, for each subset of the plurality of subsets, a certificate revocation list comprising a list of revoked certificates in the respective subset;

receiving notification that a certificate has been revoked by a certificate authority in the PKI;

identifying a subset containing the revoked certificate from the plurality of subsets; and

updating the certificate revocation list for the subset.
The method of claim 1, wherein partitioning the set of certificates into a plurality of subsets comprises partitioning the set of certificates based on identification data associated to each certificate.
The method of claim 2, wherein the identification data comprises a first portion and a second portion and wherein the first portion is common to all of the certificates in a subset.
The method of claim 3 wherein respective first portions of the identification data comprise a sub-portion identifying the certificate authority that issued the respective certificate.
The method of claims 3 to 4 wherein for each certificate in a subset of certificates, the respective second portion of the identification data identifies the certificate from others of the certificates in the subset.
The method of claim 5 comprising encoding the revocation status of the certificates of a subset as a vector of data values
The method of claim 6, wherein respective second portions of the identification data of each certificate is used as an index for respective entries of the vector, and wherein respective entries of the vector encode a revocation status of the certificate with the corresponding index”.
The method of claim 6 or 7, wherein each data value of the vector comprises a binary value.
The method of claim 6 to 8, comprising applying a lossless compression algorithm to the vector.
A method, comprising,

receiving, at a first entity in a public key infrastructure (PKI) , a certificate from a second entity in the PKI;

extracting a first portion of identification data from the certificate, the identification data comprising a first portion and a second portion, the first portion identifying a subset in a collection of subsets of certificates, the subset containing the certificate;

communicating the first portion to a third entity in the PKI;

receiving, in response to communication the first portion to the third entity, a certificate revocation list for the subset; and

determining the revocation status of the certificate on the basis of the revocation list.
A computing system comprising

A processor

A memory coupled to the processor, the memory storing instructions that when implemented by the processor, cause the processor to:

partition a set of certificates of a public key infrastructure (PKI) into a plurality of subsets;

generate, for each subset of the plurality of subsets, a certificate revocation list comprising a list that identifies revoked certificates in the respective subset;

receive notification that a certificate has been revoked by a certificate authority in the PKI;

identify the subset containing the revoked certificate in the plurality of subsets; and

update the certificate revocation list of the subset.
The computing system of claim 11, wherein

the set of certificates is partitioned into a plurality of subsets of certificates based on identification data associated to each certificate.
The computing system of claim 12, wherein the identification data comprises a first portion and a second portion and wherein the first portion is common to all of the certificates in a subset.
The computing system of claim 13 wherein respective first portions of the identification data comprise a sub-portion identifying the certificate authority that issued the respective certificate.
The computing system of claim 13 or 14 wherein for each certificate in a subset of certificates, the respective second portion of the identification data identifies the certificate from others of the certificates in the subset.