ISO 22376:2023

Security and resilience - Authenticity, integrity and trust for products and documents - Specification and usage of visible digital seal (VDS) data format for authentication, verification and acquisition of data carried by a document or object

This document defines the conditions necessary for the interoperable deployment of visible digital seals (VDSs). It describes the structure, possible forms of representation, production process and verification process applicable to VDSs, for any type of document or object to which they relate. This document does not establish requirements for users that issue and verify documents or for users that implement and deploy VDSs. This document does not apply to detailed response formatting functions (RFFs). These requirements and functions are defined by the trust service operator (TSO) and generally cover functionalities such as the security levels of certificates and governance rules to be applied to document issuers and trust service providers (TSPs) intervening in the VDS ecosystem. This document does not apply to the governance related to the operation of the VDS scheme. It is not intended to replace the specifications from Agence Nationale des Titres Sécurisés (ANTS), Bundesamt für Sicherheit in der Informationstechnik (BSI) and International Civil Aviation Organization (ICAO) documents.

Sécurité et résilience — Authenticité, intégrité et confiance pour les produits et les documents — Spécifications relatives aux formats de données et l'utilisation du Cachet Électronique Visible (CEV) aux fins d'authentification, de vérification et d'acquisition des données véhiculées par un document ou un objet

Le présent document définit les conditions nécessaires au déploiement interopérable de cachets électroniques visibles (CEV). Il décrit la structure, les formes de représentation possibles ainsi que les processus de production et de vérification des CEV, pour tout type de document ou d'objet auxquels ils se rapportent. Le présent document ne définit pas d'exigences pour les utilisateurs qui émettent ou vérifient des documents ni pour les utilisateurs qui mettent en œuvre et déploient des CEV. Le présent document ne s'applique pas aux fonctions de formatage de la réponse (RFF). Ces exigences et fonctions sont définies par un opérateur de service de confiance (OSC) et visent des fonctionnalités telles que les niveaux de sécurité des certificats utilisés et les règles de gouvernance à appliquer aux émetteurs de documents et aux prestataires de services de confiance (PSC) intervenant pendant le processus de production et de lecture des CEV. Le présent document ne s'applique pas à la gouvernance liée au fonctionnement du schéma CEV. Il n'est pas destiné à remplacer les spécifications des documents de l'Agence nationale des titres sécurisés (ANTS), du Bundesamt für Sicherheit in der Informationstechnik (BSI) et de l'International Civil Aviation Organization (ICAO).

General Information

• Status: Published
• Publication Date: 15-Aug-2023
• ICS: 03.100.01 - Company organization and management in general
• ICS: 35.040.50 - Automatic identification and data capture techniques
• Technical Committee: ISO/TC 292 - Security and resilience
• Drafting Committee: ISO/TC 292 - Security and resilience
• Current Stage: 6060 - International Standard published
• Start Date: 16-Aug-2023
• Due Date: 08-Oct-2023
• Completion Date: 16-Aug-2023

Overview

ISO 22376:2023 specifies the data format and usage model for a Visible Digital Seal (VDS) - a structured, often machine-readable presentation (for example, an MRC/QR code) that provides authenticity, integrity and trust for data carried by a document or object. The standard defines the VDS structure, representation options, production and verification processes to enable interoperable deployment across sectors while remaining technology-agnostic. ISO 22376 focuses on how VDSs are formed and checked; it does not set governance rules for trust service operators (TSOs) or trust service providers (TSPs), nor does it replace existing national or sector specifications (ANTS, BSI, ICAO).

Key topics and technical requirements

The standard lays out the conditions and structural building blocks required for interoperable VDS implementation:

• VDS structure and encoding - binary encoding and defined logical sections (header, payload, signature, auxiliary data) to carry signed data.
• Manifest and trust service list (TSL) - references for scheme metadata, policy extensions and TSO identity/locations supporting verification.
• Signing certificate handling - certificate references, revocation checks and usage-list extensions to support trust validation.
• Production and verification processes - lifecycle steps for creating a VDS and for acquiring, parsing and cryptographically verifying VDS data.
• XML security and schema definitions - use of XML schemas for manifest and TSL examples; informative annexes include encoding and schema samples.
• Interoperability considerations - design choices that enable heterogeneous track-and-trace, anti-counterfeiting and cross-border verification. Note: ISO 22376 excludes detailed Response Formatting Functions (RFFs) and governance of VDS schemes.

Practical applications

ISO 22376 enables secure, low-cost authentication and data integrity for a wide range of use cases:

• Track-and-trace and supply chain authentication for products and packaging
• Anti-counterfeiting verification for documents, credentials, labels and assets
• Secure presentation of product data via QR codes or other machine-readable codes
• Universal reader/Trusted Entry Point (TEP) implementations for inspectors and consumers Because the VDS is technology-agnostic, it can be combined with ESEDS and existing identifier schemes (e.g., GS1 Digital Link) and digital signatures (e.g., ISO/IEC 20248-based approaches).

Who should use this standard

• System architects and developers building secure verification/readers for documents and products
• Authorities and organizations implementing machine-readable authenticity marks
• Trust service operators (TSOs) and TSPs integrating VDS support into services
• Standards and compliance teams planning interoperable track-and-trace or anti-counterfeit solutions

Related standards

• ISO/IEC 20248 (electronic seals and signatures for data)
• ISO 22300 (security and resilience vocabulary)
• ISO 3166-1, ISO 14533-1/2, ISO/IEC 8825-1 (referenced standards and profiles) These related specifications complement ISO 22376’s VDS data format and verification workflows.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 22376
First edition
2023-08
Security and resilience — Authenticity,
integrity and trust for products and
documents — Specification and usage
of visible digital seal (VDS) data
format for authentication, verification
and acquisition of data carried by a
document or object
Sécurité et résilience — Authenticité, intégrité et confiance pour les
produits et les documents — Spécifications relatives aux formats
de données et l'utilisation du Cachet Électronique Visible (CEV) aux
fins d'authentification, de vérification et d'acquisition des données
véhiculées par un document ou un objet
Reference number
© ISO 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 General concepts . 5
5 Structures and resources . 6
5.1 General . 6
5.2 Trust service list and extensions. 6
5.2.1 General . 6
5.2.2 Extensions . 6
5.2.3 TSO identity . 6
5.2.4 TSO manifest location . 6
5.2.5 CA reference . 6
5.2.6 Public certificate directory . 7
5.2.7 XML security . 7
5.2.8 Example and verification . 7
5.3 Manifest . 7
5.3.1 General . 7
5.3.2 Information section . 7
5.3.3 Schema section . 8
5.3.4 Extensions section . 10
5.3.5 XML security . 11
5.3.6 Example and verification . 11
5.4 Manifest extensions . 11
5.4.1 General . 11
5.4.2 Policies extension . 11
5.4.3 Authorized usage policy . 11
5.5 VDS . 11
5.5.1 General . 11
5.5.2 Binary encoding .12
5.5.3 Header section . 12
5.5.4 Payload section . 14
5.5.5 Signature section .15
5.5.6 Auxiliary data section. 16
5.5.7 Example . 16
5.6 Signing certificate . 16
5.6.1 General . 16
5.6.2 Usage list extensions. 17
6 Production process .17
7 Verification process .18
7.1 General concepts . 18
7.2 Acquisition of VDS data. 18
7.3 Header structure analysis . 18
7.4 Reference retrieval and verification . 18
7.4.1 General . 18
7.4.2 TSL . 18
7.4.3 Manifest . 19
7.4.4 Signing certificate and certificate revocation list . 19
7.5 Payload processing . 19
7.6 Extensions processing . 19
7.7 Signature verification . 19
iii
7.8 Document data presentation . 19
Annex A (informative) VDS encoding example .20
Annex B (informative) TSL example .22
Annex C (informative) Manifest example .26
Annex D (informative) TSL XML schema definition example .28
Annex E (informative) Manifest XML schema definition example .29
Bibliography .40
iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use
of (a) patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed
patent rights in respect thereof. As of the date of publication of this document, ISO had not received
notice of (a) patent(s) which may be required to implement this document. However, implementers are
cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents. ISO shall not be held responsible for identifying any or all
such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO’s adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 292, Security and resilience.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
v
Introduction
A visible digital seal (VDS) is a presentation of a structured data set, often in the form of a machine-
readable code (MRC), used to ensure the authenticity and integrity of key data associated with a
document or object at a relatively low cost and with a high level of security through asymmetrical
cryptography.
Systems based on a VDS format can enable enhanced and interoperable secure track and trace with
related anti-counterfeiting authentication.
The trustworthiness of the data carried by a VDS is dependent on the confidence that can be granted
to the certificate related to its cryptographic environment. The VDS specified in this document is one
possible presentation of electronically signed encoded data sets (ESEDSs), such as, for example, uniform
resource identifier (URI) formatted in accordance with GS1 Digital Link Standard and protected by
digital signature in accordance with ISO/IEC 20248. The expected confidence for this VDS is provided
via a related ESEDS scheme.
This document will not interfere with existing authentication, traceability and identification systems.
It enables interoperability between technologically heterogenous track and trace and anti-counterfeit
environments.
Implementation of a trusted entry point (TEP) is enabled, helping to reduce the number of object
identification applications by combining them into a universal and use-case resilient reader for
professional inspectors and consumers. This document is intended for developers and users wishing
to enable secure and interoperable track and trace and authentication systems. Since the method is
technology agnostic, it is available for all industrial sectors where unique identifiers (UIDs) or data
need to be secured and inspected in a global and multilingual environment.
vi
INTERNATIONAL STANDARD ISO 22376:2023(E)
Security and resilience — Authenticity, integrity and trust
for products and documents — Specification and usage of
visible digital seal (VDS) data format for authentication,
verification and acquisition of data carried by a document
or object
1 Scope
This document defines the conditions necessary for the interoperable deployment of visible digital seals
(VDSs). It describes the structure, possible forms of representation, production process and verification
process applicable to VDSs, for any type of document or object to which they relate.
This document does not establish requirements for users that issue and verify documents or for users
that implement and deploy VDSs.
This document does not apply to detailed response formatting functions (RFFs). These requirements
and functions are defined by the trust service operator (TSO) and generally cover functionalities such
as the security levels of certificates and governance rules to be applied to document issuers and trust
service providers (TSPs) intervening in the VDS ecosystem.
This document does not apply to the governance related to the operation of the VDS scheme. It is not
intended to replace the specifications from Agence Nationale des Titres Sécurisés (ANTS), Bundesamt
für Sicherheit in der Informationstechnik (BSI) and International Civil Aviation Organization (ICAO)
documents.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
code
ISO 14533-1, Processes, data elements and documents in commerce, industry and administration — Long
term signature — Part 1: Profiles for CMS Advanced Electronic Signatures (CAdES)
ISO 14533-2, Processes, data elements and documents in commerce, industry and administration — Long
term signature — Part 2: Profiles for XML Advanced Electronic Signatures (XAdES)
ISO 22300, Security and resilience — Vocabulary
ISO/IEC 8825-1, Information technology — ASN.1 encoding rules — Part 1: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
ISO/IEC 9834-1, Information technology — Procedures for the operation of object identifier registration
authorities — Part 1: General procedures and top arcs of the international object identifier tree
ISO/IEC 9834-8, Information technology — Procedures for the operation of object identifier registration
authorities — Part 8: Generation of universally unique identifiers (UUIDs) and their use in object identifiers
ISO/IEC 15459-2, Information technology — Automatic identification and data capture techniques —
Unique identification — Part 2: Registration procedures
ETSI TS 102 853, Electronic Signatures and Infrastructures (ESI); Signature verification procedures and
policies Technical Specification
ETSI TS 119 612, Electronic Signatures and Infrastructures (ESI); Trusted Lists
IETF RFC 3339, Date and Time on the Internet: Timestamps
IETF RFC 3986, Uniform Resource Identifiers
IETF RFC 4387, Internet X.509 Public Key Infrastructure, Operational Protocols: Certificate Store Access
via HTTP
IETF RFC 4648:2006, The Base16, Base32, and Base64 Data Encodings
IETF RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile
NIST FIPS 180-4, Secure Hash Standard (SHS)
NIST FIPS 186-5, Digital Signature Standard (DSS)
PCRE, Perl Compatible Regular Expressions [online]. Available at: https:// www .pcre .org/
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 22300 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
machine-readable code
MRC
graphical symbol or electronic device, or a combination of the two, containing a set of signs, characters,
patterns or signals that can be interpreted by an acquisition system
Note 1 to entry: Examples of MRC include, but are not limited to, 2D barcodes and radio-frequency identification
(RFID) tags.
3.2
electronically signed encoded data set
ESEDS
structured data set containing the header, payload, signature and optional auxiliary data block
Note 1 to entry: The payload type and issuer identity are included in the header.
Note 2 to entry: ESEDS can often be expressed as machine-readable code (3.1).
3.3
visible digital seal
VDS
structured data set, often in the form of a machine-readable code (3.1), containing a payload and its
signature from the issuer
Note 1 to entry: A header identifies the type of payload and the issuer. An optional auxiliary data block may be
added after the signature
Note 2 to entry: VDS specified in this document is one of possible various electronically signed encoded data sets
(3.2).
3.4
asymmetrical cryptography
encryption/decryption operations performed using a key pair: a private key used by the issuer to sign
documents (3.10) and a public key used to verify the signature
Note 1 to entry: The two keys have an “asymmetric” role, hence the term.
3.5
base36
notation for encoding arbitrary data using a restricted set of symbols made of 36 characters: digits 0 to
9 and letters A to Z
Note 1 to entry: Symbol “Z” has a value of 35
3.6
C40 encoding
encoding to reduce the number of bytes required to encode a string of characters
Note 1 to entry: C40 encoding is explained in ISO/IEC 16022:2006.
3.7
certificate authority
CA
service offered by a trust service provider (3.21) to create, issue and produce certificates (3.11) on behalf
of users, and ensure the integrity of the electronic identification of signatories
Note 1 to entry: The CA signs the certificate (with its own private key) to guarantee the integrity of the certificate
and the accuracy of the data contained in the certificates that it issues.
3.8
certificate revocation list
CRL
list of certificates (3.11) that have been revoked by the issuing certificate authority (3.7)
Note 1 to entry: The CRL shall be in in accordance with IETF RFC 5280.
3.9
digital signature algorithm
DSA
mathematical technique used to validate the authenticity and integrity of a message, software or digital
document
Note 1 to entry: These include, but are not limited to, the RSA and ECDSA algorithms defined in NIST FIPS 186-4.
3.10
document
information and the medium on which it is contained
Note 1 to entry: The medium can be paper or any other substrate, magnetic, electronic or optical computer disc,
photograph or master sample, or a combination thereof.
3.11
certificate
electronic certificate
X.509 certificate
electronic file attesting that a cryptographic key pair belongs to either a physical or legal person, a
hardware component or a software component as identified in the certificate
Note 1 to entry: Certificates are issued by a certificate authority (CA) (3.7). By signing the certificate, the CA
certifies the association between the key pair with the person, hardware component or software component.
A certificate may be revoked if this association can no longer be established. A certificate is valid for a limited
amount of time.
3.12
hash
operation that consists of applying a mathematical function to create a digital fingerprint on a data
block, transforming the data block into a fixed-size code for authentication and storage purposes
Note 1 to entry: Any change to the original data block results in a change in the hash value.
3.13
manifest
external resource containing information in extensible markup language (XML) format about the visible
digital seal (3.3) use case, its schema (3.18), validation policies and optional extensions
3.14
message pack
binary data exchange format used to represent simple data structures and tables
Note 1 to entry: The purpose of message pack is to be as compact and simple as possible. It is defined in
Reference [10].
3.15
online certificate status protocol
OCSP
protocol to validate a certificate’s (3.11) status, usually to determine if the certificate has been revoked
Note 1 to entry: OCSP is explained in IETF RFC 6960.
Note 2 to entry: OCSP is an alternative to a certificate revocation list (3.8).
3.16
regular expression
character string that describes, using a specific syntax, a set of allowed strings or characters
Note 1 to entry: The regular expression shall conform to the Perl Compatible Regular Expressions (PCRE)
specification.
3.17
response formatting function
RFF
function specifying how to format and present the output with visible digital seal (3.3) verification
results
3.18
schema
payload data structure that allows for data encoding, decoding and verification
3.19
symbology
description of numeric, text or binary data encoding in a machine-readable code (3.1) defining the
redundancy, error correction code mechanisms and specifying the quiet zone around the barcode
3.20
trust service operator
TSO
entity that defines the governance structure and technical requirements of the trust service, and
oversees the overall operations
Note 1 to entry: In some industries, the TSO acts as the authentication service body (ASB).
3.21
trust service provider
TSP
entity tasked with defining the certificate authority (CA) (3.7) trust framework and governance
structure, offering certificate service(s), operating the CA and ensuring compliance with said
governance
3.22
trusted entry point
TEP
method provided and/or certified by the trust service operator (3.20) having support for the response
formatting function (3.17), open for additional object identification and authentication systems (OIAS),
and able to resolve without ambiguity any unique identifier (UID)
3.23
trust service list
TSL
list containing compliant information about the trust service operator (TSO) (3.20), the trust service
providers (TSPs) (3.21) and the TSP’s certificate authority (3.7) authorized to issue certificates (3.11) to
sign electronically signed encoded data sets (3.2)
Note 1 to entry: ETSI TS 119 612 sets out what is a compliant TSL.
Note 2 to entry: TSLs are extensible using extensible markup language (XML) defined by the TSO.
3.24
uniform resource identifier
URI
character string that unambiguously identifies a resource
Note 1 to entry: The syntax shall conform to IETF RFC 3986.
4 General concepts
A VDS is usually represented in the form of one or a combination of MRC(s). It contains data to be
protected and the electronic signature of the data by the document issuer. VDSs are read using an
optoelectronic or electronic device, e.g. a scanner, 2D barcode reader, RFID reader or a combination of
devices.
The detailed implementation of a VDS is always conditioned by a specific use case. Defined by a group
of experts, each use case determines the key data fields to be included in the schema, as well as the
field constraints. If required, the use case may also include additional verification policies and features
defined in TSO extensions to satisfy the business rules for the use case. Use cases are then translated
into a machine-readable format (secure XML-format manifest file) so that those who produce and
verify the VDSs can interpret and process the information in a standard and deterministic way, while
respecting the rules defined for each use case. The manifest is extensible through XML extensions
defined by the TSO, with the aim of enabling a richer set of functionalities, such as additional VDS
verification policies (e.g. authorized symbologies, signer’s legitimacy, validity period), the RFF and
post-verification business rules.
Many steps have been taken to minimize the amount of space used by the data carrier and to maximize
the amount of space that can be used for data. As such, the VDS does not contain the certificate used
for the signature or the definition of the use case; rather, the VDS contains identifiers allowing for their
retrieval (see 5.3.2). The VDS payload and signature are also structured to minimize size.
To ensure the reliability of the service, verification of the different elements of the VDS and the chain of
trust is essential. Therefore, verification is a normative component to this specification (see Clause 7).
Each element supporting the VDS is protected and signed by the TSO to ensure its trustworthiness.
In this document, in order to unambiguously differentiate hexadecimal numbers from others, a prefixed
notation “0x” is used.
5 Structures and resources
5.1 General
All URI and endpoints shall be in lower case.
5.2 Trust service list and extensions
5.2.1 General
The TSL shall conform to ETSI TS 119 612, with the exception of the field which is
optional, and include information regarding the TSO and authorized TSP’s certificate authority (CA) to
enable trusted service operation.
5.2.2 Extensions
The operation of a VDS trust service requires adding the following three attributes that are not defined
in ETSI TS 119 612:
— URI to locate manifests;
— CA reference for each TSP Service;
— URI to locate signing certificates for each CA.
These shall be defined through extensions.
5.2.3 TSO identity
The TSO shall be identified in accordance with ISO/IEC 15459-2 by an Issuing Agency Code (IAC). This
IAC code shall be used to locate the TSL.
5.2.4 TSO manifest location
The VDS header includes a reference to the manifest. To locate the manifest, the TSL shall include a URI
to the manifest directory.
The manifest directory URI is defined by the extension attribute in the scheme
extensions of the TSL using the following xPath:
/TrustServiceStatusList/SchemeInformation/SchemeExtensions/Extension/
vdsext:VDSManifestResource
The manifest URI is a concatenation of the manifest directory URI and the manifest ID (in hexadecimal
format, always in lower case letters). An example to retrieve manifest 0x89AB01 with the
extension value is as follows:
“https://manifest.otentik.codes”:
https://manifest.otentik.codes/89ab01.xml

5.2.5 CA reference
The CA reference is a four-character string included in the VDS header to locate the signing certificate
and to ensure the CA validity in the TSL. It is composed of:
— CA issuing country (ISO 3166-1 Alpha2), in upper case letters;
— CA identifier: two digits assigned by the TSO.
The CA reference is defined by the extension attribute in the TSL’s service
information extensions using the following xPath:
/TrustServiceStatusList/TrustServiceProviderList/TrustServiceProvider/TSPInformation/
ServiceInformationExtensions/Extension/vdsext:VDSAuthorityID

5.2.6 Public certificate directory
The VDS header includes a reference to the signing certificate. To locate the certificate, the TSL shall
include, for each CA, a URI to the certificate directory. The TSP’s CA identifier should be present in the
URI.
The certificate endpoint is defined by the attribute in the service information
extensions of the TSL using the following syntax:
/TrustServiceStatusList/TrustServiceProviderList/TrustServiceProvider/
TSPServices/TSPService/ServiceInformation/ServiceInformationExtensions/Extension/
vdsext:VDSCertResource
The certificate URI is a concatenation of the certificate endpoint and the certificate reference number
(in base36 format). This URI format shall conform to IETF RFC 4387. An example to retrieve certificate
“09HZ” issued by a CA that is assigned the identifier “FR01” and the to “https://
trust.otentik.codes/fr01” is as follows:
https://trust.otentik.codes/fr01/09hz.cer

5.2.7 XML security
To ensure its integrity, the TSL shall be electronically signed by the TSO in accordance with ISO 14533-1
CAdES or ISO 14533-2 XAdES-B format. The TSO may detail the required parameters and characteristics
of the signature.
5.2.8 Example and verification
See Annex B for a TSL example.
The TSL shall include a xsi: schemaLocation directive to facilitate automated XML validation (see the
example in Annex D).
5.3 Manifest
5.3.1 General
The manifest is a machine-readable definition of a use case. It contains various sections: use case
information, data schema and optional extensions (defined by the TSO). The VDS header includes a
reference to a manifest. The reference number shall be assigned by the TSO.
5.3.2 Information section
This section links the machine-readable manifest identifier to a human-readable use case name and
description. The list of attributes and their description is given in Table 1.
Table 1 — Information section attributes
Attribute Description
Id
Use case identifier (six hexadecimal characters).
Corresponds to the manifest ID field in the VDS header.
Version
Use case version (informative only). Allows for non-breaking changes in the
data schema, such as changes in the name or description of the use case, or
non-breaking changes to extension information.
Name
Use case name. Multilingual.
Description
Use case description. Multilingual.
An example of the information section is as follows:


89AB01
1

Use Case Name
Nom du cas d’usage


Use case description
Description du cas d'usage

...

5.3.3 Schema section
This section defines, for a specific use case, the structure of the information in the VDS payload and
auxiliary data sections as well as the field validation rules. The schema is used both for VDS production
and verification.
The default Payload and AuxData encoding format is MessagePack. The TSO may define support for
other encoding formats. When using MessagePack encoding, the VDS Payload and AuxData data shall
be encoded in the same order as the manifest’s schema definition. The list of attributes and their
description is given in Table 2.
Table 2 — Schema section attributes
Attribute Description
Payload
Defines the data structures, whether optional or mandatory, that will be signed. The optional
parameter encoding is used for formats other than MessagePack (CBOR, JSON, TLV or any other),
e.g. )
AuxData
Defines the data structures that are not be signed. The auxiliary data section is optional and uses
the same XML structure and encoding principles as the payload.
Types
Defines custom field types to be referenced by objects and object arrays.
The schema can define data types and constraints, such as permitted characters and minimum/
maximum lengths or values. The schema supports typical data fields as well as objects and data arrays.
When a TSO authorizes a specific data structure, it shall include the ability to decode that data structure
in the TEP reader application.
An example of the schema section is as follows:







[A-Z0-9]
C40





1
9999















[A-Za-z]





2000-01-01






See Annex C for more detailed examples.
The manifest uses common field types, as well as objects, arrays and C40-encoded strings (see Table 3).
NOTE String encoding generally reduces the data size of the encoded string (albeit with a reduced character
set) and is available for any symbology.
Table 3 — Schema parameters and related constraints
Schema Optional parameter constraints
parameters
Integer

Nillable: the field is optional
Min: minimum value of the integer
Max: maximum value of the integer
Boolean

Nillable: the field is optional
Float

Nillable: the field is optional
Min: minimum value of the float
Max: maximum value of the float
TTabablele 3 3 ((ccoonnttiinnueuedd))
Schema Optional parameter constraints
parameters
String

Nillable: the field is optional
MinLength: minimum number of characters
MaxLength: maximum number of characters
Pattern: regular expression in accordance with Perl Compatible
Regular Expressions (PCRE) defining the accepted characters in the
string
Encoding: alternative encoding type if the default UTF-8 isn’t
adequate. Only value C40 is accepted.
Binary

Nillable: the field is optional
MinLength: minimum number of bytes
MaxLength: maximum number of bytes
Timestamp

Nillable: the field is optional
Date
Encodes the number of days (positive or negative) between a date and
a reference date.

Nillable: the field is optional
From: reference date using the format YYYY-MM-DD. Default reference
date is 1900-01-01
NotBefore: minimum valid date
NotAfter: maximum valid date
Object

Nillable: the field is optional
Objects are defined in a custom type, and are encoded as an array of
fixed size, using one entry of the array for each field defined in the
custom type.
IntegerArray
BooleanArray Nillable: the array is optional
FloatArray MinSize: minimum array size
StringArray MaxSize: maximum array size
BinaryArray In addition to the ArrayConstraints, arrays should have constraints
that correspond to the field type in the array (Integer, Boolean, Float,
TimestampArray
etc.)
DateArray
ObjectArray
5.3.4 Extensions section
The manifest’s XML shall be structured to allow extensions through the /Manifest/Extensions
attribute.
5.3.5 XML security
To ensure its integrity, the manifest shall be electronically signed by the TSO in accordance with
ISO 14533-1 CAdES or ISO 14533-2 XAdES-B format. TSO may detail the required parameters and
characteristics of the signature.
5.3.6 Example and verification
See Annex C for an example of a manifest.
For automatic verification, the manifest shall include the xsi: schemaLocation directive. See the example
in Annex E for more details.
5.4 Manifest extensions
5.4.1 General
The TSO is responsible to define the default validation policies in accordance with ETSI TS 102 853.
Some policies can be added or overridden by a use case and defined in the manifest.
5.4.2 Policies extension
The policies extension is defined as follows:

...

5.4.3 Authorized usage policy
The TSO shall put in place the policy, ensuring that the signing certificate is legitimately authorized to
sign a VDS for a specific use case.
This policy is tagged Authorized Usage.
When this policy is defined, VDS verification shall fail if the universally unique identifier (UUID)
defined in the manifest is not listed in the signing certificate’s usage list extension identified by the
object identifier (OID) (see 5.6.2 for more details). The UUID shall be 128-bit long, in accordance with
ISO/IEC 9834-8.

1.3.6.1.4.1.51528.1.1
57c19de1cbe74605ba74deb773f97042

NOTE Additional extensions that can be defined and specified by the TSO are outside the scope of this
document.
5.5 VDS
5.5.1 General
A VDS is a data structure that may be preceded by ISO/IEC 15459-2 IAC code and is composed of up to
four blocks of data delivered by the data carrier reader to the TEP. The functional structure of a VDS
is given in Figure 1. Received data are organized or reorganized via the mechanisms included in the
manifest resulting in the order shown in Table 4.
NOTE The role of the ISO/IEC 15459-2 IAC prefix is to enable common readers and application programming
interfaces (APIs) to recognize the TSO exploiting the VDS scheme carried by ISO-standardized MRCs including,
but not limited to, RFID, QR-code, data matrix and Han Xin. Since the ISO/IEC 15459-2 IAC prefix is mandatory
in the VDS header, the VDS implementations within URIs and private data carriers can be optimized for VDS-
dedicated readers and APIs. In such a case, there is no need to precede the VDS with the IAC code because once
VDS blocks are decoded, the data can be reorganized by the RFF (via manifest) as data in accordance with
ISO/IEC 15459-2.
Figure 1 — General format of a visible digital seal
Table 4 — Data blocks in VDS structure
Attribute Description
Header
The header provides the information required to decode and verify the VDS.
Payload
The payload contains the data specific to each VDS, whether mandatory or
optional. The size of this block is variable. The header and payload are together
referred to as the “Data”.
Signature
The signature is used to verify the integrity of the two parts mentioned above
(the header and the payload) and to identify/authenticate the issue
...

NORME ISO
INTERNATIONALE 22376
Première édition
2023-08
Sécurité et résilience — Authenticité,
intégrité et confiance pour les
produits et les documents —
Spécifications relatives aux formats
de données et l'utilisation du Cachet
Électronique Visible (CEV) aux fins
d'authentification, de vérification et
d'acquisition des données véhiculées
par un document ou un objet
Security and resilience — Authenticity, integrity and trust for
products and documents — Specification and usage of visible
digital seal (VDS) data format for authentication, verification and
acquisition of data carried by a document or object
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2023
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos .v
Introduction . vi
1 Domaine d'application .1
2 Références normatives .1
3 Termes et définitions . 2
4 Concepts de base . 5
5 Structures et ressources .6
5.1 Généralités . 6
5.2 Liste des services de confiance et extensions . 6
5.2.1 Généralités . 6
5.2.2 Extensions . 6
5.2.3 Identité d'un OSC . 6
5.2.4 Emplacement du manifeste d'un OSC. 7
5.2.5 Référence de l'AC . 7
5.2.6 Répertoire des certificats publics . 7
5.2.7 Sécurité XML . 7
5.2.8 Exemple et vérification . 8
5.3 Manifeste . 8
5.3.1 Généralités . 8
5.3.2 Section Information . 8
5.3.3 Section Schema . 8
5.3.4 Section Extensions. 11
5.3.5 Sécurité XML . 11
5.3.6 Exemple et vérification . 11
5.4 Extensions de manifeste . 11
5.4.1 Généralités . 11
5.4.2 Extension de politiques . 11
5.4.3 Politique d'utilisation autorisée.12
5.5 CEV . 12
5.5.1 Généralités .12
5.5.2 Encodage binaire . 13
5.5.3 Section Header .13
5.5.4 Section Payload . .15
5.5.5 Section Signature . 16
5.5.6 Section Auxiliary Data. 17
5.5.7 Exemple . 17
5.6 Certificat de signature . 17
5.6.1 Généralités . 17
5.6.2 Extensions des listes d'utilisation . 18
6 Processus de production .18
7 Processus de vérification.19
7.1 Concepts de base . 19
7.2 Acquisition des données du CEV . 19
7.3 Analyse de la structure de l'en-tête . 19
7.4 Extraction et vérification des références. 19
7.4.1 Généralités . 19
7.4.2 TSL (Trust Service List) . 19
7.4.3 Manifeste .20
7.4.4 Certificat de signature et liste de révocation des certificats .20
7.5 Traitement du message .20
7.6 Traitement des extensions .20
7.7 Vérification de la signature .20
iii
7.8 Présentation des données des documents . 20
Annexe A (informative) Exemple d'encodage d'un CEV .21
Annexe B (informative) Exemple de TSL .23
Annexe C (informative) Exemple de manifeste .27
Annexe D (informative) Exemple de définition de schéma XML de TSL .29
Annexe E (informative) Exemple de définition de schéma XML d'un manifeste .30
Bibliographie .41
iv
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes
nationaux de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est
en général confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l'ISO participent également aux travaux.
L'ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document
a été rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2
(voir www.iso.org/directives).
L'ISO attire l'attention sur le fait que la mise en application du présent document peut entraîner
l'utilisation d'un ou de plusieurs brevets. L'ISO ne prend pas position quant à la preuve, à la validité et
à l'applicabilité de tout droit de propriété revendiqué à cet égard. À la date de publication du présent
document, l'ISO n'avait pas reçu notification qu'un ou plusieurs brevets pouvaient être nécessaires à sa
mise en application. Toutefois, il y a lieu d'avertir les responsables de la mise en application du présent
document que des informations plus récentes sont susceptibles de figurer dans la base de données de
brevets, disponible à l'adresse www.iso.org/brevets. L'ISO ne saurait être tenue pour responsable de ne
pas avoir identifié tout ou partie de tels droits de brevet.
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l'intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l'Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir www.iso.org/iso/fr/avant-propos.
Le présent document a été élaboré par le comité technique ISO/TC 292, Sécurité et résilience.
Il convient que l'utilisateur adresse tout retour d'information ou toute question concernant le présent
document à l'organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l'adresse www.iso.org/fr/members.html.
v
Introduction
Un cachet électronique visible (CEV) est une représentation d'un ensemble de données structurées, se
présentant souvent sous la forme d'un code lisible par machine, utilisé pour garantir l'authenticité et
l'intégrité de données clés associées à un document ou à un objet. Le CEV a un coût relativement faible
et, grâce à la cryptographie à clé publique, un niveau de sécurité élevé.
Les systèmes basés sur le format du CEV peuvent permettre un suivi et une traçabilité sécurisés,
renforcés et interopérables, associés à une authentification anti-contrefaçon.
La fiabilité des données véhiculées par un CEV dépend de la confiance que l'on peut accorder au
certificat lié à son environnement cryptographique. Le CEV spécifié dans le présent document est l'une
des représentations possibles d'ensembles de données encodées signés électroniquement (ESEDS)
comme, par exemple, un identificateur de ressource uniforme (URI) formaté selon la norme GS1 Digital
Link et protégé par une signature numérique conforme à l'ISO/IEC 20248. La confiance attendue de ce
CEV est fournie par le schéma ESEDS associé.
Le présent document n'interfère pas avec les systèmes d'authentification, de traçabilité et d'identification
existants. Il permet de rendre interopérables des environnements techniquement hétérogènes de suivi,
de traçabilité et de lutte contre la contrefaçon.
Il est possible de configurer un point d'entrée de confiance (PEC), afin de réduire le nombre
d'applications d'identification d'objets en les combinant en un lecteur universel à même de faire face
aussi bien aux cas d'utilisation des inspecteurs professionnels que des consommateurs. Le présent
document s'adresse aux développeurs et aux utilisateurs qui souhaitent mettre en place des systèmes
de suivi, de traçabilité et d'authentification sécurisés et interopérables. Étant donné que la méthode
n'est pas liée à une quelconque technologie, elle peut convenir à tous les secteurs industriels où des
identifiants uniques (UID) ou des données doivent être sécurisés et inspectés dans un environnement
global et multilingue.
vi
NORME INTERNATIONALE ISO 22376:2023(F)
Sécurité et résilience — Authenticité, intégrité et confiance
pour les produits et les documents — Spécifications
relatives aux formats de données et l'utilisation du Cachet
Électronique Visible (CEV) aux fins d'authentification, de
vérification et d'acquisition des données véhiculées par un
document ou un objet
1 Domaine d'application
Le présent document définit les conditions nécessaires au déploiement interopérable de cachets
électroniques visibles (CEV). Il décrit la structure, les formes de représentation possibles ainsi que les
processus de production et de vérification des CEV, pour tout type de document ou d'objet auxquels ils
se rapportent.
Le présent document ne définit pas d'exigences pour les utilisateurs qui émettent ou vérifient des
documents ni pour les utilisateurs qui mettent en œuvre et déploient des CEV.
Le présent document ne s'applique pas aux fonctions de formatage de la réponse (RFF). Ces exigences
et fonctions sont définies par un opérateur de service de confiance (OSC) et visent des fonctionnalités
telles que les niveaux de sécurité des certificats utilisés et les règles de gouvernance à appliquer aux
émetteurs de documents et aux prestataires de services de confiance (PSC) intervenant pendant le
processus de production et de lecture des CEV.
Le présent document ne s'applique pas à la gouvernance liée au fonctionnement du schéma CEV.
Il n'est pas destiné à remplacer les spécifications des documents de l'Agence nationale des titres
sécurisés (ANTS), du Bundesamt für Sicherheit in der Informationstechnik (BSI) et de l'International
Civil Aviation Organization (ICAO).
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu'ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l'édition citée s'applique.
Pour les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).
ISO 3166-1, Codes pour la représentation des noms de pays et de leurs subdivisions — Partie 1: Codes de
pays
ISO 14533-1, Titre manque — Partie 1: Titre manque
ISO 14533-2, Processus, éléments d'informations et documents dans le commerce, l'industrie et
l'administration — Signature à long terme — Partie 2: Profils pour les signatures électroniques avancées
XML (XAdES)
ISO 22300, Sécurité et résilience — Vocabulaire
ISO/IEC 8825-1, Technologies de l'information — Règles de codage ASN.1 — Partie 1: Spécification des
règles de codage de base (BER), des règles de codage canoniques (CER) et des règles de codage distinctives
(DER)
ISO/IEC 9834-1, Technologies de l'information — Procédures opérationnelles pour les organismes
d'enregistrement d'identificateur d'objet — Partie 1: Procédures générales et arcs sommitaux de
l'arborescence des identificateurs d'objet internationale
ISO/IEC 9834-8, Technologies de l'information — Procédures opérationnelles pour les organismes
d'enregistrement d'identificateur d'objet — Partie 8: Génération des identificateurs uniques universels
(UUID) et utilisation de ces identificateurs dans les composants d'identificateurs d'objets
ISO/IEC 15459-2, Technologies de l'information — Identification automatique et techniques de capture de
données — Identification unique — Partie 2: Procédures d'enregistrement
ETSI TS 102 853, Electronic Signatures and Infrastructures (ESI); Signature verification procedures and
policies Technical Specification
ETSI TS 119 612, Electronic Signatures and Infrastructures (ESI); Trusted Lists
IETF RFC 3339, Date and Time on the Internet: Timestamps
IETF RFC 3986, Uniform Resource Identifiers
IETF RFC 4387, Internet X.509 Public Key Infrastructure, Operational Protocols: Certificate Store Access
via HTTP
IETF RFC 4648:2006, The Base16, Base32, and Base64 Data Encodings
IETF RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile
NIST FIPS 180-4, Secure Hash Standard (SHS)
NIST FIPS 186-5, Digital Signature Standard (DSS)
PCRE Perl Compatible Regular Expressions [en ligne]. Disponible à l'adresse: https:// www .pcre .org/
3 Termes et définitions
Pour les besoins du présent document, les termes et les définitions de l'ISO 22300 ainsi que les suivants
s'appliquent.
L'ISO et l'IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l'adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l'adresse https:// www .electropedia .org/
3.1
code lisible par machine
MRC (Machine-Readable Code)
symbole graphique ou dispositif électronique, ou une combinaison des deux, contenant un ensemble de
signes, de caractères, de motifs ou de signaux qui peuvent être interprétés par un système d'acquisition
Note 1 à l'article: Les exemples de MRC comprennent, sans s'y limiter, les codes à barres 2D et les étiquettes
d'identification par radiofréquence (RFID).
3.2
ensemble de données encodées signé électroniquement
ESEDS (Electronically Signed Encoded Data Set)
ensemble de données structurées contenant l'en-tête, le message, la signature et un bloc de données
auxiliaires facultatif
Note 1 à l'article: Le type de données utiles et l'identité de l'émetteur sont inclus dans l'en-tête.
Note 2 à l'article: L'ESEDS peut souvent être exprimé sous forme de code lisible par machine (3.1).
3.3
cachet électronique visible
CEV
ensemble de données structurées, souvent sous forme de code lisible par machine (3.1), contenant un
message et sa signature par l'émetteur
Note 1 à l'article: L'en-tête détermine le type de message et l'émetteur. Un bloc de données auxiliaires facultatif
peut être ajouté après la signature.
Note 2 à l'article: Le CEV spécifié dans le présent document est l'un des différents ensembles de données encodées
signés électroniquement (3.2) possibles.
3.4
cryptographie à clé publique (aussi appelé «cryptographie asymétrique»)
opérations de chiffrement et de déchiffrement exécutées à l'aide d'une paire de clés: une clé privée
utilisée par l'émetteur pour signer les documents (3.10) et une clé publique servant à vérifier la signature
Note 1 à l'article: Les deux clés ayant un rôle «asymétrique», le terme «cryptographie asymétrique» est utilisé
comme synonyme.
3.5
base36
notation pour l'encodage de données arbitraires à l'aide d'un ensemble restreint de symboles composés
de 36 caractères: les chiffres 0 à 9 et lettres A à Z
Note 1 à l'article: Le symbole «Z» a la valeur 35.
3.6
encodage C40
encodage réduisant le nombre d'octets requis pour encoder une chaîne de caractères
Note 1 à l'article: L'encodage C40 est expliqué dans l'ISO/IEC 16022:2006.
3.7
autorité de certification
AC
service offert par un prestataire de services de confiance (3.21) pour créer, émettre et produire des
certificats (3.11) au nom des utilisateurs et confirmer l'intégrité de l'identification électronique des
signataires
Note 1 à l'article: L'AC signe le certificat (avec sa propre clé privée) pour garantir l'intégrité du certificat et
l'exactitude des données contenues dans chaque certificat qu'elle émet.
3.8
liste de révocation des certificats
CRL (Certificate Revocation List)
liste de certificats (3.11) qui ont été révoqués par l'autorité de certification (3.7) émettrice
Note 1 à l'article: La CRL doit être conforme à l'IETF RFC 5280.
3.9
algorithme de signature numérique
DSA (Digital Signature Algorithm)
technique mathématique utilisée pour valider l'authenticité et l'intégrité d'un message, d'un logiciel ou
d'un document numérique
Note 1 à l'article: Les DSA comprennent, sans s'y limiter, les algorithmes RSA et ECDSA définis dans la norme
NIST FIPS 186-4.
3.10
document
information et support sur lequel cette information est contenue
Note 1 à l'article: Le support peut être du papier ou un autre type de substrat, un disque électronique ou optique,
un support magnétique, une photographie, un échantillon maître ou une combinaison de ces supports.
3.11
certificat
certificat électronique
Certificat X .509
fichier électronique attestant qu'une paire de clés cryptographiques appartient à la personne physique
ou morale, ou au composant matériel ou logiciel identifié dans le certificat
Note 1 à l'article: Les certificats sont émis par l'autorité de certification (AC) (3.7). En signant un certificat, l'AC
certifie l'association entre la paire de clés et la personne ou le composant matériel ou logiciel. Un certificat peut
être révoqué si cette relation ne peut plus être établie. Un certificat a une durée de validité déterminée.
3.12
hachage (aussi appelé «condensat»)
application d'une fonction mathématique pour créer une empreinte numérique sur un bloc de données.
Ce dernier est ainsi transformé en code de format fixe aux fins d'authentification et de stockage
Note 1 à l'article: Toute modification du bloc de données initial entraîne une modification de la valeur de hachage.
3.13
manifeste
ressource externe contenant des informations au format XML (langage de balisage extensible) sur le
cas d'utilisation du cachet électronique visible (3.3), son schéma (3.18), ses politiques de validation et ses
extensions facultatives
3.14
message pack
format d'échange de données binaires utilisé pour représenter des structures de données simples et
des tableaux
Note 1 à l'article: Le format message pack se veut le plus simple et compact possible. Il est défini à la Référence [10].
3.15
protocole OCSP
OCSP
protocole de vérification de certificat (3.11) en ligne utilisé pour valider l'état d'un certificat,
habituellement pour déterminer si le certificat a été révoqué
Note 1 à l'article: Le protocole OCSP est expliqué dans la norme IETF RFC 6960.
Note 2 à l'article: Le protocole OCSP est une solution de remplacement à l'utilisation d'une liste de révocation des
certificats (3.8).
3.16
expression rationnelle (aussi appelée «expression régulière»)
chaîne de caractères décrivant, à l'aide d'une syntaxe spécifique, un ensemble de chaînes ou de
caractères admissibles
Note 1 à l'article: L'expression rationnelle doit être conforme à la spécification PCRE (Perl-Compatible Regular
Expression).
3.17
fonction de formatage de la réponse
RFF (Response Formatting Function)
fonction précisant comment formater et présenter les résultats de vérification du cachet électronique
visible (3.3)
3.18
schéma
structure de données du message permettant l'encodage, le décodage et la vérification des données
3.19
symbologie
décrit l'encodage des données numériques, texte ou binaires dans un code lisible par machine (3.1)
définissant les mécanismes de redondance et de code de correction d'erreurs et spécifiant la zone
blanche autour du code-barres
3.20
opérateur de service de confiance
OSC
entité définissant la structure de gouvernance et les exigences techniques du service de confiance, et
qui assure la supervision de l'ensemble des opérations
Note 1 à l'article: Dans certains secteurs d'activité, l'OSC est également l'organisme d'authentification (ASB,
Authentication Service Body).
3.21
prestataire de services de confiance
PSC
entité ayant la responsabilité de définir le cadre de confiance et la structure de gouvernance de l'autorité
de certification (AC) (3.7), d'offrir des services de certificats, d'exploiter l'AC et de veiller à la conformité
à ladite gouvernance
3.22
point d'entrée de confiance
PEC
méthode fournie et/ou certifiée par l'opérateur de service de confiance (3.20) prenant en charge la
fonction de formatage de la réponse (3.17), ouverte à des systèmes d'identification et d'authentification
d'objets (OIAS) supplémentaires, et capable de résoudre sans ambiguïté tout identifiant unique (UID)
3.23
liste des services de confiance
TSL (Trust Service List)
liste contenant des informations conformes sur l'opérateur de service de confiance (OSC) (3.20), les
prestataires de services de confiance (PSC) (3.21) et l'autorité de certification (3.7) du PSC autorisée à
émettre des certificats (3.11) pour signer les ensembles de données encodées signés électroniquement
(3.2)
Note 1 à l'article: L'ETSI TS 119 612 définit ce qu'est une TSL conforme.
Note 2 à l'article: Les TSL sont extensibles grâce au langage de balisage extensible (XML) défini par l'OSC.
3.24
identificateur de ressource uniforme
URI
chaîne de caractères qui identifie une ressource sans ambiguïté
Note 1 à l'article: La syntaxe doit se conformer à l'IETF RFC 3986.
4 Concepts de base
Un CEV est habituellement représenté sous forme d'un ou de plusieurs MRC. Il contient des données à
protéger et la signature électronique de ces données, apposée par l'émetteur du document. Les CEV sont
lus à l'aide d'un dispositif électronique ou optoélectronique, par exemple, un scanneur ou un lecteur de
codes-barres 2D, un lecteur RFID ou une combinaison de ces dispositifs.
La mise en œuvre détaillée d'un CEV donné est toujours régie par un cas d'utilisation spécifique.
Défini par un groupe d'experts, chaque cas d'utilisation détermine les champs de données clés devant
être inclus dans le schéma, ainsi que les contraintes de chaque champ. Au besoin, le cas d'utilisation
peut inclure des politiques de vérification supplémentaires et des fonctionnalités définies dans les
extensions de l'OSC afin de respecter les règles d'affaires du cas d'utilisation. Le cas d'utilisation est
ensuite traduit en format lisible par machine (fichier manifeste en format XML sécurisé) afin que le
CEV puisse être interprété et traité de manière normalisée et déterministe par la personne morale ou
physique qui l'a produit et par celles devant le vérifier, conformément aux règles prescrites dans chaque
cas d'utilisation. Le manifeste peut être étendu à l'aide d'extensions XML définies par l'OSC dans le but
de permettre un plus grand ensemble de fonctionnalités, telles que des politiques de vérification de CEV
supplémentaires (par exemple, symbologies autorisées, légitimité des signataires, période de validité),
l'utilisation d'une RFF et des règles d'affaires post-vérification.
De nombreuses actions ont été mises en place pour réduire au minimum l'espace utilisé par le support
de données et maximiser l'espace utilisable par les données. Ainsi, le CEV ne contient pas le certificat
utilisé pour la signature ni la définition du cas d'utilisation; il contient, en revanche, des identifiants
qui permettent d'accéder à ces éléments (voir 5.3.2). De plus, le message et la signature du CEV sont
structurés de manière à ce que leur taille soit réduite.
Pour assurer la fiabilité du service, la vérification des différents éléments du CEV et de la chaîne de
confiance est essentielle. Ainsi, la vérification est un composant normatif de cette spécification
technique (voir Article 7). Chaque élément requis par le CEV est protégé et signé par l'OSC pour en
assurer la fiabilité.
Afin de différencier sans ambiguïté les nombres hexadécimaux des autres nombres, la notation préfixée
«0x» est utilisée dans le présent document.
5 Structures et ressources
5.1 Généralités
Tous les URI et points d'accès doivent être en minuscules.
5.2 Liste des services de confiance et extensions
5.2.1 Généralités
La TSL doit être conforme à l'ETSI TS 119 612, à l'exception du champ qui est
facultatif. La TSL doit inclure les informations relatives à l'OSC et à l'autorité de certification (AC) du
PSC autorisé afin de permettre l'exploitation des services de confiance.
5.2.2 Extensions
L'exploitation d'un service de confiance d'un CEV exige l'ajout des trois attributs suivants non définis
dans l'ETSI TS 119 612:
— une adresse URI pour localiser les manifestes;
— une référence d'AC pour chaque service d'un PSC;
— une adresse URI pour localiser les certificats de signature de chaque AC.
Ces attributs doivent être définis par des extensions.
5.2.3 Identité d'un OSC
L'OSC doit être identifié conformément à l'ISO/IEC 15459-2 par le code de l'agence émettrice (IAC,
Issuing Agency Code). Ce code IAC doit être utilisé pour localiser la TSL.
5.2.4 Emplacement du manifeste d'un OSC
L'en-tête du CEV comprend une référence au manifeste. Pour qu'il soit possible de localiser le manifeste,
la TSL doit comprendre une adresse URI pointant vers le répertoire de manifestes.
L'URI du répertoire de manifestes est définie par l'attribut d'extension dans
les extensions de schéma de la TSL utilisant le XPath suivant:
/TrustServiceStatusList/SchemeInformation/SchemeExtensions/Extension/
vdsext:VDSManifestResource
L'URI du manifeste est une concaténation de l'URI du répertoire des manifestes et de l'ID du manifeste
(au format hexadécimal, toujours en lettres minuscules). Voici un exemple permettant de récupérer le
manifeste 0x89AB01 avec la valeur d'extension :
“https://manifest.otentik.codes”:
https://manifest.otentik.codes/89ab01.xml

5.2.5 Référence de l'AC
La référence de l'AC est une chaîne de quatre caractères faisant partie de l'en-tête du CEV et permettant
de localiser le certificat de signature et d'assurer la validité de l'AC dans la TSL. Elle est composée des
éléments suivants:
— pays émetteur de l'AC (ISO 3166-1 Alpha2), en lettres majuscules;
— identifiant de l'AC: deux chiffres attribués par l'OSC.
La référence de l'AC est définie par l'attribut d'extension dans les extensions
d'information sur le service de la TSL utilisant le XPath suivant:
/TrustServiceStatusList/TrustServiceProviderList/TrustServiceProvider/TSPInformation/
ServiceInformationExtensions/Extension/vdsext:VDSAuthorityID

5.2.6 Répertoire des certificats publics
L'en-tête du CEV comprend une référence au certificat de signature. Pour qu'il soit possible de localiser
le certificat, la TSL doit comprendre une adresse URI vers le répertoire de certificats propre à chaque
AC. Il convient que l'identifiant d'AC du PSC soit présent dans l'URI.
Le point d'accès du certificat est défini par l'attribut dans les extensions
d'information sur le service de la TSL utilisant la syntaxe suivante:
/TrustServiceStatusList/TrustServiceProviderList/TrustServiceProvider/
TSPServices/TSPService/ServiceInformation/ServiceInformationExtensions/Extension/
vdsext:VDSCertResource
L'URI du certificat est une concaténation du point d'accès du certificat et du numéro de référence du
certificat (en format Base36). Le format de l'URI doit se conformer à l'IETF RFC 4387. Voici un exemple
permettant d'extraire le certificat «09HZ» émis par l'AC à qui il a été attribué l'identifiant «FR01» et
l'attribut sous “https://trust.otentik.codes/fr01”:
https://trust.otentik.codes/fr01/09hz.cer

5.2.7 Sécurité XML
Pour que son intégrité soit garantie, la TSL doit être signée électroniquement par l'OSC au format CAdES
conformément à l'ISO 14533-1 ou au format XAdES-B conformément à l'ISO 14533-2. L'OSC peut détailler
les paramètres et caractéristiques requis de la signature.
5.2.8 Exemple et vérification
Voir l'Annexe B pour un exemple de TSL.
Pour faciliter la validation XML automatisée, la TSL doit inclure une directive xsi: schemaLocation (voir
l'exemple fourni à l'Annexe D).
5.3 Manifeste
5.3.1 Généralités
Le manifeste est une définition d'un cas d'utilisation lisible par machine. Il contient diverses sections:
information sur le cas d'utilisation, schéma de données et extensions facultatives (définies par l'OSC).
L'en-tête du CEV comprend une référence à un manifeste. Le numéro de référence doit être attribué par
l'OSC.
5.3.2 Section Information
Cette section associe l'identifiant de manifeste lisible par machine au nom et à la description du cas
d'utilisation lisible par des personnes. Une liste des attributs avec leur description est donnée dans
le Tableau 1.
Tableau 1 — Attributs de la section Information
Attribut Description
Id
Identifiant du cas d'utilisation (6 caractères hexadécimaux).
Correspond au champ ID du manifeste de l'en-tête du CEV.
Version
Version du cas d'utilisation (à titre informatif uniquement). Permet des modi-
fications rétrocompatibles dans le schéma de données, telles que des change-
ments dans le nom ou la description du cas d'utilisation ou des modifications
rétrocompatibles des extensions.
Name
Nom du cas d'utilisation. Multilingue.
Description
Description du cas d'utilisation. Multilingue.
Un exemple de section Information est donné ci-dessous:

codes/ https://otentik.codes/schemas/otentik-baseline-manifest-v1.xsd”>
89AB01
1

Use Case Name
Nom du cas d’usage


Use case description
Description du cas d’usage

...

5.3.3 Section Schema
Cette section définit, pour un cas d'utilisation en particulier, la structure de l'information dans les
sections Payload et Auxiliary Data du CEV, ainsi que les règles de validation de ces champs. Le schéma
est utilisé autant pour la production que pour la vérification du CEV.
Le format d'encodage par défaut pour Payload et AuxData est MessagePack. Il est permis que l'OSC
prenne en charge d'autres formats d'encodage. Lorsque le format d'encodage MessagePack est utilisé,
l'ordre des données du message et des données auxiliaires du CEV doit être identique à l'ordre prescrit
dans la définition du schéma du manifeste. Une liste des attributs avec leur description est donnée dans
le Tableau 2.
Tableau 2 — Attributs de la section Schema
Attribut Description
Payload
Définit les structures de données, facultatives ou obligatoires, qui seront signées. L'encodage des
paramètres facultatifs est utilisé pour les formats autres que MessagePack (CBOR, JSON, TLV ou
autre), par exemple, ).
AuxData
Définit les structures de données qui ne doivent pas être signées. Cette section est facultative et
utilise la même structure XML et les mêmes principes d'encodage que le message.
Types
Définit les types de champs personnalisés auxquels les objets et tableaux d'objets renvoient.
Le schéma peut définir des types de données et des contraintes, comme les longueurs minimales/
maximales et les caractères autorisés, ou des valeurs bornées. Le schéma accepte les champs de données
standard ainsi que les objets et les tableaux de données.
Lorsqu'un OSC autorise une structure de données spécifique, il doit inclure la possibilité de décoder
cette structure de données dans l'application de lecture du PEC.
Un exemple de section Schema est donné ci-dessous:







[A-Z0-9]
C40





1
9999















[A-Za-z]





2000-01-01






Voir l'Annexe C pour plus d'exemples détaillés.
Le manifeste utilise des types de champs standard ainsi que des objets, des tableaux et des chaînes de
caractères encodées en C40 (voir Tableau 3).
NOTE L'encodage de chaîne réduit généralement la taille des données des chaînes encodées (bien que ne
comportant qu'un ensemble réduit de caractères) et s'applique à toute symbologie.
Tableau 3 — Paramètres du schéma et contraintes connexes
Paramètres
Contraintes facultatives du paramètre
du schéma
Integer

Nillable: champ facultatif
Min: valeur minimale de l'entier
Max: valeur maximale de l'entier
Boolean

Nillable: champ facultatif
Float

Nillable: champ facultatif
Min: valeur minimale du flottant
Max: valeur maximale du flottant
String

Nillable: champ facultatif
MinLength: nombre minimal de caractères
MaxLength: nombre maximal de caractères
Pattern: expression rationnelle conforme à la spécification
PCRE (Perl Compatible Regular Expressions) définissant les carac-
tères acceptés dans la chaîne de caractères
Encoding: autre type d'encodage si l'encodage UTF-8 par défaut ne
convient pas. Seule la valeur C40 est acceptée.
Binary

Nillable: champ facultatif
MinLength: nombre minimal d'octets
MaxLength: nombre maximal d'octets
Timestamp

Nillable: champ facultatif
Date
Encode le nombre de jours (positif ou négatif) entre une date et une
date de référence.

Nillable: champ facultatif
From: date de référence au format AAAA-MM-JJ. La date de référence
par défaut est 1900-01-01
NotBefore: date de validité minimale
NotAfter: date de validité maximale
TTaabblleeaau 3 u 3 ((ssuuiitte)e)
Paramètres
Contraintes facultatives du paramètre
du schéma
Object

Nillable
...