Smart Meters Programme Schedule 2.1

Transcription

1 Smart Meters Programme Schedule 2.1 (DCC Requirements) (SMKI version) V1.2 1

2 Schedule 2.1 (DCC Requirements) This Schedule 2.1 (DCC Requirements) is formed of the following parts: Part A Introduction...3 Part B Scope...3 Part C SMKI Context...4 Part D SMKI Implementation...5 Part E SMKI Technical Requirements...5 Part F SMKI Business and Service Requirements Part G SMKI Implementation and Programme Requirements Part I SMKI Required Products APPENDIX A - GLOSSARY APPENDIX B CERTIFICATE & DEVICE CERTIFICATE PROFILES APPENDIX C VOLUME AND PERFORMANCE APPENDIX D SMKI RECOVERY REQUIREMENTS APPENDIX E SMKI STANDARDS APPENDIX F SMKI DEVICE CERTIFCATE ROLLOUT APPENDIX G ORGANISATION CERTIFICATE POLICY APPENDIX H DEVICE CERTIFICATE POLICY V1.2 2

3 Part A Introduction 1 This schedule sets out certain DCC Requirements for the Services to be provided by the Contractor. 2 The Contractor Solution shall deliver the requirements set out in this Schedule The following aspects are covered: (a) Error! Reference source not found.(see page 3) (b) Error! Reference source not found. (see page 3) (c) Part D: SMKI Implementation (See page 4) (d) Error! Reference source not found. (see page 5) (e) Error! Reference source not found. (see page 5) (f) Error! Reference source not found. (see page 113) (g) Error! Reference source not found. (see page 117) (h) Part I: SMKI Required Products (see page 119) (i) And all Appendices A - H 3 The provisions of this Schedule shall be interpreted as obligations on the Contractor (as if preceded by the words "the Contractor shall ensure") unless expressly stated otherwise. The Contractor shall ensure all the requirements listed in Parts A to I (inclusive) are met at all times in accordance with their terms. 4 The Contractor shall ensure the Services are provided at all times in accordance with each of the Contractor Solution Schedule 4.1 and each document forming a part of the Service. Part B Scope 1 The SMKI Service comprises the provision on behalf of the Licensee to SEC Parties of a secure Public Key Infrastructure consisting of a set of arrangements for controlling the creation, distribution, and management of Public Key Certificates for use by SEC Parties and the type 1 smart meter devices forming part of Smart Metering Equipment for the purpose of ensuring, among other things, the authenticity, integrity, and non-repudiation of communications and data, and the confidentiality of information within them. 2 The Contractor will deliver a managed service that is able to support secure messaging from the beginning of the DCC Systems Integration Testing period and will subsequently be able to fully support the implementation of User Integration Testing. V1.2 3

4 3 Out of Scope The physical network used to communicate with SMKI is out of scope but the interfaces including LAN Extensions (LE) are in scope. First line Service User support (this will be delivered by DCC). The Public Key repository will be hosted by the DSP and is therefore not in scope of this procurement. The Registration Authority personnel (these will be provided by DCC). Part C SMKI Context 1 The SMKI service will comprise of two distinct solutions as shown in the diagram below. These are: a) Organisation SMKI this supports the issuance of secure signed public certificates to the DCC, its service providers, and DCC Service Users. b) Devices SMKI this supports the issuance of secure signed public certificates for type 1 devices, e.g. meters, communications hubs Smart Metering Devices SMKI Organisation SMKI Procured Service Device Certificate Authorities PKD/CRL Procured Service Organisation Certification Authorities Root Device Certification Authority (Offline) Device Inventory Other Directory Root Organisation Certification Authority (Offline) Issuing Device Certification Authorities Issuing Organisation Certification Authorities Issuing Organisation Certification Authorities Issuing Organisation Certification Authorities Issuing Organisation Certification Authorities Issuing Organisation Certification Authorities Certificates Certificates Devices Large Energy Suppliers Network Operators DCC Smaller Energy Suppliers Other Users SMKI Particpants 2 The cryptographic algorithms in use across the SMKI service defined in these requirements will be the same as those detailed in the GB Companion Specification (GBCS). V1.2 4

5 3 The Certificate status management requirements for Device Certificates will differ to those of traditional X.509v3 managed Certificates and Certificates issued by the Organisation Certificate Authority. 4 There is no requirement for the Device Certificate Authority and the Organisation Certificate Authority to interoperate from a PKI technical trust point of view i.e. no requirement for crosscertification between the two associated root authorities. Part D SMKI Implementation 1 The contractor shall manage delivery according to the requirements and Milestones set out and agreed by both parties and signed off by DCC in the SMKI PID. Such approval not to be reasonably given. 2 The indicative milestone dates are as below: Milestone xxxxx xxxxx High Level Design xxxxx xxxxx Detailed Design xxxxx xxxxx Pre-Integration xxxxx xxxxx Systems Integration Test xxxxx xxxxx Go Live (live commissioning) xxxxx xxxxx Part E SMKI Technical Requirements 1 This section details the technical requirements for the SMKI Service. The contractor is required to deliver all the detailed elements below identified as essential, where they are within the scope of the Contractor solution and deliverables. Where a requirement has been identified as information, it is provided because it is relevant to SMKI delivery and the SMKI Contractor must understand this information, but is not required to deliver the functionality. 2 Document Conventions Where the term Device SMKI is used it shall be read and understood to encompass Device Certificate Authority and the associated Root Device Certificate Authority (Offline). Additionally where the term Organisation SMKI is used it shall be read and understood to encompass Organisation Certificate Authority and its associated Root Organisation Certificate Authority V1.2 5

6 (Offline). In both cases the Registration Authority (RA) and RA Portal support the request mechanism for approving Certificate Signing Requests destined for the OCA and DCA s prior to issuing publicly signed certificates. 3 Document References The following documents are referenced in this Schedule 2.1: Ref ID Title & Originator s Reference Source Release Date Version SMKI_SERVICE SMKI Service Definitions DECC Oct SMKI_DEVICE_CP SMKI Device Certificate Policy DECC Dec 2013 TBD SMKI_CONTEXT SMKI Concept of Operations see document pack. DCC Nov 2013 TBD PROG_PLAN DCC Programme Plan DCC Nov 2013 TBD 4 Detailed Technical Requirements All referenced HMG Security Framework Documents are subject to suitable mandate from DECC. 4.1 Organisation SMKI Service Definitions & Requirements The Organisation SMKI for the energy suppliers, network operators, the DSP, the CSP, and other DCC users will be based on a standard X509 PKI and will use X509.v3 Certificates. Certificates will be managed in the sense that the revocation status of Certificates will be published in a Certificate Revocation List (CRL). 4.2 Organisation SMKI General Service Definitions & Requirements The Organisation SMKI shall be a hierarchy with a depth of 2 levels. At the top level, the Organisation SMKI shall have a single Root Certification Authority (Root OCA) The Root OCA will be held offline The Root OCA will only issue Certificates for Issuing Certification Authorities (Issuing-OCA). The Root OCA will not issue Certificates to Organisations or Individuals The Root OCA shall only issue Issuing-Organisation Certificate Authority (OCA) Certificates in accordance with the Certificate Policy. V1.2 6

7 4.2.5 The Root OCA and Issuing-OCA will be based on X.509v3 Certificates as defined in [RFC 5759 and RFC5280], which by specification are encoded using the ASN.1 Distinguished Encoding Rules. See Appendix B for full details of Certificate profiles. Certificate serial numbers will be 16 octets in length, The Certificate Profiles will be as defined in Appendix B. All end entity Certificates will be based on X.509v3 Certificates as defined in [RFC 5759 and RFC5280], which by specification are encoded using the ASN1 Distinguished Encoding Rules. Serial numbers which will be 16 octets in length The Issuing-OCA issues Certificates to End Entity Organisations in accordance with the Certificate Policy. 4.3 Certificate & Certificate Lifecycles Certificates within the Organisation SMKI have finite lifetimes. This will need to be agreed with the DCC & the PMA. 4.4 Organisation Certificate Cryptographic Algorithm Lifetime [NIST SP800-57] treats the question of the expected lifetime of various cryptographic algorithm choices and key lengths. For the purpose of this document, the Organisation Certificate uses a choice of NSA Suite B cryptographic algorithms and key lengths that currently have no end-use date i.e. the cryptographic strength is adequate for the foreseeable future. 4.5 Organisation Certificate Validity An Organisation Certificate issued by the Issuing-OCA is considered valid for the life of the Certificate as defined in the applicable Certificate Policy published and approved by the Policy Management Authority (PMA) operating under the SEC Panel The Issuing-OCA will need to support multiple Certificate requests for an Organisation over the course of its lifetime where circumstances dictate The Issuing-OCA will need to inform the authorised requester of a Certificate if it has seen a request for that Organisation before, either from the same authorised requester or a different one If an Organisation already has a Certificate issued, the Issuing-OCA must validate with the requester that a new Organisation Certificate is required An Organisation may need to simultaneously hold multiple Certificates for different key pairs where policy or local security requirements dictate. 4.6 General Restrictions & Conditions V1.2 7

8 4.6.1 In addition, all Certificates in the Organisation CA (OCA) hierarchy have the following restrictions: The only permitted public key type for Certificates issued by the OCA (the OCA is used here to mean any CA in the Organisation SMKI hierarchy) is an Elliptic Curve (EC) public key on the NIST P- 256 curve. That public key MUST contain an elliptic curve point in uncompressed form. See [RFC 5480] Section 2.2 for details on the uncompressed form. The signature method for signatures formed by EC P-256 private keys MUST be SHA256 with ECDSA. The structure for ECDSA signatures is as per [RFC 5480] Per [RFC 5280], Registration Authorities (RA) and Issuing-OCAs MUST ensure the uniqueness of the serial numbers on the Certificates or Certificates they issue. RAs or Issuing-OCAs should use the mechanism for serial number generation as defined in the GB Companion Specification The Issuing-OCA will need to inform the authorised requester of a Certificate if it has seen a request for that Organisation before, either from the same authorised requester or a different one If an Organisation already has a Certificate issued, the Issuing-OCA must validate with the requester that a new Organisation Certificate is required. 4.7 Organisation SMKI Overview The Certificates issued to end entities under the Organisation SMKI are intended for use in supporting the messaging for Smart Metering systems and are currently limited to the authentication, integrity, nonrepudiation, and encryption of Smart Metering message communications. The Certificate Policy defines the community, usage and security requirements associated with the digital Certificates The Certificate Policy (CP) is a fundamental part of the compliance process. The SMKI Contractor providing Organisation SMKI services to SEC Parties MUST produce a Certificate Practice Statement (CPS) which complies with the obligations contained in the Certificate Policy 1 (see Appendix G) as published by the Policy Management Authority (PMA) The CP states the minimum requirements necessary to support trust in secure messaging and authentication, and details the minimum standards required; individual Certification Authorities (OCAs) may 1 The Base Certificate Policy for the Organisation SMKI V1.2 8

9 exceed the specifications of the Certificate Policy The SMKI Contractor must produce a PKI Disclosure Statement (PDS) and this must be published. The format of the PDS is as per [RFC 3647] (Note: this document may be omitted if the SMKI Contractor can fully justify reasons for doing so) The PDS must serve as the highest-level vehicle by which provisions affecting Subscribers and Relying Parties are defined. (Note: this document may be omitted if the SMKI Contractor can fully justify reasons for doing so) The PKI Disclosure Statement supporting the CP shall incorporate the CP by reference. 4.8 Organisation SMKI Participants The roles that need to be undertaken in the Organisation SMKI are as follows: SMKI Contractor DCC Certification Authorities (comprising of): Root OCA Issuing Organisation Certificate Authority Registration Authority (or Registrar) All technology, policies, processes, maintenance Repository (for internal service usage) Provision of personnel to operate the Registration Authority capability delivered and maintained by the SMKI CONTRACTOR. This will encompass as a minimum: Identifying and validating Organisations and Users to HMG Level 3 of GPG43 Approving CSR s prior to onward processing by the Organisation/Device Certificate Authorities Resolving CSR errors End Entities Subscriber V1.2 9

10 Subject Relying Party. 4.9 Organisation SMKI Certification Authority General Requirements A Certification Authority Service shall be designed and operated to issue Public Certificate Documents for Organisations within GB Smart Metering The Organisation SMKI Certification Authority for secure messaging will consist of a single hierarchy with a single trusted root Certificate At the top of the hierarchy is the Root OCA. The Root OCA will be managed, operated and co-ordinated by the SMKI Contractor To support the SMIP in delivering the Root OCA capability, the SMKI Contractor SHALL provide the cryptographic trust in the delivery of the Root OCA, and therefore will provide the Organisation SMKI Root Certificate (known as the Root Certificate) It shall be possible to form a validation path from all Certificates up to the Root Certificate At the second layer of the hierarchy are Issuing-OCAs which issue Certificates to end entities in Organisations The Organisation SMKI hierarchy SHALL only have 2 layers, to allow relying parties to perform full Certificate chain verification with minimum effort. This means that further subordinate Issuing-OCAs shall not be created All Issuing-OCAs will be authorised by the Root Certificate Authority. The Root Certificate Authority will be an offline authority that signs the Public Key Certificates for Issuing-OCAs Operation of a Root OCA and Issuing-OCAs is subject to approval by the PMA and is conditional on successful completion of the PMA defined compliance process. (See Section - Compliance Audit & Other Assessments 4.133) The SMKI Contractor will operate the Root OCA and all Issuing-OCAs on behalf of DCC DCC will be acting in the role of the Certification Authority and therefore DCC will be the name in the Issuer field of all digital Certificates. It is the only entity with which End-Entities have any form of direct or indirect contractual relationship. V1.2 10

11 The Root Certification Authority shall be compliant with [RFC 5759 and RFC5280], accredited and compliant with the CP and relevant Certificate profiles, before Live Data is used in the Service, and for the life of the Service once compliance has been achieved The Issuing-OCAs shall be compliant with [RFC 5759 and RFC5280], accredited and compliant with the CP and relevant Certificate profiles, before Live Data is used in the Service, and for the life of the Service once compliance has been achieved Certification Authority RFC 3647 defines Certification Authorities as the entities that Issue Certificates By definition, an Issuing-OCA is the entity listed in the Issuer field of a Certificate The SMKI Contractor must operate PKI functions in accordance with the Certificate Policy An online RA system for Subscribers/Subjects to submit Certificate requests must be made available and shall be documented and published. Access to the online RA system should only be via strong 2- factor authentication. Initial identity verification for authorised users of the RA system should be as defined in section Initial Identity Validation The binding of an Organisation s public key to its identity (the original assertion that an Organisation and its Public Key are correct) will be attested by the SMKI RA and the Issuing-OCA The OCA will operate to industry-standard PKI components, methods and good practice Where a SMKI Contractor chooses to use a contractor to provide certification services e.g. a Certificate manufacturer, the SMKI Contractor organisation itself remains responsible and accountable to the SMKI PMA and to the Issuing Authority for its operation. The scope of contracted out services must be approved by Smart DCC and the PMA Under this model, End-Entities (SMKI participants) only have a business relationship with the OCA. These relationships are defined by the Subscriber Agreements and Relying Party Agreements between the End- Entities and the OCA. In all matters the End-Entity relationship is with the DCC acting as the OCA With respect to the SMKI Contractor s delivery model, the PMA has overall and final control over compliance with the Certificate Policy and related documentation. V1.2 11

12 4.11 Registration Authority (or Registrar) Service Definitions 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) Further details of the RA Service Definition and Requirements can be found in Section Enrolment Process & Responsibilities 4.12 Subscribers A Subscriber is an End-Entity organisation that has applied for, and received a Certificate for use in Smart Metering under the Certificate Policy The Subscriber bears responsibility for the use of the Private Key associated with the Certificate Subjects The Subject is the entity to whom the Certificate applies Where a Certificate is issued for an Organisation, which does not directly contract with the OCA, the Subscriber (or an authorised representative acting on behalf of the Subscriber) will accept the terms and conditions on behalf of the Subject that is identified in the Certificate The Subject will be under the jurisdiction and control of the Subscriber and will comply with all relevant aspects of the CP and other agreements and obligations undertaken by the Subscriber In all cases the Subscriber is responsible for compliance with the CP and all other obligations applicable to it and the Subject Relying Parties A Relying Party is an End-Entity that does not necessarily hold a Certificate but even so, may rely on a Certificate and/or Digital Signatures/Derived symmetric keys created using that Certificate. The Relying Party is responsible for deciding whether or how to check the validity of the Certificate by checking the appropriate Certificate status information. The exact rights and responsibilities between a OCA and a Relying Party will be defined in the Relying Party Agreement Eligible Relying-Parties for Certificates Issued by the Issuing-OCA under the CP are DCC and DCC Users. V1.2 12

13 4.15 Other Participants Policy Management Authority The Policy Management Authority has ultimate responsibility for governance and control over the Issuance, management and usage of Certificates Issued under the CP. Simply stated the Policy Management Authority is the entity that sets the rules under which the Organisation SMKI is to be operated Repository The Repository provides a community-wide accessible mechanism by which primarily Subscribers and Relying Parties can obtain Certificates and CRLs issued by the Issuing-OCA under the CP The SMKI repository holds data in support of SMKI operations. This includes policy and related documentation, CRLs and Certificates. The Issuing Authority shall use the following approved Repository: DSP Public Key Directory (PKD). The repository shall be identified in the PKI Disclosure Statement Certificate Usage Certificate usage is defined by the Certificate Profiles as detailed in Appendix B Appropriate Certificate Uses Certificates are permitted for use only in respect of services operated by the DCC in support of end-to-end transactions between DCC, DCC Service Users, and Smart Metering Devices Appropriate Certificate uses will be detailed in the Certificate Policy and these must be adhered to Policy Administration The Policy Management Authority is responsible for approving rights, obligations, liabilities and all other terms and conditions contained in the Certificate Profile Any changes to the Certificate Policy must be done through the SEC SMKI change request process Contact details of the OCA must be published Person(s) Determining CPS Suitability for the Policy V1.2 13

14 The Policy Management Authority determines the suitability of any Certification Practice Statement operating under the CP OCA and CPS Approval Procedures The Policy Management Authority is responsible for approval procedures. See section Compliance Audit & Other Assessments (from 4.133) 4.21 Definitions and Acronyms Definitions of the terms used in this document are detailed in the Glossary of Terms which may be found in Appendix A. Publication and Repository Responsibilities 4.22 Repositories The OCA will use the approved Repository provided by the DSP as detailed in section The Issuing-OCA is the entity with overall responsibility for publishing Certificates and other Certificate for SMKI participants as detailed in section to the approved repository Publication of Certificate The Issuing-OCA shall ensure the following items are published for all Participants of this SMKI via the approved Repository: End Entity Public Key Certificates The Certificate Policy with its associated PKI Disclosure Statement. Any supporting policy documents and agreements. The that will allow the authenticity of the Certificate(s) of the Issuing-OCA to be verified. Root Public Key Certificate All Certificates of Issuing-OCAs issued by the Root OCA CRLs (produced by the Root OCA and Issuing-OCAs) 4.24 Time or Frequency of Publication as listed in section shall be published in accordance with the Performance Measures set out in Schedule 2.2. V1.2 14

15 Identification and Authentication 4.25 Naming Types of names See Appendix B for Certificate Profiles and naming rules Anonymity or pseudonymity of subscribers The anonymity or pseudonymity of Subscribers is not permitted Rules for Interpreting Various Name Forms The rules for interpreting name forms must match those as defined in the Certificate Profile in Appendix B. Any non-prescribed name forms must be rejected Uniqueness of Names Distinguished names must be globally unique for Issuing-OCAs and all Subjects under the jurisdiction of the Issuing-OCA Recognition, Authentication, and Role of Trademarks The Issuing-OCA is not liable for the inclusion of trademarks, trade names or other information under restricted use. Subscriber Agreements shall require Subscribers to warrant legitimacy of their registration details provided to the Issuing-OCA as part of the Registration Process Initial Identity Validation Method to Prove Possession of Private Key See section Authentication of Organisation Identity See section Authentication of Individual Identity See section Non-verified Subscriber See section Validation of Authority See section Criteria for Interoperation There is no requirement for interoperation Identification and Authentication for Re-Key Requests Identification and Authentication for Routine Re-Key Re-key of Certificates as governed by the Certificate Policy is not permitted. Changes must be enacted via Issuance of a new Certificate V1.2 15

16 following one of the approved processes specified in the Certificate Policy Identification and Authentication for Revocation Requests 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 When the requester of revocation is the authorised requester (through the online RA System) other methods may be used to validate requests, such as communication with the authorised SMKI RA Agent 2, providing reasonable assurances that the person or organisation requesting revocation is, in fact, an authorised requester. The SMKI Contractor 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 Requests to revoke an Organisation End Entity Certificate may be validated using that Certificate s associated public key, regardless of whether or not the Private Key has been compromised Requests for the revocation of an Issuing-OCA Certificate must be accompanied by two written signatures from appropriately authorised SMKI RA personnel Requests for revocation of all Certificates shall be logged, as described in Section Revocation requests for end entities must at a minimum include the identification and authentication of the authorised requester and sufficient information to uniquely identify the Certificate to be revoked. Valid proof of possession of the Certificate to be revoked is permitted as authentication Revocation requests for OCAs must at a minimum include the identification and authentication of the authorised SMKI RA Agent and sufficient information to uniquely identify the Certificate to be revoked. Valid proof of possession of the Certificate to be revoked is permitted as authentication. Revocation requests for OCAs are constrained to authorised personnel within the service or the PMA Where reliable authentication of the Revocation request isn t possible, the OCA or Registration Authority acting on its behalf, is authorised to conduct Revocation. In such cases the OCA or SMKI Registration Authority shall 2 RA Agent: A role within the SMKI Registration Authority authorised to carry out Certificate requests and perform Certificate management duties. V1.2 16

17 seek confirmation of the request to the greatest extent possible by practical means, prior to Revocation The SMKI Contractor needs to publish details of the revocation processes in the Registration Policies and Procedures Document Certificate Life-Cycle Operational Requirements 4.29 Certificate Application Who Can Submit a Certificate Application End Entity Certificate applications may only be made by: Authorised Subscribers through a centrally provided online RA system for submission of certificate requests OCA Certificate applications may only be made by: Authorised RA Agents within the OCA (using internal RA systems and processes) The following types of Certificate can be applied for according to the Certificate Policy: 1) RA Certificates (SMKI RA Roles); 2) End-entity Certificates; 3) Issuing-OCA Certificates generated by Root All Certificate requesters must comply with the procedures described as laid out by the OCA in its Registration Authority Policy and Procedures An application for a Certificate does not oblige an Issuing-OCA to issue a Certificate. The Issuing-OCA must ensure all criteria for Certificate requests are fulfilled. All procedures for Certificate application shall be documented in the CPS Enrolment Process and Responsibilities The SMKI Contractor must operate enrolment processes for OCAs and RAs operating within their domain before issuing any Certificates. The specific enrolment processes must be defined in its Registration Policy and Procedures. See section for more detail The SMKI Contractor must operate the enrolment processes for End Entities as described in section before issuing any Certificates Certificate Application Processing V1.2 17

18 Performing Identification and Authentication Functions The approved SMKI Registration Authority agent is permitted to conduct authentication of Certificate requesters Approval or Rejection of Certificate Applications The SMKI Registration Authority Agent will either approve or reject a Certificate application Where an application fails to achieve the specified criteria (properly constructed Where a Certificate application is rejected Time to Process Certificate Applications See Appendix C 4.32 Certificate Issuance OCA Actions During Certificate Issuance Certificates shall be issued automatically by the Issuing-OCA only in response to a properly constructed, signed and validated Certificate request from an approved SMKI RA Agent. Only the approved SMKI Registration Authority system can communicate with the Issuing-OCA to submit a Certificate request Notification to Subscriber by the Issuing-OCA of Issuance of Certificate The Issuing-OCA is responsible for such notification Certificate Acceptance Conduct Constituting Certificate Acceptance The Issuing-OCA shall ensure that the authorised Subscriber during application for, or delivery of a Certificate, is provided with the details of terms and conditions stipulated in the governing Certificate Policy, associated Subscriber Agreement and any other applicable contractual commitments The Subscriber agrees to the terms and conditions stipulated in the Certificate Policy and associated Subscriber Agreement and any other applicable contractual commitments prior to first use of the Certificate. The mechanism for acknowledgement process must be determined by the SMKI Contractor The Issuing-OCA shall clearly inform the authorised Subscriber that by accepting a Certificate issued under the Certificate Policy, an authorised Subscriber agrees to the conditions as laid out in the Subscriber Agreement The above stipulations may be integrated with the Certificate application process Publication of the Certificate by the Issuing-OCA The Issuing-OCA must publish the Issued Certificate to the approved Repository at the location specified in the Certificate Policy. V1.2 18

19 Further publication of the Certificate is permitted. Details of approved Repositories shall be provided in the PKI Disclosure Statement Notification of Certificate Issuance by the Issuing-OCA to Other Entities The Issuing-OCA shall inform the authorised requester immediately that the Certificate has been created. The newly created Certificate shall be sent to the authorised requester in a format to be agreed, and also publish the Certificate to the approved Repository Key Pair and Certificate Usage Subscriber Private Key and Certificate Usage Subscribers must ensure that use of the Private Key associated with the Certificate is consistent with the usage restrictions in the Certificate as stipulated and published in the Subscriber Agreement Relying Party Public Key and Certificate Usage A Relying Party may only rely on a Subscriber s Public Key and the associated Certificate for the specific functions stipulated and published by the OCA in the Relying Party Agreement Guidance shall be given by the SMKI Contractor to Relying Parties, through the Relying Party Agreement or otherwise, regarding the mechanisms by which they shall adhere to their obligations Certificate Renewal Circumstance for Certificate Replacement Certificates may be renewed at any time during their Operational Period. Renewal of Expired, Revoked or Suspended Certificates is not permitted. Replacement Certificate requests may be made where the Issuing-OCA was known to be compromised or the organisation was compromised Certificate replacement requests can only be made by an authorised Subscriber using the centrally provided RA System A replacement Certificate may be issued for the same organisation subject to the checks defined in section Certificate replacement requests for OCAs can only be made by trusted RA personnel operating within the Organisation SMKI. Policies and procedures for OCA Certificate renewals must be published and approved by the PMA Who May Request a Replacement Certificate? Replacement of End Entity Certificate applications may be made by: V An authorised Subscriber through the centrally provided RA System. An authorised RA Agent within the Organisation SMKI Processing Replacement Certificate Requests The authorised SMKI RA Agent will either approve or reject an application for a replacement Certificate Replacement Certificates must be automatically processed by the Issuing-

20 CA in response to a properly constructed and signed Certificate request from the relevant authorised SMKI RA Agent Notification of Replacement Certificate Issuance to Subscriber As specified in Section Conduct Constituting Acceptance of a Replacement Certificate As specified in Section Publication of the replacement Certificate by the IA As specified in Section Notification of Certificate Issuance by the IA to Other Entities As specified in Section Certificate Re-Key Circumstance for Certificate Re-Key Re-Key of Certificates is not permitted at any time during their operational period. Changes must be enacted via Issuance of a new Certificate following one of the approved processes specified in the Certificate Policy Certificate Modification Circumstance for Certificate modification Modification of existing Certificates is not to be permitted. Changes must be enacted via issuance of a new Certificate following one of the approved processes specified in section Certificate Revocation and Suspension Suspension of Certificates is not supported Certificate Status services shall identify all Revoked; at least until their assigned validity period expires Upon Revocation of a Subscriber s Certificate, the Issuing-OCA shall undertake to inform the relevant authorised Subscriber through the centrally provided RA System or other approved mechanism If a Certificate has been compromised, is reasonably suspected to be compromised, or potentially compromised, the Certificate shall be immediately revoked 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 A Certificate must be revoked: upon suspected or known compromise of the media holding the Private Key associated with the Certificate when the Subscriber (Subject) withdraws from or is no longer eligible to participate in SMKI governed by the Certificate Policy known compromise of the Private Key due to theft, loss, V1.2 20

21 disclosure, modification or other compromise associated with the Certificate any misuse of keys and Certificates known compromise of the media holding the Private Key information contained in the Certificate changes a change in role such that the Certificate is no longer valid or authorised the determination by the OCA or RA that the Certificate was not properly issued in accordance with the Certificate Policy it becomes apparent that any of the information submitted during registration is false the device to which an end-entity Certificate relates is taken out of service, sent for repair or disposed of a merger or a takeover of the OCA, RA or Subscriber The SMKI Registration Authority Agent may Revoke a Certificate when an Entity fails to comply with obligations set out in the Certificate Policy, any additional published documents defining practices to be followed by the entity, any other relevant agreement or any applicable law The SMKI Contractor must specify revocation procedures in their Registration Authority Policy and Procedures Revocation procedures must be able to be enacted through the centrally provided RA System by an authorised Subscriber where applicable Who can request revocation The Revocation of an end entity Certificate may only be requested by an authorised SMKI RA Agent or authorised Subscriber through the online RA System Only the authorised SMKI RA Agent is entitled to request or initiate the revocation of Certificates issued to its own OCAs Revocation requests must present a valid circumstance for Revocation according to Section Approval of a Revocation request may only be granted by: The Certification Authority. The relevant authorised SMKI RA Agent The Subscriber through the centrally provided RA System Procedure for revocation request Revocation must be requested promptly after detection of a compromise or any other event giving cause for Revocation A Revocation request may be generated in the following ways, in order of preference: i. Electronically by an authorised Subscriber using the centrally provided RA System (ideally by a digitally signed message). ii. By personal representation to the Certification Authority or the SMKI Registration Authority. V1.2 21

22 iii. By a signed fax message. iv. Electronically by a non-signed message. v. By telephone call to the Certification Authority or SMKI Registration Authority. vi. A Sub-OCA can revoke an SMKI RA or End-entity Certificate at its discretion (The SMKI Contractor must specify this process in their Registration Authority Policy and Procedures.). vii. The PMA may revoke any Certificate at its discretion if the Sub- OCA, SMKI RA or Subscriber does not comply with the Certificate Policy (The SMKI Contractor must specify this process in their Registration Authority Policy and Procedures.) Certificate Revocation requests will be received by the OCA which must:- Conduct authentication of the requestor. Validate the reason for the request. Ensure sufficient information to uniquely identify the Certificate which is the subject of the request Certificate Revocations must be automatically processed by the Issuing- OCA in response to a Revocation instruction from the relevant authorised SMKI RA Agent Revocation requests must be authenticated, accountable to an individual and auditable Revocation request grace period There is no grace period for revocation requests. If the Revocation request is approved, it must be reflected in the next scheduled publication of Certificate Status Time within which OCA must process the revocation request The time to process a Certificate Revocation request is made up of two elements: The time for the Certificate Revocation request to be validated, approved and action taken by the authorised SMKI RA Agent. This time is not constrained but the authorised SMKI RA Agent must take all reasonable steps to conduct the Revocation procedure expeditiously. The time taken for the Issuing-OCA to respond to the authorised Certificate Revocation request. The OCA must process authorised revocation requests in accordance with the Performance Measure set out in Schedule CRL issuance frequency (if applicable) The frequency of issuance for the CRL that relates to Issuing-OCA Certificates (ARL) by the Root OCA shall be every 12 months, or whenever an OCA Certificate is revoked The frequency of issuance for the CRL that relates to End-entities Certificates by the Issuing-OCA shall be every 12hrs with the next update or validity period set to 24hrs. V1.2 22

23 CRLs shall be issued, even if there is no change to the Certificate status information 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 If a revoked Certificate expires, it may be removed from subsequent versions of the CRL Issuing-OCAs shall make CRLs accessible to Relying Parties through the approved Repository. The required availability level is 99.95% Maximum latency for CRLs (if applicable) The maximum latency between the creation and publication of a CRL that contains revocation information relating to End-entity certificates is one hour The maximum latency between the creation and publication of a CRL that only contains revocation information relating to Sub-OCA certificates is four hours Centrally provided revocation/status checking availability The service will not support centrally provided revocation/status checking Centrally provided revocation checking requirements The service will not support centrally provided revocation/status checking Other forms of revocation advertisements available 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 Other forms of revocation advertisements may be used provided the following requirements are met: the procedures shall be fully described in the CPS; the method shall provide authentication and integrity services to the same level as provided by the CRL; and the same time constraints apply as for the CRL The availability of other forms of Revocation advertisement must be published by the Issuing OCA in the PKI Disclosure Statement and approved by the PMA Special requirements in event of key compromise In the event of the compromise, or suspected compromise, of any Entity s Private Key, an authorised Subscriber must notify the SMKI RA or V1.2 23

24 OCA immediately and must indicate the nature and circumstances of the compromise, to the fullest extent known If an OCA key is compromised, or is suspected of compromise, the OCA must immediately notify the PMA and all parties to which it has issued Certificates An OCA must ensure that its CPS contains provisions outlining the means it will use to provide notice of compromise or suspected compromise Certificate Status Services Operational characteristics Where applicable, the types of Certificate Status checking services made available to the Subscriber by the Repository must be defined in the PKI Disclosure Statement Service availability 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 accept the Certificate unless it has been explicitly authorised by the PMA to be able to make an informed decision as to whether to accept or reject the Certificate The availability of any Certificate Status checking services that are available to Relying Parties must be published in the PKI Disclosure Statement Optional features The optional features of any Certificate Status checking services that are available to the Relying Parties must be published in the PKI Disclosure Statement End of Subscription If a Subscriber or Subject wishes to terminate subscription, a termination request should be submitted to OCA. The online RA System must support such requests from an authorised Subscriber On termination of subscription, all certificates relating to that Subscriber or Subject shall be revoked in accordance with Section Key Escrow and Recovery Key Escrow and Recovery Policy and Practices The service shall not offer or support any form of key escrow in accordance with the CP Session key encapsulation and recovery policy and practices The Issuing-OCA must not offer or support any form of session key encapsulation. Certificates, CRL and OCSP Profiles V1.2 24

25 4.42 Certificate Profile Certificate Profiles are under the direct control of the Policy Management Authority. These are as detailed in Appendix B 4.43 Version Number(s) Only Certificates conformant to X.509 Version 3 (value number 2) and IETF RFC 5759 and 5280 may be issued Certificate Extensions All End Entity PKI software must correctly process the extensions identified in sections and of the IETF RFC 5280 Certificate Profile Specification See Appendix B for details of Certificate Profiles The CPS must define the use of any extensions supported by the OCA, its RA and End-entities Algorithm Object Identifiers The supported algorithms and key sizes are identified in section 4.6.The Object Identifiers to represent these algorithms and key size choices are: Signatures: Keys: ECDSA-256 and SHA-256: ecdsa-with-sha Name Forms ECDSA-256: key: id-ecpublickey , curve: ansix9p256r The use of all name forms shall be consistent with Appendix B of this document. Any other Name forms must be approved by the PMA Name Constraints As detailed in Appendix B Certificate Policy Object Identifier The Certificate Policy OID as defined in the PKI Disclosure Statement or the Certificate Policy must be included in the certificatepolicies extension of all Certificates issued under the Certificate Policy Usage of Policy Constraints Extension Out of scope 4.50 Policy Qualifiers Syntax and Semantics Out of scope V1.2 25

26 4.51 Processing Semantics for the Critical Certificate Policies Extension Critical extensions shall be interpreted as defined in PKIX RFC CRL Profile This section defines the key elements of the profiles that are fully defined in Appendix B and Section Version number(s) The version number shall be v2 (value number 1), as defined in RFC5759/RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Only Certificate Revocation Lists conforming to this may be issued CRL and CRL entry extensions The CRL profile, including the use of CRL extensions, to be used by a OCA shall be approved by the PMA prior to the issuance of any Certificates 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 OCA, its RAs and end-entities Certification Authorities shall define and populate the following CRL fields and extensions for all CRLs generated: a) nextupdate ; and b) reasoncode OCSP Profile Version number(s) No OCSP profile is required OCSP extensions No OCSP profile is required. Devices SMKI: Service Definitions and Requirements 4.54 Devices SMKI General Service Definitions The Devices SMKI shall be a hierarchy with a depth of 2 levels. At the top level, the Devices SMKI shall have one Root Device Certificate Authority (Root DCA) The Root DCA will be held offline The Root DCA will only issue Certificates for sub-ordinate Issuing Device Certificate Authorities (Issuing-DCA). The Root DCA will not issue Certificates to devices The Root DCA issues Issuing-DCA Certificates based on Certificate Policy. V1.2 26

27 The Root DCA and Issuing-DCA will be based on X.509 v3 Certificates as defined in [RFC 5759 and RFC5280], which by specification are encoded using the ASN1 Distinguished Encoding Rules. There are no constraints to consider here and best practices should be used The Issuing-DCA issues Device Certificates Certificate to devices based on Certificate Policy. The Device Certificate profile will be as defined in Appendix B All Certificate will be will be based on a lightweight X.509v3 Certificate as defined in [RFC 5759 and RFC5280], which by specification are encoded using the ASN1 Distinguished Encoding Rules Device Certificate Lifecycles Certificates within the Device SMKI have an indefinite lifetime this includes the Root DCA In order to support the standard X.509 Certificate format as defined in [RFC 5280]; a Certificate/Device Certificate expiry time is specified. The GeneralizedTime value Z should be used for this purpose see [RFC 5280]. This means the Device Certificate expiry time will be indefinite Root-DCA and Issuing-DCA Certificates may be retired and subsequently replaced when circumstances dictate. In such cases where applicable, the retired Certificate and its associated private key SHALL no longer be used for issuing Certificates for Issuing-DCAs, or Device Certificates for smart metering devices. However, it is not considered revoked for the purpose of validation of Device Certificates An Issuing-DCA Certificate shall not be re-issued (e.g., re-signed with the same subjectname and public key, but with a new validity period). Instead, if it is desired to retire an existing key/certificate, a new key pair shall be generated and bound into a new Issuing-DCA Certificate generally with a new serialnumber component of the subjectname. Operationally, the responsible Issuing-DCA shall verifiably 3 destroy the private key of the retired Certificate. Retired Certificates MUST remain available to verify any Certificates issued under the retired Issuing-DCA. A replacement of an Issuing-DCA should use a new name Due to the high number of end entity Device Certificates for smart metering devices, the service shall not run a Certificate status management service. Specifically, no Issuing-DCA or Root-DCA shall issue or be required to issue CRLs and no Issuing-DCA shall operate or have operated on their behalf any form of Certificate status management service for the purpose of providing validity information for any Certificate under the Device SMKI hierarchy. 3 The process for destroying private keys is a business issue that should be covered by any contract for SMKI services. V1.2 27

28 The lifetime of an Issuing-DCA will either be time or volume limited (number of Device Certificates issued). At which point, where the time limit or volume is reached (whichever comes first), the Issuing-DCA will be destroyed and a new Issuing-DCA stood up. See Section 4.61 for more details Device Certificate Lifetime [NIST SP800-57] treats the question of the expected lifetime of various cryptographic algorithm choices and key lengths. For the purpose of this document, the Organisation Certificate uses a choice of NSA Suite B cryptographic algorithms and key lengths that currently have no end-use date i.e. the cryptographic strength is adequate for the foreseeable future 4.57 Device Certificate Validity A Device Certificate issued by the Issuing-DCA is considered valid indefinitely The Issuing-DCA will need to support multiple Certificate requests for a Device over the course of its lifetime where circumstances dictate For single ad-hoc Certificate requests, the Issuing-DCA will need to inform the authorised RA Agent if it has seen a request for that Device before, either from the same authorised RA Agent or a different one For batch requests the Issuing-DCA will need to log where it has seen a request for that device before and make the log available to the authorised RA Agent through the centrally provided RA System or service request In all cases, if a Device already has a Certificate issued, the Issuing-DCA must validate with the authorised RA Agent that a new Device Certificate is required, where two requests for the same device have already been processed before prior to proceeding Previous Certificate will not be revoked. It is the responsibility of the requester to associate the Device with the new Certificate (manage the status) and retire the old Certificate through alternative mechanisms General Restrictions and Conditions In addition, DCA Certificates have the following restrictions: The only permitted public key type for Certificates in the Devices SMKI is an Elliptic Curve (EC) public key on the NIST P-256 curve. That public key MUST contain an elliptic curve point in uncompressed form. See [RFC 5480] Section 2.2 for details on the uncompressed form The signature method for signatures formed by EC P-256 private keys MUST be SHA256 with ECDSA. The structure for ECDSA signatures is as per [RFC 5480]. V1.2 28

29 Per [RFC 5280], Root DCAs and Issuing-DCAs MUST ensure the uniqueness of the serial numbers on the Certificates they issue. Root DCAs or Issuing-DCAs should use the mechanism for serial number generation as defined in the GB Companion Specification. Certificate serial numbers are generated according to Best Practice and ensure uniqueness. Current draft of GB Companion Specification doesn't define mechanism for serial number generation Per [RFC 5280], the IssuerName of any Device Certificate MUST be identical to the signer's SubjectName In all cases, the DCC will be named as the Issuer. Therefore, the Issuer Field of a Device Certificate must be populated with the following values (as a minimum): O=DCC, OU=GBSM this is to identify Certificates issued under the SMKI Devices SMKI Overview The Device Certificates are intended for use in supporting the messaging for Smart Metering systems and are currently limited to the authentication, integrity, non-repudiation, and encryption of Smart Metering message communications. The Devices Certificate Policy (CP) defines the community, usage and security requirements associated with the digital Certificates and Device Certificates The CP is a fundamental part of the compliance process. The SMKI Contractor providing SMKI Trust Services to SEC Parties MUST produce a Certificate Practice Statement (CPS) which complies with the obligations contained in the Devices SMKI Base Certificate Policy as published by the PMA The CP states the minimum requirements necessary to support trust in secure messaging and authentication, and details the minimum standards required. Individual Device Certificate Authorities (DCAs) may exceed the specifications of the Certificate Policy The SMKI Contractor must produce a PKI Disclosure Statement (PDS) as per [RFC 3647] and this must be published. (Note: this document may be omitted if the SMKI Contractor can fully justify reasons for doing so) The PDS serves as the highest-level vehicle by which provisions affecting Subscribers and Relying Parties are defined. (Note: this document may be omitted if the SMKI Contractor can fully justify reasons for doing so) DCC will be the Certificate Authority and therefore DCC will be the name in the Issuer field of all Device Certificates. It is the only entity with which End-Entities have any form of direct or indirect contractual relationship Devices SMKI Participants Typically, the roles that need to be undertaken in the Devices SMKI are as follows: SMKI Contractor o Device Certificate Authorities (comprising of): V1.2 29

30 o Root DCA Device Certificate Authority Registration Authority (or Registrar) DCC o Provision of personnel to operate the Registration Authority capability delivered and maintained by the SMKI Contractor. This will encompass as a minimum: Approving CSR s prior to onward processing by the Organisation/Device Certificate Authorities. Resolving CSR errors. Repository (local use only) End Entities Subscriber Subject Relying Party 4.61 Smart Metering Devices SMKI Certificate Authorities The Issuing-DCA is the entity listed in the Issuer field of a Certificate RFC 3647 defines Certification Authorities as the entities that Issue Certificates. For the purpose of this document a Certificate Authority will adopt the same definition The Devices SMKI Certificate Authority for secure messaging will consist of a single hierarchy with a single trusted root Certificate At the top of the hierarchy is the Root DCA. The Root DCA will be managed, operated and coordinated by the SMKI Contractor To support the SMIP in delivering the Root BA capability, the SMKI Contractor shall provide the cryptographic trust in the delivery of the Root DCA It must be possible to form a validation path from all Device Certificates up to the Root Certificate At the second layer of the hierarchy are Issuing-DCAs which issue Certificates to devices. The Devices SMKI hierarchy SHALL only have 2 layers, to allow relying parties to perform full Certificate chain verification with minimum effort. This means that further subordinate Issuing-DCAs shall not be created All Issuing-DCAs will be authorised by the Root Certificate Authority. The Root Certificate Authority will be an offline authority that signs the Public Key Certificate for Issuing-DCAs. V1.2 30

31 Operation of a Root DCA and Issuing-DCAs is subject to approval by the PMA and is conditional on successful completion of the PMA compliance process (see section ) The DCC requires the SMKI Contractor to operate the Root DCA and all Issuing-DCAs on its behalf The Root Certificate Authority shall be compliant with [RFC5759 and RFC5280], accredited and compliant with the CP and relevant Certificate profiles before Live Data is used in the Service, and for the life of the Service once compliance has been achieved The Issuing-DCA shall be compliant with [RFC5759 and RFC5280], accredited and compliant with the CP and relevant Certificate profiles, before Live Data is used in the Service, and for the life of the Service once compliance has been achieved An online RA system for Subscribers/Subjects to submit Device Certificate requests must be made available and shall be documented and published. Access to the online RA system should only be via strong 2- factor authentication Initial identity verification for authorised users of the RA system should be as defined in section The binding of a Device s public key to its identity (the original assertion that a Device and its Public Key are correct) will be attested by a Issuing-DCA, acting in a capacity equivalent to a Issuing-OCA for Organisation Certificates The Issuing-DCA will with the exception of Certificate and Device Certificate status management operate to industry-standard PKI components, methods and good practice, which can be provided by commercial providers as both technology and service components Due to the fact that there is no Certificate or Device Certificate status management i.e. they will not be revoked, or their status published for relying parties, a high degree of trust will be placed in the Issuing Device Certificate Authorities. If a DCA is compromised, or subsequently found to have been compromised, any Certificates issued by that Issuing-DCA will not be revoked. Therefore, to limit the impact of the compromise of an Issuing-DCA, the number of Certificates that can be issued by a single Issuing-DCA will be limited by volume or time whichever limit is reached first No single Issuing-DCA shall be operational (i.e. able to issue Certificates) for longer than the allowed operational Time Period of an Issuing-DCA, as advised by the Certificate Policy or the Policy Management Authority. This shall be the Maximum Operational Time Period No single Issuing-DCA shall issue Certificates for more than the number of Devices advised by the Certificate Policy or the Policy Management Authority. This shall be the Maximum Issue Volume When the Maximum Operational Time Period or Maximum Issue Volume is close to being reached, the Policy Management Authority will V1.2 31

32 need to be informed, prior to the Issuing-DCA being terminated. The process for informing the Policy Management Authority will be designed as part of this Service, and shall be subject to approval by the Policy Management Authority The Maximum Issue Volume for the number of Device Certificates issued by any single Issuing-DCA is 100, The Maximum Operational Time Period any single Issuing-DCA may be operational for is 3 months from when it first comes on-line and operational Once that volume or time period is reached, the Device Certificate Authority s existing private keying material will be destroyed to an auditable standard and new keying material created for the next Issuing- DCA. However, parties will continue to rely upon the old Issuing-DCA public key Certificates for validating i.e. these MUST not be revoked or time limited The precise profile for the number and duration of Issuing Device Certification Authorities will need to be designed based upon the deployment profile during initial rollout and steady state, but should be able to manage peak demand during rollout. See Appendix C for volumes Where a SMKI Contractor chooses to use a contractor to provide certification services e.g. a Certificate manufacturer, the SMKI Contractor organisation itself remains responsible and accountable to the Policy Management Authority and to any Relying Party for its operation. The scope of contracted out services must be approved by the PMA With respect to the SMKI Contractor s delivery model, the PMA has overall and final control over compliance with the CP, accreditation approval, and related documentation Registration Authority (or Registrar) Service Definitions An entity that is responsible for identification and authentication of Device Certificate Authorities, Subscribers and Device Certificate subjects, but that does not sign or issue Certificates or Device Certificate (i.e. a Registration Authority is delegated certain tasks on behalf of an authorised DCA) Further details of the RA Service Definition and Requirements can be found in Section Subscribers A Subscriber is an End-Entity organisation that has applied for, and received a Device Certificate for use in Smart Metering under the SMKI Certificate Policy It is the Subscriber that contracts with the Issuing-DCA for the Issuance of Device Certificates The Subscriber bears responsibility for the use of the Private Key associated with the Device Certificate. V1.2 32

33 It is the Subscriber that agrees to the terms and conditions as defined in the Subscriber Agreement (this may also be on behalf of the subject) Smart Metering Devices SMKI Certificate Authorities As a Certificate is issued for a Device, who does not directly contract with the Issuing-DCA, the Subscriber will accept the terms and conditions on behalf of the Subject that is identified in the Certificate in the SubjectAlternativeName field The Subject will be under the jurisdiction and control of the Subscriber and will comply with all relevant aspects of the CP and other agreements and obligations undertaken by the Subscriber In all cases the Subscriber is responsible for compliance with the CP and all other obligations applicable to it and the Subject Relying Parties A Relying Party is an End-Entity that does not necessarily hold a Device Certificate but even so, may rely on a Certificate and/or Digital Signatures/Derived symmetric keys created using that Certificate. The Relying Party is responsible for deciding whether or how to check the validity of the certificate by checking the appropriate device status mechanism out with of the SMKI service Eligible Relying-Parties for Certificates Issued by the Issuing-DCA under the CP are DCC and DCC Users Other Participants Policy Management Authority The Policy Management Authority has ultimate responsibility for governance and control over the Issuance, management and usage of Device Certificates Issued under the CP. Simply stated, the Policy Management Authority is the entity that sets the rules under which the Devices SMKI is to be operated These details should be identified in the PKI Disclosure Statement to be delivered by the SMKI Contractor. (Note: this document may be omitted if the SMKI Contractor can fully justify reasons for doing so) Repository See section Device Certificate Usage Device Certificate usage is defined by the Profile as detailed in Appendix B Appropriate Device Certificate Uses Device Certificates are permitted for use only in respect of services operated by DCC in support of end to end transactions between DCC, DCC V1.2 33

34 Service Users and smart metering devices Appropriate Device Certificate uses will be detailed in the Certificate Policy and these must be adhered to Prohibited Device Certificate Uses All other application use and any other usage categories for Device Certificates Issued under the Certificate Policy are not permitted Policy administration Smart DCC require that the SMKI Contractor accept that the Policy Management Authority is responsible for approving rights, obligations, liabilities and all other terms and conditions contained in the CP The DCC shall contact the SMKI Contractor regarding the contents of the CP Contact details of the Device Certificate Authority must be published; these shall be made available in the PKI Disclosure Statement. (Note: this document may be omitted if the SMKI Contractor can fully justify reasons for doing so) Person(s) Determining CPS Suitability for the Policy The Policy Management Authority determines the suitability of any Certification Practice Statement operating under the CP DCA and CPS Approval Procedures The Policy Management Authority determines the suitability and approves the use of any Certification Practice Statement which is used to support the CP Definitions and Acronyms Definitions of the terms used in this document are detailed in the Glossary of Terms which may be found in Appendix A. Publication and Repository Responsibilities 4.74 Repositories The Issuing-DCA will use the approved Repository provided by the DSP The Issuing-DCA is the entity with overall responsibility for publishing Certificates and other Certificate for SMKI participants (as detailed in section 4.75 to the approved repository as detailed in section ) V1.2 34

35 4.75 Publication of Device Certificate The Issuing Authority shall ensure the following items are published for all Participants of this SMKI via the approved Repository: The Device Certificate The Certificate Policy with its associated PKI Disclosure Statement. Any supporting policy documents and agreements. The that will allow the authenticity of the Device Certificate(s) of the Issuing-DCA to be verified. Root DCA Public Key Certificate All DCA-Certificates of Issuing-DCAs issued by the Root-DCA Time or frequency of publication as listed in section 4.75 shall be published in accordance with the Performance Measure set out in Schedule 2.2 Identification and Authentication 4.76 Naming Types of names For Root DCA and IssuingDCA Certificates, each Subject must have a clearly distinguishable and globally unique X.501 Distinguished Name (DN) in the Certificate subjectname field of Certificates issued under the Certificate Policy and in accordance with [RFC5759 and 5280]. Where the Certificates do not conform, then the Certificate requests must be rejected The SubjectName field of the Certificate must be empty as the X.500 name form is not well suited to describe or identify physical serialized devices. The device identity must be contained in the SubjectAlternativeName extension which shall contain a single GeneralName of type OtherName that is further sub-typed as a HardwareModuleName (id-on- HardwareModuleName) as defined in [RFC 4108]. The hwserialnum field shall be set to the Device s Entity Identifier. This extension MUST be marked critical when the SubjectName field is empty See Appendix B for more details Anonymity or pseudonymity of subscribers is not permitted The rules for interpreting name forms must match those as defined in the Certificate profile in Appendix B. Any non-prescribed name forms must be rejected. V1.2 35

36 Distinguished names must be unique for Issuing-DCAs and hwserialnum must be unique for all Subjects under the jurisdiction of the Issuing-DCAs Recognition, Authentication and Role of Trademarks. The Issuing-DCA is not liable for the inclusion of trademarks, trade names or other information under restricted use. Subscriber Agreements shall require Subscribers to warrant legitimacy of their registration details provided to the Issuing-DCA as part of the Registration Process Initial Identity Validation Method to Prove Possession of Private Key See section Authentication of Organisation Identity (for System to System Device Certificate requests) See section Authentication of Individual Identity (including Device) See section Non-verified Subscriber See section Validation of Authority See section Criteria for Interoperation There is no requirement for interoperation Identification and Authentication for Re-Key Requests Identification and Authentication for Routine Re-Key Re-key of Device Certificates is governed by the Certificate Policy and is not permitted. Changes must be enacted via Issuance of a new Certificates following one of the approved processes specified in Registration Policies and Procedures document published by the DCA Identification and authentication for re-key after revocation Not applicable for Device Certificates Identification and Authentication for Revocation Requests Not applicable for Device Certificates Certificate Life-Cycle Operational Requirements The following types of Certificate can be applied for according to the Certificate Policy: 1) SMKI RA Certificates; 2) End-entity Device Certificates; 3) Issuing-DCA Certificates generated by Root. V1.2 36

37 All the above Certificates relate to organisational systems, devices, and individuals (RA Agents) All Certificate applicants must comply with the procedures described as laid out by the DCA in its Registration Authority Policy and Procedures Eligible Subscribers must be specified in the PKI Disclosure Statement An application for a Certificate does not oblige an Issuing-DCA to issue a Certificate. The DCA must ensure all criteria for Certificate requests are fulfilled. All procedures for Certificate application shall be documented in the CPS Device Certificate Application Who Can Submit a Device Certificate Application Certificate applications may only be made by authorised Subscribers through the online RA System or by Authorised Systems (trusted system to system Certificate requests) Certificate applicants must comply with the procedures described as laid out by the DCA in its Registration Authority Policy and Procedures Eligible Subscribers must be specified in the PKI Disclosure Statement An application for a Certificate does not oblige an Issuing-DCA to Issue a Certificate. The Issuing-DCA must ensure all criteria for Certificate requests are fulfilled. All procedures for Certificate applications shall be documented by the Issuing-DCA in its Registration Authority Policy and Procedures Certificate Application (Issuing-DCAs and Authorised Systems) Who Can Submit a Certificate Application Issuing-DCA Certificate applications may only be made by: Authorised SMKI RA Agents operating within the DCA (using internal RA systems and processes) Authorised System Certificate applications may only be made by: Authorised Subscribers through the on-line RA System Enrolment Process and Responsibilities The SMKI Contractor must operate enrolment processes for DCAs and RAs operating within their domain before issuing any Certificates. The specific enrolment processes must be defined in its Registration Policy and Procedures. See section for more detail The SMKI Contractor must operate the enrolment processes for End Entities as described in section before issuing any Device Certificates. V1.2 37

38 4.84 Registration Authorities and Their Representatives A Registration Authority is an entity that is responsible for identification and authentication of Device Certificate Authorities, Subscribers and Device Certificate subjects, but that does not sign or issue Certificates (i.e. a Registration Authority is delegated certain tasks on behalf of an authorised DCA) Registration Authority Policies and Procedures The SMKI Contractor must produce and publish the Registration Authority Policy and Procedures document that needs to be approved by the DCC and the PMA. This document needs to include the following as a minimum: Identification and authentication processes Enrolment processes and responsibilities SMKI RA processes Subscriber Certificate and Device Certificate request processes 4.85 Device Certificate Application Processing Performing Identification and Authentication Functions The SMKI Registration Authority Agent (DCC Staff trained by the SMKI Contractor) is permitted to conduct authentication of Device Certificate requesters from authorised Subscribers and requests from authorised Subscribers for Authorised Systems (trusted system to system Device Certificate requests) Approval or Rejection of Device Certificate Applications The SMKI Registration Authority (DCC Staff trained by the SMKI Contractor) will either approve or reject a Device Certificate application Where an application fails to achieve the specified criteria (properly constructed, signed and validated request), or the authentication requirements or the level of assurance of authentication cannot be met for an authorised Subscriber or Authorised Systems (trusted system to system Certificate requests), a Certificate application must be rejected Where a Device Certificate application is rejected, the reasons for rejection may be given to the prospective applicant in accordance with the Issuing- DCA Registration Policy and Procedures Time to Process Device Certificate Applications See Appendix C Device Certificate Issuance Issuing-DCA Actions during Device Certificate Issuance Certificates shall be issued automatically by the Issuing-DCA only in V1.2 38

39 response to a properly constructed and validated Device Certificate request from the relevant approved Subscriber or Authorised Systems (trusted system to system Certificate requests). Only the centrally provided online RA System or Authorised Systems (trusted system to system Certificate requests) provided under the Trust Service can communicate with the associated SMKI RA Agent to submit Certificate requests Notification to Subscriber by the Issuing-DCA of Issuance of Device Certificate The Issuing-DCA is responsible for such notification. Notification for all Device Certificate requests shall be made through the centrally provided RA System Device Certificate Acceptance Conduct Constituting Device Certificate Acceptance An authorised Subscriber shall explicitly indicate acceptance of a Certificate to the SMKI Registration Authority Agent. This must be through a mechanism for confirming acceptance through the centrally provided RA System Collection of a Device Certificate via on line authentication to the central RA System by the authorised Subscriber may also constitute acceptance of the Certificate The Issuing-DCA or SMKI RA shall ensure that the authorised Subscriber during application for or delivery of a Certificate is provided with the details of terms and conditions stipulated in the governing Certificate Policy, associated Subscriber Agreement and any other applicable contractual commitments The authorised Subscriber must acknowledge that it agrees to the terms and conditions stipulated in the Certificate policy and associated Subscriber Agreement and any other applicable contractual commitments prior to first use of the Device Certificate. The mechanism for acknowledgement process must be through the online RA System The Issuing-DCA or SMKI RA shall clearly inform the authorised Subscriber that by accepting a Certificate issued under the Certificate Policy, they agree to, and certify, that at the time of Certificate acceptance and throughout the operational period of the Certificate the authorised Subscriber has adhered to the terms and conditions as defined in the Subscriber Agreement The above stipulations may be integrated with the Certificate application process Publication of the Device Certificate by the Issuing-DCA The Issuing-DCA must place the Issued Certificate into the approved V1.2 39

40 Repository at the location specified in the Certificate Policy Further publication of the Certificate is permitted. Details of approved Repositories shall be provided in the PKI Disclosure Statement. (Note: this document may be omitted if the SMKI Contractor can fully justify reasons for doing so) Notification of Device Certificate Issuance by the Issuing-DCA to Other Entities The Issuing-DCA (or Certificate Manufacturer) does not directly inform any other participants of the Issuance of a Certificate Key Pair and Device Certificate Usage Subscriber Private Key and Device Certificate Usage Subscribers must ensure that use of the Private Key associated with the Certificate is consistent with the usage restrictions in the Certificate as stipulated and published by the Issuing-DCA in the Subscriber Agreement. Relying Party Public Key and Certificate Usage A Relying Party may only rely on a Subscriber s Public Key and the associated Certificate for the specific functions stipulated and published by the Issuing-DCA in the Relying Party Agreement. Guidance shall be given by the Issuing-DCA to Relying Parties, through the Relying Party Agreement or otherwise, regarding the mechanisms by which they shall adhere to their obligations Certificate Renewal Circumstance for Certificate Replacement There is no need to manage renewal of Certificates as they are issued with an indefinite lifetime and they are never revoked Circumstance for Certificate Replacement Replacement Certificate requests may be made where the Issuing-DCA was known to be compromised or the Device or Authorised System was compromised In the event of the compromise, or suspected compromise, of any Entity s Private Key, an Entity must notify the DCA or SMKI RA immediately and must indicate the nature and circumstances of the compromise, to the fullest extent known A replacement Certificate may be issued for the same entity subject to the checks defined in section Who May Request a Replacement Certificate? V1.2 40

41 Replacement Certificate applications may be made by: An authorised Subscriber through the online RA System; Authorised Systems (trusted system to system Certificate requests); or Authorised SMKI RA Agents Processing Replacement Certificate Requests The authorised Registration Authority will either approve or reject an application for a replacement Certificate. Replacement Certificates are automatically processed by the Issuing-DCA or SMKI Registration Authority in response to a properly constructed and signed Certificate request. Notification of Replacement Certificate Issuance to Subscriber As specified in Section Conduct Constituting Acceptance of a Replacement Certificate As specified in Section Publication of the replacement Certificate by the Issuing-DCA As specified in Section Notification of Certificate Issuance by the Issuing-DCA to Other Entities As specified in Section Certificate Re-Key Re-Key of Certificates is not permitted at any time during their operational period. Changes must be enacted via issuance of a new Device certificate following one of the approved processes specified in the Certificate Policy Where a new key pair is generated, a request for a new Certificate must be made Certificate Modification Circumstance for Certificate modification Modification of existing Certificates is not to be permitted. Changes must be enacted via Issuance of a new Certificate following one of the approved processes specified in the Certificate Policy Certificate/ Device Certificate Revocation and Suspension There will be no Certificate Status services in the Devices SMKI. V1.2 41

42 Certificates will not be revoked or suspended Special Requirements in the Event of a Key Compromise In the event of the compromise, or suspected compromise, of any Entity s Private Key, an authorised Subscriber must notify the DCA immediately and must indicate the nature and circumstances of the compromise, to the fullest extent known If a DCA key is compromised, or is suspected of compromise, the DCA must immediately notify the PMA and all parties to which it has issued Certificates A DCA must ensure that its CPS contains provisions outlining the means it will use to provide notice of compromise or suspected compromise Key Escrow and Recovery Key Escrow and Recovery Policy and Practices The service shall not offer or support any form of key escrow in accordance with the CP Session key encapsulation and recovery policy and practices The Issuing-DCA must not offer or support any form of session key encapsulation. Certificate Profiles 4.96 Certificate Profile Certificate Profiles are under the direct control of the Policy Management Authority. These are as detailed in Appendix B Device Certificate Profile Device Certificate Profiles are under the direct control of the Policy Management Authority. These are as detailed in Appendix B Version Number(s) Only Certificates conformant to X.509 Version 3 (value number 2) and IETF RFC 5759 and 5280 may be issued Certificate Extensions V1.2 42

43 All End Entity PKI software must correctly process the extensions identified in sections and of the IETF RFC 5280 Certificate Profile Specification Certificate extensions will be as defined in Appendix B. The CPS must define the use of any extensions supported by the DCA, its RA and Endentities Algorithm Object Identifiers The supported algorithms and key sizes and the Object Identifiers to represent these algorithms and key size choices are: Signatures: ECDSA-256 and SHA-256: ecdsa-with-sha Keys: Name Forms ECDSA-256: key: id-ecpublickey , curve: ansix9p256r The use of all name forms shall be consistent with section 4.76 of this document. Any other Name forms must be approved by the PMA Name Constraints See Appendix B for details Certificate Policy Object Identifier The Certificate Policy OID as defined in the Certificate Policy must be included in the CertificatePolicies extension of all Certificates Issued under the Certificate Policy Usage of Policy Constraints Extension The policy constraints extension must not be used in any Certificates issued Policy Qualifiers Syntax and Semantics See Appendix B for details Processing Semantics for the Critical Certificate Polices Extension See Appendix B for details. Common Security Requirements and Service Definitions V1.2 43

44 The following sections detail the security requirements and service definitions that are common to the Devices SMKI and the Organisation SMKI Volume and Performance The SMKI Contractor Systems shall deliver services that comply with the service level requirements as defined in Appendix C: Volume and Performance. The SMKI Contractor Systems shall provide the capacity throughput expressed in Appendix C: Volume and Performance. The SMKI Contractor shall maintain the capacity throughput specified in Appendix C: Volume and Performance. The SMKI Contractor shall publish the Service Performance as described in sections Appendix C: Volume and Performance will be carried out at a frequency to be determined during the Design Stage. The SMKI Contractor Systems shall meet the Service Availability defined in Appendix C: Volume and Performance. The SMKI Contractor Systems shall meet the Disaster Recovery Capabilities stated in Section Interfaces Definition The SMKI Contractor must support standard interfaces based on PKIX/IETF/PKCS open standards. The SMKI Contractor shall define, develop and publish interface specifications and user interfaces ( Interfaces ) between the Trust Systems and external parties. At each stage, the SMKI Contractor shall provide assurance to the Policy Management Authority of the quality and adherence of the interface to open standards. The SMKI Contractor shall test the Interfaces to provide assurance to the Policy Management Authority that the interfaces meet functional and performance requirements and compliant with the open standards above and the interface specifications published by the SMKI Contractor. The SMKI Contractor shall arrange interoperability testing with the SMKI Parties to provide assurance to the DCC & PMA and SMKI Parties of the interoperability of the Services. It is proposed that DCC will be obliged under SEC to carry out SIT and UIT of the whole SMKI service in conjunction with the SMKI Contractor The SMKI Contractor must provide support to the DCC and DCC Service Providers during the System Integration and User Integration Test Phases. Support will include resolving defects, dealing with queries and SMKI Test environment issues. Devices SMKI The SMKI Contractor shall design, develop, build, test and provision the V1.2 44

45 following Devices SMKI Systems interfaces: On-line RA System for Certificate workflow management, and requests to the Issuing-DCA that is capable of supporting batch requests (of up to 50,000 per single Device Certificate Requests per batch) and single ad-hoc Device Certificate Requests. Organisation SMKI The Contractor shall design, develop, build, test and the following Organisation SMKI Systems interfaces: On-line RA System for Certificate request and revocation workflow management, and requests to the Issuing Certificate Authority (capable of supporting batch and single ad-hoc requests) Test and Development Environments The SMKI Contractor shall test the Services (including Interfaces) and provide assurance to the Policy Management Authority that the Services (including Interfaces) meet functional and performance requirements and compliant with the open standards above and the interface specifications published by the SMKI Contractor. The SMKI Contractor must be able to demonstrate a clear structured Test Assurance process and shall develop and maintain a complete set of Test documentation, including a Test Strategy, Approach and Plan detailing the provision of test assurance that they will be facilitating. The DCC and the PMA shall have the right to reject the Test Strategy, Approach or Plan if it believes that the documented approach will not provide sufficient assurance. Where this is the case, the SMKI Contractor will remedy and resubmit the Test document in question until such assurance is provided. Test Activities shall be carried out on a specific testing environment, separate from the Development and Operational Environments. A dedicated Test environment must be provided for all phases of testing including System, System Integration and User Integration In addition after the conclusion of User Integration Testing, an Enduring Test environment must be provided for BAU testing and facilitating new entrant service user testing. The DCC Test Programme is responsible for the overall test assurance of all DCC Service Provider deliverables, and therefore has to ensure full traceability of test specifications back to requirements and the test evidence captured, in turn must be fully traceable back to the test V1.2 45

46 specifications. The DCC Test Programme must complete a Test Witnessing Stage in addition to the auditing activity. The SMKI Contractor is required to fully comply with the DCC test assurance processes, which include test witnessing and auditing. The SMKI Contractor must be able to evidence full traceability of test specifications back to requirements, and furthermore provide test evidence to prove successful outcomes of each executed test. Witness testing for DCC Test Assurance purposes is carried out during a Factory Acceptance Test (FAT) stage which naturally follows the System Testing stage. The SMKI Contractor must provide the facility for the DCC test team to be able to witness a sample of tests for the purposes of Test Assurance. The SMKI Contractor shall provide at least two test environments to all Subscribers to enable Subscribers to test interoperability of their own systems with the SMKI Contractor Interfaces and Services: 1) A test environment that is representative of the Devices SMKI; and 2) A test environment that is representative of the Organisation SMKI. The SMKI Contractor shall develop and maintain an Interoperability Test Plan detailing how such testing shall be carried out. The DCC and the PMA shall have the right to reject the Test Plan if it believes that the approach will not provide sufficient interoperability assurance to Subscribers. Where this is the case, the SMKI Services Provider will need to agree the remediation plan with the DCC and the PMA. The SMKI Contractor shall not carry out development activities on either the Test environments or the Operational Services Environments described in section There must be clear physical separation between test, development and operational environments. There must be clear physical separation between development, test and operational facilities to achieve segregation of the roles involved. Processes for the transfer of software from development to operational status should be defined and documented and be in accordance with the SMKI Contractor Quality Management System and ISO The SMKI Contractor shall replicate the functionality of all operational interfaces in the test Interfaces. The SMKI Contractor shall not use Test Interfaces on the Operational Environments. V1.2 46

47 Certificates used for test purposes must not be used in any operational services, production operations and vice versa Operational Services and Operational Environments The SMKI Contractor shall provide Operational Services to Subscribers for the purposes of: Live Service Operation of the Smart Metering Service. ( Live Operation ) Operational Testing of the Smart Metering Service ( Operational Testing ). The SMKI Contractor shall ensure that logically and physically separate environments (including processing capacity, network, software and storage) are used for each purpose. The SMKI Contractor shall ensure that Certificates used for Live Operation are not used in Operational Test Service and vice versa. The SMKI Contractor shall develop and maintain separate Certificate Policies for Live Operation and Operational Testing environments. These must be written by the SMKI Contractor (based on the operational Certificate Policy) and approved by the DCC and the PMA Enrolment Process and Responsibilities All Sub-OCA, Sub-DCA, SMKI RA and End-entity Device Certificate Applicants shall undergo a registration process which, prior to Certificate issuance, shall: establish and prove the identity of the Subscriber, and establish the validity of the subject according to the registration procedures described in section require proof of authorisation to have a certificate; require the Subscriber to attest to the accuracy of information submitted in certificate requests; require the Subscriber to read, understand and sign the Subscriber Agreement; submit a signed certificate request to the OCA or DCA using a recognised standard protocol (e.g. PKCS#10), as approved by the PMA; and 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. Where the Applicant is a Sub-OCA or Sub-DCA, the elements of apply, but the request can take the form of a procedural request for the generation of a Sub-OCA key pair or Sub-DCA key pair, and the issuing of a signed public key certificate. V1.2 47

48 All procedures for Certificate application shall be documented in the CPS and the Registration Policy and Procedures document. All requests for End-entity Certificates to a Sub-OCA or Sub-DCA 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. For any Certificates issued to support the operation of the Sub-OCA or Sub-DCA (e.g. to authenticate the actions of an Operator of the Sub- CA), the Sub-)CA or Sub-DCA must verify the identity of the Applicant in the same way as an RA Initial Identity Validation Method to prove possession of Private Key Subscribers must prove to the Issuing-OCA, Issuing-DCA or RA, as part of the registration process, possession of the Private Key corresponding to the Public Key contained in the certificate request. The registration and/or Issuance process shall involve a stage in which the applicant demonstrates possession of the Private Key. Technical means employed to ensure possession of Private Keys, will be PKCS#10, other equivalent cryptographic mechanism or using a process specifically approved by the Issuing Authority. Authentication of Organisation Identity Smart DCC require that each Organisation will require a unique identifier. There will be a globally unique 8 octet Organisation Identifier (EUI64 as defined in GBCS) which uniquely identifies the connecting organisation. The identity of the organisation must be established to a level of substantial assurance. Authentication processes may include face-to-face authentication with a representative of the organisation, or other form of direct registration by representative of the organisation. Where this is the case, both the identity of the representative must be authenticated and their authority to represent the organisation must be validated. Organisational identity may be authenticated via remote means such as public registration provided that the criterion of substantial assurance is satisfied. The central Registration Authority shall define and document the mechanisms used to support the level of authentication assurance and document these in the Registration Policies and Processes for approval by the SMKI PMA. The central Registration Authority shall verify that each Certificate applicant has a right to obtain that Certificate and, if the Certificate identifies that the Subscriber (or Subject) has particular attributes or privileges, that they are valid. V1.2 48

49 Authentication of the identities of individuals The authentication of Registration Authority Operators must at a minimum satisfy the specific criteria for authentication as specified in section Additionally a nominated authorised individual (acting in a position of authority) shall undertake the initial face-to-face authentication of one or more initial Registration Authority Managers. An authenticated and nominated Registration Authority Manager may undertake face-to-face authentication of subsequent Registration Authority Agents. The separation of distinct SMKI personnel roles by named personnel, distinguishing between day-to-day operation of the OCA/DCA/RA systems and the management and audit of those operations. To the greatest extent practicable, differing levels of physical and systems access control based on roles and responsibilities shall be employed to reflect the requirements of those roles and responsibilities. Controls must be detailed in the Certification Practice Statement and/or supporting documentation. All OCA, DCA and SMKI RA personnel must have their identity and authorisation verified to Level 3 (Verified) as detailed in the CESG GPG43 RSDOPS framework (or equivalent framework to be agreed with the PMA) All Subscribers (users) of the online RA system for submission of Certificate requests must have their identity and authorisation verified to Level 3 (Verified) as detailed in the CESG GPG43 RSDOPS framework (or equivalent framework to be agreed with the PMA). Access to the online RA system must be via strong 2-factor authentication. The Registration Authority shall define and document the mechanisms used to support the level of authentication assurance. Authentication of devices Authentication of the identity of a Device is a local responsibility, and shall be verified using appropriate documentation, such as an invoice, warranty, contract, maintenance schedule or information marked on the device itself. The local process shall ensure that: Device Certificates are only issued to genuine devices; and Documented management procedures are in place to manage the private key material. In all cases, it is the responsibility of the authorised Subscriber to verify that the End-entity Subject for which the Certificate is to be issued matches the identity information provided by the requester. The central RA shall verify that the End-entity Subject for which the Certificate is to be issued matches the identity information provided by the Subscriber. V1.2 49

50 The central Registration Authority will accept non-verified subscriber information submitted by a Device Certificate applicant, and included within a Device Certificate that has not been confirmed by the central RA, and for which the applicable central RA provide no assurances to the Issuing-DCA, other than the information was submitted by the eligible applicant and verified by local organisation processes. Non-verified subscriber information Non-verified information may not be included in Certificates. All organisation Certificates must have their information verified with the central Registration Authority. All Certificates issued to individual identities must have their information verified with the central Registration Authority Non-verified information may be included in Device certificate requests Where non-verified information is incorporated in a Device Certificate these sources of information must be detailed in the Registration Policy and Procedures. Validation of authority Validation of authority (i.e. the determination of whether a Subscriber has specific rights, entitlements, or permissions, including the permission to act on behalf of an organisation to obtain a Certificate) is the responsibility of the Registration Authority. Validation procedures shall be conducted as described in the document Registration Policy and Procedures. Details of validation procedures may be published to Participants. When processing the application for an Issuing-OCA or Issuing-DCA certificate, the Registration Authority shall verify that the applicant is an eligible OCA or DCA and has the authority to make a certificate request. When processing the application for a certificate signing request or Device Certificate request, the Issuing-OCA or Issuing-DCA shall verify that the applicant is an eligible Registration Authority, and have the authority to make a certificate request. An application for an RA certificate allowing mutual authentication between the RA system and the Issuing-OCA or Issuing-DCA (M2M) certificates shall be accompanied by at least two written signatures from an appropriately registered individual e.g. RA Manager. This must be defined as part of the compliance process When processing the application for an End-entity Subject Certificate, the RA shall verify that the applicant is an eligible Subscriber Registration Authority SMKI RA Services (OCA and DCA) The SMKI Contractor will need to provide the following SMKI RA facilities (RA within the OCA or DCA facilities): V1.2 50

51 The SMKI Contractor shall provide a system to allow SMKI RA Agents to register with the SMKI RA Service having provided substantial assurance in the proof of their identity prior to the issuance of any Certificates The SMKI Contractor shall provide system to allow SMKI RA Agents to register with the SMKI RA Service and provide substantial assurance in the proof of their identity in line with Level 3 of the HMG Authentication Framework (or equivalent identity and authentication framework) prior to the issuance of any Certificates The SMKI RA function is accountable for actions they perform on behalf of the Issuing-OCA and the Issuing-DCA. To achieve this accountability, the actions performed in pursuance of RA duties and the identity of the person performing them must be recorded in an audit trail (see section 4.120). The audit trail must be securely protected and archived (see section and ) Policies, procedures and practices to support the SMKI RA facility must be produced by the SMKI Contractor. Details of the SMKI RA service will be published to all Subscribers and SMKI RA Agents. These may be placed in the approved Repository, or promulgated via other approved mechanisms. The SMKI RA is responsible for ensuring the eligibility of applicants to be issued with Certificates together with the validation of the accuracy and integrity of required information presented by applicants. The SMKI Contractor is responsible for the vetting, identification and authentication and issuance of credentials for all SMKI RA Agents. The SMKI Contractor is responsible for the issuance and management of credentials for SMKI RA functions to allow secure SMKI RA functions to be carried out RA Services (Subscribers and Subjects) The SMKI Contractor will need to provide the following local RA facilities (systems and processes for Subscribers/Subjects): 1) A centrally provided online RA service for requesters of Certificates (from authorised Subscribers); and 2) The authorised Subscriber is accountable for actions they perform on behalf of the Subject. To achieve this accountability, the actions performed in pursuance of Subscriber RA duties and V1.2 51

52 the identity of the person/organisation performing them must be recorded in an audit trail (see section 4.119). The audit trail must be securely protected and archived (see section and ). The online centrally provided RA System must support strong 2-factor authentication mechanisms for authorised Subscribers. The authorised Subscriber function for application of Certificates and Device Certificates through the online RA System must follow the SMKI RA processes as defined in the Registration Policies and Procedures document. Policies, procedures and practices to support the local RA facility must be produced by the SMKI Contractor. The SMKI Contractor is responsible for the issuance and management of credentials for authorised Subscribers authenticating to the online RA system to allow secure RA functions to be carried out through the online RA System. The SMKI Contractor shall provide facilities to allow RA functions to register for authorised Subscribers with the SMKI RA Service. All local RA functions requesting credentials for local authorised Subscribers must provide to the SMKI RA, substantial assurance in the proof of their identity in line with Level 2 of the HMG Authentication Framework (or equivalent identity and authentication framework) prior to the issuance of any credentials. The SMKI Contractor is responsible for the vetting, identification and authentication for all local authorised Subscribers prior to issuance of any credentials. Where applicable, the SMKI Contractor SMKI RA is responsible for ensuring the eligibility of applicants to be issued with Certificates together with the validation of the accuracy and integrity of required information presented by applicants. The Registration Authority is a delegated function of the Issuing-OCA or Issuing-DCA. It processes and approves requests from applicants for the issue of Certificates or Device Certificates as detailed in the Certificate Policies. The solution may choose not to delegate responsibility to the RA, and the Issuing-OCA or Issuing-DCA may carry out these checks themselves. The SMKI Contractor must publish approved Registration Authorities in the PKI Disclosure Statement with respect to Certificates and Device Certificates governed by the Certificate Policies. (Note: this document may be omitted if the SMKI Contractor can fully justify reasons for doing so). All personal data held by the SMKI RAs relating to the registration operations (e.g., personnel checks, personal identification documentation, Certificate Holder Agreements, etc.) are considered to be sensitive information and must be protected in accordance with the V1.2 52

53 Data Protection Act. All actions undertaken by local authorised Subscribers through the online RA System must be audited and made available upon request. Non-verified Subscriber Non-verified information may be included in Certificates governed by the Certificate Policies. Non-verified subscriber information means any information submitted by a Certificate, and included within a Certificate that has not been confirmed by the OCA/DCA or SMKI RA acting on their behalf, and for which the applicable OCA/DCA and SMKI RA provide no assurances other than the information was submitted by the eligible applicant and verified by local RA processes. Where non-verified information is incorporated in a Certificate these sources of information must be detailed in the Registration Policy and Procedures and approved by the Issuing-OCA or Issuing-DCA. Authentication of the identity of a Device is a local responsibility, and 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: DCA Certificates are only issued to genuine devices; and documented management procedures are in place to manage the private key material; In all cases, it is the responsibility of the local RA agent to verify that the End-entity Subject for which the Device Certificate is to be issued matches the identity information provided by the requester. Validation of Authority Validation of authority (i.e. the determination of whether a Subscriber has specific rights, entitlements, or permissions, including the permission to act on behalf of an organisation to obtain a Certificate or Device Certificate) is the responsibility of the Registration Authorities. Validation procedures must be conducted as described in the Registration Policy and Procedures. Details of validation procedures must be published to Participants Solution Management Where requirements are not stipulated, specific details on controls operated for components of the Devices and Organisation SMKI V1.2 53

54 infrastructure must be detailed in the Certification Practice Statement and/or supporting documentation. The Solution shall meet the cryptographic standards as defined in the SMKI Certificate Policies and the GB Companion Specification Breaches in Security A security incident management process for managing breaches of security and the rectification of those breaches, either by the Contractor, the DCC, DCC Users, or any other Third Party, shall be defined as part of the Service design stage. This process must be submitted to the Policy Management Authority for approval before service go-live. Both the SMKI Contractor and the DCC shall notify the other immediately upon becoming aware of any actual, potential or attempted breach of security (regardless of the cause of such Breach of Security). Such notification shall, where applicable, be made in accordance with the agreed security incident management process. The SMKI Contractor acknowledges and agrees that the DCC is entitled to notify the relevant DCC Service Providers and/or DCC Service Users of any actual, potential or attempted breach of security that may also affect the Systems of such persons. As soon as reasonably practicable (but, in any event, within one hour of the occurrence of the actual, potential or attempted breach of security being detected), the SMKI Contractor shall provide to the DCC a further report setting out all details of the actual, potential or attempted breach of security that are then available to the Contractor (having made all enquiries and analysis that are reasonably practicable within these timescales). Upon becoming aware of any actual, potential or attempted breach of security, the SMKI Contractor shall promptly and without unnecessary delay take all reasonable steps necessary to: a) remedy any actual breach of security or protect the integrity of the Contractor Solution against any potential or attempted breach of security; and b) Prevent an equivalent breach of security (whether actual, potential or attempted) in the future Such steps shall include any action or changes reasonably required by the DCC. V1.2 54

55 4.116 Facility, Management and Operational Control All OCAs or DCAs shall be required to develop a Certification Practice Statement, defining the mechanisms by which it implements the requirements of the applicable Certificate Policy and referencing the detailed operating procedures Physical Controls The CPS will be reviewed as part of the SMKI compliance process for onboarding a SMKI service. The SMKI Contractor shall ensure that all physical locations where the live production OCA and DCA systems and its associated environments are located and operated, routed or directly accessed are located in United Kingdom. The SMKI Contractor shall ensure that the OCA and DCA systems and its associated environments used during the System Integration Phase are located and operated in United Kingdom. The SMKI Contractor shall ensure that all Security Related Functionality is developed and tested within the United Kingdom, where this functionality is a bespoke development for the SMKI Contractor solution. The SMKI Contractor shall ensure that all Security Related Functionality is integrated, configured, tested in situ, implemented, operated and maintained within the United Kingdom. The SMKI Contractor shall ensure all Operators of the OCA and DCA Systems are registered with the SMKI Contractor and there is substantial assurance in the proof of their identity in line with Level 3 of HMG Authentication Framework or equivalent prior to any electronic transaction with that Operator. Site location and construction Sites where Certificate manufacture or time-stamping operations are carried out must: Satisfy at least the requirements specified by the compliance scheme see from section for production and control of Certificates or Device Certificates. Be manually or electronically monitored for unauthorised intrusion at all times. Apply controls such that unescorted access to OCAs, IBAs or timestamping servers is limited to authorised personnel. V1.2 55

56 Ensure unauthorised personnel are properly escorted and supervised. Ensure a site access log is maintained and inspected periodically. Ensure all removable media and paper containing sensitive plain text information is stored in secure containers. Ensure all users are authenticated using strong two-factor authentication Under the applicable Certificate Policy, the detailed functionality of a Registration Authority is simply a data gatherer that assists the OCA and DCA in gathering Registration or Revocation information from applicants, authenticating applicants, and forwarding the results to the OCA/DCA. Where the SMKI Registration Authorities act only as information verifiers/forwarders:- Registration Authority sites must be located in areas that at least satisfy the controls required for the assurance levels for the level of registration and vetting conducted, and at a minimum be compliant with ISO If a Registration Authority is permitted to submit centrally provided requests for Certificate or Device Certificate issuance, the OCA/DCA will ensure the operation of the Registration Authority site provides appropriate security protection of the cryptographic module and the Registration Authority Administrator s Private Key. A security container shall be utilised for storing all security devices and tokens used to gain access to the Registration Authority workstation. Where applicable to the service, all local Repository sites must be located in areas that at a minimum satisfy the requirements for ISO and in addition, must: Ensure unescorted access to the Repository server is limited to authorised personnel. Ensure unauthorised personnel are properly escorted and supervised Ensure a site access log is maintained and inspected periodically Where PINs, pass-phrases or passwords are recorded, they must be stored in a security container accessible only to authorised personnel Physical access OCAs, DCAs and RAs shall implement physical access control to limit access to the systems to the minimum number of personnel required. V1.2 56

57 Access to each tier of physical security shall be auditable and controlled so that each tier can be accessed only by authorised personnel Power and air conditioning The secure facilities for the OCA/ DCA shall be located in accommodation with appropriate power and air conditioning systems. Water exposures The secure facilities of OCAs, DCAs and RAs shall be constructed and equipped, and procedures shall be implemented, to prevent floods, protected against ingress of water or other damaging exposure to water. Fire prevention and protection The secure facilities of OCAs, DCAs and RAs shall be equipped, and procedures shall be implemented, to prevent and extinguish fires or other damaging exposure to flame or smoke. Media storage Controls must be placed on all media used for the storage of information such as keys, activation data, confidential Subscriber information or OCA/DCA/RA information. Controls must be detailed in the Certification Practice Statement and/or supporting documentation. OCAs, DCAs and RAs shall protect the magnetic media holding back ups of critical system data or any other sensitive information from water, fire, or other environmental hazards, and shall use protective measures to deter, detect, and prevent the unauthorised use of, access to, or disclosure of such media. Waste disposal Paper documents and magnetic, optical, or solid state media containing commercially sensitive or confidential information relating to the operation of the SMKI, shall be securely disposed of in accordance with commercial best practice and Security Standard No 5 Category A techniques should be deployed where appropriate. All media used for the storage of information such as keys, activation data; confidential Subscriber information, OCA/ DCA and RA Private Key material shall be disposed of in accordance with the risk level of the material concerned. This process must be approved by the PMA. V1.2 57

58 Off-site backup OCAs, DCAs and RAs shall maintain back-ups of critical system data or any other sensitive information, including audit data, in a secure off-site facility. Any transfer of media between sites shall be protected in accordance with the requirements for the handling of information at the appropriate risk levels. All OCA, DCA and RA Private Key material shall be protected in accordance with the requirements commensurate with the protection of cryptographic material. All private keying material must be backed up using the proprietary backup mechanisms specific to the HSM Off-site backup arrangements must be in place as required by the business continuity arrangements Where data and facilities are removed from primary locations or in support of business continuity activities, then the off-site facility must have appropriate levels of security in place, equivalent to the main OCA/DCA sites Procedural Controls Trusted roles Separation of duties for critical functions to prevent a single person from maliciously using OCA/DCA systems and supporting systems without detection must be in place and evidenced. The separation of distinct SMKI personnel roles by named personnel, distinguishing between day-to-day operation of the OCA/DCA systems and the management and audit of those operations. To the greatest extent practicable, differing levels of physical and systems access control based on roles and responsibilities shall be employed to reflect the requirements of those roles and responsibilities. Controls must be detailed in the Certification Practice Statement and/or supporting documentation. Number of persons required per task AN OCA or DCA must ensure separation of duties for critical OCA or DCA functions to prevent one person from maliciously using the OCA or DCA system without detection. At a minimum, four individuals will be required in order to fulfil the following roles: V1.2 58

59 a) System Administration (e.g. System Administrator role); b) Operations (e.g. Backup Operator, OCA/DCA Operator and RA Operator roles); c) Security (e.g. System Security Officer role); and d) Auditing (e.g. System Auditor role) The OCA System Administrator is responsible for system administration, including configuration changes and management of user accounts The OCA Operator has responsibility for day to day operation of the facility (e.g. generation of certificates, publication of CRLs, etc.) 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. The System Auditor has responsibility for auditing the operation of the CA. The System Auditor shall only be given supervised access for audit purposes and should not have administration access to the system. Unless otherwise authorised by the PMA, each OCA, DCA and RA must ensure that no single individual may gain direct access to OCA, DCA or RA Private Keys. Two individuals, using a split-knowledge technique such as twin smartcards, are required for the following processes: a) OCA/DCA system start-up; b) OCA/DCA system shutdown; c) key backup; d) key recovery; and e) Revocation of OCA and RA Certificates. In very restricted circumstances where other physical and personnel controls are in place, the PMA may authorise a OCA /DCA to enable a single individual to gain access to OCA/DCA Private Keys. Multi-person control is required for OCA Key and DCA Key generation. Multi-person controls must be established for the performance of critical functions associated with the build and management of OCA and DCA systems, including the software controlling Certificate or Device Certificate manufacturing operations All other duties associated with Certificate Manufacture, Device Certificate Manufacture or Participants providing other Trust Services V1.2 59

60 under the contract may be performed by an individual operating alone, however, verification processes employed must provide for oversight of all activities performed by trusted role holders. Identification and authentication for each role The authentications of system administrators must be assured to a high level. It is recommended that the security of the relevant authentication mechanism be designed to have an appropriate level of assurance to counter the threats against the system. This should be covered in the SMKI Contractor s risk assessment. All OCA, DCA and SMKI RA personnel must have their identity and authorisation verified to Level 3 (Verified) as detailed in GPG43 RSDOPS framework (or equivalent framework to be agreed with the PMA), before they are: 1) included in the access list for the OCA/DCA site; 2) included in the access list for physical access to the CA or BA system; OCA or DCA 3) given a Certificate for the performance of their OCA or DCA role; and 4) given an account on the SMKI system. Each of these accounts must: 1) be directly attributable to an individual; 2) not be shared; and 3) be restricted to actions authorised for that role through the use of OCA or DCA software, operating system and procedural controls. Credentials issued to personnel in trusted roles must be: Managed so that their use can be detected and monitored. Managed so that their use is restricted to actions authorised for that role through applicable technical and procedural controls. Maintained under a prescribed and documented security policy. Roles requiring separation of duties Other Participants providing Trust Services under the contract shall maintain appropriate separation of duties so as not to compromise the security arrangements for critical processes Personnel Controls Qualifications, experience, and clearance requirements A Participant providing Trust Services must ensure that all personnel V1.2 60

61 performing duties with respect to its operation must: Be appointed in writing. Be bound by contract or statute to the terms and conditions of the position they are to fill. Have received training with respect to the duties they are to perform. Be bound by statute or contract not to disclose sensitive securityrelevant information or Subscriber information and maintain required protection of personal information. Not be assigned duties that may cause a conflict of interest with their service provision duties. Not have been, as far as known, previously relieved of a past assignment for reasons of negligence or non-performance of duties All OCA, DCA and RA personnel shall have suitable qualifications and experience, and shall have, as a minimum, a Security Check (SC) clearance. Sub-contractors to the SMKI Contractor (and approved by the PMA) providing services under the contract may also specify additional criteria for security clearance of personnel, such as requirements for citizenship, rank, qualifications, satisfactory credit check, and absence of a criminal record. Any such additional requirements shall be stated in the Certification Practice Statement and/or supporting documentation. Background check procedures Checks appropriate to the clearance levels defined in Section shall be carried out in accordance with the HMG Security Policy Framework or equivalent policy/standard as agreed with the PMA. Training requirements Must be defined in the CPS and include the training requirements for the DCC staff operating the SMKI Contractor provisioned RA service. Retraining frequency and requirements Must be defined in the CPS. Job rotation frequency and sequence Must be defined in the CPS. V1.2 61

62 Sanctions for unauthorised actions Appropriate disciplinary actions shall be undertaken if the Certificate policies are violated, including the unauthorised use of authority, or the unauthorised use of SMKI systems, Certificates or Device Certificates. This will include any breach of the Acceptable Use Policy or Security Operating Procedures Disciplinary actions may include actions under the Computer Misuse Act and Data Protection Act Independent contractor requirements Requirements for contractors and other non-smki Contractor staff are the same as for SMKI Contractor staff. Any SMKI Contractors who provide services under the contract shall establish procedures to ensure that any subcontractors perform in accordance with the relevant Certificate Policies and the relevant CPS. The actions of contracting staff are subject to the same audit arrangements and requirements as those of the personnel of the SMKI Contractor. Documentation supplied to personnel All personnel associated with SMKI Service provision shall be provided access to all documentation relevant to their position. This will include the Certificate Policies and associated Certification Practice Statements relevant to the service, together with any specific supporting documentation, statutes, policies or contracts relevant to the position and role of the personnel Audit Logging Procedures Types of events recorded All events pertaining to the use of OCA, DCA 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 OCA, DCA and RA operators, errors and failures, publication of a CRL and all communications received and sent; the full list shall be identified in the CPS Certificate Manufacturer - Audit logs of all transactions relevant to Certificate creation, Certificate lifecycle management and the V1.2 62

63 operation of trusted systems and services must be maintained to provide an audit trail. Device Certificate Manufacturer - Audit logs of all transactions relevant to Device Certificate creation, Device Certificate lifecycle management and the operation of trusted systems and services must be maintained to provide an audit trail. The Registration Authority and centrally provided RA System must record for audit purposes, at a minimum the event types listed below: Any log on/off attempts by RA operators All messages from authorised sources requesting an action of the RA and the subsequent actions taken by the RA in response to such requests. All messages to the OCA or DCA requesting an action of the OCA or DCA and the subsequent action taken by the OCA or DCA. All physical accesses to RA systems (including components) and RA locations. RA application start-up and shut down. All use of the RA signing key(s). Any suspected or known violations of physical security. Any suspected or known violations of network and system security. All checks made for the registration of RA staff. All personnel/role changes for trusted roles Frequency of processing log The audit logs of OCA, DCA and RA systems shall be reviewed daily for any anomalies and these anomalies investigated. The audit logs of the Root OCA and RootDCBA system shall be reviewed whenever activated for any anomalies and these anomalies investigated. Care shall be taken to ensure compliance with the Data Protection Act. Sensitive personal data must not be recorded in the audit logs where it may be unintentionally exposed. V1.2 63

64 As a minimum, the following events shall be recorded in the audit logs 4 : a) any logon or logoff attempts by OCA, DCA or RA operators; b) any password changes; c) failed logon attempts; d) messages received from any source requesting OCA, DCA or RA action (e.g. Certificate requests, Device Certificate requests, Certificate revocation requests, etc.); e) actions taken in response to requests; f) physical access to, loading, zeroization, 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 OCA, DCA or RA equipment; l) server installation, access or modification; m) system start-up and shutdown; n) OCA, DCA or RA application start-up and shutdown; o) OCA, DCA or RA equipment access (e.g. room access); p) file manipulation and account management, including personnel changes; q) any use of the OCA, DCA or RA signing key; r) documentation supporting Certificate or Device Certificate applications s) revocation requests; t) any CRLs issued; and u) checks made during the registration process. 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; 4 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 This data is sometimes referred to as accounting logs. V1.2 64

65 d) success or failure indication, where relevant; and e) the identity of the entity that caused the event. Private Keys shall not under any circumstances be recorded in the audit log. Each OCA, DCA or RA shall enable any accounting or audit capability of the underlying operating system on which software relating to the SMKI operates. Protective monitoring shall follow CESG Good Practice Guide Number 13, or a recognised equivalent set of good practices. Audit logging shall comply with BS10008:2008 Code of Practice for Legal Admissibility and Evidential Weight of Stored Electronically. Access to the audit log shall be read-only, and shall be limited to a dedicated System Audit role only. The Participant shall provide details of audit log processing in the records of role allocation in the Certification Practice Statement and/or supporting documentation Retention period for audit log Audit logs are to be retained for a period of no less than seven (7) years. Protection of audit log The electronic audit log system must include mechanisms to protect the log files from unauthorised viewing, modification, and deletion. Manual audit information must be protected from unauthorised viewing, modification and destruction. The audit log file should be read only, and protection mechanisms shall be put into place to enforce this for the OCA and DCA Software audit log and that the integrity of the log is maintained for evidential purposes. Audit log backup procedures Audit logs and audit summaries must be backed up or if in manual form, must be copied. Such backups must be provided with the same level of security as the originals and must be commensurate with the data contained within them. Audit logs shall be backed up daily, or whenever activity has taken place at the OCA or DCA in the event of infrequent use, as part of the same schedule as the regular backup of the OCA or DCA database. If audit logs are held in a physical form, they shall also be backed up daily, or whenever activity has taken place at the OCA or DCA in the event of infrequent use, through photocopy or other means. V1.2 65

66 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 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 detailed in Section Audit collection system (internal vs. external) Must be detailed in the CPS Notification to event-causing subject Must be detailed in the CPS Vulnerability assessments Each OCA, DCA and RA must ensure that its SMKI services are accredited by the PMA prior to live operation. This will include assessment and auditing under the approved compliance scheme (see section ) as defined in the Certificate policies The compliance and accreditation document set produced by the SMKI Contractor shall be reviewed and revised in the event that security issues are identified in the examination of monitored events An information security penetration test shall be undertaken by an independent party, of OCA and DCA systems prior to live operation. The scope of the penetration test shall include both internal and external attacks and application layer testing. An information security penetration test shall be undertaken by a CHECK or CREST Service Provider of OCA and DCA systems prior to live operation. The scope of the penetration test shall include both internal and external attacks and application layer testing The Root OCA and Root DCA shall undergo appropriate security testing by an independent party prior to live operation. The Root OCA and Root DCA shall undergo appropriate security testing by a CHECK or CREST Service Provider prior to live operation Records Archive Types of records archived The event records and any accompanying data as described in section 4.120) of this document are to be archived. The SMKI Contractor may also be required to retain additional information to ensure compliance with the Certificate Policies and/or legal requirements. V1.2 66

67 Registration Authorities must retain records of information provided in support of Certificate applications, Device Certificate applications and Certificate Revocation requests. Retention period for archive Archived information is to be retained for a period of no less than seven (7) years Protection of archive Archives are to be protected from unauthorised viewing, modification, and deletion. Archives are to be adequately protected from environmental threats such as temperature, humidity and magnetism. 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 Multiple copies of information may be archived Archive backup procedures 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. Requirements for time-stamping of records All OCAs and DCAs shall time-stamp all records with the date and time, in hours, minutes and seconds. The accuracy of the time-stamping shall be in accordance with the requirements of Section Archive collection system (internal or external) The OCA, DCA and RA archive collection system shall be documented in the CPS. Procedures to obtain and verify archive information Participants providing Trust Services shall comply with the confidentially requirements specified. The procedures for verification shall be stated in the CPS Key Changeover OCA Key Changeover OCAs shall not issue Certificates that extend beyond the expiry dates of their own Certificates and public keys. This is not applicable for DCAs due to indefinite lifetimes of Certificates, Device Certificates and keys. V1.2 67

68 OCA key changeover shall be as defined in the Certificate Lifecycle Management document to be published by the SMKI Contractor in agreement with the PMA On OCA key changeover a new key-pair shall be generated and a new Certificate published On OCA key changeover: a) The old OCA Private Key will no longer be used to sign Certificates b) The old OCA 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. e) The old Private Key is verifiably destroyed. DCA Key Changeover DCAs will not be subject to key changeover. At the point of the volume or time limit being reached, an Issuing-DCA will be decommissioned, the private key destroyed, and a new Issuing-DCA created with a new key pair, and a new Certificate published On Issuing-DCA changeover, a new key-pair shall be generated and a new Certificate published Issuing-DCA changeover needs to be managed accordingly to ensure there is no disruption to service On Issuing-DCA changeover: The old Issuing-DCA Private Key will be destroyed and therefore no longer be used to sign Device Certificates. The old Issuing-DCA Public Key remains valid indefinitely in order to validate signatures produced by the old Private Key prior to Issuing-DCA changeover. The new Private Key is used to sign Device Certificates. The new Public key is used to validate signatures produced by the new Private Key. The old Private Key is verifiably destroyed All OCA Certificates and DCA Certificates shall be made available in a repository accessible to all Participants (DCC and its Service Users) in the SMKI Compromise and Disaster Recovery V1.2 68

69 Incident and compromise handling procedures In the case of comprise of an OCA or OCA-keys, the OCA shall as a minimum require the following: Immediately cause the suspension of the Certificate Status checking service for all Issued Certificates affected by a compromise, failure or disaster. This will stop any of these Certificates from being accepted by any Relying Party who follows proper Revocation checking procedures according to Section the PKI Disclosure Statement. (Note: this document may be omitted if the SMKI Contractor can fully justify reasons for doing so). Suspension of any further Certificate Issuance from the affected OCA The Policy Management Authority must be notified and shall make any determination relating to Revocation of OCA Certificates In the case of compromise of a DCA or DCA-keys, the DCA shall as a minimum require the following: Under no circumstances revoke Device Certificates or the DCA Public Key. Suspension of any further Device Certificates issued from the affected DCA The Policy Management Authority must be notified in the event of a compromise to any OCA or DCBA Security breaches must be recorded in line with service level incident reporting. See section Computing resources, software, and/or data are corrupted SMKI Contractors must establish business continuity procedures that outline the steps to be taken in the event of the corruption or loss of computing resources, software and/or data. Business continuity plans for SMKI Contractors shall be detailed in the Certification Practice Statement and/or supporting documentation. Plans must be approved as part of accreditation Business continuity capabilities after a disaster The Solution shall include Business Continuity and Disaster Recovery procedures. These shall be compliant with ISO22301 and ISO A business continuity plan shall be in place to protect critical SMKI processes from the effect of major compromises, failures or disasters. These shall enable the recovery of all CA and BA services. Business continuity plans for SMKI Contractors shall be detailed in the Certification Practice Statement and/or supporting documentation. V1.2 69

70 All OCAs and DCAs shall implement a business continuity strategy and plan, including a disaster recovery site to ensure the issuance of Certificates and Device Certificates, and in the case of the OCA, continuation of the revocation capability in the event of a disaster SMKI Contractors must provide evidence that such plans have been exercised at a minimum annually Where a Public Key Repository is not under the control of the OCA or DCA, an OCA or DCA must ensure that any agreement with the Public Key Repository provider includes the requirement that a disaster recovery plan be established, tested and documented by the repository provider In developing disaster recovery and failover plans, the Organisation SMKI CA must give priority to: 1) the availability of all previously issued CRLs; and 2) The ability to revoke Certificates OCAs and DCAs 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 the Certificate Policies Disaster recovery capabilities shall be consistent with good industry practices and shall be designed to enable the OCA and DCA to provide services in accordance with the Certificate Policies within 12hrs of a disruption. Any backup facility used for relocation following a disaster shall maintain compliance with the Certificate Policies. The provisions of the Certificate Policies shall be maintained during any relocation/transition Registration Authority business continuity arrangements must be documented in the CPS OCA or RA Termination Termination of an OCA is regarded as the situation where all service associated with an Issuing Authority is terminated permanently. It is not the case where the service or elements of the service is transferred, such as between or to Certificate Manufacturers or responsibility for Certificates is transferred between Issuing Authorities, even if there is a change of OCA-Keys. Prior to termination, OCAs shall provide archived data to an approved archival facility. In the event that a OCA 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 OCAs keys and information. V1.2 70

71 In the event of a change in management of a OCA s operations, the OCA must notify in writing all Entities for which it has issued Certificates. The OCA archives should be retained in the manner and for the time indicated in Section Registration Authority - Registration Authorities deployment and configuration details vary. At minimum the Registration Authority terminating service shall: DCA or RA Termination Have all RA keys under their control Revoked. Have all RA Agents Certificates Revoked Ensure preservation and storage of records for the minimum period of time stipulated for the service being terminated but in any event not less than 7 years. Alternatively with the approval of the Issuing Authority and the PMA, records may be transferred to another Participant providing Trust Services, e.g. a new or alternative Registration Authority Prior to termination, Issuing-DCAs shall provide archived data to an approved archival facility. In the event that an Issuing-DCA ceases operation, there is no requirement to notify its Subscribers. The DCA archives should be retained in the manner and for the time indicated in Section For a Device Certificate Manufacturer The specific circumstance related to termination of a Device Certificate Authority must be prescribed by the DCA. At a minimum the following actions shall be taken under the direction of the DCA: Inform both the DCA and Policy Management Authority for the governing Certificate Policy. Provide a notice period of 90 days. Arrange with a third party for the preservation and storage of records for the minimum period of time stipulated for the service being terminated but in any event not less than 7 years Registration Authority - As per section Technical Security Controls Specific details on technical controls operated for components of the SMKI infrastructure must be detailed in the Certification Practice Statement and/or supporting documentation. Controls must be approved by the PMA or Auditors acting on its behalf. V1.2 71

72 4.127 Key Pair Generation and Installation Key pair generation Root OCA, Root DCA, OCA keys, and DCA keys shall be generated in a protected environment conforming to at least Federal Processing Standard FIPS140-2 at level 3 its equivalents and successors. DCA or OCA-Key generation shall be multi-person control using random numbers of such length so as to make it computationally infeasible to regenerate them, even with the knowledge of the when and in which equipment they were generated. RA signing keys shall be generated in a protected environment conforming to at least Federal Processing Standard FIPS140-2 at level 2 its equivalents and successors. Private Keys used in any Issuing Authority, Issuing-DCA and/or Trust Services process that affects the outcome of Issued Certificates, Issued Device Certificates and Certificate Status services (such as signing of Certificate Revocation Lists), shall be generated under controlled procedures using a hardware cryptographic token designed to meet the level of requirements as specified in FIPS level 2, or its equivalents and successors. Participants conducting such key generation shall provide detail of the procedure in the Certification Practice Statement and/or supporting documentation. Procedures must be approved by the PMA or Auditors acting on its behalf Subscribers (Subjects ) Key Pairs will be generated by the Subscriber (Subject). Public key delivery to Certificate issuer The mechanism by which Subscriber Public Keys are delivered to the Certificate Manufacturer or Device Certificate Manufacturer through the centrally provided RA System shall be defined by the OCA and the DCA and described in the OCA/DCA Registration Policy and Procedures, but should be achieved using a recognised standard protocol e.g. PKCS#10. OCA or DCA public key delivery to relying parties The delivery of Public Keys to the Certificate authority shall use PKCS#10 or other equivalent standards compliant cryptographic V1.2 72

73 mechanism The delivery of Root OCA and Root DCA public key to the approved Repository must be performed in a secure manner in order to guarantee the integrity of the public key. This process must be documented in the CPS All Issuing-OCA and Issuing-DCA Certificates must be made available in the approved repository. Key sizes The size of Issuing-OCA, Issuing-DCA, and any supporting OCA-Keys, or DCA-Keys shall be: Elliptic Curve on the NIST P-256 curve in its uncompressed form, as defined in RFC5480; Digital Signature verification with Elliptic Curve Digital Signature Authentication using SHA256. Public key parameters generation and quality checking Public Key exponents shall be of values and lengths that make known attacks (e.g. low exponent attacks) infeasible. Key usage purposes (as per X.509 v3 key usage field ) The Certificate or Device Certificate keyusage field must be used in accordance with the PKIX-1 Certificate and CRL Profile [RFC5759 and RFC5280] Certificates or Device Certificates Issued under the policies may be used in applications and services as listed in the PKI Disclosure Statement. (Note: this document may be omitted if the SMKI Contractor can fully justify reasons for doing so). A Certificate or Device Certificate may be used for one or more of the following key usage services: Subscriber o Digital signature. o Key Agreement. Certificate Authority (OCA-Keys) o Certificate Signature. o CRL Signature. Device Certificate Authority (DCA-Keys) o Device Certificate Signature V1.2 73

74 No other keyusage values may be present in Certificates or Device Certificates Use of extensions in the Certificate shall be consistent with those as specified in the applicable Certificate Policy. Private Key Protection and Cryptographic Module Engineering Controls Cryptographic module standards and controls OCA-Keys and DCA-Keys shall be protected by high assurance physical and logical security controls. They must be stored in, and operated from inside a specific tamper resistant hardware based security module that complies with FIPS140-2 at level 3, its equivalents and successors. Private Keys used in any Issuing-OCA, Issuing-DCA and/or Registration Authority process that affects the outcome of Issued Certificates, Issued Device Certificates and Certificate Status services (such as signing Certificate Revocation Lists), shall be protected by, maintained in, and restricted to, a hardware cryptographic token designed to meet the level of requirements as specified in FIPS level 3, or its equivalents and successors. Private OCA-Keys and DCA-Keys shall not be made available in unprotected form (complete or unencrypted) except in approved security modules specified in the Certificate Policies. Private Key (n out of m) multi-person control For generation of Issuing-OCA, Issuing-DCA, supporting OCA-Keys, supporting DCA-Keys and keys that affects the outcome of Issued Certificates, Issued Device Certificates and Certificate Status services, at a minimum two-person control is required HSMs shall require at least two individuals in order to start up and shut down. Private Key escrow The service shall not provide Private Key escrow services. Private Key backup The SMKI Contractor may backup and archive Private Keys (other than Subscribers ), including OCA- keys and DCA-Keys. In all cases key backups shall at a minimum be protected to the standards commensurate with that stipulated for the primary version of the key. In the case of aggregated backups of keys, (for example, many keys backed-up inside and protected by a single security environment), the backed-up keys must be protected at a level commensurate with that stipulated for the OCA s and DCA s private signing key. Private Key archival V1.2 74

75 Private keys shall not be archived Private Key transfer into or from a cryptographic module OCA or DCA 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 OCA or DCA Private Key transfer or backup shall only be performed by personnel with an appropriate trusted role The transfer or backup process must be compliant with the cryptographic module standard as defined in Section Participants conducting such key transfer or backup shall provide detail of the procedure in the Certification Practice Statement and/or supporting documentation. Private key storage on cryptographic module For any Issuing-OCA, Issuing-DCA, supporting OCA-Keys, supporting DCA-Keys and keys that affect the outcome of Issued Certificates, Device Certificates and Certificate Status services and other business processes prescribed standards are required for the cryptographic protection of Private Keys. See Section Method of activating private key For OCA or DCA Certificates, the cryptographic module shall require the successful completion of an authentication process, which shall involve the use of Activation Data (password or smartcard), before activating the Private Key. The authentication credentials must have an appropriate level of strength for the keys or data to be protected. Cryptographic modules which are used as components of Certificate lifecycle management shall block themselves after a specified number of consecutive failed attempts to authenticate to the module Unblocking shall require authorised personnel to use a mechanism to authenticate to the module Method of deactivating private key The private key may be de-activated by the system. The following actions should de-activate the private key: V1.2 75

76 1) Turning the power off 2) Logging off 3) System reset 4) A pre-defined period of inactivity Method of destroying private key Strict controls over destruction of OCA-Keys, DCA-Keys and keys that affect the outcome of Issued Certificates, Issued Device Certificates and Certificate Status services must be exercised. Controls must be detailed in the Certification Practice Statement and/or supporting documentation. The OCA or DCA must approve the destruction of OCA, DCA and supporting OCA-Keys and DCA-Keys. Cryptographic Module Rating See Section Other Aspects of Key Pair Management Public key archival Public keys shall be archived in accordance with Section Certificate operational periods and key pair usage periods for Organisation SMKI Usage periods for key pairs shall be governed by validity periods set in Issued Certificates. These shall be as defined in the Certificate Lifecycle Management document as published by the SMKI Contractor in agreement with the PMA. Certified Private Keys shall not be extended beyond the initial lifetime of the Certificate Issued to authenticate them. This means that a renewal which would result in Certificate expiry after the expiry date for the original Certificate issued for that Key Pair is not permitted. Device Certificate operational periods and key pair usage periods for Devices SMKI Usage periods for key pairs shall be governed by validity periods set in Issued Device Certificates. These shall have the following values under the Devices SMKI: Subscribers indefinite lifetime. Centrally provided intermediate Issuing Device Certification Authorities indefinite lifetime. Off-line primary Issuing Root Device Certificate Authority V1.2 76

77 indefinite lifetime Activation Data Activation data generation and installation All OCA, supporting OCA-Keys, all DCA and supporting DCA-Keys, and keys that affect the outcome of Issued Certificates, Issued Device Certificates and Certificate Status services shall have activation data that is unique and unpredictable. 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. Where PINs, passwords or pass-phrases are used, an entity must have the capability to change these at any time. If applicable, unblocking code for a cryptographic module (if available) shall only be delivered to the legitimate holder of the module after an express request from the holder. Delivery of the unblocking code requires strong identification of the holder. Activation data protection All OCA, supporting OCA-Keys, all DCA and supporting DCA-Keys, and keys that affect the outcome of Issued Certificates, Issued Device Certificates and Certificate Status services shall have mechanisms for the protection of activation data which is appropriate to the Keys being protected. See section Details of protection shall be provided in the Certification Practice Statement and/or supporting documentation. Other aspects of activation data No stipulation Computer Security Controls Specific computer security technical requirements. The OCA, DCA and RA process must have successfully completed and been awarded a compliance/accreditation under the specified accreditation scheme. This will cover the specific computer security technical requirements. As a minimum, the SMKI Contractor shall implement security measures that have been identified through a threat assessment exercise and must cover the following functionality where appropriate: Access control to trust services and PKI roles. Enforced separation of duties for PKI roles. Identification and authentication of PKI roles and associated identities. Use of cryptography for session communication and database V1.2 77

78 security. Archival of Participant history and audit data. Audit of security related events. Trusted path for identification of PKI roles and associated identities. Recovery mechanisms for keys of PKI Participants providing trust services. This functionality may be provided by the operating system, or through a combination of operating system, PKI OCA/DCA software, and physical safeguards. The SMKI Contractor must document procedures, in the Certification Practice Statement and/or supporting documentation. Procedures shall, at a minimum, include logging and audit requirements for processes related to initialisation, resetting, shutdown or reconfiguration of Certificate Authorities and Device Certificate Authorities and any services that affect the outcome of Issued Certificates, Issued Device Certificates and Certificate Status. Computer security rating Participants providing Trust Services may use system components that do not possess a formal computer security rating provided that all requirements of the Certificate Policies are satisfied. Any hardware security module device or system holding OCA-Keys or DCA-Keys must comply with the requirements of Section Where specific additional requirements prescribe systems or security environments that fulfil specific security ratings these must detailed in the Certification Practice Statement and/or supporting documentation Lifecycle Technical Controls System development controls The development of software, that implements Trust Service functionality shall as a minimum be performed in a controlled environment that, together with at least one of the following approaches, shall protect against the insertion of malicious logic: The system developer shall have a quality system compliant with international standards e.g. ISO 9001:2000 or; The system developer shall have a quality system available for inspection and approval by the SMKI Contractor. V1.2 78

79 No upgrades shall be permitted without prior offline testing and assessment, and regular backups Security management controls The configuration of systems operated by Participants providing Trust Services under contract to the Contractor, as well as any modifications, upgrades and enhancements must be documented and controlled. There must be a method of detecting unauthorised modification or configuration of the software supporting Trust Services. Participants providing Trust Services under contract to the Contractor shall ensure that it has a configuration management process in place to support the evolution of the systems under its control The OCA and DCA shall provide a mechanism to periodically verify the integrity of the software Upon installation time, and regularly thereafter, the integrity of the OCA and DCA system shall be validated Details of security management systems e.g. ISO/IEC shall be provided in the Certification Practice Statement and/or supporting documentation System security management shall be controlled by the privileges assigned to system accounts and by trusted roles Any Issuing-OCA or Issuing-DCA installation that is connected to a network shall be subject independent penetration testing. Life cycle security controls The scope and extent of this subcomponent addressing system development controls and security management controls must be included in the SMKI Contractor s security risk management document sets. Network security controls An offline Root-OCA and Root DCA capability must be used. There must be no connection to external networks. SMKI Contractor systems must be protected from attack through any open or general-purpose network with which they are connected. Such protection must be provided and configured to allow only the minimal set of functions, protocols and commands required for the operation of the Trust Service. V1.2 79

80 Time Stamping Participants providing Trust Services to the SMKI Contractor shall detail the standards procedures and controls for network security in the Certification Practice Statement and/or supporting documentation which must be approved by the PMA or Auditors acting on its behalf. Any online Issuing-OCA, Issuing-DCA or RA (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 the network. Any Issuing-OCA, Issuing-DCA or RA installation that is connected to a network shall be subject to an annual penetration testing by an independent body Time recording shall be implemented for all Certificates, Device Certificate and other related activities that require recorded time. A synchronised and controlled time source shall be used. Participants providing Trust Services to the SMKI Contractor shall detail the time source used and mechanisms for its control in the Certification Practice Statement and/or supporting documentation which must be approved by the Auditors acting on behalf of the PMA. Compliance Audit and Other Functions General Compliance The Contractor and all contractors to them shall be ISO27001:2005 or later certified The scope of the ISO27001 audit should, as a minimum, cover the service definitions defined in this document. The exact scope will be agreed in accordance with the auditor Compliance of End-entity organisations shall be assessed under the agreed compliance scheme (see section ) as part of the standard Compliance process. The frequency and extent of external audits will be specified by the SMKI PMA in accordance with the Compliance policy Compliance of OCAs and DCAs with the Certificate Policy shall be ensured using a process that is consistent with the Compliance process. The SMKI PMA Compliance policy will detail the compliance requirements for the V1.2 80

81 PKI and the Certificate Policy aspects of the SMKI. Before an OCA or DCA is operational, it shall be subject to an assurance assessment (in this case the tscheme) with the report considered by the PMA (or nominated assessor on its behalf e.g. tscheme) to assess compliance with this Certificate Policy Following live operation, the OCA and DCA must undergo an external and independent assurance assessment audit to ensure that it is compliant with the requirements of the Certificate Policy The OCA / DCA must undertake an annual internal audit and certify annually to the PMA that they have at all times during the period in question complied with the requirements of the Certificate Policies. The OCA / DCA must also provide to the PMA details of any periods of noncompliance and explain the reasons why the OCA / DCA have not complied with the relevant Certificate Policy The PMA shall have the right to audit and inspect the premises, staff documents and data of any Issuing-OCA or Issuing-DCA for the purposes of evaluating that OCA or DCA compliance with the terms of the relevant Certificate Policy The PMA, at its discretion, may request an Issuing-OCA or Issuing-DCA to undergo an independent external assurance assessment audit at any time The external and independent assurance assessment audit of the Root OCA and Root DCA to review compliance with the relevant Certificate Policy must also be undertaken by the before operation and periodically thereafter at a frequency to be agreed by PMA The SMKI Contractor shall gain tscheme (or it s equivalent) Registered Applicant status prior to the start of pre-integration testing of the service commencing (currently scheduled for 1 st September 2014) and full assurance in place for SMKI Go Live, as permissible by tscheme Frequency and Circumstance of Assessment The details for assessment are specified in contractual arrangements between Smart DCC and the SMKI Contractor. These must be approved by the PMA For all Participants providing Trust Services, independent assurance assessments shall be via a not for profit assurance scheme that is recognised and recommended by the UK Government and industry in relation to the UK Electronic Communications Act The scheme should be specifically focussed on profiles that provide assurance of PKI operations, using assessors accredited by UKAS and also recognised in the EU Although it is expected that the SMKI Contractor has gained an industry recognised certification for their OCA and DCA service and to use this as evidence, prior industry certification is not mandatory. V1.2 81

82 The Policy Management Authority may require supplementary or additional assurance for any Participants providing Trust Services The Policy Management Authority may exercise right to audit any Participants providing Trust Services at any time The frequency and extent of external assurance assessments will be specified by the PMA The scope of the compliance assurance will extend to externally provided Trust Services or Trust Service Components. For example: where the SMKI Contractor uses an external Certificate Manufacturer. This ensures that the overall quality and security of the Trust System being offered is not prejudiced by any insecurity s in the services or components upon which it depends While operations may be delegated, responsibility and liability for service provision is not Identity/ Qualification of Assessor The assurance assessment must be conducted under a scheme and with assessors accredited by UKAS and based on ISO27001 and subject to approval by the Policy Management Authority Assessor s Relationship to Assessed Entity The acceptability of independent assurance scheme is decided by the Policy Management Authority on a recommendation from Smart DCC Topics Covered by Assessment Assurance assessments are required to ensure a SMKI Contractor is operating in accordance with its Certification Practice Statements, the Certificate Policies and any declared assurance or approval schemes under which Trust Services are operated Where the Participants providing Trust Services uses any designated authorised agents in order to provide service, the assurance assessment shall include the operations of the designated authorised agents Assessment must be sufficient to demonstrate to the Policy Management Authority that the services comply with the relevant Certificate Policies and any supporting policy documents applicable to their services Actions Taken as a Result of Deficiency For compliance audits of Participants providing Trust Services, where significant exceptions or deficiencies are identified, the OCA or DCA must inform the Policy Management Authority which shall determine action to be taken If an immediate threat to the security or integrity of the SMKI services is identified, the Policy Management Authority may require suspension or termination of non-compliant services by the OCA or DCA. V1.2 82

83 For lesser exceptions or deficiencies, the OCA or DCA may determine the course of action to be taken and provide a remediation action plan that must be approved by the Policy Management Authority. The Policy Management Authority has overall responsibility to ensure implementation of the action plan Communication of Results Following an assurance assessment, the approval status of Issuing Authorities and Issuing Device Certificate Authorities shall be made publicly available by the SMKI Contractor In the event of identification of material non-compliance with the Certificate Policies, the OCA or DCA shall make available to Subscribers and Relying Parties details of action to be taken as a result of the deficiency and any remedial action required to be taken SMKI Security Testing The SMKI Contractor shall undertake security testing of its proposed approved solution and all components that encompass the SMKI service and seek Smart DCC approval of the resulting penetration test report. The SMKI Contractor shall gain approval of the penetration test scope before submitting as a schedule for testing. The SMKI Contractor shall undertake security testing under controlled conditions and manage all changes to the solution as formal changes to be signed off by Smart DCC prior to implementation. The SMKI Contractor shall treat all risks identified by the penetration test report as Very-High, High and Medium-high, and gain Smart DCC approval on the effectiveness of the risk treatment plan applied to these risks. The SMKI Contractor shall seek Smart DCC approval on all risks labelled Medium and below which may include treatment and/or Do-Nothing dependent on the severity of the risk to the DCC. The SMKI Contractor shall produce a risk mitigation report and seek its approval from Smart DCC for all those risks it believes require no further risk treatment with justification in each case supported by a risk assessment. Certificate and Device Certificate Profiles For further information and detail on the requirements in this section see Appendix B Certificate & Device Certificate Profiles End Entity Certificate and Device Certificate Structure and Contents This section lays out requirements as to structure and content to which all valid authorised Certificates and Device Certificates shall comply. All V1.2 83

84 terms in this section shall, where not defined in previously, or in the GBCS, have the meanings in IETF RFC 5759 and IETF RFC Common requirements Applicable to Certificates and Device Certificates All Certificates and Device Certificates that are validly authorised within the SMKI for use by Devices within the scope of GBCS and GB Smart Metering: be compliant with IETF RFC 5759 and so with IETF RFC5280. For clarity and in adherence with the requirements of IETF RFC5759, all Security Credential Documents shall: o contain the authoritykeyidentifier extension, except where the security credentials document is self signed or Root Certificates; o contain the keyusage extension which shall be marked as critical; be X.509 v3 certificates as defined in IETF RFC 5280, encoded using the ASN.1 Distinguished Encoding Rules only contain public keys of types that are explicitly allowed within the GBCS. At this version, this means all public keys shall be elliptic curve public keys on the NIST P-256 curve; only contain public keys in uncompressed form contain an elliptic curve point in uncompressed form as detailed in Section 2.2 of IETF RFC5480; only provide for signature methods that are explicitly allowed within the GBCS. At this version, this means using P-256 Private Keys with SHA 256 and ECDSA; contain a certificatepolicies extension containing at least one PolicyIdentifier which shall be marked as critical. For clarity and in adherence with IETF RFC 5280, Certification Path Validation undertaken by Smart Metering Devices shall interpret this extension; contain a serialnumber of no more than 8 octets in length; contain a subjectkeyidentifier which shall be marked as noncritical; contain a authoritykeyidentifier in the form [0] KeyIdentifier which shall be marked as non-critical, except where the Security Credential Document is self signed. Note this exception only applies where RemotePartyRole as specified in the X520OrganizationalUnitName field = root; only contain KeyIdentifiers generated as per method (2) of Section of IETF RFC 5280 and so which shall always be 8 octets in length; contain an IssuerName which MUST be identical to the signer's V1.2 84

85 SubjectName have a valid notbefore field consisting of the time of issue encoded and a valid notafter as per IETF RFC 5280 Section Requirements applicable to End Entity Certificates only All Certificates that are validly authorised within the Organisation SMKI for use by Devices and SMKI participants within the scope of GBCS and GB Smart Metering shall: have an expiration date in the notafter field; contain a subjectuniqueid whose value shall be the 8 octet Entity Identifier of the subject of the Certificate; contain a non-empty subject field which contains: an X520 OrganizationalUnitName whose value shall be set to the RemotePartyRole that this Certificate allows the subject of the certificate to perform contain a single Public Key contain a keyusage extension marked as critical, with a value of only one of: digitalsignature; or keyagreement. contain a single policyidentifier in the certificatepolicies extension that refers to the OID applicable to the environment the Certificate has been issued in Requirements applicable to Device Certificates only All Device Certificates that are validly authorised within the SMKI for use by Devices within the scope of GBCS and GB Smart Metering shall: not have a well-defined expiration date and so the notafter shall be assigned the GeneralizedTime value of Z; have an empty SubjectName contain SubjectAlternativeName extension which contains a single GeneralName of type OtherName that is further sub-typed as a HardwareModuleName (id-on-hardwaremodulename) as defined in [RFC 4108]. The hwserialnum field shall be set to the Device s Entity Identifier. In adherence to IETF RFC 5280, SubjectAlternativeName shall be marked as critical contain a single Public Key contain a keyusage extension marked as critical, with a value of V1.2 85

86 only one of: digitalsignature; or keyagreement. contain a single policyidentifier in the certificatepolicies extension that refers to the OID applicable to the environment the Device Certificate has been issued in. Requirements applicable to Root OCAs and Issuing-OCAs All Root OCA certificates and Issuing-OCA certificates that are validly authorised within the SMKI for use by CAs shall: have a fixed expiration date in the notafter field; must have a Valid: notbefore field consisting of the time of issue encoded as per [RFC5280] Per [RFC5280], the IssuerName of any certificates MUST be identical to the signer s SubjectName have a globally unique SubjectName contain a single public key except for the Root-OCA where there shall be two public keys. The second public key shall be referred to as the Contingency Key and shall be present in the WrappedApexContingencyKey extension with the meaning of IETF RFC5934. The Contingency Key shall be encrypted as per the requirements of the GBCS. contain a keyusage extension marked as critical and defined as: keycertsign; and crlsign. For Issuing-OCAs, contain at least one policyidentifier in the certificatepolicies extension that refers to the OID(s) valid for usage in GB Smart Metering. For Root-OCA, contain a single policyidentifier in the certificatepolicies extension that refers to the OID for anypolicy. For Issuing-OCAs, contain the basicconstraints extension, with values ca=true, and pathlen=0. This extension shall be marked as critical For Root-OCA, contain the basicconstraints extension, with the value ca=true and pathlen absent (unlimited). This extension shall be marked as critical Requirements applicable to Root DCAs and Issuing-DCAs All Root DCA certificates and Issuing-DCA certificates that are validly authorised within the SMKI for use by the DCA shall: not have a well-defined expiration date and so the notafter shall be assigned the GeneralizedTime value of Z; must have a Valid: notbefore field consisting of the time of issue V1.2 86

87 encoded as per [RFC5280] Per [RFC5280], the IssuerName of any certificates MUST be identical to the signer s SubjectName have a globally unique SubjectName contain a single public key contain a keyusage extension marked as critical and defined as: keycertsign; and crlsign. For Issuing-DCAs contain at least one policyidentifier in the certificatepolicies extension that refers to the OID(s) valid for usage in GB Smart Metering.. For Root-DCA contain a single policyidentifier in the certificatepolicies extension that refers to the OID for anypolicy. For Issuing-DCAs, contain the basicconstraints extension, with values ca=true, and pathlen=0. This extension shall be marked as critical For Root-DCA, contain the basicconstraints extension, with the value ca=true and pathlen absent (unlimited). This extension shall be marked as critical End Entity Organisation Certificate Profile The End Entity Organisation Certificate Profile must comply with the specification laid out in the table 1 Appendix B version The version of the X.509 certificate. Valid certificates shall identify themselves as version serialnumber Certificate serial number, a positive integer of 16 octets. The serialnumber identifies the Certificate, and shall be created by the Issuing-OCA that signs the Certificate. The serialnumber shall be unique in the scope of Certificates signed by the Issuing-OCA signature The identity of the signature algorithm used to sign the certificate. The field is identical to the value of the signaturealgorithm field see section issuer The name of the signer of the certificate. This will be the globally unique name of the Issuing-OCA. The issued credentials contain the authoritykeyidentifier extension as specified in Section and the CA certificates in the Organisation SMKI certificate chain contain the subjectkeyidentifier extension. Adding authoritykeyidentifier and subjectkeyidentifer facilitates certificate path V1.2 87

88 building, which is necessary to validate credentials authoritykeyidentifier To optimise building the correct credential chain, the non-critical Authority Key Identifier extension shall be populated with a unique value as recommended by RFC 5280 and shall be included in all Certificates. The Certificate shall contain a authoritykeyidentifier in the form [0] KeyIdentifier. subjectkeyidentifier The subjectkeyidentifier extension should be included and marked as non-critical in the certificate. The certificate shall contain a subjectkeyidentifier with KeyIdentifier generated as per method (2) of Section of IETF RFC 5280 and so which shall always be 8 octets in length. validity The time period over which the issuer expects the Certificate to be valid for. The validity period is the period of time from notbefore through notafter, inclusive. All times shall be stated in the Universal Coordinated Time (UTC) time zone. Times up to and including 23:59:59 December 31, 2049 UTC shall be encoded as UTCTime as YYMMDDHHmmssZ. Times later than 23:59:59 December 31, 2049 UTC shall be encoded as GeneralizedTime as YYYYMMDDHHmmssZ. notbefore The earliest time a Certificate may be used. This shall be the time the Certificate is created. notafter The latest time a Certificate is expected to be used. The value in a notafter field shall be treated as specified in RFC subject The formatting of this field shall contain a unique X.500 Distinguished Name (DN). This should be the unique trading name of the Organisation. organizationalunitname The organisationalunit attribute of subject shall be populated with the RemotePartyRole code that the Certificate allows the subject of the Certificate to perform. See GBCS for details of RemotePartyRole codes. V1.2 88

89 subjectuniqueid This shall be populated with the 64 bit Entity Identifier of the subject of the Certificate. There will be no subjectuniqueid section; the standard DN component id-at-uniqueidentifier will be used subjectpublickeyinfo The Certificate subjectpublickeyinfo field shall indicate the public key algorithm identifier and the public key in the specified algorithm format as specified in RFC 3279 and RFC The algorithm field in the subjectpublickeyinfo structure shall be use the following identifier: id-ecpublickey OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-x9-62(10045) keytype(2) 1 } id-ecpublickey indicates that the algorithms that can be used with the subject public key are unrestricted. The key is only restricted by the values indicated in the key usage certificate extension. The parameter for id-ecpublickey is as follows and shall always be present: ECParameters ::= CHOICE { namedcurve OBJECT IDENTIFIER -- implicitcurve NULL -- specifiedcurve SpecifiedECDomain } Only the following field in ECParameters shall be used: o namedcurve - identifies all the required values for a particular set of elliptic curve domain parameters to be represented by an object identifier. The namedcurve field in ECParameters uses object identifiers to name well-known curves. The NIST recommended namedcurve is the P-256 curve. The object identifier fo the curve choice to be used in certificates is: secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi- X9-62(10045) curves(3) prime(1) 7 } V1.2 89

90 The subjectpublickey from SubjectPublicKeyInfo is the ECC public key. ECC public keys have the following syntax: ECPoint ::= OCTET STRING Implementations of Elliptic Curve Cryptography according to this document shall only support the uncompressed form The elliptic curve public key (a value of type ECPoint that is an OCTET STRING) is mapped to a subjectpublickey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. The first octet of the OCTET STRING indicates whether the key is compressed or uncompressed. The uncompressed form is indicated by 0x04 (the compressed form is indicated by either 0x02 or 0x03). The public key MUST be rejected if any value other than 0x04 is included in the first octet. signaturealgorithm The signaturealgorithm field shall indicate the CA signature algorithm used to sign this Certificate is as defined in section signaturevalue The OCA s signature of the Certificate is computed using the OCA s private 256-bit ECC certificate signing key using the algorithm identified in When using the Elliptic Curve keys the certificates shall be signed by the OCA using the ECDSA algorithm identified in The structure for ECDSA signatures is as per RFC extensions End Entity Certificates MUST contains the extensions described below. They SHOULD NOT contain any additional extensions: Extensions: certificatepolicy: critical; OID as a policyidentifier (applicable Certificate Policy OID). keyusage: critical; either one of keyagreement or digitalsignature. V1.2 90

91 authoritykeyidentifier subjectkeyidentifier Cryptographic Primitives for Signature Method Signature Method (ECDSA) The ECDSA signature method is defined in NIST FIPS When implementing ECDSA, the SHA-256 message digest algorithm and the P- 256 elliptic curve as defined in FIPS Annex D, D.1.2.3, shall be used. The signature algorithm shall be ecdsa-with-sha256 as specified in RFC 5759 and The algorithm identifier is: ecdsa-with-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 } SHA-256 hash algorithm The hash algorithm used by the Certificate shall be the SHA-256 secure hash algorithm as defined in NIST FIPS Device Certificate Profile The Device Certificate Profile must comply with the specification laid out in Table 2 Appendix B Certificate & Device Certificate Profiles version The version of the X.509 Device Certificate. Valid Device Certificates shall identify themselves as version serialnumber Device Certificate serial number, a positive integer of 16 octets. The serialnumber identifies the Device Certificate, and shall be created by the Issuing-DCA that signs the Device Certificate. The serialnumber shall be unique in the scope of Device Certificates signed by the Issuing-DCA signature The identity of the signature algorithm used to sign the Device Certificate. The field is identical to the value of the signaturealgorithm field see section V1.2 91

92 issuer The name of the signer of the Device Certificate. This will be the globally unique name of the Issuing-DCA. The issued credentials contain the authoritykeyidentifier extension as specified and the DCA Certificates in the Devices SMKI certificate chain contain the subjectkeyidentifier extension. Adding authoritykeyidentifier and subjectkeyidentifer facilitates certificate path building, which is necessary to validate credentials authoritykeyidentifier To optimize building the correct credential chain, the non-critical Authority Key Identifier extension shall be populated with a unique value as recommended by RFC 5280 and shall be included in all device Device Certificates. The Device Certificate shall contain a authoritykeyidentifier in the form [0] KeyIdentifier subjectkeyidentifier The Subject Key Identifier extension should be included and marked as non-critical in the Device Certificate. The Device Certificate shall contain a subjectkeyidentifier with KeyIdentifier generated as per method (2) of Section of IETF RFC 5280 and so which shall always be 8 octets in length validity The time period over which the issuer expects the Device Certificate to be valid for. The validity period is the period of time from notbefore through notafter, inclusive. Device Certificates are expected to operate indefinitely into the future and should use the value Z. Solutions verifying a Device Certificate are expected to accept this value indefinitely. All times shall be stated in the Universal Coordinated Time (UTC) time zone. Times up to and including 23:59:59 December 31, 2049 UTC shall be encoded as UTCTime as YYMMDDHHmmssZ. Times later than 23:59:59 December 31, 2049 UTC shall be encoded as GeneralizedTime as YYYYMMDDHHmmssZ. notbefore The earliest time a Device Certificate may be used. This shall be the time the Device Certificate is created. V1.2 92

93 notafter The latest time a Device Certificate is expected to be used. Device Certificates are expected to operate indefinitely into the future and should use the value Z. Solutions verifying a Device Certificate are expected to accept this value indefinitely subject This field must be empty subjectaltname The non-critical subjectaltname extension shall contain a single GeneralName of type OtherName that is further sub-typed as a HardwareModuleName (id-on-hardwaremodulename) as defined in [RFC 4108]. The hwserialnum field shall be set to the Device s Entity Identifier subjectpublickeyinfo The Device Certificate subjectpublickeyinfo field shall indicate the public key algorithm identifier and the public key in the specified algorithm format as specified in RFC 3279 and RFC The algorithm field in the subjectpublickeyinfo structure shall be use the following identifier: id-ecpublickey OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-x9-62(10045) keytype(2) 1 } id-ecpublickey indicates that the algorithms that can be used with the subject public key are unrestricted. The key is only restricted by the values indicated in the key usage Device Certificate extension (see 0). The parameter for id-ecpublickey is as follows and shall always be present: ECParameters ::= CHOICE { namedcurve OBJECT IDENTIFIER -- implicitcurve NULL -- specifiedcurve SpecifiedECDomain } Only the following field in ECParameters shall be used: o namedcurve - identifies all the required values for a particular V1.2 93

94 set of elliptic curve domain parameters to be represented by an object identifier. The namedcurve field in ECParameters uses object identifiers to name well-known curves. The NIST recommended namedcurve is the P-256 curve. The object identifier for the curve choice to be used in Device Certificates is: secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi- X9-62(10045) curves(3) prime(1) 7 } The subjectpublickey from SubjectPublicKeyInfo is the ECC public key. ECC public keys have the following syntax: ECPoint ::= OCTET STRING Implementations of Elliptic Curve Cryptography according to this document shall only support the uncompressed form. The elliptic curve public key (a value of type ECPoint that is an OCTET STRING) is mapped to a subjectpublickey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. The first octet of the OCTET STRING indicates whether the key is compressed or uncompressed. The uncompressed form is indicated by 0x04 (the compressed form is indicated by either 0x02 or 0x03). The public key MUST be rejected if any value other than 0x04 is included in the first octet signaturealgorithm The signaturealgorithm field shall indicate the DCA signature algorithm used to sign this Device Certificate is as defined in section signaturevalue The DCA s signature of the Device Certificate is computed using the DCA s private 256-bit ECC Device Certificate signing key using the algorithm identified in When using the Elliptic Curve keys the Device Certificates shall be signed by the DCA using the ECDSA algorithm identified in The structure for ECDSA signatures is as per RFC V1.2 94

95 extensions Device Device Certificates MUST contain the extensions described below. They SHOULD NOT contain any additional extensions: certificatepolicy: critical; (applicable Certificate Policy OID). subjectalternativename: critical; one GeneralName of type OtherName of hardwaremodulename. keyusage: critical; either keyagreement or digitalsignature. authoritykeyidentifier subjectkeyidentifier Cryptographic Primitives for Signature Method Signature Method (ECDSA) The ECDSA signature method is defined in NIST FIPS When implementing ECDSA, the SHA-256 message digest algorithm and the P- 256 elliptic curve as defined in FIPS Annex D, D.1.2.3, shall be used. The signature algorithm shall be ecdsa-with-sha256 as specified in RFC 5759 and The algorithm identifier is: ecdsa-with-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 } SHA-256 hash algorithm The hash algorithm used by the Device Certificate shall be the SHA-256 secure hash algorithm as defined in NIST FIPS Recovery Certificate Profile As per the End Entity Organisation Certificate Profile defined in section Root DCA Certificate Profile The Root-BA Certificate Profile must comply with the specification laid out in Table 3 in Appendix B Certificate & Device Certificate Profiles. These certificates are the root of trust for the Devices SMKI. V1.2 95

96 version The version of the X.509 Certificate. Valid Certificates shall identify themselves as version serialnumber Certificate serial number, a positive integer of 16 octets. The serialnumber identifies the Certificate, and shall be created by the Issuing-DCA that signs the Certificate (self-signed by Root). The serialnumber shall be unique in the scope of Certificates signed by the Issuing-DCA signature The identity of the signature algorithm used to sign the Certificate. The field is identical to the value of the signaturealgorithm field see issuer The name of the signer of the Certificate. This will be the globally unique name of the Issuing-DCA. This will be the same as the SubjectName as it is self-signed by the Root-DCA. The issued credentials contain the subjectkeyidentifier extension. Adding subjectkeyidentifer facilitates certificate path building, which is necessary to validate credentials. subjectkeyidentifier The Subject Key Identifier extension should be included and marked as non-critical in the Certificate. The Certificate shall contain a subjectkeyidentifier with KeyIdentifier generated as per method (2) of Section of IETF RFC 5280 and so which shall always be 8 octets in length. validity The time period over which the issuer expects the Certificate to be valid for. The validity period is the period of time from notbefore through notafter, inclusive. Root-DCA certificates are expected to operate indefinitely into the future and should use the value Z. Solutions verifying a Root- DCA certificate are expected to accept this value indefinitely. All times shall be stated in the Universal Coordinated Time (UTC) time zone. Times up to and including 23:59:59 December 31, 2049 UTC shall be encoded as UTCTime as YYMMDDHHmmssZ. V1.2 96

97 Times later than 23:59:59 December 31, 2049 UTC shall be encoded as GeneralizedTime as YYYYMMDDHHmmssZ. notbefore The earliest time a Certificate may be used. This shall be the time the Certificate is created. notafter The latest time a Certificate is expected to be used. Certificates are expected to operate indefinitely into the future and should use the value Z. Solutions verifying a Certificate are expected to accept this value indefinitely. subject This field must be populated with the globally unique name of the Root- DCA. subjectpublickeyinfo The Certificate s subjectpublickeyinfo field shall indicate the public key algorithm identifier and the public key in the specified algorithm format as specified in RFC 3279 and RFC The algorithm field in the subjectpublickeyinfo structure shall be use the following identifier: id-ecpublickey OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-x9-62(10045) keytype(2) 1 } id-ecpublickey indicates that the algorithms that can be used with the subject public key are unrestricted. The key is only restricted by the values indicated in the key usage Certificate extension (see 0). The parameter for id-ecpublickey is as follows and shall always be present: ECParameters ::= CHOICE { namedcurve OBJECT IDENTIFIER -- implicitcurve NULL -- specifiedcurve SpecifiedECDomain } Only the following field in ECParameters shall be used: o namedcurve - identifies all the required values for a particular set of elliptic curve domain parameters to be represented by an V1.2 97

98 object identifier. The namedcurve field in ECParameters uses object identifiers to name well-known curves. The NIST recommended namedcurve is the P-256 curve. The object identifier for the curve choice to be used in Certificates is: secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi- X9-62(10045) curves(3) prime(1) 7 } The subjectpublickey from SubjectPublicKeyInfo is the ECC public key. ECC public keys have the following syntax: ECPoint ::= OCTET STRING Implementations of Elliptic Curve Cryptography according to this document shall only support the uncompressed form The elliptic curve public key (a value of type ECPoint that is an OCTET STRING) is mapped to a subjectpublickey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. The first octet of the OCTET STRING indicates whether the key is compressed or uncompressed. The uncompressed form is indicated by 0x04 (the compressed form is indicated by either 0x02 or 0x03). The public key MUST be rejected if any value other than 0x04 is included in the first octet. signaturealgorithm The signaturealgorithm field shall indicate the DCA signature algorithm used to sign this Certificate as defined in section signaturevalue The DCA s signature of the Certificate is computed using the DCA s private 256-bit ECC Device Certificate signing key using the algorithm identified in When using the Elliptic Curve keys the Device Certificates shall be signed by the DCA using the ECDSA algorithm identified in The V1.2 98

99 structure for ECDSA signatures is as per RFC extensions Certificates MUST contain the extensions described below and MUST have the name form as described. They SHOULD NOT contain any additional extensions: Extensions o o o o certificatepolicy: critical; 1:anyPolicy keyusage: critical; keycertsign, crlsign basicconstraints: critical; ca=true, pathlen absent (unlimited) subjectkeyidentifer Cryptographic Primitives for Signature Method Signature Method (ECDSA) The ECDSA signature method is defined in NIST FIPS When implementing ECDSA, the SHA-256 message digest algorithm and the P- 256 elliptic curve as defined in FIPS Annex D, D.1.2.3, shall be used. The signature algorithm shall be ecdsa-with-sha256 as specified in RFC 5759 and The algorithm identifier is: ecdsa-with-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 } SHA-256 hash algorithm The hash algorithm used by the Certificate shall be the SHA-256 secure hash algorithm as defined in NIST FIPS Root OCA Profile The Root-OCA Profile must comply with the specification laid out in Table 4 in Appendix B Certificate & Device Certificate Profiles. These certificates are the root of trust for the Organisation SMKI version The version of the X.509 Certificate. Valid Certificates shall identify themselves as version 3. V1.2 99

100 serialnumber Certificate serial number, a positive integer of up to 16 octets. The serialnumber identifies the Certificate, and shall be created by the Issuing-OCA that signs the Certificate (self-signed by Root). The serialnumber shall be unique in the scope of Certificates signed by the Issuing-OCA signature The identity of the signature algorithm used to sign the Certificate. The field is identical to the value of the signaturealgorithm field see issuer The name of the signer of the Certificate. This will be the globally unique name of the Issuing-OCA. This will be the same as the SubjectName as it is self-signed by the Root-OCA The issued credentials contain the subjectkeyidentifier extension. Adding subjectkeyidentifer facilitates certificate path building, which is necessary to validate credentials. subjectkeyidentifier The Subject Key Identifier extension should be included and marked as non-critical in the Certificate. The Certificate shall contain a subjectkeyidentifier with KeyIdentifier generated as per method (2) of Section of IETF RFC 5280 and so which shall always be 8 octets in length. validity The time period over which the issuer expects the Certificate to be valid for. The validity period is the period of time from notbefore through notafter, inclusive. All times shall be stated in the Universal Coordinated Time (UTC) time zone. Times up to and including 23:59:59 December 31, 2049 UTC shall be encoded as UTCTime as YYMMDDHHmmssZ. Times later than 23:59:59 December 31, 2049 UTC shall be encoded as GeneralizedTime as YYYYMMDDHHmmssZ. notbefore The earliest time a Certificate may be used. This shall be the time the Certificate is created. notafter The latest time a Certificate is expected to be used. The value in a notafter field shall be treated as specified in RFC V

101 subject This field must be populated with the globally unique name of the Root- OCA. subjectpublickeyinfo The Certificate s subjectpublickeyinfo field shall indicate the public key algorithm identifier and the public key in the specified algorithm format as specified in RFC 3279 and RFC The algorithm field in the subjectpublickeyinfo structure shall be use the following identifier: id-ecpublickey OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-x9-62(10045) keytype(2) 1 } id-ecpublickey indicates that the algorithms that can be used with the subject public key are unrestricted. The key is only restricted by the values indicated in the key usage Certificate extension (see ). The parameter for id-ecpublickey is as follows and shall always be present: ECParameters ::= CHOICE { namedcurve OBJECT IDENTIFIER -- implicitcurve NULL -- specifiedcurve SpecifiedECDomain } Only the following field in ECParameters shall be used: o namedcurve - identifies all the required values for a particular set of elliptic curve domain parameters to be represented by an object identifier. The namedcurve field in ECParameters uses object identifiers to name well-known curves. The NIST recommended namedcurve is the P-256 curve. The object identifier for the curve choice to be used in Certificates is: secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi- X9-62(10045) curves(3) prime(1) 7 } V

102 The subjectpublickey from SubjectPublicKeyInfo is the ECC public key. ECC public keys have the following syntax: ECPoint ::= OCTET STRING Implementations of Elliptic Curve Cryptography according to this document shall only support the uncompressed form. The elliptic curve public key (a value of type ECPoint that is an OCTET STRING) is mapped to a subjectpublickey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING The first octet of the OCTET STRING indicates whether the key is compressed or uncompressed. The uncompressed form is indicated by 0x04 (the compressed form is indicated by either 0x02 or 0x03). The public key MUST be rejected if any value other than 0x04 is included in the first octet. signaturealgorithm The signaturealgorithm field shall indicate the OCA signature algorithm used to sign this Certificate as defined in section signaturevalue The OCA s signature of the Certificate is computed using the OCA s private 256-bit ECC Certificate signing key using the algorithm identified in section When using the Elliptic Curve keys the Certificates shall be signed by the CA using the ECDSA algorithm identified in section The structure for ECDSA signatures is as per RFC extensions Certificates MUST contain the extensions described below and MUST have the name form as described. They SHOULD NOT contain any additional extensions: Extensions o certificatepolicy: critical; 1:anyPolicy o keyusage: critical; keycertsign, crlsign o basicconstraints: critical; ca=true, pathlen absent (unlimited) o subjectkeyidentifer o WrappedApexContingencyKey, with both fields populated in line with the requirements of the GBCS V

103 Cryptographic Primitives for Signature Method Signature Method (ECDSA) The ECDSA signature method is defined in NIST FIPS When implementing ECDSA, the SHA-256 message digest algorithm and the P- 256 elliptic curve as defined in FIPS Annex D, D.1.2.3, shall be used. The signature algorithm shall be ecdsa-with-sha256 as specified in RFC 5759 and The algorithm identifier is: ecdsa-with-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 } SHA-256 hash algorithm The hash algorithm used by the Certificate shall be the SHA-256 secure hash algorithm as defined in NIST FIPS Issuing DCA Profile The Issuing-DCA Profile must comply with the specification laid out in the Table 5 in Appendix B Certificate & Device Certificate Profiles version The version of the X.509 Certificate. Valid Certificates shall identify themselves as version 3. serialnumber Certificate serial number, a positive integer of 16 octets. The serialnumber identifies the Certificate, and shall be created by the Issuing-DCA that signs the Certificate. The serialnumber shall be unique in the scope of Certificates signed by the Issuing-DCA. signature The identity of the signature algorithm used to sign the Certificate. The field is identical to the value of the signaturealgorithm field see issuer The name of the signer of the Certificate. This will be the globally unique name of the Issuing-DCA. The issued credentials contain the authoritykeyidentifier extension as specified in , and the DCA certificates in the Devices SMKI certificate chain contain the subjectkeyidentifier extension. Adding V

104 authoritykeyidentifier and subjectkeyidentifer facilitates certificate path building, which is necessary to validate credentials subjectkeyidentifier The Subject Key Identifier extension should be included and marked as non-critical in the Certificate. The Certificate shall contain a subjectkeyidentifier with KeyIdentifier generated as per method (2) of Section of IETF RFC 5280 and so which shall always be 8 octets in length authoritykeyidentifier To optimize building the correct credential chain, the non-critical Authority Key Identifier extension shall be populated with a unique value as recommended by RFC 5280 and shall be included in all device Certificates. The Certificates shall contain a authoritykeyidentifier in the form [0] KeyIdentifier validity The time period over which the issuer expects the Certificate to be valid for. The validity period is the period of time from notbefore through notafter, inclusive. Root-DCA certificates are expected to operate indefinitely into the future and should use the value Z. Solutions verifying a Root- BA certificate are expected to accept this value indefinitely. All times shall be stated in the Universal Coordinated Time (UTC) time zone. Times up to and including 23:59:59 December 31, 2049 UTC shall be encoded as UTCTime as YYMMDDHHmmssZ. Times later than 23:59:59 December 31, 2049 UTC shall be encoded as GeneralizedTime as YYYYMMDDHHmmssZ. notbefore The earliest time a Certificate may be used. This shall be the time the Certificate is created. notafter The latest time a Certificate is expected to be used. Certificates are expected to operate indefinitely into the future and should use the value Z. Solutions verifying a Certificate are expected to accept this value indefinitely subject This field must be populated with the globally unique name of the Root- V

105 DCA subjectpublickeyinfo The Certificate s subjectpublickeyinfo field shall indicate the public key algorithm identifier and the public key in the specified algorithm format as specified in RFC 3279 and RFC The algorithm field in the subjectpublickeyinfo structure shall be use the following identifier: id-ecpublickey OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-x9-62(10045) keytype(2) 1 } id-ecpublickey indicates that the algorithms that can be used with the subject public key are unrestricted. The key is only restricted by the values indicated in the key usage Certificate extension (see ). The parameter for id-ecpublickey is as follows and shall always be present: ECParameters ::= CHOICE { namedcurve OBJECT IDENTIFIER -- implicitcurve NULL -- specifiedcurve SpecifiedECDomain } Only the following field in ECParameters shall be used: o namedcurve - identifies all the required values for a particular set of elliptic curve domain parameters to be represented by an object identifier. The namedcurve field in ECParameters uses object identifiers to name well-known curves. The NIST recommended namedcurve is the P-256 curve. The object identifier for the curve choice to be used in Certificates is: secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi- X9-62(10045) curves(3) prime(1) 7 } The subjectpublickey from SubjectPublicKeyInfo is the ECC public key. ECC public keys have the following syntax: V

106 ECPoint ::= OCTET STRING Implementations of Elliptic Curve Cryptography according to this document shall only support the uncompressed form. The elliptic curve public key (a value of type ECPoint that is an OCTET STRING) is mapped to a subjectpublickey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. The first octet of the OCTET STRING indicates whether the key is compressed or uncompressed. The uncompressed form is indicated by 0x04 (the compressed form is indicated by either 0x02 or 0x03). The public key MUST be rejected if any value other than 0x04 is included in the first octet signaturealgorithm The signaturealgorithm field shall indicate the BA signature algorithm used to sign this Certificate as defined in section signaturevalue The BA s signature of the Certificate is computed using the BA s private 256-bit ECC Device Certificate signing key using the algorithm identified in When using the Elliptic Curve keys the Device Certificates shall be signed by the DCA using the ECDSA algorithm identified in The structure for ECDSA signatures is as per RFC extensions Issuing-OCA certificates must contain the extensions described below and MUST have the name form as described. They SHOULD NOT contain any additional extensions: o certificatepolicy: critical; 1:at least one policyidentifier in the certificatepolicies extension that refers to the OID(s) valid for usage in the GBSM environments o keyusage: critical; keycertsign, crlsign o basicconstraints: critical; ca=true, pathlen=0 o subjectkeyidentifer o authoritykeyidentifier Cryptographic Primitives for Signature Method Signature Method (ECDSA) The ECDSA signature method is defined in NIST FIPS When implementing ECDSA, the SHA-256 message digest algorithm and the P- V

107 256 elliptic curve as defined in FIPS Annex D, D.1.2.3, shall be used. The signature algorithm shall be ecdsa-with-sha256 as specified in RFC 5759 and The algorithm identifier is: ecdsa-with-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 } SHA-256 hash algorithm The hash algorithm used by the Certificate shall be the SHA-256 secure hash algorithm as defined in NIST FIPS Issuing OCA Profile The Issuing-OCA Profile must comply with the specification laid out in the Table 6 - in Appendix B Certificate & Device Certificate Profiles version The version of the X.509 Certificate. Valid Certificates shall identify themselves as version serialnumber Certificate serial number, a positive integer of 16 octets. The serialnumber identifies the Certificate, and shall be created by the Issuing-OCA that signs the Certificate. The serialnumber shall be unique in the scope of Certificates signed by the Issuing-OCA signature The identity of the signature algorithm used to sign the Certificate. The field is identical to the value of the signaturealgorithm field see issuer The name of the signer of the Certificate. This will be the globally unique name of the Issuing-OCA. The issued credentials contain the authoritykeyidentifier extension as specified in and the OCA certificates in the Organisation SMKI certificate chain contain the subjectkeyidentifier extension. Adding authoritykeyidentifier and subjectkeyidentifer facilitates certificate path building, which is necessary to validate credentials. subjectkeyidentifier The Subject Key Identifier extension should be included and marked as non-critical in the Certificate. The Certificate shall contain a subjectkeyidentifier with KeyIdentifier generated as per method (2) of Section of IETF RFC 5280 and so which shall always be 8 octets in length. V

108 authoritykeyidentifier To optimize building the correct credential chain, the non-critical Authority Key Identifier extension shall be populated with a unique value as recommended by RFC 5280 and shall be included in all device Certificates. The Certificates shall contain a authoritykeyidentifier in the form [0] KeyIdentifier. validity The time period over which the issuer expects the Certificate to be valid for. The validity period is the period of time from notbefore through notafter, inclusive. All times shall be stated in the Universal Coordinated Time (UTC) time zone. Times up to and including 23:59:59 December 31, 2049 UTC shall be encoded as UTCTime as YYMMDDHHmmssZ. Times later than 23:59:59 December 31, 2049 UTC shall be encoded as GeneralizedTime as YYYYMMDDHHmmssZ. notbefore The earliest time a Certificate may be used. This shall be the time the Certificate is created. notafter The latest time a Certificate is expected to be used. The value in a notafter field shall be treated as specified in RFC subject This field must be populated with the globally unique name of the Root- OCA subjectpublickeyinfo The Certificate s subjectpublickeyinfo field shall indicate the public key algorithm identifier and the public key in the specified algorithm format as specified in RFC 3279 and RFC The algorithm field in the subjectpublickeyinfo structure shall be use the following identifier: id-ecpublickey OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) ansi-x9-62(10045) keytype(2) 1 } id-ecpublickey indicates that the algorithms that can be used with the subject public key are unrestricted. The key is only restricted by the values indicated in the key usage Certificate extension (see ) The parameter for id-ecpublickey is as follows and shall always be present: V

109 ECParameters ::= CHOICE { namedcurve OBJECT IDENTIFIER -- implicitcurve NULL -- specifiedcurve SpecifiedECDomain } Only the following field in ECParameters shall be used: o namedcurve - identifies all the required values for a particular set of elliptic curve domain parameters to be represented by an object identifier. The namedcurve field in ECParameters uses object identifiers to name well-known curves. The NIST recommended namedcurve is the P-256 curve. The object identifier for the curve choice to be used in Certificates is: secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi- X9-62(10045) curves(3) prime(1) 7 } The subjectpublickey from SubjectPublicKeyInfo is the ECC public key. ECC public keys have the following syntax: ECPoint ::= OCTET STRING Implementations of Elliptic Curve Cryptography according to this document shall only support the uncompressed form. The elliptic curve public key (a value of type ECPoint that is an OCTET STRING) is mapped to a subjectpublickey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. The first octet of the OCTET STRING indicates whether the key is compressed or uncompressed. The uncompressed form is indicated by 0x04 (the compressed form is indicated by either 0x02 or 0x03). The public key MUST be rejected if any value other than 0x04 is included in the first octet signaturealgorithm The signaturealgorithm field shall indicate the OCA signature algorithm used to sign this Certificate as defined in section signaturevalue V

110 The OCA s signature of the Certificate is computed using the OCA s private 256-bit ECC Certificate signing key using the algorithm identified in When using the Elliptic Curve keys the Certificates shall be signed by the CA using the ECDSA algorithm identified in The structure for ECDSA signatures is as per RFC extensions Issuing-CA certificates must contain the extensions described below and MUST have the name form as described. They SHOULD NOT contain any additional extensions: certificatepolicy: critical; 1:at least one policyidentifier in the certificatepolicies extension that refers to the OID(s) valid for usage in the GBSM environments keyusage: critical; keycertsign, crlsign basicconstraints: critical; ca=true, pathlen=0 subjectkeyidentifer authoritykeyidentifier Cryptographic Primitives for Signature Method Signature Method (ECDSA) The ECDSA signature method is defined in NIST FIPS When implementing ECDSA, the SHA-256 message digest algorithm and the P- 256 elliptic curve as defined in FIPS Annex D, D.1.2.3, shall be used. The signature algorithm shall be ecdsa-with-sha256 as specified in RFC 5759 and The algorithm identifier is: ecdsa-with-sha256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x9-62(10045) signatures(4) ecdsa-with-sha2(3) 2 } SHA-256 hash algorithm The hash algorithm used by the Certificate shall be the SHA-256 secure hash algorithm as defined in NIST FIPS SMKI Recovery Requirements V

111 4.150 Definition of a Recovery Service Based on the details in Appendix D - SMKI Recovery Requirements, the SMKI Contractor will need to work with the PMA to define, test and implement the mechanism and processes for recovery of compromised key pairs issued under the Organisation SMKI (including Root). SMKI Interfaces Interface Definitions The SMKI Contractor shall, define the specification for all interfaces between SMKI and the DCC. As a minimum these shall include: a. Issuing Certification Authorities (ICA) and the Registration Authority portal; b. Registration Authority portal and the Service Providers/Service Users; c. Issuing Device Certificate Authority (DCA) and the Registration Authority portal; d. DCC Registration Authority network (provided by the SMKI Contractor) and the Registration Authority portal; e. Issuing-OCA and the DCC PKI Repository hosted in the DSP infrastructure; f. Issuing-DCA and the DCC PKI Repository hosted in the DSP infrastructure; g. Issuing-DCA and the DCA Root; h. Issuing-OCA and the OCA Root; Additional Testing Requirements Test Strategy & Test Data Strategy The Contractor must supply a detailed test strategy to include and not exclusively the following areas: Objective Test Organisation, Management & Assurance Test Process Test Data, Environments, Tools Resource Management V

112 Dependencies A detailed test data strategy is required, clearly indicating how test data will be prepared that is representative of Production Test Approach A detailed test approach is required to include and not exclusively the following areas: Scope Objectives Deliverables Process Environments Test Management Defect Management Milestones Risks, Issues & Dependencies Test Specification Smart DCC require a detailed description of the Test Scenarios intended to verify the product is fit for purpose and ready for User Acceptance Testing The SMKI Contractor must provide a detailed account of the test environments required for the System, System Integration and User Integration testing phases and how they will interface with the respective DCC Test Environments Test Planning & Scheduling A detailed test plan is required. It shall include and not exclusively the following areas: Scope Features Method Entry & Exit Criteria Item Pass & Fail Criteria Suspension/resumption Criteria Deliverables Environments Milestones & Schedule Risks, Issues & Dependencies The SMKI Contractor must demonstrate through the execution schedule how many test cycles will be required for predicted resolution of defects. The schedule should also factor in the required Test Auditing and Witnessing activities Defect Management V

113 Provide details of how Incidents will be managed by priority once the product has been accepted into User Acceptance Testing, including a suggested approach to resolution, new releases and supporting notes. Furthermore the DCC Test Programme will also require a definition of service levels for defect fixes based on Severity and Priority levels A definition of release management process for test environments must be provided outlining the SMKI Contractor s approach to code releases following defect fixes or changes. The SMKI Contractor must provide an outline of Re-test and Regression test Assurance processes. Part F SMKI Business and Service Requirements 1 Contract Management and Administration This section describes the requirements regarding how the SMKI Contractor and DCC shall work together, including reporting and relationships. 1.1 Contract Approach and Administration The SMKI Contractor shall adopt a partnership approach to working with the DCC The SMKI Contractor will be expected to co-operate with the other DCC Service Providers and work towards delivery of an integrated plan and the timescales contained within The SMKI Contractor shall ensure that the contract is delivered by personnel with the appropriate capacity and capability (i.e.: allocate appropriately qualified/experienced staff) The SMKI Contractor shall provide sufficient resources to ensure delivery of the contract requirements The SMKI Contractor shall supply contract management information in the agreed format at the required intervals It is expected that the SMKI Contractor shall carry out all activities identified in this proposal for the duration of the contract. Should the SMKI Contractor wish to sub-contract any of this work they V

114 must seek the prior consent of Smart DCC. 1.2 Contract Management Prior to Go Live the SMKI Contractor shall attend the weekly project meeting to provide updates on progress against agreed programme milestones Following Go Live the SMKI Contractor s representative shall meet with the nominated representative/s of Smart DCC on a monthly basis. These dates will be agreed in advance The purpose of the contract management meeting is as follows: To review and develop the SMKI service. Promote continuous improvement. Inform the process of strategic planning across current and future services Identify concerns and take action to strengthen services to be delivered To monitor the development of quality assurance measures To monitor the SMKI performance measures To monitor quality improvement plans and in year improvements as necessary Note: this list is not exhaustive. 1.3 Continuous Improvement and Efficiencies Smart DCC require the SMKI Contractor to proactively seek opportunities to improve the way the contract is delivered The SMKI Contractor will be required to demonstrate efficiency improvements through the duration of the contract. 1.4 Collaborative Working The SMKI Contractor is required to work cooperatively with Smart DCC and its other Service Providers, i.e. the DSP and CSPs, to deliver a comprehensive and cohesive service. 1.5 Performance Monitoring The Contractor shall be required to put in place robust performance management arrangements to include business planning according to Contract requirements, (this is within the SMKI Contract Schedule 2.2). V

115 1.5.2 Service performance data shall be made available to SMKI Parties on a weekly basis at a time and day to be agreed during design phase Service performance data shall be collected for each rolling seven day period (e.g. 00:00 Monday to 23:59 Sunday, 00:00 Tuesday to 23:59 Monday) This information shall be available via a Dashboard Service which will enable each requestor to see the: i. Total volumes processed (but organisation shall not be provided) by the Service and the performance of each type of request and ii. Volumes processed for the Requestor s organisation and the performance of each types of request The Requestor shall be able to choose to see data by: (a) Day (b) Week (rolling 7 days) (c) Month (calendar) Each data set shall clearly differentiate the volumes and performance of the Batch Service, Singe Request Service and System to System Service. The online RA System shall at all times inform the Requestor of the volumes of Batch Requests processed or queued for processing within the current 24 hour period (07:00 to 06:59). 1.6 Policies The SMKI Contractor will Ensure all premises/activities comply with current Health and Safety legislation The SMKI Contractor will align its information security policies with those of DCC The Contractor will make available on request Smart DCC any of their following policies on request: Data Management / Data Protection Security Security Health & Safety Environmental Equality & Diversity Quality Legal & Regulatory V

116 2 Service Management Smart DCC have a requirement for the SMKI Contractor to deliver a systematic and professional approach to the service management of the SMKI services. 2.1 Service Management General The SMKI Contractor shall provide a service management system which is accessible to the DCC Service Management team through a secure portal which is accessible 24 hours x 7 days a week x 365 days a year Smart DCC require that the service management process and functions are carried out within the UK Full Service Management provisions will be provided and documented based upon ITIL V3 lifecycle The SMKI Contractors service management processes and functions will align with the DCC Service Management service. See Appendix I for the DCC Service Model The SMKI Contractor is required to provide a robust change management process that aligns with the DCC processes The SMKI Contractor is required to identify, create and deliver relevant training, knowledge and materials, including FAQ s to the DCC service management function Full auditing of all services shall be maintained for the duration of the contract The SMKI Contractor must maintain a plan of scheduled maintenance windows and effectively communicate this to Smart DCC within agreed timescales The SMKI Contractor must have a structured approach to patch/upgrade schedules which is aligned to DCC release schedules The SMKI Contractor shall define and gain approval of all SLA s supporting the SMKI service with the DCC prior to service Go-Live Service Level Agreements will be defined for the issuance of Device Certificates and Certificates. These SLAs will be submitted to the Policy Management Authority for approval. See Appendix C. 2.2 Contractor Service Desk nd line support calls must be handled directly by the SMKI Contractor service desk Contact to the SMKI Contractors service desk must be by and telephone as a minimum Smart DCC require the SMKI Contractor s Service desk to be technically trained in the solution provided The SMKI Contractor will provision 2 nd and 3 rd line support for SMKI V

117 issues raised on the DCC service desk. 2.3 Service Management - Management The Contractor shall provide monthly reporting to include as a minimum, details of incidents, MIM, changes, problems, service requests, availability, capacity, utilisation (such as CPU, memory) and performance measures that have occurred during the period, service levels achieved, full details for failed measures and MIM there may be a requirement during peak periods to produce some reports more frequently Smart DCC require a weekly dashboard service to provide for performance data, to include as a minimum total volumes processed and separately total volumes per requester organisation. It must clearly show batch service, single request service and system to system request Smart DCC requires real time dashboard detailing status of service and outstanding incidents as a minimum. 2.4 Service Management Measures The Contractor is required to provide service availability as detailed in Appendix C Volume and Performance. 2.5 Back Up and Recovery Smart DCC require that the SMKI service is restored within 12 hours in the event of a failure Smart DCC requires the SMKI Contractor to create a full backup process to include frequency, offsite storage and recovery details Smart DCC require that the SMKI Contractor provides robust business continuity and disaster recovery plan that are aligned to the overall DCC BCDR Plan. Part G SMKI Implementation and Programme Requirements 1 The SMKI service forms an integral component of the overall DCC. 2 Implementation of the SMKI service must align with programme: timescales (see Section C SMKI Context) delivery approach design approach governance structures. V

118 3 Project and Programme Management Requirements 3.1 Project and Programme Management Requirements The SMKI Contractor shall utilise a structured project/programme management approach to the delivery of requirements and reporting progress to DCC The SMKI Contractor shall produce a Project Initiation Document (PID) for DCC authorisation which will detail how the SMKI Service will be delivered The SMKI Contractor shall produce a mobilisation plan for DCC authorisation which will detail how the SMKI Contractor project/team will be mobilised The SMKI Contractor shall produce a detailed implementation plan for DCC authorisation covering design, build, testing and operational stages. This shall be maintained and updated throughout the course of the project The SMKI Contractor shall produce stage plans (Design, Build etc...) for DCC authorisation 40 working days in advance of each stage. These shall be maintained and updated throughout the course of the project The SMKI Contractor shall produce weekly progress reports for the DCC Programme Management Office The SMKI Contractor shall adhere to the DCC Programme Governance arrangements 3.2 Design Requirements The SMKI Contractor shall utilise a structured approach and processes to the design of the SMKI service The SMKI Contractor shall align its design approach and processes to the DCC design approach processes The SMKI Contractor shall participate fully in DCC design governance and forums The Contractor shall adopt DCC s architectural standards (TOGAF v9) in production of its design documentation and artefacts The Contractor shall ensure that the SMKI service design aligns with the overall DCC service design. 3.3 Collaborative Working The Contractor shall work collaboratively with DCC, its Service Providers and Service Users during the design, build, test and ongoing operation of the SMKI service. V

119 3.3.2 The Contractor shall co-locate at DCC offices to participate in design and programme governance processes On request, the Contractor shall make space available for DCC resources to visit and work at the facilities of the Contractor. Part I SMKI Required Products 1 The SMKI Contractor must ensure that the required products as stated in Part I section 2 are produced and delivered by the required due date. 2 SMKI Product List: Ref Document Name Consultation required? Deadline (milestone) Responsible for Production SC1 SMKI High Level Design (HLD) Document Yes 30/05/2014 SMKI Contractor SC2 PKI Disclosure Statement No 31/07/2014 SMKI Contractor SC3 SMKI Low Level Design (LLD) Document No 24/06/2014 SMKI Contractor SC4 Certificate Lifecycle Management Yes 31/07/2014 SMKI Contractor SC5 Assurance Scheme Compliance No 01/07/2015 SMKI Contractor SC6 SMKI & Repository Entry Guide Yes 31/07/2014 SMKI Contractor SC7 SMKI Pre-Integration Test Approach Document Yes 22/07/2014 SMKI Contractor SC8 SMKI Service Code of Connection Yes 31/07/2014 SMKI Contractor SC9 SMKI Service Interface Specification Yes 31/07/2014 SMKI Contractor SC10 Registration Policies and Procedures Yes 31/07/2014 SMKI Contractor SC11 Certificate Practice Statement (Organisation) No 15/08/2014 SMKI Contractor SC12 Certificate Practice Statement (Device) No 15/08/2014 SMKI Contractor SC13 Subscriber Agreements Yes 31/07/2014 SMKI Contractor SC14 Relying Party Agreements Yes 31/07/2014 SMKI Contractor SC15 Recovery Process Yes 31/07/2014 SMKI Contractor V

120 APPENDIX A - GLOSSARY Glossary appears in Schedule 1.1 APPENDIX B CERTIFICATE & DEVICE CERTIFICATE PROFILES Please note: the requirements associated with these tables are at Section of this document. Table 1 - End Entity Organisation Certificate Profile Field Name RFC 5759/5280 Type Value version Integer V3 serialnumber Integer Positive Integer of 16 Octets Signature AlgorithmIdentifier SHA256 with ECDSA Issuer Name Globally unique name of Issuing-CA Authoritykeyidentifier KeyIdentifier A unique value that matches the subjectkeyidentifier of the issuer s credential subjectkeyidentifier KeyIdentifier Provides a means for identifying certificates containing the particular public key used in an application notbefore Time Creation time of the certificate notafter Time Expiry time of the certificate Subject Name Name of the subject organizationalunitname Sub-type of Name Remote Party Role Code of the subject of the Certificate subjectuniqueid UniqueIdentifier The 64 bit Entity Identifier of the subject of the Certificate subjectpublickeyinfo SubjectPublicKeyInfo The subject s public key V

121 Extensions Extensions Critical and non-critical extensions signaturealgorithm AlgorithmIdentifier SHA256 with ECDSA signaturevalue BIT STRING Subject certificate signature Table 2 - Device Certificate Profile Field Name RFC 5759/5280 Type Value Version Integer V3 serialnumber Integer Positive Integer of 16 Octets Signature AlgorithmIdentifier SHA256 with ECDSA Issuer Name Globally unique name of Issuing-BA Authoritykeyidentifier KeyIdentifier A unique value that matches the subjectkeyidentifier of the issuer s credential subjectkeyidentifier KeyIdentifier Provides a means for identifying certificates containing the particular public key used in an application notbefore Time Creation time of the Device Certificate notafter Time shall be assigned the GeneralizedTime value of Z Subject Name Empty subjectaltname OtherName contains a single GeneralName of type OtherName that is further sub-typed as a HardwareModuleName (id-on- HardwareModuleName) as defined in [RFC 4108]. The hwserialnum field shall be set to the Device s Entity Identifier subjectpublickeyinfo SubjectPublicKeyInfo The subject s public key Extensions Extensions Critical and non-critical extensions V

122 signaturealgorithm AlgorithmIdentifier SHA256 with ECDSA signaturevalue BIT STRING Subject Device Certificate signature Table 3 - Root-DCA Certificate Profile Field Name RFC 5759/5280 Type Value Version Integer V3 serialnumber Integer Positive Integer of up to 8 Octets Signature AlgorithmIdentifier SHA256 with ECDSA Issuer Name Globally unique name of Root-BA subjectkeyidentifier KeyIdentifier A unique value that matches the subjectkeyidentifier of the issuer s credential notbefore Time Creation time of the Certificate notafter Time shall be assigned the GeneralizedTime value of Z Subject Name Globally unique name of Root-BA (same as Issuer name) subjectpublickeyinfo SubjectPublicKeyInfo The subject s public key Extensions Extensions Critical and non-critical extensions signaturealgorithm AlgorithmIdentifier SHA256 with ECDSA signaturevalue BIT STRING Subject Certificate signature V

123 Table 4 - Root-OCA Profile Field Name RFC 5759/5280 Type Value Version Integer V3 serialnumber Integer Positive Integer of 16 Octets Signature AlgorithmIdentifier SHA256 with ECDSA Issuer Name Globally unique name of Root-CA subjectkeyidentifier KeyIdentifier A unique value that matches the subjectkeyidentifier of the issuer s credential notbefore Time Creation time of the certificate notafter Time Expiry time of the certificate Subject Name Globally unique name of Root-CA (same as Issuer name) subjectpublickeyinfo SubjectPublicKeyInfo The subject s public key WrappedApexContinge ncykey ApexContingencyKey The subject s protected (encrypted) public key used for recovery purposes, Extensions Extensions Critical and non-critical extensions signaturealgorithm AlgorithmIdentifier SHA256 with ECDSA signaturevalue BIT STRING Subject certificate signature Table 5 - Issuing-DCA Profile Field Name RFC 5759/5280 Type Value version Integer V3 serialnumber Integer Positive Integer of 16 Octets Signature AlgorithmIdentifier SHA256 with ECDSA V

124 Issuer Name Globally unique name of Root-BA subjectkeyidentifier KeyIdentifier A unique value that matches the subjectkeyidentifier of the issuer s credential authoritykeyidentifier KeyIdentifier A unique value that matches the subjectkeyidentifier of the issuer s credential notbefore Time Creation time of the certificate notafter Time shall be assigned the GeneralizedTime value of Z Subject Name Globally unique name of Issuing-BA subjectpublickeyinfo SubjectPublicKeyInfo The subject s public key Extensions Extensions Critical and non-critical extensions signaturealgorithm AlgorithmIdentifier SHA256 with ECDSA signaturevalue BIT STRING Subject certificate signature Table 6 - Issuing-OCA Profile Field Name RFC 5759/5280 Type Value version Integer V3 serialnumber Integer Positive Integer of 16 Octets Signature AlgorithmIdentifier SHA256 with ECDSA Issuer Name Globally unique name of Root-CA subjectkeyidentifier KeyIdentifier A unique value that matches the subjectkeyidentifier of the issuer s credential Authoritykeyidentifier KeyIdentifier A unique value that matches the subjectkeyidentifier of the issuer s credential V

125 notbefore Time Creation time of the certificate notafter Time Expiry time of the certificate Subject Name Globally unique name of Issuing-CA subjectpublickeyinfo SubjectPublicKeyInfo The subject s public key Extensions Extensions Critical and non-critical extensions signaturealgorithm AlgorithmIdentifier SHA256 with ECDSA signaturevalue BIT STRING Subject certificate signature V

126 APPENDIX C VOLUME AND PERFORMANCE This appendix describes the volume and performance requirements that the SMKI Contractor must adhere to. It will form the foundation of the core SLAs during the term of agreement. Devices It is expected that at full operation, there will be up to 53 million Gas and Electricity Smart Metering Devices, in addition to 30 million Communications Hubs, and 30 million Gas Proxies, each requiring the processing of four Device Certificate Documents. The expected minimum total is therefore 452 million; as a result the Contractor solution is required to cater for up to 440 million Device certificates. The initial two Device Certificate Documents will be installed on the Device at manufacture, and must therefore be available at the point of manufacture. Device Certificate Document initial signing will be supported using the online Registration Agent (RA) System. Submissions will be by individual Device Certificate Signing request or via batch Device Certificate Signing Requests. Following installation, installed Devices will re-key Private Keys, and Device Certificate Documents will need to be resigned by the Device Certificate Authority. This will take place via a System to System interface. A. Device Certificate Document Volumes All estimates are indicative and any solution needs to be scalable The early periods of Smart Metering will see large volumes of Device manufacture and installation ( Peak Period ) during roll-out, with lower volumes of manufacture and installation expected thereafter ( Non-Peak Period ). Manufacture Peak Period Up to 360,000 Device Certificates required per day, via the RA System. The system should be able to cope with delivering up to 500,000 certificates per day. Manufacture Non-Peak Period Up to 4,000,000 Device Certificate Signing Requests required per annum via the RA System. Installation and Commission Peak Period Up to 375,000 Device Certificates required per day, via System to System Interface. The system should be able to cope with delivering up to 500,000 certificates per day. Installation and Commission Non-Peak Period - Up to 4,000,000 Device Certificate Signing Requests per annum via the System to System Interface V

127 B. Online RA System Peak Period The Online RA System shall support during Peak Period: Batch Requests: Up to 375,000 Device Certificate Requests (this shall be the Peak Maximum Daily Volume) in any 24 hour period (07:00 to 06:59 UTC the following day). Processed Device Certificate Documents submitted between and 07:00 and 18:00 shall be available to the requesting RA by 06:59 the following day. Single Certificate Device Certificate Requests up to 1,500 per working day: processed and available for collection within: 95% of signing requests within 10 seconds 99% of signing requests within 20 seconds 100% of signing requests within 30 seconds Non-Peak Period The Online RA System shall support during Non-Peak Period: Batch Requests: Up to 100,000 Device Certificate Requests (this shall be the Peak Maximum Daily Volume) in any 24 hour period (07:00 to 06:59 UTC the following day). Processed Device Certificate Documents submitted between and 07:00 and 18:00 shall be available to the requesting RA by 06:59 the following day. Single Certificate Device Certificate Requests up to 1,000 per working day: processed and available for collection within: 95% of signing requests within 10 seconds 99% of signing requests within 20 seconds 100% of signing requests within 30 seconds Where an RA Request will exceed the Daily Maximum Volume for the applicable Period (Peak or Non-Peak), the requestor shall be informed of this ahead of submission, and informed that the request may not be processed until the following 24 hour period. The RA System must inform requesters of the number of batch requests waiting in the queue for that 24 hour period prior to the RA submitting the request. C. Service Availability RA System The RA System shall be available for requests to be made and results to be retrieved between 00:00 and 23:59 every day. These shall be the Core Service Hours. V

128 The On-line RA System shall be capable of supporting batch requests (of up to 50,000 per single Device Certificate Requests per batch) and single ad-hoc Device Certificate Requests. A maximum of 3 hours per calendar month down time will be permitted. This shall be the Device Service Permitted Down Time. Periods of downtime shall be agreed with Smart DCC. D. Authorised Systems (trusted system to system Device Certificate requests) Interface Peak Period The System to System Interface shall support up to 375,000 Device Certificate Requests (this shall be the Maximum Daily Volume) in any 24 hour period (07:00 to 06:59 UTC the following day). Device Certificate Requests submitted via the System to System Interface shall be processed: 95% of signing requests within 10 seconds 99% of signing requests within 20 seconds 100% of signing requests within 30 seconds Non-Peak Period The System to System Interface shall support up to 375,000 Device Certificate Requests (this shall be the Maximum Daily Volume) in any 24 hour period (07:00 to 06:59 UTC the following day). Device Certificate Requests submitted via the System to System Interface shall be processed: 95% of signing requests within 10 seconds 99% of signing requests within 20 seconds 100% of signing requests within 30 seconds E. Service Availability Authorised Systems (trusted system to system Device Certificate requests) Interface The System to System Interface shall be available for requests to be made between 07:00 and 20:00 each day. These shall be the Core Service Hours. A maximum of 3 hours per calendar month down time will be permitted. This shall be the device service permitted down time. Periods of downtime shall be agreed with Smart DCC. V

129 Organisation It is expected that a volume of Organisation Certificates will be no more than 1,000. Certificates are expected to be renewed. The renewal period is expected to be agreed between the SMKI PMA and the Certification Authority, post the SMKI contract award. Certificate Signing Requests shall be supported by the Online RA System either in batch or in single Requests. F. Service Performance The service shall be available for Certification Request Submission and signed Certificate collection between 00:00 and 23:59 Monday to Friday, and 06:00 and 20:00 Saturday, Sunday and on Public and Bank Holidays. G. Service Availability The service shall be available for Certification Request Submission and signed Certificate collection between 00:00 and 23:59 Monday to Friday, and 06:00 and 20:00 Saturday, Sunday and on Public and Bank Holidays. Additionally, the service shall be capable of extending support to 00:00 Saturday to 23:59 Sunday if required for example, during roll-out periods. This will be managed at Design Phase and will be subject to Change Control Process in accordance with the SEC Change Control process. A maximum of 3 hours per calendar month down time will be permitted. This shall be the Organisation Service Permitted Down Time. Such Periods of downtime shall be agreed with Smart DCC. V

130 APPENDIX D SMKI RECOVERY REQUIREMENTS The following sections lay out the background and scenarios for recovery situations: 1. Recovery Requirements and Scenarios a) It is possible that one or more participating organisations or the SMKI Contractor will suffer a compromise of cryptographic keys at some point, namely: A failure in a certain make / model of meters (either as a result of design failures or attack) results in corruption of security credentials used for cryptographic operations; A party has lost use of one or more of their private keys or shared secrets; A party believes or knows that one or more of their private keys is no longer private; and A party believes or knows that one or more of their shared secrets are no longer secret. b) This introduces a need to have a mechanism to allow for the replacement of key pairs. c) A smart metering device applies strict RBAC procedures regarding replacement of certificates. In general only the certificate owner can replace their existing credentials. d) To provide a mechanism to allow for the recovery from a situation whereby a set of public credentials on a meter need replacing due to a compromise of the device or one of more of the associated owner s private key material (or loss thereof), an additional role and associated public key certificate are installed on every device this is the Recovery public key certificate. e) The Recovery role associated with the Recovery public key certificate has significantly greater privileges than any of the other roles that the meter is aware of. As a result there is a need to maintain strict controls over the use of its associated private keys, i.e. it is restricted to situations requiring a recovery process to be enacted due to a significant compromise of one or more of the role types known to devices, or to the devices themselves. f) Any point of trust in the SMIP Architecture requires a Trust Anchor (ref. RFC 6024). A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor s public key, and by enforcing the constraints expressed in the associated data for the trust anchor. There will be multiple trust anchors on each device, since multiple organisations can interacts with each device. However, one trust anchor is superior to all others. This trust anchor is referred to as the apex trust anchor. This trust anchor represents the ultimate authority over the trust anchor store. Much of this authority can be delegated to other trust anchors (ref. RFC 5934). For the SMKI this apex trust anchor is known as the Root, there is a need to ensure that there is a capability to replace the Root in an assured fashion for one or more of the following reasons: DCC Public V

131 The crypto period for the apex trust anchor public/private key pair has come to an end; The apex trust anchor private key is no longer available; The apex trust anchor public/private key pair needs to be revoked; The authority has decided to use a different digital signature algorithm or the same digital signature algorithm with different parameters, such as a different elliptic curve; The authority has decided to use a different key size; and The authority has decided to transfer control to another authority. g) Normally, Root can be replaced by sending certificates relating to a new root that was authorised by the old root. Only in extreme circumstances will this not be possible (e.g. old root being corrupted on devices by an attacker or design error; old root private key being unusable). h) The Root Key will contain a second public key (known as a wrapped apex contingency key), that will be encrypted with a symmetric key. i) This wrapped apex contingency key will be used specifically in the case of a disaster recovery scenario. j) The capability to replace the Root is then provided by whoever has control of the private key associated with the public contingency key and the associated encryption key. Without this capability to replace Root (the Apex Trust Anchor) then there is no mechanism to deal with either the loss or compromise of Root or indeed any compromise affecting multiple supplier credentials across a large estate of meters? k) This nuclear Root Recovery mechanism is required to provide a capability to recover from any disaster recovery scenario relating to an unexpected, unplanned and unidentified cryptographic compromise. As such the nuclear Recovery mechanism represents a God like key due to the extent of privileges associated with it i.e. the potential to affect the cryptographic protections of the whole of the GB SMIP. As a result any access to and use of the nuclear Root Recovery keys must be tightly controlled and its exposure limited to as shorter period as possible. Therefore, the service needs to provide a robust, secure mechanism for the operation of recovery from the following scenarios: Replacement of any known remote party credential on the meter (other than Root) 5 ; and 5 There is a scenario whereby if the Recovery party is compromised, then the only alternative is to replace Root and as a result, replace all other public credentials on the meters as they will now need to be re-issued under the new Root. DCC Public V

132 Replacement of Root (and as a consequence, all other credentials as well). Recovery Mechanism Scenarios The following list of scenarios defines the scope of the Recovery credentials, i.e. the Recovery mechanism usage procedures will need to be utilised when: Compromise of Root private key material requiring generation of new keys and replacement of public certificate on end devices, where attempts to install the new Root certificate by other means have failed; Compromise of Supplier private key material requiring generation of new keys and replacement of public certificate on end devices, where attempts to install the new Supplier certificate by other means have failed; Compromise of the DSP Broker or Transitional CoS private key material requiring generation of new keys and replacement of public certificate on end devices, where attempts to install the new certificates by other means have failed; Compromise of Network Operator private key material requiring generation of new keys and replacement of public certificate on end devices, where attempts to install the new certificate by other means have failed; Loss of use of private keys relating to one or more of these roles, where no alternatives recovery routes are available. Note: The only unrecoverable situations are: Loss by all parties for a specific device category, e.g. for a Gas meter this would be loss of both the DSP and its Supplier private key material. At a large scale an adversary succeeding in replacing Recovery and Root public credentials on a device; Loss of use of Root and Contingency Recovery private keys; Loss of use of Recovery and Contingency Recovery private keys. a) Compromise (but not loss of use) of any set of private key material will lead to a race condition that can be counteracted by using the compromised credentials within a timeframe which limits the number of devices impacted, thus avoiding utilisation of the Key Recovery Procedure (KRP). Determination of when the recovery process must be enacted will be determined by the DCC in alignment with the KRP, which will be defined by the PMA. In a case where there is a large scale compromise of devices due to loss of the race, i.e. another entity has taken effective control of the device with their own credentials before the compromised party could, or due to loss of private key material, then Key Recovery Procedure (or Contingency Recovery) will need to be invoked. Due to the risks associated with misuse of the Recovery key there is a need to ensure that there is multi-party collusion at key points within the process: DCC Public V

133 Creation and distribution of the key parts; Re-composition and use of the recovery credentials (or Contingency Public Recovery Key Encryption Key); and Multi-party cryptographic protections of any certificate replacement commands b) Note: that there are many compromise scenarios which may well be recoverable without use of the Recovery mechanisms. The Recovery mechanisms would only be used where such alternatives have failed or are not available due to the nature of the compromise. DCC Public V

134 APPENDIX E SMKI STANDARDS The table below lists the standards which the SMKI Services shall adhere to. Description RFC PKCS #10: Certification Request Syntax Specification Version 1.7 Importance RFC Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework RFC Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) RFC Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile RFC Specifies the syntax and semantics for the Subject Public Key field in Certificates that support Elliptic Curve Cryptography. RFC Suite B Certificate and Certificate Revocation List (CRL) Profile RFC Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) ISO/IEC 27001: technology Security techniques security management systems Requirements ISO/IEC22301: Societal security Business continuity management systems Requirements ISO/IEC27013: technology Security techniques Guidelines for information and communication technology readiness for business continuity DCC Public V

135 APPENDIX F SMKI DEVICE CERTIFCATE ROLLOUT The information below is a representation of the estimated Device Certificate requirements. Please note that, it is based on high level planning data. AVERAGE VOLUME SPREAD MIN MAX Daily Average 50, ,859 Weekly Average 251,268 1,814,294 Monthly Average 1,088,829 7,861,940 DCC Public V

136 Assumptions i. GSMEs, ESMEs, PPMIDs and Communications Hubs all require Device Signing under SMKI. ii. iii. There are currently no PPMID profiles available. Devices in the three CSPs regions have the same SMKI requirements. DCC Public V