### Description This use case will cover crypto-agility aspects related to the setup and use of a private CA managed internally by an organization. A private CA is the authority for a public key infrastructure (PKI) for a specific organization or a closed network of peers, and typically issues certificates that are intended for use only by the organization or its peers to which it is assigned. The actions of an individual entity during the certificate lifecycle are described in [[End-Entity Certificate Requirements]] For simplicity, we will assume that there will be a simple three-level hierarchy: - root -> intermediate -> end-entity In many ways, the crypto agility of the signing algorithm used by a private CA is similar to that of the public type. The main difference is that the organization now controls much, if not all, of the considerations involved. This is reflected in the considerations below. There are various types of CAs which fall into the category of private, including: - **Inspection CAs:** These are CAs which are specifically in place to intercept incoming and outgoing content for the purpose of inspection of traffic. This would include performing content filtering and malware detection. This CA is typically an intermediate CA off of an enterprise-accepted CA. - **Special Use CAs:** Some applications require their own CA in order to function. These are often limited in scope to the devices involved with the application. Examples include special purpose hardware such as Encryption PIN Pads (EPPs) on an ATM or POS device, routers from a specific vendor, or IoT implementations such as cameras or display monitors. ### Discovery / Inventory It is important to have an inventory of the different private CAs that exist within an organization. Enterprise-wide CAs are generally well-known, but special-use CAs can sometimes be embedded and hidden from normal business operations. Discovering special use CAs may require either consulting application vendors or performing a network scan for certificates (e.g., scan ports 443, 1443, 8443 for HTTPS, other ports for TLS). For each private CA, the inventory outlined in [[Public Certificate Authority CA - Public Key Infrastructure PKI]] for public CAs should be followed. If the CA is internally hosted, then it would be important to also have information on the CA’s operating infrastructure such as: - Servers; - Hardware Security Modules (HSMs); - Network location; - Location of CA private key including online or offline backups; - CRL location. For a special-use CA, it would also be important to have an inventory of devices that leverage the special-use CA. ### Migration Considerations Since this is an internal CA, it is assumed that the organization controls all aspects of its setup for crypto agility, including the following: - Decide on the new type of cryptographic algorithms that will be used by the CA for signing certificates and can support the organization’s needs with respect to designated factors (e.g., latency, throughput, storage space, etc.); - Decide how the new cryptographic algorithms will be realized within the CA and its certificates (e.g., certificate extension fields); - Decide on the cryptographic algorithms to be used for the CRL signing; - Decide on how the CA is structured (e.g., cross-signed with old root); - Establish the infrastructure for a Root CA (e.g., HSM, offline device, cryptography card) which is compatible with the new crypto; - Create the new root CA certificate and export for backup purposes as appropriate; - Establish the infrastructure for an online issuing intermediate CA (e.g., server, VM, HSM, networking capabilities, etc.) which are compatible with the new cryptographic algorithms; - Create the new intermediate CA certificate and perform any additional operations such as cross-signing; - Make the CA certificates available to the organization and/or push them out to the requisite systems; - Establish or modify the Registration Authority (RA) setup to leverage the new cryptographic algorithms; - Ensure provisioning protocols such as SCEP or PKCS #10 are able to leverage the new certificates; - For a special-use CA that may be specific to a particular service or hardware, ensure that the devices leveraging this CA are compatible with the new hierarchy; this may require an upgrade to a different generation of device. ### Cutover Strategy Once established, the new CA would need a cutover strategy similar to that of the Public CA. - Develop and manage a cutover strategy for moving from the old CA to the new CA: - Establish a cut-off point for a defined transition period; - Establish and communicate organizational guidelines for cutover; - Establish oversight for removal of old CAs. An inspection CA would be similar to that of a standard private CA, with the exception that it is likely dependent upon the private CA from which it was signed. It can be treated as another intermediate issuing CA of the private CA. Special-use CAs are vendor dependent. It would be up to the vendor to determine or recommend a cutover strategy. It could either be gradual or all at once, depending on the options provided by the vendor and the characteristics of the business use case. ### Governance Governance for this use case would be similar to that of the public CA/PKI. For special-use CAs, there would need to be an additional level of governance to track the different implementations and assessing each one’s ability to migrate. Note that audit requirements here would be internal unless a specific use requires external oversight.