Skip to content.
|Networking government in New Zealand.
 
You are here: Home » Services » SEEMail » S.E.E. PKI Certificate Policy Version 2.0 » 4. Operational requirements

4. Operational requirements

4.1 Certificate Application

4.2 Certificate Issuance

82. The CA must ensure any 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).

83. The CA's registration process must be sufficiently rigorous that for PASSPORT certificates

  • It is 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 tested by sending an email to the address, and requesting a reply confirming the validity of the application.

  • It, or one of its RAs has verified the identity and authorisation of the Subscriber in accordance with Identification & Authentication (Section 3)

  • The details in the certificate must match the Subscriber's details,

84. The CA's registration process must be sufficiently rigorous that for BUSINESS CARD certificates

  • The Sponsor delegated from CE of organisation has approved certificate request;

  • 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.

  • 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.

  • Ensure that it has appropriately verified the identity and authorisation of the Sponsor in accordance with Identification & Authentication (Section 3)

  • Ensure that the organisation name and email address / Internet domain details in the certificate match the Sponsor's organisation details.

  • Only request BUSINESS CARD certificate with Internet domain names (e.g. in email addresses and urls) that are in the control of the organisation name requested.

85. The CA's registration process must be sufficiently rigorous that for ASSOCIATE certificates

  • It has appropriately verified the identity and authorisation of the Sponsor in accordance with Identification & Authentication (Section 3);

  • 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 organisation name details in the certificate match the Sponsor's organisation details

  • 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.

86. The CA's registration process must be sufficiently rigorous that for ANONYMOUS certificates

  • The DN's uniqueness is assured.

  • If a private key is lost together with its certificate, the details of the certificate will give no clue to what it may unlock.

87. The CA's registration process must be sufficiently rigorous that for SMART-TOKEN certificates

  • The private key associated with the certificate is stored in a non-exportable form on a hardware token as per Certificate Policy.

88. The CA's registration process must be sufficiently rigorous that for PROXY certificates

  • The private key is stored on a gateway server acting on behalf of the individual, e.g. email gateway signing or proxy authentication to a server.

89. The CA's registration process must be sufficiently rigorous that for ACCESS certificates

  • The "non-repudiation" key usage flag should NOT be set.

90. The CA's registration process must be sufficiently rigorous that for ID certificates

  • The "digital signature" key usage flag should be set.

91. The CA's registration process must be sufficiently rigorous that for SIGN certificates

  • The "non-repudiation" key usage flag should be set.

92. The CA's registration process must be sufficiently rigorous that for ENCRYPTION certificates

  • The "digital signature" key usage flag should be set.

4.3 Certificate Acceptance

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

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

95. 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

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

97. 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;

98. 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

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

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

101. 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.

102. 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

103. 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.

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

105. 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

106. No stipulation.

4.7 Key Changeover

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

108. 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

109. 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

110. 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.

CA Termination

111. 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


[ Previous | Next ]