Skip to content.
|Networking government in New Zealand.
 
You are here: Home » Services » SEEMail » SEE PKI » S.E.E. PKI - Certificate policy

S.E.E. PKI - Certificate policy

S.E.E. PKI: Key Certificate Policy v1.91

Note: this version of the certificate policy has been superseded. The current Certificate Policy is version 2.

Written to comply with Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework (RFC 2527), http://www.ietf.org/rfc/rfc2527.txt

Contents

    For example, the OID for a Business Card style certificate is BusinessCard, and the full numeric OID is 2.16.554.101.2.1.1.2 = JointISO(2).Country(16).NZ(554).Govt(101).SSC(2).CertificatePolicy(1).SEEKey_1_0(1).BusinessCard(2)

    alphanumeric OID

    numeric OID

    Passport

    Passport

    2.16.554.101.2.1.1.1

    Business Card

    BusinessCard

    2.16.554.101.2.1.1.2

    Associate Card

    AssociateCard

    2.16.554.101.2.1.1.3

These OIDs are not formally registered.

1.3 Community and Applicability

5. The definition of a Certification Authority (CA) under this Policy is a party that will:

  1. create and sign digital certificates binding Subscribers with the public component of their asymmetric cryptographic key pairs;
  2. promulgate certificate status through Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP); and
  3. enforce the requirements of the Certificate Policy within the entities it has issued certificates for (i.e., CA staff, Registration Authorities, and Subscribers).

6. This Policy covers three variations of authentication certificates, Business Card, Passport, and Associate Card:

  • Business Card certificates are tied to a specific sponsoring agency and/or role and include those details in the DN. The certificate implies that the individual represents the named organisation.
  • Passport certificates are based on the individual's identity and do not include organisational descriptors.
  • Associate Card certificates reflect an external individual's relationship with a S.E.E Agency without implying they represent the agency in any way.

The three variations are differentiated by the certificate subjectName Distinguished Name (DN) conventions defined in Section 3.1 as well as by Policy OID as defined in Section 1.2.

The S.E.E. Steering Group may accredit a CA for one or more of these certificate variations.

7. The Certification Authority must:

  • ensure any CA public key approved for S.E.E. PKI use is only used to issue certificates under the certificate policies approved for S.E.E. PKI (i.e. the CA must not issue lower assurance certificates with that particular CA key). The exception to this rule is if the organisation name in the O field of the DN is prefixed with a mutually agreed string, e.g. "Associate registered by " to support Associate Card style certificates (see section 3 below).
  • have at least one CRL repository associated with them;
  • provide a web site for Subscriber and Relying Party access to the documents that define their rights and responsibilities.

8. The CA should provide an OCSP service.

9. The Certification Authority may

  • create Subscriber key pairs.
  • issue, recognise or support any number of certificate policies as long as the requirements of one do not affect compliance to the requirements of another, i.e. a CA issuing certificates under this Policy is not limited to only this Policy.

10. Registration Agents (RAs) - also called a Local Registration Authorities (LRAs) or Organisation RAs (ORAs) - are responsible for administration of Subscribers on behalf of a CA. The RA is an agent of the CA. An RA may act as an agent for more than one CA or public key infrastructure.

11. Certificates must only be issued after authorisation from an authorised Sponsor.

12. The Sponsor must have the right to authorise certificates under that domain and organisation name (e.g @ssc.govt.nz and O=State Service Commission), as an agent of the department or agency.

13. The Sponsor role may be performed by the same person or group as the RA role.

1.4 Contact Details

The S.E.E. PKI Project Team developed this document as part of the State Services Commission's E-government initiative. The policy management authority is the S.E.E. Steering Group. The contact person is the S.E.E. Project Manager, who can be contacted at pki@security.govt.nz.

2 General Provisions

2.1 Obligations

CA and RA Obligations

14. CAs and RAs must operate in accordance with their Certification Practice Statement (CPS), the current version of this Policy, and the laws of New Zealand when issuing and managing the certificates and keys provided to S.E.E Key RAs and Subscribers.

CA Obligations

15. The Certification Authority must:

  • ensure that Subscribers are aware of their rights and obligations with respect to the operation and management of keys, certificates and cryptographic modules.
  • verify in writing that they comply with this Policy and from time to time conduct compliance audits if requested to do so by the SEE PKI Project Team. Such compliance audits will be conducted at the CA's cost;
  • have mechanisms and procedures to ensure that their RAs, Subscribers, and any CAs they certify, also agree to abide with this Policy; and
  • make the CRLs and OCSP services they manage available to Subscribers and Relying Parties in accordance with Section 4.
  • in the case of a Passport style certificate, ensure that it, or one of its RAs has verified the identity and authorisation of the Subscriber in accordance with Section 3 and that the details in the certificate match the Subscriber's details, and that the email address is reliable.
  • in the case of a Business Card style certificate, ensure that it has appropriately verified the identity and authorisation of the Sponsor in accordance with Section 3 and that the organisation name and email address / internet domain details in the certificate match the Sponsor's organisation details.
  • in the case of an Associate Card style certificate, ensure that it has appropriately verified the identity and authorisation of the Sponsor in accordance with Section 3, that the organisation name details in the certificate match the Sponsor's organisation details, and that the email address is reliable.
  • provide any S.E.E. Agency with a list of all certificates issued using its name within one working day of request, including the status of each certificate, the certificate's subjectName, and its expiry date.
  • ensure that the procedures for the expiration, revocation and re-issuance of their certificates conform to this Policy and are expressly stated in their CPSs and any Subscriber agreements or policies.
  • ensure that when they revoke a certificate all relevant CRL and OCSP servers are updated and published within one working day of notification.

Sponsor Obligations

16. The Sponsor must

  • ensure that any information submitted to a CA/RA when applying, updating or requesting revocation of a certificate is complete and accurate.
  • notify the CA/RA when an End-entity certificate is no longer required.
  • only request Business Card and Associate Card style certificates with organisation names for which they are authorised to act.
  • only request Business Card style certificate with internet domain names (e.g. in email addresses and urls) that are in the control of the organisation name requested.

Subscriber Obligations

17. The Subscriber must

  • ensure that any information submitted to a CA/RA when applying, updating or requesting revocation of a certificate is complete and accurate.
  • protect their private keys and key tokens (if applicable) in accordance with Section 6, and to take all reasonable measures to prevent their loss, disclosure, modification, or unauthorised use.
  • notify their CA or RA as soon as possible, if they suspect private key compromise.

Relying Party Obligations

18. A Relying Party should consider the differences among Passport, Associate Card and Business Card style certificates, and if necessary, place different levels of trust in certificates based on the contents of the Organisation field of certificates as specified in section 3, and/or the policy OIDs as specified in section 1.

19. A relying party must not assume that a subscriber has any authority to conduct business transactions or otherwise act on behalf of the subscriber's organisation based solely on the fact that the subscriber has a certificate.

20. Relying parties should note the intended purpose of certificates issued under this certificate policy as discussed in the Introduction.

2.2 Liability

21. Accreditation of or the issue of certificates by a CA in relation to S.E.E. Key does not permit or authorise under any circumstances the CA to conduct business transactions or otherwise act on behalf of the organisation using the certificates or the New Zealand government.

2.3 Financial Responsibility

22. No stipulation.

2.4 Interpretation and Enforcement

23. Certificates issued under this policy must be governed by New Zealand law.

Dispute Resolution - Escalation, Arbitration - Principles

24. The parties agree to use their best efforts to resolve any dispute that may arise under the Accreditation Process through good faith negotiations.

25. The parties acknowledge their desire that any irreconcilable dispute or difference shall be resolved by mediation. This is without prejudice to any other right or entitlement that they may have. The rules governing any mediation shall be agreed between the Parties. The Parties agree to the assistance of LEADR (Lawyers involved in Alternative Dispute Resolution) to set the terms of reference for any such mediation and/or to procure mediation at equal cost to the parties or on such other terms as the Parties agree.

Process

26. If an irreconcilable dispute or difference arises between any two parties, either party may seek request that the dispute be submitted for mediation within 14 days by way of written notice by one party to the other.

27. However where an irreconcilable dispute or difference arises between the Applicant and the S.E.E. Manager as a result of an application for Accreditation by a supplier, or from the Accreditation Process, the dispute shall first be referred to the S.E.E. Steering Group for discussion and resolution.

28. If an irreconcilable dispute or difference is not submitted for mediation within 14 days of written notice by one party to the other, or resolved by mediation, either party may by way of 14 days written notice to the other require the matter to be determined by the arbitration of a single arbitrator in accordance with the provisions of the Arbitration Act 1996 (as amended by this Agreement).

The arbitrator shall be appointed by the parties or, failing agreement within five Working Days of such notice, appointed as soon as possible by the President of the New Zealand Law Society at the request of either party. The arbitration shall be conducted as soon as possible at Wellington.

The parties shall continue to perform their obligations as far as possible as if no dispute had arisen pending the final settlement of any matter referred to mediation or arbitration.

Nothing in this section shall preclude either party from taking immediate steps to seek urgent interlocutory relief before a New Zealand Court.

2.5 Fees

29. No stipulation.

2.6 Publication & Repository

30. The Certification Authority must

  • ensure that all NZ Government Relying Parties have access to current CRLs and OCSP services from the locations and via the protocols specified in its certificates' CRLDISTRIBUTIONPOINT and AUTHORITYINFOACCESs fields
  • ensure that the CRLs and OCSP services specified in the CRLDISTRIBUTIONPOINT and AUTHORITYINFOACCESS fields in the certificates must specify locations accessible via the Internet over LDAP and/or HTTP.
  • publish a copy of this Policy and a public version of its CPS on its web site

2.7 Compliance Audit

31. The CA will be required to

  • provide resource to the accreditation/audit process
  • pay for all costs incurred in their accreditation/audit

32. The Certification Authority must

  • notify the S.E.E. Steering Group prior to making any substantive change to their operations that could affect the likelihood of being successfully re-accredited;
  • provide a full CPS when necessary for the purposes of any audit or accreditation;

Periods of Notice

33. The following periods of notice will apply to the Accreditation/Audit Process.

(a) The S.E.E. Steering Group will give Applicants five (5) working days notice of termination of the Accreditation/Audit Process.

(b) Applicants will give the S.E.E. Steering Group five (5) working days notice of their intention to withdraw from the Accreditation/Audit Process.

(c) The S.E.E. Steering Group will give Applicants and Accredited Suppliers: - fourteen (14) days notice of changes or variations to the Accreditation/Audit process - fourteen (14) days notice of changes or variations to its requirements.

(d) Applicants or Accredited Suppliers will give notice by e-mail, to the S.E.E. Steering Group. The period of notice will commence from the time of acceptance of that notice by the S.E.E. Steering Group. Acceptance will be notified by return e-mail to the person(s) who is authorised by the Applicant or Accredited Supplier to act on behalf of their organisation for the purposes of the Accreditation Process.

(e) The S.E.E. Steering Group will give notice by e-mail to the person(s) who is authorised by the Applicant or Accredited Supplier to act on behalf of their organisation for the purposes of the Accreditation Process. The period of notice will commence at the time of dispatch of the e-mail.

The S.E.E. Steering Group reserves the right to amend the Accreditation or Audit Process, its requirements and/or this Document and to make any changes whatsoever, including cancelling the Accreditation Process and the S.E.E project itself. Applicants and Accredited Suppliers will be notified of any changes to the requirements in accordance with the notice provisions detailed in this document.

Accreditation

34. The Certification Authority must have been accredited by the S.E.E. Steering Group, BEFORE they can issue any S.E.E. PKI certificate.

35. The Certification Authority is eligible for accreditation if they provide a statement of compliance with this Certificate Policy and has either

(a) undergone an independent audit (evidence of audit) deemed acceptable by the S.E.E. Steering Group; or (b) been accredited to another scheme approved by the S.E.E. Steering Group (third party accreditation); or (c) been accredited to another scheme approved by the S.E.E. Steering Group, and the differences between that scheme's CP and the S.E.E. CP has undergone an independent audit (audit to S.E.E. PKI CP)

36. At the time of application for accreditation, the Certificate Authority must provide the S.E.E. Steering group:

  • a copy of the CA's most recent audited annual report
  • the CA's proposed Certificate Practice Statement (CPS)
  • a formal comparison of the CPS with the S.E.E. Key CP (this document)
  • a letter indicating whether the proposed CA matches the requirements of the S.E.E. Key CP, indicating any potentially controversial areas of compliance
  • any certificate of accreditation from another body
  • access to relevant audit reports of CA operations
  • access to CA operations centres where requested

37. The S.E.E. Steering Group reserves the right to accept or decline any application for accreditation received.

38. The formal comparison of the CPS with the S.E.E. Key CP must:

  • Compare the documents on a paragraph-by-paragraph basis
  • Mark each paragraph with either "Pass" or "Fail" in each case.
  • For each paragraph where your proposal satisfies S.E.E. Key needs but there is not an accurate match of policies between the CP and CPS, complete the sentence "Meets because..."
  • Mark each paragraph as to whether compliance has been audited by an independent auditor.

39. During the accreditation process the Certificate Authority must make available on request CRL, OCSP services and FOUR (4) digital certificates, to each of up to FIVE (5) S.E.E. application owners selected by the S.E.E. Steering Group to test the proposed certificates with their applications.

40. The S.E.E. Steering Group may accredit the CA, on completion of the accreditation process, and verification that the CA satisfies other local conditions. Accreditation will be at the discretion of the S.E.E. Steering Group and may be withdrawn at any time.

Withdrawal of accreditation

41. In the event that the S.E.E. Manager is considering withdrawal of S.E.E. Key accreditation, the following process will be used.

42. The S.E.E. Manager will send the CA an email notice that they intend to recommend withdrawal of S.E.E. Key accreditation.

43. The e-mail will include:

  • The reason for the withdrawal of accreditation;
  • The withdrawal of accreditation process;
  • The contact details of the S.E.E. Steering Group chair;
  • The contact details of the S.E.E. Manager.

44. The CA will have 14 days to resolve the matter to the satisfaction of the S.E.E. Manager.

45. If after 14 days, the S.E.E. Manager still considers withdrawal of S.E.E. Key accreditation necessary, the S.E.E. Manager will recommend to the S.E.E. Steering Group that accreditation should be withdrawn.

46. The S.E.E. Manager will invite the CA to present any counter argument to the S.E.E. Steering Group. The CA will be required to present its case in writing within 7 days of the invitation. The CA may also request to be heard orally by the S.E.E. Steering Group.

47. The S.E.E. Steering Group's decision will be final.

48. In the event that accreditation is withdrawn

  • the CA must offer Sponsors, or in the case of Passport style certificates, the Individual, the choice of either the destruction or the return of all backed up or escrowed private keys managed by the CA. All costs associated with return or destruction of private keys will be met by the CA;
  •  the CA must continue to provide certificate status checking, and certificate revocation services as per this document, for a period of one year unless agreed otherwise between the S.E.E. Manager and the CA;
  • the CA must not continue to sell or issue S.E.E. branded certificates.

Audit

49. CAs must demonstrate a commitment to ongoing audit of CA operations.

50. The results of the audit must be provided to the S.E.E. Steering Group as soon as practicable and at no cost.

51. The S.E.E. Steering Group may require that CAs be audited:

  • prior to initial approval by the S.E.E. Steering Group;
  • upon breach of any part of the S.E.E. Certificate Policy

2.8 Confidentiality of Information

52. Private keys must be protected in accordance with Section 6.

53. The Subscriber must protect his or her private key from disclosure to any other party, unless required by law..

54. No party shall make backups of a Subscriber or Sponsor's private keys without the prior consent of the Subscriber or Sponsor. Backups of private keys shall not be made available to any party other than the Subscriber or Sponsor without the prior consent of the Subscriber or Sponsor, unless required by law.

55. The CA must ensure

  • information collected is only be used for digital certificate management purposes;
  • it complies with the Privacy Act of New Zealand 1993.

2.9 Intellectual Property Rights

56. No stipulation.

3 Identification and Authentication

3.1 Initial Registration

57. Business Card and Associate Card certificates must include an Organisation name in the Distinguished Name

58. The CA must get authorisation from the organisation to produce each certificate it produces with that organisation's name in the Distinguished Name. Authorisation shall be from the chief executive or a company director, or a Sponsor explicitly delegated by them for the management of digital certificates issued under the organisation's name.

59. The CA's registration process must be sufficiently rigorous that:

for Business Card style certificates,

  • an individual can be issued with a S.E.E. Key only in the name by which they are usually called within the Sponsor's organisation. For devices, the certificate must include the name of the device administrator, the business unit, or the primary business function the device is used for;
  • the S.E.E. Key may only be stamped with the name of the organisation which employs or manages the End-entity identified in the certificate; and
  • the email address in the certificate uses an Internet domain registered to the organisation.

for Associate Card style certificates,

  • an individual can be issued with a S.E.E. Key only in the name by which they are known to the Sponsor's organisation. For devices, the certificate must include the name of the device administrator, the business unit, or the primary business function the device is used for;
  • the S.E.E. Key may only be stamped with the name of the Sponsor's organisation
  • the email address is reliable and approved by the individual, e.g. this should be testing by sending an email to the address, and requesting a reply confirming the validity of the application.

for Passport style certificates

  • the registration process must be at least as rigorous as the Australian GateKeeper Project 100 point system
  • the email address is reliable and approved by the individual, e.g. this should be testing by sending an email to the address, and requesting a reply confirming the validity of the application.

60. Each PKI Entity (e.g. CA, RA, Subscriber or device) must have a clearly distinguishable and unique Distinguished Name (DN) in the certificate subjectName field as defined in the IETF PKIX Certificate and CRL Profile.

61. End-entity DN's must:

  • be in the form of an X.501 or UTF-8 PRINTABLESTRING.
  • either have an association with the authenticated name of the Subscriber or reflect the organisation or organisational unit
  • be unique for all End-Entities of a CA.

62. Additional numbers or letters may be appended to the commonName to ensure the Relative DN's uniqueness.

63. The DN should include an e-mail address.

64. The Subscriber's commonName field should reflect their preferred name e.g., Les Battersby, rather than Lesley Battersby or, in the case of a server certificate, its DNS address, rather than IP address.

65. The DN structure for a Business Card certificate shall be

C=country, S=state, L=location, O=organisation, OU=optional organisation unit, CN=common name, E=e-mail address

    Recommended DN structure

    Business Card DN for Andy Bucket in the Ministry of Water

    Business Card DN for the Ministry of Water's Web site

    C=country

    S=state

    L=location

    O=organisation

    OU=organisation unit (optional)

    CN=common name

    E=e-mail address

    C=NZ

    S=-

    L=-

    O=Ministry of Water

    OU=Drains

    CN=Andy Bucket

    E=andy.bucket@minwater.govt.nz

    C=NZ

    S=-

    L=-

    O=Ministry of Water

    OU=Drains

    CN=www.minwater.govt.nz

    E=itsupport@minwater.govt.nz

66. and certificates differ from the Business Card style certificate only in the ORGANISATION (O=) field of the Distinguished Name.

67. For Passport certificates the Organisation field must be left blank.

68. For Associate Card certificates, the Organisation field must contain mutually agreed text significantly differentiating the certificate from a Business Card certificate. The recommended text is "Associate registered by " <agency name> e.g., O=Associate registered by The Treasury. In this example, Sponsor authorisation by The Treasury would be required before this Associate Card certificate could be issued.

69. The CA must not require any additional fields.

70. The CA and the agency may, include additional fields in the DN, at their joint discretion.

71. Where an alternative type of name form is required in the certificate the SUBJECTALTERNATENAME field may also be used. This usage must be in accordance with PKIX Part 1.

72. Respective identities must be confirmed prior to the exchange of a public or private key or the issuance of a certificate.

  • For Passport style certificates, the Certification Authority/RA and the Subscriber must confirm their respective identities
  • For Business Card and Associate Card style certificates, the Certification Authority/RA and the Sponsor must confirm their respective identities.

73. The appropriate mechanisms for confirming respective identities are either

  • in person,
  • through the use of a shared secret (e.g., secret key or password), or
  • through the use of pre-positioned asymmetric key pairs,

74. The key transfer protocol described in the PKIX Certificate Management Protocol is suitable for the above tasks.

3.2 Authentication for Routine Rekey

75. The Certification Authority or RA must authenticate all requests by Subscribers and Sponsors for issuance of new certificates and key pairs, and subsequent responses.

76. This authentication may be done by an online method in accordance with the PKIX Certificate Management Protocol where the Entity is authenticated using its current key pair.

3.3 Rekey after Revocation

The Certification Authority or RA must re-authenticate the entity in the same manner as for initial registration when there is a known or suspected compromise of an entity's private key.

77. The Certification Authority/RA must verify any change in the information contained in a certificate - via the Sponsor where applicable - before an updated certificate is issued.

3.4 Revocation Request

No stipulation.

4 Operational Requirements

4.1-4.3 Application and Issuance of a Certificate

79. The Certification Authority must ensure that all procedures and requirements with respect to an application for a certificate are set out in its CPS.

80. Only authorised Sponsors (i.e. such persons authorised by both the organisation and the CA) may make bulk applications on behalf of prospective Subscribers.

81. CAs, or RAs on their behalf, must ensure that each application for a certificate is accompanied by:

  • Sponsor authorisation for the certificate to be issued. This will include any use of a departmental identifier in the name or alternate name fields, and authorisation for any requested certificate attributes; and
  • In the case of a Passport certificate, an acknowledgement by the Subscriber of the terms and conditions governing their use of the keys and certificate.

4.4 Certificate Suspension & Revocation

82. The Subscriber, the Sponsor or the CA may initiate a Certificate revocation.

83. A certificate should be revoked:

  • if any of the information in the certificate is no longer true; or
  • if the Subscriber is no longer associated with their Sponsor; or
  • if the private key or the media holding the private key is lost, stolen or compromised; or
  • if the Subscriber disregards any of the obligations set out in their agreement with the CA; or
  • at the request of the Sponsor;

84. The Certification Authority must:

  • publish the revocation in the appropriate CRL and make it available via OCSP until after the certificate's expiry date.
  • ensure an up-to-date CRL is issued at least every eight (8) hours every day of the year (including public holidays)
  • ensure the validity period for OCSP responses does not exceed eight (8) hours
  • have the capability to update and issue an appropriate CRL immediately, for instance in the case of suspected compromise of a Subscriber's private key

85. The subscriber must notify their CA as soon as possible, If a Subscriber's private key is lost or possibly compromised.

86. The Certification Authority must notify the S.E.E. Steering Group immediately, if a CA certificate-signing key is compromised or possibly compromised.

87. A Relying Party must check all the certificates in the validation chain for authenticity and integrity (by checking the digital signature) and validity (against the CAs OCSP service or the applicable CRLs) BEFORE relying on the certificate. The digital signature of each CRL or OCSP response must be checked as part of this process.

88. The Certification Authority should ensure that all procedures and requirements with respect to the revocation of a certificate are set out in their CPS.

4.5 System Security Audit Procedures

89. The Certification Authority must perform periodic vulnerability assessments, where their system is connected to a shared or public network, to ensure resilience to network attack.

90. The vulnerability assessment should take into account any alerts or irregularities in network traffic noticed in the audit logs.

91. The Certification Authority should:

  • record all events relating to their security in audit log files
  • ensure all logs, whether electronic or manual, contain the date and time of the event, and the identity of the entity which caused the event
  • review their audit logs at least once every working day

4.6 Records Archival

92. No stipulation.

4.7 Key Changeover

93. S.E.E. Key certificates must have an expiry date of no longer than THIRTEEN months after the issue date.

94. A new key pair must be generated for the replacement certificate if the existing key pair has been in use for FOUR years or more (i.e. key lifetime period must be no more than FIVE years).

4.8 Compromise and Disaster Recovery

95. The Certification Authority must

  • ensure that their CPS, and any Subscriber agreements, contain provisions outlining the means they will use to provide notice of compromise or suspected compromise
  • have business continuity procedures that outline the steps to be taken in the event of the corruption or loss of computing resources, software and/or data

96. The Certification Authority should have a disaster recovery plan that outlines the steps to be taken to re-establish a secure facility and CA services in the event of a natural or other type of disaster.

4.9 CA Termination

97. The Certification Authority must

  • notify its Subscribers and the S.E.E. Steering Group immediately in the event that a CA ceases operation or changes ownership .
  • ensure arrangements are in place to ensure the CA's and Subscriber's keys are protected and available in accordance with this Policy

5 Physical, Procedural and Personnel Security

5.1 Physical Security Controls

98. Any site housing a CA system or administration terminal must:

satisfy at least the requirements for a Grade 2 site (as per Security In Government Departments) i.e.:

  • structural barriers are used to deter the entry of unauthorised persons outside normal working hours; and
  • an approved security guard patrols outside normal working hours in the vicinity of the site and within the perimeter security barrier are irregular intervals at least once every two hours, with random patrols inside the site at least once every four hours; or
  • an approved intruder detection system is installed and maintained by technically qualified and security cleared personnel.

have restricted access to the CA area. All people not on the authorised access list must be escorted and supervised whenever in the area; and

ensure all removable media and paper containing sensitive plaintext information is stored in at least Group IIIA containers (as per Security In Government Departments).

99. Where CA, RA or Subscriber private keys are stored on a computer or removable media they must be protected at all times from any unauthorised access.

100. All media used for the storage of information such as keys, activation data or CA files is to be sanitised by overwriting or degaussing as described in NZSIT207: Declassification of Storage Media, or destroyed before it is released from a CA's control. When no longer required, paper documents containing operational information should be disposed of or destroyed in a way that makes reconstruction highly unlikely.

101. The Certification Authority must ensure that any facilities used for off-site backup of data or services have the same level of physical access control and monitoring as the primary CA site.

5.2 Procedural Security Controls

102. The Certification Authority must comply with AS/NZS4444 Information Security Management or another approved quality control standard.

5.3 Personnel Security Controls

103. The Certification Authority must

ensure that all CA personnel in operational roles (i.e. those with login or physical access to the CA system and/or database) have achieved an NZ Government CONFIDENTIAL, or equivalent, vetting level. This may be arranged through the S.E.E. Steering Group.

enforce their obligations on staff in regard to Subscriber privacy and service expectations.

ensure that all personnel performing CA or RA duties have received appropriate training in:

  • PKI security principles and mechanisms;
  • the operation of the CA and/or RA hardware and software; and
  • all relevant procedures and requirements in this Policy and their Certification Practice Statement.

104. The Certification Authority manager must:

  • authorise any contractors or non-CA personnel requiring access to the CA site
  • ensure such visitors are escorted during their visit.
  • ensure such visitors are not permitted physical access to the CA workstation unless required for CA operation and only under supervision

6 Technical Security Controls

6.1 Key Pair Generation and Installation

105. Subscriber key pairs must be 1024 bit RSA. CAs' keys may be 1024 bit or 2048 bit RSA.

106. Each key pair should be generated using a S.E.E. Steering Group approved key generation algorithm or system. Any keys passed between the CA and the Subscriber at this time must be either delivered in an on-line transaction in accordance with PKIX-3 Certificate Management Protocol, or via an equally secure manner.

107. Keys may be used for authentication, message integrity and session key establishment. Only CA signing keys must be permitted for signing certificates and CRLs.

108. The certificate KEYUSAGE field must be used in accordance with PKIX-1 Certificate and CRL Profile.

109. The DIGITALSIGNATURE key usage value must be present in all certificates.

110. KEYCERTSIGN and CRLSIGN values must only be present in CA certificate-signing certificates.

6.2 Private Key Protection

111. Each Entity must physically protect their private keys from disclosure and tampering.

112. Subscriber private keys for Passport and Business Card certificates must be stored and processed in hardware cryptomodules (e.g. a smartcard, PC card, USB token, etc)

113. The cryptomodule must be protected from theft or misuse to a similar level to a driver's licence or credit card.

114. Subscriber private keys for Associate Card certificates may be software based or stored and processed in hardware cryptomodules.

115. Private keys for server and other devices may be software based or stored and processed in hardware cryptomodules.

116. Subscriber's private keys may be backed up by the Subscriber, the CA, or a third party on behalf of the Sponsor on the proviso that the back-up keys are not stored on-line, never reside outside New Zealand, and are protected from physical harm and compromise. They should be stored in an encrypted and password protected form (using Triple DES, AES or equivalent).

117. Subscribers must be authenticated to their cryptographic modules before their private keys are activated (e.g. by a PIN, password or biometrics comparision).

118. Whenever private keys are inactive they must be available only in an encrypted form.

119. The cryptomodule and/or computer should also include mechanisms to prevent extraction of the private key(s) by an unauthorised user or malicious software.

120. All keys (including CA keys) must have validity periods of no more than FIVE years, except for 2048 bit CA keys which may have a validity period of up to TWENTY years.

121. The S.E.E. Steering Group reserves the right to make such changes as are required, if in their opinion, any deficiency in the security of the PKI is suspected.

6.3 Other Aspects of Key Pair Management

122. No stipulation.

6.4 Activation Data

123. Any activation data such as passwords and shared secrets (e.g. between a subscriber and their CA) must be unpredictable and unrelated to other user's activation data.

124. Subscribers must have the capability to change their passwords at any time.

125. The cryptographic token should include a facility to temporarily lock the token after a predetermined number of login attempts, if a reusable password scheme is used.

6.5 Computer Security Controls

126. The Certification Authority must include the following system security functionality:

  • Unique identification and authentication of CA operators;
  • System controlled access to the CA functions;
  • Use of cryptography for session communication and database security;
  • Archival of CA and Subscriber history and audit data; and
  • Self-test of security related CA services and audit of security related events.

This functionality may be provided by the operating system, or through a combination of operating system, CA software, and physical safeguards.

127. The Certification Authority operating system and application software should be evaluated to an assurance level of at least ITSEC-E2 or Common Criteria EAL3 (refer to the AISEP area on www.dsd.gov.au/infosec or www.commoncriteria.org)). Only the services required for the CA tasks - including CA management and protection - should be active on the CA server.

128. The Certification Authority system should include a virus detection system that is kept up to date.

6.6 Life Cycle Technical Controls

129. The Certification Authority must ensure:

that a documented configuration management procedure is used for installation and ongoing maintenance of the CA system.

the CA personnel verify the CA software during installation, to confirm it:

  • originated from the software developer;
  • has not been modified prior to installation; and
  • is the version intended for use.

The integrity of the software and configuration should be verified at regular intervals.

6.7 Network Security Controls

130. The Certification Authority server must be protected from attack through any open or general-purpose network it is connected to. Such protection must include the use of a firewall certified to EAL3 or better and configured to allow only the protocols and commands required for the operation of the CA.

131. The Certification Authority subnet should be protected against all AusCERT-published vulnerabilities.

132. A network intrusion detection system should be in place with appropriate procedures and responsibilities defined to manage any alerts appropriately.

133. The RA must satisfy all the physical, personnel and network security controls required for a CA site, in situations where an RA has Subscriber administration access on the CA server. Certificate-based authentication and encryption must be used to secure the connection.

6.8 Cryptographic Module Engineering Controls

134. All CA, RA and End-entity cryptographic functions must be performed in cryptographic modules that have been evaluated to a minimum of either FIPS140 Level 2, ITSEC level E2, or common Criteria EAL3.

135. The cryptographic application software used by RAs and End-entities should:

  • establish, transfer and use the public and private keys correctly and in a secure fashion;
  • be capable of performing the appropriate certificate validity and verification checking; and
  • report appropriate information and warnings to the user.

136. The Certification Authority, RA and Subscriber crypto-modules must support RSA 1024 and 2048 (as per PKCS#1) and SHA-1 (as per FIPS PUB 180-1 / ANSI X9.30).

7 Certificate and CRL Profiles

7.1 Certificate Profile

137. All certificates must be X.509 Version 3 in accordance with the PKIX Certificate and CRL Profile.

138. The PKI End-Entity software must support all the base (non-extension) X.509 fields as well as the certificate extensions identified in section 4.2.2 of the PKIX certificate profile.

139. The CRL Distribution Point (CDP) defined in each certificate must specify the location of the CRL and the protocol used to address and obtain it (either HTTP or LDAP).

140. The Authority Information Access extension should specify an OCSP service, and if specified, must specify HTTP or HTTPS as the protocol.

141. The Certificate Policies extension must specify the appropriate Certificate Policy OID as per Section 1.2, for all certificates issued under this policy.

7.2 CRL Profile

142. All CRLs must be X.509 Version 2 in accordance with the PKIX Certificate and CRL Profile.

8 Specification Administration

8.1 Specification Change Procedures

143. The S.E.E. Steering Group will notify all approved CAs in writing of any non-minor changes to this Policy.

144. The S.E.E. Steering Group may assign a new OID for the modified Policy, in some circumstances.

8.2 Publication and Notification Policy

145. An electronic copy of this document is available via an e-mail request to pki@security.govt.nz or from the S.E.E. Web site, URL http://www.see.govt.nz/pki/. Any changes to the Policy will be posted to the Web site.

8.3 CPS Approval Procedures

146. Refer Section 2.7 Compliance Audit.

9 Glossary

CA (Certification Authority)

An entity trusted by users to issue and manage X.509 public key certificates and CRLs.

CP (Certificate Policy)

A standard by which public key certificates and keys are issued and managed. The CP that a specific certificate is issued under should be referenced in the certificate's certificatePolicy field.

CPS (Certification Practice Statement)

A Certification Authority's security plan and standard operating procedures.

CRL (Certificate Revocation List)

An electronically signed list of certificates that should no longer be trusted but have not yet expired. Each CA will issue one or more CRLs. The location of the relevant CRL for a specific certificate will be defined in the certificate's CRL Distribution Point (CDP) field.

DN (Distinguished Name)

An ISO X.500 term defining a standard for unique identifiers for people, devices or other objects.

EAL (Evaluation Assurance Level)

International Common Criteria IT product security testing evaluation level. EAL1 is the lowest level of testing; EAL7 is the highest.

End-entity

The users of the certificates and keys, for instance, Subscribers, Webservers, S.E.E. Mail gateways, etc.

FIPS (Federal Information Processing Standards)

A set of IT security standards promulgated by the US National Institute of Standards and Technology.

HTTP (Hypertext Transfer Protocol)

The primary application-level communications protocol of the World Wide Web.

IETF PKIX (Internet Engineering Task Force PKI X.509)

References the Internet Working Group on PKI and their resulting standards.

IN-CONFIDENCE

Compromise of such information would be likely to prejudice the maintenance of law and order, impede the effective conduct of government in New Zealand, or affect adversely the privacy of its citizens.

ITSEC (IT Security Evaluation Criteria)

UK Government IT product security testing criteria. Evaluations go from E1 (lowest assurance = EAL2) to E6 (mathematically proven = EAL7)

LDAP (Lightweight Directory Access Protocol)

An Internet protocol for communicating with directories.

NZSIT (NZ Security of IT)

A set of IT security publications promulgated by the Government Communications Security Bureau.

OCSP (Online Certificate Status Protocol)

An Internet protocol used by a client to obtain from a server the validity status and other information concerning a digital certificate. OCSP provides more up-to-date status than is possible with CRLs at the expense of increased network traffic, latency and dependence on the OCSP service. The location of the relevant OCSP service for a specific certificate will be defined in the certificate's Authority Information Access field.

OID (Object Identifier)

The unique alphanumeric/numeric identifier registered under the ISO registration standard to reference a specific object or object class. Certificate policies and cryptographic algorithms are two such classes.

PKCS (Public Key Cryptographic Standard)

Cryptographic guidelines promulgated by RSA Inc.

RA (Registration Agent/Authority)

An entity that is responsible for the identification and authentication of Subscribers before certificate issuance, but does not actually create or issue the certificates. The RA is a delegated agent of the CA.

S.E.E. (Secure Electronic Environment)

NZ Government initiative to provide secure interaction and collaboration between Government departments and agencies across the Internet.

SENSITIVE

Compromise of such information would be likely to damage the interests of the New Zealand government or endanger the safety of its citizens.

SIGD

Security in Government Departments manual available at http://www.security.govt.nz/sigd/

Sponsor

The department or public servant that has nominated an individual or organisation to be issued a certificate. The Sponsor is responsible for either supplying or confirming an individual's requirement for a certificate and the attribute details in the certificate. The Sponsor is also responsible for informing the CA or RA if the department's relationship with the Subscriber is terminated or changed such that the certificate should be revoked or updated. Some organisations may combine the Sponsor and Registration Agent roles.

Steering Group (SG)

The body responsible for setting, implementing and administering this Certificate Policy statement and overseeing the CA's issuing certificates under it. The S.E.E. Steering Group is the Policy Management Authority (PMA) for S.E.E. PKI.

Subscriber

An individual or organisation whose public key is certified in a public key certificate. In the Government context this could be a public servant, a citizen, or a Government client or supplier.

URL (Universal Resource Locator)

World Wide Web address of a computer or file.