CRYPTO STANDARDS
ISO
ISO blockchain standards
ISO TC307
- TR22739 Vocabulary
- TR 23244:2020 Privacy and personally identifiable information protection considerations (published)
- FDIS 23257 Reference architecture (published)
- TR 23576 Security management of digital asset custodians (published)
- TS 23258 Taxonomy/Ontology (published)
Soon to be published:
- TR23249 Overview of existing DLT systems for identity management
- DTS 23635 Guidelines for governance
- DTR 3242 Use cases – collaboration with JTC19 [New Use-cases welcome, there will be one more iteration of TR]
- TR 23644 Overview of trust anchors for DLT-based identity management (TADIM) – links with JTC19
ISO crypto standards
Hashing and MAC
- IS 10118 Hashing
- IS 9797 MAC
Encryption
- IS 18033 Encryption
- IS 10116 Modes of operation
- IS 15946 ECC
Authentication
- IS 9798 Entity authentication
- ISO/IEC 20089: Direct Anonymous Attestation
- ISO/IEC 20009: Anonymous Entity Authentication
- IS 13888 Non-repudiation
- IS 18014 Time-stamping
Signing
The CEF DSS documentation is practical.
Basics
- IS 9796 Signatures with message recovery
- IS 14888 Signatures with appendix
- ISO/IEC 20248:2018 is an ISO/IEC 9594-8 application specification for automated identification services.
It specifies a method whereby data stored within a barcode and/or RFID tag are structured, encoded and digitally signed.
- ISO/IEC 9594-8 Public Key Infrastructure: digital signatures and certificates
Long term signature
- ISO 14533-1:2012, Processes, data elements and documents in commerce, industry and administration Long term signature profiles Part 1: Long term signature profiles for CMS Advanced Electronic Signatures (CAdES)
- ISO 14533-2:2012, Processes, data elements and documents in commerce, industry and administration Long term signature profiles Part 2: Long term signature profiles for XML Advanced Electronic Signatures (XAdES)
Blind signature
- ISO/IEC 18370 Blind Signature
Anonymity
- ISO/IEC 29191: Requirements on relative anonymity with identity escrow model for authentication and authorization using group signatures
Anonymous signatures
- ISO/IEC 20008: Anonymous digital signatures
Management
- ISO/IEC 11770-1:2010 Key management Part 1: Framework
- Defines a model of key management independent of the use of any particular cryptographic algorithm. However, certain key distribution mechanisms can depend on particular algorithm properties, for example, properties of asymmetric algorithms.
- Examples of the use of key management mechanisms are included in ISO 11568. If non-repudiation is required for key management, ISO/IEC 13888 is applicable.
- ISO/IEC 11770-2:2018 Key management Part 2: Mechanisms using symmetric techniques
- ISO/IEC 11770-3:2015 Key management Part 3: Mechanisms using asymmetric techniques
Assurance and testing
- ISO 29128 crypto protocols assurance levels
- ISO/IEC 24759:2008 Methods to test whether a cryptographic module conforms to the requirements specified in ISO/IEC 19790:2006.
Biometric protection
- NP 24745 Biometric template protection
Authenticated encryption
- IS 19772 Authenticated encryption
Generation
- IS 18031 Random bit generation
- IS 18032 Prime number generation
ISO other standards - TTP and related
- ISO 14516 Guidelines for TTP services
- ISO 19626 Trusted communication platform for electronic documents - legally provable way of dematerialisation, Jasmine Jaegyong Chang, 2017
- ISO 21188:2018 Public key infrastructure for financial services Practices and policy framework
EU standards and related matters
Europe's Standard Development Organisations are ETSI, CEN and CENELEC.
Regarding security standards, there is also the SOG-IS group, ref below.
ETSI local files
ETSI
EU standards were particularly successful in mobile communication such as GSM. These standards were originally driven through CEPT (European Conference on Post and Telecommunications Administrations).
In 1988, ETSI took over, and in 2001 GSM standardisation was transferred to the global 3GPP.
For ETSI basics refer to ETSI standards.
ETSI security workshops
For a starting point refer to ETSI security workshop and the whitepapers such as "ETSI White Paper No. 1 Security for ICT - the Work of ETSI" by Charles Brookson and Dionisio Zumerle (January 2006).
ETSI security workshop videos and related
ETSI publications
For the different types of ETSI standards refer to the ETSI standards information page. The main types are:
- European Standard (EN)
- ETSI Standard (ES)
- ETSI Guide (EG)
- ETSI Technical Specification (TS)
- ETSI Technical Report (TR)
- ETSI Special Report (SR)
- ETSI Group Specification (GS)
- ETSI Group Report (GR)
ETSI TC ESI
ETSI TC ESI basics
TC and documents
ETSI activities on electronic signatures are coordinated by Technical Committee (TC)
Electronic Signatures and Infrastructures (ESI), chaired by Ricardo Genghini.
The ESI TC ongoing and
past activities are available, together with the drafts.
The naming of ETSI documents is mainly based on the six areas described below.
However, there are particular ways in naming documents. The EN and TS names of the same standard are completely unrelated, as in PAdES, ETSI TS 102 778 (parts 1 to 5), also published as EN 19 142.
Standard names are generally structured as DD L19 xxx-z.
- DD indicates the deliverable type in the standardisation process (SR, TS, TR and EN)
- L
- set to 0, 1, 2, or 3: identifies an ETSI deliverable and the type of deliverable in the standardisation process
- set to 4: identifies a CEN deliverable
- hence:
- 019 xxx for ETSI published Special Reports (SR)
- 119 xxx for ETSI published Technical Specification (TS) and Technical Report (TR)
- 219 xxx for ETSI published Standard (ES) and ETSI Guide (EG)
- 319 xxx for ETSI published European Norm (EN)
- 419 xxx for CEN published Technical Specification (TS) or European Norm (EN)
- 19 indicates the series of standardisation documents related to eSignatures
Emerging work
- DTS/ESI‐0019462 (TS) Wallet interfaces for trust services and signing - Early draft (2022‐09‐12) - Michal Tabor
- DTS/ESI‐0019471 (TS) Policy and Security requirements for Attribute Attestation Services - Early draft (2022‐10‐03) - Paloma LLaneza González
- DTS/ESI‐0019472 (TS) Profiles for Attribute Attestations - Early draft (2022‐09‐13) - Juan Carlos Cruellas
Mandates and Special Task Forces
In 2013, EU e-signature standardisation mandate m460 was given from the EC to CEN and ETSI to establish a rationalised framework for electronic signature standardisation.
ETSI M460 STFs
- ETSI STF 457 Rationalised Framework for electronic signatures standards; Framework and Coordination Activities
- ETSI STF 458 Signature Creation and Validation and Trusted Service Providers (TSP) supporting eSignatures
- ETSI STF 459 Priority Activities relating to Testing Compliance & Interoperability and Trust Applications Service Providers
ETSI other STFs
- ETSI STF 560 Standards for machine-processable signature policy formats and the global acceptance of European Trust Services
- ETSI STF 588 Identity Proofing for Trust Service Subjects
- ETSI TR 119 460 Electronic Signature and Infrastructures (ESI); Survey of technologies and regulatory requirements for identity proofing for trust service subjects.
- ETSI TS 119 461 Electronic Signatures and Infrastructures (ESI); Policy and security requirements for trust service components providing identity proofing of trust service subjects.
- Scope: identity proofing of applicants to be enrolled as subjects or subscribers of a Trust Service Provider (TSP)
- Aims at a.o. eIDAS. As identity is not a trust service, identity proofing is defined as a 'trust service component'
- Can be done by TSP or by Identity Proofing Service Provider (IPSP) acting as a subcontractor to the TSP
- Results in identity proofing to a Baseline Level of Identity Proofing (LoIP) that is considered applicable to all relevant ETSI trust services standards
- Defines process, requirements, threat scenarios
Trust models
- ETSI TR 103 684 analysis of the global acceptance of European Trust Services, 37 global, sector and national public key infrastructure schemes
ETSI TC ESI framework and areas
Signature - read on for identity
Always check the ESI portal.
- ETSI TR 119 000 The framework for standardization of signatures: overview. It states the following six areas are addressed regarding trust services.
- Signature creation and validation - starting point: ETSI TR 119 100 on "Guidance on the use of standards for signature creation and validation"
- Signature creation and other related devices - starting point: ETSI TR 119 200 on "Guidance on the use of standards for signature creation and other related devices"
- Cryptographic suites - starting point: ETSI TR 119 300 on "Guidance on the use of standards for cryptographic suites"
- TSPs supporting digital signatures - starting point ETSI TR 119 400 on "Guidance on the use of standards for TSPs supporting digital signatures and related services" - covers time-stamping
- Trust application service providers - starting point: ETSI TR 119 500 on "Guidance on the use of standards for trust application service providers"
- Trust service status list providers - starting point: ETSI TR 119 600 on "Guidance on the use of standards for trust service status lists providers"
- ETSI TR 119 001 The framework for standardization of signatures: Definitions and abbreviations
- ETSI TS standards directory
ETSI ESI 119 area 1 signature creation and validation
- EN 319 102-1 ESI - Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation (see TS 119 102-1) - a core standard
- Signature class 1: basic signature (signer's document/signed attributes/signature value/unsigned attributes
- Signature class 2: signature with time (signer's document/signed attributes/signature value/unsigned attributes that contain a time assertion
- Signature class 3: signature with long term validation material (signer's document/signed attributes/signature value/unsigned attributes that contain a time assertion+complete certificate and revocation data
- Signature class 4: signature proving long term availability and integrity of validation material (signer's document/signed attributes/signature value/unsigned attributes that contain a time assertion+complete certificate and revocation data+additional material and time assertion
Furthermore:
- ETSI TS 119 101 Policy and security requirements
for applications for signature creation and signature validation
- ETSI TS 119 102 Signature validation
- ETSI TS 119 102-1 Procedures for Creation and Validation of AdES Digital Signatures; Part 1: Creation and Validation
- ETSI TS 119 102-2 Procedures for Creation and Validation of AdES Digital Signatures; Part 2: Signature Validation Report
ETSI ESI 119 area 2 signature creation and other related devices
- ETSI TR 119 200 on "Guidance on the use of standards for signature creation and other related devices"
ETSI standards related to remote signature:
- EN 419 241-1 General System requirements for remote signing - with two levels of Sole Control Assurance (SCAL)
- SCAL1: low confidence in sole control of the signer, the signing application authenticates the signatory
- SCAL2: high confidence in sole control of the signer, the signature activation module (SAM) uses signature activation data (SAD) provided through the signature activation protocol (SAP)
- ETSI TS 419 241 - local copy
- EN 419 241-2 PP for QTSP
- TS 119 431-1 Policy and security requirements for TSP service components operating a remote QSCD/SCD
- TS 119 431-2 Policy and security requirements for TSP service components supporting AdES digital signature creation
- TS 119 432 Protocols for remote digital signature creation
- TS 119 442 Protocol profiles for TSPs providing AdES digital signature validation services (XML and JSON)
ETSI ESI 119 area 3 cryptographic suites
- ETSI TS 119 312 Cryptographic suites - list of recommended algorithms, updated every two year
ETSI ESI 119 area 4 TSPs supporting digital signatures
TS 119 4nn becomes EN 319 4nn.
ETSI ENs regarding TSPs
- ETSI EN 319 401 General policy requirements for TSPs
- Intro/scope/references/terms
- Overview
- Risk Assessment
- Policies and practices
- Trust Service Practice Statement
- Terms and Conditions
- Information Security Policy
- TSP management and operation
- Internal organisation, segregation of duty, ...
- HR
- Asset management
- Access control
- Cryptographic controls
- ...
- Compliance
- ETSI EN 319 403 Requirements for CABs assessing TSPs - migrated into multipart standard
- ETSI EN 319 403-1 Requirements for CABs assessing TSPs
- ETSI TS 119 403-2 (future EN 319 403-2) Additional Requirements for CABs assessing TSPs issuing public certificates
- ETSI TS 119 403-3 (future EN 319 403-3) Additional Requirements for CABs assessing EU QTSPs
- ETSI EN 319 411-1 Policy and security requirements for TSPs part 1 General requirements
- LCP (lightweight certificate policy - good practices), NCP (normalised certificate policy - best practices)
- Structure:
- 1 Scope
- 2 References
- 3 Definitions
- 4 General concepts - applicable documentation - certification services
- 5 General provisions on CPS and CP
- 6 TSP practice
- 7 Framework for definition of other certificate policies
- Annex A Model PKI disclosure statement
- Annex B Conformity assessment checklist
- Annex C Bibliography
- Annex D Change history
- ETSI EN 319 411-2 Policy and security requirements for TSPs part 2 For issuing qualified certificates
- Includes reference CPs: QCP-l, QCP-n, QCP-l-qscd, QCP-n-qscd, QCP-w (legal person, natural person, web)
- Other countries may build their own ETSI EN 319 411-2 (i.e. a specific CP) see clause 7.
- Structure:
- 1 Scope
- 2 References
- 3 Definitions
- 4 General concepts
- 5 General provisions on CPS and CP
- 6 TSP practice
- 7 Framework for definition of other certificate policies
- Annex A Regulation and EU QC policy mapping
- Annex B Conformity assessment checklist ---> this is a pointer to ETSI TR 119 411-4
- Annex C Change history
- ETSI EN 319 412
ETSI TSs regarding TSPs
- TS 119 400
- TS 119 411-4 Checklist for TSP (referred to in EN 319 411-2)
- TS 119 431-1 Policy and security requirements for TSP service components operating a remote QSCD/SCD (to be seen in the context of CEN SCAL1 and SCAL2)
- TS 119 431-2 Policy and security requirements for TSP service components supporting AdES digital signature creation
- TS 119 432 Protocols for remote digital signature creation (supports both signature creation by application and by signature activation module - SCAL1 and SCAL2)
- JSON implementation (based on Cloud Signature Consortium)
- XML (based on OASIS DSS-X)
- TS 119 442 Protocols for remote digital signature validation
- ETSI TR 119 460 Survey of technologies and regulatory requirements for identity proofing for trust service subjects
- ETSI TS 119 461 Policy and security requirements for trust service components providing identity proofing of trust service subjects
- TS 119 495 PSD2 Qualified Certificate standard
- combines ETSI EN 319 411-1 or -2; or 412-4 (websites) and/or 412-3 (legal persons)
- plus authorisation number PSD
Also: CEN Standards for remote signing systems (e.g. cloud):
- EN 419 221-5: eIDAS Cryptographic module / HSM - i.e. the basics
- EN 419 241-1: General System requirements (cloud/remote signing)
- EN 419 241-2: Protection Profile for QSCD for Server Signing
ETSI ESI 119 area 5 Trust application service providers (TASPs)
- ETSI TS 119 511 Policy and security requirements for TSP using long-term preservation of digital signatures or general data using digital signature techniques
- ETSI TS 119 512 Preservation service/protocol
ETSI ESI 119 area 6 Trust service status list providers
- ETSI TS 119 612 Trust service status lists (TL - Trusted List - LOTL)
Identity
- ETSI TR 119 460 Overview of technology
- ETSI TS 119 461 V1.1.1 (2021-07)
ETSI CAdES, XAdES, PAdES, AsIC, JAdES
ETSI refers to electronic signatures as AdES, of which CAdES, XAdES, PAdES, AsIC, JAdES are instantiations.
CAdES
While CMS is a general framework for electronic signatures, CAdES specifies profiles of CMS signed data making it compliant with eIDAS.
The main document describing the format is ETSI TS 101 733.
- CAdES - Wikipedia
- ETSI TS 101 733 CMS Advanced Electronic Signature (CAdES)
specifies formats for Advanced Electronic Signatures built on CMS (CAdES)
- defines a number of signed and unsigned optional signature properties, resulting in support for a number of variations
in the signature contents and processing requirements
- common options are jointly specified as profiles:
- CAdES-B: Basic Electronic Signature, the simplest version, containing the SignedInfo, SignatureValue, KeyInfo and SignedProperties. This level combines the old -BES and -EPES levels. This form extends the definition of an electronic signature to conform to the identified signature policy
- CAdES-T: B-Level for which a Trust Service Provider has generated a trusted token (time-mark or time-stamp token) proving that the signature itself actually existed at a certain date and time.
- CAdES-LT: are built by direct incorporation to CAdES-T signatures conformant to the T-Level, a long-term-validation attribute containing values of certificates and values of certificate revocation status used to validate the signature.
- CAdES-LTA: a signature conformant to LT-Level to which one or more long-term-validation attribute with a poeValue has been incorporated. By using periodical timestamping (e.g. each year) it is prevented the compromising of the signature due to weakening algorithms during long time storage periods. This level is equivalent to the old -A level
- ETSI TS 119 102 Signature validation
XAdES
XAdES (XML Advanced Electronic Signatures) is a set of extensions to the W3C XML-DSig recommendation making it suitable for advanced electronic signatures. W3C and ETSI maintain and update XAdES together.
- XAdES - Wikipedia
- OpenXADES.org - Digidoc - Estonia
- ETSI TS 101 903 XaDES
- XaDES profiles:
- XAdES (also named XAdES-BES for "Basic Electronic Signature"), basic form just satisfying Directive legal requirements for advanced signature
- XAdES-T (timestamp), adding timestamp field to protect against repudiation
- XAdES-C (complete), adding references to verification data (certificates and revocation lists) to the signed documents to allow off-line verification and verification in future (but does not store the actual data)
- XAdES-X (extended), adding timestamps on the references introduced by XAdES-C to protect against possible compromise of certificates in chain in future
- XAdES-X-L (extended long-term), adding actual certificates and revocation lists to the signed document to allow verification in future even if their original source is not available
- XAdES-A (archival), adding the possibility for periodical timestamping (e.g. each year) of the archived document to prevent compromise caused by weakening signature during a long storage period
- In 2016 ETSI publishes EN 319 132-1 V1.1.0 where the profiles have been omitted
PAdES
- ETSI TS 102 778 parts 1 to 5 PDF Advanced Electronic Signature see also PADES FAQ
- PADES FAQ
ASiC
Associated Signature Containers (ASiC) specifies the use of container structures to bind together one or more signed objects with either advanced electronic signatures or timestamp tokens into one single container. The format extends zip, OpenDocument and EPUB. The ASiC standard is used in the Estonian DigiDoc system.
- ASiC - Wikipedia
- ETSI EN 319 162-1 V1.1.1 Associated Signature Containers (ASiC); Part 1: Building blocks and ASiC baseline containers
JAdES
Original JAdES proposal is RFC 7515.
ETSI timestamping
Starting points:
- All ETSI signature standards (such as XAdES et al) include a variant -T, which addresses timestamping within the signature
- ETSI TR 119 400 covers a.o. timestamping
Furthermore
- ETSI TS 101 861 Time stamping profile
- ETSI TS 102 023 Policy requirements for time-stamping authorities
- ETSI EN 319 412 Certificate Profiles
- -1 Overview (based on RFC 5280)
- -2 Natural persons
- -3 Legal persons
- -4 Websites (ref to CABforum)
- -5 QC statements (e.g. use of QSCD)
- ETSI EN 319 421 Policy and Security Requirements for Trust Service Providers issuing Time-Stamps
- ETSI EN 319 422 Time-stamping protocol and time-stamp token profiles
- ETSI TS 102 042 Policy Requirements for CA issuing PKI certificates
Don't forget the influencial IETF RFCs
- RFC 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
- RFC 3628 Policy Requirements for Time-Stamping Authorities (TSAs)
ETSI signing-other
- ETSI TS 101 456 Policy Requirements for CA issuing QC - ref also ETSI EN 319 401 General policy requirements for TSPs
- ETSI TS 101 733 Signature format and syntax
- ETSI TS 102 042 Policy Requirements for CA issuing PKI certificates
- ETSI TS 102 458 Mapping comparison US Federal Bridge CA and ETSI 101 456
- ETSI 419 221-5 PP for QSCD
Refer also to related CEN standards.
ETSI certificates
ETSI standards related to certificates
- ref Nacho
- TS 101 862 QCP Qualified Certificate Profile
- TS 119 495 PSD2 Qualified Certificate standard
ETSI signature validation
- TS 102 853 Signature validation procedures
- Identification of signer's certificate
- Validation context initialisation
- X.509 certificate validation
- Cryptographic verification
- Signature acceptance validation
- Validation processes for basic validation, time stamps, AdES-T, LTV
- TS 119 172-4 Signature validation policy for European qualified electronic signatures/seals using trusted lists
- Validation constraints and procedures
- Requirements on validation and applicability rules checking practices
- Technical applicability rules checking process
- Report
- TS 119 441 Policy requirements for TSP providing signature validation services
- General concepts
- Risk assessment
- Signature Validation Service (SVS) management and operation
- Signature Validation Service technical requirements
- Framework for definition of validation service policies
- Appendices: SVS Practice Statement, QES SVS as per eIDAS Art 33, mapping of requirements onto eIDAS, recommendation on UI, checklist, validation of validation report signature
ETSI Electronic Registered Delivery Services (ERDS)
ETSI standards related to Electronic Registered Delivery Services (ERDS) and AS4, the CEF eDelivery message exchange protocol, based on OASIS ebMS.
- ETSI work was accepted as ISO standard
- ISO 15000 Part 1
- ISO 15000 Part 2
- Binding to eIDAS is through:
- ETSI EN 319 522-1 Electronic Registered Delivery Services; Part 1: Framework and Architecture
- ETSI EN 319 522-2 Electronic Registered Delivery Services; Part 2: Semantic Contents
- ETSI EN 319 522-3 Electronic Registered Delivery Services; Part 3: Formats
- ETSI EN 319 522-4-1 Electronic Registered Delivery Services; Part 4: Bindings; Sub-part 1: Message delivery bindings
- ETSI EN 319 522-4-2 Electronic Registered Delivery Services; Part 4: Bindings; Sub-part 2: Evidence and identification bindings
ETSI mobile and SIM
ETSI standards related to the new USIM - the SSP
- TS 103 465 SSP Requirements and Use Cases
- TS 103 666 Part 1 SSP General characteristics
- TS 103 666 Part 2 iSSP General characteristics
- TS 103 713 SPI interface
ETSI blockchain and DLT
See also CEN/CENELEC.
ETSI blockchain and DLT - ESI for general matters
- Electronic Signatures and trust Infrastructures.
ETSI blockchain and DLT
ETSI blockchain, DLT and Permissioned Distributed Ledger (PDL)
- ETSI PDL technology page
- ETSI GR PDL 001 Permissioned Distributed Ledger; Landscape of Standards and Technologies
- ETSI GR PDL 002 Permissioned Distributed Ledger; Applicability and compliance to data processing requirements
- ETSI GR PDL 003 Permissioned Distributed Ledger; Application Scenarios
- ETSI GR PDL 004 Permissioned Distributed Ledger; Smart Contracts; System Architecture and Functional Specification
- ETSI GS PDL 005 Permissioned Distributed Ledger; Proof of Concepts Framework
ETSI cyber, IOT and related
Trust
- ETSI TS 103 486 - identity-based trust - cyber/IOT
IOT
- ETSI EN 303 645 - identity-based trust - cyber/IOT
Related
- ETSI TS 103 532 Attribute Based Encryption for Attribute Access Control
QUOTE
Trust - as defined in ETSI TS 103 532 is the level of confidence in the reliability and integrity of an entity to fulfil specific responsibilities. If a network cannot fulfil its obligations because it cannot access data in encrypted content, it will become less trusted. The concern in this case is that as trust in the network is lowered more encryption from outside the control of the network is then applied, thus further degrading the trust.
UNQUOTE
- ETSI GR ETI 001 Encrypted Traffic Integration - Problem statement
ETSI post quantum
Quantum safe cryptography
- ETSI PQ - cluster
- ETSI GR QSC001 Analysis of Quantum-Safe Primitives
- ETSI GR QSC003 Quantum-Safe Case Studies & Use Cases
- ETSI GR QSC004 Quantum-Safe Threat Analysis
- ETSI TR 103 570 Quantum-Safe Key Exchanges
- ETSI TR 103 617 Quantum Safe Virtual Private Networks
- ETSI TR 103 618 Quantum-Safe Identity-Based Encryption
- ETSI TR 103 619 Migration strategies and recommendations to Quantum Safe schemes
CEN
- CEN - Comité Européen de Normalisation (+/- EU's counterpart for ISO)
CEN standards relevant for blockchain/DLT
- CEN/TC 224 “Personal identification and related personal devices with secure element, systems, operations and privacy in a multi sectorial environment
- CEN/TC 468 “Management and preservation of digital content” (for the eArchiving trust service)
- CEN/CENELEC/JTC 19 “Blockchain and Distributed Ledger Technologies” (for the Electronic Ledgers trust service)
CEN signing standards
EN 419 261 Security requirements for TWS
- CEN TS 419 261: Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures
EN 419 221 PPs for TSP cryptomodules
- CEN TS 419 221-1: Protection profiles for TSP Cryptographic modules - Part 1: Overview
- CEN TS 419 221-2: Protection profiles for TSP Cryptographic modules - Part 2: Cryptographic module for CSP signing operations with backup
- CEN TS 419 221-3: Protection profiles for TSP Cryptographic modules - Part 3: Cryptographic module for Cryptographic module for CSP key generation services
- CEN TS 419 221-4: Protection profiles for TSP Cryptographic modules - Part 4: Cryptographic module for CSP signing operations without backup
- CEN EN 419 221-5: Protection profiles for TSP Cryptographic modules - Part 5: Cryptographic module for trust services
- The eIDAS Protection Profile EN 419 221-5 “Cryptographic Module for Trust Services” standardises security requirements for cryptographic modules being used as Qualified Signature Creation Device (QSCD) according to the eIDAS regulation
- This PP was certified by an accredited evaluation laboratory in late 2017 and approved by the EU member states in 2018
- The Utimaco CryptoServer CP5 HSM received the Common Criteria (CC) EAL4+ certification based on this PP
EN 419 241 server signing/remote signature
- EN 419 241-1 General System requirements for remote signing - with two levels of Sole Control Assurance (SCAL1/2)
- EN 419 241-2 PP for QTSP
EN 419 231 time stamping
- CEN EN 419 231 - Security requirements for trustworthy systems supporting time-stamping
CEN other standards
Working groups
- WG 15 European Citizen Card - SSCD PP's, where e.g. Gixel defined IAS ECC ecosystem, as well as the BSI definitions on EAC v2 ecosystem
- WG 16 dig sign eIAS tool for SE (Secure Element)
- WG 17 PP for SE
CWA
- CWA's - CEN Workshop Agreements - legacy
- CWA's - CEN Workshop Agreements - pointer
- CWA 14167-1/4 Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures
- CWA 14169 Secure Signature-Creation Devices "EAL 4+"
- CWA 14170 Security Requirements for Signature Creation Applications
- CWA 14171 General guidelines for electronic signature verification
- CWA 14172 -1/8 EESSI Conformity Assessment Guidance
- CWA 14174 FINREAD
- CWA 14355 Guidelines for the implementation of Secure Signature Creation Devices
- CWA 14365-1/2 Guide on the Use of Electronic Signatures
- CWA 14722 Embedded FINREAD
- CWA 14890-1/2 Application Interface for smart cards used as Secure Signature Creation Devices
- CWA 15264 eAuthentication
- CWA 15499-1 Personal Data Protection Audit Framework (EU Directive EC 95/46) Part I: Baseline Framework - The protection of Personal Data in the EU
- CWA 15499-2 Personal Data Protection Audit Framework (EU Directive EC 95/46) Part II: Checklists, questionnaires and templates for users of the framework - The protection of Personal Data in the EU
- CWA 15262 Inventory of Data Protection Auditing Practices
- CWA 15263 Analysis of Privacy Protection Technologies, Privacy- Enhancing Technologies (PET), Privacy Management Systems (PMS) and Identity Management systems (IMS), the Drivers thereof and the need for standardization
- CWA 15292 Standard form contract to assist compliance with obligations imposed by article 17 of the Data Protection Directive 95/46/EC (and implementation guide)
- EN 15713:2009 Secure disposal of confidential material
- Relevant extract
CENELEC
SOG-IS
Regarding security standards, there is also the SOG-IS group.
The SOG-IS agreement was produced in response to the EU Council Decision of March 31st 1992 (92/242/EEC) in the field
of security of information systems, and the subsequent Council recommendation of April 7th (1995/144/EC) on
common information technology security evaluation criteria.
The agreement was updated in January 2010. Participants are government organisations or government agencies from countries
of the European Union or EFTA (European Free Trade Association), representing their country or countries.
The participants work together to:
- Coordinate the standardisation of Common Criteria protection profiles and certification policies between European Certification Bodies in order to have a common position in the fast growing international CCRA group
- Coordinate the development of protection profiles whenever the European commission launches a directive that should be implemented in national laws as far as IT-security is involved
The agreement provides for member nations to participate in two fundamental ways:
- As certificate consuming participants and
- As certificate producers
Global de-facto standards and related matters
SECG
The Standards for Efficient Cryptography Group (SECG) is consortium founded by Certicom in 1998 to develop
commercial standards for elliptic curve cryptography (ECC).
Introduced implicit certificates (ECQV implicit certificate scheme) as a variant of public key certificates, such that a public key can be
reconstructed from any implicit certificate, and is said then to be implicitly verified, in the sense that the
only party who can know the associated private key is the party identified in the implicit certificate.
Implicit certificates contain an ID, public key and digital signature, but the data elements are super imposed into a string the size of the public key. For example, using an elliptic curve system at 160
bits would give us implicit certificates of size 160 bits.
With implicit certificates there is no explicit validation of the certificate authority's (CAs) signature on a certificate. Instead, a user computes a public key from the implicit certificate and simply uses it in e.g. key agreement protocols such as ECDH and ECMQV, or signing such as ECDSA. The operation will fail if the certificate is invalid. Thus ECQV is regarded as an implicit validation scheme. Computing the public key is very fast, much faster than a public key operation.
Implicit certificates are also small in size. An X.509 certificate is in the order of 1KB in size (~8000 bits). Using an elliptic curve system at 160 bits would give us implicit certificates with the size of 160 bits.
- SECG homepage
- The finalized SEC specifications are:
- SEC 1: Elliptic Curve Cryptography, Version 2.0
- Introduction
- Mathematical foundation
- Cryptographic components (domain parameters, key pairs, DH and MQV primitives, hash, key derivation, MAC, symmetric, key wrap, RNG, security levels)
- Signature schemes (ECDSA)
- Encryption and key transport schemes
- Key agreement schemes (DH, MQV)
- SEC 2: Recommended Elliptic Curve Domain Parameteres, Version 2.0
- Recommended domain parameters over Fp (secp192k1, secp192r1, ...) where k stands for Koblitz and r for random
- Recommended domain parameters over F2m (sect163k1, sect163r1, ...)
- SEC 4: Elliptic Curve Qu-Vanstone Implicit Certificates
- Cryptographic components (security levels, hash function, hashing to integers module n, RNG, domain parameter
generation and validation
- ECQV implicit certificate scheme (set-up, certificate request and generation, certificate public key extraction,
self-signed certificate generation scheme, self-signed implicit certificate public key extraction
ITU-T
X509
For certificates there are competing/complementary standards from ITU-T and IETF (PKIX certificate profiles).
The structure foreseen by the standards is expressed in Abstract Syntax Notation One (ASN.1).
Inside the structure, objects are found. OIDs serve to name almost every object type in X.509 certificates, such as components of Distinguished Names, CPSs, etc.
Extensions were introduced in X509 version 3. A CA can use extensions to issue a certificate only for a specific purpose.
An extension can be critical or non-critical:
- If an extension is critical and the system processing the certificate does not recognize the extension or cannot process it, the system MUST reject the entire certificate.
- A non-critical extension, can be ignored while the system processes the rest of the certificate.
- ITU X509 local info
- ITU X509 certificate - Wikipedia
- ITU X509 versions and corrigendums
- X.509 (10/2019)
- Section 1 General (references, definitions, frameworks overview, encoding in DER format)
- Section 2 Public-key certificate framework
- Public keys and certificates (certificates, extensions, trust anchor, entity relationship, certification path, uniqueness of names, ...)
- Extensions from Section 2, Subsection 9.2 (yes the numbering is odd): key and policy information extensions
- authority key identifier: identifies the public key to be used to verify the signature on this public-key certificate or CRL.
- subject key identifier: identifies the public key being certified.
- key usage:
- identifies the intended usage for which the public-key certificate has been issued.
- The intended usage may be further constrained by policy which may be stated in a certificate policy definition, a contract, or other specification.
- More than one bit may be set: digitalSignature, contentCommitment, keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, decipherOnly
- extended key usage: in addition to, or in place of the basic purposes indicated in the key usage extension.
- private key usage period: indicates the period of use of the private key corresponding to the certified public key. Applicable only for private key used for creating digital signatures
- certificate policies: lists certificate policies, recognized by the issuing CA, that apply to the public-key certificate, together with optional qualifier information pertaining to these certificate policies. The list of certificate policies is used in determining the validity of a certification path.
- policy mappings:
- shall be used in CA certificates only,
- allows an issuing CA to indicate that, for the purposes of the user of a certification path containing this CA certificate, one of the issuer’s certificate policies can be considered equivalent to a different certificate policy used in the subject CA’s domain.
- authorization and validation:
- may only be present in end-entity public-key certificates.
- Indicates that this public-key certification shall not be accepted if it cannot be checked against a particular authorization validation list (AVL).
- These extensions shall be used only as public-key certificate extensions, except for the authorityKeyIdentifier extension which may also be used as a CRL extension. Unless otherwise noted, these extensions may be used in both CA certificates and end-entity public-key certificates.
- Extensions from Section 2, Subsection 9.3 (yes the numbering is odd): Subject and issuer information extensions
- Subject alternative name extension: contains one or more alternative names, using any of a variety of name forms, for the entity that is bound by the issuing CA to the certified public key.
- Issuer alternative name extension: contains one or more alternative names, using any of a variety of name forms, for the CA or CRL issuer.
- Subject directory attributes extension: conveys directory attributes for assigning privileges associated with the subject of the public-key certificate.
- Associate information extension: conveys directory attributes for associating miscellaneous information with the subject.
- Trust models (Three cornered, four cornered (with trust broker))
- Public key certificate and CRL extensions
- Delta CRL relationship to base
- Authorization and validation lists (AVL)
- Certification path processing procedure
- PKI directory schema
- Section 3 Attribute certificate framework
- Attribute certficates
- Attribute authority
- PMI models
- Attribute certficate and attribute certficate revocation list extensions
- Delegation path processing
- PMI directory scheme
- Annex A Public-key and attribute certificate frameworks
- Annex B Reference definition of cryptographic algorithms
- Annex C Certificate extension attribute types
- Annex D External ASN.1 modules
- Annex E CRL generation and processing rules
- Annex F Examples of delta CRL issuance
- Annex G Privilege policy and privilege attribute definition examples
- Annex H Intro to publlic key crypto
- Annex I Examples of use of certification path constraints (basic constraints, policy mapping)
- Annex J Guidance on determining for which policies a certification path is valid
- Annex K Key usage certificate extension issues
- Annex L Deprecated extensions
- Annex M Directory concepts
- Annex N Considerations on strong authentication
- WWW legacy library - ITU-CCITT e.g. X.509
- ISI - X.509 OID registration
- ISI - X.509 OID list
X509 certificate formats and encoding
Certificate formats
The most popular certificate format is ITU's X.509, particularly the X.509v3 version standardised by the IETF.
Certificate encoding
The two major encoding schemes for X.509 certificates (and keys)
- DER (according to X.509, binary format)
- popular DER filenames: .cer, .crt, .der
- can be checked with ‘openssl x509 -in cert.crt -inform DER -text’
- PEM (according to IETF RFCs, base64 ASCII format), see PEM certificate encoding details
However, there is overlap and other extensions are used, so you can't always tell what you are working with just from looking at the filename.
Container formats
These include
- .p7b, .p7c - PKCS#7 stores a certificate, a certificate chain, and/or CRL(s) – also referred to as CMS (Cryptographic Message Standard) format
- .p12 - PKCS#12, may contain certificate(s) (public) and private keys - can be checked with openssl pkcs12 -in cert.crt -info
- .pfx - PFX, predecessor of PKCS#12 (usually contains data in PKCS#12 format, e.g., with PFX files generated in IIS)
ITU-T other
TBD
OASIS
OASIS DSS
- OASIS Digital Signature Services (DSS) core v1 - remote signing standard2007, chairs: Nick Pope and Juan Carlos Cruellas
- OASIS DSS TC
- Supports signature formats including XML and CMS for remote signing
- Designed around a basic "core" set of elements and procedures which can be profiled to support specific uses
such as time-stamping (including XML structured timestamps), corporate entity seals, electronic post marks and code signing.
- XML request/response protocols for signing and verifying XML documents and other data
- an XML timestamp format, and an XML signature property for use with these protocols
- Specifies:
- Core document defines the XML-based syntax and semantics for the basic services of signature generation/verification.
This includes:
- Definition of four basic messages: SignRequest, SignResponse, VerifyRequest and VerifyResponse.
They are defined to easily manage the most common signatures formats, ie, [XMLSig] and [CMS].
- Definition of an extensibility mechanism that allows the clients to further qualify or even increase the
extent of the requests through optional inputs. It also allows the servers to answer with extended responses
through the corresponding optional outputs.
- Definition of XML format for time-stamp token, based on XMLSig.
- Definition of mechanisms for managing generation and verification of digital signatures carrying time-stamp tokens
(both CMS-based [RFC 3161] and XML-based a specified in the core document itself)
computed on the signatures themselves (signature time-stamps).
- Definition of bindings for transport and security. The first ones specify how DSS messages are encoded and carried
over the most popular transport protocols (it defines bindings for HTTP (through HTTP POST exchanges) and SOAP 1.2).
The security bindings establish rules for providing confidentiality, authentication and integrity to the transport binding.
- OASIS DSS-X DSS eXtended or version 2.0 due
to problems of version 1.0
- OASIS DSS-X documents
- OASIS DSS-X core v2.0
OASIS SAML
OASIS KMIP
The Key Management Interoperability Protocol (KMIP) is an extensible communication protocol that defines message formats for the manipulation of cryptographic keys on a key management server. This facilitates data encryption by simplifying encryption key management. Keys may be created on a server and then retrieved, possibly wrapped by other keys. Both symmetric and asymmetric keys are supported, including the ability to sign certificates. KMIP also allows for clients to ask a server to encrypt or decrypt data, without needing direct access to the key.
The KMIP standard was first released in 2010. Clients and servers are commercially available from multiple vendors. The KMIP standard effort is governed by the OASIS standards body.
Cloud Signature Consortium
W3C
Emerging: BS 1008:2208 Evidential weight and legal admissibility of electronic information
RSA PKCS
- RSA PKCS
- PKCS#7 (also known as P7B) is a container format for digital certificates that is most often found in Windows and
Java server contexts, and usually has the extension .p7b. PKCS#7 files are not used to store private keys.
- PKCS#12 (also known as PKCS12 or PFX) is a common binary format for storing a certificate chain and private key in
a single, encryptable file, and usually have the filename extensions .p12 or .pfx.
IETF
CMS
PKI and PKIX
The PKIX Working Group was established in 1995 to develop Internet standards to support X.509-based
Public Key Infrastructures (PKIs).
- Initially PKIX pursued this goal by profiling X.509 standards developed by the CCITT (later the ITU-T).
- Later, PKIX initiated the development of standards that are not profiles of ITU-T work, but rather are independent initiatives designed to address X.509-based PKI needs in the Internet.
PKI and PKIX
Trust anchor
CP and CPS
Other
XML
- IETF RFC 2807 XML Signature Requirements
- IETF RFC 3275 XML-Signature Syntax and Processing
- other RFC's address canonical XML, XPath and related matters
IPSEC
TLS
Comprises two layers: the TLS record and the TLS handshake protocols.
PEM -Privacy Enhancement for Internet Electronic Mail
PEM is best known as a de facto file format for storing and sending cryptographic keys, CSRs, certificates, and other data, based on a set of 1993 IETF RFCs.
The original standards were never broadly adopted, and were supplanted by PGP and S/MIME. However the textual encoding PEM defined became popular and was formalised by the IETF in RFC 7468.
A single PEM file could contain
- an end-entity certificate
- a private key, or
- multiple certificates forming a complete chain of trust.
Info:
- PEM Wikipedia
- ASCII Wikipedia
- Control characters: the first 32 codes (numbers 031 decimal) are reserved for control characters, originally intended
not to represent printable information, but rather to control devices (such as printers) that make use of ASCII, or to provide meta-information about data streams such as those stored on magnetic tape.
Examples: STX, ETX, ACK, LF, etc
- Printable characters: codes 20-hex to 7E-hex, represent letters, digits, punctuation marks, and miscellaneous symbols. There are 95 printable characters in total.
PEM encoding, 2015
- IETF RFC 7468 Textual Encodings of PKIX, PKCS, and CMS Structures
- Certificate Revocation Lists
- PKCS #7 Cryptographic Message Syntax
- PKCS #10 Certification Request Syntax
- PKCS #8 Private Key, refers also to RFC 5958
- An unencrypted private key start with the label -----BEGIN PRIVATE KEY-----
- An encrypted private key start with the label -----BEGIN ENCRYPTED PRIVATE KEY-----
- Attribute Certificates
- Subject Public Key Info
PEM encoding of certificates
A PEM file is a text file containing one or more items in Base64 ASCII encoding, each with plain-text headers and footers (e.g. -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----).
Typical use:
- .xml elements in xml dsig structures, these are Base64 encoded
- .pem - Base64 encoded certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----“, can be checked with a text editor, or with ‘openssl x509 -in certname.crt -text’
You can use e.g. base64decode online.
PEM's original 1993 RFCs (legacy)
- IETF RFC 1421 Part I: Message Encryption and Authentication Procedures
- IETF RFC 1422 Part II: Certificate-Based Key Management
- IETF RFC 1423 Part III: Algorithms, Modes, and Identifiers
- IETF RFC 1424 Part IV: Key Certification and Related Services (key certification, certificate revocation list (CRL) storage, and CRL retrieval)
S/MIME
- IETF RFC 8551 S/MIME v4 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification
- A protocol for adding cryptographic signature and encryption services to MIME data.
- Defines how to create a MIME body part that has been cryptographically enhanced according to the Cryptographic Message Syntax (CMS), which is derived from PKCS #7 [RFC2315].
- S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity, and non-repudiation of origin (using digital signatures), and data confidentiality (using encryption). As a supplementary service, S/MIME provides message compression.
PGP
PGP is used for signing, encrypting, and decrypting texts, e-mails, files, directories, and disk partitions.
Phil Zimmermann developed PGP in 1991. The open source version is GPG.
Refer also to crypto-tools
JOSE, JWS, etc.
IEEE
Other