Migration to and from a Cryptographic Agile Hybrid Public Key Infrastructure

Abstract

In a general aspect, a digital certificate is generated. In some aspects, the method includes accessing a first root certificate of a root certification authority of a PKI system. The first root certificate includes a first public key based on a first cryptographic system and a first signature generated with a private key corresponding to the first public key. A second cryptographic agile root certificate is generated. The second cryptographic agile root certificate includes the first public key of the root certification authority, a second public key of the root certification authority based on a second cryptographic system, a second signature of the root certification authority generated with a second private key corresponding to the second public key, and a third signature of the root certification authority generated with the first private key. The second cryptographic agile root certificate is propagated to lower entities in the PKI system.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This patent application claims priority to U.S. Provisional Patent Application No. 63 / 352,828, filed on Jun. 16, 2022, and U.S. Provisional Patent Application No. 63 / 417,785, filed on Oct. 20, 2022, both entitled "Transition to and from an Encrypted Agile Hybrid Public Key Infrastructure". U.S. Provisional Patent Application No. 63 / 852,828 and U.S. Provisional Patent Application No. 63 / 417,785 are hereby incorporated by reference into this specification, respectively.

[0002] (Technical Field) The following description relates to the transition to and from an encrypted agile hybrid public key substrate.

Background Art

[0003] Cryptographic systems are used to communicate securely over public channels. For example, some cryptographic systems provide confidentiality by encrypting messages, and some cryptographic systems provide authenticity through digital signatures. Many cryptographic systems include protocols that use cryptographic keys. For example, in a public key infrastructure (PKI), the cryptographic keys include a public key and a private key for each entity, and a certificate authority can issue an electronic certificate to prove the public key.

Brief Description of the Drawings

[0004]

Figure 1A

Figure 1B

Figure 2A

Figure 2B

Figure 2C

Figure 2D

Figure 2E

Figure 3

Figure 4

Figure 5

[0005] In some aspects described herein, a public key infrastructure system is deployed and used in a cryptographically agile (crypto-agile) manner. For example, a public key infrastructure (PKI) system can be migrated from an old cryptographic system to a new cryptographic system in a secure manner. In some cases, a non-hybrid PKI system using an old cryptographic system can be migrated in parallel to a crypto-agile hybrid PKI system that uses both the old and new cryptographic systems. In some cases, a crypto-agile hybrid PKI system can be migrated to a new non-hybrid PKI system that uses only the new cryptographic system.

[0006] In some implementations, an Agile Hybrid PKI system can utilize Agile Hybrid certificates. U.S. Patent No. 9,660,978, titled "Using Electronic Certificates in Multiple Cryptographic Systems," incorporated herein by reference, describes examples of Agile Hybrid certificates linked to each other (see, e.g., FIG. 6 of U.S. Patent No. 9,660,978). For example, the X.509 standard for electronic certificates can store alternative public keys and signatures in the extensions of the electronic certificates (e.g., alternative cryptographic system extensions), which provides a tool for generating Agile Hybrid electronic certificates. As described in U.S. Patent No. 9,660,978, after such a certificate chain is established in a PKI system, the PKI system can operate with a mixture of old and new cryptographic systems (e.g., in some cases, achieving backward compatibility).

[0007] Here, we describe techniques and systems that can be used to convert an existing PKI system (e.g., a PKI system with non-hybrid standard certificates for an old cryptographic system) into an Agile Hybrid PKI system (e.g., a PKI system with Agile Hybrid certificates). In some implementations, to transition to such a state, while maintaining the continuous functionality of the PKI system, Agile certificates are gradually incorporated into the existing PKI system (e.g., without interruption). For example, a second Agile Hybrid certificate of a root certification authority (CA) can be inserted into the existing certificate chain. At that time, each intermediate certification authority can obtain a new Agile Hybrid certificate that replaces the old certificate of the intermediate certification authority in the certificate chain. Such a process can provide a smooth transition to an Agile Hybrid PKI system.

[0008] Here, we also describe techniques and systems that can be used to convert a cryptographic agile hybrid PKI system into a non-hybrid PKI system (e.g., a non-hybrid PKI system that uses non-hybrid standard digital certificates for a new cryptographic system). In some cases, converting to a non-hybrid PKI system completes the migration to a new cryptographic system. For example, a non-hybrid PKI system can utilize a standard PKI tree resulting from a root certificate in a non-hybrid standard certificate format using the new cryptographic system. By migrating to a non-hybrid PKI system, a cryptographic agile hybrid certificate chain can be converted into a standard certificate chain where the new cryptographic system elements are in the main storage of the certificate (e.g., the public key and CA signature fields). Migration to a non-hybrid PKI system involves generating a new root certificate with the new cryptographic system elements, and in addition, a verification end entity can obtain the new root certificate, and an identification end entity can receive a new certificate chain resulting from the new root certificate. The propagation of these updates can be time-consuming and there may be a mismatch between the identification end entity and the verification end entity. The techniques and systems described herein can handle such mismatches and enable end entities to utilize the PKI system even when the updates did not propagate to one or both of the end entities.

[0009] Therefore, aspects of the systems and techniques described herein can be used to improve the operation of communication systems (e.g., data networks, etc.), computer systems (e.g., network-connected computers, etc.), smart devices (e.g., so-called "Internet of Things" (IoT) devices, etc.), and other kinds of technologies. For example, a variety of state-of-the-art technologies rely on PKI systems for secure operation, and the techniques described herein can improve such computer-implemented systems, e.g., by making them more efficient, more secure, more cryptographically agile, more standards-compliant, or in some instances, providing other advantages. In some aspects, the systems and techniques described herein can provide improvements to existing systems for migrating between cryptographic systems. In some cases, the systems and techniques described herein can be implemented in a less cumbersome and non-disruptive manner, e.g., in a way that does not require an update to the operating system (OS) to drive changes on system components. For example, such improvements can be achieved in some cases by inserting a second self-signed certificate of the root CA into an existing certificate chain so that the second certificate can function as a trusted anchor in the PKI system, and the update can then be propagated through the PKI system, e.g., to intermediate CAs and end entities, without interruption of service. These and other techniques described herein can, in some cases, provide additional or different advantages and improvements.

[0010] Generally, a PKI system is a mechanism widely deployed to provide trust in public keys such that the public keys are trusted as belonging to legitimate identities. The PKI system utilizes a hierarchical tree of trust originating from a known trust root entity as the root certification authority (root CA). The root CA issues a root certificate that functions as a trust anchor for the PKI system. Such a PKI system is designed to provide assurance of the binding between a public key and an identity in the form of a digital certificate. The root CA provides assurance in the form of that certificate called the root certificate.

[0011] Due to their position at the top of the chain, root certificates can be self-signed and as a result, can be implicitly trusted through their addition to the trust store of an application or operating system. In the case where a root certificate needs to be replaced, the requirement for a new version needs to be propagated to all entities that need to verify the trust chain ending with the root certificate in question, and relying on the distribution of such entities can require cooperation and coordination among multiple corporate entities or business units. For example, replacing a root certificate with a certificate containing a new key and / or subject key identifier will simply and definitely invalidate all existing subordinate certificates. Therefore, traditional migration processes can become cumbersome (e.g., replacing a root certificate invalidates the entire trust chain it depends on). Traditional solutions such as cross-signing can mitigate this somewhat, while such solutions can potentially sacrifice appropriate flexibility if intermediate systems and clients need to be updated to maintain the new system. The technical problems associated with these traditional techniques can, in some cases, be solved by providing a migration path that allows the old system to remain usable during the migration process.

[0012] Encryption systems provide computational security, however, their security may degrade over time. Effective security requires changing the encryption system in anticipation of existing encryption systems being broken. Thus, users of encryption systems should act to migrate to a new encryption system before the existing encryption system becomes obsolete or is broken. The systems and techniques described herein can be used to migrate to a substitution cipher system in a way that ensures that all nodes within the system (root CAs, intermediate CAs, identifying end entities, verifying end entities) can support the substitution cipher system. For example, the migration process can transparently replace root certificates while maintaining backward compatibility and providing a path forward for building a new chain of trust, e.g., through a new encryption system, larger key sizes, or a quantum-safe encryption system.

[0013] PKI systems have been widely deployed in various environments, including identity authentication on the Internet. In this environment, PKI systems use digital certificates that chain from a root certificate to identifying end entities (such as web servers, users, etc.) through intermediate certificate authorities (intermediate CAs). PKI systems use public key cryptography as the basis for security. Anticipating the obsolescence of existing public key cryptography systems in PKI systems, it may be necessary to increase the key size or migrate to a different public key cryptography system. In a typical environment, it is necessary or desirable for the PKI system to continue to function without interruption during the migration. Traditional migration processes can be challenging due to the complexity and time required to propagate new cryptographic systems and root certificates and then require all nodes of the PKI system to switch to the new cryptographic system. In traditional migration processes, a second PKI system can be built using the new cryptographic system, and the two systems can be operated in parallel during the migration. However, this can require the construction and maintenance of two independent PKI systems, which can be quite costly and error-prone. Therefore, the systems and techniques described herein can provide an efficient and effective way to implement the migration of cryptographic techniques.

[0014] In some implementations, the transition can be achieved by generating a second cryptographic agile hybrid certificate of the root CA that uses the same public key as the original root certificate. By continuing to provide the existing public key, the existing first-level intermediate CA certificates signed by the original root certificate can be verified by the second cryptographic agile hybrid certificate of the root CA, and the root CA's certificate can be updated independently without requiring the other components of the PKI system to be changed simultaneously. In some implementations, the CA and end entities can install the cryptographic agile hybrid certificate and new cryptographic system processing capabilities asynchronously or non-sequentially before requiring the cryptographic agile hybrid certificate. In some cases, the second cryptographic agile hybrid certificate of the root CA is inserted between the root certificate and the certificates of the intermediate (first-level) CAs in the certificate chain. As a result, in some implementations, the potentially incomplete new chain can be propagated to any entity within the PKI system.

[0015] At that time, the second cryptographic agile hybrid certificate of the root CA can be further propagated to the intermediate CAs in several ways. The intermediate certificates can similarly use the same public key as their existing certificates to maintain the existing validation chain. The updated certificate chain can then be propagated to the end entity as a single certificate chained to the second cryptographic agile hybrid certificate of the root CA. This updated chain is sent along with the end entity certificate at authentication time.

[0016] After receiving the second cryptographic agile hybrid certificate of the root CA, the verifying end entity can verify the second cryptographic agile hybrid certificate using the original root certificate for the old cryptographic system. At that time, the verifying end entity can push the second cryptographic agile hybrid certificate of the root CA into their trust store through an existing mechanism that replaces the original root certificate.

[0017] In some implementations, the root CA generates a key pair for the new cryptographic system and constructs a second cryptographic agile hybrid certificate of the root CA that includes the public key of the original root certificate (e.g., the public key field) for itself, an alternative public key and signature for the new cryptographic system in the extensions (e.g., in the extensions for alternative cryptographic technologies), and a signature generated using the original private key of the CA for the old cryptographic system (e.g., in the CA signature field). The original private key of the CA used to generate the CA signature so that the second cryptographic agile hybrid certificate includes a similar public key corresponds to the original public key of the CA in the original root certificate.

[0018] In some implementations, intermediate CAs also implement cryptographic agile hybrid certificates and support for the new cryptographic system. Intermediate CAs can also request cryptographic agile hybrid certificates from higher-level CAs and can use the old public key at the standard public key location and the public key of the new cryptographic system in the extensions. Intermediate CAs receive cryptographic agile hybrid certificates along with a chain that includes the cryptographic agile hybrid certificate of the upper CA. These steps can also be repeated for downstream intermediate CAs until the lowest-level intermediate CA is reached.

[0019] In some implementations, an end entity can implement an Agile Hybrid Certificate for cryptography and support for a new cryptosystem, and can request an Agile Hybrid Certificate from a lowest-level CA. In some cases, the end entity receives a new Agile Hybrid Certificate along with an Agile Hybrid Certificate chain.

[0020] In some cases, a verification end entity (an entity that verifies the identity of an identifying end entity) receives a new Agile Hybrid Certificate and an Agile Hybrid Certificate chain from the identifying end entity. The verification end entity can validate the received certificate chain using an old cryptosystem, for example, if the verification end entity does not support the new cryptosystem. If the verification end entity supports the new cryptosystem, the verification end entity can verify the received certificate chain using the new cryptosystem. In some implementations, the verification end entity can mark the second Agile Hybrid Certificate of the root CA as trusted. In some cases, the second Agile Hybrid Certificate is marked as a trusted anchor after verifying the signature of the root CA in the second Agile Hybrid Certificate using the public key in the original root certificate.

[0021] In some cases, the original (non-hybrid) root certificate must be replaced with a new root certificate (e.g., if the original root certificate is about to expire soon, etc.), and the root certificate can be replaced in a way specified by the PKI system. In this case, the new root certificate can be a non-hybrid root certificate.

[0022] In some implementations, if an intermediate CA realizes that it can implement a new cryptographic system, implement the processing of cryptographic agile hybrid certificates, and a higher-level CA can issue a cryptographic agile hybrid certificate that supports the new cryptographic system, then it can request a new cryptographic agile hybrid certificate. For example, the intermediate CA can come to recognize that the higher-level CA can issue a cryptographic agile hybrid certificate that supports the new cryptographic system by receiving a notification from the higher-level CA, by receiving an updated cryptographic agile hybrid certificate chain from the higher-level CA, or by some other means.

[0023] In some implementations, an intermediate CA can request a new cryptographic agile hybrid certificate from a higher-level CA. If the higher-level CA does not respond, the intermediate CA can retry the request. In some implementations, the higher-level CA can respond that it is not ready. In some implementations, the higher-level CA can send its own cryptographic agile hybrid certificate chain.

[0024] In some implementations, the propagation of certificates can be initiated by the root CA notifying the first-level intermediate CAs that a new second cryptographic agile hybrid certificate of the root CA is available for insertion into the existing certificate chain. After being upgraded to handle cryptographic agile hybrid certificates and the new cryptographic system, the first-level intermediate CAs can request their own cryptographic agile hybrid certificates from the root CA and receive those new cryptographic agile hybrid certificates along with the second cryptographic agile hybrid certificates of the chained root CAs. The first-level intermediate CAs can then notify a plurality of second-level intermediate CAs that a new chain is available and, in the appropriate upgrade of the second-level intermediate CAs, provide the new chain to the second-level intermediate CAs. This process can be repeated until the lowest-level intermediate CAs receive the cryptographic agile hybrid certificates.

[0025] In some implementations, end entities can be upgraded to accommodate cryptographic agile hybrid certificates as well as the new cryptographic system, and the end entities can request a cryptographic agile hybrid certificate chain that includes the cryptographic agile hybrid certificate and the second cryptographic agile hybrid certificate of the root CA. The end entities can then use the cryptographic agile hybrid certificate chain to identify themselves to the verifying end entities.

[0026] In some cases, the propagation of a new certificate chain with an agile hybrid cryptographic certificate can occur with a chain that is only partially updated with the agile hybrid cryptographic certificate. In some implementations, the lower intermediate CAs require their issuing (upper) CA to sign the certificate with the new cryptographic system, resulting in the intermediate CAs being updated in a special order. As a result, both the lower intermediate CA and the issuing CA should be equipped to handle the agile hybrid cryptographic certificate and the new cryptographic system. Also, the issuing CA should have a private key that is valid and trusted in the new cryptographic system to sign the certificates of the lower CAs, and the issuing CA generally requires its own agile hybrid cryptographic certificate before signing. This means that certificate generation and deployment start at the root CA, proceed level by level within a tree of multiple intermediate CAs, and conclude at the end entity.

[0027] In some implementations, the installation of the agile hybrid cryptographic certificate and the new cryptographic system processing function at the intermediate CA can occur in any order or asynchronously, and each intermediate CA can complete the installation before the intermediate CA requests the agile hybrid cryptographic certificate from the upper CA. Some end entity systems (e.g., some smartphones, etc.) enable the user to trust the intermediate certificate. Some implementations have the security policy set so that a second agile hybrid cryptographic certificate (of the root CA) is trusted.

[0028] In some implementations, an end entity can trust a provided cryptographic agile hybrid certificate chain. For example, an end entity can validate a certificate chain up to a root certificate in an old cryptographic system. An end entity can also validate a certificate chain up to a second cryptographic agile hybrid certificate of a root CA in a new cryptographic system. Next, a new policy can be placed to trust the second cryptographic agile hybrid certificate of the root CA as a trusted anchor.

[0029] In some implementations, a cryptographic agile hybrid PKI system enables the coexistence of legacy as well as updated intermediate CAs and end entities within the PKI system. In some examples, all or part of a certificate chain extending from a cryptographic agile hybrid certificate of a root CA includes one or more non-hybrid certificates that do not include new cryptographic system elements. In some examples, all or part of a certificate chain includes a cryptographic agile hybrid certificate that includes new cryptographic system elements and old cryptographic system elements.

[0030] The systems and techniques described herein can be implemented in many different environments. In some environments, for example, full control of a PKI infrastructure such as an enterprise's or an enterprise's infrastructure is provided where mediation is available among multiple independent entities (certification authorities, browser / OS vendors, etc.). In some environments, for example, in a public PKI system (e.g., a public Internet PKI tree), control is distributed and the migration process is initiated by a public root CA. In some cases, the migration process can benefit from coordination between intermediate CAs and end entities, maintaining the security of old cryptographic systems, not compromising the private key of the root CA, and other means.

[0031] In some cases, the intermediate CA can generate a new key pair for the old cryptographic system when requesting a new cryptographic agile hybrid certificate. In this case, certificates issued after this point are signed with the new private key of the old cryptographic system, while certificates issued before this point are signed with the old private key of the old cryptographic system. Therefore, in such cases, the intermediate CA may need the old private key (e.g., for typical certificate revocation list (CRL) and online certificate status protocol (OCSP) operations), and should maintain the old certificates and the old key pair. When a typical CRL or OCSP process is executed, the intermediate CA can determine which old cryptographic system's private key should be used. Using the old key pair for the CSR to obtain a new cryptographic agile hybrid certificate may result in the same public key in the new certificate. Then, the same key pair remains valid for the old cryptographic system. Thus, the intermediate CA can delete the old certificates and simplify the CRL or OCSP process. The old signatures remain valid.

[0032] The identifying end entity, which is the certificate owner, e.g., a web server, always provides its certificate along with the certificate chain whenever it identifies itself. Thus, in some implementations, the identifying end entity can request a new cryptographic agile hybrid certificate with a new key pair for the old cryptographic system. However, there may be cases where benefits can be obtained from using the old key pair, e.g., enabling a verification end entity to cache previously received certificates from the same identifying end entity.

[0033] In some examples, any certificate chain in a PKI system starting from the root CA can remain valid at any point in time. Therefore, in some implementations, any intermediate CA can propagate a newer certificate chain, even when the intermediate CA itself does not have a cryptographic agile hybrid certificate.

[0034] Figure 1A is a block diagram showing an exemplary public key infrastructure system 100. The exemplary system 100 shown in FIG. 1A includes a root CA 102, two intermediate CAs 104, 106 and an end entity 108. In the example shown, the first-level intermediate CA 104 is subordinate to the root CA 102, the second-level intermediate CA 106 is subordinate to the first-level intermediate CA 104, and the end entity 108 is subordinate to the second-level intermediate CA 106. The public key infrastructure system 100 can include a plurality of intermediate CAs at the first level, additional CAs at the second level, additional end entities, or combinations thereof and other features not shown in FIG. 1A.

[0035] Figure 2A is a block diagram showing an initial state of a certificate chain in the public key infrastructure system 100. As shown in FIG. 2A, the certificate chain 200A includes four certificates for an old cryptosystem, namely the original non-hybrid certificate 162A of the root CA 102, the original non-hybrid certificate 164A of the first-level intermediate CA 104, the original non-hybrid certificate 166A of the second-level intermediate CA 106, and the original non-hybrid certificate 168A of the end entity 108. The old cryptosystem can be, for example, a cryptosystem that uses one or more cryptographic algorithms belonging to a category of vulnerable cryptographic techniques that have been migrated away. FIGS. 2B, 2C, 2D and 2E show the next state of the certificate chain when the cryptographic agile hybrid certificates are propagated from the root CA 102 to the intermediate CAs 104, 106 and the end entity 108. In various implementations, the distribution of the certificate chain includes propagating the certificates of the certificate chain to lower-level entities, starting with a certificate that is subordinate to the original root certificate 162A of the root certification authority 102. For example, in some implementations, the distribution of the certificate chain will include propagating a certificate that starts from the first-level intermediate certification authority 104. The original root certificate 162A of the root certification authority 102 is not distributed as part of the certificate chain.

[0036] In the example shown in FIG. 1A, the root CA 102 implements a cryptographic agile hybrid certificate and support for a new cryptographic system. The new cryptographic system can be, for example, a cryptographic system that uses one or more cryptographic algorithms belonging to a category of strong cryptographic technologies being migrated. In some examples, the root CA 102 increases the key size, changes to a new cryptographic system, or both. An exemplary format for digital certificates is defined by the ITU standard X.509, and an example of a cryptographic agile hybrid certificate is described in U.S. Patent No. 9,660,978. The X.509 standard for current digital certificates allows for storing alternative public keys and signatures (e.g., public keys and signatures for an alternative cryptographic system) in the extensions.

[0037] In the example shown in FIG. 1A, the original root certificate 162A for the old cryptographic system includes a public key 110 and a signature 112 generated for the old cryptographic system. The original root certificate 162A is a self-signed certificate, which means that the root CA 102 generates the CA's signature 112 by signing the CA's public key 110 (and additional data elements) with the CA's private key corresponding to the CA's public key 110.

[0038] In the example shown in FIG. 1A, the original root certificate 162A is the first root certificate, and the root CA 102 generates a second cryptographic agile hybrid certificate 162B. The extensions of the second cryptographic agile hybrid certificate 162B include a new public key 114 and a new signature 116 for the new cryptographic system. The second cryptographic agile hybrid certificate 162B holds the old public key 110 of the CA for the old cryptographic system and a signature 118 generated with the corresponding private key of the root CA for the old cryptographic system.

[0039] The second cryptographic agile hybrid certificate 162B is a self-signed certificate, meaning that the root CA 102 generates a signature 116 of the CA for the new cryptographic system by signing the public key 114 of the CA for the new cryptographic system (and additional data elements) with the secret key of the CA for the new cryptographic system (corresponding to the public key 114 of the CA), and the root CA 102 generates a signature 118 of the CA for the old cryptographic system by signing the old public key 110 of the CA for the old cryptographic system (and additional elements) with the secret key of the CA for the old cryptographic system (corresponding to the public key 110 of the CA). In some cases, the cryptographic agile hybrid certificate 162B of the root CA 102 can be generated using the process described in U.S. Patent No. 9,660,978 or in another way.

[0040] In the example shown, the root CA 102 signs the second cryptographic agile root hybrid certificate 162B with the existing secret key for the old cryptographic system. Therefore, the second cryptographic agile hybrid certificate 162B of the root CA 102 is self-signed by the original key pair of the old cryptographic system and has the same public key 110 as the original root certificate 162A. As shown in the example, the second cryptographic agile hybrid certificate 162B of the root CA 102 is self-signed using the new (alternative) cryptographic system, and the signature 126 of the CA for the new cryptographic system is stored in the extension of the second cryptographic agile hybrid certificate 162B. By continuing to provide the original public key 110, the existing intermediate and / or end entity certificates (164A, 166A, 168A) signed by the original root certificate 162A can continue to be verified by the second cryptographic agile hybrid certificate 162B of the root CA 102.

[0041] An updated certificate chain 200B including a second cryptographic agile hybrid certificate 162B of the root CA 102 is illustrated in FIG. 2B. As shown in FIG. 2B, the second cryptographic agile hybrid certificate 162B of the root CA 102 is inserted into the certificate chain 200B between the original non-hybrid certificate 162A of the root CA 102 and the original non-hybrid certificate 164A of the first-level intermediate CA 104.

[0042] As shown in FIG. 1A, after implementing the cryptographic agile hybrid certificate and support for the new cryptographic system, the first-level intermediate CA 104 requests a new certificate from the root CA 102 and receives a new cryptographic agile hybrid certificate 164B to replace its original non-hybrid certificate 164A. The first-level intermediate CA 104 also receives the second cryptographic agile hybrid certificate 162B of the root CA 102 as part of the certificate chain. In some implementations, the first-level intermediate CA 104 can receive a notification of the issuance of the cryptographic agile hybrid certificate from the root CA 102. The new cryptographic agile hybrid certificate 164B includes a first public key 120 generated by the old cryptographic system and a new public key 124 generated by the new cryptographic system. The new cryptographic agile hybrid certificate 164B also includes a first signature 128 that can be verified with the original public key 110 of the root CA 102, as well as a second signature 126 that can be verified with the new public key 114 of the root CA 102. In some cases, the cryptographic agile hybrid certificate 164B of the first-level intermediate CA 104 can be generated using the process aspects described in U.S. Patent No. 9,660,978 or in another way.

[0043] The updated certificate chain 200C, which includes the new cryptographic agile hybrid certificate 164B of the first-level intermediate CA 104, is shown in Figure 2C. As shown in Figure 2C, the new cryptographic agile hybrid certificate 164B of the first-level intermediate CA 104 replaces the original non-hybrid certificate 164A of the first-level intermediate CA 104. Therefore, the cryptographic agile hybrid certificate 164B is between the second cryptographic agile hybrid certificate 162B of the root CA 102 and the original non-hybrid certificate 166A of the second-level intermediate CA 106 in the certificate chain 200C.

[0044] As shown in Figure 1A, after implementing the cryptographic agile hybrid certificate and support for the new cryptographic system, the second-level intermediate CA 106 requests a new certificate from the first-level intermediate CA 104 and receives a new cryptographic agile hybrid certificate 166B to replace its original non-hybrid certificate 166A. The second-level intermediate CA 106 can also receive updated elements of the cryptographic agile hybrid certificate chain, including the second cryptographic agile hybrid certificate 162B of the root CA 102 and the cryptographic agile hybrid certificate 164B of the first-level intermediate CA 104. In some implementations, the second-level intermediate CA 106 can receive a notification of the issuance of the cryptographic agile hybrid certificate from the first-level intermediate CA 104.

[0045] As shown in FIG. 1A, the cryptographic agile hybrid certificate 166B includes a first public key 130 generated by an old cryptographic system and an updated public key 134 generated by a new cryptographic system. The new cryptographic agile hybrid certificate 166B also includes a first signature 138 verifiable with the old public key 120 of the first-level intermediate CA 104, as well as a second signature 136 verifiable with the new public key of the first-level intermediate CA 104. In some cases, the cryptographic agile hybrid certificate 166B of the second-level intermediate CA 106 can be generated using the processes described in U.S. Patent No. 9,660,978 or in another way.

[0046] An updated certificate chain 200D including the new cryptographic agile hybrid certificate 166B of the second-level intermediate CA 106 is shown in FIG. 2D. As shown in FIG. 2D, the new cryptographic agile hybrid certificate 166B of the second-level intermediate CA 106 replaces the original non-hybrid certificate 166A of the second-level intermediate CA 106. Therefore, the cryptographic agile hybrid certificate 166B is between the cryptographic agile hybrid certificate 164B of the first-level intermediate CA 104 and the original non-hybrid certificate 168A of the end entity 108 in the certificate chain 200D.

[0047] As shown in FIG. 1A, after implementation of the cryptographic agile hybrid certificate and support for a new cryptographic system, end entity 108 (which owns the original non-hybrid certificate 168A) requests a new certificate 168B from the second-level intermediate CA 106 and receives the new cryptographic agile hybrid certificate 168B to replace its original non-hybrid certificate 168A. In some implementations, end entity 108 can receive a notification of the availability of the new certificate 168B from the second-level intermediate CA 106. In some implementations, the identifying end entity 108 also receives updated elements of the cryptographic agile hybrid certificate chain including the second cryptographic agile hybrid certificate 162B of the root CA 102, the cryptographic agile hybrid certificate 164B of the first-level intermediate CA 106, and the cryptographic agile hybrid certificate 166B of the second-level intermediate CA 108.

[0048] As shown in FIG. 1A, the cryptographic agile hybrid certificate 168B includes a first public key 140 generated by an old cryptographic system and a new public key 144 generated by a new cryptographic system. In some examples, the public key 140 generated by the old cryptographic system need not be the same as the public key in the original certificate of the identifying end entity. In such examples, a new key pair for the old cryptographic system can be generated. The new cryptographic agile hybrid certificate 168B also includes a first signature 148 verifiable with the old public key 130 of the second-level intermediate CA 106 as well as a second signature 146 verifiable with the new public key 134 of the second-level intermediate CA 106. In some cases, the cryptographic agile hybrid certificate 168B of end entity 108 can be generated using the processes described in U.S. Patent No. 9,660,978 or in another manner.

[0049] The updated certificate chain 200E including the new cryptographic agile hybrid certificate 168B of the end entity 108 is shown in FIG. 2E. As shown in FIG. 2E, the new cryptographic agile hybrid certificate 168B of the end entity 108 replaces the original non-hybrid certificate 168A of the end entity 108. Therefore, the cryptographic agile hybrid certificate 168B is below the cryptographic agile hybrid certificate 166B of the second-level intermediate CA 106 in the certificate chain 200E.

[0050] After all or part of the certificate chain is updated as shown in FIGS. 2B, 2C, 2D, or 2E, the PKI system can start the transition from using cryptographic agile hybrid certificates (including elements of the old and new cryptographic systems) to using non-hybrid certificates that include only elements for the new cryptographic system. For example, as shown in FIG. 1B, after some or all of the verification end entities receive the cryptographic agile hybrid certificate chain and use the new cryptographic system to verify the certificate chain, the PKI system 100 can transition from the cryptographic agile hybrid certificate to a standard non-hybrid certificate for the new cryptographic system (e.g., a standard non-hybrid X.509 certificate, or another type).

[0051] For such a transition, a new root certificate 162C for the new cryptographic system can be generated and distributed to the verification end entity. The new non-hybrid root certificate 162C includes the public key 114 from the cryptographic agile hybrid certificate 162B. The new non-hybrid root certificate 162C is self-signed and includes a signature 152 generated with the private key corresponding to the public key 114. As shown in FIG. 1B, the first-level intermediate CA 104 can request a new non-hybrid certificate 164C. In some implementations, the new non-hybrid certificate 164C includes the public key 124 from the cryptographic agile hybrid certificate 164B. In other embodiments, the new non-hybrid certificate 164C can include a public key different from the public key 124 from the cryptographic agile hybrid certificate 164B. The new non-hybrid certificate 164C includes a signature 162 generated with the private key corresponding to the public key 114 of the root CA. Similarly, the second-level intermediate CA 106 can request a new non-hybrid certificate 166C. In some implementations, the new non-hybrid certificate 166C includes the public key 134 from the cryptographic agile hybrid certificate 166B. In other embodiments, the new non-hybrid certificate 166C can include a different public key from the cryptographic agile hybrid certificate 166B. The new non-hybrid certificate 166C includes a signature 172 generated with the private key corresponding to the public key of the first-level intermediate CA 104. In various embodiments, the public key of the first-level intermediate CA 104 can be the public key 124 from the cryptographic agile hybrid certificate 164B or a different public key. The identification end entity 108 can request a new non-hybrid certificate 168C. In some implementations, the new non-hybrid certificate 168C includes the public key 144 from the cryptographic agile hybrid certificate 168B. In other embodiments, the new non-hybrid certificate 168C can include a different public key from the cryptographic agile hybrid certificate 168B. The new non-hybrid certificate 168C includes a signature 182 generated with the private key corresponding to the public key of the second-level intermediate CA 106.In various embodiments, the public key of the intermediate CA 106 at the second level can be the public key 134 from the cryptographic agile hybrid certificate 168B or a different public key.

[0052] In a large-scale PKI system, it is not easy to distribute the new root certificate 162C to all verification end entities simultaneously. Meanwhile, the identification end entity 108 can obtain a new certificate chain resulting from the new non-hybrid root certificate 162C for the new cryptographic system. Thus, the following mismatch between the identification end entity and the verification end entity may occur. (1) The verification end entity still uses the old root certificate (e.g., certificate 162A in FIG. 1A) while the identification end entity sends a new certificate chain for the new cryptographic system. (2) The verification end entity has the new root certificate for the new cryptographic system (e.g., certificate 162C in FIG. 1B), but receives the cryptographic agile hybrid certificate chain from the identification end entity 108. Therefore, a mechanism for handling such a mismatch is provided.

[0053] To enable the issuance of cryptographic agile hybrid certificates, the CA can install resources for the new cryptographic system and resources for processing cryptographic agile hybrid certificates. For example, an entity such as an intermediate CA or an identified end entity may not be able to obtain a hybrid certificate if the issuing (upper-level) CA is not enabled to issue hybrid certificates. Typically, if the new cryptographic system and cryptographic agile hybrid certificate processing functions are installed from the root CA down to the identified end entity, it would be most effective and natural. The functions can be installed for the CA and the identified end entity in any order. However, the issuance of hybrid certificates occurs from the root CA downwards. According to this, the only form of a hybrid and non-hybrid mixed certificate chain is to have a hybrid certificate in the upper part and a non-hybrid certificate with old cryptographic system elements in the lower part. Thus, in the transition from a non-hybrid certificate chain with old cryptographic system elements to a hybrid certificate chain, the identified end entity can receive one of the following three forms of the certificate chain. (1) All non-hybrid certificates with old cryptographic system elements, (2) All hybrid certificates with old and new cryptographic system elements, and (3) A mixture of hybrid and non-hybrid certificates with a hybrid at the top of the chain.

[0054] Hybrid certificates provide backward compatibility, so as long as the public key of the same old cryptographic system as the original non-hybrid certificate with the old cryptographic system is placed in the hybrid certificate, the mixed chain (Form 3 described above) will not cause any problems. However, if it is desired to avoid mixing (Form 3), the intermediate CA can be maintained on a certificate chain of only the old cryptographic system (Form 1), and when the issuance of a non-hybrid old cryptographic system is required there, this chain is provided, and only when a hybrid certificate is required, the hybrid certificate chain is provided.

[0055] In hybrid cryptographic agile certificates, the same public key as the old cryptographic system is used except for the identifying end entity. The merit of using the same public key as the identifying end entity is very small, and the decision can be left to the implementer / operator.

[0056] When the hybrid certificate chain migrates to a non-hybrid certificate chain, the situation is different. Since all CAs on the path of the certificate chain can process hybrid certificates, these CAs can process the new cryptographic system. Therefore, at any point in time, any intermediate CA or identifying end entity can obtain a non-hybrid certificate with new cryptographic system elements. The identifying end entity can receive one of the following three forms of the certificate chain. (1) All hybrid certificates with the old cryptographic system and new cryptographic system elements, (2) All non-hybrid certificates with new cryptographic system elements, and (3) A mixture of hybrid certificates and non-hybrid certificates in any order. In this environment, non-hybrid certificates do not provide backward compatibility. Therefore, Form 2 or 3 can be used when it is certain that the verifying end entity has the ability to process the new cryptographic system. The identifying end entity can maintain a hybrid certificate chain, i.e., Form 1, until such time as it knows that all the verifying end entities it communicates with have the ability to process the new cryptographic system. Here, the mixed chain (Form 3) does not seem to have any significant advantages as the verifying end entity has to use the new cryptographic system. Moreover, Form 3 can make the chain validation process unnecessarily complex and may be ignored in some environments. This means that the identifying end entity can own Form 1 or Form 2, or both certificate chains. One strategy is that when a lower-level CA or the identifying end entity requests a non-hybrid certificate, each CA issues a non-hybrid certificate with a non-hybrid certificate chain (having only the new cryptography). If a hybrid certificate is requested, the CA issues a hybrid certificate with a hybrid certificate chain.

[0057] The new non-hybrid root certificate should use the same public key as in the alternative cryptographic extension of the root CA's second cryptographic agile hybrid certificate. However, all other non-hybrid certificates can use a new key pair and the decision can be left to the implementer / operator.

[0058] FIG. 3 is a block diagram of an exemplary PKI tree 300 for a PKI system that has at least partially migrated from a cryptographic agile hybrid certificate to a standard non-hybrid certificate for a new cryptography. The PKI tree 300 includes a root CA 302. The root CA 302 has a non-hybrid root certificate 304 for the new cryptosystem and a cryptographic agile hybrid certificate 306 for the new and old cryptosystems. In various embodiments, the root CA 302 can correspond to the root CA 102 illustrated in FIGS. 1A and 1B.

[0059] In the example shown in FIG. 3, the root certificate 304 is a non-hybrid, self-signed root certificate that includes a signature generated using the public key of the root CA for the new cryptosystem and the corresponding private key of the CA for the new cryptosystem. For example, the root certificate 304 can be a standard, self-signed root certificate for the new cryptosystem. The cryptographic agile hybrid certificate 306 of the root CA 302 can correspond to the second cryptographic agile hybrid certificate 162B of the root CA 102 shown in FIGS. 1A and 1B. In some examples, a non-hybrid, self-signed root certificate that includes the public key of the root CA for the old cryptosystem can be retained. Once the cryptographic agile hybrid certificate 306 of the root CA becomes a trusted anchor, the self-signed root certificate for the old cryptosystem cannot be used, however, the self-signed root certificate for the old cryptosystem remains as the root certificate of the hybrid certificate chain.

[0060] The PKI tree 300 also includes a first-level intermediate CA 308. In various embodiments, the first-level intermediate CA 308 can correspond to a separate example of the first-level intermediate CA 104 illustrated in FIGS. 1A and 1B. Each first-level intermediate certification authority 308 has a non-hybrid certificate 312 for the new cryptographic system and also has a cryptographic agile hybrid certificate 314 for the new and old cryptographic systems. Each non-hybrid certificate 312 can be a standard certificate for the new cryptographic system, and each non-hybrid certificate 312 is issued by the root certification authority 302. Each cryptographic agile hybrid certificate 314 can correspond to an example of the cryptographic agile hybrid certificate 164B shown in FIGS. 1A and 1B, and each cryptographic agile hybrid certificate 314 is issued by the root certification authority 302.

[0061] The PKI tree 300 also includes second-level intermediate CAs 316. In various embodiments, each second-level intermediate CA 316 can correspond to an example of the second-level intermediate CA 106 illustrated in FIGS. 1A and 1B. Each second-level intermediate CA 316 has a non-hybrid certificate 318 for the new cryptographic system and a cryptographic agile hybrid certificate 320 for the new and old cryptographic systems. Each non-hybrid certificate 318 can be a standard certificate for the new cryptographic system, and each non-hybrid certificate 318 is issued by one of the first-level intermediate CAs 308. Each cryptographic agile hybrid certificate 316 can correspond to an example of the cryptographic agile hybrid certificate 166B illustrated in FIGS. 1A and 1B, and each cryptographic agile hybrid certificate 320 is issued by one of the first-level intermediate CAs 308. While FIG. 3 illustrates the PKI tree 300 including the first-level intermediate CAs 308 and the second-level intermediate CAs 316, in various implementations, the PKI tree 300 can include any number of intermediate CAs and any number of levels. For example, in various implementations, the PKI tree 300 can include three or more intermediate CA levels, while in other implementations, the PKI tree 300 can include a single intermediate CA level.

[0062] The PKI tree 300 also includes an identifying end entity 322 that obtains a certificate issued by one of the second-level intermediate CAs 316. One or more identifying end entities 322 can have a non-hybrid certificate 324 for the new cryptographic system and can also have a cryptographic agile hybrid certificate 326 for the new and old cryptographic systems. In some examples, one or more end entities 322 have a cryptographic agile hybrid certificate 326 for the new and old cryptographic systems but do not yet have a non-hybrid certificate 324 for the new cryptographic system. Each non-hybrid certificate 324 of the end entity 322 can be a standard certificate for the new cryptographic system. Each cryptographic agile hybrid certificate 326 of the end entity 322 can correspond to an example of the cryptographic agile hybrid certificate 168B illustrated in FIGS. 1A and 1B.

[0063] In a typical use case, the certificate chain is provided by the identifying end entity and the trusted root certificate is available to the verifying end entity. When the identifying end entity provides its identity to the verifying end entity as a certificate and certificate chain, the identifying end entity sends only the certificate chain up to the first-level intermediate CA. The identifying end entity does not include the root certificate in the certificate chain it sends. It is the verifying end entity that owns the root certificate trusted by the verifying end entity. The verifying end entity uses its trusted root certificate to verify the signature on the first-level intermediate CA's certificate in order to complete the verification of the identifying end entity's certificate chain. Thus, a mismatch between the hybrid certificate chain and the non-hybrid certificate chain can occur, especially in the transition from a hybrid certificate chain to a non-hybrid certificate chain with new cryptographic system elements, between the identifying end entity's certificate chain and the root certificate owned by the verifying end entity.

[0064] In the issuance of non-hybrid certificates, the root CA issues a certificate to the first-level intermediate CA. At this level, there is no relevant certificate chain. However, in the issuance of hybrid certificates, the root CA sends its second cryptographic agile hybrid certificate as a chain from the root certificate to the first-level intermediate CA. Thus, lower-level intermediate CAs and identified end entities will receive additional certificates in the chain when hybrid certificates are used. The root CA's second cryptographic agile hybrid certificate is included in the certificate chain sent to the verifying end entity.

[0065] As shown in Figure 3, the identified end entity 322 can communicate with the verifying end entity 328. For example, the identified end entity 322 can represent a web server, and the verifying end entity 328 can represent a web browser that retrieves content from the web server. As part of this process, the identified end entity 322 identifies itself to the verifying end entity 328, and the verifying end entity 328 attempts to verify the identity of the identified end entity 322. Generally, any number of verifying end entities 328 can communicate with the identified end entity 322. Two example verifying end entities 328A, 328B are shown in Figure 3, where the first verifying end entity 328A communicates with the first identified end entity 322A, and the second verifying end entity 328B communicates with the second identified end entity 322B.

[0066] To verify the identification end entity 322, the verification end entity 328 uses a certificate-based identity authentication process. An exemplary certificate-based identity authentication process is described below, and these and other certificate-based identity authentication processes can be used. The certificate-based identity authentication process uses one of the certificates of the identification end entity 322 and the corresponding certificate chain from the PKI tree 300. In the certificate-based identity authentication process, the identification end entity 322 sends one of the certificates of the identification end entity 322 and the corresponding certificate chain to the verification end entity 328, and the verification end entity 328 verifies the certificate chain. The certificate chain is initially provided to the identification end entity 322 by the CA that issued the certificate of the identification end entity 322. Thus, when the CA issues a certificate, the CA creates a certificate chain that can be used with the certificate to verify the certificate.

[0067] When the verification end entity receives a hybrid certificate chain, it verifies the signature on the hybrid certificate of the first-level intermediate CA using the second cryptographic agile hybrid certificate of the root CA in the received certificate chain. It can verify the chain using the old cryptographic system or the new cryptographic system or both. At that time, the verification end entity can verify the signature on the second cryptographic agile hybrid certificate of the root CA using the root certificate of the root CA, which is a non-hybrid certificate of the old cryptographic system. In an example where the old cryptographic system is valid, this provides trust on the second cryptographic agile hybrid certificate of the root CA. It can be said that the second cryptographic agile hybrid certificate of the root CA is chained to the root certificate. After this, the verification end entity uses the second cryptographic agile hybrid certificate of the root CA as a trusted anchor certificate. Then, the verification of the certificate chain stops with the trusted anchor certificate, and the verification can only use the new cryptographic system. There is no need to hold the old root certificate of the old cryptographic system. Since the old root certificate and the new trusted anchor certificate contain the same public key, this is functional. In such an example, there is a single trusted anchor certificate of the root CA.

[0068] When a verification end entity receives a new root certificate along with new cryptographic system elements, if there are no identification end entities that use only old cryptographic techniques, the verification end entity is marked as a trusted anchor and no longer requires the second cryptographic agile hybrid certificate of the stored root CA. However, if some identification end entities still use only old cryptographic techniques, the second cryptographic agile certificate of the root CA is retained. Alternatively, if a security policy is deployed where the verification end entity rejects, for example, a non-hybrid certificate chain based on old cryptographic techniques and instead selects new cryptographic techniques beyond the old ones, the second cryptographic agile certificate of the root CA can be deleted. When the second cryptographic agile certificate of the root CA is deleted, only a single trusted anchor certificate of the root CA exists. This implies that this verification end entity has the ability to process new cryptographic systems, and this implication should usually be valid since the verification end entity received a root certificate for only the new cryptographic system.

[0069] Even if the certificate is a trusted anchor at the verification end entity, the hybrid certificate chain includes the second cryptographic agile hybrid certificate of the root CA. Consider the case where the verification end entity has the second cryptographic agile hybrid certificate of the root CA as a trusted anchor but does not include a new non-hybrid root certificate with new cryptographic technology. This verification end entity can receive one of the following two certificate chains: (1) all hybrid certificates, and (2) all non-hybrid certificates with new cryptographic system elements. If the verification end entity receives all hybrid certificate chains, it uses the trusted anchor to validate the chain. If it receives all non-hybrid certificate chains, the signature on the first-level intermediate CA can be verified by using the public key in the alternative cryptographic technology extension of the trusted anchor certificate. This works because the non-hybrid root certificate of the root CA has the same public key as the public key in this trusted anchor certificate.

[0070] Next, consider the case where the verification end entity has a new root certificate with a new cryptographic technology. If the identification end entity is not using an old non-hybrid certificate chain, or if the identification end entity rejects the old non-hybrid certificate chain through policy settings, this verification end entity can receive one of the following two certificate chains: (1) all hybrid certificates, and (2) all non-hybrid certificates with new cryptographic system elements. If it receives all hybrid certificate chains, it can use the new root signature to verify the signature in the second cryptographic agile hybrid certificate of the root CA, which is the last certificate in the chain. Alternatively, it can use the new root certificate to verify the signature in the alternative cryptographic technology extension of the first-level intermediate CA's certificate and skip the second cryptographic agile hybrid certificate of the root CA. This works because the public key in the alternative cryptographic technology extension of the second cryptographic agile hybrid certificate of the root CA is the same as the public key in this new non-hybrid root certificate. If the verification end entity receives all non-hybrid certificate chains, this is a non-hybrid procedure for chain verification. Thus, chain verification can be completed using the new root certificate.

[0071] (Certificate Generation) In the example shown in Figure 3, the root CA 302 uses the key pair of the new cryptographic system to generate a self-signed non-hybrid root certificate 304. This key pair is the same key pair used to generate the public key and signature in the alternative cryptographic technology extension of the second cryptographic agile hybrid certificate 306 of the root CA 302. The new root certificate 304 is distributed to the end entities 322, 328 at the appropriate time. In some examples, the root CA 302 can notify some or all of the subordinate entities of the availability of the new root certificate 304.

[0072] When the CA receives a certificate signing request ("CSR") from an entity, the CA can sign and issue a new certificate for the entity. To sign the new certificate, the CA generates a signature using one of its private keys. In various examples, the CA can sign the certificate issued by the CA using a new cryptosystem. In Method 1, when the Root CA 302 receives a CSR having only new cryptosystem elements, it signs only with the new cryptosystem. Thus, under Method 1, until all PKI system entities migrate to the new cryptosystem, the Root CA 302 maintains the Second Cryptographic Agile Hybrid Certificate 306 and the new Standard Root Certificate 304. Under Method 2, the Root CA 302 signs with the new cryptosystem even when a signature of the Cryptographic Agile Hybrid Certificate is required.

[0073] (Construction of Certificate Chain) To obtain a non-hybrid certificate for the new cryptographic system, the first-level intermediate CA 308 and the second-level intermediate CA 316 each request a non-hybrid certificate from the upper-level CA (e.g., the root CA 302 in the case of the first-level intermediate CA 308, or the first-level intermediate CA 308 in the case of the second-level intermediate CA 316) using only the new cryptographic system. To request a new non-hybrid certificate, the intermediate CA can use the same key pair (for the new cryptographic system) that was used to obtain the intermediate CA's existing cryptographic agile hybrid certificate. This helps to simplify the signing of the certificate revocation list ("CRL") or the Online Certificate Status Protocol ("OCSP"). Alternatively, the first-level intermediate CA 308 and the second-level intermediate CA 316 can generate a new key pair for the new cryptographic system to request a new non-hybrid certificate. However, in such a case, the first-level intermediate CA 308 and the second-level intermediate CA 316 can maintain their old key pairs so that they can sign the CRL or OCSP for these query entities that receive the cryptographic agile hybrid certificate chain instead of the new certificate chain.

[0074] In some implementations, the issuing CA may have to sign the OCSP response or CRL. During the transition from non-hybrid certificates with old cryptographic technologies to cryptographic agile hybrid certificates, since the hybrid certificate requires the private key of the old cryptographic technology, the CA still owns the private key of the old cryptographic technology. In such arrangements, the signature can be verified with the hybrid certificate or the old non-hybrid certificate.

[0075] During the transition from hybrid certificates to non-hybrid certificates for a new cryptographic system, the CA maintains the hybrid certificates. Thus, since the hybrid chain is still in use, the CA maintains the private keys of the old cryptographic system, meaning that some legacy verification entities that only have the functionality of the old cryptographic system still exist. However, once the migration of all end entities to the new cryptographic system is complete, the old private keys can be discarded.

[0076] In the example shown in Figure 3, after the intermediate CAs (308, 316) obtain non-hybrid certificates (312, 318) for the new cryptographic system, the identified end entity 322 can request a non-hybrid certificate for the new cryptographic system. In this case, the identified end entity 322 can use an existing key pair for the new cryptographic system (including the new public key in the existing cryptographic agile hybrid certificate 326 of the identified end entity), or can generate another key pair for the new cryptographic system. In Method 1, when the intermediate CA receives a certificate signing request (CSR) that only has elements of the new cryptographic system, it signs only with the new cryptographic system. Thus, the intermediate CA maintains the second cryptographic agile hybrid certificate and the corresponding certificate chain. In Method 2, even when a cryptographic agile hybrid certificate is requested, the intermediate CA signs only with the new cryptographic system, and the intermediate CAs (308, 316) provide a certificate chain that only includes non-hybrid certificates for the new cryptographic system.

[0077] (Verification End Entity Without New Root Certificate) In a typical PKI system, the distribution of new root certificates can be time-consuming, and each verification end entity can receive new root certificates at different times. For example, there may be a period during which the first verification end entity 328A has received a non-hybrid root certificate 304 for a new cryptographic system, while the second verification end entity 328B has not yet received the non-hybrid root certificate 304 for the new cryptographic system. In such a case, if the identification end entity 322B holds its cryptographic agile hybrid certificate 320, the verification end entity 328B receives the cryptographic agile hybrid certificate chain. At that time, the existing process for validating the cryptographic agile hybrid certificate chain 320 remains valid. However, the identification end entity 322B can instead use a certificate chain that does not include the cryptographic agile hybrid certificate (for example, if the identification end entity 322B did not hold its cryptographic agile hybrid certificate 320), and in such a case, the verification end entity 322B without the new root certificate 304 can develop a different method of certificate chain verification.

[0078] In the example shown in FIG. 3, the verification end entity 328B stored the second cryptographic agile hybrid certificate 306 of the root CA 302 as a trusted anchor. In some examples, the identification end entity 322B can send a certificate chain that includes only non-hybrid certificates to the verification end entity 328B. For example, the certificate chain can include the non-hybrid certificate 324 of the identification end entity 322B, the non-hybrid certificate 318 of the second-level intermediate CA 316, and the non-hybrid certificate 312 of the first-level intermediate CA 308. In such examples, the verification end entity 322B can utilize the public key (for the new cryptographic system) in the alternative cryptographic technology extension of the cryptographic agile hybrid certificate 306 of the root CA 302 to verify the signature on the non-hybrid certificate 312 of the first-level intermediate CA 308 (which is at the top of the certificate chain provided to the verification end entity 328B).

[0079] If Method 2 is deployed, the verification end entity 328B can receive a certificate chain of cryptographic agile hybrid certificates and non-hybrid certificates. The chain must be traced using the new cryptographic technology. That is, if standard certificates and hybrid certificates are mixed in the certificate chain, the verification end entity 328B must find the public key and signature either in the standard location or in the alternative cryptographic technology extension depending on the certificate type when tracing to the certificate chain for which the verification end entity 328B verifies the signature.

[0080] (Verification end entity with a new root certificate) In the example shown in FIG. 3, the verification end entity 328A obtained the non-hybrid root certificate 304 of the certification authority 302. If the identification end entity 322A also has a non-hybrid certificate chain (including the non-hybrid certificate 324 of the identification end entity 322A, the non-hybrid certificate 318 of the second-level intermediate CA 316, and the non-hybrid certificate 312 of the first-level intermediate CA 308), standard certificate chain verification can be used. However, if the identification end entity 322A still does not have a new certificate chain, an alternative certificate chain verification process can be used. Therefore, if the verification end entity 328A receives a hybrid certificate chain (a certificate chain including one or more cryptographic agile hybrid certificates) from the identification end entity 322A, the verification end entity 328A can select an appropriate certificate chain verification process.

[0081] When verifying a hybrid certificate chain from the identification end entity 322A, the verification end entity 328A uses the non-hybrid root certificate 304 to verify the signature of the root CA on the certificate of the first-level intermediate CA 308 (which is the top of the certificate chain). The public key of the new root certificate 304 is the same as the public key in the alternative cryptographic technology extension of the second cryptographic agile hybrid certificate 306 of the root CA 302. Thus, verification can be properly performed. If Method 2 is deployed, the verification end entity 322B can receive the certificate chains of the cryptographic agile hybrid certificates and non-hybrid certificates. The verification end entity 322B will be able to trace the chain with the new cryptographic technology. That is, if standard certificates and hybrid certificates are mixed in the certificate chain, when the verification end entity 328B traces up to the certificate chain whose signature the verification end entity 328B verifies, depending on the certificate type, the public key and signature must be found either in the standard location or in the alternative cryptographic technology extension.

[0082] In the example shown in FIG. 3, the intermediate CA can request non-hybrid certificates in any order because all CAs along the cryptographic agile hybrid certificate have the ability to process the new cryptographic system. If the CA uses the same key pair (including the public key in the alternative cryptographic technology extension of the CA's cryptographic agile hybrid certificate) to request a non-hybrid certificate, the hybrid certificate chain can still remain valid when the new cryptographic system is used. If the certificate chain is a mixture of hybrid certificates and non-hybrid certificates, different chain validation processes can be used. In some scenarios, when the identification end entity 328 requests a new certificate, it may be more practical for the identification end entity 328 to have a non-hybrid certificate obtained from the first-level intermediate CA so as to receive a new certificate chain that has only non-hybrid certificates (for a single cryptographic system). To ensure this result, each intermediate CA can delay issuing a non-hybrid certificate until the intermediate CA itself has the CA certificate chain of the non-hybrid certificate originating from the root CA 302.

[0083] In some cases, the migration to a non-hybrid (single cryptographic technology) certificate chain can occur in a specific part of the PKI system that originates from the root CA 302 (e.g., a designated subset of intermediate CAs, a designated subset of end entities, etc.) instead of the entire PKI system. In some cases, for example, when all verification end entities of the PKI subsystem are capable of processing a cryptographic agile hybrid certificate chain that includes the new cryptographic system and thus are capable of processing the new cryptographic system, the migration process can be carried out in a part of the PKI system that originates from a specific intermediate CA or a specific identified end entity. In such cases, since there are some identified end entities that are using the non-hybrid certificate chain with the old cryptographic system elements as a dependency, two root certificates (one with the old cryptographic system and the other with the new cryptographic system) coexist.

[0084] In some implementations, alternative solutions for PKI migration can be utilized. For example, in some implementations illustrated in FIG. 2B, a second cryptographic agile hybrid certificate of the root CA is used, but the other certificates in the certificate chain remain non-hybrid.

[0085] In some implementations, the first root certificate of the root CA (e.g., the original root certificate 162A in FIG. 1A) has been widely deployed and thus already exists in the trust stores of other entities (e.g., verification end entities, authentication end entities). The second cryptographic agile certificate of the root CA (e.g., the second cryptographic agile hybrid certificate 162B in FIG. 1A) will be deployed into the trust stores in other entities so that the second cryptographic agile certificate of the root CA can act as a trust anchor, thereby enabling the new cryptographic technology to be used for entity authentication.

[0086] Once the verification end entity receives the second cryptographic agile certificate of the root CA, the verification end entity can use the first root certificate of the root CA to verify the validity of the second cryptographic agile certificate of the root CA, and in a successful verification, add the second cryptographic agile certificate of the root CA to the trust store. Once in the trust store, the second cryptographic agile certificate of the root CA becomes a trust anchor that enables entity authentication using the new cryptographic technology system.

[0087] In various implementations, if the private key of the CA corresponding to the public key (e.g., 110 in FIG. 1A) included in the first root certificate of the root CA for the old cryptographic system becomes vulnerable (such that it can no longer be used securely), the verification end entity can use the public key of the CA for the new cryptographic system (114 in FIG. 1A) in the second cryptographic agile certificate of the root CA, for example, by chaining up to the second cryptographic agile certificate of the root CA for entity verification, and thus use the new cryptographic system.

[0088] Entity authentication using the public key of the CA for the old cryptographic system (e.g., 110 in FIG. 1A) can still be chained up to either the first root certificate of the root CA or the second cryptographic agile certificate of the root CA, while entity authentication using the public key of the CA for the new cryptographic system can be chained up to the second cryptographic agile certificate of the root CA. Therefore, the certificate verification platform still maintains backward compatibility with the public key of the CA for the old cryptographic system.

[0089] In some implementations, only the second cryptographic agile certificate of the root CA is a hybrid certificate. All other certificates (e.g., the original non-hybrid certificate 164A of the first-level intermediate CA 104, the original non-hybrid certificate 166A of the second-level intermediate CA 106, and the original non-hybrid certificate 168A of the end entity 108 in FIG. 1A) can be conventional non-hybrid certificates. Nevertheless, the presented system achieves migrating to new cryptographic technologies while maintaining backward compatibility with the keys of old cryptographic technologies.

[0090] In this scenario, if a certificate using the public key for the old cryptographic system is requested by the first-level intermediate CA 104, the root CA 102 issues a non-hybrid certificate for the old cryptographic system, and the second cryptographic agile hybrid certificate of the root CA is part of the certificate chain. The private key of the CA for the old cryptographic system can then be used to sign the non-hybrid certificate of the first-level intermediate CA 104. If a certificate utilizing the public key for the new cryptographic system is requested by the first-level intermediate CA 104, the root CA 102 can issue a non-hybrid certificate for the new cryptographic system, in which case the non-hybrid certificate is signed with the private key of the CA that matches the public key of the CA for the new cryptographic system in the extension of the second cryptographic agile hybrid certificate of the root CA.

[0091] Similar to the root CA 102, the intermediate CAs (104, 106) issue certificates for the old cryptographic system using the private key for the old cryptographic system corresponding to the public key in the first certificate of the intermediate CAs (104, 106) for the old cryptographic system. In various implementations, the first certificate of the intermediate CAs (104, 106) for the old cryptographic system can be, for example, the original non-hybrid certificate 164A of the first-level intermediate CA 104 or the original non-hybrid certificate 166A of the second-level intermediate CA 106. If a certificate for the new cryptographic system is requested, the intermediate CAs (104, 106) use the private key for the new cryptographic system corresponding to the public key in the non-hybrid certificate for the new cryptographic system. In various implementations, the intermediate CAs (104, 106) may have to maintain both the old and new certificates. In one scenario, the second cryptographic agile certificate of the root CA is always included in the certificate chain.

[0092] In various implementations, the identified end entity has a certificate chain for either the old or new cryptographic technology. In either case, the second cryptographic agile hybrid certificate of the root CA is part of the certificate chain as the only hybrid certificate. All other certificates, such as the certificates of the intermediate CAs (104, 106), are non-hybrid. In various implementations, the non-hybrid certificates of the intermediate CAs (104, 106) can include either the old or new cryptographic technology.

[0093] For the old cryptographic technology certificate chain, standard chain verification is applied. For the new cryptographic technology certificate chain, the chain verification can reach up to the second cryptographic agile hybrid certificate of the root CA, and the alternative public key in the second cryptographic agile hybrid certificate of the root CA can be used for verification.

[0094] In various implementations, the root CA 102 can generate a new root certificate with a public key for a new cryptographic system that is the same as that in the extension of the second cryptographic agile hybrid certificate of the root CA. A verification end entity having a new root certificate for the new cryptographic system stops using the second cryptographic agile hybrid certificate of the root CA and can directly verify the signature on the certificate of the first-level intermediate CA 104 using the new root certificate of the root CA 102.

[0095] FIG. 4 is a flow diagram illustrating an exemplary process 400 for updating a PKI system, such as the public key infrastructure system 100 discussed above with respect to FIGS. 1A and 1B or another type of PKI system. The exemplary process 400 can include additional or different steps, and the steps can be executed in the order shown or in a different order. In some cases, one or more steps can be repeated, omitted, or executed in another way. The process 400 can be executed by one or more computer nodes or devices, such as by one or more certificate authority nodes 514, 516 shown in FIG. 5, or by another type of computer system.

[0096] At 410, the first root certificate of the root certificate authority is accessed. By way of example, the root certificate authority can be the root CA 102 shown in FIG. 1A, and the first root certificate can be the original non-hybrid root certificate 162A shown in FIG. 1A. In the exemplary process 400, the first root certificate includes a first public key based on a first cryptographic system and a first signature generated with a secret key corresponding to the first public key. By way of example, the first public key can be the public key 110 in FIG. 1A, and the first signature can be the signature 112 illustrated in FIG. 1A.

[0097] At 420, a second cryptographic agile root certificate of the root certification authority is generated. As an example, the second cryptographic agile root certificate can be the second cryptographic agile root certificate 162B illustrated in FIGS. 1A and 1B. In the exemplary process 400, the second cryptographic agile root certificate of the root certification authority includes a first public key of the root certification authority and a second public key of the root certification authority based on a second cryptographic system. As an example, the second public key can be the public key 114 illustrated in FIGS. 1A and 1B.

[0098] In the exemplary process 400, the second cryptographic agile root certificate of the root certification authority also includes a second signature of the root certification authority generated with a second private key corresponding to the second public key. As an example, the second signature can be the signature 116 shown in FIGS. 1A and 1B. In the exemplary process 400, the second cryptographic agile certificate includes a third signature of the root certification authority generated with a first private key. For example, the third signature can be the signature 118 illustrated in FIGS. 1A and 1B. Accordingly, the second cryptographic agile root certificate of the root certification authority can be a self-signed certificate including two signatures of the root certification authority.

[0099] In 430, the second cryptographic agile root certificate is propagated to at least one subordinate entity in the PKI system. The subordinate entity can include an intermediate certification authority, an end entity, or both. In some cases, the subordinate entity includes multiple levels of certification authorities, such as, for example, a first-level intermediate certification authority (e.g., the first-level intermediate certification authority 104 shown in FIGS. 1A and 1B) and a second-level intermediate certification authority (e.g., the second-level intermediate certification authority 106 shown in FIGS. 1A and 1B). In some cases, the subordinate entity includes several end entities, such as, for example, the end entity 108 and additional end entities shown in FIGS. 1A and 1B. In some implementations, the second cryptographic agile root certificate is propagated to hundreds or thousands of entities, for example, throughout an enterprise or organization in the PKI system. In such cases, each first-level intermediate certification authority propagates the second cryptographic agile root certificate to one or more second-level intermediate certification authorities and others until all entities within the enterprise or organization are updated.

[0100] In the exemplary process 400, by propagating the second cryptographic agile root certificate, the second cryptographic agile root certificate is inserted into the certificate chain between the first root certificate and the intermediate CA's certificate, and the updated certificate chain (including the inserted certificate) can then be distributed to one or more lower entities in the PKI system. For example, the second cryptographic agile root certificate can be inserted into the certificate chain as illustrated in the exemplary certificate chains 200A and 200B shown in FIGS. 2A and 2B. In some cases, the second cryptographic agile root certificate can be inserted in another way. In some implementations, the second cryptographic agile root certificate is further propagated in the PKI system, for example, by initiating further updates in the certificate chain. For example, propagating the second cryptographic agile root certificate can include such further steps as those shown in FIGS. 1A, 2C, 2D, and 2E. In various implementations, distributing the certificate chain includes propagating the certificate chain to a lower entity that begins with a certificate lower than the original root certificate 162A of the root CA 102. For example, in some implementations, distributing the certificate chain would include propagating a certificate that begins with the second cryptographic agile root certificate 162B of the CA 104. The original root certificate 162A of the root CA 102 is not distributed as part of the certificate chain.

[0101] In an exemplary implementation of process 400, propagating the second cryptographic agile root certificate includes the root CA notifying the intermediate CA that the second cryptographic agile root certificate is available, whereupon the intermediate CA requests an updated certificate from the root CA, and the root CA then generates a second cryptographic agile certificate for the intermediate CA in response to the request and transmits the intermediate CA's second cryptographic agile certificate to the intermediate CA for use in the PKI system.

[0102] At 440, a new root certificate of the certification authority is generated. The new root certificate can be, for example, the certificate 162C shown in FIG. 1B or the certificate 304 shown in FIG. 3. In the exemplary process 400, the new root certificate includes the fourth signature of the root certification authority generated with the second public key and the second private key of the root certification authority. For example, the fourth signature can be the signature 152 shown in FIG. 1B. In some cases, the new root certificate is formatted according to a digital certificate standard, such as the X.509 digital certificate standard from ITU.

[0103] At 450, the new root certificate is propagated to at least one subordinate entity within the PKI system. In some cases, by propagating the new root certificate, the first root certificate and the second cryptographic agile certificate are replaced by the new root certificate within the certificate chain, and the updated certificate chain (including the new root certificate) can then be distributed to one or more subordinate entities within the PKI system. In various implementations, the distribution of the certificate chain includes propagating the certificates of the certificate chain to subordinate entities starting with the certificates below the root certificate of the root certification authority. For example, in some implementations, the distribution of the certificate chain will include propagating the certificates starting from the first-level intermediate certification authority. The root certificate of the root certification authority is not distributed as part of the certificate chain. In some implementations, the new root certificate is further propagated within the PKI system, for example, by initiating further updates within the certificate chain. For example, propagating the new root certificate can further include steps such as those described with respect to FIG. 1B. In some cases, the new root certificate is propagated through the PKI system to upgrade the PKI system from the first cryptographic system to the second cryptographic system (e.g., for a higher level of security, etc.). In some cases, when the propagation and upgrade are complete, the PKI system no longer uses the first cryptographic system.

[0104] FIG. 5 is a block diagram showing aspects of an exemplary computing environment 500. The exemplary computing environment 500 shown in FIG. 5 includes four nodes, namely two entity nodes 502, 504, and two certification authority nodes 514, 516. The nodes use a cryptographic system to communicate with each other via a network 506. The computing environment 500 can include additional or different features, and the components in the computing environment can be configured to operate as shown in FIG. 5 or in another way.

[0105] The nodes within the computing environment 500 can have a client-server relationship. For example, node 502 can be a server, and node 504 can be its client within a client-server network, and vice versa. In some implementations, the nodes within the computing environment 500 can have a peer-to-peer relationship. For example, nodes 502, 504 can act as peers within a client-server network, a peer-to-peer network, or another type of network. The nodes can have another type of relationship within the computing environment 500.

[0106] In some examples, the computing environment 500 uses a public key infrastructure (PKI) for cryptographic communication. In a typical public key infrastructure (PKI), entities can authenticate each other based on certificates issued by a trusted certification authority. Entities within the PKI (e.g., users, user accounts, devices, or machines, software modules, or other types of entities) each have a key pair that includes the user's identity and a public key and a private key, and the certification authority can issue a digital certificate to bind the public key to the user's identity of the entity.

[0107] In some exemplary PKIs, there are two types of digital certificates, namely, Certificate Authority (CA) certificates and end - entity certificates. CA certificates can be used to authenticate other certificates. End - entity certificates can be used to identify an entity (certificate owner). In the example shown in FIG. 5, each of entity nodes 502, 504 can be associated with an entity having an end - entity certificate, and each of certificate authority nodes 514, 516 can be associated with a certificate authority having a CA certificate.

[0108] In the example shown in FIG. 5, exemplary entity nodes 502, 504 and certificate authorities 514, 516 each have computer resources (e.g., hardware, software, firmware) used to communicate with other nodes. In some implementations, the nodes within computing environment 500 can be implemented within various systems such as, for example, laptops, desktops, workstations, smartphones, tablets, personal digital assistants, servers, server clusters, mainframes, and other types of computer systems. As shown in FIG. 5, exemplary node 516 includes a memory 510, a processor 511, and an interface 513. Each of entity nodes 502, 504 and certificate authority nodes 514, 516 can include the same, additional, or different components. In some cases, a single device can operate both as an entity node and as a certificate authority node.

[0109] In the exemplary node 516 shown in FIG. 5, the memory 510 can include, for example, a random access memory (RAM), a storage device (e.g., a writable read-only memory (ROM) or others), a hard disk, or another type of storage medium. The exemplary memory 510 can store an operating system, computer applications, and instructions (e.g., computer code, computer programs, etc.) associated with other resources. The memory 510 can also store application data and data objects that can be interpreted by one or more applications or virtual machines executed on the node 516. The node 516 can be pre-programmed or it can be programmed (and re-programmed) by loading a program from another source (e.g., from a DVD-ROM, from a removable memory device, from a remote server, from a data network, or in another way). In some cases, the memory 510 stores computer-readable instructions for software applications, scripts, programs, functions, executable files, or other modules that are to be interpreted or executed by the processor 511.

[0110] In the exemplary node 502 shown in FIG. 5, the processor 511 can execute instructions to generate output data, for example, based on data inputs. For example, the processor 511 can execute a computer program by executing or interpreting software, scripts, programs, functions, executable files, or other modules stored in the memory 510. The exemplary processor 511 shown in FIG. 5 can include one or more chips or chip sets including analog circuits, digital circuits, or combinations thereof. In some cases, the processor 511 can include multiple processor devices such as, for example, one or more main processors and one or more coprocessors. For example, the processor 511 can include a main processor that can assign a computer task to a coprocessor of cryptographic technology configured to execute the computer task more efficiently than the main processor or in parallel with other computer tasks executed by other processor devices. In some cases, the processor 511 can adjust and control the operation of other components of the node 516 such as, for example, user interfaces, communication interfaces, peripheral devices, and / or other components.

[0111] In the exemplary node 516 shown in FIG. 5, the interface 512 provides communication with other nodes or devices. In some cases, the interface 512 includes, for example, among other things, a wireless communication interface that provides wireless communication under various wireless protocols such as BLUETOOTH®, WiFi, Near Field Communication (NFC), GSM voice calls, SMS, EMS, or MMS messaging, wireless standards (e.g., CDMA, TDMA, PDC, WCDMA®, CDMA2000, GPRS). Such communication can be performed, for example, via a radio frequency transceiver or another type of component. In some cases, the interface 512 includes, for example, one or more input / output devices such as a keyboard, a pointing device, a scanner, or a wired communication interface (e.g., USB, Ethernet) that can be connected to a networking device such as a switch or a router via, for example, a network adapter.

[0112] The exemplary network 506 can include all or part of a connector, a data communication network, or another type of communication link. For example, the network 506 can include one or more wired or wireless connections, one or more wired or wireless networks or other communication channels. In some examples, the network 506 includes a Local Area Network (LAN), a Wide Area Network (WAN), a private network, a Virtual Private Network (VPN), a public network (such as the Internet, etc.), a peer-to-peer network, a cellular network, a WiFi network, a Personal Area Network (PAN) (e.g., a Low Energy Bluetooth® (BTLE) network, a ZigBee® network, etc.), or another short-range network including Machine-to-Machine (M2M) communication, or another type of data communication network.

[0113] Nodes within the exemplary computing environment 500 include other types of system components that use a secure communication module (e.g., virtual private network (VPN), secure web browsing, secure email, etc.) or PKI for authentication and use related cryptographic keys for identification (e.g., in a digital signature-based zero-knowledge proof or in another type of identification mechanism) to establish a trusted identity of the related entities. The security of such authentication and identification mechanisms may depend on one or more cryptographic systems (the "cryptosystems"). Examples of cryptosystems include various RSA-based cryptosystems, ECC-based cryptosystems, lattice-based cryptosystems, code-based cryptosystems, isogeny-based cryptosystems, and the like. A cryptosystem typically defines a set of parameters used within a protocol of the cryptographic technique and a protocol of the cryptographic technique.

[0114] In the example shown in FIG. 5, the computing environment 500 can utilize a digital signature system that is authenticated by digital certificates whose public keys are issued by the certification authority nodes 514, 516. The digital certificates can include the exemplary digital certificates described above with respect to FIGS. 1A and 1B. The digital certificates can form a certificate chain that includes a first root certificate, and a second cryptographic agile root certificate can be generated by one of the certification authority nodes 514, 516. The second cryptographic agile root certificate can then be propagated within the computing environment 500 to other entities and used by other entities. In some cases, a new root certificate is generated by one of the certification authority nodes 514, 516, and the new root certificate can then be propagated within the computing environment 500 to other entities and used by other entities. Exemplary processes for generating and propagating digital certificates have been described above. Digital certificates generated and propagated within an exemplary computing environment can be used (e.g., by entity nodes 502, 504) for certificate-based identity authentication.

[0115] (Certificate-based Identity Authentication Process) The certificate-based identity authentication process uses a PKI system, digital signatures, and digital certificates to establish functioning identity authentication. Digital signature algorithms are used to generate and verify digital signatures. In some cases, certificate-based identity authentication can be performed between two entities (where a "verifier" entity authenticates the identity of a "prover" entity) based on the following process.

[0116] 1. The verifier sends a random challenge to the prover.

[0117] 2. The prover appends its digital certificate to the random challenge in the certificate chain scheme.

[0118] 3. The prover signs the concatenated data above.

[0119] 4. The prover sends the concatenated data together with the signature.

[0120] 5. The verifier verifies the received signature using the public key within the prover's certificate.

[0121] 6. The verifier then validates / verifies the certificate chain and verifies the signatures on the certificates within the chain.

[0122] 7. For the last certificate in the chain, the verifier must use the trusted root certificate to verify the signature on the certificate.

[0123] In the exemplary process outlined above, the prover provides a digital certificate to the verifier. The prover signs the concatenation of the random challenge and the digital certificate and sends the concatenated data and digital signature to the verifier. The reason for the random challenge is to prevent replay attacks. The verifier verifies the prover's signature on the concatenated data to confirm data integrity and private key ownership. Next, the verifier checks the CA's signature on the certificate to obtain assurance that this prover is legitimate. The digital certificate of this CA is used to verify the signature and obtain the CA's public key. A higher-level CA that vouches for the intermediate CA can also be used. In this case, the prover provides not only its own digital certificate but also the digital certificate of the intermediate CA. The verifier uses the digital certificate of the intermediate CA to verify the digital signature on the prover's digital certificate. The public key of the higher-level CA is used to verify the digital signature on the digital certificate of the intermediate CA. Thus, the digital certificate of the higher-level CA is required. There are multiple hierarchical certificates concatenated by signatures from the higher-level CA to the intermediate CA and then to the prover. Based on this certificate chain, the verifier uses a certificate chain validation process or a certificate chain verification process to verify the signatures on these digital certificates.

[0124] Some of the subject matter and operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware that includes the structures disclosed in this specification and combinations of one or more of those structures. Some of the subject matter described in this specification can be implemented as one or more computer programs, i.e., as modules of one or more computer program instructions encrypted on a computer storage medium for execution by, or to control the operation of, a data processing apparatus. The computer storage medium can be, or can include, a computer-readable storage device, a computer-readable storage circuit board, a random access memory array or serial access memory array or device, or a combination of one or more of them, or can be included in them. Moreover, while the computer storage medium is not a propagated signal, the computer storage medium can be the source or destination of computer program instructions encrypted in an artificially generated propagated signal. The computer storage medium can also be, or can include, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices), or can be included in them.

[0125] Some of the operations described in this specification can be implemented as operations executed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[0126] The term "data processing apparatus" encompasses all kinds of devices, apparatuses, and machines for processing data, including, by way of example, programmable processors, computers, system-on-chips, or a plurality thereof, or combinations of the foregoing. The apparatus can include application-specific logic circuitry, such as, for example, an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit). The apparatus can also include code for creating an execution environment for a computer program in question in addition to the hardware, that is, code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of these.

[0127] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language including compiled languages, interpreted languages, declarative languages, or procedural languages, and it can be deployed in any form including as a stand-alone program or as a module, component, subroutine, object, or other suitable unit for use in a computing environment. A computer program can correspond to a file in a file system, but this is not required. The program can be stored in part of a file that holds other programs or data (such as one or more scripts stored in a markup language document), in a single file that holds the program, or in a plurality of coordinated files (such as files that hold one or more modules, subprograms, or portions of code). A computer program can be deployed to be executed on one computer or on a plurality of computers located at one site or distributed across a plurality of sites and interconnected by a communication network.

[0128] Some of the processes and logic flows described in this specification can be performed by one or more programmable processors that execute one or more computer programs to perform actions by operating input data and generating output. The processes and logic flows can also be performed by special-purpose logic circuits, such as, for example, FPGAs (Field Programmable Gate Arrays) or ASICs (Application Specific Integrated Circuits), and the apparatus can also be implemented as special-purpose logic circuits, such as, for example, FPGAs (Field Programmable Gate Arrays) or ASICs (Application Specific Integrated Circuits).

[0129] Suitable processors for the execution of a computer program include, by way of example, both general-purpose and special-purpose microprocessors as well as processors for any kind of digital computer. In general, a processor will receive instructions and data from a read-only memory or a random access memory or both. The elements of a computer can include a processor that executes actions in accordance with the instructions and one or more memory devices that store the instructions and data. A computer can also include or be operatively coupled to one or more mass storage devices for storing data, such as, for example, a non-magnetic drive (e.g., a solid-state drive), a magnetic disk, a magneto-optical disk, an optical disk, or to receive data from, transfer data to, or both of these. However, a computer does not necessarily require such devices. Further, a computer can be incorporated into another device, such as, for example, a telephone, an electronic appliance, a mobile audio or video player, a game console, a global positioning system (GPS) receiver, an Internet of Things (IoT) device, a machine-to-machine (M2M) sensor or actuator, or a portable storage device (e.g., a universal serial bus (USB) flash drive). Suitable devices for storing computer program instructions and data include all kinds of non-volatile memories, media, and memory devices, such as, by way of example, semiconductor memory devices (e.g., EPROM, EEPROM, flash memory devices, etc.), magnetic disks (e.g., internal hard disks, removable disks, etc.), magneto-optical disks, and CD-ROM and DVD-ROM disks. In some cases, the processor and memory can be supplemented by, or incorporated in, special-purpose logic circuitry.

[0130] To provide interaction with a user, the operations can be implemented on a computer having a display device (e.g., a monitor or another type of display device) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse, trackball, tablet, touch screen, or another type of pointing device) by which the user can provide input to the computer. Other types of devices can be used to provide for interaction with the user, and moreover, for example, feedback provided to the user can be in any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and input from the user can be received in any form including acoustic input, voice input, or tactile input. Additionally, the computer can interact with the user by sending documents to and receiving documents from the devices used by the user, for example, by sending a web page to a web browser on the user's client device in response to a request received from the web browser.

[0131] A computer system can include a single computing device or multiple computers that operate in proximity to each other or generally remotely and typically interact via a communication network. Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), Internet networks (e.g., the Internet), networks including satellite links, and peer-to-peer networks (e.g., ad hoc peer-to-peer networks). The client and server relationships can arise by virtue of computer programs executed on respective computers that have a client-server relationship with each other.

[0132] In a general aspect, the systems and techniques described herein enable migrating to and from a hybrid cryptographic agile public key infrastructure system.

[0133] In a first example, the method includes accessing a first root certificate of a root certification authority of a PKI system. The first root certificate is generated with a first public key based on a first cryptographic system, a secret key corresponding to the first public key, and includes a first signature. A second cryptographic agile root certificate of the root certification authority is generated. The second cryptographic agile root certificate includes the first public key of the root certification authority, a second public key of the root certification authority based on a second cryptographic system, a second signature of the root certification authority generated with a second secret key corresponding to the second public key, and a third signature of the root certification authority generated with the first secret key. The second cryptographic agile root certificate is propagated to at least one subordinate entity in the PKI system. By propagating the second cryptographic agile root certificate, the second cryptographic agile root certificate is inserted into a certificate chain between the first root certificate and a certificate of an intermediate certification authority.

[0134] The implementation of the first example can include notifying an intermediate certification authority that a second cryptographic agile root certificate is available. Propagating the second cryptographic agile certificate to a lower entity can include generating the second cryptographic agile certificate of the intermediate certification authority in response to a request from the intermediate certification authority. The second cryptographic agile certificate of the intermediate certification authority can include the first public key of the intermediate certification authority based on the first cryptographic system, the second public key of the intermediate certification authority based on the second cryptographic system, the first signature generated with the first private key of the root certification authority, and the second signature generated with the second private key of the root certification authority. The second cryptographic agile certificate of the intermediate certification authority is sent to the intermediate certification authority. In some cases, the intermediate certification authority can be a first-level intermediate certification authority, and propagating the second cryptographic agile root certificate to a lower entity includes propagating the second cryptographic agile root certificate to a plurality of intermediate certification authorities and a plurality of end entities. The plurality of certification authorities can include a first-level intermediate certification authority and a second-level intermediate certification authority.

[0135] In some implementations of the first example, propagating the second cryptographic agile root certificate to a lower entity includes propagating the second cryptographic agile root certificate to a plurality of first-level intermediate certification authorities. Each of the plurality of first-level intermediate certification authorities can further propagate the second cryptographic agile root certificate to one or more second-level intermediate certification authorities.

[0136] In some implementations of the first example, after the second cryptographic agile root certificate is propagated, a new root certificate of the certification authority is generated. The new root certificate includes the fourth signature of the root certification authority generated with the second public key and the second private key of the root certification authority. The new root certificate is propagated to at least one lower entity. By propagating the new root certificate, the first root certificate and the second cryptographic agile certificate are replaced by the new root certificate in the certificate chain. The new root certificate is propagated to upgrade the PKI system from the first cryptographic system to the second cryptographic system, and the new root certificate is formatted according to the digital certificate standard.

[0137] In the second example, the system includes one or more processors and a memory storing executable instructions that, when executed by one or more processors for performing one or more operations of the first example. In the third example, a non-transitory computer-readable medium includes instructions for performing one or more operations of the first example when executed by a data processing apparatus of a computer system.

[0138] While this specification includes many details, these should be understood as descriptions of specific features of particular examples rather than limitations within the scope of what can be claimed. In the context of separate implementations, the specific features described or illustrated in this specification can also be combined. Conversely, the various features described and illustrated in the context of a single implementation can also be implemented separately or in any suitable sub-combination in multiple embodiments.

[0139] While operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in a sequential order, or that all illustrated operations be performed, to achieve a desirable result. Depending on the situation, multitasking and parallel processing may be used. Further, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the program components and systems described may generally be integrated together in a single product or packaged into multiple products.

[0140] Numerous embodiments have been described. Nevertheless, it will be understood that various modifications can be made. Accordingly, other embodiments are within the scope of the following claims.

Claims

1. Accessing a first root certificate of a root certification authority in a PKI system, wherein the first root certificate includes the first public key based on a first signature generated by a first cryptographic system and a private key corresponding to the first public key, and accessing; generating a second cryptographic agile root certificate of the root certification authority, wherein the second cryptographic agile root certificate includes the first public key of the root certification authority, a second public key of the root certification authority based on a second cryptographic system, a second signature of the root certification authority generated by a second private key corresponding to the second public key, and a third signature of the root certification authority generated by the first private key, and generating; and propagating the second cryptographic agile root certificate to at least one subordinate entity in the PKI system, wherein by propagating the second cryptographic agile root certificate, the second cryptographic agile root certificate is inserted into a certificate chain between the first root certificate and a certificate of an intermediate certification authority, and propagating; A method comprising the steps of:

2. Propagating the second cryptographic agile root certificate includes notifying the intermediate certification authority that the second cryptographic agile root certificate is available, The method according to claim 1.

3. The propagating further includes generating a second cryptographic agile certificate of the intermediate certification authority in response to a request from the intermediate certification authority, wherein the second cryptographic agile certificate of the intermediate certification authority includes the first public key of the intermediate certification authority based on the first cryptographic system, a second public key of the intermediate certification authority based on the second cryptographic system, a first signature generated by the first private key of the root certification authority, and a second signature generated by the second private key of the root certification authority, and generating; transmitting the second cryptographic agile certificate of the intermediate certification authority to the intermediate certification authority. The method according to claim 2.

4. The intermediate certification authority is a first-level intermediate certification authority, and propagating the second cryptographic agile root certificate includes propagating the second cryptographic agile root certificate to a plurality of intermediate certification authorities and a plurality of end entities. The method according to claim 2.

5. The method according to claim 4, wherein the plurality of certification authorities includes the intermediate certification authority of the first level and the intermediate certification authority of the second level.

6. The method according to claim 1, wherein propagating the second cryptographic agile root certificate includes propagating the second cryptographic agile root certificate to a plurality of intermediate certification authorities of the first level.

7. The method according to claim 6, wherein each of the plurality of intermediate certification authorities of the first level propagates the second cryptographic agile root certificate to one or more intermediate certification authorities of the second level.

8. Furthermore, after propagating the second cryptographic agile root certificate, generating a new root certificate of the certification authority, wherein the new root certificate includes the second public key of the root certification authority, and a fourth signature of the root certification authority generated with the second private key, including generating; propagating the new root certificate to the at least one lower entity, wherein by propagating the new root certificate, the first root certificate and the second cryptographic agile certificate are replaced by the new certificate in the certificate chain, including propagating; The method according to claim 1.

9. The method according to claim 8, wherein the new root certificate is propagated to upgrade the PKI system from the first cryptographic system to the second cryptographic system, and the new root certificate is formatted according to digital certificate standards.

10. One or more processors; a memory storing executable instructions that are operable when executed by the one or more processors to perform operations, accessing a first root certificate of a root certification authority of a PKI system, wherein the first root certificate includes a first public key based on a first cryptographic system, and a first signature generated with a private key corresponding to the first public key, including accessing; generating a second cryptographic agile root certificate of the root certification authority, wherein the second cryptographic agile root certificate includes the first public key of the root certification authority, a second public key of the root certification authority based on a second cryptographic system, and a second signature of the root certification authority generated with a second private key corresponding to the second public key, and the third signature of the root certification authority generated with the first secret key, and including generating, propagating the second cryptographic agile root certificate to at least one lower entity in the PKI system, wherein by propagating the second cryptographic agile root certificate, the second cryptographic agile root certificate is inserted into the certificate chain between the first root certificate and the certificate of the intermediate certification authority, and propagating, and a memory including; a computer system including.

11. The computer system according to claim 10, wherein propagating the second cryptographic agile root certificate includes notifying the intermediate certification authority that the second cryptographic agile root certificate is available.

12. The propagating further includes, generating a second cryptographic agile certificate of the intermediate certification authority in response to a request from the intermediate certification authority, the second cryptographic agile certificate of the intermediate certification authority is the first public key of the intermediate certification authority based on the first cryptographic system, the second public key of the intermediate certification authority based on the second cryptographic system, the first signature generated with the first secret key of the root certification authority, and the second signature generated with the second secret key of the root certification authority, including generating, sending the second cryptographic agile certificate of the intermediate certification authority to the intermediate certification authority, and the computer system according to claim 11.

13. The computer system according to claim 11, wherein the intermediate certification authority is a first-level intermediate certification authority, and propagating the second cryptographic agile root certificate includes propagating the second cryptographic agile root certificate to a plurality of intermediate certification authorities and a plurality of end entities.

14. The computer system according to claim 13, wherein a plurality of certification authorities include the first-level intermediate certification authority and the second-level intermediate certification authority.

15. The computer system according to claim 10, wherein propagating the second cryptographic agile root certificate includes propagating the second cryptographic agile root certificate to a plurality of first-level intermediate certification authorities.

16. The operation further includes, after propagating the second cryptographic agile root certificate, generating the new root certificate of the certification authority, The new root certificate is generated to include the second public key of the root CA and the fourth signature of the root CA generated with the second private key, and propagating the new root certificate to the at least one or more subordinate entities, wherein propagating the new root certificate replaces the first root certificate and the second cryptographic agile certificate in the certificate chain with the new root certificate, The computer system according to claim 10, comprising

17. A non-transitory computer-readable medium containing instructions to perform operations, when executed by a data processing device of a computer system, access the first root certificate of the root CA of the PKI system, wherein the first root certificate includes a first public key based on a first cryptographic system and a first signature generated with a private key corresponding to the first public key, generate a second cryptographic agile root certificate of the root CA, wherein the second cryptographic agile root certificate includes the first public key of the root CA, a second public key of the root CA based on a second cryptographic system, a second signature of the root CA generated with a second private key corresponding to the second public key, and a third signature of the root CA generated with the first private key, and propagating the second cryptographic agile root certificate in the PKI system to at least one subordinate entity, wherein propagating the second cryptographic agile root certificate inserts the second cryptographic agile root certificate into the certificate chain between the first root certificate and the certificate of the intermediate CA, The non-transitory computer-readable medium, comprising

18. The non-transitory computer-readable medium according to claim 17, wherein propagating the second cryptographic agile root certificate includes notifying the intermediate CA that the second cryptographic agile root certificate is obtainable.

19. Furthermore, the propagating includes generating a second cryptographic agile certificate of the intermediate CA in response to a request from the intermediate CA, wherein the second cryptographic agile certificate of the intermediate CA ​ the first public key of the intermediate certification authority based on the first cryptographic system, the second public key of the intermediate certification authority based on the second cryptographic system, a first signature generated with the first private key of the root certification authority, and a second signature generated with the second private key of the root certification authority, and generating, transmitting the second cryptographic agile certificate of the intermediate certification authority to the intermediate certification authority, A non-transitory computer-readable medium according to claim 18, comprising: **Claim 20** The intermediate certification authority is a first-level intermediate certification authority, and propagating the second cryptographic agile root certificate includes propagating the second cryptographic agile root certificate to a plurality of intermediate certification authorities and a plurality of end entities. A non-transitory computer-readable medium according to claim 18.

Images