Version 1: Release Note 28 November 2014


Certification Path Validation



Download 4.8 Mb.
Page26/258
Date03.04.2021
Size4.8 Mb.
1   ...   22   23   24   25   26   27   28   29   ...   258

Certification Path Validation

  1. Access Control Broker requirements

Before it calculates the Access Control Broker to Device MAC (ACB-SMD MAC) in line with Section 6.2.3, the Access Control Broker shall undertake Certification Revocation List (CRL) Validation for any Organisation Certificate in a Command:

  • either by using the algorithm specified in IETF RFC 52809 Section 6.3; or

  • by using functionality equivalent to the external behaviour resulting from that algorithm.

Only if the CRL Validation is successful shall the Access Control Broker calculate the ACB-SMD MAC. For clarity, the Access Control Broker shall never send a Message to a Device which contains any Certificate that has failed CRL Validation.
          1. Device requirements

The requirements in this Section 4.3.2.8.2 shall apply only to Use Case CS02b (Update Security Credentials).

Where a Device has successfully completed all required Command Authenticity and Integrity checks on a Command of type covered by Use Case CS02b it has received, the Device shall undertake either:



If the Device does not have Reliable Time (as defined in Use Cases GCS28 and ECS70 Set Clock) it shall always undertake Certification Path Validation, excluding time checks. Otherwise the validation to be undertaken shall be determined by the contents of the Remote Party Command instance. For clarity, Device types which are not required to have a clock, shall always undertake Certification Path Validation, excluding time checks.

The Device shall undertake Certification Path Validation, including time checks:



  • either by using the algorithm specified in IETF RFC 5280 Section 6.1; or

  • by using functionality equivalent to the external behaviour resulting from that algorithm.

The Device shall undertake Certification Path Validation, excluding time checks:

  • either by using the algorithm specified in IETF RFC 5280 Section 6.1 but not applying the check at 6.1.3 (a) (2) (‘the certificate validity period includes the current time’); or

  • by using functionality equivalent to the external behaviour resulting from that algorithm where not applying the check that ‘the certificate validity period includes the current time’.

The ‘trust anchor’ information (with the meaning in IETF RFC 5280) shall be in the root Security Credentials held on the Device.

If the Device’s Certificate Path Validation does not confirm the required certification path validity, then the Device shall undertake no further processing of the Command, except for the issuance of a Response notifying that the Command was unsuccessful.



        1. 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:
1   ...   22   23   24   25   26   27   28   29   ...   258




The database is protected by copyright ©essaydocs.org 2020
send message

    Main page