Guides

Glossaire des termes de provenance des images

Chaque terme et acronyme qui apparaît dans un rapport AuditImage ou dans ces guides, de APP1 à XMP, épelé et expliqué en quelques phrases chacun.

Un rapport de ce site nomme beaucoup de choses : segments, blocs, manifestes, assertions, ancres de confiance. Cette page définit chacune d'entre elles une fois, regroupées par endroit où vous les rencontrez. Les termes sont en gras, et chaque acronyme est suivi de son orthographe complète entre parenthèses la première fois qu'il apparaît. Les guides liés en fin de section approfondissent chaque point.

Le verdict et le rapport

  • Provenance — D'où vient une photo et ce qui lui est arrivé depuis : capturée par un appareil photo, générée par un modèle, éditée par un programme, ou une chaîne de ces opérations. Tout ce que fait ce site tente de lire la provenance directement dans le fichier.
  • Verdict — La conclusion en une ligne en haut d'un rapport. Il est choisi par priorité : un Content Credential valide ou invalide prime sur une auto-déclaration dans les métadonnées, qui prime sur une incohérence, qui prime sur un bloc EXIF d'appareil photo simple, qui prime sur des métadonnées ne disant rien sur l'origine.
  • Observation — Un constat avec un niveau (info, notification, avertissement). Un rapport est un verdict plus ses observations ; le verdict est dérivé des observations, jamais l'inverse.
  • Signal IA — Un constat d'un type spécifique : un champ, un bloc de texte ou un manifeste indiquant que l'image a été générée par un modèle. Le rapport nomme à la fois le signal et l'emplacement exact d'où il a été lu, comme XMP DigitalSourceType ou PNG tEXt "parameters".
  • Auto-déclaré — Ce que le fichier dit de lui-même dans des métadonnées simples, non signées. N'importe quel programme peut l'écrire ou l'effacer, une auto-déclaration est donc la preuve de ce qu'un outil a écrit, non de ce qui s'est passé.
  • Déclaré dans les Content Credentials — Dit à l'intérieur d'un manifeste C2PA signé. Si la signature est vérifiée et le signataire de confiance, l'affirmation n'a pas pu être modifiée depuis la signature.
  • Incohérent — Le verdict lorsque les parties des métadonnées se contredisent, ce qui est l'empreinte d'un fichier qui a été nettoyé puis ré-étiqueté manuellement. Voir les observations sur EXIF versus XMP ci-dessous.
  • Nettoyé — Métadonnées supprimées. La plupart des plateformes sociales et des applications de messagerie le font lors de l'upload ; les outils « supprimer l'EXIF » également. Un fichier nettoyé ne peut pas être jugé sur la base de ses métadonnées.
  • Ré-étiqueté — Métadonnées écrites sur un fichier après la suppression de ses métadonnées originales, pour lui faire dire ce qu'il n'est pas. Généralement détecté comme une incohérence.
  • Carte des segments — Le tableau en bas d'un rapport JPEG, PNG ou WebP listant chaque bloc du fichier dans l'ordre, avec son décalage et sa longueur. Les blocs portant des informations de provenance sont marqués.
  • SHA-256 (Secure Hash Algorithm, 256 bits) — Un hachage cryptographique : une empreinte de taille fixe des octets du fichier. Le rapport l'affiche pour que deux personnes puissent confirmer qu'elles regardent le même fichier. La modification d'un seul octet modifie tout le hachage.

Conteneurs : la disposition des octets

  • Conteneur — Le format de fichier qui enveloppe les données de l'image et ses métadonnées : JPEG, PNG, WebP, etc. Chacun a sa propre façon de contenir les métadonnées, c'est pourquoi le même bloc EXIF se trouve dans un « segment APP1 » dans un JPEG et un « bloc eXIf » dans un PNG.
  • JPEG (Joint Photographic Experts Group) — Le format photo le plus courant, nommé d'après le comité qui l'a défini. Un JPEG est une séquence de segments, chacun introduit par un marqueur de deux octets.
  • SOI / EOI (Start Of Image / End Of Image) — Les premier et dernier marqueurs d'un JPEG. Les données après EOI sont ignorées par les visionneuses et constituent un endroit classique de dissimulation.
  • Segment APPn (segment application n) — APP0 à APP15, où vivent les métadonnées JPEG. Quel standard utilise quel numéro est une convention, non imposée par le format.
  • APP0 JFIF (JPEG File Interchange Format) — L'en-tête JPEG basique : version, densité de pixels, parfois une miniature. Presque tous les JPEG en ont un. Ne porte pas de provenance.
  • APP1 EXIF (Exchangeable Image File Format) — Le segment qui contient l'EXIF (voir ci-dessous). Les appareils photo et les téléphones l'écrivent.
  • APP1 XMP (Extensible Metadata Platform) — Le segment qui contient XMP. Un grand paquet XMP déborde dans des segments APP1 XMP ext (XMP étendu) qui doivent être réassemblés.
  • APP2 ICC (International Color Consortium) — Le profil couleur, réparti sur plusieurs segments APP2 s'il est grand. Indique comment interpréter les valeurs de couleur, rien sur l'origine.
  • APP2 MPF (Multi-Picture Format) — Un index d'images supplémentaires embarquées dans le même fichier, typiquement un aperçu agrandi ou une carte de profondeur d'un téléphone. Les métadonnées de certains téléphones se trouvent ici.
  • APP11 (JPEG XT) — Le numéro de segment utilisé par JPEG XT (JPEG eXTensions, la famille ISO/IEC 18477 ; IEC est la Commission électrotechnique internationale, partenaire d'ISO pour les normes conjointes) pour les données en boîte. C2PA l'utilise aussi, donc APP11 C2PA est l'étiquette des segments APP11 dont le contenu est une boîte C2PA JUMBF, potentiellement répartie sur plusieurs segments et réassemblée par numéro de séquence.
  • APP13 Photoshop IRB (Image Resource Block) / IPTC (International Press Telecommunications Council) — Les blocs ressources de Photoshop. Historiquement où étaient stockés les champs de légende et de copyright IPTC ; Photoshop les écrit toujours.
  • APP14 Adobe — Un petit segment que les encodeurs Adobe écrivent pour décrire la transformation de couleur. Sa présence indique que le fichier est passé par une bibliothèque Adobe à un moment donné.
  • COM (commentaire) — Un segment de commentaire en texte libre. Certains générateurs y écrivent leurs paramètres.
  • Scan data — Les pixels compressés eux-mêmes, tout depuis le premier marqueur SOS (Start Of Scan) jusqu'à EOI.
  • PNG (Portable Network Graphics) — Un format sans perte composé de blocs : un type de quatre lettres, une longueur, les données, et un checksum CRC (vérification par redondance cyclique). Les noms de blocs avec une première lettre minuscule sont optionnels et peuvent être omis par tout outil qui ne les comprend pas.
  • Signature PNG — Les huit octets fixes avec lesquels commence chaque PNG.
  • IHDR / IDAT / IEND (en-tête image / données image / fin image) — Les blocs obligatoires : en-tête (dimensions, profondeur de bits), données image, et fin de fichier.
  • tEXt / iTXt / zTXt — Blocs de texte PNG : un mot-clé plus une valeur. tEXt est en Latin-1 (ISO 8859-1), iTXt est du texte international en UTF-8 (Unicode Transformation Format, 8 bits) et peut être compressé, zTXt est du Latin-1 compressé par zlib. C'est là que Stable Diffusion, ComfyUI et NovelAI écrivent leurs paramètres de génération, et c'est généralement là que se trouve l'étiquette AIGC dans un PNG.
  • eXIf — Le bloc PNG standardisé en 2017 pour porter un bloc EXIF. Les outils plus anciens mettaient l'EXIF dans un bloc de texte à la place.
  • iCCP (profil ICC) — Le bloc PNG pour un profil couleur ICC.
  • caBX — Le type de bloc de quatre lettres que la spécification C2PA a enregistré pour porter une boîte JUMBF dans un PNG. C'est un nom de bloc, pas un acronyme avec une signification officielle. caBX C2PA dans un rapport signifie que le bloc a été trouvé et analysé comme un magasin de manifestes.
  • WebP — Le format d'image de Google, dérivé du codec vidéo VP8. Un WebP est un fichier RIFF (Resource Interchange File Format) : un en-tête et une séquence de blocs avec des noms de quatre lettres. VP8 et VP8L (VP8 sans perte) contiennent les données de l'image ; VP8X (VP8 étendu) est l'en-tête qui indique quels blocs optionnels suivent. Les blocs EXIF, XMP et ICCP (profil ICC) portent ces données ; le bloc C2PA porte une boîte JUMBF.
  • HEIC / AVIF / TIFF / GIF — Formats dont ce site lit l'EXIF et le XMP mais ne cartographie pas segment par segment. HEIC (High Efficiency Image Container) et AVIF (AV1 Image File Format ; AV1 est AOMedia Video 1, le codec qu'il stocke) sont des conteneurs au format de fichier média de base ISO, la même famille que MP4 (MPEG-4 Part 14 ; MPEG est le Moving Picture Experts Group). TIFF (Tagged Image File Format) est le format sur lequel l'EXIF lui-même est modélisé. GIF (Graphics Interchange Format) ne contient pratiquement pas de métadonnées.

En savoir plus : Où vivent les métadonnées dans un fichier, Pourquoi les métadonnées disparaissent.

Standards de métadonnées

  • Métadonnées — Données sur l'image stockées à côté des pixels : quand elle a été prise, par quel appareil, avec quels paramètres, par quel logiciel elle a été enregistrée en dernier. Aucune de ces données n'est nécessaire pour afficher l'image, c'est pourquoi elle peut être supprimée sans changement visible.
  • EXIF (Exchangeable Image File Format) — Le standard que les appareils photo et téléphones utilisent pour enregistrer les détails de capture : Make et Model, exposition, objectif, DateTimeOriginal, orientation, GPS, et Software (le dernier logiciel ayant enregistré le fichier). C'est une structure binaire empruntée à TIFF. Les éditeurs le préservent, le réécrivent ou l'ignorent. Rien dans l'EXIF n'est signé.
  • DateTimeOriginal — L'horodatage de capture EXIF, en heure locale sans fuseau. Comparé à la date de création XMP pour détecter une incohérence.
  • Software — La balise EXIF nommant le logiciel ayant dernier enregistré le fichier. Un nom de générateur ici est un signal IA ; un nom d'éditeur est juste un éditeur.
  • XMP (Extensible Metadata Platform) — Le standard de métadonnées d'Adobe, écrit en XML (Extensible Markup Language) et désormais standard ISO (International Organization for Standardization), ISO 16684. Il stocke les mêmes faits que l'EXIF ainsi que les informations d'édition : CreatorTool (le logiciel), CreateDate et ModifyDate, et l'historique des modifications. Texte, non signé, et réécrit par chaque produit Adobe lors de l'enregistrement.
  • CreatorTool — Le champ XMP nommant le logiciel qui a créé le fichier. Comparé au Software EXIF ; les deux sont généralement cohérents pour un fichier avec un historique honnête.
  • Historique XMP — xmpMM:History (MM pour Media Management), une liste d'événements d'édition, chacun avec un agent logiciel, une action et une heure. Un fichier qui affirme dériver d'un autre (DerivedFrom) mais n'a pas d'historique est suspect.
  • DerivedFrom — Le champ XMP pointant vers le document à partir duquel celui-ci a été fait. Présent sur une exportation éditée ; sans signification sur un original d'appareil photo.
  • Document ID / Instance ID (identifiant) — Identifiants XMP que les produits Adobe attribuent à un document et à chaque version enregistrée. Ils permettent aux entrées d'historique d'être liées à des enregistrements spécifiques.
  • IPTC (International Press Telecommunications Council) — Le schéma de métadonnées de l'industrie de la presse pour les photos : légende, crédit, copyright, et depuis 2023 le champ DigitalSourceType.
  • DigitalSourceType — Un champ IPTC, stocké dans XMP, qui indique comment l'image a été produite. La valeur trainedAlgorithmicMedia signifie « créée par un modèle IA entraîné ». Adobe Firefly, DALL·E et plusieurs autres l'écrivent. C'est le plus proche d'un drapeau IA standard de l'industrie dans les métadonnées simples, et ce n'est toujours que du texte.
  • Profil ICC (International Color Consortium) — Un profil couleur. Indique aux logiciels comment convertir les valeurs de couleur du fichier pour l'affichage. Ne dit rien sur l'origine, bien que la description du profil puisse nommer le logiciel qui l'a intégré.
  • GPS (Global Positioning System) — Champs de localisation dans l'EXIF. Signalé comme constat car une photo partagée a rarement besoin de les porter.

En savoir plus : Bases de l'EXIF, XMP et historique des modifications, Comment les métadonnées sont falsifiées.

C2PA et Content Credentials

  • C2PA (Coalition for Content Provenance and Authenticity) — Un organisme industriel (Adobe, Microsoft, Google, Sony, Nikon, Leica, OpenAI et autres) et le nom de la spécification technique ouverte qu'il publie pour les données de provenance signées.
  • CAI (Content Authenticity Initiative) — La communauté dirigée par Adobe qui promeut l'adoption de C2PA et gère le site public de vérification.
  • Content Credentials — Le nom grand public pour les données C2PA attachées à un fichier. Lorsqu'un rapport indique « Contient des Content Credentials », cela signifie qu'un magasin de manifestes C2PA a été trouvé.
  • Manifeste — Un enregistrement signé de provenance : qui a fait cette version, avec quel outil, quelles actions ont été effectuées, de quoi elle dérive. Un fichier édité plusieurs fois par des outils compatibles C2PA porte plusieurs manifestes.
  • Magasin de manifestes — Le conteneur contenant tous les manifestes d'un fichier. Physiquement, c'est une boîte JUMBF dans APP11, caBX ou le bloc C2PA de WebP.
  • Manifeste actif — Le manifeste le plus récent, celui qui décrit le fichier tel qu'il est actuellement. Seule sa liaison dure est censée correspondre aux octets actuels ; les manifestes précédents sont couverts en tant qu'ingrédients des suivants.
  • Revendication — Le cœur d'un manifeste : une structure CBOR listant les assertions par hachage, le générateur de revendication et une référence à la signature. La signature est calculée sur les octets de la revendication.
  • Générateur de revendication — Le logiciel qui a produit le manifeste, nommé dans la revendication. Signalé comme l'outil.
  • Assertion — Une affirmation dans un manifeste. Les standardisées incluent c2pa.actions (ce qui a été fait), c2pa.hash.data (la liaison dure), c2pa.ingredient (de quoi cela a été fait), et stds.schema-org.CreativeWork (auteur et copyright).
  • Action — Une entrée dans l'assertion d'actions : c2pa.created, c2pa.edited, c2pa.opened, c2pa.placed, etc. Une action de création avec un type de source numérique de trainedAlgorithmicMedia est la façon dont un manifeste déclare une génération IA ; digitalCapture déclare une capture par appareil photo.
  • Ingrédient — Une assertion enregistrant un autre actif qui est entré dans celui-ci, avec son propre hachage de manifeste lorsqu'il en avait un. Les ingrédients sont la façon dont une chaîne d'édition reste vérifiable.
  • JUMBF (JPEG Universal Metadata Box Format) — Le conteneur binaire structuré en boîtes que C2PA utilise, défini dans ISO/IEC 19566-5. Les boîtes s'emboîtent : une super-boîte contient une boîte de description (jumd) et des boîtes de contenu telles que cbor, json ou bidb (boîte de données binaires).
  • CBOR (Concise Binary Object Representation) — Un codage binaire compact de données de type JSON, défini dans la RFC 8949. Les revendications et la plupart des assertions sont en CBOR.
  • JSON (JavaScript Object Notation) — Le format de données en texte brut dont CBOR est le cousin binaire. Certaines assertions, et l'étiquette AIGC, sont en JSON.
  • COSE (CBOR Object Signing and Encryption) / COSE_Sign1 — Le format de signature construit sur CBOR, défini dans la RFC 9052. COSE_Sign1 est la structure de signature à signataire unique que C2PA utilise : en-têtes protégés (algorithme, chaîne de certificats), la charge utile (la revendication), et les octets de signature.
  • Certificat X.509 — Le format standard pour un certificat de clé publique, nommé d'après la recommandation ITU-T (Union internationale des télécommunications, Secteur de normalisation des télécommunications) qui le définit : une clé publique, le nom de son propriétaire, le nom de l'autorité de certification qui le garantit, les dates de validité, et la signature de l'autorité. Le certificat de signature voyage à l'intérieur de l'en-tête COSE sous le nom x5chain (chaîne X.509).
  • Chaîne de certificats — Le certificat de feuille signant, l'intermédiaire qui l'a émis, et ainsi de suite jusqu'à une racine. Chaque maillon est vérifié en vérifiant la signature d'un certificat avec la clé du suivant.
  • Ancre de confiance — Un certificat que le vérificateur décide de faire confiance sans preuve supplémentaire. Si la chaîne en atteint un, l'identité du signataire est considérée comme établie.
  • Liste de confiance — L'ensemble des ancres de confiance. C2PA publie une liste officielle des autorités de certification et des signataires qu'il a examinés. « Signature valide, signataire inconnu » signifie que les calculs mathématiques sont corrects mais que la chaîne n'a rien atteint dans la liste, ce qui est le cas d'un certificat auto-signé.
  • Signature valide — La signature COSE sur la revendication est vérifiée avec la clé du certificat de feuille. Prouve que le manifeste n'a pas été altéré après la signature. Cela ne prouve pas en soi qui a signé.
  • Liaison dure — Le hachage dans c2pa.hash.data, calculé sur le fichier en excluant le magasin de manifestes lui-même. S'il correspond, les pixels n'ont pas été modifiés après la signature et ce manifeste appartient à ce fichier. Si l'image a été réencodée ou éditée par un outil sans support C2PA, cette vérification échoue.
  • Liaison souple — Une liaison qui survit au réencodage, comme un filigrane invisible ou une empreinte perceptuelle, utilisée pour rechercher un manifeste lorsqu'il a été retiré du fichier. Ce site n'évalue pas les liaisons souples.
  • Hachages des assertions — Chaque assertion est hachée et la revendication liste les hachages. Les vérifier prouve qu'aucune assertion n'a été substituée sous une revendication valide.
  • Horodatage (sigTst, horodatage de signature) — Un jeton optionnel RFC 3161 (Request for Comments 3161, le standard Internet pour les horodatages de confiance) d'une autorité d'horodatage, prouvant que la signature existait à un moment donné. Signalé comme présent ou absent ; non vérifié dans cette version.
  • Échec de vérification / Vérification partielle — « Échec » signifie que l'une des quatre vérifications (signature, liaison dure, hachages des assertions, chaîne) a échoué. « Vérification partielle » signifie qu'une vérification n'a pas pu être terminée, par exemple parce qu'un algorithme de hachage n'est pas pris en charge, et le rapport indique lequel.
  • Site de vérification — verify.contentauthenticity.org, le vérificateur public du CAI. Un deuxième avis utile, car il applique la même liste de confiance que ce site.

En savoir plus : Qu'est-ce que C2PA, Comment vérifier C2PA.

Traces laissées par les générateurs IA

  • Paramètres de génération — Le prompt, le modèle, la graine, l'échantillonneur et les paramètres qu'un générateur a utilisés, écrits dans le fichier par les outils qui veulent que l'image soit reproductible. Leur présence est un fort signal IA ; leur absence ne prouve rien.
  • Stable Diffusion (SD) — La famille open-source de modèles d'images. Ses interfaces les plus courantes écrivent les paramètres dans le texte PNG. SDXL est Stable Diffusion XL, le modèle plus grand de 2023.
  • Stable Diffusion WebUI (AUTOMATIC1111, A1111) — L'interface web classique, nommée d'après le pseudonyme de son auteur ; A1111 est la forme abrégée. Écrit un bloc de texte parameters : le prompt, puis une ligne Negative prompt:, puis Steps: ..., Sampler: ..., Model: .... Le rapport extrait le nom du modèle lorsqu'il est présent.
  • ComfyUI (Comfy User Interface) — Une interface à graphe de nœuds. Écrit deux blocs de texte : prompt (le graphe en JSON) et workflow (la mise en page de l'éditeur).
  • NovelAI — Un générateur hébergé orienté anime. Écrit Software: NovelAI plus un bloc Comment avec des paramètres JSON, et souvent les mots « Stable Diffusion » dans la description.
  • Midjourney — Un générateur hébergé. Les téléchargements portent XMP avec le prompt dans la description et un Job ID (un UUID, identifiant universel unique) dans un champ spécifique à Midjourney ; aussi un champ Creator nommant l'utilisateur.
  • DALL·E / OpenAI — Les modèles d'images d'OpenAI ; le nom est un mélange de l'artiste Dalí et du robot WALL·E, pas un acronyme. Les sorties récentes portent un manifeste C2PA nommant OpenAI et une assertion d'actions avec trainedAlgorithmicMedia ; les fichiers DALL·E 3 plus anciens n'avaient qu'un DigitalSourceType.
  • Adobe Firefly — Le générateur d'Adobe. Écrit un manifeste C2PA et un IPTC DigitalSourceType.
  • Google Imagen / Gemini — Les modèles de Google. Les sorties portent un filigrane SynthID invisible et, sur certaines surfaces, des métadonnées C2PA ou un indicateur IPTC.
  • FLUX, Ideogram, Leonardo.Ai, Recraft, Krea, Runway, InvokeAI, Fooocus, Microsoft Designer, LiblibAI — Autres générateurs et interfaces dont les noms, lorsqu'ils sont trouvés dans n'importe quel champ de métadonnées, sont traités comme une déclaration d'origine IA.
  • Tongyi Wanxiang, Jimeng / Doubao, Kling, Yige, Hunyuan — Services de génération chinois. Leurs noms dans les métadonnées sont des signaux IA, et depuis septembre 2025, leurs sorties sont censées porter l'étiquette implicite AIGC décrite ci-dessous.
  • Filigrane invisible — Un signal intégré dans les pixels eux-mêmes plutôt que dans les métadonnées, conçu pour survivre au recadrage, au réencodage et aux captures d'écran. SynthID est celui de Google ; d'autres existent. Ils nécessitent le détecteur du fournisseur et ne sont pas lisibles dans les métadonnées, ce site ne peut donc pas les voir.

En savoir plus : Métadonnées Stable Diffusion, Métadonnées Midjourney, Métadonnées images OpenAI, Filigranes invisibles.

Les règles chinoises d'étiquetage AIGC

  • AIGC (AI-Generated Content) — Le terme utilisé par la réglementation et l'industrie chinoises pour le texte, les images, l'audio et la vidéo produits par des modèles génératifs.
  • Mesures d'étiquetage — Les Mesures d'étiquetage du contenu synthétique généré par l'IA, émises par la CAC (Cyberspace Administration of China) avec trois autres régulateurs, en vigueur depuis le 1er septembre 2025. Elles obligent les services de génération à étiqueter les sorties et les plateformes de distribution à préserver et afficher les étiquettes.
  • GB 45438-2025 — La norme nationale obligatoire qui spécifie comment étiqueter : « Technologie de cybersécurité : Méthode d'étiquetage du contenu synthétique généré par l'IA ». GB est l'abréviation de Guobiao, « norme nationale », le préfixe de chaque norme nationale chinoise. Entrée en vigueur le même jour que les Mesures.
  • TC260 (Technical Committee 260) — Le Comité technique de normalisation de la sécurité de l'information nationale, qui rédige les normes et publie des guides de pratique, dont celui décrivant l'étiquette de métadonnées.
  • Étiquette explicite — Une étiquette perceptible par les personnes : texte visible ou badge sur une image, signal sonore dans l'audio.
  • Étiquette implicite — Une étiquette écrite dans les métadonnées du fichier pour que les machines la lisent. En pratique, un objet JSON dans un champ XMP, un bloc de texte PNG ou un commentaire JPEG.
  • Label: "AIGC" — Le premier champ fixe de l'étiquette implicite. Le rapport recherche dans chaque support de texte du fichier un objet JSON le contenant.
  • ContentProducer — Le nom ou le code du service qui a généré le contenu.
  • ProduceID — L'identifiant du service pour ce contenu particulier.
  • ContentPropagator / PropagateID — La plateforme qui a distribué le contenu et son identifiant pour celui-ci, rempli lorsqu'une plateforme réécrit l'étiquette lors de l'upload.
  • ReservedCode1 / ReservedCode2 — Champs que la norme réserve pour une utilisation future.

En savoir plus : À quoi ressemble l'étiquette implicite AIGC.

Cryptographie, en bref

  • Hachage — Une fonction à sens unique qui transforme n'importe quelles données en une empreinte de taille fixe. Des entrées égales donnent des hachages égaux ; une entrée modifiée donne un hachage sans rapport. C2PA utilise SHA-256 et ses apparentés pour chaque liaison.
  • Signature numérique — Une valeur calculée à partir d'un hachage des données avec une clé privée, vérifiable par n'importe qui avec la clé publique correspondante. Prouve que les données n'ont pas été altérées et ont été signées par le détenteur de la clé.
  • Clé publique / clé privée — Les deux moitiés d'une paire de clés. La moitié privée signe et est gardée secrète ; la moitié publique vérifie et est publiée dans le certificat.
  • AC (autorité de certification) — Une organisation qui émet des certificats après vérification de l'identité du demandeur. Le certificat racine d'une AC est ce que contiennent les listes de confiance.
  • Certificat auto-signé — Un certificat signé avec sa propre clé. N'importe qui peut en créer un en quelques secondes, il ne prouve donc rien sur l'identité, seulement que la même clé a signé le certificat et les données.
  • RFC (Request for Comments) — Les documents numérotés dans lesquels les standards Internet sont publiés ; la RFC 3161 (horodatages), la RFC 8949 (CBOR) et la RFC 9052 (COSE) apparaissent toutes sur cette page.
  • TSA (autorité d'horodatage) — Un service qui signe un hachage avec l'heure actuelle, selon la RFC 3161, afin qu'une signature puisse être prouvée comme antérieure à un moment donné.
  • Période de validité — Les dates entre lesquelles un certificat est censé être utilisé. Un manifeste signé avec un certificat expiré est signalé ; l'importance de cela dépend de si un horodatage prouve qu'il a été signé pendant sa validité.