6 Digital Certificates

1 General digital certificate requirements

1. An acceptable CA must issue the certificate (refer page *).

2. Digital certificates must be X.509 V3 compliant.

3. The certificate must use RSA 1024 bit or longer keys.

2 Distinguished name (DN) recommendations

1. Certificates may be issued to individuals, servers or other devices.

2. The recommended distinguished name structure is

3. O=organisation, CN=common name, E=e-mail address, L=location, S=state, C=country

4. The recommended distinguished name for a fictitious person Andy Bucket in a fictitious Ministry of Water is

5. O=Ministry of Water, CN=Andy Bucket, E=andy.bucket@minwater.govt.nz, L=-, S=-, C=NZ

6. The recommended distinguished name for the Ministry of Water's web site is

7. O=Ministry of Water, CN=www.minwater.govt.nz, E=itsupport@minwater.govt.nz, L=-, S=-, C=NZ

8. The certificate should include the email address of the user in the distinguished name. This can assist application development and simplifies distinguished name collisions.

9. If email addresses are used, the CA must guarantee that they will not issue digital certificates to more than one individual using the same email address, i.e. an individual may have more than one certificate and the same email address may be in each certificate, but two individuals must not be permitted to share an email address.

10. A single email address may be used for multiple digital certificates for more than one server or device. In this case the email address should be generic, e.g. itsupport@minwater.govt.nz rather than for an individual.

11. The common name (CN) field should reflect the individual's preferred name, e.g. Les Battersby rather than Lesley Battersby; or in the case of server certificates, the DNS address of the server, e.g. www.minwater.govt.nz.

12. The Organisation (O) field must be the agency's legal name.

13. Large organisations may wish to use an Organisation Unit (OU) field, however in general this should be avoided if staff movement among OUs is common.

14. The Location (L) field is optional and may be used for the region or city of the individual if relevant and useful. This field should be set to a hyphen if unused.

15. The State (S) field should always be set to a hyphen for New Zealand agencies.

16. C=NZ should be used for all New Zealand agencies. Foreign offices of New Zealand agencies may wish to use the Location field to identify the city and country of the individual.

3 Key sharing and certificate implications

1. 1024 bit key pairs should be used for no longer than three years before being replaced. This includes CA keys. 2048 bit key pairs may be used for longer periods.

2. Key sharing should generally be avoided to aid accountability, but there are situations where key sharing is a business requirement.

3. Encryption certificates may be shared, for example to allow a PA to read their manager's email.

4. Digital signature certificates should only be issued to individuals. These should be clearly distinguishable from "authentication" certificates issued to devices.

5. The distinguished name (DN) in certificates should specify the individual rather than organisation positions, so as to aid accountability. If certificates are issued to positions, when an individual is replaced in a position, the certificate should be replaced using new keys to protect both individuals.

6. Authentication (but not Digital Signature) certificates may be issued to functional groups if this is appropriate for the application. For example for agency access to CFISnet, one certificate could have been issued to each agency to be shared among the finance staff at that site. The security of the token coupled with regular PIN changes could obviate the need for certificate replacement with staff turnover. However CFISnet still uses certificates for each individual so that data changes can be attributed to individuals.

4 Separate signing / encryption certificates, and key recovery

1. All encryption keys issued to employees or contractors should be escrowed and be accessible to the organisation to prevent the organisation from being denied access to its information. Individuals should be notified when an organisation accesses the individual's encryption keys unless the individual is no longer in the service of the organisation.

2. Individual's keys for digital signing should not be escrowed.

3. Keys for authentication could be escrowed, however it is unlikely that there would be any benefit to anyone in doing so.

4. To meet the above objectives, users should be issued with a signing/authentication certificate, and if required, a separate encryption certificate with a different key pair.

5. Given the current state of PKT, there are still likely to be good business or usability reasons why a single certificate for both encryption and signing/authentication is preferred in some situations.

5 Tokens / private key protection

1. If the private key is backed up or escrowed, it must be stored in an encrypted form and physically secured.

2. All private key handling including key generation, escrow, retrieval from escrow and token loading must be handled in a highly secure manner designed to avoid any potential for private key compromise.

3. The department should also verify that the end-user cryptographic software performs correctly and in a secure fashion. For instance, they should be confident that any key generation and handling processes are secure, that certificates are appropriately validated and verified, and that the user is informed if an event or state occurs that could weaken or negate the security (e.g. a message that could not be encrypted is going to be sent in plaintext). Formal evaluation schemes such as the AISEP programme provide lists of products that have been thoroughly tested for such design or implementation flaws.

4. To avoid theft of the private key and social engineering attacks, the private key must be stored on a token, for example a smart card, that the user carries with them or stores securely. The same approach should be taken for server-based keys where feasible.

5. To reduce risk through loss of the token, the token must require a password or biometrics to activate the private key. If you are investigating biometrics for activation of private keys on tokens, please work closely with the S.E.E. Team.

6. To avoid social engineering attacks and to encourage good key management, the private key must not be exportable from the token.

7. The private key must never leave the token. For example during a signing process when a user signs / authenticates themselves, the process typically generates a small hash of the message and this must be passed to the token for signing by the token's processor.

8. Tokens and associated software should be FIPS 140-1 evaluated or similar, or be undergoing evaluation.

9. The token drivers must be compatible with the choice of client application software. To ease compatibility with other applications, tokens should have PKCS#11, PC/SC, and MS CAPI drivers.

10. Note that some application software may be PKT-enabled to a certain degree but not support tokens, e.g. Opera 4 at time of writing.

11. Where token support is not available or where tokens are S.E.E.n as unnecessarily expensive, please discuss this with the S.E.E. Project Team.

12. Escrowed or backups of private keys of subscribers must not be stored outside New Zealand.

6 CRLs, CDPs and OCSP

1. The CA must publish X.509 V2 certificate revocation lists (CRLs) at least daily.

2. Note that version 2 CRLs are not used by some software products, in particular the Netscape range, however this is mitigated by the fact that these products are moving to the use of an Online Certificate Status Protocol (OCSP) service, which complements the use of CRLs. Version 2 CRLs (as opposed to version 1 CRLs and OCSP) record not only which certificates have been revoked but also when the certificate was revoked - this is important for verification of stored signed data, e.g. signed documents.

3. The certificate must specify a CRL Distribution Point (CDP).

4. The CDP should use HTTP, HTTPS or Lightweight Directory Access Protocol (LDAP) for access to the CRL. The use of secure HTTP (HTTPS) is an unnecessary overhead, as the CA digitally signs the CRL. HTTP is preferred over LDAP because the software retrieving the CRLs will more than likely better support HTTP. The CDP may specify multiple uniform resource identifiers (URIs).

5. The CA should also provide an OCSP service. Note that OCSP is relatively new and that the S.E.E. Project has not piloted it. Therefore, the following recommendations are tentative.

6. The validity period for OCSP responses must not exceed one day.

7. The certificate should specify an AuthorityInfoAccess field to specify an OCSP service and this service should be accessible using HTTP or HTTPS. The use of HTTPS is an unnecessary overhead, as the CA digitally signs the CRL. More than one URI may be specified.

7 Attribute certificates

1. The S.E.E. Project Team has not had any experience with attribute certificates. However, from discussions with overseas counterparts, it appears there is currently very little product support. If you are experimenting with attribute certificates, please tell the S.E.E. Project Team so we can track your progress for the benefit of other departments.

8 Root CAs, Bridge CAs, other

1. The S.E.E. Project Team does not consider that a Root CA for government is required. Instead, it is considering Bridge CA models and Audit based trust models.

2. In the interim, applications must be manually configured as to which CAs to trust.