Version 1: Release Note 28 November 2014


Requirements for Certificates



Download 4.8 Mb.
Page141/258
Date03.04.2021
Size4.8 Mb.
1   ...   137   138   139   140   141   142   143   144   ...   258

Requirements for Certificates


This Section 12 lays out requirements as to structure and content to which all valid authorised Certificates shall comply, in so far as those requirements affect the processing carried out by Devices. All terms in this section shall, where not defined in the GBCS, have the meanings in IETF RFC 575923 and IETF RFC 5280.
    1. Requirements applicable to all Certificates


All Security Credential Documents that are successfully authorised within the APKI for use by Devices within the scope of this GBCS shall:

  • be compliant with IETF RFC 5759 and so with IETF RFC 5280. In adherence with the requirements of IETF RFC5759, all Security Credential Documents shall:

        • contain the authorityKeyIdentifier extension, except where the Security Credential Document is self-signed;

        • 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. This means all public keys shall be elliptic curve public keys on the NIST P-256 curve;

  • only contain public keys in uncompressed form which shall be elliptic curve points in uncompressed form as detailed in Section 2.2 of IETF RFC 548024;

  • only provide for signature methods that are explicitly allowed within the GBCS. This means using P-256 Private Keys with SHA 256 and ECDSA;

  • contain a serialNumber of no more than 8 octets in length;

  • contain a subjectKeyIdentifier which shall be marked as non-critical;

  • 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 Devices shall interpret this extension;

  • contain an 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 4.2.1.2 of IETF RFC 5280. Thus KeyIdentifiers shall always be 8 octets in length;

  • contain an IssuerName which is identical to the Security Credential Document’s signer's SubjectName; and

  • have a valid notBefore field consisting of the time of issue encoded and a valid notAfter as per IETF RFC 5280 Section 4.1.2.5.

    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   ...   137   138   139   140   141   142   143   144   ...   258




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

    Main page