- Global de-facto - SECG, ITU-T, IETF, W3C, OASIS, CSC
- FR - ANSSI including product certification
- US - ANSI, NIST, FIPS
ISO crypto standards
Hashing and MAC
- IS 10118 Hashing
- IS 9797 MAC
- IS 18033 Encryption
- IS 10116 Modes of operation
- IS 15946 ECC
- IS 9798 Entity authentication
- ISO/IEC 20089: Direct Anonymous Attestation
- ISO/IEC 20009: Anonymous Entity Authentication
- IS 13888 Non-repudiation
- IS 18014 Time-stamping
The CEF DSS documentation is practical.
- 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)
- ISO/IEC 18370 Blind Signature
- ISO/IEC 20008: Anonymous digital signatures
- ISO/IEC 29191: Requirements on relative anonymity with identity escrow model for authentication and authorization using group signatures
- ISO/IEC 11770-1:2010 Key management — Part 1: Framework
- 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.
- NP 24745 Biometric template protection
- IS 19772 Authenticated encryption
- 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.
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 an an overview ref to ETSI security workshop and their whitepapers such as "ETSI White Paper No. 1 Security for ICT - the Work of ETSI" by Charles Brookson and Dionisio
Zumerle (January 2006). Areas covered by ETSI:
- GSM and 3GPP
- SAGE (algorithms such as for GSM (A3, A5, A8), 3GPP (Milenage family), UMTS radio interface (UEA1, UIA1, both based
on SAGE's Kasumi, actually a variation of Mitsubishi's Misty1)
- TETRA and DECT
- EMTEL (emergency) and MESA (safety)
- LI - Lawfull Interception
- TIPHON, SPAN, TISPAN (Telecom and Internet Converged Services and Protocols for Advanced Networks)
- Broadcasting, satellite, IPCablecom
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.
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
ETSI M460 STFs
ETSI other 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 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.
ETSI CAdES, XAdES, PAdES, AsIC, JAdES
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 (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 February 2016, ETSI publishes ETSI EN 319 132-1 V1.1.0 where the profiles have been omitted
- ETSI TS 102 778 parts 1 to 5 PDF Advanced Electronic Signature see also PADES FAQ
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 - to be ETSI TS 119 182-1 - by Cruellas
ETSI TR and TS (selection)
Foundation is 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 ESI introduction
- 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
- 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 ESI 119 area 3 cryptographic suites
- ETSI TS 119 312 Cryptographic suites
ETSI ESI 119 area 4 TSPs supporting digital signatures
- TS 119 400
- 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 Protocols for remote digital signature validation
- TS 119 495 PSD2 Qualified Certificate standard
- 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
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
- 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
Don't forget the influencial IETF RFCs
- ETSI TS 101 861 Time stamping profile
- ETSI TS 102 023 Policy requirements for time-stamping authorities
- 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
- RFC 3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
- RFC 3628 Policy Requirements for Time-Stamping Authorities (TSAs)
Refer also to related CEN standards.
- ETSI TS 101 456 Policy Requirements for CA issuing QC
- 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 TS 102 778 parts 1 to 5 PDF PDF Advanced Electronic Signature see also PADES FAQ
- ETSI 419 221-5 PP for QSCD
ETSI standards related to certificates
The participants work together to:
- ref Nacho
- TS 101 862 QCP – Qualified Certificate Profile
ETSI EU Trust Services
ETSI standards related to EU trust services
- Policy requirements, defined in ETSI EN 319 4xx series (e.g. EN 319 411-2) and EN 319 5xx series
- Assessment scheme, defined in ETSI EN 319 403
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
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 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 - Comité Européen de Normalisation (+/- EU's counterpart for ISO)
CEN signing standards
CEN Standards for remote signing systems:
CEN standards related to remote signature:
- EN 419 241-1: General System requirements
- prEN 419 241-2: Protection Profile for QSCD for Server Signing
- EN 419 221-5: Cryptographic module
- 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
CEN other standards
- 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'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
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 agreement provides for member nations to participate in two fundamental ways:
- 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
- As certificate consuming participants and
- As certificate producers
Global de-facto standards and related matters
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 (CA’s) 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
- 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
- OASIS DSS, SAML, XACML, web services, ebXML, ...
- 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
- Core document defines the XML-based syntax and semantics for the basic services of signature generation/verification.
- 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
Cloud Signature Consortium
Emerging: BS 1008:2208 Evidential weight and legal admissibility of electronic information
- 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.
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.
- IETF RFC 2807 XML Signature Requirements
- IETF RFC 3275 XML-Signature Syntax and Processing
- other RFC's address canonical XML, XPath and related matters
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, 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.
PEM's original 1993 RFCs
- 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)
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
- 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 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
Certificate formats and encoding
The most popular certificate format is the ITU's X.509, particularly the X.509v3 version standardised by the IETF.
The two major encoding schemes for X.509 certificates (and keys) are PEM (Base64 ASCII), and DER (binary).
However, there is some overlap and other extensions are used,
so you can’t always tell what kind of file you are working with just from looking at the filename.
can be used to create/display certificates. E.g. '>openssl x509 -in sample.cer -noout -text'
- Cert decoder from redkestrel - nice
- GoDaddy cert decoder online
- PEM is the most common format for X.509 certificates, CSRs, and cryptographic keys.
- 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-----).
- A single PEM file could contain
- an end-entity certificate
- a private key, or
- multiple certificates forming a complete chain of trust.
- PEM Wikipedia
- ASCII Wikipedia
- Control characters: the first 32 codes (numbers 0–31 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.
France - ANSSI
- ANSSI - Agence National de la Sécurité des Systèmes
- ANSSI - certified products
US standards and related matters
E.g. according to FIPS or EAL levels