AuditImage
ガイド

画像出処関連用語集

AuditImageレポートや本ガイドで使用されるすべての用語と略語を、APP1からXMPまで各用語について数文で説明します。

このサイトのレポートには多くの用語が登場します。セグメント、チャンク、マニフェスト、アサーション、トラストアンカーなどです。このページではそれぞれを一度に定義し、遭遇する場所ごとにグループ化しています。用語は太字で表示され、すべての略語は初めて登場する際に括弧付きの綴りを併記します。各セクションの末尾にリンクされているガイドではさらに詳しく解説しています。

判断結果とレポート

  • 出処（Provenance） — 写真がどこから来て、その後何が起きたか：カメラで撮影された、モデルによって生成された、プログラムで編集された、またはそれらの組み合わせ。このサイトのすべての作業は、ファイル自体から出処を読み取ろうとする試みです。
  • 判断結果（Verdict） — レポートの先頭にある一行の結論。優先順位に基づいて選択されます：有効または無効なContent Credentialはメタデータの自己申告より優先され、自己申告は矛盾より優先され、矛盾はプレーンなカメラEXIFブロックより優先され、EXIFブロックは出処について何も語らないメタデータより優先されます。
  • 発見事項（Finding） — レベル（info、notice、warning）付きの観察結果。レポートは判断結果とその発見事項で構成されます。判断結果は発見事項から導き出されるものであり、その逆ではありません。
  • AI（人工知能）シグナル — 特定の種類の発見事項：画像がモデルによって生成されたことを示すフィールド、テキストブロック、またはマニフェスト。レポートにはシグナルと、XMP DigitalSourceTypeやPNG tEXt "parameters"のような正確な読み取り場所が記載されます。
  • 自己申告（Self-declared） — ファイルが署名のないプレーンなメタデータで自身について述べた内容。どのプログラムでも書き込みや削除が可能なため、自己申告はツールが何を書いたかの証拠であり、何が起きたかの証明ではありません。
  • Content Credentialsで宣言済み — 署名されたC2PAマニフェスト内で述べられた内容。署名が検証され、署名者が信頼される場合、その声明は署名以降改ざんされていません。
  • 矛盾（Inconsistent） — メタデータの部分が相互に矛盾する場合の判断結果。これはファイルが削除された後に手動で再ラベル付けされた指纹です。以下のEXIFとXMPの発見事項を参照してください。
  • 削除済み（Stripped） — メタデータが削除された状態。ほとんどのソーシャルプラットフォームとメッセージングアプリはアップロード時にこれを実行します。同様に「EXIFを削除」ツールもこれを行います。削除されたファイルはメタデータから判断することはできません。
  • 再ラベル付け（Re-labelled） — 元のメタデータが削除された後にファイルに書き込まれたメタデータ。原本でないものに見せるためです。通常、矛盾として検出されます。
  • セグメントマップ — JPEG、PNG、またはWebPレポートの下部にあるテーブルで、ファイル内のすべてのブロックをオフセットと長さとともに順番に列挙しています。出処情報を含むブロックにはマークが付きます。
  • SHA-256（Secure Hash Algorithm, 256ビット） — 暗号ハッシュ：ファイルのバイト列の固定長フィンガープリント。レポートに表示されることで、2人が同じファイルを見ていることを確認できます。1バイトでも変更するとハッシュ全体が変わります。

コンテナ：バイト列の配置方法

  • コンテナ — 画像データとメタデータを包むファイルフォーマット：JPEG、PNG、WebPなど。各フォーマットはメタデータを保持する独自の方法を持っています。そのため同じEXIFブロックがJPEGでは「APP1セグメント」に、PNGでは「eXIfチャンク」に配置されます。
  • JPEG（Joint Photographic Experts Group） — 最も一般的な写真フォーマットで、策定した委員会の名前から命名されました。JPEGはセグメントの系列であり、各セグメントは2バイトのマーカーで始まります。
  • SOI / EOI（Start Of Image / End Of Image） — JPEGの最初と最後のマーカー。EOI以降のデータはビューアーに無視され、古典的な隠し場所です。
  • APPnセグメント（application segment n） — APP0からAPP15で、JPEGメタデータが配置される場所です。どの標準がどの番号を使用するかは慣例であり、フォーマットによっては強制されません。
  • APP0 JFIF（JPEG File Interchange Format） — 基本的なJPEGヘッダー：バージョン、ピクセル密度、サムネイル（有时）。ほぼすべてのJPEGがこれを保持しています。出処情報は含まれません。
  • APP1 EXIF（Exchangeable Image File Format） — EXIFを保持するセグメント（以下参照）。カメラとスマートフォンが書き込みます。
  • APP1 XMP（Extensible Metadata Platform） — XMPを保持するセグメント。大きなXMPパケットはAPP1 XMP ext（拡張XMP）セグメントに拡張され、再アセンブルが必要です。
  • APP2 ICC（International Color Consortium） — カラープロファイル。大きい場合は複数のAPP2セグメントに分割されます。色値の解釈方法を示しますが、出処については何も述べません。
  • APP2 MPF（Multi-Picture Format） — 同じファイルに埋め込まれた追加画像のインデックス。通常はスマートフォンの大きなプレビューまたは深度マップです。一部のスマートフォンのメタデータはここに配置されています。
  • APP11（JPEG XT） — JPEG XT（JPEG eXTensions、ISO/IEC 18477ファミリー；IECは国際電気標準会議で、ISOとの共同標準のパートナー）がボックスデータに使用するセグメント番号です。C2PAもこれを使用するため、APP11 C2PAはコンテンツがC2PA JUMBFボックスであるAPP11セグメントのラベルです。複数のセグメントに分割され、シーケンス番号で再アセンブルされることもあります。
  • APP13 Photoshop IRB（Image Resource Block）/ IPTC（International Press Telecommunications Council） — Photoshopのリソースブロックです。歴史的にはIPTCのキャプションと著作権フィールドがここに格納されていました。Photoshopは現在でも書き込み続けています。
  • APP14 Adobe — Adobeエンコーダーがカラートランスフォームを記述するために書き込む小さなセグメント。このセグメントの存在は、ファイルがどこかでAdobeライブラリを通ったことを示します。
  • COM（comment） — フリーテキストコメントセグメント。一部の生成ツールはパラメータをここに書き込みます。
  • スキャンデータ — 圧縮されたピクセルそのもの。最初の**SOS（Start Of Scan）**マーカーからEOIまですべてです。
  • PNG（Portable Network Graphics） — チャンクからなるロスレスフォーマット：4文字のタイプ、長さ、データ、**CRC（cyclic redundancy check）**チェックサム。小文字で始まるチャンク名はオプションであり、理解しないツールによっては削除される可能性があります。
  • PNG署名 — すべてのPNGが開始する固定8バイト。
  • IHDR / IDAT / IEND（image header / image data / image end） — 必須チャンク：ヘッダー（寸法、ビット深度）、画像データ、ファイル終了。
  • tEXt / iTXt / zTXt — PNGテキストチャンク：キーワードと値。tEXtはLatin-1（ISO 8859-1）、iTXtは**UTF-8（Unicode Transformation Format, 8ビット）**の国際テキストで圧縮される場合もあります、zTXtはzlib圧縮Latin-1です。Stable Diffusion、ComfyUI、NovelAIは生成パラメータをここに書き込み、PNGのAIGCラベルも通常ここに配置されます。
  • eXIf — 2017年にEXIFブロックを運ぶために標準化されたPNGチャンク。古いツールは代わりにテキストチャンクにEXIFを配置していました。
  • iCCP（ICC profile） — ICCカラープロファイル用のPNGチャンク。
  • caBX — C2PA仕様がPNGでJUMBFボックスを運ぶために登録した4文字のチャンクタイプです。チャンク名であり、公式な展開を持つ頭字語ではありません。レポート内のcaBX C2PAは、チャンクが見つかりマニフェストストアとして解析されたことを意味します。
  • WebP — VP8ビデオコーデックから派生したGoogleの画像フォーマット。WebPはRIFF（Resource Interchange File Format）ファイルです：ヘッダーと4文字の名前を持つチャンクの系列。VP8とVP8L（VP8ロスレス）は画像データを保持し、VP8X（VP8拡張）はどのオプションチャンクが続くかを示すヘッダーです。EXIF、XMP、ICCP（ICC profile）チャンクはそれらのブロックを運び、C2PAチャンクはJUMBFボックスを運びます。
  • HEIC / AVIF / TIFF / GIF — このサイトがEXIFとXMPを読み取るが、セグメントごとにマッピングしないフォーマットです。**HEIC（High Efficiency Image Container）とAVIF（AV1 Image File Format；AV1はAOMedia Video 1で、格納するコーデック）**はMP4と同じファミリーのISO基本メディアファイルフォーマットコンテナです。**TIFF（Tagged Image File Format）**はEXIF自体がモデルにしたフォーマットです。**GIF（Graphics Interchange Format）**はほぼメタデータを保持していません。

詳しくは：ファイル内のメタデータの配置場所、なぜメタデータは消えるのかを参照してください。

メタデータ標準

  • メタデータ（Metadata） — ピクセルと一緒に画像に格納されるデータ：いつ撮影されたか、どのカメラで、どの設定で、最後にどのプログラムで保存されたか。表示するために必要ではないため、目に見える変更なしに削除できます。
  • EXIF（Exchangeable Image File Format） — カメラとスマートフォンが撮影詳細を記録するために使用する標準：MakeとModel、露出、レンズ、DateTimeOriginal、向き、GPS、Software（最後にファイルを書き込んだプログラム）。TIFFから借用したバイナリ構造です。エディターは保存、再書き込み、削除のいずれかを行います。EXIFには署名されたものはありません。
  • DateTimeOriginal — EXIFの撮影タイムスタンプ。現地時間でタイムゾーンなし。不一致を検出するためにXMPの作成日と比較されます。
  • Software — 最後にファイルを書き込んだプログラムを名前付するEXIFタグ。ここに生成ツールの名前がある場合はAIシグナルです。エディターの名前はエディターであるだけです。
  • XMP（Extensible Metadata Platform） — Adobeのメタデータ標準で、XML（Extensible Markup Language）で書かれ、現在はISO（International Organization for Standardization）標準ISO 16684です。EXIFと同じ事実に加えて編集情報を格納します：CreatorTool（プログラム）、CreateDateとModifyDate、および編集履歴です。テキストで署名されておらず、すべてのAdobe製品が保存時に再書き込みします。
  • CreatorTool — ファイルを作成したプログラムを名前付するXMPフィールド。EXIF Softwareと比較されます。誠実な履歴を持つファイルでは通常一致します。
  • XMP History — xmpMM:History（MMはMedia Management）は編集イベントのリストで、各イベントにはソフトウェアエージェント、アクション、時刻があります。他の文書からの派生を主張するが履歴がない（DerivedFrom）ファイルは疑わしいです。
  • DerivedFrom — この文書が作成された元の文書を指すXMPフィールド。エクスポートされた編集には存在します。カメラオリジナルには無意味です。
  • Document ID / Instance ID（identifier） — Adobe製品が文書とその各保存バージョンに割り当てるXMP識別子。これによりHistoryエントリを特定の保存に紐付けることができます。
  • IPTC（International Press Telecommunications Council） — ニュース業界の写真メタデータスキーマ：キャプション、クレジット、著作権、および2023年からはDigitalSourceTypeフィールド。
  • DigitalSourceType — XMPに格納されるIPTCフィールドで、画像がどのように生成されたかを記述します。trainedAlgorithmicMediaという値は「訓練されたAIモデルによって作成された」ことを意味します。Adobe Firefly、DALL·Eなど複数のツールがこれを書き込みます。プレーンメタデータにおける業界標準AIフラグに最も近いものですが、まだテキストであるにすぎません。
  • ICC（International Color Consortium）profile — カラープロファイル。ソフトウェアにファイルの色値を表示用にどのように変換するかを伝えます。出処については何も述べませんが、プロファイルの説明に埋め込んだプログラム名が記載されることがあります。
  • GPS（Global Positioning System） — EXIF内の位置フィールド。共有された写真がこれらを保持する必要は少ないため、発見事項として報告されます。

詳しくは：EXIFの基礎、XMPと編集履歴、メタデータの偽造方法を参照してください。

C2PAとContent Credentials

  • C2PA（Coalition for Content Provenance and Authenticity） — 産業団体（Adobe、Microsoft、Google、Sony、Nikon、Leica、OpenAIなど）および、その団体が公開する署名された出処データのための公開技術仕様の名前です。
  • CAI（Content Authenticity Initiative） — C2PAの採用を推進し、公開Verifyサイトを運営するAdobe主導のコミュニティです。
  • Content Credentials — ファイルに添付されたC2PAデータのコンシューマー向け名称です。レポートに「Contains Content Credentials」と表示される場合、C2PAマニフェストストアが見つかったことを意味します。
  • マニフェスト（Manifest） — 出処の署名された記録：誰がこのバージョンを作成したか、どのツールで、何のアクションが行われたか、何から派生したか。C2PA対応ツールで複数回編集されたファイルは複数のマニフェストを保持します。
  • マニフェストストア（Manifest store） — ファイルのすべてのマニフェストを保持するコンテナ。物理的にはAPP11、caBX、またはWebP C2PAチャンク内のJUMBFボックスです。
  • アクティブマニフェスト（Active manifest） — 最新のマニフェストで、現在のファイルを記述するものです。現在のバイト列と一致が期待されるのはハードバインディングのみです。以前のマニフェストは後続のマニフェストのイングリディエントとしてカバーされます。
  • クレーム（Claim） — マニフェストの核心：アサーションをハッシュでリスト化し、クレーム生成者を記名し、署名への参照を含むCBOR構造です。署名はクレームのバイト列に対して計算されます。
  • クレーム生成者（Claim generator） — マニフェストを生成したソフトウェアで、クレーム内で名前付されます。ツールとして報告されます。
  • アサーション（Assertion） — マニフェスト内の声明です。標準のアサーションにはc2pa.actions（何が行われたか）、c2pa.hash.data（ハードバインディング）、c2pa.ingredient（何から作られたか）、stds.schema-org.CreativeWork（著者と著作権）があります。
  • アクション（Action） — アサーションアサーション内の1つのエントリ：c2pa.created、c2pa.edited、c2pa.opened、c2pa.placedなど。trainedAlgorithmicMediaというデジタルソースタイプを持つcreatedアクションは、マニフェストがAI生成を宣言する方法です。digitalCaptureはカメラ撮影を宣言します。
  • イングリディエント（Ingredient） — このアセットに入った他のアセットを記録するアサーションで、元にマニフェストハッシュがあればそれも記録されます。イングリディエントは、編集の連鎖を検証可能にする方法です。
  • JUMBF（JPEG Universal Metadata Box Format） — C2PAが使用するボックス構造のバイナリコンテナで、ISO/IEC 19566-5で定義されています。ボックスはネストします：スーパーボックスは説明ボックス（jumd）とcbor、json、bidb（バイナリデータボックス）などのコンテンツボックスを保持します。
  • CBOR（Concise Binary Object Representation） — RFC 8949で定義された、JSONに似たデータの簡潔なバイナリエンコーディングです。クレームとほとんどのアサーションはCBORです。
  • JSON（JavaScript Object Notation） — CBORのバイナリ表親であるプレーンテキストデータフォーマットです。一部のアサーションとAIGCラベルはJSONです。
  • COSE（CBOR Object Signing and Encryption）/ COSE_Sign1 — CBORの上に構築された署名フォーマットで、RFC 9052で定義されています。COSE_Sign1はC2PAが使用する単一署名者署名構造です：保護ヘッダー（アルゴリズム、証明書チェーン）、ペイロード（クレーム）、署名バイト列です。
  • X.509証明書 — 公開鍵証明書の標準フォーマットで、策定したITU-T（国際電気通信連合、電気通信標準化部門）の勧告にちなんで命名されました：公開鍵、所有者の名前、保、保証する発行者の名前、有効期限、および発行者の署名です。署名証明書はCOSEヘッダー内でx5chain（X.509チェーン）として送られます。
  • 証明書チェーン（Certificate chain） — 署名（リーフ）証明書、それを発行した中間証明書、 rootViewまで。各リンクは1つの証明書の署名を次の証明書の鍵で検証して確認されます。
  • トラストアンカー（Trust anchor） — 検証者がさらなる証明なしに信頼すると決めた証明書です。チェーンがトラストアンカーに到達した場合、署名者の身元は確立されたと見なされます。
  • トラストリスト（Trust list） — トラストアンカーのセットです。C2PAは、審査済みの認証局と署名者の公式リストを公開しています。「署名は有効だが署名者不明」は、数学的には正しいがチェーンがリスト上の何にも到達しなかったことを意味します。自己署名証明書の場合はこのケースです。
  • 署名有効（Signature valid） — クレームに対するCOSE署名がリーフ証明書の鍵で検証されること。マニフェストが署名後に改ざんされていないことを証明します。それ自体で誰が署名したかを証明するものではありません。
  • ハードバインディング（Hard binding） — c2pa.hash.data内のハッシュで、マニフェストストア自体を除外したファイルに対して計算されます。一致する場合、ピクセルは署名後に変更されておらず、このマニフェストはこのファイルに属します。画像がC2PAサポートのないツールで再エンコードまたは編集された場合、このチェックは失敗します。
  • ソフトバインディング（Soft binding） — 再エンコードに耐えるバインディングで、不可視ウォーターマークや知覚フィンガープリントなど。マニフェストがファイルから削除された場合にマニフェストを検索するために使用されます。このサイトはソフトバインディングを評価しません。
  • アサーションハッシュ — 各アサーションをハッシュ化し、クレームがハッシュをリスト化します。検証することで、有効なクレームの下でアサーションが交換されていないことが証明されます。
  • タイムスタンプ（sigTst、署名タイムスタンプ） — オプションのRFC 3161（信頼できるタイムスタンプのインターネット標準）トークンで、時刻認証局からのもので、署名が特定の時刻に存在したことを証明します。存在するか不存在として報告されます。このバージョンでは検証されません。
  • 検証失敗 / 部分検証 — 「失敗」は4つのチェック（署名、ハードバインディング、アサーションハッシュ、チェーン）の1つが否定的であったことを意味します。「部分検証」は、たとえばハッシュアルゴリズムがサポートされていないなどの理由でチェックが完了できなかったことを意味し、レポートにはどのチェックが失敗したかが記載されます。
  • Verifyサイト — verify.contentauthenticity.org、CAIの公開チェッカーです。このサイトと同じトラストリストを適用するため、有用な第二の意見となります。

詳しくは：C2PAとは何か、C2PAの検証方法を参照してください。

AI生成ツールが残す痕跡

  • 生成パラメータ — 生成ツールが使用したプロンプト、モデル、シード、サンプラー、設定。画像を再現可能にするためにツールがファイルに書き込みます。存在は強いAIシグナルですが、存在しないことは何も証明しません。
  • Stable Diffusion（SD） — オープンソースの画像モデルファミリー。最も一般的なフロントエンドはパラメータをPNGテキストに書き込みます。SDXLはStable Diffusion XLで、2023年のより大きなモデルです。
  • Stable Diffusion WebUI（AUTOMATIC1111、A1111） — クラシックなWebフロントエンドで、著者のハンドルネームから命名。A1111は略称です。parametersテキストチャンクを書き込みます：プロンプト、Negative prompt:行、Steps: ..., Sampler: ..., Model: ...。レポートは存在する場合にモデル名を抽出します。
  • ComfyUI（Comfy User Interface） — ノードグラフフロントエンド。2つのテキストチャンクを書き込みます：prompt（JSON形式のグラフ）とworkflow（エディターのレイアウト）。
  • NovelAI — ホスト型のアニメ特化生成ツール。Software: NovelAIとJSONパラメータを含むCommentチャンクを書き込み、説明に「Stable Diffusion」という単語が含まれることが多いです。
  • Midjourney — ホスト型生成ツール。ダウンロードには説明にプロンプトを含むXMPと、Midjourney固有のフィールドにJob ID（UUID、普遍的一意識別子）が含まれます。また、ユーザーを名前付するCreatorフィールドもあります。
  • DALL·E / OpenAI — OpenAIの画像モデル。名前はアーティストのDalíとロボットのWALL·Eを組み合わせたもので、略語ではありません。最近の出力にはOpenAIを名前付するC2PAマニフェストとtrainedAlgorithmicMediaを持つactionsアサーションが含まれます。古いDALL·E 3ファイルにはDigitalSourceTypeのみでした。
  • Adobe Firefly — Adobeの生成ツール。C2PAマニフェストとIPTC DigitalSourceTypeを書き込みます。
  • Google Imagen / Gemini — Googleのモデル。出力には不可視のSynthIDウォーターマークが埋め込まれ、一部のプラットフォームではC2PAメタデータまたはIPTCフラグが含まれます。
  • FLUX、Ideogram、Leonardo.Ai、Recraft、Krea、Runway、InvokeAI、Fooocus、Microsoft Designer、LiblibAI — その他の生成ツールとフロントエンドで、メタデータフィールドで見つかった場合はAI出_originsの声明として扱われます。
  • 通義万相 Tongyi Wanxiang、即夢 Jimeng / 豆包 Doubao、可灵 Kling、文心一格 Yige、混元 Hunyuan — 中国の生成サービスです。メタデータ内の名前はAIシグナルであり、2025年9月以降は以下で説明するAIGC暗黙ラベルを含むことが期待されています。
  • 不可視ウォーターマーク（Invisible watermark） — メタデータではなくピクセル自体に埋め込まれたシグナルで、トリミング、再エンコード、スクリーンショットに耐えるように設計されています。SynthIDはGoogleのものです。他のものも存在します。ベンダーの検出器が必要で、メタデータから読み取れないため、このサイトでは確認できません。

詳しくは：Stable Diffusionメタデータ、Midjourneyメタデータ、OpenAI画像メタデータ、不可視ウォーターマークを参照してください。

中国のAIGCラベル付け規則

  • AIGC（AI-Generated Content） — 中国の規制と業界が生成モデルによって作成されたテキスト、画像、音声、動画に使用する用語です。
  • ラベル付け措置（Labelling Measures） — **CAC（Cyberspace Administration of China）**が他の3つの規制機関と共同で発出した「AI生成合成コンテンツのラベル付けに関する措置」で、2025年9月1日に施行されました。生成サービスに出力のラベル付けを、配信プラットフォームにラベルの保持と表示を義務付けています。
  • GB 45438-2025 — ラベル付け方法を定める義務国規格：「サイバーセキュリティ技術：AI生成合成コンテンツのラベル付け方法」。GBは「国標（Guobiao）」の略で、すべての中国国規格のプレフィックスです。措置と同日に施行されました。
  • TC260（Technical Committee 260） — 国家情報セキュリティ標準化技術委員会。標準を起草し、メタデータラベルを説明する実践ガイドを含む実践ガイドを公開しています。
  • 明示ラベル（Explicit label） — 人が知覚できるラベル：画像上の視覚可能なテキストまたはバッジ、音声内の可聴通知。
  • 暗黙ラベル（Implicit label） — マシンが読み取るためにファイルメタデータに書き込まれるラベル。実際にはXMPフィールド、PNGテキストチャンク、またはJPEGコメント内のJSONオブジェクトです。
  • Label: "AIGC" — 暗黙ラベルの最初の固定フィールド。レポートはファイル内のすべてのテキストキャリアを検索し、これを含むJSONオブジェクトを見つけます。
  • ContentProducer — コンテンツを生成したサービスの名前またはコード。
  • ProduceID — サービスがこの特定のコンテンツに割り当てた識別子。
  • ContentPropagator / PropagateID — コンテンツを配信したプラットフォームとその識別子。プラットフォームがアップロード時にラベルを再書き込みする際に記入されます。
  • ReservedCode1 / ReservedCode2 — 規格が将来の使用のために予約しているフィールド。

詳しくは：AIGC暗黙ラベルの概要を参照してください。

暗号学の概要

  • ハッシュ（Hash） — 任意のデータを固定長フィンガープリントに変換する単方向関数。等しい入力は等しいハッシュを生成し、変更された入力は無関係なハッシュを生成します。C2PAはすべてのバインディングにSHA-256とその派生を使用します。
  • デジタル署名（Digital signature） — データのハッシュと秘密鍵から計算される値で、対応する公開鍵を持つ谁都が検証できます。データが改ざんされておらず、鍵の保有者によって署名されたことを証明します。
  • 公開鍵 / 秘密鍵（Public key / private key） — 鍵ペアの2つの半分。秘密の半分は署名し、非公開にされます。公開の半分は検証に使用され、証明書内で公開されます。
  • CA（certificate authority） — 申請者の身元を確認した後に証明書を発行する組織です。CAのルート証明書はトラストリストに含まれるものです。
  • 自己署名証明書（Self-signed certificate） — 自分自身の鍵で署名された証明書です。谁でも数秒で作成できるため、身元について何も証明せず、証明書とデータの両方が同じ鍵で署名されたことだけを示します。
  • RFC（Request for Comments） — インターネット標準が公開される番号付き文書です。RFC 3161（タイムスタンプ）、RFC 8949（CBOR）、RFC 9052（COSE）がこのページに登場します。
  • TSA（time-stamping authority） — RFC 3161に従い、ハッシュと現在の時刻を一緒に署名するサービスです。これにより、署名が特定の時刻より前に存在したことを証明できます。
  • 有効期間（Validity period） — 証明書が使用される予定の日付の範囲です。有効期限が切れた証明書で署名されたマニフェストは報告されます。重要かどうかは、タイムスタンプが有効期間中に署名されたことを証明するかどうかに依存します。