### Description This use case will cover the crypto-agility aspects of the signing algorithm for certificates issued by a public Certificate Authority (CA) from the perspective of a subscriber. In particular, the CA will be one which has been designated by the organization as being allowed to issue certificates on domain names belonging to that organization. The actions of an individual entity during the certificate lifecycle are handled in [[End-Entity Certificate Requirements]] For concreteness, we will assume that there will be a simple three-level hierarchy: - root -> intermediate -> end-entity. ### Discovery / Inventory It is important to have a list of all CAs from which the organization can obtain certificates. For each such CA, the following should appear in an inventory: - The different types of certificates available (e.g., Class 3 server, Class 2 client, Extended Validation); - For each type, an inventory of the actual certificates which have been issued. For each certificate, this should include: - Fully Qualified Domain Names (FQDNs) and Subject Alternate Names (SANs), or other identifying information appropriate to the certificate use case - Certificate Expiry - Algorithm, fingerprint and/or public key - Locations where the CA certificates exists - Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) server. Most public CAs provide an inventory of the certificates it issues. Alternatively, there are scanning tools available that can find certificates in use on different systems within an environment. Organizations should balance their security needs with their needs for usability and availability when considering such automated tools. ### Migration Considerations Organizations are dependent on the public CA migrating their service to a new certificate signing algorithm. The following are dependencies that the public CA would be expected to address as part of the migration: - If a new algorithm is required, establish or stand up a new root CA certificate with the new type of cryptography and make it publicly available - If a new algorithm is required, stand up a new intermediate CA certificate with the new cryptography; note that the intermediate CA may migrate at a different time than the root CA; - Deploy a new Certificate Policy (CP) or Certificate Practice Statement (CPS) that describes the specifics with respect to how the cryptography works (e.g., hybrid, placing it in extensions); for example, in X.509 certificates it is common practice for new data elements to go into an X.509 extension of the certificate although this is not a requirement; - Detail the extent to which the end-entity certificates are backward compatible (i.e., verifiable by entities expecting the older format); - Specify any cross-signing hierarchy (e.g., the typical cross-signed hierarchy depicted in Figure I-2 on the next page); - Update the CP/CPS to specify how the CRL or OCSP responses will be signed and provided for both root and intermediate CAs; - Be responsible for the legitimacy of the CA via audits (e.g., Web Trust audits); - Detail any specification the CA is doing from a requirement’s perspective with respect to the subscriber Registration Authorities (RA). With these items having been addressed, an organization preparing for a migration should do the following: - Verification of new CA hierarchy and guidelines: - Understand what the new guidelines mean for the organization; - Understand how the cryptography (e.g., hybrid) is implemented and how it will affect general applications and clients that use those applications; - Communicate the implications to authorized subscribers to Certificate Authorities. - Registration Authority (RA): - Ensure that what the Registration Authority (RA) is doing, is considered in making yourself compatible with the new procedure or algorithm; - The RA may need to use new asymmetric key pairs according to specifications and compatibility (e.g., TLS certificates to use new algorithms). This will apply to RAs which are used for both manual and automated renewal. ![[Pasted image 20241216154744.png]] ### Cutover Strategy Cutting over CAs to new cryptography has been done successfully in the recent past. Many CAs transitioned from 1024-bit RSA keys to 2048-bit RSA keys or to ECC, and then later signatures were transitioned from using SHA1 to SHA2. We suggest the following cutover strategy for organizations, modelled on those successful transitions. - Once the new cryptographic algorithms and/or certificate profile are known, any systems that will interact with the new certificates as signers, verifiers, or servers must be updated to handle the changes; this could potentially occur through a software update, configuration change or other method; - Once the new public CA has been stood up, a transition period and cut-off point should be established; the timelines may depend on the CA, as they may have a requirement for transitions to be completed by a certain time; these timelines may be different for the root and intermediate CAs and may be subject to CA policy or CA/B forum baseline requirements - During the transition period, any new certificates and certificate renewals should be done under the new CA, provided the relevant systems have been upgraded; - Continually monitor the progress of system upgrades, to ensure that all systems will be able to transition before the cut-off: - Develop a plan for any systems having difficulty cutting over. - As the transition cut-off approaches, any certificates still using the old cryptography should be renewed outside of the regular schedule; ensure that any valid certificates using the old cryptography are revoked. ### Governance The overall governance for the migration would incorporate existing certificate governance of renewal upon expiry as standard process. It would additionally include the following: - Monitoring of systems and their certificates to keep track of which ones have migrated and which ones have not; - Removal of old CAs from active Trust Stores when the migration has completed; - Proper audit mechanisms to ensure compliance.