5 Certification Authorities (CAs)

1 Sovereignty and CA location

1. While the CA needn't have access to the private keys used to protect the confidentiality of information, a CA still has the potential for denial of service, e.g. by not producing CRLs, or revoking certificates, and has the potential to masquerade as a subscriber by creating additional certificates, potentially gaining access to privileged information.

2. By requiring a CA to be a New Zealand registered company, and by having their staff and systems vetted by New Zealand security agencies, we can have greater confidence in their operations and have recourse to New Zealand law.

3. For performance and reliability it is advantageous to have a CA's directory, CRLs and OCSP situated locally.

4. It has been proposed that we have a role in developing and maintaining local knowledge and skill in PKT. By requiring that CA root keys be held in New Zealand we would encourage local investment in PKT, which may have gains for New Zealand companies through export of product or skills.

5. Due to Australia's proximity, the Australia New Zealand Closer Economic Relations Trade Agreement (CER), and Australia's existing investment in PKT, it seems appropriate to permit the use of Australian CAs. However, NZ CAs cannot sell certificates to the Australian government without setting up shop both physically and legally in Australia, and so they might as well move their operations to Australia and just leave a marketing division in NZ.

6. The private sector will have an interest in being able to conduct electronic business with Australian firms and there is a concern that New Zealand businesses may need Australian Gatekeeper certificates to do business with Australian businesses and the Australian government; but this is outside the scope of this document.

7. These issues of interoperability and sovereignty need further consideration.

2 General

1. The CA must have a published Certification Practice Statement and should comply with IETF RFC Guideline 2527.

2. The CA should give good indications of its trustworthiness, for example by accepting financial liability for problems due to mistakes or errors on their part.

3 Environment security

1. The CA should be in a Grade II or better site and the CA functions should be separated from all other functions so that only authorised CA personnel have physical access to CA equipment and media.

2. The CA must have good security management along the lines of NZS4444. This should be audited regularly.

3. The CA's private keys should be kept in hardware security modules, and when offline must be stored in such a way as to require multiple operators for reactivation.

4. The CA must be willing to be visited by the GCSB - or similar Government or third party auditor - to look at the appropriateness of the authority's processes and security management with respect to the intended application.

5. Critical CA personnel must be SIS vetted to at least SECRET; this should include personnel who are able to utilise the CA's private keys directly or indirectly, e.g. those who are able to issue and revoke certificates. Note that a government department must sponsor this vetting.

6. The CA should also have appropriate measures in place to prevent unauthorised access to the CA system and private keys via the network. This should include a firewall and virus and intrusion detection mechanisms, which should be configured in compliance with documented policies, and be monitored and managed in accordance with Internet best-practices.

4 Processes

1. The CA must have good process management (e.g. ISO9001 certification).

2. The CA should use formally evaluated operating systems and CA software where available to ensure that the security and CA mechanisms operate consistently and in a secure fashion. The AISEP programme (www.dsd.gov.au/infosec) provides a list of some of these products.

3. The CA must archive all transactions related to certificate requests, renewal, replacement, suspension and revocation. Archived transactions must be maintained for a period not less than the period over which electronic transactions undertaken with the CA's certificates need to be non-repudiable, and this period must be explicit in the CA's CPS. This period should be no less than 7 years.

4. Where a new certificate request enters a system (RA or CA), the transaction must be validated against the identity documentation provided.

5 Identification

1. Certificate holders must have their identity confirmed.

2. The level of identification required for an individual to be issued with a digital certificate is very much dependent on the intended usage, other processes around granting access to a system and other uses to which the certificate could be put.

3. There are clear arguments for making identification harder, e.g. similar to the requirements for obtaining a NZ passport, and for making it easier, e.g. similar to that required to obtain a library card, or even to trust that an agency has already performed sufficient identification of its employees and so let the agency vouch for that employee.

4. This document targets the exchange of SENSITIVE information among government agencies and we consider that a system similar to that used in the commercial world, e.g. when opening a cheque account, is likely to be appropriate. Providing at least two forms of Government-issued identification should be considered a minimum.

5. Each request for a digital certificate issued with O=agency in the DN of the certificate (refer page *) must be authorised by the relevant agency.

6 Quality of service

1. The CA's CRLs and OCSP services must be highly available so that applications can check whether a certificate has been revoked.

2. Service levels will depend on the system availability requirements of the users or owners of the system.

3. Note that as applications are developed which make use of certificates that were originally issued for use with another application, user expectations on the service levels may change.

4. Agencies and CAs should agree on service levels for revocation of certificates and for issuing new certificates and tokens.

5. CAs must have a business continuity plan and should have standby facilities in another city.