Constructing the @ProvideDeviceCertificateFromDevice.CommandPayload and @ProvideDeviceCertificateFromDevice.ResponsePayload

Constructing the @ProvideDeviceCertificateFromDevice.CommandPayload and @ProvideDeviceCertificateFromDevice.ResponsePayload

322. 
     @ProvideDeviceCertificateFromDevice.CommandPayload shall have the structure defined in Section 13.6.6 and the Remote Party constructing the Command shall populate with values according to Table 13.6.7a.
     

     Attribute name	Data Type	Value (blank cells mean the command specific value is derived by the encoding process)	Mandatory, OPTIONAL or DEFAULT value	Notes
     @ProvideDeviceCertificateFromDevice.CommandPayload	SEQUENCE
     keyUsage	BIT STRING	Either digitalSignature (0) only, Or keyAgreement (4) only	Mandatory	Only one or the other is valid

323. 
     Table 13.6.7a: @ProvideDeviceCertificateFromDevice.CommandPayload population
     
324. 
     @ProvideDeviceCertificateFromDevice.ResponsePayload shall have the structure defined in Section 13.6.6, and the Device constructing the Response shall populate with values according to Table 13.6.7b.
     

     Attribute name	Data Type	Value (blank cells mean the command specific value is derived by the encoding process)	Mandatory, OPTIONAL or DEFAULT value	Notes
     @ProvideDeviceCertificateFromDevice.ResponsePayload	CHOICE
     Certificate	See IETF RFC 5912	The Device Certificate provided pursuant to Section 13.6.4	Mandatory	Mandatory if certificate successfully produced
     provideDeviceCertResponseCode	INTEGER	Shall be populated according to the processing defined in Section 13.5.4	Mandatory	Mandatory if certificate is not successfully produced

325. 
     Table 13.6.7b: @ProvideDeviceCertificateFromDevice.ResponsePayload population
     

7. Pair-wise Authorisation of Devices

   1. Introduction to pair-wise Authorisation of Devices - informative

      1. The role of pair-wise Authorisation - informative

The process of authorising two Devices to communicate is referred to as ‘Joining’³². Removal of such authorisation is referred to as ‘Un-joining’. Correspondingly, Remote Party Commands are specified in this Section 13.7 for instructing Devices that they are to ‘Join’ or ‘Unjoin’.

In line with the SMETS and CHTS Device Log requirements, two Devices on a HAN must only be capable of interacting at the application layer if they are currently Joined. They must not be capable of interacting if (1) they have never been Joined or (2) they have been Unjoined.

The application layer interactions between Devices on the same SMHAN must conform to the Device Based Access Controls (DBAC) as defined in Section 13.7.3. For example, an ESME must not be capable of processing an ‘Enable Supply’ Command from an IHD or an HCALCS.

It is a precondition of Joining that both Devices have been ‘White-listed’ on to the HAN (as per Use Case ‘CCS01 Add Device to CHF Device log’) so that they are able to communicate over the HAN at the network layer (and so have network access). The GPF may be configured to be in the CHF’s Device Log at manufacture. A Device on a white-list can be removed from the white-list. It must then be unable to communicate over the HAN, and so unable to interact at the application layer with any Devices to which it was ‘Joined’.

In SMETS terminology:

• 
  the CHF’s Device Log holds the list of currently white-listed Devices on the SMHAN; and
  
• 
  the Device Log on an ESME, GSME, GPF or Type 1 Device holds the Entity Identifiers, Device Types and related Security Credentials of other Devices on the HAN to which the Device is currently Joined (and so Authorised to interact with at an application layer).
  

IHDs and other Type 2 Devices are not required to have a Device Log (as defined in SMETS). They are required to store security and related details of the Devices to which they are Joined as required by ZSE however (otherwise they would be cryptographically unable to understand the information being sent to them by the Joined Devices).

IHDs and other Type 2 Devices can only read application layer information from Devices to which they are Joined (either by requesting the information from the Device or by receiving information published by the Device). When a PPMID is joined to a GPF the PPMID can only read information from the GPF to which it is Joined.

When other types of Device are Joined (e.g. HCALCS, PPMID), they can also exchange Commands and Responses at the application layer. For example, an ESME that is Joined to an HCALCS can send a Command to the HCALCS to turn its switch on and the HCALCS can send a Response saying whether it has done that. A PPMID can send an ‘enable supply’ Command to an ESME etc.

2. 
   
   Directory: government -> uploads -> system -> uploads -> attachment data -> file
   file -> Remove this if sending to pagerunnerr Page Title Light Rail Security Recommended Best Practice
   file -> 8 Section 1 : Sport
   file -> Notice of exercise of additional powers of seizure under Sections 50 or 51 of the Criminal Justice and Police Act 2001
   file -> Home office circular 004/2014 Powers to search for and seize invalid travel documents in Schedule 8 to the Anti-social Behaviour, Crime and Policing Act 2014
   file -> Consultation on the Royal Parks and Other Open Spaces (Amendment) (No. 2) Regulations 2012
   file -> Crown copyright 2012
   file -> This is the Report to Government by the Film Policy Review Panel The brief
   file -> Impact Assessment (IA)
   file -> Dcms/Wolfson Museums and Galleries Improvement Fund a public-Private Partnership (2002-2010)
   
   
   
   Share with your friends: