Design and build a privately hosted Public Key Infrastructure

The registration procedure validates the identity of the end entity before requesting their certificate to be issued.

A failure of the registration system could lead to fraudulently issued (or 'mis-issued') certificates, allowing the attacker to impersonate genuine identities. In other words, failure of the registration process will lead to the PKI system being broken.

When a certificate is first requested by an end entity, a thorough identity validation (See Validation requirements should be carried out by the registration authority. This should be followed by an authorisation process, which determines whether the entity is allowed the type of certificate being requested and the proposed fields in the certificate.

An end entity will send a certificate signing request (CSR) to a registration authority. The CSR should not be trusted when it is first received, it should be verified and then forwarded to the CA to issue the certificate.

The CA should determine a number of the fields in the certificate from a 'certificate profile.' This takes the form of several pre-configured certificate fields, such as key usage or certificate lifetime.

Normally, the particular fields are chosen to enable a specific use case only, such as TLS on a web server or a VPN. This helps to mitigate the risk of an end entity being allowed a certificate with unauthorised characteristics. For example, a key usage that's not required, or a very long expiry date.

Validation and authorisation processes

Identity validation and authorisation may be automated. Some examples include proving identity of an end entity by checking a central identity provider. Alternatively, an end entity could prove ownership of a resource, such as a domain name, which requires the identity to have been previously established to an acceptable level of certainty.

In certain high impact situations, such as issuing an intermediate CA or end-entity certificate for a high value service, some level of human intervention may be required. This could mean the authorisation is provided by human interaction or an out of band process employed to prove identity.

An out of band process could be a physical check of identification (passport or driving licence), or for a human checking the validly of the request before approving. For device certificates, this process could be a manual step carried out as part of the device provisioning process.

Validation requirements

The amount of access that a certificate will give, should dictate the level of validation required on the identity of a new participant. The method used to validate a new end entity and the level of stringency will depend on the use case.

An example validation could check that a person is actually an employee of the organisation. This check should be performed against a definitive source, such as the HR database. Alternatively, you could check that a particular end user device is an asset owned by the organisation. Again, this should involve a sufficiently definitive source, such as an asset database.

The initial validation is normally carried out by the registration authority function of the PKI. If the registration is for a high value key, such as registering a new CA, then a second person or factor should be implemented to ensure the new participant is valid.

Non-technological components

The registration process is not just a technology problem. It requires governance, process and auditing.