psn certificate policy ipsec il3 - gov.uk

UNCLASSIFIED

UNCLASSIFIED

PSN Certificate Policy IPsec IL3

Public Services Network Programme

Version 1.0

Prepared by: PSN Core Team, CESG

Date Prepared: 31/07/12

UNCLASSIFIED


Author: Pete Bentley/Paul Meachen PSN Certificate Policy IPsec IL3 v1.0

of 99

This information is exempt from disclosure under the Freedom of Information Act 2000 and may be subject to exemption under other UK

information legislation. Refer disclosure requests to GCHQ on 01242 221491 x30306, email [email protected]

UNCLASSIFIED

Document Information

Project Name: PSN Programme

Prepared By: CESG Document Version No: 1.0

Title: PSN Certificate Policy IPsec IL3 Document Version Date: 31/07/12

Approved By: PSN Design Authority Review Date: 30/07/12

Version History

Ver.

No.

Ver. Date Revised By Description Filename

0.1 19 March

2011 Paul Allen and Paul

Wakeley

First version for initial review PB275D004-0.1 PSN draft

Certificate Policies.docx

0.2 8 July 2011 Paul Allen Incorporates comments from Cabinet

Office

PB275D004-0.2 PSN draft


0.3 20 October

2011 Paul Allen Incorporates further comments from

CESG

PB275D004-0.3 PSN draft


0.4 25/11/11 Malcolm Duncan Further resolution of comments PB275D004-0.4 PSN draft


0.5 01/12/11 Malcolm Duncan Further resolution of comments PB275D004-0.4 PSN draft


0.6 2/12/11 Steve Lomas Track changes corrections and

comments deleted resolved. Legal

questions resolved.

PSN Draft Certificate Policy

v0.6.docx. Discovery ref.

15065285

0.7 09/03/12 Pete Bentley/Paul

Meachen

New document based on previous

versions, updated based on review

comments and targeted to IPsec IL3.

PSN Draft Certificate Policy

v0.7.docx. Discovery ref.

16927308

0.8 22/05/12 Pete Bentley/Paul

Meachen

Update based on latest comments and

used for further legal review purposes.

PSN Draft Certificate

Policy_IPsec IL3 v0.8.doc

Discover ref. 18200119

0.9 24/06/12 Paul Meachen Issue for baseline review. PSN Draft Certificate

Policy_IPsec IL3 v0.9.doc


0.9.2 08/07/12 Paul Meachen Updated after Review. Version for SF

review.


Policy_IPsec IL3 v0.9.2.doc


0.9.3 19/07/12 Paul Meachen Changes to format issues in PDF

version. Version for DA review


Policy_IPsec IL3 v0.9.2.doc


UNCLASSIFIED



of 99



UNCLASSIFIED

Approvals

1.0 30/07/12 Paul Meachen Baseline version for testing following

Design Authority approval on 30 July

2012

PSN Certificate Policy IPsec

IL3 v1.0


Title Signature

Programme Director

PKI Working Group (Review Group)

Encryption Work Stream (Forum)

Security Forum

Design Authority

UNCLASSIFIED



of 99



UNCLASSIFIED

Table of Contents

1. Introduction ...................................................................................................................... 7

1.1 Overview .......................................................................................................................... 7

1.2 Document name and identification ................................................................................... 8

1.3 PKI participants ................................................................................................................ 8

1.4 Certificate usage ............................................................................................................ 10

1.5 Policy administration ...................................................................................................... 11

1.6 Definitions and acronyms ............................................................................................... 11

2. Publication and Repository Responsibilities .................................................................. 12

2.1 Repositories ................................................................................................................... 12

2.2 Publication of certification information ............................................................................ 13

2.3 Time or frequency of publication .................................................................................... 13

2.4 Access controls on repositories ..................................................................................... 13

3. Identification and Authentication .................................................................................... 15

3.1 Naming .......................................................................................................................... 15

3.2 Initial identity validation .................................................................................................. 16

3.3 Identification and authentication for re-key requests ...................................................... 18

3.4 Identification and authentication for revocation request ................................................. 19

4. Certificate lifecycle operational requirements ................................................................ 20

4.1 Certificate application ..................................................................................................... 20

4.2 Certificate application processing .................................................................................. 21

4.3 Certificate issuance ........................................................................................................ 21

4.4 Certificate acceptance ................................................................................................... 22

4.5 Key pair and certificate usage ........................................................................................ 23

4.6 Certificate renewal ......................................................................................................... 25

4.7 Certificate re-key ............................................................................................................ 25

4.8 Certificate modification ................................................................................................... 27

4.9 Certificate revocation and suspension ........................................................................... 27

4.10 Certificate status services ..................................................................................... 32

4.11 End of subscription................................................................................................ 33

4.12 Key escrow and recovery ...................................................................................... 33

5. Facility, Management and Operational Controls ............................................................ 34

5.1 Physical controls ............................................................................................................ 35

5.2 Procedural controls ........................................................................................................ 36

UNCLASSIFIED



of 99



UNCLASSIFIED

5.3 Personnel controls ......................................................................................................... 38

5.4 Audit logging procedures ............................................................................................... 39

5.5 Records archival ............................................................................................................ 43

5.6 Key changeover ............................................................................................................. 44

5.7 Compromise and disaster recovery ............................................................................... 45

5.8 CA or RA termination ..................................................................................................... 47

6. Technical Security Controls ........................................................................................... 48

6.1 Key pair generation and installation ............................................................................... 48

6.2 Private Key protection and cryptographic module controls ............................................ 50

6.3 Other aspects of key pair management ......................................................................... 53

6.4 Activation Data ............................................................................................................... 53

6.5 Computer security controls ............................................................................................ 54

6.6 Life cycle technical controls ........................................................................................... 54

6.7 Network security controls ............................................................................................... 55

6.8 Time-stamping ............................................................................................................... 56

7. Certificate, CRL, and OCSP Profiles .............................................................................. 57

7.1 Certificate Profile ............................................................................................................ 57

7.2 CRL Profile..................................................................................................................... 59

7.3 OCSP profile .................................................................................................................. 59

8. Compliance Audit and Other Assessment ..................................................................... 61

8.1 Frequency or circumstances of assessment .................................................................. 61

8.2 Identity/qualifications of assessor .................................................................................. 61

8.3 Assessor‟s relationship to assessed entity ..................................................................... 61

8.4 Topics covered by assessment ...................................................................................... 62

8.5 Actions taken as a result of deficiency ........................................................................... 62

8.6 Communication of results .............................................................................................. 63

9. Other Business and Legal Matters ................................................................................. 63

9.1 Fees ............................................................................................................................... 63

9.2 Financial responsibility ................................................................................................... 64

9.3 Confidentiality of business information ........................................................................... 64

9.4 Privacy of information .................................................................................................... 65

9.5 Intellectual property rights .............................................................................................. 65

9.6 Representations and warranties .................................................................................... 65

9.7 Disclaimers of Warranties .............................................................................................. 66

9.8 Limitations of liability ...................................................................................................... 66

UNCLASSIFIED



of 99



UNCLASSIFIED

9.9 Indemnities..................................................................................................................... 66

9.10 Term & termination ................................................................................................ 66

9.11 Individual notices and communications with participants ...................................... 66

9.12 Amendments ......................................................................................................... 66

9.13 Dispute resolution provisions ................................................................................ 67

9.14 Governing law ....................................................................................................... 67

9.15 Compliance with applicable law ............................................................................ 67

9.16 Miscellaneous provisions ...................................................................................... 67

9.17 Other provisions .................................................................................................... 67

Annex A. References ....................................................................................................... 69

Annex B. Acronyms and Abbreviations ............................................................................ 70

Annex C. Glossary ........................................................................................................... 73

Annex D. PSN CSR Template .......................................................................................... 77

Annex E. PSN IL3 IPsec Root CA Certificate Profile (Interim) ......................................... 79

Annex F. PSN IL3 IPsec Root CA Certificate Profile (End-state) ..................................... 82

Annex G. PSN IL3 Sub-CA Certificate Profile (Interim) .................................................... 84

Annex H. PSN IL3 Sub-CA Certificate Profile (End-state) ................................................ 87

Annex I. PSN IL3 Certificate Revocation List (CRL) Profile (Interim) .............................. 90

Annex J. PSN IL3 Certificate Revocation List (CRL) Profile (End-State) ......................... 92

Annex K. PSN IL3 End-entity Certificate Profile (Interim) ................................................. 94

Annex L. PSN IL3 End-entity Certificate Profile (End-state) ............................................ 97

UNCLASSIFIED



of 99



UNCLASSIFIED

1. Introduction

1.1 Overview

1.1.1 This document details the Certificate Policy (CP) to be used across the Public Services Network (PSN) for Internet Protocol Security (IPsec) at Impact Level 3 (IL3).

1.1.2 The PSN Public Key Infrastructure (PKI) Certificates are intended for use in supporting the infrastructure of the PSN and are currently limited to the authentication of IPSec for data communications. This Certificate Policy defines the community, usage and security requirements associated with the digital certificates.

1.1.3 This document covers the PSN IL3 IPsec CP, which is intended for authentication of IPsec communications required to create an IL3 (RESTRICTED) capability over the PSN (IL 2-2-4 network).

1.1.4 This document states the minimum requirements necessary to support trust in an IL3 IPsec authentication Certificate and details the minimum standards required for the Certificate Policy; individual Certification Authorities (CAs) may exceed the specifications of this Certificate Policy.

1.1.5 The Certificate Policy is a fundamental part of the compliance process. Organisations wishing to provide a CA must produce a Certificate Practice Statement (CPS) which complies with the obligations contained in the Certificate Policy.

1.1.6 The issue of a Certificate to a CA under this Certificate Policy signifies that the CA is approved by the PSN Authority (PSNA) to issue Certificates under this Certificate Policy, has followed the procedures specified in this document, and that there is a high level of assurance that the name on the Certificate is a valid representation of the identity of the CA to which it relates.

1.1.7 The issue of a Certificate by a CA to a Registration Authority (RA) under this Certificate Policy signifies that the RA is approved to perform delegated tasks on behalf of that CA, has followed the procedures specified in this document, and that there is a high level of assurance that the name on the Certificate is a valid representation of the identity of the RA to which it relates

1.1.8 The structure of this Certificate Policy document has been based on IETF RFC3647.

1.1.9 A target audience for this document is anyone who needs to write a CPS for the PSN PKI. A CPS shall be produced by anyone generating certificates or managing keys in accordance with this Certificate Policy and shall define how the clauses within this Certificate Policy are implemented.

1.1.10 The PSN PKI is based on a Hierarchical Trust Model. It relies on a single CA at the top of a CA hierarchy. The complete trust model is derived from the root certificate hence every device must trust the Root CA. It is implemented by distributing the public key of the Root CA and scalability and local control

UNCLASSIFIED



of 99



UNCLASSIFIED

is provided by a number of Subordinate Certification Authorities (Sub-CA‟s) between the root and the end devices.

1.1.11 It is the long term intention of the PSN PKI to support multiple certificate policies for different business functions each of which will require a separate root certificate and will be documented either via extensions to this Certificate Policy or by separate Certificate Policy documents.

1.1.12 This Certificate Policy defines the implementation of the PSN PKI for IPsec IL3 only at this time.

1.2 Document name and identification

1.2.1 The name of this document is the PSN Certificate Policy for IPsec IL3 and the Object Identifier (OID) of this Certificate Policy is 1.2.826.0.1316.3.0.0.

1.3 PKI participants

1.3.1 Certification Authorities

1.3.1.1 The PSN PKI for IPsec IL3 will eventually consist of a single hierarchy with a

single trusted root certificate. Initially (until 2018) the PSN PKI will consist of

a dual hierarchy with 2 root certificates one to support the “interim” IPsec

profile and one to support the “end state” PRIME IPsec profile.

Figure 1 PSN PKI Hierarchy

1.3.1.2 At the top of the hierarchy is the Root CA. The Root Certificate Authority will

be managed, operated and coordinated by the PSN Authority (PSNA). The

PEPAS or CAPS IPsec devices

Eligible Certification Authorities

Root Certificate Authority (PSNA)

Cryptographic Root of Trust

(CESG)

Root CA

Sub-CA Sub-CA

End-entity Subject

End-entity Subject

End-entity Subject

Sub-CA

UNCLASSIFIED



of 99



UNCLASSIFIED

PSNA has been established as a function within the Cabinet Office, with its

authority coming from the Minister for the Cabinet Office.

1.3.1.3 To support the PSNA in delivering the Root Certificate Authority capability,

CESG will provide the cryptographic trust in the delivery of the Root

Authority. CESG shall be defined as the Cryptographic Root of Trust and

will provide the PSN IPsec IL3 Root Certificate (known as the Root

Certificate).

1.3.1.4 It shall be possible to form a validation path from all PSN certificates up to

the Root Certificate.

1.3.1.5 At the second layer of the hierarchy are Sub-CAs which issue certificates to

devices. The CA hierarchy should have as few layers as possible to allow

devices to perform full certificate chain verification with minimum effort. This

means Sub-CA suppliers shall not create subordinate Sub-CAs.

1.3.1.6 If required organisational differentiation within a Sub-CA supplier can be

achieved with DN attributes in the certificate. A Sub-CA supplier can operate

a separate CA entity for management purposes if separate management and

production certificates are required for devices that do not support multiple

certificates from one CA. In all cases Sub-CAs must trust the same Root

Certificate.

1.3.1.7 The organisations entitled to apply to operate as a Sub-CA within the PSN

PKI („Eligible Certification Authorities‟) are:

a. PSN Direct Network Service Providers (DNSP), who can issue

Certificates to any PSN Subscriber;

b. PSN Service Providers (SP), who can issue certificates to any PSN

Subscriber;

c. any HMG department or UK public sector organisation, who can

issue certificates internally within the organisation; and

d. any organisation that has been authorised by the PSNA to apply to

operate as a PSN Sub-CA for the PSN PKI.

1.3.1.8 Operation of a Sub-CA is subject to approval by the PSNA and is conditional

on successful completion the PSN compliance process, reference [13].

1.3.1.9 While a Sub-CA may use a contractor to provide certification services, the

Sub-CA organisation itself remains responsible and accountable to the

PSNA and to any Relying Party for its operation.

1.3.2 Registration Authorities

UNCLASSIFIED



of 99



UNCLASSIFIED

1.3.2.1 The organisations entitled to apply to operate as a Registration Authority

(RA) within the PSN PKI („Eligible Registration Authorities‟) are:

a. PSN DNSP, who can register certificates to any PSN Subscriber;

b. PSN SP, who can register certificates to any PSN Subscriber;

c. any HMG department or UK public sector organisation, who can

register certificates internally within the organisation; and

d. any organisation that has been authorised by the PSNA to apply to

operate as a RA for the PSN PKI.

1.3.2.2 The RA remains responsible and accountable to the Sub-CA that it supports.

1.3.3 End-Entities

1.3.3.1 End-entities can be considered to consist of:

a. Subscribers, the organisations or individuals responsible for End-

entity Certificates; and

b. Subjects, the devices that use the End-entity Certificates

1.3.3.2 The following entities may be End-entity Subscribers of the PSN PKI

(„Eligible End-entity Subscribers‟):

a. PSN DNSP or;

b. PSN SP; or

c. PSN public sector customer that adheres to the PSN Code of

Connection

1.3.3.3 For IPsec IL3 certificates the following entities may be End-entity Subjects of

the PSN PKI:

a. PSN Encryption Products Assurance Scheme (PEPAS) assured

devices and

a. The CESG Assisted Products Scheme (CAPS) assured devices

1.3.3.4 The assurance requirements for cryptographic devices are detailed in the

PSN Cryptographic Framework, reference [1].

1.3.4 Relying Parties

1.3.4.1 The Relying Party community is the same as the Subscriber community.

1.3.5 Other participants

1.3.5.1 The Root CA and Sub-CA‟s will provide Certificate Status Services in the

PSN PKI.

1.4 Certificate usage

UNCLASSIFIED



of 99



UNCLASSIFIED

1.4.1 Appropriate certificate usage

1.4.1.1 Certificates issued under this Certificate Policy shall only be used to support

the operation of the PSN and shall adhere to the approved Certificate

Profiles details in section 7 and tables in Annex E - Annex L.

1.4.1.2 PSN IL3 IPsec certificates shall only be used for authenticating IL3 IPsec

transactions within the PSN.

1.4.2 Prohibited certificate usage

1.4.2.1 Certificates shall not be used for devices in any networks other than the

PSN. This includes, but is not limited to, connecting corporate networks and

the Internet.

1.5 Policy administration

1.5.1 Organisation administering the document

1.5.1.1 The Policy Management Authority (PMA) for this Certificate Policy will be the

PSNA.

1.5.1.2 The PMA shall be responsible for the publication, revision and interpretation

of this policy.

1.5.1.3 The address for any correspondence is PSNA Operations Director, Cabinet

Office, 1 Horse Guards Road, London SW1A 2HQ.

1.5.2 Contact person

1.5.2.1 The contact person for all matters relating to this Certificate Policy is the

PSNA Security Manager, Cabinet Office, 1 Horse Guards Road, London

SW1A 2HQ.

1.5.3 Person Determining CPS suitability for the policy

1.5.3.1 The PMA shall be responsible for determining the suitability of any

Certification Practice Statement (CPS), Subscriber Agreement and Relying

Party Agreements that relate to this policy.

1.5.4 CA & CPS approval procedures

1.5.4.1 A CA‟s enrolment into the PSN PKI must be in accordance with procedures

specified in PSN Compliance Policy reference [13], the PSN PKI Operating

Model ref [7] and acceptance of the clauses within this Certificate Policy.

1.6 Definitions and acronyms

1.6.1 The terms used in this Certificate Policy are defined in the Glossary Annex B

UNCLASSIFIED



of 99



UNCLASSIFIED

2. Publication and Repository Responsibilities

2.1 Repositories

2.1.1 The Public Key Directory (PKD) used by PSN will be a logical construct made up of a set of federated repositories. The individual repositories will be owned and managed by PSNA (PSN PKD) and each Sub-CA provider (Sub-CA PKD).

Figure 2 The PKD

2.1.2 The PKD shall store copies of all Sub-CA Certificates and the Certificate Revocation Lists (CRLs). The contents of the individual repositories that make up the logical PKD may be replicated to provide redundancy; however, there must be one master for the replicated information.

2.1.3 The CRL produced by the Root CA is also known as the Authority Revocation List (ARL).

2.1.4 The PSNA performs the role of RA for the Root CA and receives the Sub-CA signing requests. The PSNA passes the signing requests to the Cryptographic Root of Trust which signs the Sub-CA certificates. The PSNA receives the signed Sub-CA certificates and distributes them to the Sub-CA.

2.1.5 The Root Certificate and the CRL relating to Sub-CAs are distributed by the Cryptographic Root of trust to PSNA who publishes them in to the PSN PKD.

2.1.6 As an interim the PSNA may distribute the Root Certificate and CRL relating to Sub-CAs to the Sub-CA‟s for publishing in the Sub-CA PKDs alongside Sub-CA certificates and CRLs relating to End-entity devices.

Sub-CA providers

Registration Authority for the Root CA (PSNA)

Cryptographic Root of Trust (CESG)

Root Certificate, Signed Sub-CA Certificates & CRL relating to

Sub-CAs

PSN PKD

Sub-CA PKD Sub-CA PKD

Sub-CA Certificates and CRLs relating to

End-entities

UNCLASSIFIED



of 99



UNCLASSIFIED

2.1.7 Every Sub-CA provider is responsible for providing the relevant data (CRLs, Certificates etc.) to enable IL3 connectivity to its own End-entity devices from other End-entity device from other Sub-CA providers.

2.1.8 The Sub-CA CRL distribution point should be reachable by all End-entity devices.

2.1.9 For services within IL3 the PKD needs to be present at IL3. To enable initial bootstrapping of the IL3 enabling infrastructure End-entity devices the whole PKD requires presentation at IL2.

2.1.10 The address for any correspondence regarding the overall PKD is the PSNA Operations Director, Cabinet Office, 1 Horse Guards Road, London, SW1A 2HQ.

2.2 Publication of certification information

2.2.1 All CA certificates (Root CA & Sub-CA) and CRLs (produced by the Root CA and Sub-CAs) shall be published to the PKD.

2.2.2 End-entity device certificates need not be published to the PKD as they will be passed in-band during the IPsec session negotiation.

2.2.3 Where possible PKI related documentation will be generally available to the PSN community on the PSN web site.

2.2.4 CPSs will not be made publicly available.

2.3 Time or frequency of publication

2.3.1 Root CA certificates shall be published by PSNA on issuance to the PSN PKD.

2.3.2 Sub-CA Certificates shall be published by each Sub-CA on issuance to its Sub-CA PKD.

2.3.3 CRLs shall be published by the relevant CA in accordance with section 4.9.7, even if there is no change to the certificate status information. CRLs shall comply with RFC 5280, section 7 and Annex I and Annex J

2.3.4 Each CRL shall contain a full and complete listing of all unexpired certificates issued by the CA that have been revoked for any reason.

2.3.5 Relying Parties shall have read access to the PKD, and shall have read access to certificates used in transactions with them, including all certificates in the certification path up to the Root Certificate.

2.4 Access controls on repositories

2.4.1 The PSN is a closed community and the PKD shall only be available to the PSN community.

2.4.2 Repository providers shall ensure that sufficient controls, detailed in the Risk Management and Accreditation Document Set (RMADS) for each repository, are in place to ensure that write/modify/delete access to elements of the

UNCLASSIFIED



of 99



UNCLASSIFIED

repositories shall only be available to authorised entities entitled to publish information to that repository.

UNCLASSIFIED



of 99



UNCLASSIFIED

3. Identification and Authentication

3.1 Naming

3.1.1 Types of names

3.1.1.1 Each certificate issued under these Policies must have a non-null X.501

Distinguished Name in the Certificate Subject Name field, in accordance with

IETF RFC5280, reference [5] An alternative name may be used in addition,

using the ”subjectAltName” field, also in accordance with IETF RFC 5280

and section 7.1.2.7.

3.1.2 Need for names to be meaningful

3.1.2.1 Certificate Subject Names shall identify the organisation and device to which

the certificate is issued. For End-entity Certificates this means the relevant

organisation, model and serial/asset number of the device, potentially with

additional information in order to be unique.

3.1.2.2 Each certificate shall have an X.501 Distinguished Name which uniquely and

unambiguously identifies the device, in accordance with the format defined in

reference [16].

3.1.2.3 Each certificate shall be assigned to an individual responsible for the device.

3.1.2.4 The name of the individual responsible for the certificate shall be recorded

and maintained in a separate register held by the Sub-CA or the RA.

3.1.3 Anonymity or pseudo-anonymity of subscribers

3.1.3.1 PSN PKI Certificates shall not be anonymous.

3.1.3.2 Pseudo-anonymous certificates shall not be allowed.

3.1.3.3 All certificates shall be traceable to the responsible individual.

3.1.4 Rules for interpreting various name forms

3.1.4.1 Names shall be defined in accordance with the RFC5280.

3.1.4.2 Names shall be defined in accordance with reference [16] and shall be

genuine, unique and unambiguous.

3.1.4.3 Rules for interpreting name forms are contained in the applicable certificate

profile details in section 7 and Annex E - Annex L.

3.1.5 Uniqueness of names

3.1.5.1 All Distinguished Names shall be unique across the PSN PKI for all time.

UNCLASSIFIED



of 99



UNCLASSIFIED

3.1.5.2 The PSN naming format will prevent collisions in the Sub-CA namespace

immediately below the root by allocating enough name space to make these

Sub-CA‟s unique and its then down to these Sub-CA‟s to handle their own

namespace.

3.1.5.3 All Sub-CAs and RAs shall only issue names from within the X.500 name

space for which they have been authorised.

3.1.5.4 All Sub-CAs and RAs shall enforce uniqueness within the X.500 name space

from which they have been authorised to issue names.

3.1.5.5 The Sub-CAs shall investigate and correct if necessary any name collisions

brought to its attention, relating to certificates issued by that Sub-CA. If

appropriate, the Sub-CA shall coordinate with and defer to the appropriate

naming authority (PSNA).

3.1.5.6 Each Sub-CA shall have and follow a name claim dispute resolution

procedure with providers of repository services, if external to the Sub-CA.

3.1.5.7 If a Sub-CA is not able to correct a name collision brought to its attention, it

shall be referred to the PSNA.

3.1.6 Recognition, authentication and role of trademarks

3.1.6.1 If a person claims that a certificate contains a registered trademark for which

they are the registered proprietor, and the issuing Sub-CA is reasonably

satisfied that the proper use of the certificate would infringe that registered

trade mark, the Sub-CA shall immediately suspend or revoke the certificate.

3.1.6.2 There is no obligation for the Root CA, Sub-CA or RA to investigate whether

a certificate application contains a registered trademark. However, a

certificate should not be issued where it is reasonable to suspect that the

proper use of the certificate is likely to infringe a registered trademark.

3.2 Initial identity validation

3.2.1 Method to prove possession of Private Key

3.2.1.1 Subscribers must prove to the Sub-CA or RA, as part of the registration

process, possession of the Private Key corresponding to the Public Key

contained in the certificate request.

3.2.1.2 Proof of possession of the Private Key shall be achieved by signing the

certificate request using a recognized standard protocol, as determined by

the PSNA. The PSNA shall maintain a list of approved methods for

achieving this.

UNCLASSIFIED



of 99



UNCLASSIFIED

3.2.2 Authentication of organisation identity

3.2.2.1 Each entity in an organisation will require a unique identifier. There will be an

Organisation Identifier (OrgID) which uniquely identifies the connecting

organisation. The requestor (person) shall be verified to Level 3 (Verified) in

the CESG GPG43 RSDOPS framework, reference [6].

3.2.3 Authentication of individual identity

3.2.3.1 Certificates shall only be issued to Sub-CAs and End-entities which fall

under the authority of a formally appointed Crypto Custodian, in accordance

with HMG‟s policy on managing cryptographic devices. The identity of the

Crypto Custodian shall be verified to Level 3 (Verified) in the CESG GPG43

RSDOPS framework, reference [6].

3.2.3.2 End-entity devices shall be formally assured in accordance with:

a. PEPAS for IL3 devices; or

b. CAPS for IL3 devices

3.2.3.3 Authentication of the identity of a device shall be verified using appropriate

documentation, such as an invoice, warranty, contract, maintenance

schedule or information marked on the device itself. The registration process

shall ensure that:

a. certificates are only issued to genuine devices;

b. certificates are only issued to End-entity Subjects that have been

assured under the PEPAS or CAPS assurance schemes;

c. documented management procedures are in place to manage the

private key material;

d. a Crypto Custodian has been formally assigned for the certificate;

and

e. the registration process shall ensure that the device has been

assured and authorised for the processing of RESTRICTED

information.

3.2.3.4 The Sub-CA or RA shall verify that the End-entity Subject for which the

certificate is to be issued matches the identity information provided by the

Crypto Custodian.

3.2.4 Non-verified subscriber information

3.2.4.1 All End-entity Subscriber supplied information shall be verified as specified in

sections 3.2.2 and 3.2.3.

3.2.5 Validation of authority

UNCLASSIFIED



of 99



UNCLASSIFIED

3.2.5.1 When processing the application for a Sub-CA certificate, the Root Authority

shall verify that the Applicant is an Eligible Certificate Authority as defined in

Section 1.3.1 and has the authority to make a certificate request.

3.2.5.2 When processing the application for an RA certificate, the issuing Sub-CA

shall verify that the Applicant is an Eligible Registration Authority as defined

in Section 1.3.2 and the authority to make a certificate request

3.2.5.3 An application for a Sub-CA or RA certificate shall be accompanied by at

least two written signatures from an appropriately individual registered with

PSNA and defined as part of the compliance process.

3.2.5.4 When processing the application for an End-entity Subject certificate, the

issuing Sub-CA shall verify that the Applicant is an Eligible Subscriber as

defined in Section 1.3.3.

3.2.5.5 An application for an End-entity Subject certificate shall be authorised by the

nominated device custodian.

3.2.5.6 An RA shall validate that a registration operator has the authority to make a

certificate request.

3.2.6 Criteria for interoperation

3.2.6.1 Cross certification between Certificate Authorities external to the PSN PKI is

not currently allowed under this Certificate Policy.

3.3 Identification and authentication for re-key requests

3.3.1 Identification and authentication for routine re-key

3.3.1.1 A request for re-key of an End-entity Subject may only be made by the

Crypto Custodian of the device, with whom the responsibility for the

certificate resides.

3.3.1.2 A request for re-key for certificates issued to Sub-CAs and RAs should be

accompanied by a written signature from an appropriately authorised

individual defined as part of the compliance process.

3.3.1.3 All requests for re-key must be authenticated by the relevant CA, and the

subsequent response must be authenticated by the Subject. This may be

done with a standard protocol such as PKCS#10, as determined by the

PSNA.

3.3.1.4 If the Private Key has expired or has been compromised a routine re-key is

not allowed, a new certificate request must be submitted.

UNCLASSIFIED



of 99



UNCLASSIFIED

3.3.1.5 Procedures for re-key are contained in Section 4.7.

3.3.2 Identification and authentication for re-key after revocation

3.3.2.1 Where the information contained in a certificate has changed the request for

re-key must be authenticated in the same manner as for initial registration.

Any change in the information contained in a certificate must be verified by

the relevant CA, or the RA authorised to act on behalf of that CA, before that

certificate is issued.

3.3.2.2 Where a known or suspected compromise of the Private Key has resulted in

a revocation a re-key is not allowed, a new certificate request must be

submitted.

3.4 Identification and authentication for revocation request

3.4.1.1 The list of entities that can request revocation is described in Section 4.9.2.

Validation of a request for the revocation of a certificate shall be achieved by

verifying the digital signature, or written signatures, associated with the

request.

3.4.1.2 When the requester of revocation is the Subscriber, other methods may be

used to validate requests, such as communication with the Subscriber

providing reasonable assurances that the person or organisation requesting

revocation is, in fact, the Subscriber. A Sub-CA must establish and make

publicly available the process by which it addresses such revocation

requests and the means by which it will establish the validity of the request.

3.4.1.3 Requests to revoke a certificate may be validated using that certificate‟s

associated public key, regardless of whether or not the Private Key has been

compromised.

3.4.1.4 Requests for the revocation of a Sub-CA certificate must be accompanied by

two written signatures from appropriately authorised personnel.

3.4.1.5 Requests for revocation of certificates shall be logged, as described in

Section 5.4.

UNCLASSIFIED



of 99



UNCLASSIFIED

4. Certificate lifecycle operational requirements

4.1 Certificate application

4.1.1 Who can submit a certificate application

4.1.1.1 Certificate Requests must be submitted by the Subscriber.

4.1.1.2 The following types of certificate can be applied for according to this

Certificate Policy:

a. CA certificates;

b. RA certificates;

c. End-entity certificates;

4.1.1.3 All the above certificates relate to organisational systems or devices not

individuals.

4.1.1.4 When the Subscriber is an RA the certificate request must be submitted to

the Sub-CA that the RA is intending to support.

4.1.2 Enrolment process and responsibilities

4.1.2.1 All Sub-CA, RA and End-entity certificate Applicants shall undergo a

registration process which, prior to certificate issuance, shall:

a. establish and prove the identity of the Subscriber, and establish the

validity of the subject according to the registration procedures

described in Section 3.2;

b. require proof of authorisation to have a certificate, as defined in

Section 3.2.5;

c. require the Subscriber to attest to the accuracy of information

submitted in certificate requests;

d. require the Subscriber to read, understand and sign the Subscriber

Agreement;

e. submit a signed certificate request to the CA using a recognised

standard protocol (e.g. PKCS#10), as approved by the PSNA; and

f. require the Subject, where they have generated the key pair

themselves, to prove possession of the Private Key corresponding

to the public key contained in the certificate request, as described in

Section 3.2.

4.1.2.2 Where the Applicant is a Sub-CA the elements 4.1.2.1 a - e above apply, but

the request can take the form of a procedural request for the generation of a

Sub-CA key pair and the issuing of a signed public key certificate.

4.1.2.3 All procedures for certificate application shall be documented in the CPS.

UNCLASSIFIED



of 99



UNCLASSIFIED

4.1.2.4 All requests for End-entity certificates to a Sub-CA shall be accompanied by

a digitally signed authorisation from an RA. The RA shall authenticate the

identity of the Applicant and the entitlement of the Applicant to be issued a

certificate.

4.1.2.5 For any certificates issued to support the operation of the Sub-CA (e.g. to

authenticate the actions of an Operator of the Sub-CA), the Sub-CA must

verify the identity of the Applicant in the same way as an RA, as described in

Section 3.2.

4.1.3 CA cross-certificate

4.1.3.1 CA cross-certification is not currently allowed under this Certificate Policy.

4.2 Certificate application processing

4.2.1 Performing identification and authentication functions

4.2.1.1 The Sub-CA shall verify the signature of the RA and shall check the RA

signature of the certificate request against a known list of authorised RAs.

4.2.1.2 The RA shall authenticate the identity of the Applicant and the entitlement of

the Applicant to be issued a certificate, in accordance with Section 3.2.

4.2.2 Approval or rejection of certificate applications

4.2.2.1 An application for a certificate does not oblige the CA to issue a certificate.

The CA or RA may decline an application under this Certificate Policy at its

absolute discretion.

4.2.2.2 An RA shall verify the content of each certificate request to ensure that it is

correctly formed and completed as defined in Appendix C. Incorrect

certificate requests shall be rejected and the Applicant requested to re-

submit with corrected information.

4.2.2.3 The issuance and publication of a certificate by a CA indicates that the CA

has approved the certificate application, following the approval policy

specified in this Certificate Policy.

4.2.3 Time to process certificate applications

4.2.3.1 Time limits for certificate processing will be governed by the commercial

relationships between organisations. There is no stipulation for the time limit

to process applications for certificates under this Certificate Policy.

4.3 Certificate issuance

4.3.1 CA actions during certificate issuance

UNCLASSIFIED



of 99



UNCLASSIFIED

4.3.1.1 The Sub-CA shall verify the RA signature in accordance with Section 3.2 and

shall check the RA signature of the certificate request against a known list of

authorised RAs.

4.3.1.2 A CA shall verify the content of each certificate request to ensure that it is

correctly formed and completed.

4.3.1.3 Issued CA certificates shall be published to the PKD, as described in Section

2.

4.3.2 Notification to subscriber by the CA of issuance of certificate

4.3.2.1 The CA is responsible for notifying the RA that a certificate has been

created, and will either provide the certificate directly or will place it in the

certificate repository, as defined in Section 2.1. Notification is to be given

from the CA to the RA immediately following the creation and publication of

the certificate.

4.3.2.2 The RA is responsible for notifying the Subscriber that the certificate has

been created, and will either provide the certificate directly or inform the

Subscriber of a location the certificate can be obtained.

4.3.2.3 Certificates for devices shall be issued to the Crypto Custodian using secure

electronic transfer or removable media, in accordance with Section 6.

4.3.2.4 The PSNA, Sub-CAs and RAs must ensure that delivery of the Root

Certificate to Subscribers is achieved in a secure way, as detailed in Section

6.1.4.

4.4 Certificate acceptance

4.4.1 Conduct constituting certificate acceptance

4.4.1.1 The Applicant will be deemed to have accepted the issued certificate when

either of the following conditions is met:

a. the subject has not notified the RA or CA regarding rejection of the

certificate within 24 working hours of receipt of the certificate or

b. the subject uses the certificate for the first time.

4.4.1.2 In using the certificate the Applicant automatically accepts all Relying Party

and Subscriber Agreements that exist in relation to the use of the certificate.

4.4.2 Publication of the certificate by the CA;

4.4.2.1 The issued certificate shall be published to the PKD, as described in Section

2.2.

UNCLASSIFIED



of 99



UNCLASSIFIED

4.4.3 Notification of certificate issuance by the CA to other entities

4.4.3.1 The CA shall inform the RA immediately that the certificate has been

created. The newly created certificate shall be sent to the RA and/or placed

in the PKD as defined in Section 2.2.

4.4.3.2 The Sub-CA may inform any other entity that the certificate has been

created, as determined by the Sub-CA.

4.5 Key pair and certificate usage

4.5.1 Subscriber private key and certificate usage

4.5.1.1 Prior to applying for or being issued with a certificate by a CA, a Subscriber

shall read and sign a Subscriber Agreement by which they agree to be

bound by the terms of this Certificate Policy.

4.5.1.2 The Subscriber Agreement shall clearly state that the Subscriber shall:

a. provide accurate information at registration and at all subsequent

communications with any member of the PSN PKI;

b. ensure that key pair generation, if not performed at CA or RA

premises, is performed in an approved environment as defined

within the relevant CPS and in accordance with Section 6.1;

c. prove possession of the Private Key in accordance with the

Registration procedure, as defined in Section 3.2.1;

d. protect the Private Key at all times, in accordance with this policy;

e. ensure that the Private Key is only accessible by the Subject of the

certificate, that the Private Key remains under control of the Crypto

Custodian(s) of the Subject of the certificate at all times, and that no

entity other than the device and Crypto Custodian(s) has access to

the Private Key at any time;

f. ensure that the Crypto Custodian(s) of the Subject certificate does

not disclose the Activation Data protecting the Private Key (as

defined in Section 6.4) to any unauthorised person at any time;

g. ensure that certificates are used in accordance with this Certificate

Policy at all times;

h. notify the RA in the event of any change to, or inaccuracy in,

information given at registration time;

i. notify either the CA or RA in the event of suspected compromise of

the Private Key or the Activation Data protecting the Private Key;

j. ensure that the certificate is not used by the Subject after it has

expired or been revoked;

UNCLASSIFIED



of 99



UNCLASSIFIED

k. not tamper with, or attempt to reverse engineer, any aspect of the

technical implementation of the PSN PKI;

l. not apply (whether to a CA or to any other person whatsoever) for

any other certificate using the same key pair that has been

generated in the registration for a certificate under this policy; and

m. agree to the terms in the Relying Party Agreement in force at the

time the Relying Party relies on the certificate.

4.5.1.3 End-entity Subscriber Agreements shall clearly state that the Subscriber

shall not attempt to duplicate or backup the Private Key.

4.5.1.4 Guidance shall be given by the CA to Subscribers, through the Subscriber

Agreement or otherwise, regarding the mechanisms by which they shall

adhere to their obligations.

4.5.1.5 A Subscriber is responsible and liable for the acts and omissions of its

officers, directors, employees, agents and contractors in connection with any

application for a certificate or key, and their use, storage, security and

destruction, as if those acts and omissions were the Subscriber‟s.

4.5.1.6 If an authorised entity reasonably suspects a Subscriber of having acted in a

manner inconsistent with these obligations, an authorised entity may request

revocation of the Subscriber‟s certificate(s), as described in Section 4.9.

Authorised entities who may request revocation are listed in Section 4.9.2.

4.5.1.7 The use of a private key is permitted only after the Subscriber has accepted

the corresponding certificate.

4.5.1.8 The Subscriber shall discontinue use of the private key following the

revocation of the certificate.

4.5.1.9 Private keys shall be used with appropriately evaluated products, as

approved by the PSNA and detailed in reference [2].

4.5.2 Relying party public key and certificate usage

4.5.2.1 Relying Parties shall use the PSN PKI, and rely on a certificate that has

been issued under this Certificate Policy if (and only if):

a. the certificate has been used for the purpose for which it has been

issued, as described in this Certificate Policy;

b. the Relying Party has verified the validity of the digital certificate,

using procedures described in the X.509 standard, including

checking the revocation status of the certificate either through an

UNCLASSIFIED



of 99



UNCLASSIFIED

online certificate status checking protocol or by accessing the

relevant CRLs from the PKD;

c. the Relying Party has established trust in the certificate by verifying

the certificate path to a trust point, in accordance with the guidelines

set by the X.509 standard and as stated in Section 4.9;

d. the Relying Party has accepted and agreed to the Relying Party

Agreement at the time of relying on the certificate; it shall be

deemed to have done so by relying on the certificate.

4.5.2.2 Guidance shall be given by the Sub-CA to Relying Parties, through the

Relying Party Agreement or otherwise, regarding the mechanisms by which

they shall adhere to their obligations.

4.6 Certificate renewal

4.6.1 Circumstance for certificate renewal

4.6.1.1 The PSN PKI does not allow certificate renewal (the issuance of a new

certificate using existing key pairs).

4.6.2 Who may request renewal

4.6.2.1 No stipulation within this Certificate Policy.

4.6.3 Processing certificate renewal requests


4.6.4 Notification of new certificate issuance to subscriber


4.6.5 Conduct constituting acceptance of a renewal certificate


4.6.6 Publication of the renewal certificate by the CA




4.7 Certificate re-key

4.7.1 Circumstance for certificate re-key

4.7.1.1 A routine re-key may take place before a certificate has expired where an

identical certificate (apart from, for example, expiry date, key pair, Subject

Key Identifier, Serial Number) is required. The Subscriber should re-key in

accordance with this Section 4.7.

UNCLASSIFIED



of 99



UNCLASSIFIED

4.7.1.2 A Subscriber may alternatively re-key a certificate by applying for a new

certificate in accordance with Section 4.1.

4.7.1.3 The circumstances in which routine re-key shall not take place are as

follows:

a. after a certificate has expired, the Subscriber should apply for a

new certificate in accordance with Section 4.1; and

b. after a certificate has been revoked, the Subscriber should apply for

a new certificate in accordance with Section 4.1.

4.7.2 Who may request certification of a new public key

4.7.2.1 Re-key requests shall be made by the Subject in whose name the certificate

has been issued, or by the Crypto Custodian of a server, system or device

certificate.

4.7.2.2 Certificates may be renewed through consecutive on-line re-keys.

4.7.3 Processing certificate re-keying requests

4.7.3.1 A Subject shall submit a request for re-key to the RA or CA from which the

certificate was originally issued. The request may either be submitted on-

line or in person and shall be accompanied by the reason for the re-key

(typically routine re-key before expiry)

4.7.3.2 Identification and authentication requirements for routine re-key are outlined

in Section 3.3.1.

4.7.3.3 Identification and authentication requirements for re-key after revocation are

outlined in Section 3.3.2.

4.7.3.4 Before issuing the re-keyed certificate, the RA or CA shall:

a. verify the validity of the signature in the re-key request;

b. verify the validity of the reason for the re-key; and

c. establish whether the information contained within the requested re-

keyed certificate is identical to that contained within the original

certificate.

4.7.3.5 After a successful re-key, the RA or CA shall inform the Crypto Custodian via

a separate channel that the re-key has been undertaken.


4.7.4.1 Notification of the new certificate to the Subscriber shall be conducted in the

same manner as for the original certificate issuance, as described in Section

4.3.2.

UNCLASSIFIED



of 99



UNCLASSIFIED

4.7.5 Conduct constituting acceptance of a re-keyed certificate

4.7.5.1 Conduct constituting acceptance of a re-keyed certificate is the same as for

the original certificate issuance, as described in Section 4.4.1.

4.7.6 Publication of the re-keyed certificate by the CA

4.7.6.1 Publication requirements for the re-keyed certificate by the CA are the same

as for the original certificate issuance, as described in Section 4.4.2.


4.7.7.1 Notification of the new certificate to other entities shall be conducted in the

same manner as for the original certificate issuance, as described in Section

4.4.3.

4.8 Certificate modification

4.8.1 Circumstance for certificate modification

4.8.1.1 The PSN PKI does not allow certificate modification (re-issuance of a

modified certificate using existing key pairs). If a certificate requires

modification, the Subscriber should re-key in accordance with Section 4.7.

4.8.2 Who may request certificate modification


4.8.3 Processing certificate modification requests




4.8.5 Conduct constituting acceptance of modified certificate


4.8.6 Publication of the modified certificate by the CA




4.9 Certificate revocation and suspension

4.9.1 Circumstances for revocation

UNCLASSIFIED



of 99



UNCLASSIFIED

4.9.1.1 If a certificate has been compromised, is reasonably suspected to be

compromised, or potentially compromised, the certificate shall be

immediately revoked.

4.9.1.2 A certificate shall be revoked when the binding between the subject and the

subject‟s public key defined within a certificate is no longer considered valid

by one of the entities listed in Section 4.9.2.

4.9.1.3 Circumstances that invalidate the binding are :

a. known compromise of the Private Key due to theft, loss, disclosure,

modification or other compromise;

b. any misuse of keys and certificates;

c. known compromise of the media holding the Private Key;

d. information contained in the certificate changes;

e. a change in role such that the certificate is no longer valid or

authorised;

f. the determination by the CA or RA that the certificate was not

properly issued in accordance with the Certificate Policy;

g. it becomes apparent that any of the information submitted during

registration is false;

h. the device to which an end-entity certificate relates is taken out of

service, sent for repair or disposed of;

i. a merger or a takeover of the Sub-CA, RA or Subscriber.

4.9.1.4 A certificate shall be revoked when any of the following conditions are true:

a. a properly formatted request for revocation is received from an

authorised party (as described in Section 4.9.2);

b. the registered proprietor of a registered trademark claims that a

certificate infringes that trademark and this claim is upheld.

4.9.1.5 A Sub-CA can revoke an RA or End-entity certificate, at its discretion, if:

a. the Subscriber fails to abide by the Subscriber Agreement or does

not comply with this Certificate Policy; or

b. the Subscriber or Subject undergoes a change in role such that the

certificate is no longer required.

4.9.1.6 The PSNA may revoke any Certificate at its discretion if the Sub-CA, RA or

Subscriber does not comply with this Certificate Policy.

4.9.2 Who can request revocation

4.9.2.1 The following entities are authorised to request revocation:

UNCLASSIFIED



of 99



UNCLASSIFIED

a. the Subscriber of the certificate (or Crypto Custodian in the case of

a device certificate);

b. RA personnel who have been previously authorised by the Sub-CA

to revoke certificates, for certificates that have been issued by that

RA;

c. Sub-CA personnel who have been previously authorised by the

Sub-CA to revoke certificates, for certificates that have been issued

by that Sub-CA; and

d. the PSNA Security Manager or Operations Director for any

certificate.

4.9.3 Procedure for revocation request

4.9.3.1 Revocation requests must be authenticated, accountable to an individual

and auditable.

4.9.3.2 Each CA shall describe the procedure for revocation in the CPS, which shall

include:

a. an identification of the certificate to be revoked;

b. a clear statement of the reasons for revocation; and

c. the authentication of the requester of the revocation.

4.9.3.3 When revoking a certificate, checks shall be made to verify that the

certificate has not been used to re-key replacement certificates; if the

certificate has been used for certificate re-key after an actual or suspected

compromise, these additional certificates shall also be revoked.

4.9.3.4 Once a revocation request has been received and authenticated, the

certificate shall be revoked and the revocation shall be published in the

relevant CRL and made available to all Relying Parties. A CRL shall be

published, even if an on-line status checking mechanism is additionally used.

4.9.4 Revocation request grace period

4.9.4.1 There is no grace period for revocation under this policy; Subscribers shall

inform the Sub-CA or RA on suspected compromise, whether inside or

outside normal business hours (i.e. 24x7x365).

4.9.5 Time within which CA must process the revocation request

4.9.5.1 Sub-CAs shall revoke certificates immediately upon receipt of a proper

revocation request. If there is the potential that the certificate has been

compromised, revocation shall occur immediately, whether inside or outside

normal business hours (i.e. 24x7x365). Otherwise, the Sub-CA must

process the revocation request by the end of the next working day.

UNCLASSIFIED



of 99



UNCLASSIFIED

4.9.6 Revocation checking requirements for third parties

4.9.6.1 Relying parties must check revocation status of any certificates on which

they wish to rely, either through an on-line certificate status checking

protocol such as OCSP or by accessing the relevant CRLs from the

published source at the time of certificate validation.

4.9.6.2 Relying parties must check the authenticity and integrity of the certificate

status information by:

a. verifying that the CRL or certificate status message has been

digitally signed using the Private Key corresponding with the digital

certificate purported to have been used;

b. verifying the validity of the digital certificate, using procedures

described in the X.509 standard; and

c. establishing trust in the CA who issued a certificate by verifying the

certificate path in accordance with the guidelines set by the X.509

standard.

4.9.6.3 If necessary, and if practical, the Relying Party shall check the subsequent

CRL or certificate status message issued after the digital signature has been

created to verify the on-going validity of the certificate that has been used.

4.9.6.4 If a CRL or certificate status service is temporarily unavailable, a certificate

has no status or value until the CRL or certificate status service becomes

available once more and hence the Relying Party must reject the certificate,

unless it has been explicitly authorised by the PSNA to accept the certificate.

4.9.7 CRL issuance frequency

4.9.7.1 The frequency of issuance for the CRL that relates to Sub-CA certificates

(ARL) by the Root CA shall be monthly.

4.9.7.2 The frequency of issuance for the CRL that relates to End-entities

certificates by the Sub-CA shall be every 24hrs with the next update or

validity period set to 48hrs.

4.9.7.3 CRLs shall be issued, even if there is no change to the certificate status

information.

4.9.7.4 Following receipt of an authorised and authenticated End-entity revocation

request for a certificate where there is the potential that the private key has

been compromised, the certificate shall be revoked and an updated CRL

issued within one hour. This shall occur whether inside or outside business

hours (i.e. 24x7x365). Where there is no potential that the private key has

UNCLASSIFIED



of 99



UNCLASSIFIED

been compromised, the Sub-CA must issue the updated CRL in accordance

with paragraph 4.9.7.2.

4.9.7.5 If a revoked certificate expires, it may be removed from subsequent versions

of the CRL.

4.9.7.6 Sub-CAs shall make CRLs accessible to Relying Parties whether inside or

outside normal business hours (i.e. 24x7x365). The required availability

level is 99.95%.

4.9.8 Maximum latency for CRLs

4.9.8.1 In the case of scheduled issuance of a CRL by a Sub-CA that relates to End-

entity certificates, the CRL shall be issued a minimum of four hours before

the previous CRL expires to ensure continuity of service.

4.9.8.2 In the case of scheduled issuance of a CRL that relates to Sub-CA

certificates, the CRL shall be issued a minimum of three days before the

previous CRL expires to ensure continuity of service.

4.9.8.3 The maximum latency between the creation and publication of a CRL that

contains revocation information relating to End-entity certificates is one hour.

4.9.8.4 The maximum latency between the creation and publication of a CRL that

only contains revocation information relating to Sub-CA certificates is four

hours.

4.9.9 On-line revocation/status checking availability

4.9.9.1 Sub-CAs may support on-line status checking in addition to (but not in place

of) the publication of CRLs.

4.9.9.2 Relying Party client software may support on-line status checking in addition

to CRL checking.

4.9.9.3 On-line status checking, if provided, shall be available whether inside or

outside normal business hours (i.e. 24x7x365). The required availability

level is 99.95%.

4.9.10 On-line revocation checking requirements

4.9.10.1 An on-line status checking service must perform the same level of checks

as to the status of the certificate as that which would be achieved by

checking the published CRL and the same conditions apply.

4.9.10.2 The requirements for checking by Relying Parties are the same, whether

the Relying Party uses CRLs or on-line revocation checking services

UNCLASSIFIED



of 99



UNCLASSIFIED

4.9.11 Other forms of revocation advertisements available

4.9.11.1 Another revocation advertisement service must perform the same level of

checks as to the status of the certificate as that which would be achieved by

checking the published CRL and the same conditions apply.

4.9.11.2 Other forms of revocation advertisements may be used provided the

following requirements are met:

a. the procedures shall be fully described in the CPS;

b. the method shall provide authentication and integrity services to the

same level as provided by the CRL or on-line status checking

approach; and

c. the same time constraints apply as for the CRL or on-line status

checking approach.

4.9.12 Special requirements re key compromise

4.9.12.1 A Subscriber shall inform the issuing RA or CA immediately, whether

inside or outside normal business hours, if there are reasonable grounds to

suspect that the confidentiality of the Private Key has been compromised.

4.9.12.2 If a CA key is compromised, or is suspected of compromise, the CA must

immediately notify all parties to which it has issued certificates.

4.9.12.3 A CA must ensure that its CPS contains provisions outlining the means it

will use to provide notice of compromise or suspected compromise.

4.9.13 Circumstances for suspension

4.9.13.1 Suspension is not allowed under this Certificate Policy.

4.9.14 Who can request suspension


4.9.15 Procedure for suspension request


4.9.16 Limits on suspension period


4.10 Certificate status services

4.10.1 Operational characteristics


4.10.2 Service availability

UNCLASSIFIED



of 99



UNCLASSIFIED

4.10.2.1 The availability of certificate status information services shall be 99.95%.

4.10.2.2 If a CRL or certificate status service is temporarily unavailable, a certificate

has no status or value until the CRL or certificate status service becomes

available once more. The Relying Party must reject the certificate unless it

has been explicitly authorised by the PSNA to be able to make an informed

decision as to whether to accept or reject the certificate.

4.10.3 Optional features


4.11 End of subscription

4.11.1.1 If a Subscriber or Subject wishes to terminate subscription, for example on

termination of employment, a termination request should be submitted to the

RA or CA.

4.11.1.2 On termination of subscription, all certificates relating to that Subscriber or

Subject shall be revoked in accordance with Section 4.9.

4.11.1.3 Expired certificates shall be removed from the revocation service.

4.12 Key escrow and recovery

4.12.1 Key escrow and recovery policy and practices

4.12.1.1 This Certificate Policy does not allow key escrow (the storage of private

keys with a third party).

4.12.1.2 Key backup is defined in Section 6.2.4.

4.12.2 Session key encapsulation and recovery policy and practices

4.12.2.1 Not stipulation.

UNCLASSIFIED



of 99



UNCLASSIFIED

5. Facility, Management and Operational Controls All CAs shall be required to develop a Certification Practice Statement, defining the

mechanisms by which it implements the requirements of this Certificate Policy and

referencing the detailed operating procedures. The CPS will be reviewed as part of

the PSN compliance process for on-boarding a PKI service.

UNCLASSIFIED



of 99



UNCLASSIFIED

5.1 Physical controls

5.1.1 Site location and construction

5.1.1.1 All components of a CA or RA system, including backups shall be located in

a facility capable of housing RESTRICTED material, as defined in the HMG

Security Policy Framework (SPF) reference [8].

5.1.2 Physical access

5.1.2.1 CAs and RAs shall implement physical access control to limit access to the

systems to the minimum number of personnel required, as defined in the

SPF for RESTRICTED material.

5.1.3 Power and air conditioning

5.1.3.1 The CA shall be located in accommodation with appropriate power and air

conditioning systems.

5.1.4 Water exposures

5.1.4.1 The accommodation shall be protected from water ingress.

5.1.5 Fire prevention and protection

5.1.5.1 The accommodation shall have a fire protection system.

5.1.6 Media storage

5.1.6.1 All paper documents, magnetic, optical and solid state media containing CA

and RA information shall be uniquely identified, logged in a document

register and shall be stored in containers that conform to the requirements of

the SPF for RESTRICTED material. All CA and RA Private Key material

shall be stored in accordance with the requirements of the SPF for

RESTRICTED CRYPTO material.

5.1.7 Waste disposal

5.1.7.1 Paper documents and magnetic, optical, or solid state media containing

commercially sensitive or confidential information relating to the operation of

the PKI, shall be securely disposed of in accordance with the requirements

for RESTRICTED material in the SPF and Information Assurance Standard

Number 5.

5.1.7.2 All CA and RA Private Key material shall be disposed of in accordance with

the requirements of Information Assurance Standard Number 4 for

RESTRICTED CRYPTO material.

5.1.8 Off-site backup

UNCLASSIFIED



of 99



UNCLASSIFIED

5.1.8.1 The media backup cycle shall include a regular secure transfer of backup

media to an off-site location. The off-site storage shall:

a. be available to authorised personnel during the hours of operation

of the CA, for the purpose of retrieving software and data; and

b. have appropriate levels of security in place, equivalent to the main

CA sites.

5.1.8.2 Any transfer of media between sites shall be protected in accordance with

the requirements of the SPF for the handling of RESTRICTED information.

All CA and RA Private Key material shall be protected in accordance with the

requirements of the SPF for RESTRICTED CRYPTO material..

5.2 Procedural controls

5.2.1 Trusted roles

5.2.1.1 A CA must ensure a separation of duties, and where necessary use dual

control, for critical CA functions to prevent one person from maliciously using

the CA system without detection. Each user‟s system access is to be limited

to those actions for which they are required to perform in fulfilling their

responsibilities.

5.2.1.2 At a minimum, the following roles shall be established:

a. CA or RA System Administrator;

b. CA or RA Operator;

c. System Security Officer (SSO); and

d. System Auditor.

5.2.1.3 The CA or RA Administrator is responsible for system administration,

including configuration changes and management of user accounts.

5.2.1.4 The CA or RA Operator has responsibility for day to day operation of the

facility (e.g. generation of certificates, publication of CRLs, etc.).

5.2.1.5 The SSO has overall responsibility for system security, including the review

of audit logs and taking the appropriate corrective action. The SSO shall not

have operational access to the system, apart from the system logs.

5.2.1.6 The System Auditor has responsibility for auditing the operation of the CA or

RA, as described in Section 5.4 of this Certificate Policy. The System

Auditor shall only be given supervised access for audit purposes and should

not have administration access to the system.

5.2.2 Number of persons required per task

UNCLASSIFIED



of 99



UNCLASSIFIED

5.2.2.1 A CA must ensure a separation of duties for critical CA functions to prevent

one person from maliciously using the CA system without detection. At a

minimum, four individuals will be required in order to fulfil the following roles:

a. System Administration (e.g. System Administrator role);

b. Operations (e.g. Backup Operator, CA Operator and RA Operator

roles);

c. Security (e.g. System Security Officer role); and

d. Auditing (e.g. System Auditor role).

5.2.2.2 Unless otherwise authorised by the PSNA, each CA and RA must ensure

that no single individual may gain direct access to CA Private Keys. Two

individuals, using a split-knowledge technique such as twin passwords, are

required for the following processes:

a. CA system start-up;

b. CA system shutdown;

c. key backup;

d. key recovery;

e. revocation of CA and RA certificates.

5.2.2.3 In very restricted circumstances where other physical and personnel controls

are in place, the PSNA may authorise a CA to enable a single individual to

gain access to CA Private Keys.

5.2.3 Identification and authentication for each role

5.2.3.1 Authentication of system administrators shall comply with Information

Assurance Standard Number 7.

5.2.3.2 All CA and RA personnel must have their identity and authorisation verified

to Level 3 (Verified) in the CESG GPG43 RSDOPS framework, reference [6]

before they are:

a. included in the access list for the CA site;

b. included in the access list for physical access to the CA system;

c. given a certificate for the performance of their CA role; and

d. given an account on the PKI system.

5.2.3.3 Each of these accounts must:

a. be directly attributable to an individual;

b. not be shared; and

c. be restricted to actions authorised for that role through the use of

CA software, operating system and procedural controls.

UNCLASSIFIED



of 99



UNCLASSIFIED

5.2.4 Roles requiring separation of duties

5.2.4.1 Separate individuals shall fill each of the four roles: System Administrator,

Operator, System Auditor and SSO. Each individual shall be fully

accountable for the operation of the role.

5.3 Personnel controls

5.3.1 Qualifications, experience and clearance requirements

5.3.1.1 All CA and RA personnel shall have suitable qualifications and experience,

and shall have, as a minimum, a Security Check (SC) clearance. Where

personnel have direct access to an unprotected Private Key of the certificate

or can generate key pairs they shall be inducted as a Crypto Custodian.

5.3.1.2 All employees of Subscriber organisations who act as a Crypto Custodian or

have direct access to an unprotected Private Key of the certificate shall

have, as a minimum, a SC clearance.

5.3.2 Background check procedures

5.3.2.1 Checks appropriate to the clearance levels defined in Section 5.3.1 shall be

carried out in accordance with the HMG Security Policy Framework,

reference [8].

5.3.3 Training requirements

5.3.3.1 Appropriate training shall be provided for all CA and RA personnel, and a

training plan shall be produced.

5.3.3.2 Training shall cover the following aspects:

a. PKI concepts;

b. an explanation of the risks associated with the PKI;

c. the use and operation of the CA or RA software;

d. documented CA or RA procedures;

e. computer security awareness and procedures;

f. the use of smart cards (if used for authentication purposes);

g. how to explain to Subscribers the responsibilities adhering to the

possession, use and operation of their key pairs (for RA staff); and

h. the meaning and effect of this Certificate Policy and the relevant

CPS.

5.3.4 Retraining frequency and requirements

5.3.4.1 Any significant change in CA or RA operation shall have a training plan. The

execution of the training plan shall be documented.

UNCLASSIFIED



of 99



UNCLASSIFIED

5.3.5 Job rotation frequency and sequence

5.3.5.1 Job rotation frequency and sequence shall be described in the CPS.

5.3.6 Sanctions for unauthorised actions

5.3.6.1 Appropriate disciplinary actions shall be undertaken if this policy is violated,

including the unauthorised use of authority, or the unauthorised use of PKI

systems or certificates. This will include any breach of the Acceptable Use

Policy or Security Operating Procedures.

5.3.6.2 Disciplinary actions may include actions under the Official Secrets Act,

Computer Misuse Act and Data Protection Act.

5.3.7 Independent contractor requirements

5.3.7.1 Requirements for contractors and other non-PSN staff are the same as for

PSN staff, as specified in Sections 5.3.1 through 5.3.8.

5.3.7.2 Any PKI service providers who provide services to PSN bodies shall

establish procedures to ensure that any subcontractors perform in

accordance with this CP and the relevant CPS.

5.3.8 Documentation supplied to personnel

5.3.8.1 All CA and RA personnel, and End-entity Subscriber personnel with access

to certificates, must be provided with an Acceptable Use Policy and Security

Operating Procedures, to which they must sign to confirm understanding and

agreement for compliance. These documents should be available for audit.

5.3.8.2 Personnel must be supplied with sufficient documentation and training in

order to perform their job responsibilities competently and satisfactorily.

5.3.8.3 All personnel involved in registration, revocation or certificate signing

activities shall be provided with comprehensive user manuals detailing the

procedures for registration and revocation of Subscribers, and the creation

and signing of certificates.

5.4 Audit logging procedures

5.4.1 Types of event recorded

5.4.1.1 Events pertaining to the use of CA and RA equipment shall be recorded in

an audit log. The list of events to be recorded shall include all operations by

privileged users, any access to the Private Key, critical operations by CA/RA

operators, errors and failures, publication of a CRL and all communications

received and sent; the full list shall be identified in the CPS.

UNCLASSIFIED



of 99



UNCLASSIFIED

5.4.1.2 The audit logs of Sub-CA and RA systems shall be reviewed daily for any

anomalies and these anomalies investigated. The audit logs of the Root CA

system shall be reviewed whenever activated for any anomalies and these

anomalies investigated.

5.4.1.3 Care shall be taken to ensure compliance with the Data Protection Act and,

in particular, ensure that sensitive personal data is not recorded in the audit

logs where it may be unintentionally exposed.

5.4.1.4 As a minimum, the following events shall be recorded in the audit logs1:

a. any logon or logoff attempts by CA or RA operators;

b. any password changes;

c. failed logon attempts;

d. messages received from any source requesting CA or RA action

(e.g. certificate requests, certificate revocation requests, etc.);

e. actions taken in response to requests;

f. physical access to, loading, zeroizing, transferring keys to or from,

backing up, acquiring or destroying cryptographic modules;

g. key ceremony activities and evidence;

h. receipt, servicing (e.g. keying or other cryptologic manipulations),

and shipping hardware cryptographic modules;

i. publishing of, removal of, or modification to any material to a

repository;

j. anomalies, error conditions, software integrity check failures, receipt

of improper or misrouted messages;

k. any known or suspected violations of physical security, suspected

or known attempts to attach the CA or RA equipment;

l. server installation, access or modification;

m. system start-up and shutdown;

n. CA or RA application start-up and shutdown;

o. CA equipment access (e.g. room access);

p. file manipulation and account management, including personnel

changes;

q. any use of the CA signing key;

r. documentation supporting certificate applications

s. revocation requests; and

t. checks made during the registration process.

1 The term ‘audit log’ as used in this document refers to the data that is collected in preparation for an

audit, rather than the log of the audit process itself. This use of terminology is compatible with RFC3647 and

BS ISO/IEC 17799. This data is sometimes referred to as ‘accounting logs’.

UNCLASSIFIED



of 99



UNCLASSIFIED

5.4.1.5 For each event, the following information shall be recorded:

a. type of event;

b. date and time of the event;

c. message source, destination and contents, where relevant;

d. success or failure indication, where relevant; and

e. the identity of the entity that caused the event.

5.4.1.6 Private Keys shall not under any circumstances be recorded in the audit log.

5.4.1.7 Each CA and RA shall enable any accounting or audit capability of the

underlying operating system on which software relating to this PKI operates.

5.4.1.8 Protective monitoring shall follow CESG Good Practice Guide Number 13

where applicable. Audit logging shall comply with BS10008:2008 “Code of

Practice for Legal Admissibility and Evidential Weight of Information Stored

Electronically”. Access to the audit log shall be read-only, and shall be

limited to the System Security Officer role only.

5.4.2 Frequency of processing log

5.4.2.1 For Sub-CAs, the audit log shall be reviewed daily as a minimum, and

immediately if there is any suspicion of compromise, in order to verify that:

a. the log has not been tampered with;

b. the logging is working correctly; and

c. no anomalies have been detected

5.4.2.2 For the PSN Root CA, the audit log shall be reviewed whenever activity has

taken place.

5.4.2.3 A more detailed study of each suspect entry shall be undertaken if any

anomalies are detected in the initial review, and any anomalies shall be

resolved.

5.4.2.4 All actions taken shall be documented.

5.4.3 Retention period for audit log

5.4.3.1 Each CA shall retain a copy of the audit log on-site for at least 12 months;

after this period the audit log shall be archived as described in Section 5.5.

Processes must be in place to ensure the audit log is able to be interrogated

for the full extent of the archived period.

5.4.4 Protection of audit log

5.4.4.1 Access to the audit log shall be read-only and shall be limited to the SSO

and, during an audit, the auditor. Protection mechanisms shall be put into

UNCLASSIFIED



of 99



UNCLASSIFIED

place to enforce this for the CA Software audit log and that the integrity of

the log is maintained for evidential purposes.

5.4.5 Audit log backup procedures

5.4.5.1 Audit logs should be written to two locations, at least one of which is not

accessible by any role other than the Security Auditor and SSO. Otherwise

audit logs shall be backed up daily, or whenever activity has taken place at

the CA in the event of infrequent use, as part of the same schedule as the

regular backup of the CA database.

5.4.5.2 If audit logs are held in a physical form, they shall also be backed up daily, or

whenever activity has taken place at the CA in the event of infrequent use,

through photocopy or other means.

5.4.5.3 Audit logs shall be written to a device which can only be written to once but

may be read many times, in order to ensure audit logs cannot be modified

after creation. In very restricted circumstances where other physical and

personnel controls are in place, the PSNA may authorise a CA to write the

logs to disk.

5.4.5.4 Reliance on incremental backups alone is not permitted. However CA

software that performs internal incremental backups every few hours is

acceptable providing a full backup of the entire system is also performed.

5.4.5.5 All audit log backups, whether electronic or physical, shall be held in

accordance with the outcome of a risk assessment and documented within

the CPS. The security of the audit log backup shall be at least as strong as

for the primary copy of the audit logs, in accordance with the requirements of

Section 5.

5.4.6 Audit collection system (internal vs. external)

5.4.6.1 The CA audit collection system shall be documented in the CPS.

5.4.7 Notification to event-causing subject

5.4.7.1 Where an individual causes an audit event, information concerning the audit

event and that individual will be retained. The individual will not be notified

separately that this information will be retained but the right to do so will be

included in the employment contract.

5.4.8 Vulnerability assessments

5.4.8.1 Events in the audit process are logged, in part, to monitor system

vulnerabilities.

UNCLASSIFIED



of 99



UNCLASSIFIED

5.4.8.2 Each CA and RA must ensure that its PKI services are accredited by the

PSTSA Accreditation Board (PSAB) to impact levels 4-4-4 and included

within an RMADS prior to live operation.

5.4.8.3 The RMADS shall be reviewed and revised in the event that security issues

are identified in the examination of monitored events.

5.4.8.4 An information security penetration test, including a CESG IT Health Check,

shall be undertaken of Sub-CA systems prior to live operation. The scope of

the penetration test shall include both internal and external attacks and

application layer testing.

5.4.8.5 The PSN Root CA shall undergo appropriate security testing by CESG prior

to live operation.

5.5 Records archival

5.5.1 Types of event recorded

5.5.1.1 The events and accompanying data described in Section 5.4 shall be

recorded in the archive.

5.5.1.2 All issued CRLs shall be archived.

5.5.1.3 Private Keys shall not be recorded in the archive.

5.5.2 Retention period for archive

5.5.2.1 Archive records shall be kept for a period of at least 7 years without any loss

of integrity.

5.5.2.2 Where possible, archives shall be held as ASCII text in comma-separated

variable (CSV) or rich text format (RTF) files. If this is not possible,

applications necessary to read these archives, and the environments

necessary to run these applications, shall be maintained for at least the

applicable retention period above.

5.5.3 Protection of archive

5.5.3.1 Protection for confidentiality shall either be physical security alone, or a

combination of physical security and cryptographic protection. The archive

shall also be protected from environmental factors such as temperature,

humidity and magnetism.

5.5.3.2 The archive shall only be accessible to, and accessed by, authorised

personnel (e.g. the System Administrator). No user shall be able to write to,

modify, or delete any data held in the archive.

UNCLASSIFIED



of 99



UNCLASSIFIED

5.5.4 Archive backup procedures

5.5.4.1 The archive shall be backed up in a second physical location in accordance

with the outcome of a risk assessment and documented within the CPS.

Protection shall be to the same level as required at the primary site, in

accordance with the requirements of Section 5.

5.5.5 Requirements for time-stamping of records

5.5.5.1 All CAs shall time-stamp all records with the date and time, in hours, minutes

and seconds.

5.5.5.2 The accuracy of the time-stamping shall be in accordance with the

requirements of Section 6.8.

5.5.6 Archive collection system (internal vs. external)

5.5.6.1 An internal archive collection system shall be used.

5.5.6.2 The CA and RA archive collection system shall be documented in the CPS.

5.5.7 Procedures to obtain and verify archive information

5.5.7.1 All CAs and RAs shall ensure that the integrity of archives is verified at least

every 12 months. The integrity of archived material that is stored off-site

shall be verified at least annually. The procedures for verification shall be

stated in the CPS.

5.6 Key changeover

5.6.1.1 CAs shall not issue certificates that extend beyond the expiry dates of their

own certificates and public keys.

5.6.1.2 CA key changeover shall occur half way through the lifetime of each

certificate plus or minus six months.

5.6.1.3 On key changeover a new key-pair shall be generated and a new certificate

published.

5.6.1.4 On key changeover:

a. The old CA Private Key will no longer be used to sign certificates.

b. The old CA Public Key remains valid for its lifetime in order to

validate signatures produced by the old Private Key prior to

changeover.

c. The new Private Key is used to sign certificates.

d. The new Public key is used to validate signatures produced by the

new Private Key.

UNCLASSIFIED



of 99



UNCLASSIFIED

5.6.1.5 For each CA there will be a single signing key (Private Key) and two

verification keys (Public Keys) active at any time (except for the first half of

the operational lifetime of a new CA where there will be a single validation

key).

5.7 Compromise and disaster recovery

5.7.1 Incident and compromise handling procedure

5.7.1.1 In the event of a security incident, the Information Assurance Standard

Number 4 reference [2] and PSN Incident and Problem Management

reference [17] should be used (CPNI Incident Response mechanisms should

be used as appropriate).

5.7.1.2 Each CA must establish a business continuity plan, incorporating disaster

recovery and crisis management plans, outlining the steps to be taken to re-

establish a secure facility in the event of any disaster.

5.7.1.3 If the security incident is tied to a service incident, the PSN entity will work

through the PSN Service Bridge and endeavour to re-instate normal service

as part of this activity.

5.7.2 Computing resources, software and/or data are corrupted

5.7.2.1 All Sub-CAs shall operate a dual site configuration with a fully documented

and tested failover procedure. The failover period in the event of the failure

of one of the sites shall be no more than 12hrs.

5.7.2.2 In the event of a disaster where the CA service becomes inoperative, the CA

service shall be recovered to a known state with priority given to:

a. the availability of all previously issued CRLs; and

b. the ability to revoke certificates.

5.7.2.3 If the Sub-CA cannot re-establish revocation capabilities within one day it

must report this to the PSNA, which shall consider the immediate revocation

of the Sub-CA certificates if necessary. The PSNA may grant extensions to

Sub-CAs on a case-by-case basis.

5.7.2.4 If all copies of the Sub-CA CRL signature key are destroyed, the PSNA shall

revoke the Sub-CA certificate. The Sub-CA installation shall be rebuilt from

the start, by re-establishing the Sub-CA equipment and, where necessary,

re-issuing the Sub-CA certificate, and all End-entity certificates.

5.7.2.5 If a Sub-CA certificate is revoked, the Sub-CA shall notify all End-entity

Subscribers and of this fact.

UNCLASSIFIED



of 99



UNCLASSIFIED

5.7.2.6 In the event of a disaster where the CA service becomes inoperative, a

report of the disaster shall be produced by the CA and made available to the

PSNA. This report shall include

a. an assessment of the impact of this disaster;

b. an assessment of whether and to what degree compromise of the

confidentiality, integrity of availability of confidential information (as

defined in Section 9.3) has taken place;

c. a description of the actions taken to restore the CA;

d. a description of the results of those actions; and

e. a description of the level of service that has been restored,

including the time at which the service was restored.

5.7.3 Entity private key compromise procedures

5.7.3.1 In the event of a compromise of the Private Key of a Sub-CA, the certificate

shall be revoked in accordance with Section 4.9.3 of this policy and the

revocation reported in accordance with Section 4.9.12 of this policy.

5.7.3.2 Compromise issues associated with other types of certificate are described

in Section 4.9

5.7.3.3 A crisis management plan shall be in place to deal with the media and legal

implications of any compromise.

5.7.4 Business continuity capabilities after a disaster

5.7.4.1 All CAs shall implement a business continuity strategy and plan, including a

disaster recovery site to ensure the continuation of the revocation capability

in the event of a disaster. Where a repository is not under the control of the

CA, a CA must ensure that any agreement with the repository provider

includes the requirement that a disaster recovery plan be established, tested

and documented by the repository provider.

5.7.4.2 In developing disaster recovery and failover plans, priority shall be given to:

a. the availability of all previously issued CRLs; and

b. the ability to revoke certificates.

5.7.4.3 CAs shall implement, document and periodically test such contingency

planning and disaster recovery capabilities and procedures as it considers

appropriate in light of its obligations under this CP.

5.7.4.4 Such disaster recovery capabilities shall be consistent with good industry

practices and shall be designed to enable the Sub-CA to provide services in

accordance with this Certificate Policy within 12hrs of a disruption.

UNCLASSIFIED



of 99



UNCLASSIFIED

5.8 CA or RA termination

5.8.1.1 Prior to termination, Sub-CAs shall provide archived data to a PSNA-

approved archival facility.

5.8.1.2 In the event that a Sub-CA ceases operation, it must notify its Subscribers in

writing at least one month before termination of operations and arrange for

the continued retention of the Sub-CA‟s keys and information.

5.8.1.3 In the event of a change in management of a Sub-CA‟s operations, the Sub-

CA must notify in writing all Entities for which it has issued certificates.

5.8.1.4 The Sub-CA archives should be retained in the manner and for the time

indicated in Section 5.5.2.

UNCLASSIFIED



of 99



UNCLASSIFIED

6. Technical Security Controls

6.1 Key pair generation and installation

6.1.1 Key pair generation

6.1.1.1 CA signing keys shall be generated in accordance with HMG Information

Assurance Standard Number 4 [Reference 2] and as specified in Section

6.2:

a. by CESG on behalf of PSNA; or

b. by the Sub-CA using PSNA approved key generation devices and

standards in conjunction with PSNA provided entropy generated by

CESG.

c. by the Sub-CA using PSNA approved key generation devices and

standards.

6.1.1.2 RA signing keys shall be generated in accordance with HMG Information

Assurance Standard Number 4 reference [2] and as specified in Section 6.2:

a. by CESG on behalf of PSNA;

b. by the Sub-CA using PSNA approved key generation devices and

standards in conjunction with PSNA provided entropy generated by

CESG: or

c. by the Sub-CA using PSNA approved key generation devices and

standards.

6.1.1.3 End-entity keys may be locally generated or self-generated by the device,

subject to PSNA approval of the generation and certificate signing processes

in accordance with Section 6.2.1.

6.1.1.4 Keys that are not generated within the device itself must be authenticated on

loading into the device to ensure that they originate from an authorised

source. This should be achieved through the provision of a digital signature

of the key which shall be verified by the device when the key is installed.

6.1.1.5 End-entity devices shall support a full RFC5280-compliant path validation

process, and in particular shall enable configuration of the following input

parameters in order to ensure that inappropriate certificates are not used

(this is a requirement for PRIME profiles only):

a. user-initial-policy-set;

b. initial-policy-mapping-inhibit;

c. initial-explicit-policy; and

d. initial-any-policy-inhibit.

UNCLASSIFIED



of 99



UNCLASSIFIED

6.1.2 Private Key delivery to subscriber

6.1.2.1 If the key pair has been generated by a CA for a Subscriber then the Private

Key shall be delivered using accountable out-of-band methods approved by

the PSNA.

6.1.2.2 The handling of cryptographic material, including private key distribution,

shall at all times comply with HMG Information Assurance Standard Number

4.

6.1.3 Public key delivery to certificate issuer

6.1.3.1 If key pairs are generated by the RA, delivery of public keys shall be

achieved with a certificate request signed by the RA using a recognised

standard protocol (e.g. PKCS#10).

6.1.3.2 If key pairs are generated by the Subscriber, delivery of public keys shall be

achieved with a certificate request using a recognised standard protocol (e.g.

PKCS#10).

6.1.4 CA public key delivery to relying parties

6.1.4.1 The delivery of the Root CA public key to End-entities must be performed in

a secure manner in order to guarantee the integrity of the public key, such

as:

a. secure delivery via internal systems, such as directory systems

accessible from the PSN;

b. manual delivery with physical security measures suitable for

handling RESTRICTED material;

c. secure on-line delivery of the trust point using a PSNA approved

encryption method; or

d. on-line delivery of the public key using an out-of-band method to

verify the integrity of the public key using a PSNA-approved hash

function.

6.1.4.2 All Sub-CA certificates shall be manually distributed to servers and devices

and made available in the PKD.

6.1.5 Key sizes

6.1.5.1 Certificate algorithms and key sizes shall be consistent with the CESG PSN

Cryptographic Framework, reference [2]. Both the End State Profile and the

Interim Profile are currently supported; however the End State Profile is

preferable and support for the Interim Profile will be removed from this policy

in due course.

UNCLASSIFIED



of 99



UNCLASSIFIED

6.1.5.2 The supported algorithms and key sizes for the Root CA are as follows:-

a. Interim Profile: 2048-bit RSA and SHA-1; and

b. End State Profile: ECDSA-384 and SHA-384.

6.1.5.3 The supported algorithms and key sizes for Sub-CAs are as follows:-



6.1.5.4 The supported algorithms and key sizes for IPsec End-entities are as

follows:



6.1.6 Public key parameters generation and quality checking

6.1.6.1 A CA shall generate parameters in accordance with the CESG PSN

Cryptographic Framework, reference [2].

6.1.6.2 The quality of the parameters shall be verified in accordance with the CESG

PSN Cryptographic Framework, reference [2].

6.1.7 Key usage purposes (as per X.509 v3 key usage field)

6.1.7.1 The certificate “keyUsage” field must be used in accordance with the PKIX-1

Certificate and CRL Profile (RFC5280 reference [5]).

6.1.7.2 The following additional values must be present in CA certificate-signing

certificates (these values must not be present in End-entity certificates):

a. “keyCertSign”, and

b. “cRLSign”.

6.1.7.3 CA signing keys are the only keys permitted to be used for signing

certificates and CRLs.

6.1.7.4 End-entity certificates shall only be used in the single device to which they

have been issued.

6.1.7.5 The “digitalSignature” “keyUsage” values must be present in End-entity

certificates.

6.1.7.6 No other “keyUsage” values may be present in certificates issued under this

Certificate Policy.

6.2 Private Key protection and cryptographic module controls

6.2.1 Cryptographic module standards and controls

UNCLASSIFIED



of 99



UNCLASSIFIED

6.2.1.1 CA and RA Private Keys shall be stored within a hardware security module

(HSM) which has been formally assured according to one of the following:

a. FIPS140-2 Level 3;

b. CAPS-approved BASELINE grade; or

c. an alternative CESG assessment process approved by the PSNA

6.2.1.2 All CA and RA cryptographic operations must be performed within the

hardware security module (HSM).

6.2.1.3 For Sub-CAs, the keys must be stored and processed within a hardware

security module (HSM).

6.2.1.4 End-entity Private Keys shall be stored within a security module which has

been formally assured according to one of the following:

a. PSN Encryption Products Assurance Scheme (PEPAS)

b. CAPS-approved BASELINE grade; or

c. an alternative CESG assessment process approved by the PSNA

6.2.2 Private Key (n out of m) multi-person control

6.2.2.1 Unless explicitly authorised otherwise by the PSNA, handling of CA Private

Keys shall be under “n out of m” multi-person control, where both n and m

are 2 or greater.

6.2.2.2 HSMs shall require at least two individuals in order to start up and shut

down.

6.2.2.3 Sub-CAs may automatically fulfil requests and therefore the HSM shall not

require further n of m controls for private key usage, once the Sub-CA has

been started.

6.2.3 Private Key escrow

6.2.3.1 Private Key escrow is not supported by PSN PKI.

6.2.4 Private Key backup

6.2.4.1 CA Private Keys shall be backed up and stored in encrypted form. CA

Private Key backups shall be maintained in secure storage, where the

security of the backup site shall be at least as secure as the security of the

main CA database, in accordance with the requirements of Section 5. CA

Private Keys shall not be transferred from a cryptographic module in an

unencrypted form.

6.2.5 Private Key archival

6.2.5.1 Private Keys shall not be archived.

UNCLASSIFIED



of 99



UNCLASSIFIED

6.2.6 Private Key transfer into or from a cryptographic module

6.2.6.1 CA Private Keys shall not be transferred from a cryptographic module except

for where multiple devices are used for a resilient solution or for backup

purposes. During key transfer or backup, CA Private Keys shall be

encrypted. CA Private Key transfer or backup shall only be performed by

personnel with an appropriate Trusted Role, as described in Section 5.2.1.

6.2.6.2 End-entity Private Keys that are generated by the Sub-CA or RA shall be

encrypted.

6.2.6.3 When a Private Key is not generated within a cryptographic module, it shall

be delivered to the module in a secure manner, either using PKIX compliant

key management protocol or in a manner approved by the PSNA and CESG.

6.2.7 Private Key storage on cryptographic module

6.2.7.1 Private Keys shall be stored in encrypted form.

6.2.8 Method of activating Private Key

6.2.8.1 For CA certificates, the cryptographic module shall require the successful

completion of an authentication process, which shall involve the use of

Activation Data (a password or smart card), before activating the Private

Key. Passwords shall be unique, shall not be reused and shall not be

guessable. The authentication credentials must have an appropriate level of

strength for the keys or data to be protected, commensurate with the

protection of RESTRICTED data in accordance with HMG Security Policy

Framework, reference [8].

6.2.8.2 CA Private Keys shall only be activated by personnel with an appropriate

Trusted Role, as described in Section 5.2.1.

6.2.8.3 Explicit authentication is not required to activate an End-entity Private Key

but may be used if required. Once authenticated, an End-entity Private Key

shall be activated until de-activated.

6.2.9 Method of deactivating private key

6.2.9.1 The Private Key may be de-activated by the Subscriber or by the system.

The following actions shall de-activate the private key:

a. turning the power off;

b. logging off;

c. system reset; and

d. the private key may also be deactivated after a pre-set period of

inactivity if required.

UNCLASSIFIED



of 99



UNCLASSIFIED

6.2.9.2 Other events may de-activate the private key if required.

6.2.10 Method of destroying private key

6.2.10.1 CA and End-entity Private Keys stored in hardware modules shall be

securely overwritten or destroyed in accordance with the guidance for the

destruction of RESTRICTED CRYPTO material in the Security Policy

Framework, HMG Information Assurance Standard Number 4, reference [2].

6.2.10.2 Private keys shall be destroyed prior to the disposal or repair of any

cryptographic module.

6.2.11 Cryptographic module rating

6.2.11.1 Cryptographic module engineering controls are covered in Section 6.2.1 of

this Certificate Policy.

6.3 Other aspects of key pair management

6.3.1 Public key archival

6.3.1.1 CAs shall archive their Public Keys in accordance with the requirements of

Section 5.4.

6.3.2 Certificate operational periods and key pair usage periods

6.3.2.1 The maximum certificate operational lifetime periods shall be as follows:

a. ten years for the PSN Root CA certificate;

b. five years for PSN Sub-CA certificates); and

c. one year for PSN End-entity certificates (IPsec IL3 devices)

6.4 Activation Data

6.4.1 Activation Data generation and installation

6.4.1.1 Activation Data shall be unique and unpredictable.

6.4.1.2 Where Personal Identification Numbers (PINs) or passwords are used, an

entity must have the capability to change its PIN or password at any time.

6.4.1.3 The Activation Data, in conjunction with any other access control, must have

an appropriate level of strength for the keys or data to be protected,

commensurate with the protection of RESTRICTED data in accordance with

HMG Security Policy Framework, reference [8].

6.4.2 Activation Data protection

6.4.2.1 Activation Data must be protected from unauthorised use by a combination

of cryptographic and physical access control mechanisms. The level of

UNCLASSIFIED



of 99



UNCLASSIFIED

protection must be adequate to deter a motivated attacker with substantial

resources.

6.4.3 Other aspects of Activation Data


6.5 Computer security controls

6.5.1 Specific computer security technical requirements

6.5.1.1 The Sub-CA and RA will have successfully completed and been awarded a

PSN Compliance Certificate for its PSN PKI service.

6.5.2 Computer security rating

6.5.2.1 To obtain a PSN Compliance certificate for a PSN PKI service a Sub-CA or

RA capability shall have been accredited by the PGA on behalf of the PSAB

and assured using the PSN CA assurance process ref [15] by CESG. As

part of that assurance process it is expected that certain components within

the capability will have been independently assured.

6.6 Life cycle technical controls

6.6.1 System development controls

6.6.1.1 CA operational systems shall be developed in a controlled environment,

under a recognised quality management system (e.g. ISO 9001:2000 or

similar). The configuration of the CA system as well as any modifications and

upgrades must be documented and controlled. A formal configuration

management methodology must be used for installation, ongoing

maintenance and evolution of the CA system. No upgrades shall be

permitted without prior offline testing and assessment, and regular backups

must be taken.

6.6.2 Security management controls

6.6.2.1 The CA shall provide a mechanism to periodically verify the integrity of the

software. The CA shall have mechanisms and policies in place to control

and monitor the configuration of the CA system. Upon installation time, and

regularly thereafter, the integrity of the CA system shall be validated.

6.6.2.2 System security management shall be controlled by the privileges assigned

to system accounts and by the trusted roles described in Section 5.2.1,

according to appropriate standards (e.g. ISO/IEC 27001 or similar).

6.6.2.3 The configuration of the CA system as well as any modifications and

upgrades must be documented and controlled. A formal configuration

UNCLASSIFIED



of 99



UNCLASSIFIED

management methodology must be used for installation, ongoing

maintenance and evolution of the CA system. No upgrades shall be

permitted without prior offline testing and assessment, and regular backups

must be taken. The CA software, when first loaded, must provide a method

for the CA to verify that the software on the system:

a. originated from the software developer;

b. has not been modified prior to installation; and

c. is the version intended for use.

6.6.2.4 Any Sub-CA installation that is connected to a network shall be subject to an

IT Health Check, carried out by CESG or a CHECK-approved supplier.

6.6.2.5 The CA shall conduct a failure impact analysis in order to demonstrate

security resilience. The CA shall provide a mechanism to periodically verify

the integrity of the software. These mechanisms shall be documented in the

CPS.

6.6.2.6 Subscribers shall use security access controls provided by the underlying

operating system to ensure that only the subject and authorised users (e.g.

administrators) may access Private Key files.

6.6.3 Life cycle security controls


6.7 Network security controls

6.7.1.1 An offline Root CA capability shall be used. No connections to external

networks are permissible.

6.7.1.2 Any online Sub-CA or RA system (i.e. connected to an external network)

shall be located in a separate network segment, separated from other

activities within the organisation‟s network by a secure assured gateway,

which shall be configured to enable traffic for only the required business

communications. The level and strength of the secure assured gateway shall

be sufficient for the protection of a RESTRICTED network.

6.7.1.3 Any Sub-CA or RA installation that is connected to a network shall be

subject to a regular IT Health Check at a frequency determined during the

PSN compliance process by the PGA as agents for the PSNA. The IT Health

Check shall be carried out by CESG or a CHECK approved supplier with

Green Light status.

6.7.1.4 Subscribers shall ensure that networks with devices holding Private Keys are

compliant with the PSN Code of Connection at Impact Level 2 (IL2).

UNCLASSIFIED



of 99



UNCLASSIFIED

6.8 Time-stamping

6.8.1.1 CAs shall timestamp all records with the date and time, in hours, minutes

and seconds.

6.8.1.2 The system clocks on all platforms associated with the issuing of certificates

or CRLs at RAs and CAs shall be synchronised to an accuracy defined

within the Technical Domain Description (TDD) reference [14].

6.8.1.3 All Sub-CA and RA systems shall be synchronised to an accuracy defined

within the TDD reference [14].

6.8.1.4 All time sources shall be derived as defined in the TDD.

UNCLASSIFIED



of 99



UNCLASSIFIED

7. Certificate, CRL, and OCSP Profiles

7.1 Certificate Profile

This section defines the key elements of the profiles that are fully defined in Annex E - Annex L.

7.1.1 Version number(s)

7.1.1.1 The version number shall be v3 (value number 2), as defined in RFC 5280

“Internet X.509 Public Key Infrastructure Certificate and Certificate

Revocation List (CRL) Profile”.

7.1.2 Certificate extensions

7.1.2.1 The certificate profile, including the use of certificate extensions, to be used

by a CA shall be approved by the PSNA prior to the issuance of any

certificates.

7.1.2.2 The use of certificate extensions shall comply with the specifications in RFC

5280.

7.1.2.3 Certification Authorities shall define, populate and make non-critical the

following extensions for all certificates generated:

a. “authorityKeyIdentifier”, using one of the two methods specified in

RFC 5280;

b. “subjectKeyIdentifier”, using one of the two methods specified in

RFC 5280; and

c. “cRLDistributionPoints”.

7.1.2.4 Certification Authorities shall define, populate and make critical the following

extensions for all certificates generated:

a. “keyUsage”, using the values specified in Section 6.1.7.

b. “certificatePolicies”, using the values specified in Section 7.1.6: the

value “anyPolicy” shall not be present on end-entity certificates;

7.1.2.5 Certification Authorities shall define, populate and make critical the following

extensions for certificates issued to Sub-CAs:

a. “basicConstraints”, where the value of “cA” shall be true.

7.1.2.6 Certification Authorities shall define and populate the following extensions for

certificates issued to Sub-CAs:

a. “policyConstraints”, where the “requireExplicitPolicy” field shall be

defined with value 0 (zero).

UNCLASSIFIED



of 99



UNCLASSIFIED

7.1.2.7 Certification Authorities may define and populate the following extensions (If

defined, these extensions shall be non-critical):

a. “subjectAltName”;

b. “subjectDirectoryAttributes”;

c. “basicConstraints” (for End-entity certificates only, where the value

of “cA” shall be false);

d. “authorityInfoAccess”;

e. “freshestCRL”; and

f. “subjectInfoAccess”.

7.1.2.8 Certification Authorities may define and populate the “inhibitAnyPolicy”

extension. If defined, this extension shall be non-critical.

7.1.2.9 The CPS must define the use of any extensions supported by the CA, its

RAs and End-entities.

7.1.3 Algorithm object identifiers

7.1.3.1 The supported algorithms and key sizes are identified in Section 6.1.5. The

Object Identifiers to represent these algorithms and key size choices are:-

7.1.3.2 Signatures:

a. RSA-2048 and SHA-1: sha1WithRSAEncryption

1.2.840.113549.1.1.5

b. ECDSA-256 and SHA-256: ecdsa-with-SHA256

1.2.840.10045.4.3.2

c. ECDSA-384 and SHA-384: ecdsa-with-SHA384

1.2.840.10045.4.3.3

7.1.3.3 Keys:

a. RSA-2048: rsaEncryption 1.2.840.113549.1.1.1

b. ECDSA-256: key: id-ecPublicKey 1.2.840.10045.2.1, curve:

ansix9p256r1 1.2.840.10045.3.1.7

c. ECDSA-384: key: id-ecPublicKey 1.2.840.10045.2.1, curve:

ansix9p384r1 1.3.132.0.34

7.1.4 Name forms

7.1.4.1 All distinguished names must be in the form of an X.501 PrintableString.

7.1.5 Name constraints

7.1.5.1 Subject and issuer distinguished names must comply with PKIX standards

and must be present in all certificates. All names must comply with

reference [16].

UNCLASSIFIED



of 99



UNCLASSIFIED

7.1.5.2 Unique identifiers (“issuerUniqueID” and “subjectUniqueID”) shall not be

defined.

7.1.6 Certificate Policy Object Identifier

7.1.6.1 All certificates must contain the appropriate PKI Policy OID as defined in

Section 1.2 of this Certificate Policy.

7.1.7 Usage of Policy Constraints extension

7.1.7.1 All CA certificates shall define and populate the Policy Constraints extension

as defined in Section 7.

7.1.8 Policy qualifiers syntax and semantics


7.1.9 Processing semantics for the critical Certificate Policies extension

7.1.9.1 Critical extensions shall be interpreted as defined in PKIX RFC 5280.

7.2 CRL Profile


7.2.1.1 The version number shall be v2 (value number 1), as defined in RFC 5280

“Internet X.509 Public Key Infrastructure Certificate and Certificate

Revocation List (CRL) Profile”.

7.2.2 CRL and CRL entry extensions

7.2.2.1 The CRL profile, including the use of CRL extensions, to be used by a CA

shall be approved by the PSNA prior to the issuance of any certificates.

7.2.2.2 All entity PKI software must correctly process all CRL extensions identified in

the PKIX Certificate and CRL profile. The CPS must define the use of any

extensions supported by the CA, its RAs and end-entities.

7.2.2.3 Certification Authorities shall define and populate the following CRL fields

and extensions for all CRLs generated:

a. “nextUpdate”; and

b. “reasonCode”.

7.3 OCSP profile


7.3.1.1 No OCSP profile is defined within this Certificate Policy.

7.3.2 OCSP extensions

UNCLASSIFIED



of 99



UNCLASSIFIED

7.3.2.1 No OCSP profile is defined within this Certificate Policy.

UNCLASSIFIED



of 99



UNCLASSIFIED

8. Compliance Audit and Other Assessment

8.1 Frequency or circumstances of assessment

8.1.1 Compliance of End-entity organisations shall be assessed by PSNA as part of the standard PSN Compliance process as detailed in the PSN Compliance document, ref [13]. The frequency and extent of external audits will be specified by the PSNA in accordance with the PSN Compliance policy.

8.1.2 Compliance of CAs and RAs with this Certificate Policy shall be ensured using a process that is consistent with the standard PSN Compliance process. The PSN Compliance policy, ref [13], will detail the compliance requirements for the PKI and the Certificate Policy aspects of the PSN. Before a CA is operational, it shall be subject to an assessment by the PSAB to assess compliance with this Certificate Policy.

8.1.3 Following live operation, a Sub-CA will undergo an external audit to ensure that it is compliant with the requirements of this Certificate Policy.

8.1.4 The RMADS for a CA or RA (as defined in Section 6.5.1) shall be reviewed, and revised as necessary, by the CA or RA on an annual basis. Any anomalies shall be escalated to the PSNA.

8.1.5 The CA / RA must undertake an annual internal audit and certify annually to the PSNA that they have at all times during the period in question complied with the requirements of the Certificate Policy. The CA / RA must also provide to the PSNA details of any periods of non-compliance and explain the reasons why the CA / RA has not complied with the Certificate Policy.

8.1.6 The PSNA shall have the right to audit and inspect the premises, staff documents and data of any Sub-CA or RA for the purposes of evaluating that CA or RA‟s compliance with the terms of the Certificate Policy.

8.1.7 The PSNA, at its discretion, may request a Sub-CA or RA to undergo an independent external audit at any time.

8.1.8 The audit of the Root CA to review compliance with this Certificate Policy will be undertaken by the PSAB before operation and periodically thereafter at a frequency to be agreed by PSAB and PSNA. It will be performed by suitably qualified and vetted members of the PSAB led by the PGA.

8.2 Identity/qualifications of assessor

8.2.1.1 The external auditor acts as an agent for the PSNA and shall be selected by

the PSNA. The auditor shall have formal audit qualifications as accord with

best commercial practice or as required by law. This shall also include

significant experience with PKI and cryptographic technologies as well as the

operation of relevant PKI software. The external auditor will require the

appropriate vetting to perform the audit.

8.3 Assessor’s relationship to assessed entity

UNCLASSIFIED



of 99



UNCLASSIFIED

8.3.1.1 Aside from the audit function, the auditor and audited party shall not have

any current or planned financial, legal or other relationship that could result

in a conflict of interest.

8.4 Topics covered by assessment

8.4.1.1 The audit, detailed in section 8.1, shall cover whether:

a. the Certification Practice Statement (CPS) outlines, in sufficient

detail, the technical, procedural and personnel policies and

practices of the CA/RA which meet the requirements of all the

certificate policies supported by the CA/RA;

b. the CA implements and complies with the technical, procedural and

personnel practices and policies outlined in the CPS; and

c. an RA, if used, implements and complies with the technical,

procedural and personnel practices and policies set out by the CA

in the CPS.

8.4.1.2 The topics covered by a compliance audit consist of the following:

a. physical security;

b. documentation and process;

c. vetting of operational personnel;

d. technical security measures; and

e. privacy, including compliance with Data Protection laws.

8.4.1.3 A Certificate or Registration Authority shall be given advance notice (of not

less than 10 working days) of the aspects of the PKI that will be audited for

any given inspection.

8.4.1.4 The Certificate or Registration Authority shall co-operate with the auditor and

shall afford the auditor all reasonable assistance and access to the

Authority‟s premises, staff, documentation and data.

8.5 Actions taken as a result of deficiency

8.5.1.1 If deficiencies are found as a result of the independent external audit, the

Sub-CA/RA shall be informed in writing immediately. The Sub-CA/RA must

submit a report to the auditor or directly to the PSNA, as determined by the

PSNA, as to any remedial action the Sub-CA/RA will take in response to the

identified deficiencies. This report shall include a time for completion to be

approved by the auditor, or by the PSNA as appropriate. The PSNA shall be

kept informed by the Sub-CA/RA at all times.

UNCLASSIFIED



of 99



UNCLASSIFIED

8.5.1.2 Remedial action may include revocation of the Sub-CA/RA certificate, as

defined in Section 4.9.

8.5.1.3 Where a Sub-CA/RA fails to take appropriate action in response to the

identified deficiencies, the PSNA shall be informed and shall take the

appropriate action, according to the severity of the deficiencies which shall

include:

a. noting the deficiencies but allowing the Sub-CA/RA to continue

operations until the next planned, or newly scheduled, inspection; or

b. revoking the Sub-CA/RA‟s certificate.

8.6 Communication of results

8.6.1.1 Audit results shall be communicated to the PSNA and treated in accordance

with Section 9.3 unless otherwise specified in an applicable contract.

9. Other Business and Legal Matters

Rather than the Certificate Policy addressing the legal arrangements between PSN

PKI participants, these legal arrangements will primarily be dealt with in the relevant

contracts between firstly the PSNA and the Sub-CA and secondly the Sub-CA and

the End-entity. Legal effect will also be given to the provisions of this Certificate

Policy through these contracts.

9.1 Fees

9.1.1 Certificate issuance or renewal fees

9.1.2 Fees may be charged by the Sub-CA for Certificate issuance, subject to the commercial agreements between the End-entity and Sub-CA. Clear notification must be provided of the fee structure and any changes to the fee structure.

9.1.3 Certificate access fees

9.1.3.1 Certificates shall be available from the PKD and no fees shall be charged for

certificate access.

9.1.4 Revocation or status information access fees

9.1.4.1 CRLs shall be published to the PKD and no fees shall be charged for access

to CRLs.

9.1.5 Fees for other services

9.1.5.1 Fees may be charged by the Sub-CA for other revocation or status

information services, subject to the commercial agreement between the End-

UNCLASSIFIED



of 99



UNCLASSIFIED

entities and the Sub-CA. Clear notification must be provided of the fee

structure and any changes to the fee structure

9.1.6 Refund policy


9.2 Financial responsibility

9.2.1 Insurance coverage

9.2.1.1 Sub-CAs and RAs shall ensure that they have sufficient financial resources

and/or insurance cover to maintain their operations and perform their duties.

9.2.2 Other assets


9.2.3 Insurance or warranty coverage for end-entities.


9.3 Confidentiality of business information

9.3.1 Scope of confidential information

9.3.1.1 All PSN PKI Participants shall keep the following information confidential and

safeguard it accordingly:

a. all records of Root Authority, Root CA and Sub-CA activities and

events;

b. any transactional records in relation to PKI;

c. audit trail records and reports;

d. contingency planning and disaster recovery plans; and

e. security measures.

9.3.1.2 The information and material listed at section 9.3.1.1 above shall not be

further disclosed without the written consent of the relevant authority except:

a. In the case of disclosure by the PSNA, for the purposes of the PSN

PKI, or

b. if reasonably required for audit or inspection purposes or

c. where required by law.

9.3.2 Information not within the scope of confidential information


9.3.3 Responsibility to protect confidential information


UNCLASSIFIED



of 99



UNCLASSIFIED

9.4 Privacy of information

9.4.1 Privacy plan


9.4.2 Information treated as private


9.4.3 Information not deemed private


9.4.4 Responsibility to protect private information


9.4.5 Notice and consent to use private information


9.4.6 Disclosure pursuant to judicial or administrative process


9.4.7 Other information disclosure circumstances


9.5 Intellectual property rights

9.5.1 Any Intellectual Property Rights in a key pair belongs to the entity that generated the key pair.

9.6 Representations and warranties

9.6.1 The PSN PKI Root Authorities make no representations and exclude all warranties and conditions relating to the issue, use or reliance on any certificate issued pursuant to this Certificate Policy other than those expressly stated in this Certificate Policy and any which would otherwise be implied are excluded to the fullest extent permitted by law.

9.6.2 Sub-CA representations and warranties


9.6.3 RA representations and warranties


9.6.4 Subscriber representations and warranties


9.6.5 Relying party representations and warranties

UNCLASSIFIED



of 99



UNCLASSIFIED


9.6.6 Representations and warranties of other participants


9.7 Disclaimers of Warranties

9.7.1 No stipulation within this Certificate Policy.

9.8 Limitations of liability

9.8.1 There will be limitations on the liability of the PSNA and CESG. These will be set out in the contract between the PSNA and the Sub-CA.

9.9 Indemnities


9.10 Term & termination

9.10.1 Term


9.10.2 Termination


9.10.3 Effect of termination and survival


9.11 Individual notices and communications with participants

9.11.1 Individual notices and communications with participants shall be communicated by electronic mail over the PSN or by post as appropriate.

9.12 Amendments

9.12.1 Procedure for amendment

9.12.1.1 The PSNA reserves the right to amend the Certificate Policy at any time

normally giving one months notice and this will normally be in consultation

with the PKI Working Group, the PSAB and other competent bodies.

However the PSNA can if necessary modify the Certificate Policy without

prior notice see Section 9.12.2.1.

9.12.2 Circumstances under which OID must be changed

9.12.2.1 Any change to this Certificate Policy relating to formatting or the correction

of minor typographical errors can be performed without notification and

without requiring a new Object Identifier to be allocated:

UNCLASSIFIED



of 99



UNCLASSIFIED

9.12.2.2 Any changes to this Certificate Policy that does not lower, and cannot be

perceived to lower, the fundamental trust that can be placed in the certificate

can be performed with notification but without requiring a new Object

Identifier to be allocated:

9.12.2.3 Any changes to this Certificate Policy that lowers, or could be perceived to

lower, the fundamental trust that can be placed in the certificate cannot be

performed unless a new Certificate Policy with a new Object Identifier is

allocated.

9.13 Dispute resolution provisions


9.14 Governing law

9.14.1 English law governs this Certificate Policy. Sub-CAs must ensure that any agreement entered into between them and an End Entity on matters to which this Certificate Policy relates are governed by English law and are subject to the exclusive jurisdiction of the English Courts.

9.15 Compliance with applicable law


9.16 Miscellaneous provisions

9.16.1 Entire agreement


9.16.2 Assignment


9.16.3 Severability


9.16.4 Enforcement (attorneys’ fees and wavier of rights)


9.16.5 Force Majeure


9.17 Other provisions

9.17.1 Sub-CAs shall enter into legally binding agreements with End-entity Subscribers giving full effect to the provisions of this Certificate Policy in so far as they relate to or are capable of applying to End-entity Subscribers and

UNCLASSIFIED



of 99



UNCLASSIFIED

End-entity Subjects. All such agreements shall be governed by English law and subject to the exclusive jurisdiction of the English Courts.

UNCLASSIFIED



of 99



UNCLASSIFIED

Annex A. References All documents defined within this reference refer not only to the version specified but also to all subsequent amendments, revisions or versions.

[1] PSN: Cryptographic Framework, v1.0, May 2011.

[2] Management of Cryptographic Systems, HMG Information Assurance Standard Number 4, v5.1, April 2011.

[3] Strategy for a PSN Central Service Public Key Infrastructure v1.0 July 2011.

[4] RFC3647, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework.

[5] RFC5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, May 2008.

[6] Requirements for Secure Delivery of Online Public Services, Issue 1.0, July 2010.

[7] PSN Operating Model: Main Document, Public Sector Network Programme, v2.0, 03/12/10.

[8] HMG Security Policy Framework, v8, April 2012.

[9] RFC5764, Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP), May 2010.

[10] ITU-T Recommendation X.500 (2005) | ISO/IEC 9594-1:2005, Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services.

[11] ITU-T Recommendation X.501 (2005) | ISO/IEC 9594-2:2005, Information technology - Open Systems Interconnection - The Directory: Models.

[12] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks.

[13] PSN Compliance, v3.7, 26 July 2012

[14] PSN Technical Domain Description (TDD) Version v2.3, 26 July 2012

[15] PSN CA Service Requirement v1.8 July 2012

[16] PSN IL3 Inter-Provider Encryption Domain Connectivity v1.0

[17] PSN Incident & Problem Management, v2.4, 26 July 2012

UNCLASSIFIED



of 99



UNCLASSIFIED

Annex B. Acronyms and Abbreviations This section defines the acronyms and abbreviations used in this Certificate Policy.

Term Expansion

ARL Authority Revocation List

ASCII American Standard Code for Information Interchange

BASELINE A grade of encryption defined by the CAPS process

CA Certificate Authority

CAPS CESG Assisted Products Scheme (www.cesg.gov.uk)

CESG Communications-Electronics Security Group, the UK National

Technical Authority for Information Assurance, which is part of

the Government Communications Headquarters (GCHQ) an

HMG Department.

CHECK A CESG IT health check scheme to identify vulnerabilities in IT

systems and networks which may compromise the

confidentiality, integrity or availability of information

CONFIDENTIAL An HMG protective marking classification, as defined in HMG

Security Policy

CPNI Centre for the Protection of National Infrastructure

CPS Certification Practice Statement

CRL Certificate Revocation List

DNSP (PSN) Direct Network Service Provider – reference [7]

ECDSA Elliptic Curve Digital Signature Algorithm as specified in FIPS

186-2

HMG Her Majesty‟s Government

HSM Hardware Security Module

IETF Internet Engineering Task Force

IPsec Internet Protocol Security. This is an IETF standard.

ISO/IEC International Organization for Standardization (ISO) and the

International Electrotechnical Commission

UNCLASSIFIED



of 99



UNCLASSIFIED

Term Expansion

OCSP Online Certificate Status Protocol

OID Object Identifier

OrgID Organisational Identifier

PEPAS PSN Encryption Products Assurance Scheme

(www.cesg.gov.uk)

PGA Pan Government Accreditor

PIN Personal Identification Number

PKCS#10 Public Key Cryptography Standards (#10 – Certification request

syntax)

PKD Public Key Directory

PKI Public Key Infrastructure

PKIX Public-Key Infrastructure (X.509) working group

PMA Policy Management Authority

PSN Public Services Network

PSAB PSTSA Accreditation Board

PSNA Public Services Network Authority

PSTSA Public Services ???

RA Registration Authority

RESTRICTED An HMG protective marking classification, as defined in HMG

Security Policy

RFC Request for Comment

RMADS Risk Management and Accreditation Document Set

RSA Rivest, Shamir and Adleman Encryption/Signature Algorithm

RSDOPS GPG43 - Requirements for the Secure Delivery of Online Public

Services, reference [6]

SC Security Check

UNCLASSIFIED



of 99



UNCLASSIFIED

Term Expansion

SHA Secure Hash Algorithm as defined in FIPS 180-3

SP (PSN) Service Provider, – reference [7]

SPF HMG Security Policy Framework, reference [8]

SSO System Security Officer

UK United Kingdom

X.500 The set of ITU-T standards covering electronic directory

services, reference [10]

X.501 A specification, reference [11], detailing the information models

in use in the X.500 Directory, reference [10]

X.509 A specification for the format of a certificate, reference [12]

UNCLASSIFIED



of 99



UNCLASSIFIED

Annex C. Glossary This section defines the terms used in this Certificate Policy.

Term Definition

Activation Data Private data, other than keys, that are required to access

cryptographic modules (i.e., unlock Private Keys for signing or

decryption events)

Applicant The Subscriber is sometimes also called an “applicant” after

applying to a CA for a certificate, but before the certificate

issuance procedure is completed

Authority Revocation List A list maintained by the Root CA of the certificates which it has

issued that it has revoked prior to their stated expiration date.

CA Software The application software used to operate the CA.

Certificate An X.509 Certificate as profiled in RFC5280.

Certification Authority An authority trusted and authorised by the PSNA to issue and

manage X.509 Public Key Certificates and CRLs within the PSN

PKI. When CA is used on its own it refers to all Certification

Authorities within the PSN PKI.

Certificate Policy This set of rules governing the applicability of a certificate to a

particular community and/or class of application with common

security requirements

Certification Practice

Statement

A statement of the practices that a CA employs in issuing,

suspending, revoking and renewing certificates, and providing

access to them, in accordance with specific requirements (e.g.,

requirements specified in this Certificate Policy, or requirements

specified in a contract for services)

Certificate Revocation List A list maintained by a CA of the certificates which it has issued

that it has revoked prior to their stated expiration date.

Certificate Status Services A service that enables the user to determination of the status of

a Certificate.

Certificate Subject Name The field in an X.509 certificate that holds the identity of the

entity to whom a certificate is issued.

Cross-Certificate A certificate issued between two Certification Authorities used to

UNCLASSIFIED



of 99



UNCLASSIFIED

Term Definition

establish and indicate a trust relationship between them

Crypto Custodian A Custodian is appointed at each location where Comsec items

are held and is responsible for the management and accounting

of all Comsec items under their control. Where these Comsec

items bear the CRYPTO or ACCSEC descriptors, the Custodian

will usually be referred to as the CRYPTO or ACCSEC

Custodian.

Cryptographic Root of Trust Defined as CESG.

Digital Signature The result of a transformation of a message by means of a

cryptographic system using private/public key pairs and

certificates such that the recipient of the message and signature

can determine: (1) whether the transformation was created using

the Private Key which complements the public key in the

certificate; and (2) whether the message has been altered since

the transformation was made

Distinguished Name X.501 Distinguished Name.

Eligible Certification

Authorities

The bodies which are eligible to apply to become Certification

Authorities within the PSN PKI

Eligible End-entity

Subscribers

The bodies which are eligible to apply to become End-entity

Subscribers within the PSN PKI

Eligible Registration

Authorities

The bodies which are eligible to apply to become Registration

Authorities within the PSN PKI

Eligible Subscribers The bodies which are eligible to apply to become Subscribers

within the PSN PKI

End-entity Subscriber, Subject and Relying Party

End-entity Certificate The final (lowest) certificate in a chain of certificates

End-entity Subjects The devices that use the End-entity Certificates

End-entity Subscribers The organisations or individuals responsible for End-entity

Certificates

Hierarchical Trust Model A hierarchical trust model is one in which every key can be the

subject of no more than one certificate or certificate request

message

UNCLASSIFIED



of 99



UNCLASSIFIED

Term Definition

Intellectual Property Rights Any copyright, patent, trade mark, service mark, design right,

and any trade or business name or logo, or moral right,

database right or know how (whether capable of registration or

not in any country including the UK) and any such right in

respect of which an application has been made to a competent

authority.

Issuing CA A CA that issues, or has issued, a certificate

IT Health Check IT Health Check is an independent check, consisting of a

number of practical, expert tests, on an IT system or network to

ensure that known security vulnerabilities which may

compromise the confidentiality, integrity or availability of the

information on that IT system or network have been adequately

addressed or eliminated.

Object Identifier A representation of the CP within the certificate.

Private Key The key which complements the key identified in the certificate

(the Public Key)

PSN Code of Connection Sets out PSN Customer obligations and requirements for

connecting to PSN – reference [7]

PSN Code of Practice Sets out the PSNSP obligations and requirements for

connecting to the PSN – reference [7]

PSN PKI Authorities The CAs and RAs within the PSN PKI

PSN PKI Root Authorities Root Authority (PSNA) and Cryptographic Root of Trust (CESG)

Public Key The key held within the certificate, complemented by the Private

Key

Public Key Infrastructure The set of hardware, software, people, policies, and procedures

needed to create, manage, distribute, use, store, and revoke

digital certificates

Registration Authority An entity that is responsible for identification and authentication

of Certification Authorities, Subscribers and certificate subjects,

but that does not sign or issue certificates (i.e. a Registration

Authority is delegated certain tasks on behalf of an authorised

CA)

Relying Party An individual or an organisation, who acts in reliance on a

UNCLASSIFIED



of 99



UNCLASSIFIED

Term Definition

certificate and digital signatures verified using that certificate

Relying Party Agreement An agreement between a Relying Party and the issuing CA, as

published by the CA at the time of the Relying Party relying on

the certificate

Repository A service which publishes certificates and/or CRLs for access by

Relying Parties. Also referred to as the PKD.

Root CA The entity whose public key serves as the trust anchor for all

Sub-CAs, RAs and End-entities covered by this Certificate

Policy.

Root Certificate The certificate containing the public key of the Root CA.

Subject The Subject of the certificate is the entity to whom the certificate

applies

Sub-CA Subordinate Certification Authority. A CA whose certificate

signing key is certified by the Root CA and whose activities are

constrained by the Root CA.

Subscriber The Subscriber is either a CA or an entity who contracts with a

CA and is issued with a Certificate; a Subscriber can be a CA,

RA or an End-entity and bears ultimate responsibility for the use

of the Private Key

Subscriber Agreement An agreement between the CA and a Subscriber under which

the Subscriber undertakes certain obligations and liabilities to

the CA in accordance with this Certificate Policy

Trust anchor A public key that is known (trusted) by a Relying Party. The

mechanism of path discovery establishes a trusted path

between a certificate and a trust anchor. A common trust anchor

is a self-signed (root) certificate

Trust Point A trust point is a third party identity that is qualified with a level of

trust

X.500 Name Space The available set of X.501 Distinguished Names.

UNCLASSIFIED



of 99



UNCLASSIFIED

Annex D. PSN CSR Template PSN Pilot Device Certificate Request Form

This form is intended to capture the information needed to request and process PSN

Sub-CA & RA Certificate requests.

Please be advised of the following:

This form is only applicable for the request of PSN certificates.

The organisation on behalf of which the certificate(s) is being requested and their

representative must be registered with the PSN Registration Authority.

A Memorandum of Understanding or contractual agreement must exist between the

organisation and the PSN registration authority and the Device Certificate

Representative must have signed the PSN Subscriber Agreement.

PART 1 – DEVICE REPRESENTATIVE PERSONAL INFORMATION

Forename

Surname

Middle Initial

Organisation

Email

Telephone

PART 2 – DEVICE REGISTRATION INFORMATION

This section allows identification information to be provided for up to three Sub-CA or RA certificates. Should more be required then additional fields may be added.

Organisational Name: This should identify the Sub-CA or RA and must be unique within the PSN namespace. Where appropriate, this should match the DNS name of

the device.

Additional information may also be provided.

Sub-CA or RA #1

Org Name

Additional information:

UNCLASSIFIED



of 99



UNCLASSIFIED

Sub-CA or RA #2

Org Name


Sub-CA or RA #3

Org Name


ORGANISATION REPRESENTATIVE DECLARATION

I am responsible for the Sub-CA or RA described in Part 2 of this form and I attest to the accuracy of the information provided.

Signature:

Date:

PART 3 – REGISTRATION AUTHORITY AUTHORISATION

I approve the Sub-CA or RA certificate request(s) and confirm that the identified device representative has previously been registered for by the PSN Registration Authority.

Full Name

Position

Signature:

Date:

UNCLASSIFIED



of 99

This information is exempt from disclosure under the Freedom of Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to GCHQ on 01242 221491

x30306, email [email protected]

UNCLASSIFIED

Annex E. PSN IL3 IPsec Root CA Certificate Profile (Interim) Field Criticality Value Comments

Certificate

tbsCertificate Fields to be signed

version 2 Integer Value of "2" for X.509 Version 3 certificate

serial number INTEGER Unique positive integer

signature

AlgorithmIdentifier (Interim)

algorithm 1.2.840.113549.1.1.5 RSA-2048 and SHA-1: sha1WithRSAEncryption

parameters NULL For RSA encryption, parameters field must contain NULL

issuer

Name Distinguished Name, as defined by the PSN PKI Naming Policy

RDNSequence Distinguished Names must be in the form of an X.501 PrintableString.

RelativeDistinguishedName

AttribuuteTypeAndValue

AttributeType OID Object Identifier of X.500 AttributeType

AttributeValue <data> Value of attribute encoded in PrintableString format.

validity Validity period the Root CA certificate is 10 years

notBefore

Time

utcTime YYMMDDHHMMSSZ Use for dates up to and including 2049

generalTime YYYYMMDDHHMMSSZ Use for dates after 2049

notAfter

Time



subject



RellativeDistinguishedName




subjectPublicKeyInfo

algorithm

UNCLASSIFIED



of 99



UNCLASSIFIED

AlgorithmIdentifier

algorithm 1.2.840.113549.1.1.1 RSA-2048: rsaEncryption

parameters NULL For RSA encryption, parameters field must contain NULL RSAParamenters

subjectPublicKey BIT STRING Root CA certificate shall have a key length of 2048 bits

required extensions

authorityKeydentifier FALSE CA‟s shall define, populate and make non-critical this extension.

keyIdentifier OCTET STRING

Derived from the SHA-1 hash of the issuer public key using one of the two methods specified in RFC 5280

subjectKeydentifier FALSE CA‟s shall define, populate and make non-critical this extension.



keyUsge TRUE Critical extensions shall be interpreted as defined in PKIX RFC 5280. digitalSignature 0

nonRepudiation 0

keyEncipherment 0

dataEncipherment 0

keyAgreement 0

keyCertSign 1 CA signing keys are the only keys permitted to be used for signing CRL‟s

cRLSign 1 CA signing keys are the only keys permitted to be used for signing certificates.

encipherOnly 0

decipherOnly 0

certificatePolicies TRUE

CA‟s shall define, populate and make this extension critical and interpret as defined in PKIX RFC 5280.

policyIdentifier 1.2.826.0.1316.3.0.0 PSN PKI IPsec IL3 Certificate Policy

cRLDistributionPoints FALSE CA‟s shall define, populate and make non-critical this extension.

DistributionPoint

distributionPoint

DistributionPointName

fullName

GeneralNames

GeneralName

uniformResourceIdentifier

basicConstraints TRUE Critical extensions shall be interpreted as defined in PKIX RFC 5280. cA TRUE Indicates that the certified public key belongs to a CA.

UNCLASSIFIED



of 99



UNCLASSIFIED

UNCLASSIFIED



of 99



UNCLASSIFIED

Annex F. PSN IL3 IPsec Root CA Certificate Profile (End-state) Field Criticality Value Comments

Certificate




signature

AlgorithmIdentifier

algorithm 1.2.840.10045.4.3.3 ECDSA-384 and SHA-384: ecdsa-with-SHA384

parameters

issuer







validity Validity period the Root CA certificate is 10 years

notBefore

Time



notAfter

Time



subject








algorithm

UNCLASSIFIED



of 99



UNCLASSIFIED

AlgorithmIdentifier

algorithm 1.3.132.0.34 ECDSA-384: key: id-ecPublicKey 1.2.840.10045.2.1, curve: ansix9p384r1 parameters

RSAParamenters

subjectPublicKey

required extensions







keyUsge TRUE Critical extensions shall be interpreted as defined in PKIX RFC 5280. digitalSignature 0

nonRepudiation 0

keyEncipherment 0

dataEncipherment 0

keyAgreement 0

keyCertSign 1 CA signing keys are the only keys permitted to be used for signing CRL‟s

cRLSign 1 CA signing keys are the only keys permitted to be used for signing certificates.

encipherOnly 0

decipherOnly 0





DistributionPoint

distributionPoint


fullName

GeneralNames

GeneralName


basicConstraints TRUE Critical extensions shall be interpreted as defined in PKIX RFC 5280. cA TRUE Indicates that the certified public key belongs to a CA.

UNCLASSIFIED



of 99



UNCLASSIFIED

Annex G. PSN IL3 Sub-CA Certificate Profile (Interim) Field Criticality Value Comments

Certificate




signature

AlgorithmIdentifier (Interim)



issuer







validity Validity period the Sub-CA certificate is 5 years

notBefore

Time



notAfter

Time



subject








algorithm Interim

UNCLASSIFIED



of 99



UNCLASSIFIED

AlgorithmIdentifier



subjectPublicKey BIT STRING Sub-CA certificate shall have a key length of 2048 bits

required extensions







keyUsge TRUE

CA‟s shall define, populate and make critical this extension and interpret as defined in PKIX RFC 5280.

digitalSignature 0

nonRepudiation 0

keyEncipherment 0

dataEncipherment 0

keyAgreement 0

keyCertSign 1 CA signing keys are the only keys permitted to be used for signing certificates.

cRLSign 1 CA signing keys are the only keys permitted to be used for signing CRL‟s

encipherOnly 0

decipherOnly 0





DistributionPoint

distributionPoint


fullName

GeneralNames

GeneralName


authorityInfoAccess FALSE

AuthorityInfoAccessSyntax

AccessDescription

UNCLASSIFIED



of 99



UNCLASSIFIED

acessMethod

accessLocation

GeneralName


accessMethod

accessLocation

GeneralName


basicConstraints TRUE Critical extensions shall be interpreted as defined in PKIX RFC 5280.

cA TRUE Indicates that the certified public key belongs to a CA.

pathLenConstraint INTEGER Use of a path length constraint is optional.

policyConstraints

TRUE Sub-CA certificates must contain the policyConstraints extension to control path validation to require a valid PSN PKI IPsec IL3 policy identifier in all certificates and shall be interpreted as defined in PKIX RFC 5280.

requiredExplicitPolicy SkipCerts = 0

Requires certificates in an evaluated path to contain an explicit Certificate Policy identifier.

optionalextensions

inhibitAnyPolicy TRUE SkipCerts = 0

Sub-CA certificates may include the InhibitAnyPolicy extension. If defined, this extension shall be critical and shall be interpreted as defined in PKIX RFC 5280.

subjectAltName FALSE

Sub-CA certificates may include this extension. If defined, this extension shall be non-critical.

GeneralNames

GeneralName

rfc822Name

UNCLASSIFIED



of 99



UNCLASSIFIED

Annex H. PSN IL3 Sub-CA Certificate Profile (End-state) Field Criticality Value Comments

Certificate




signature

AlgorithmIdentifier


parameters

issuer







validity Validity period the Sub-CA certificate is 5 years

notBefore

Time



notAfter

Time



subject








algorithm

UNCLASSIFIED



of 99



UNCLASSIFIED

AlgorithmIdentifier

algorithm 1.2.840.10045.3.1.7 ECDSA-256: key: id-ecPublicKey 1.2.840.10045.2.1, curve: ansix9p256r1 parameters

RSAParamenters

subjectPublicKey

required extensions







keyUsge TRUE

CA‟s shall define, populate and make critical this extension and interpret as defined in PKIX RFC 5280.

digitalSignature 0

nonRepudiation 0

keyEncipherment 0

dataEncipherment 0

keyAgreement 0

keyCertSign 1 CA signing keys are the only keys permitted to be used for signing certificates.

cRLSign 1 CA signing keys are the only keys permitted to be used for signing CRL‟s

encipherOnly 0

decipherOnly 0





DistributionPoint

distributionPoint


fullName

GeneralNames

GeneralName


authorityInfoAccess FALSE

AuthorityInfoAccessSyntax

AccessDescription

UNCLASSIFIED



of 99



UNCLASSIFIED

acessMethod

accessLocation

GeneralName


accessMethod

accessLocation

GeneralName


basicConstraints TRUE Critical extensions shall be interpreted as defined in PKIX RFC 5280.

cA TRUE Indicates that the certified public key belongs to a CA.

pathLenConstraint INTEGER Use of a path length constraint is optional.

policyConstraints

TRUE Sub-CA certificates must contain the policyConstraints extension to control path validation to require a valid PSN PKI IPsec IL3 policy identifier in all certificates and shall be interpreted as defined in PKIX RFC 5280.

requiredExplicitPolicy SkipCerts = 0

Requires certificates in an evaluated path to contain an explicit Certificate Policy identifier.

optionalextensions

inhibitAnyPolicy TRUE SkipCerts = 0

Sub-CA certificates may include the InhibitAnyPolicy extension. If defined, this extension shall be critical and shall be interpreted as defined in PKIX RFC 5280.


Sub-CA certificates may include this extension. If defined, this extension shall be non-critical.

GeneralNames

GeneralName

rfc822Name

UNCLASSIFIED



of 99



UNCLASSIFIED

Annex I. PSN IL3 Certificate Revocation List (CRL) Profile (Interim) Field Criticality Value Comments

CertificateList

tbsCertList Fields to be signed.

version 1 Integer Value of "2" for X.509 Version 2 CRL.

signature

AlgorithmIdentifier

This field must contain the identifier for the signature algorithm used by the issuing CA to sign the certificate.

algorithm 1.2.840.113549.1.1.5 Sha1WithRSAEncryption

parameters NULL For RSA encryption, parameters field must contain NULL.

issuer




AttributeTypeAndValue

AttributeType OID Object Identifier of X.500 AttributeType.


thisUpdate Validity period in accordance with the PSN PKI IL3 IPsec Certificate Policy.

Time



nextUpdate TRUE

All CA‟s shall define and populate a validity period in accordance with the PSN PKI IL3 IPsec Certificate Policy and shall be interpreted as defined in PKIX RFC 5280.

Time



revokedCertificates Revoked certificates, listed by serial number (must be absent if list is empty)

userCertificate

CertificateSerialNumber INTEGER Unique positive integer.

revocationDate

Time



crlEntryExtensions

reasonCode TRUE (0-10)

Issuing authorities shall define and specify a reason code for all CRL‟s generated in accordance with RFC 5280 that identifies the reason for the certificate

UNCLASSIFIED



of 99



UNCLASSIFIED

Field Criticality Value Comments

revocation.

required extensions

authorityKeyIdentifier FALSE


Derived from the SHA-1 hash of the issuer public key using one of the two methods specified in RFC 5280.

CRLNumber FALSE INTEGER Sequence number for a given CRL scope in accordance with RFC 5280.

UNCLASSIFIED



of 99



UNCLASSIFIED

Annex J. PSN IL3 Certificate Revocation List (CRL) Profile (End-State) Field Criticality Value Comments

CertificateList

tbsCertList Fields to be signed.

version 1 Integer Value of "2" for X.509 Version 2 CRL.

signature

AlgorithmIdentifier

This field must contain the identifier for the signature algorithm used by the issuing CA to sign the certificate.


parameters

issuer




AttributeTypeAndValue

AttributeType OID Object Identifier of X.500 AttributeType.


thisUpdate Validity period in accordance with the PSN PKI IL3 IPsec Certificate Policy.

Time



nextUpdate TRUE

All CA‟s shall define and populate a validity period in accordance with the PSN PKI IL3 IPsec Certificate Policy and shall be interpreted as defined in PKIX RFC 5280.

Time



revokedCertificates Revoked certificates, listed by serial number (must be absent if list is empty)

userCertificate

CertificateSerialNumber INTEGER Unique positive integer.

revocationDate

Time



crlEntryExtensions

reasonCode TRUE (0-10)

Issuing authorities shall define and specify a reason code for all CRL‟s generated in accordance with RFC 5280 that identifies the reason for the certificate

UNCLASSIFIED



of 99



UNCLASSIFIED

Field Criticality Value Comments

revocation.

required extensions

authorityKeyIdentifier FALSE


Derived from the SHA-1 hash of the issuer public key using one of the two methods specified in RFC 5280.

CRLNumber FALSE INTEGER Sequence number for a given CRL scope in accordance with RFC 5280.

UNCLASSIFIED



of 99



UNCLASSIFIED

Annex K. PSN IL3 End-entity Certificate Profile (Interim) Field Criticality Value Comments

Certificate




signature

AlgorithmIdentifier



issuer







validity Validity period the Sub-CA certificate is 1 year

notBefore

Time



notAfter

Time



subject








algorithm

UNCLASSIFIED



of 99



UNCLASSIFIED

AlgorithmIdentifier



subjectPublicKey BIT STRING End-entity certificate shall have a key length of 2048 bits

required extensions

authorityKeydentifier FALSE End-entities shall define, populate and make non-critical this extension.



subjectKeydentifier FALSE End-entities shall define, populate and make non-critical this extension.



keyUsge TRUE

End-entities shall define, populate and make critical this extension and shall be interpreted as defined in PKIX RFC 5280.

digitalSignature 1 This extension must be present in end-entity certificates.

nonRepudiation 0

keyEncipherment 0

dataEncipherment 0

keyAgreement 0

keyCertSign 0 This extension MUST NOT be present in end-entity certificates.

cRLSign 0 This extension MUST NOT be present in end-entity certificates.

encipherOnly 0

decipherOnly 0


End-entities shall define, populate and make this extension critical and shall be interpreted as defined in PKIX RFC 5280.


cRLDistributionPoints FALSE End-entities shall define, populate and make non-critical this extension.

DistributionPoint

distributionPoint


fullName

GeneralNames

GeneralName


basicConstraints FALSE

cA FALSE cA value of FALSE for end-entity certificates.

optionalextensions

UNCLASSIFIED



of 99



UNCLASSIFIED


End-entities certificates may include this extension. If defined, this extension shall be non-critical.

GeneralNames

GeneralName

rfc822Name

UNCLASSIFIED



of 99



UNCLASSIFIED

Annex L. PSN IL3 End-entity Certificate Profile (End-state) Field Criticality Value Comments

Certificate




signature

AlgorithmIdentifier


parameters

issuer







validity Validity period the Sub-CA certificate is 1 year

notBefore

Time



notAfter

Time



subject








algorithm

UNCLASSIFIED



of 99



UNCLASSIFIED

AlgorithmIdentifier

algorithm 1.2.840.10045.3.1.7 ECDSA-256: key: id-ecPublicKey 1.2.840.10045.2.1, curve: ansix9p256r1 parameters

RSAParamenters

subjectPublicKey

required extensions

authorityKeydentifier FALSE End-entities shall define, populate and make non-critical this extension.



subjectKeydentifier FALSE End-entities shall define, populate and make non-critical this extension.



keyUsge TRUE

End-entities shall define, populate and make critical this extension and shall be interpreted as defined in PKIX RFC 5280.

digitalSignature 1 This extension must be present in end-entity certificates.

nonRepudiation 0

keyEncipherment 0

dataEncipherment 0

keyAgreement 0

keyCertSign 0 This extension MUST NOT be present in end-entity certificates.

cRLSign 0 This extension MUST NOT be present in end-entity certificates.

encipherOnly 0

decipherOnly 0


End-entities shall define, populate and make this extension critical and shall be interpreted as defined in PKIX RFC 5280.


cRLDistributionPoints FALSE End-entities shall define, populate and make non-critical this extension.

DistributionPoint

distributionPoint


fullName

GeneralNames

GeneralName


basicConstraints FALSE

cA FALSE cA value of FALSE for end-entity certificates.

optionalextensions

UNCLASSIFIED



of 99



UNCLASSIFIED


End-entities certificates may include this extension. If defined, this extension shall be non-critical.

GeneralNames

GeneralName

rfc822Name

psn certificate policy ipsec il3 - gov.uk

Documents