4 Building Trustworthiness into PKI - concept of

4.1.1 Secure use of public key certificates is highly dependant on trust in the infrastructure used to create, manage, and process the certificates and associated public and private keys.

4.1.2 The second half of the document explores the various aspects of trust, and potential vulnerabilities, that could make or break the desired level of assurance provided by the overall system. Although, it focuses on PKIs using a Browser Trust-list model and used for Authentication purposes, many of the issues apply equally to PKIs built under the other models defined in Part A and those used for Digital Signature or Confidentiality services.

4.1.3 The first section steps through the concept of operations of a PKI and where potential vulnerabilities could appear. The second section discusses some generic attack scenarios, and responds with the various mechanisms and processes proposed for the SEE PKI to reduce or eliminate these risks.

4.2 Certification Authority Initialisation

4.2.1 The first part of the certificate lifecycle is creation of a Certification Authority (CA). The CA must create a key pair for itself. The key pair must be strong enough to make the probability of an attacker breaking it extremely unlikely within the lifetime of the certificates signed with it. This will depend on a combination of key length and the quality of the key generation algorithm.

4.2.2 Once generated, the public key must made available to all potential Relying Parties in a secure manner either by being digitally signed by a CA the users already trust or via an out-of-band channel (e.g. embedded in the software, passed by hand, or mailed on a token). The CA public key will probably be passed and stored in an X.509 certificate format.

4.2.3 The public keys of many US-based CAs are already loaded in the Trust-lists of Microsoft and Netscape software. However, these are generally not the CAs that the NZ Government would use for SENSITIVE information, so would have to be either removed or differentiated from those that are accredited for use.

4.2.4 The CA must also protect its private key from unauthorised use. This will generally be by a mixture of containing it on a hardware token, use of network security controls (i.e. firewall and operating system controls) and strict access control to the CA premises. Alternatively, the CA may rely on physical protection alone by operating the CA computer in a stand-alone mode.

4.3 Certificate Creation

4.3.1 Once the CA is up and running it can start to create certificates for users. Each certificate will need a public key and various other information specific to the Subscriber. In Authentication certificates the key pair could be generated by the Subscriber, the CA, or a third party. (With Digital Signature certificates only the Subscriber should ever have access to the private key, so they should generate them.) The key generation mechanism needs to be non-deterministic (suitably random) and capable of selecting 'good' keys (e.g. for RSA keys the factors the key pair is derived from need to be tested for 'primeness').

4.3.2 Regardless of who generates the key pair, either the public component, the private component, or both, will have to be passed between the CA and the new Subscriber. For instance, if the Subscriber generates the key pair, they will have to pass the public key to the CA; if the CA generates the key pair it will have to pass the private key to the Subscriber. If this process is done online the two parties will need to securely identify and authenticate themselves to each other. This is sometimes done by a shared secret such as a password passed by hand to the Subscriber by the Registration Agent (since at this stage the Subscriber does not yet have a public key certificate).

4.3.3 The CA will also need some Subscriber information to place in the certificate. This will probably include an e-mail address and a Distinguished Name (DN) (e.g. country=NZ, org=Govt, org unit=SSC, common name=web server). The CA might check the validity of the e-mail address by communicating to the Subscriber via it as part of the registration process. The CA will need to verify that the DN uniquely identifies the entity (e.g. the Subscriber, their organisation, or device). It will have to check that the DN does not already exist, and have the Subscriber prove it is correct.

4.3.4 For Government certificates the CA will also need to verify that the prospective Subscriber has the right to use the organisational identifier within the DN. Often these functions will be performed by the Registration Agent and then passed to the CA through a trusted channel. If either of these steps is not done properly there is a risk of legitimate certificates being created for an impostor, as happened recently when Verisign issued certificates and keys for Microsoft to someone impersonating a Microsoft employee.

4.3.5 Assuming all these details are verified as accurate and current, the CA will create the certificate by forming the information into an X.509 structure. The exact structure of the certificate and the other fields in it will have to conform to a pre-determined profile (a subset of the X.509 standard) to ensure that the certificate will be fully compatible with the software and applications used by Government. Fields missed out, added, incorrectly filled, or incorrectly marked as Mandatory or Optional could cause incompatibilities or security vulnerabililties when an application processes the certificate.

4.3.6 The CA will then sign the certificate with its private key. The two signature algorithms (hash and asymmetric) will have to be approved algorithms, of appropriate strength, and implemented correctly. If the CA's cryptographic module has been FIPS 140 evaluated then these conditions can be assumed to be satisfied.

4.3.7 The CA will then pass the new certificate to the user and/or post it onto a common area such as an electronic directory for all potential Relying Parties to access. The directory may need protection from vandalism and denial of service attacks, but the threat of modification should not be an issue because Relying Parties will detect any tampering of a certificate when they verify its signature. The directory may also have access controls to protect the privacy of the content or existence of some certificates.

4.4 Certificate Usage

4.4.1 Subscribers and Relying Parties do not generally require any direct communication with the CA when they use certificates. For instance, if a Subscriber wishes to access an online service or sign e-mail they will generally pass their certificate to the other party as part of the communication. Alternatively, the Relying Party could query the directory for it. Either way, the Relying Party will need to check the authenticity and integrity of the certificate by verifying its signature using their trusted copy of the CA's public key.

4.4.2 The Relying Party will also need to check the validity of the certificate either by checking an online status checking service or by downloading the applicable CRL. In either case they will need to verify the authenticity of the status information by checking the CA's signature on the CRL or status response. The expiry date and time of the status should also be checked to prevent expired status information from being used or stale status information from being replayed by an impostor.

4.4.3 If the public key for the CA that issued the Subscriber certificate is not contained in the Relying Parties Browser Trust-list public key store, their PKI software will also need to perform similar verification (digital signature) and validity (not expired or revoked) checks on the CA certificate. This will need to continue until it has discovered a 'chain of trust' that ends with a key in the Trust-list.

4.4.4 The cryptographic software of both the sender and receiver must be capable of performing all these actions correctly and securely, and informing the user on errors detected in the processes above. Where errors are encountered, the default behaviour of the software should be to fail on the side of safety (e.g. not accepting a communication if the applicable CRL cannot be obtained), although, preferably, the user should be given the option to proceed once they have been warned of the discrepancy.

4.5 Certificate Expiry, Revocation and Rekey

4.5.1 Two of the fields in X.509 certificates are the notBefore and notAfter fields that define the validity period for the certificate. The duration of the validity period is generally derived from the most restrictive of the following factors: the public key algorithm and key length; the certificate usage ; financial and maintenance agreements with the CA; and the life cycle requirements of the services and software the certificate will be used for. For 1024-bit RSA keys used for Authentication, a certificate lifetime period of up to three years is appropriate from a security perspective. Although, for the second two reasons one to two years may be more appropriate. Where CRLs are used to promulgate certificate status the shorter certificate lifetimes are also advantageous to keep the lists shorter and consequently reduce the communications and processing overhead.

4.5.2 There are several reasons why certificates may need to be revoked before their expiry date. For instance: if the private key is lost or compromised; the details in the certificate are no longer correct; the relationship with the Sponsor has changed (e.g. the employee has left the department); the approved standard profile has been updated; or the CA key pair has been prematurely superseded. In any such situations where the certificate should no longer be used, the notification from the Subscriber or Sponsor to the CA needs to be timely and authenticated. This could be in person to the CA or RA, via a signed message, or via another authenticated channel. While the private key corresponding to the certificate being revoked can be used to authenticate a revocation request, for obvious reasons, if the request is because of compromise or suspected compromise of the private key, it cannot be used to support authentication for generation of the new certificate.

4.5.3 In other revocation situations, or for routine Subscriber re-key, either the Subscriber or the CA may need to pass the other the relevant component of the key pair before the new certificate can be generated and/or activated. As with the initial certificate generation, these communications will have to be protected for privacy, integrity and authenticity.

4.6 Certification Authority Termination

4.6.1 If for any reason a CA ceases operations or is no longer suitable for use it is important that the certificates the CA has created are supported either until they expire or can be replaced. This may involve passing control of the CA private key functions to another CA or getting another CA to generate completely new certificates. Regardless, it is critical that all the security requirements and processes on the CA are carried over during and after the transition. The CA should inform all stakeholders of such an occurrence well before the event in case applications and Subscriber/Relying Party crypto-modules need to be provided with the new CA public key.