Patent Description:
Digital certificates are electronic documents commonly used to establish ownership of a public key over a network. Once ownership of the public key is established for a particular user or entity, the public key is used to securely communicate with the user or entity. Digital certificates commonly have embedded time-based expirations that limit a period of validity of the digital certificate. After the period of validity has expired, the certificate is no longer valid. This requires that each device that receives a certificate from a purported owner of a public key associated with the certificate has a reliable clock in order to compare the current time and the period of validity. Digital certificates may also be revoked prior to their scheduled expiration date through the use of a certificate revocation list.

United States Patent Application publication document <CIT> discloses a method for proving the validity of a digital document digitally signed using a digital key that corresponds to a digital certificate in a chain of digital certificates issued by certification authorities within a hierarchy of certification authorities. At least one secure digital time stamp is applied to at least one record comprising the digital document, the digital signature, certificate chain data, and information relating to the revocation of certificates by certification authorities within the certificate chain. If, at some later time, one or more digital certificates either expire or are revoked, the timestamp serves as evidence of the integrity of the signed digital document.

United States Patent Application publication document <CIT> discloses a method of generating a shortcut certificate for authenticating a user digital certificate generated by an issuing certification authority; the method comprising: authenticating the digital certificate of the issuing certification authority; creating the shortcut certificate for the digital certificate of the issuing certification authority when the digital certificate of the issuing certification authority is authenticated; wherein the shortcut certificate comprises a signed entry of an authentication of the issuing certification authority.

United States Patent Application publication document<CIT> discloses the practical benefit of the inventive idea results from an assumption that typically, the operational subCAs will not get compromised. Assuming this, a batch of revocation lists manifesting no revocations can be generated and signed. These pregenerated CRLs (root CRLs) can then be stored outside the high-security vault and, in case of no subCA compromises, published periodically one at a time to the directory system where the PKI clients can automatically fetch them.

One aspect of the disclosure provides a method for representing certificate expiration with time-based intermediate certificate authorities. The method includes obtaining, at data processing hardware, from a root certificate authority, root digital certificate digitally signed by the root certificate authority. The method also includes generating, by the data processing hardware, a chain of intermediate certificate authorities. Each respective intermediate certificate authority in the chain of intermediate certificate authorities includes a respective intermediate certificate digitally signed by the intermediate certificate authority or the root certificate authority that is immediately higher in the chain of intermediate certificate authorities than the respective intermediate certificate authority and a respective validation time period indicating a range of times when the respective intermediate certificate authority is permitted to digitally sign intermediate certificates and end entity certificates. The respective validation time period of the respective intermediate certificate authority includes the validation time period of each intermediate certificate authority that is lower in the chain of intermediate certificate authorities than the respective intermediate certificate authority. The method also includes generating, by the data processing hardware, a certificate revocation list for the chain of intermediate certificate authorities. The method also includes generating, by the data processing hardware, from the lowest intermediate certificate authority in the chain of intermediate certificate authorities, a plurality of end entity certificates. Each end entity certificate of the plurality of end entity certificates is digitally signed by the lowest intermediate certificate authority in the chain of intermediate certificate authorities. The method also includes, after the respective validation time period of the lowest intermediate certificate authority in the chain of intermediate certificate authorities has elapsed, adding, by the data processing hardware, to the certificate revocation list, one or more of the plurality of end entity certificates generated from the lowest intermediate certificate authority in the chain of intermediate certificate authorities.

Implementations of the disclosure may include one or more of the following optional features. In some implementations, when every end entity certificate digitally signed by a respective intermediate certificate authority in the chain of intermediate certificate authorities has been added to the certificate revocation list and the current time is at or after an end of the respective validation time period of the respective intermediate certificate authority, the method includes removing, by the data processing hardware, each of the plurality of end entity certificates from the certificate revocation list and adding, by the data processing hardware, the respective intermediate certificate associated with the respective intermediate certificate authority to the certificate revocation list. In some examples, the method includes, after the respective validation time period associated with a respective intermediate certificate authority in the chain of intermediate certificate authorities has elapsed, generating, by the data processing hardware, another intermediate certificate authority associated with a validation time period having a same duration as the validation time period associated with the respective intermediate certificate authority. The method may also include replacing, by the data processing hardware, the respective intermediate certificate authority with the other intermediate certificate authority in the chain of intermediate certificate authorities. The method may also include, after replacing the respective intermediate certificate authority with the other intermediate certificate authority, generating, by the data processing hardware, an end entity certificate digitally signed by the other intermediate certificate authority and not digitally signed by the respective intermediate certificate authority.

Optionally, each validation time period is associated with one of a day, a week, a month, a quarter, or a year. In some implementations, each end entity certificate does not have an expiration time. In some examples, the method includes determining, by the data processing hardware, that a respective end entity certificate of the plurality of end entity certificates is compromised and adding, by the data processing hardware, the respective end entity certificate to the certificate revocation list.

Each intermediate certificate authority may be associated with a unique key derived from a common seed value. In some implementations, each unique key is derived using a key derivation function. Optionally, the respective validation time period of the respective intermediate certificate authority is shorter than the validation time periods of any intermediate certificate authorities higher in the chain of intermediate certificate authorities than the respective intermediate certificate authority. In some implementations, the method further includes determining, by the data processing hardware, that a respective end entity certificate of the plurality of end entity certificates has been rotated and adding, by the data processing hardware, the respective end entity certificate to the certificate revocation list.

Another aspect of the disclosure provides data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that when executed on the data processing hardware cause the data processing hardware to perform operations. The operations include obtaining, from a root certificate authority, a root digital certificate digitally signed by the root certificate authority. The operations also include generating a chain of intermediate certificate authorities. Each respective intermediate certificate authority in the chain of intermediate certificate authorities includes a respective intermediate certificate digitally signed by the intermediate certificate authority or the root certificate authority that is immediately higher in the chain of intermediate certificate authorities than the respective intermediate certificate authority and a respective validation time period indicating a range of times when the respective intermediate certificate authority is permitted to digitally sign intermediate certificates and end entity certificates. The respective validation time period of the respective intermediate certificate authority includes the validation time period of each intermediate certificate authority that is lower in the chain of intermediate certificate authorities than the respective intermediate certificate authority. The operations also include generating a certificate revocation list for the chain of intermediate certificate authorities. The operations also include generating, from the lowest intermediate certificate authority in the chain of intermediate certificate authorities, a plurality of end entity certificates. Each end entity certificate of the plurality of end entity certificates is digitally signed by the lowest intermediate certificate authority in the chain of intermediate certificate authorities. The operations also include, after the respective validation time period of the lowest intermediate certificate authority in the chain of intermediate certificate authorities has elapsed, adding, to the certificate revocation list, one or more of the plurality of end entity certificates generated from the lowest intermediate certificate authority in the chain of intermediate certificate authorities.

This aspect may include one or more of the following optional features. In some implementations, when every end entity certificate digitally signed by a respective intermediate certificate authority in the chain of intermediate certificate authorities has been added to the certificate revocation list and the current time is at or after an end of the respective validation time period of the respective intermediate certificate authority, the operations include removing each of the plurality of leaf certificates from the certificate revocation list and adding the respective intermediate certificate associated with the respective intermediate certificate authority to the certificate revocation list. In some examples, the operations include, after the respective validation time period associated with a respective intermediate certificate authority in the chain of intermediate certificate authorities has elapsed, generating another intermediate certificate authority associated with a validation time period having a same duration as the validation time period associated with the respective intermediate certificate authority. The operations may also include replacing the respective intermediate certificate authority with the other intermediate certificate authority in the chain of intermediate certificate authorities. The operations may also include, after replacing the respective intermediate certificate authority with the other intermediate certificate authority, generating an end entity certificate digitally signed by the other intermediate certificate authority and not digitally signed by the respective intermediate certificate authority.

Optionally, each validation time period is associated with one of a day, a week, a month, a quarter, or a year. In some implementations, each end entity certificate does not have an expiration time. In some examples, the operations include determining that a respective end entity certificate of the plurality of end entity certificates is compromised and adding the respective end entity certificate to the certificate revocation list.

Each intermediate certificate authority may be associated with a unique key derived from a common seed value. In some implementations, each unique key is derived using a key derivation function. Optionally, the respective validation time period of the respective intermediate certificate authority is shorter than the validation time periods of any intermediate certificate authorities higher in the chain of intermediate certificate authorities than the respective intermediate certificate authority. In some implementations, the method further includes determining that a respective end entity certificate of the plurality of end entity certificates has been rotated and adding the respective end entity certificate to the certificate revocation list.

Digital certificates (also referred to as public key certificates or identity certificates) are commonly used to cryptographically link ownership of a public key with a particular entity. For example, when a user is attempting to establish secure communications with an entity (e.g., a website via Hypertext Transfer Protocol Secure (HTTPS)), the user will need to use that entity's public key to encrypt communications. In order to verify that the public key used when encrypting communications actually belongs to the entity the user desires to communicate with, the user will receive the entity's digital certificate which demonstrates the entity's ownership of the public key. The digital certificate is typically signed by a certificate authority. As long as the user trusts the certificate authority, the user may trust that the entity owns the public key referenced by the digital certificate.

Certificate authorities (CAs) are entities that issue and sign digital certificates. Generally, CAs are established entities that have acquired sufficient enough reputation and trust that clients will accept that a digital certificate signed by the CA is legitimate. Typically, a digital certificate applicant generates a key pair (i.e., a private key and a public key) and a certificate signing request (CSR). The CSR includes the public key and other information to be included in the certificate (e.g., the entity's name or identifier, domain name information, contact information, etc.). The applicant sends the CSR to a trusted CA. The CA receives the CSR and independently verifies the information included within the CSR is correct. If the CA believes the information to be correct, the CA signs a digital certificate (with the CA's own private key) that includes the applicant's public key and the other identifying information. The CA then provides the signed digital certificate back to the applicant.

When a third party desires to securely communicate with the recipient of the certificate, the recipient can present the digital certificate to the third party. The third party may use the digital certificate to confirm the CA's signature via the CA's public key. The third party may also confirm that the applicant has possession of the private key associated with the public key listed in the digital certificate and that the digital certificate has not been modified since being signed. The third party can now trust that the public key provided by the digital certificate belongs to the entity that the third party wishes to communicate with.

Trusted CAs publish what is commonly referred to as a root certificate. This root certificate is a digital certificate that is self-signed by the CA with its own private key and publically provides the CA's public key. Using the root certificate, third parties can verify any certificate issued by the CA that is signed with the same private key as the root certificate. In order to limit exposure of root certificates, intermediate CA's may be assigned a certificate by a root CA and these intermediate CA's may in turn issue end entity certificates (also referred to as leaf certificates) to entities. That is, as explained in more detail below, a root CA and one or more intermediate CAs may form a "chain" of CAs with the last intermediate CA in the chain issuing end entity certificates to end entities. A party who desires to validate an end entity certificate will follow the chain up until the root CA is reached.

Digital certificates are typically enforced with an expiration time or period of validity. For example, a digital certificate may include a start point of its period of validity and an end point of its period of validity (i.e., its expiration point). After the period of validity has ended, the digital certificate is no longer valid and third parties should no longer accept the certificate as evidence of ownership of the respective public key. While effective, periods of validity by necessity require the receiving party (i.e., the party that received the digital certificate and desires to authenticate it) to have reliable access to the current time. However, some devices that may wish to validate a digital certificate may not have access to the current time (e.g., some network devices like switches or network controllers do not have clocks or do not have accurate clocks), making the period of validity unreliable in these circumstances, especially for certificates with short periods of validity (i.e., frequently rotated digital certificates).

Another way to invalidate digital certificates is by publishing a certificate revocation list (CRL). Typically, this list is used only to revoke digital certificates prior to their scheduled expiration date. For example, if a digital certificate is known to be compromised, the digital certificate may be added to a CRL even though the digital certificate's period of validity has not yet expired. When validating the digital certificate, a party, in addition to ensuring that the period of validity has not expired by referencing a current time, will also check that the certificate is not listed in the CRL published by the CA that issued the certificate. Thus, a CRL may be used to revoke certificates that do not have an expiration (or an expiration that is very long) to allow devices without reliable access to the current time an effective way to determine the validity of digital certificates. However, such a CRL would grow without bound and eventually become too large to be effective.

Implementations herein are directed toward a digital certificate management system that provides efficient revocation of frequently rotated digital certificates (also referred to herein as just "certificates") without relying on expiration of the certificates or a clock of a client device. The system includes a chain of time-based intermediate certificate authorities (CAs) that are each associated with or include a respective validation time period. The chain of intermediate CAs and respective validation time periods encode an expiration time into the certificates issued by the chain of intermediate CAs. Based on the respective validation time periods, the digital certificates issued by the chain of intermediate CAs are added to a certificate revocation list (CRL). The system may add certificates to the CRL in due course as the certificates are rotated (i.e., replaced by a newer certificate) or when the certificate or a CA is compromised. Once the system adds every digital certificate issued by a respective intermediate CA to the CRL, the system may revoke the digital certificate issued to that intermediate CA and prune the CRL of all certificates issued by the respective intermediate CA, thus ensuring that all of the certificates remain revoked without excessing growth of the CRL.

Referring to <FIG>, in some implementations, an example digital certificate management system <NUM> includes a remote system <NUM>. The remote system <NUM> may be multiple computers or a distributed system (e.g., a cloud environment) having scalable / elastic resources <NUM> including computing resources <NUM> (e.g., data processing hardware) and/or storage resources <NUM> (e.g., memory hardware).

The remote system <NUM> is configured to obtain a root certificate <NUM>, 210R (e.g., an X. <NUM> certificate). For example, the remote system <NUM> receives the root certificate 210R from an independent root certificate authority <NUM>, 310R. Alternatively, the remote system <NUM> includes the root certificate authority 310R and generates the root certificate 210R itself. The root CA 310R digitally signs the root certificate 210R with a public key 220R owned by the root CA 310R. That is, as is well-known in public-key cryptography, only the root CA 310R has possession of a private key (not shown) that is associated with the public key 220R. The remote system <NUM> generates a chain of intermediate CAs <NUM>, 310Na-n. Each intermediate CA 310N in the chain includes or is associated with a respective intermediate certificate <NUM>, 210Na-n digitally signed by the intermediate CA 310N that is immediately higher in the chain of intermediate CAs 310N than the corresponding intermediate CA 310N. The remote system <NUM> may use any appropriate signing algorithm to sign the certificates <NUM>. The respective intermediate certificate 210N of the intermediate CA 310N that is highest in the chain is signed by the root CA 310R, thus establishing a chain of trust. The lowest intermediate CA in the chain (i.e., intermediate CA 310Nc in the given example) issues end entity certificates <NUM> (e.g., X. <NUM> certificates) to an end-entity <NUM> via, for example, network <NUM>, 20a. When a third party, such as user <NUM> via user device <NUM> wishes to communicate with the end-entity <NUM>, the end-entity <NUM> provides the user device <NUM> with the end entity certificate <NUM> (e.g., via a network 20b). That is, the lowest intermediate CA 310N in the chain of intermediate CAs 310N generates one or more end entity certificates <NUM>. Each generated end entity certificate <NUM> is digitally signed by the lowest intermediate CA 310N in the chain of intermediate CAs 310N. In some examples, each end entity certificate <NUM> does not include an expiration. In other examples, each end entity certificate <NUM> includes a maximum or very long expiration time length/duration (e.g., one or more years).

Referring now to <FIG>, the remote system establishes a chain of trust <NUM> between the intermediate certificates 310N by signing each certificate <NUM> in the chain with the public key 220N of the intermediate CA 310N immediately higher in the chain. Here, the root certificate 210R includes the public key 220R of the root CA, an identification (ID) 230R of the root CA, and a signature 240R of the root CA. The root CA signature 240R is signed by the private key (not shown) associated with the root CA public key 220R.

The root CA 310R maintains the root certificate 210R and issues an intermediate certificate 210Na to a first intermediate CA 310Na in the chain. This certificate includes the root CA ID 230R and the root CA signature 240R (signed by the same private key as the root CA signature 240R of the root certificate 210R). The intermediate certificate 210Na also includes an ID 230Na of the first intermediate CA 310N and the public key 220Na of the first intermediate CA 310Na. This certificate establishes the first intermediate CA's ownership of its public key 220Na.

Continuing up the chain, the first intermediate CA <NUM> lONa issues another intermediate certificate 210Nb to a second intermediate CA 310Nb. This intermediate certificate 210Nb includes the signature 240Na and the ID 230Na of the first intermediate CA 310Na. The intermediate certificate 210Nb also includes the ID 230Nb and the public key 220Nb second intermediate CA 310Nb. This chain continues for any length until a final intermediate CA 310Nn provides an end entity certificate <NUM> that includes its ID 230Nn and signature 240Nn to the entity <NUM>. The end entity certificate also includes the ID 230E and the public key 220E of the entity <NUM>. These linked certificates <NUM> provide a chain of trust that allows a third party to validate the entity's ownership of the public key 220E all the way back to the root authority 310R.

Referring back to <FIG>, each intermediate CA 310N in the chain also includes a respective validation time period <NUM>, <NUM> indicating a range of times when the corresponding intermediate CA 310N is permitted to digitally sign digital certificates 210N, <NUM>. That is, each intermediate CA 310N is time-based and the validation time period <NUM> for each intermediate CA 310N establishes the range of times when the corresponding intermediate CA 310N is permitted to issue certificates <NUM>. For instance, the validation time period <NUM> for the last intermediate CA 310N (i.e., 310Nc in the given example) in the chain establishes the range of times when the corresponding intermediate CA 310N is permitted to issue end entity certificates <NUM>. In contrast to an expiration period assigned to a digital certificate <NUM> that requires a device to access a clock to determine when the expiration period has lapsed, the validation time period <NUM> is associated with the intermediate CA 310N, thereby indicating that no digital certificates 210N in the chain were digitally signed by the respective intermediate CA 310N after the validation time period <NUM>.

Referring now to <FIG>, a chain <NUM> of intermediate CAs 310N include exemplary validation time periods 312a-e. Here, the chain includes the root CA 310R at the top and next an optional switch CA <NUM>. The switch CA <NUM> may not have an associated validation time period and may instead delegate authority from the root CA 310R to the other intermediate CAs 310N. Below the switch CA <NUM> are two intermediate CAs 310Na<NUM>, 310Na<NUM> with the validation time period 312ai of the year <NUM> and the validation time period 312a<NUM> of the year <NUM> respectively. Next in the chain are the two intermediate CAs 310b<NUM>, 310b<NUM> with validation time periods 312b<NUM>, 312b<NUM> of Q1 and Q2 respectively. Next in the chain are the two intermediate CAs 310c<NUM>, 310c<NUM> with validation time periods 312ci, 312c<NUM> of January and February respectively. Continuing down the chain are two intermediate CAs 310d<NUM>, 310d<NUM> with validation time periods 312di, 312d<NUM> of Week <NUM> and Week <NUM> respectively. Finally, last in the chain are the two intermediate CAs 310d<NUM>, 310d<NUM> with validation time periods 312di, 312d<NUM> of Day <NUM> and Day <NUM> respectively.

Each of these intermediate CAs <NUM> will only issue certificates 210N, <NUM> during the period of time within the validation time period <NUM> associated with the respective intermediate CA <NUM>. For example, the intermediate CA 310Ne<NUM> may only issue certificates <NUM> for the <NUM> hours of January <NUM>, <NUM>. Once it becomes January <NUM>, <NUM>, the validation time period 312ei will conclude and the validation time period 312e<NUM> for the intermediate CA 310Ne<NUM> begins. Similarly, for the time period from January <NUM>, <NUM> through January <NUM>, <NUM>, the intermediate CA 310Ndi ("Week <NUM>") may issue certificates 210N while from January <NUM>, <NUM> to January <NUM>, <NUM>, the intermediate CA 310Nd<NUM> ("Week <NUM>") may issue certificates 210N. In some implementations, the respective validation time period <NUM> of each intermediate CA 310N is shorter than the validation time periods <NUM> of any intermediate CAs 310N higher in the chain of intermediate CAs 310N than the respective intermediate CA 310N. For example, the validation time period <NUM> for the "January" intermediate CA 310NC<NUM> (i.e., one month) is shorter than the validation time period <NUM> of both of the intermediate CAs 310N higher in the chain (i.e., the Q1 intermediate CA 310Nb<NUM> and the <NUM> intermediate CA 310Na<NUM>). That is, as the chain of intermediate CAs 310N is descended, the validation time period <NUM> grows shorter.

Referring now to <FIG>, in some examples, only a single chain of intermediate CAs 310N is active at any point in time. The chain 400a of <FIG> illustrates an active chain on the date of January <NUM>, <NUM>. Only an active intermediate CA 310N may issue certificates <NUM>. Here, the root CA 310R provides a certificate 210NS to the switch CA <NUM>, which provides a certificate 201Na to the intermediate CA 310Na<NUM>, which provides a certificate 210Nb to the intermediate CA 310Nb<NUM>, which in turn provides a certificate 210Nc to the intermediate CA 310Nc<NUM>. Similarly, the intermediate CA 310Nc<NUM> provides a certificate 210Ndi to the intermediate CA 310Nd<NUM> which in turn provides a certificate 210Nei to the intermediate CA 310Ne<NUM>.

Because in this example the intermediate CA 310Ne<NUM> (i.e., Day <NUM>) is the "bottom" of the chain, this intermediate CA 310Nei provides end entity certificates <NUM> to requesting entities <NUM>. However, any number of intermediate CAs 310N at any granularity of validation time periods <NUM> may be included. Here, the validation time periods <NUM> include a year, a quarter, a month, a week, and a day. Additionally or alternatively, any other time periods may be used such as an hour or a decade or other finite periods of time (e.g., <NUM> hours, <NUM> hours, <NUM> hours, etc.) that do align with calendar dates.

Continuing the example of <FIG>, <FIG> illustrates the active chain 400b at a date of January <NUM>, <NUM> (i.e., one day after the date of <FIG>). In some implementations, after the respective validation time period <NUM> associated with a respective intermediate CA 310N in the chain of intermediate CAs 310N has elapsed, the remote system generates another intermediate CA 310N associated with a validation time period <NUM> having a same duration as the validation time period <NUM> associated with the respective intermediate CA 310N. However, the new validation time period <NUM> encompasses a period of time after the original validation time period <NUM> has elapsed. The remote system <NUM> replaces the respective intermediate CA 310B with the other intermediate CA <NUM>10N in the chain of intermediate CAs 310N.

In this case, because the validation time period <NUM> associated with the intermediate CA 310Nei has elapsed (i.e., "Day <NUM>" or January <NUM>, <NUM>), the active chain has replaced the Day <NUM> intermediate CA 310Ne<NUM> with the Day <NUM> intermediate CA 310Ne<NUM>. The Week <NUM> intermediate CA 310Nd<NUM> issues the Day <NUM> intermediate CA 310Ne<NUM> an intermediate certificate 210Ne<NUM> and during this validation time period <NUM> (i.e., during January <NUM>, <NUM>), the Day <NUM> intermediate CA 310Ne2 issues end entity certificates <NUM> in lieu of the Day <NUM> intermediate CA 310Ne<NUM>. In other words, in some implementations, after replacing the respective intermediate CA 310N (e.g., the Day <NUM> intermediate CA 310Ne<NUM>) with the other intermediate CA 310N (e.g., the Day <NUM> intermediate CA 310Ne<NUM>), the remote system <NUM> generates an end entity certificate <NUM> digitally signed by the other intermediate CA 310N and not digitally signed by the respective intermediate CA 310N. That is, the Day <NUM> intermediate CA 310Ne<NUM> begins issuing end entity certificates <NUM> while the Day <NUM> intermediate CA 310Ne<NUM> no longer issues end entity certificates <NUM>.

In yet another example, <FIG> illustrates the active chain 400c at a date of January <NUM>, <NUM> (i.e., <NUM> days after the date of <FIG>). Now, the validation time period <NUM> associated with Week <NUM> intermediate CA 310Ndi has elapsed and the January intermediate certificate authority 310Nci has issued a new intermediate certificate 210Nd<NUM> to the Week <NUM> intermediate CA 310Nd<NUM>. Likewise, the Week <NUM> intermediate CA 310Nd<NUM> issues a new certificate 210Ne<NUM> to a new Day <NUM> intermediate CA 310Ne<NUM>. The Week <NUM> intermediate CA 310Nd<NUM> will issue certificates 210N during the time period of January <NUM>, <NUM> to January <NUM>, <NUM> while the Day <NUM> intermediate CA 310Ne<NUM> will issue end entity certificates <NUM> for the day of January <NUM>, <NUM>.

Referring back to <FIG>, the remote system <NUM> generates a certificate revocation list (CRL) <NUM>. While in the given example, the system <NUM> provides a single aggregate CRL <NUM> at the top level of the chain of intermediate CAs 310N (i.e., intermediate CA 310Na in <FIG>), alternatively each intermediate CA 310N may include its own respective CRL <NUM>. The CRL <NUM> contains a list of each certificate 210N, <NUM> that the system <NUM> has issued and subsequently revoked.

Referring now to <FIG>, after the respective validation time period <NUM> of the lowest intermediate CA 310N in the chain of intermediate CAs 310N has passed, the remote system <NUM> may add, to the CRL <NUM>, one or more of the end entity certificates <NUM> generated from the lowest intermediate CA 310N in the chain of intermediate CAs 310N. That is, generally, certificates 210N, <NUM> may be added to the CRL <NUM> at any point after the validation time period <NUM> associated with the intermediate CA <NUM> that issued the certificate has passed or elapsed. Thus, the remote system <NUM> efficiently revokes the digital certificates <NUM> without relying on an expiration time recorded within the certificates themselves or on clocks of client devices.

Notably, there is no specific point in which certificates 210N, <NUM> must be added to the CRL <NUM>, and in fact the timing may vary significantly. In some examples, the remote system <NUM> adds the certificate <NUM> to the CRL <NUM> prior to the respective validation time period <NUM> elapsing. For instance, if the certificate <NUM> or the issuing CA <NUM> has been compromised (e.g., the private key exposed), the remote system <NUM> may revoke the certificate <NUM> early (i.e., before the period of validity <NUM> elapses). Here, the remote system <NUM> determines that a respective end entity certificate <NUM> is compromised and adds the respective end entity certificate <NUM> to the CRL <NUM> immediately.

On the other hand, the remote system <NUM> may wait any amount of time after the validation time period <NUM> has passed prior to adding the certificate <NUM> to the CRL <NUM>. For example, the remote system <NUM> waits until a replacement certificate <NUM> (i.e., a certificate <NUM> with a later issue date) is in place (i.e., the certificate <NUM> has been successfully rotated) prior to revoking the original certificate <NUM> to ensure there is no lapse in service. Thus, even after the validation time period <NUM> associated with a respective intermediate CA <NUM> has passed, it may be some time before each certificate <NUM> issued by that respective intermediate CA <NUM> to be revoked.

In the example view 500a of <FIG>, the Day <NUM> intermediate CA 310Ne<NUM> issued six end entity certificates <NUM> during its validation time period <NUM>. At this point, the validation time period <NUM> for the Day <NUM> intermediate CA 310Ne<NUM> has elapsed and the remote system <NUM> has added four of the six end entity certificates <NUM> to the CRL <NUM> (i.e., end entity certificates 210La, 210Lc, 210Le, 210Lf). However, two end entity certificates 210Lb, 210Ld issued by the Day <NUM> intermediate CA 310Ne<NUM> remain unrevoked. Referring now to the example view 500b in <FIG>, at this point in time, the remote system <NUM> has added all six certificates <NUM> issued by the Day <NUM> intermediate CA 310Ne<NUM> to the CRL <NUM>. Thus, the CRL <NUM> includes a total of six entries based on the certificates <NUM> issued by the Day <NUM> intermediate CA 310Ne<NUM>.

In the example view 500c of <FIG>, the remote system <NUM>, in some implementations, prunes the CRL <NUM> by removing each of the end entity certificates <NUM> from the CRL <NUM> issued by the Day <NUM> intermediate CA 310Ne<NUM> and adding the respective intermediate certificate 210Nei associated with the Day <NUM> intermediate CA 310Ne<NUM> to the CRL <NUM>. That is, when every end entity certificate <NUM> digitally signed by a respective intermediate CA 310N in the chain of intermediate CAs <NUM> has been added to the CRL <NUM> and the current time is at or after an end of the respective validation time period <NUM> of the respective intermediate CA 310N (i.e., the respective intermediate CA 310N cannot issue any new certificates <NUM>), the remote system <NUM> may replace all of the entries in the CRL <NUM> of certificates <NUM> issued by the respective intermediate CA <NUM> with just the certificate 210N of the respective intermediate CA <NUM>. Put another way, once the remote system <NUM> adds an intermediate CA 310N to the CRL <NUM>, every certificate <NUM> lower in the hierarchy may be pruned from the CRL <NUM>. As this process works its way up the chain of intermediate CAs <NUM>, this greatly reduces the size of the CRL <NUM>. In the example shown, after the year <NUM> is over, instead of listing the thousands or millions of certificates <NUM> potentially issued during the entire year, the CRL <NUM> can instead be collapsed or compressed to just a single entry of the certificate issued to the <NUM> intermediate CA 310Na<NUM>. It must be noted that adding a certificate <NUM> issued to a CA <NUM> breaks the chain of trust and thus all certificates <NUM> issued by that CA are immediately revoked. Therefore, generally the CA's certificate <NUM> is not added to the CRL <NUM> until all certificates <NUM> issued by the respective CA <NUM> have already been revoked unless there is cause to do otherwise (i.e., if the CA <NUM> has been compromised, it may be desirable to revoke all of its certificates <NUM> regardless of the state of the validation time period <NUM>).

Referring now to <FIG>, the digital certificate management system <NUM> generates a unique key 220N (e.g., a public key and a private key) for each generated intermediate certificate authority 310N. In the example where the validation time period <NUM> for the lowest intermediate CA 310N is a day and the validation time period <NUM> for the highest CA 310N in the chain is one year (<FIG>), the digital certificate management system <NUM> must generate, store, and distribute <NUM> keys per year (i.e., <NUM> days + <NUM> weeks + <NUM> months + <NUM> quarters + <NUM> year) with each key being provided to the respective intermediate CA 310N prior to that respective intermediate CA 310N issuing any certificates <NUM>.

To reduce key management overhead, in some implementations, each intermediate CA 310N is associated with a unique key 220N derived form a common seed value. In some examples, each unique key 220N is derived using a key derivation function (KDF) <NUM> (<FIG>). A KDF is a cryptographic function that derives one or more secret keys from a single secret value such as a master key <NUM> (<FIG>). For example, the KDF <NUM> is based on a one-step key derivation that accepts as input a secret byte string (i.e., the master key <NUM>) and a key-specific byte string.

Optionally, the key-specific byte string is encoded deterministically. In some examples, the key-specific byte string for a respective intermediate CA 310N includes an encoded path down the chain to the respective intermediate CA 310N and a number of steps (e.g., bits) in the path. The key-specific byte string may include other information such as key purpose and other context. Table <NUM> provides exemplary key-specific byte string information for a chain of intermediate CAs <NUM>10N. The table <NUM> includes a label <NUM> column, a path <NUM> column, and an encoded path <NUM> column. The label <NUM> indicates an identifier for the respective intermediate CA 310N (e.g., Switch, <NUM>, Q1, January, Week <NUM>, Day <NUM>, etc.). The path <NUM> indicates each intermediate CA 310N in the chain of intermediate CAs 310N from the top of the chain to the respective intermediate CA 310N. For example, the "January" intermediate CA 310N has a path that includes <NUM>, Q1, and January. Similarly, the "Day <NUM>" intermediate CA 310N has a path that includes <NUM>, Q1, January, Week <NUM>, and Day <NUM>.

The encoded path <NUM> includes a path length <NUM> of the path <NUM> that is dependent upon the number of intermediate CAs <NUM>10N in the path <NUM>. The encoded path <NUM> also includes a path encoding <NUM> of the path <NUM>. For example, the encoded path <NUM> of the intermediate CA 310N "Q1" has a path length <NUM> of [<NUM>] (because the corresponding path <NUM> includes <NUM> and Q1) and a path encoding <NUM> of [<NUM>] (for the year) and [<NUM>] (for the first quarter). Similarly, Week <NUM> has the encoded path <NUM> with a path length <NUM> of [<NUM>] (<NUM>, Q1, Jan, Week <NUM>) and a path encoding <NUM> of [<NUM>] [<NUM>] [<NUM>] [<NUM>] (for the year <NUM>, the first quarter, the first month, and the first week). In another example (not shown), an encoded path <NUM> intermediate CA 310N with a validation time period <NUM> that encompasses April <NUM>, <NUM> includes a path length <NUM> of [<NUM>] and a path encoding <NUM> of [<NUM>] [<NUM>] [<NUM>] [<NUM>] [<NUM>] for the year of <NUM>, the second quarter of <NUM>, the first month of the second quarter, the second week of the month, and the second day of the week.

Each encoded portion (i.e., each portion in brackets) may be encoded as one or more bytes (e.g., as a big-endian integer). The remote system <NUM> provides the KDF <NUM> with the encoded path <NUM> and a secret key to generate a unique key for each intermediate CA 310N. Other means of deterministically deriving keys are also contemplated. For example, the remote system <NUM> uses a key hierarchy model to generate key bits and partition the key bits into a key derivation key for each intermediate CA 310N. The key derivation function may support any sort of signing algorithms (such as elliptic-curve, RSA, etc.). Each key 220N the remote system <NUM> generates may be completely deterministic given the same secret key. That is, the remote system <NUM>, provided with the same secret key, may generate the same keys 220N for each intermediate CA 130N.

Referring now to <FIG>, in some implementations, the remote system <NUM> executes multiple instances <NUM>, 730a-n of the chain of intermediate CAs 310N. Multiple instances may provide additional redundancy (in case of failure), increased load capability, and other benefits. However, each instance must generate the same keys for each intermediate CA 310N so that a user device <NUM> or other entity verifying an issued certificates <NUM> may use any available instance <NUM>. Because, in some examples, the KDF <NUM> generates the keys 220N deterministically, distribution and synchronization of the keys 220N is greatly simplified. Here, the remote system shares the secret key <NUM> to the KDF <NUM> of each instance <NUM>. Because each instance uses the same KDF <NUM> with the same secret key <NUM>, the generated keys <NUM> that are distributed to each intermediate CA 310N are the same. Thus, the remote system only shares and synchronizes a single secret (the master key <NUM>) to synchronize each instance <NUM>.

<FIG> is a flowchart of an exemplary arrangement of operations for a method <NUM> for representing certificate expiration with time-based intermediate certificate authorities. The method <NUM>, at operation <NUM>, includes obtaining, at data processing hardware <NUM>, from a root certificate authority 310R, a root digital certificate 210R digitally signed by the root certificate authority 310R. At operation <NUM>, the method <NUM> includes generating, by the data processing hardware <NUM>, a chain of intermediate certificate authorities 310N. Each respective intermediate certificate authority 310N in the chain of intermediate certificate authorities 310N includes a respective intermediate certificate 210N digitally signed by the intermediate certificate authority 310N or the root certificate authority 310R that is immediately higher in the chain of intermediate certificate authorities 310N than the respective intermediate certificate authority 310N. Each respective intermediate certificate authority 310N also includes a respective validation time period <NUM> indicating a range of times when the respective intermediate certificate authority 310N is permitted to digitally sign intermediate certificates 210N and end entity certificates <NUM>. The respective validation time period <NUM> of the respective intermediate certificate authority 310N includes the validation time period <NUM> of each intermediate certificate authority 310N that is lower in the chain of intermediate certificate authorities 310N than the respective intermediate certificate authority 310N.

The method <NUM>, at operation <NUM>, includes generating, by the data processing hardware <NUM>, a certificate revocation list <NUM> for the chain of intermediate certificate authorities 310N. At operation <NUM>, the method <NUM> includes generating, by the data processing hardware <NUM>, from the lowest intermediate certificate authority 310N in the chain of intermediate certificate authorities 310N, a plurality of end entity certificates <NUM>. Each end entity certificate <NUM> of the plurality of end entity certificates <NUM> is digitally signed by the lowest intermediate certificate authority 310N in the chain of intermediate certificate authorities 310N. After the respective validation time period <NUM> of the lowest intermediate certificate authority 310N in the chain of intermediate certificate authorities 310N has elapsed, the method <NUM>, at operation <NUM>, includes adding, by the data processing hardware <NUM>, to the certificate revocation list <NUM>, one or more of the plurality of end entity certificates <NUM> generated from the lowest intermediate certificate authority 310N in the chain of intermediate certificate authorities 310N.

For example, it may be implemented as a standard server 900a or multiple times in a group of such servers 900a, as a laptop computer 900b, or as part of a rack server system 900c.

A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the scope of the disclosure. Accordingly, other implementations are within the scope of the following claims.

Claim 1:
A method (<NUM>) comprising:
obtaining, at data processing hardware (<NUM>), from a root certificate authority (310R), a root digital certificate (210R) digitally signed by the root certificate authority (310R);
generating, by the data processing hardware (<NUM>), a chain of intermediate certificate authorities (310N), each respective intermediate certificate authority (310N) in the chain of intermediate certificate authorities (310N) comprising:
a respective intermediate certificate (210N) digitally signed by the intermediate certificate authority (310N) or the root certificate authority (310R) that is immediately higher in the chain of intermediate certificate authorities (310N) than the respective intermediate certificate authority (310N); and
a respective validation time period (<NUM>) indicating a range of times when the respective intermediate certificate authority (310N) is permitted to digitally sign intermediate certificates (210N) and end entity certificates (<NUM>), the respective validation time period (<NUM>) of the respective intermediate certificate authority (310N) including the validation time period (<NUM>) of each intermediate certificate authority (310N) that is lower in the chain of intermediate certificate authorities (310N) than the respective intermediate certificate authority (310N);
generating, by the data processing hardware (<NUM>), a certificate revocation list (<NUM>) for the chain of intermediate certificate authorities (310N);
generating, by the data processing hardware (<NUM>), from the lowest intermediate certificate authority (310N) in the chain of intermediate certificate authorities (310N), a plurality of end entity certificates (<NUM>), each end entity certificate (<NUM>) of the plurality of end entity certificates (<NUM>) digitally signed by the lowest intermediate certificate authority (310N) in the chain of intermediate certificate authorities (310N); and
after the respective validation time period (<NUM>) of the lowest intermediate certificate authority (310N) in the chain of intermediate certificate authorities (310N) has elapsed, adding, by the data processing hardware (<NUM>), to the certificate revocation list (<NUM>), one or more of the plurality of end entity certificates (<NUM>) generated from the lowest intermediate certificate authority (310N) in the chain of intermediate certificate authorities (310N).