Skip to content.
|Networking government in New Zealand.
 
You are here: Home » Services » SEEMail » S.E.E. PKI Certificate Policy Version 2.0 » 7 Certificate & CRL profiles

7 Certificate & CRL profiles

a name="content">

7.1 Certificate Profile

7.1.1 Version number(s)

152. The Certification Authority must ensure

  • All certificates are X.509 Version 3 in accordance with the PKIX Certificate and CRL Profile.

7.1.2 Certificate extensions

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

7.1.3 Algorithm object identifiers

154. No stipulation.

7.1.4 Name forms

155. The Certification Authority must ensure

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

  • End-entity distinguishedName's

    • Are 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
    • Are unique for all End-Entities of the CA.

156. The Certification Authority mustnot mandatorily require any additional fields.

157. The Certification Authority and the Sponsor may

  • Include additional fields in the DN, at their joint discretion.

  • Use the subjectAlternateName field where an alternative type of name form is required in the certificate. This usage must be in accordance with PKIX Part 1.

158. The Sponsor should determine the structure of the distinguishedName.

7.1.5 Name constraints

159. The DN structure for a certificate shall be:

  • C=country

  • S=state

  • L=location

  • O=organisation

  • OU=optional organisation unit

  • CN=common name

  • E=e-mail address

160. The Certification Authority must ensure

For the distinguishedName

  • The Organisation (O= ) field should reflect the proper relevant legal name of the organisation name e.g. O=Ministry of Water, not O=minwtr.govt.nz.

  • The State (S= ) field must be set to "-", however applications should not require the presence or otherwise of the S= field in the DN.

  • The Organisational Unit (OU=) field should be used to provide additional information, such as liability disclaimers.

  • The Common Name (CN=) field must be used to differentiate certificate types, using the generic format "CN = Commonname [SEEKEY name]".

  • The Common Name (CN=) field must not be used in conflict with the labels defined in this Policy

  • The Common Name (CN=) field should reflect the subcriber's 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.

For PASSPORT certificates

  • The distinguishedName Organisation field may be blank, or may contain the name of the CA organisation prefixed with a string such as "Identity authenticated by". An appropriate example is "Identity authenticated by ACME-CA Associates".

For BUSINESS CARD certificates

  • The distinguishedName Organisation (O= ) field must contain the Sponsor's name.

For ASSOCIATE certificates

  • The distinguishedName Organisation (O= ) field must contain the Sponsor's name prefixed with a mutually agreed string, such as "Associate registered by ". An appropriate example is "Associate of The Treasury".

  • The distinguishedName Organisation Unit (OU= ) field should contain a disclaimer to differentiate it significantly from a BUSINESS-CARD style certificate.

For ANONYMOUS certificate

  • The distinguishedName Organisation (O= ) field must contain "-" or the Sponsor's name.

  • The distinguishedName Common Name (CN= ) field must be set to "ANONYMOUS arbitraryString" , where arbitraryString is a unique value.

161. The Certification Authority may ensure the distinguishedName's uniqueness by appending additional numbers or letters to the commonName.

7.1.6 Certificate Policy Object Identifier (OID)

162. The SEEKEY Certificate Table lists the SEEKEY Certificate Types. Each Certificate Type has a corresponding Alphanumeric OID and Numeric OID.

163. The Certificate Type Numeric OID is specified by adding a unique numeric suffix (.1, .2, etc) to the SEEKEY Certificate Policy OID (2.16.554.101.2.1.1).

164. The Certificate Type Alphanumeric OID is a unique label, prefixed by the label "SEEKEY", used to describe the purpose of the Certificate Type, e.g. "SEEKEY BUSINESS-CARD"

165. These OIDs are not formally registered.

166. The Certification Authority must ensure

  • For each certificate issued under this Policy, that the Certificate Policies extension specifies the appropriate

    • Certificate Type Numeric OID (e.g. 2.16.554.101.2.1.1.6), and
    • A userNotice of the certificate type as it appears in the CN (e.g. [SEEKEY ASSOCIATE-ROLE], and
    • A cpsUri of http://see.govt.nz/pki/cp/seekey/#/ where # is the certificate type e.g. http://see.govt.nz/pki/cp/seekey/associate-role/

7.1.7 Usage of Policy Constraints extension

7.1.8 Policy qualifiers syntax and semantics

7.1.9 Processing semantics for the critical certificate policy extension

167. The Certification Authority must ensure

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

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

7.2 CRL Profile

168. The Certification Authority must ensure

  • All CRLs are X.509 Version 2 in accordance with the PKIX Certificate and CRL Profile.


[ Previous | Next ]