デジタル署名検証ガイドライン第 1.0 版 2021年3月31日
NPO 法人日本ネットワークセキュリティ協会電子署名ワーキンググループ
https://www.jnsa.org/result/e-signature/2021/index.html
加工
目次
1はじめに …………….. – 1
-1.1 背景と目的 ……………………………………………………………………………… – 1
-1.2 スコープ …………………………………………………………….. – 1
-1.3 本書の位置付けと構成 ………………………………………… – 1
-2 参照文献 ……………………………………………………………………………………. – 3 –
2.1 引用規格 …………………………………………………………………………………… – 3 -2.2参考文献………………………………………… …………… – 4
-3 用語定義と略語 …………………………………………………………………………… – 5
-3.1 用語 …………………………………………………………………………………… – 5
-3.2 略語 …………………………………………………… – 8
-4 デジタル署名 ………………………………………………………………………………… – 9
-4.1 デジタル署名の概念モデル …………………………………………………….. – 9 –
4.1.1 デジタル署名の基本原理 ………………………………………………………… – 9 –
4.1.2 電子証明書と認証局、公開鍵基盤(PKI) ……………………………………….. – 9 –
4.1.3 デジタル署名のメカニズムと基本要件 ……………………………………… – 11 –
4.1.4 署名データの形式 ……………………………………………………………. – 13 –
4.2 時刻の保証と長期署名フォーマット …………………… – 15 –
4.2.1 時刻情報とタイムスタンプ局 …………………………………………… – 15 –
4.2.2 長期的な署名の担保と署名の延長 ………………………………………… – 15
4.2.3 AdESフォーマット ……………………….. – 18 –
5 デジタル署名の検証 ………………………………………… – 21 –
5.1 署名検証の概念モデル ………………………………… – 21 –
5.1.1 署名検証の基本要件 ……………………………. – 21 –
5.1.2 検証のアプリケーションモデル ………………………………….. – 22 –
5.1.3 署名判定結果の概念モデル ……………………………………………….. – 23 –
5.1.4 要求レベル（必須とオプション）の考え方 ………………………. – 24 –
5.2 検証プロセス …………………………………………. – 25 –
5.2.1 検証プロセスの考え方 ……………………………………………………… – 25 –
5.2.2 トラストアンカー ………………………………………………………. – 26 –
5.2.3 証明書 …………………………………………….. – 26 –
5.2.4 失効情報 ………………………………………………………….. – 26 –
5.2.5 暗号アルゴリズムの脆弱性に関する情報 …………………… – 27 –
5.2.6 タイムスタンプ …………………………………………. – 27 –
5.2.7 検証基準時刻（validation reference time）…………………….. – 27 –
5.2.8 署名要素に対する制約 …………………………………….. – 28 –
5.3 検証データの全体構造 ………………………………………. – 29 –
5.3.1 署名者による署名(AdES-BES) …………………………………………. – 29 –
5.3.2 署名タイムスタンプ付き署名(AdES-T) ……………… – 30 –
5.3.3 検証情報付き署名(AdES-X-Long) …………………………………….. – 31 –
5.3.4 アーカイブ付き署名(AdES-A) ……………………………. – 32 –
5.4 検証基準時刻と検証の観点 ………………………….. – 33 –
5.4.1 AdES-BES検証における検証基準時刻と検証の観点 ………… – 33 –
5.4.2 AdES-T検証における検証基準時刻と検証の観点…………… – 34 –
5.4.3 AdES-X-Long検証における検証基準時刻と検証の観点 ………………. – 37 –
5.4.4 AdES-A検証における検証基準時刻と検証の観点…………. – 40 –
5.5 署名の検証要件 …………………………………. – 46 –
5.5.1 アルゴリズムの有効性の確認 ……………………. – 46 –
5.5.2 CAdESの検証要件 ………………………………. – 46 –
5.5.3 XAdESの検証要件 …………………………. – 51 –
5.5.4 PAdESの検証要件 ………………………. – 58 –
5.6 タイムスタンプの検証要件 ……………………… – 66 –
5.6.1 タイムスタンプ ……………………. – 66 –
5.6.2 署名タイムスタンプ …………………… – 70 –
5.6.3 アーカイブタイムスタンプ …………………… – 71
5.6.4 ドキュメントタイムスタンプ ……………………….. – 75 –
5.7 証明書の検証要件 ……………………………………………. – 77 –
5.7.1 AdES-BESにおける証明書 …………………………………………. – 77
-5.7.2 AdES-Tにおける証明書 …………………………………… – 81
-5.7.3 AdES-Aにおける証明書 ……………………. – 84
-付属書 A (規定):供給者適合宣言書及び供給者適合宣言書の別紙 . – 86 –
A.1 序文 ……
A.2 供給者適合宣言書の様式 ………………………. – 86 –
A.3 供給者適合宣言書の別紙の様式 ………………………. – 86 –
A.4 検証手順 ……………………………. – 87 –
A.4.1 共通 ………………………………………… – 87 –
A.4.2 CAdES 検証 …………………………………………………… – 88 –
A.4.3 XAdES 検証 ………………………. – 89 –
A.4.4 PAdES 検証 ……………………………………….. – 90 –
A.5 データ …………………………………………. – 91 –
A.5.1 タイムスタンプトークンデータ要素 ………………… – 91 –
A.5.2 CAdES データ要素 ……………………………………… – 93 –
A.5.3 XAdES 構文のXML要素 …………………….. – 94 –
A.5.4 PAdESのデータ要素 ………………………… – 95 –
A.6 X.509 証明書 …………………………………. – 97 –
A.6.1 X.509 証明書パス検証 ……………………………………………….. – 97 –
A.6.2 署名者証明書のX.509証明書パス検証 …………………. – 98 –
A.6.3 TSA証明書のX.509 証明書パス検証 …………………. – 98 –
付属書
B (参考): PAdES関連情報 …………………………… – 99 –
B.1 PAdES署名レベル判定 …………………………….. – 99 –
B.2 PAdES複数署名 …………………………………………. – 100 –
B.3 PAdES署名後の増分更新 ……………………………… – 101 –
B.4 PAdES署名とPDF暗号化仕様 ……………………………. – 102 –
B.5 PAdES署名のAcrobat Readerによる検証 ………………… – 103
-付属書 C (参考): 暗号アルゴリズム ……………… – 104 –
C.1 暗号アルゴリズムや鍵長の安全性確認の困難さについて …… – 104 –
C.2 AdES署名検証の暗号アルゴリズム及び鍵長の安全性判断基準の一例. – 108 –
– 1 -1 はじめに
1.1 背景と目的
デジタル化とネットワーク化の進展に伴い、デジタルデータの保証と取り扱う人やサービスの信頼性が、これまで以上に必要とされるようになっている。中でもデータの作成責任とその真正性は、アナログ時代においては「署名」や「押印」によって担保されてきた。デジタル時代においては、それに相当する技術として「電子署名」がある。署名は文書等にそれが付与され、受領者が署名を確認することで文書等の真偽や価値の判断材料となる。しかし、可視データであるアナログの「署名」や「押印」と違い、「電子署名」は機械処理としての「署名検証」が必要であり、検証ツール（ソフトウェア）に依存することになる。さらに、電子署名は様々な要素から構成されており、その判定は注意を要する。その判定基準が検証ツールによって異なると、同じデータに対する判定が異なる結果となり、デジタル化の阻害要因となりかねない。それを防ぐため、次世代電子商取引推進協議会（ECOM）平成18 年度成果「電子文書長期保存ハンドブック」など、署名検証の判定基準について検討されてきた。本書は、電子署名のうち公開鍵暗号技術に基づくデジタル署名について検証のガイドラインを示すため、タイムビジネス協議会（TBF）2013 年作成の「電子署名検証ガイドライン」を引き継いで更新したものである。
1.2 スコープ
電子署名とは、電磁的記録（電子文書）に関連付けられ、検証により確認可能な、電子的措置であり、その効力を持たせるために様々な方式がある。欧米では電子署名(electronicsignature)とデジタル署名(digital signature)を区別し、電子署名は広い意味で、本人と電子文書との関係を示すために本人が作成した電子データを指し、デジタル署名は、署名者の身元とデータが改ざんされていないことを、公開鍵暗号技術を使って検証できる技術を指す。本書では、デジタル署名の中でも特に規格が整備され、相互運用性、国際流通性に優れた先進電子署名（AdES）を取り上げ、以後、電子署名（又は単に署名）と記した場合はこれを指すものとする。特に規約部分では、国際標準として規定された CAdES、XAdES、PAdES のプロファイルを対象として検証の処理を示す。なお、本書では技術的な判定基準について述べるが、法的有効性に関してはスコープ外とする。
1.3 本書の位置付けと構成
本書は、先進電子署名（AdES）の検証処理に関するガイドライン（規約部分を含む）を定めるものである。・ 規約には技術的有効性を確認するための要件を定義する。- 署名検証の共通要件と CAdES、XAdES、PAdES の固有要件とを定義する。
規約には、技術的な安全性確保を優先して決定した値を規定する（規定値と呼ぶ）こととし、各国の法規制等に依存する要素や適用領域の事情に依存する要素は極力排除することとする。
・ アプリケーションの提供者が各実装における規定値との差分を明示するための供給者による適合宣言書の書式を提供する。
対象読者：・ 署名検証システムあるいはサービスの利用者。
・ 署名検証システムあるいはサービスの調達者。
・ 署名検証システムあるいはサービスの開発者（設計者及び実装者）。
構成：・ 1 章：本章。本書のスコープ、対象読者、構成、使い方を記す。
・ 2 章：本書が準拠すべき規格（引用規格）と参考となる文献（参考文献）を記す。
・ 3 章：用語定義と略語を記す。
・ 4 章：署名の基本概念とデータ形式を記す。
・ 5 章：署名検証の概念モデルと検証の詳細要件（規約部分）を記す。
・ 付属書：供給者適合宣言書の書式及び実装に関わる参考情報等を記す。
推奨する参照範囲：
・ 利用者は 3 章を参照し、4 章、5.1 節を読むことを推奨する。
・ 調達者は 3 章を参照し、4 章、5 章を読むことを推奨する。
・ 開発者は 2 章及び 3 章を参照し、4 章、5 章、付属書を読むことを推奨する。
2 参照文献
2.1 引用規格
[1] ISO 14533-1：2014：「商取引、産業におけるプロセス、データ要素、およびドキュメントおよび管理-長期署名プロファイル-パート1：長期署名CMS高度電子署名（CAdES）のプロファイル」
[2] ISO 14533-2：2012：「商取引、産業におけるプロセス、データ要素、およびドキュメントおよび管理-長期署名プロファイル-パート2：長期署名XML高度電子署名（XAdES）のプロファイル」
[3] ISO 14533-3：2017：「商取引、産業におけるプロセス、データ要素、およびドキュメントおよび管理-長期署名プロファイル-パート3：長期署名PDF高度電子署名（PAdES）のプロファイル」
[4] ISO 32000-2：2017：「ドキュメント管理-ポータブルドキュメントフォーマット-パート2：PDF 2.0 “
[5] EN 319 122-1：「CAdESデジタル署名。パート1：ビルディングブロックとCAdESベースライン署名」
[6] EN 319 122-2：「CAdESデジタル署名。パート2：拡張CAdES署名」
[7] EN 319 132-1：「XAdESデジタル署名。パート1：ビルディングブロックとXAdESベースライン署名」
[8] EN 319 132-2：「XAdESデジタル署名。パート2：拡張XAdES署名」
[9] EN 319 142-1：「PAdESデジタル署名。パート1：ビルディングブロックとPAdESベースライン署名」
[10] EN 319 142-2：「PAdESデジタル署名。パート2：追加のPAdES署名プロファイル」
[11] IETF RFC 5280：「インターネットX.509公開鍵インフラストラクチャ証明書と証明書失効リスト（CRL）プロファイル」。
[12] IETF RFC 6818：「インターネットX.509公開鍵インフラストラクチャの更新証明書および証明書失効リスト（CRL）プロファイル」
[13] IETF RFC 8398：「X.509証明書の国際化された電子メールアドレス」
[14] IETF RFC 8399：「RFC5280の国際化アップデート」
[15] ISO / IEC 9594-8：2017：「情報技術-オープンシステム相互接続-ディレクトリ–パート8：公開鍵および属性証明書フレームワーク」。
[16] W3C勧告：「XMLSignature構文および処理バージョン2.0」、2015年
[17] IETF RFC 3161：「インターネットX.509公開鍵インフラストラクチャ;タイムスタンププロトコル（TSP）」。
[18] IETF RFC 5816：「RFC3161のESSCertIDv2アップデート」
[19] IETF RFC 5652：「暗号化メッセージ構文（CMS）」。
[20] IETF RFC 8933：「アルゴリズムの暗号化メッセージ構文（CMS）の更新識別子の保護」
[21] IETF RFC 4998：「エビデンスレコード構文（ERS）」。
[22] IETF RFC 6283：「ExtensibleMarkup Language Evidence RecordSyntax（XMLERS）」
2.2参考文献
[i.1] IETF RFC 4158：「インターネットX.509公開鍵インフラストラクチャ：認証パス建物”。
[i.2] TS 119 172-1：「署名ポリシー;パート1：ビルディングブロックと目次人間が読める署名ポリシー文書の場合」
[i.3] TS 119 172-2：「署名ポリシー;パート2：署名ポリシーのXML形式」
[i.4] TS 119 172-3：「署名ポリシー;パート3：署名ポリシーのASN.1形式」
[i.5] TS 119 172-4：「署名ポリシー;パート4：の署名検証ポリシー信頼できるリストを使用したヨーロッパの資格のある電子署名/シール」
[i.6] IETF RFC 6960：「X.509インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル-OCSP」。
[i.7] EN 319 102-1＆TS 119 102-1：「AdESの作成と検証の手順デジタル署名; パート1：作成と検証」
[i.8] TS 119 102-2：「AdESデジタルの作成と検証の手順署名; パート2：署名検証レポート」
[i.9] IETF RFC 5698：暗号化のセキュリティ適合性のためのデータ構造アルゴリズム（DSSC）
[i.10] 電子文書長期保存ハンドブック：次世代電子商取引推進協議会,2007.3https://www.jipdec.or.jp/archives/publications/J0004262[i.11] 電子署名検証ガイドライン V1.0.0：タイムビジネス協議会 調査研究 WG, 2013.6.5
3 用語定義と略語
3.1 用語用語は一般的なものを除き、ISO、IETF RFC、JIS、ETSI などの規格に基づく。引用規格（normative references）:本書が参照する規格。
ベース仕様（base specification）:プロファイルのベースとなる仕様。例えば PAdES であれば、ベース仕様は PDF の ISO 32000-2 となり、プロファイルは ISO 14533-3 となる。
プロファイル（profile）:標準化においてプロファイルとは、ベースとなる仕様（引用規格）の部分集合（サブセット）となる。先進電子署名においては、ISO 14533 シリーズで定義された ISOプロファイルと、欧州のEN としての Baseline 署名(プロファイルと呼んでいないが事実上はプロファイル)がある。
先進電子署名（Advanced Electronic Signature (AdES)）:次の要件を満たす電子署名。
1) 署名者とユニークに関係付けられている
2) 署名者を特定することができる
3) 署名者単独の制御下にある手段で生成される4) その後データが改ざんされたことを発見できるような方法でデータと関連付けられている注：以降、本書では先進電子署名を「署名」と略して用いる。
【コラム１】■AdES という呼称の経緯
1999 年に発行された EU 電子署名指令（Directive 1999/93/EC）で”Advanced ElectronicSignature”が定義されている。”Advanced Electronic Signature”は日本では「先進電子署名」あるいは「高度電子署名」と訳される。ただし、略称となる”AdES”は用いられていない。初期 ETSI の電子署名に関する規格（例えば”ETSI TS 101 733 V1.2.2 (2000-12);Electronic signature formats”）でこの定義を参照しているが、”Advanced ElectronicSignature”の略称として”AdES”を当ててはいない。
最初に”AdES”の略称を用いたのは”ETSI TS 101 903 V1.1.1 (2002-02); XML AdvancedElectronic Signatures (XAdES)”であり、その後、CMS の電子署名規格（ETSI TS 101 733V1.6.3 (2005-09); CMS Advanced Electronic Signatures (CAdES)）でも”AdES”（実際には”CAdES”であるが）が用いられるようになった。2014 年に成立したEU のeIDAS 規則（eIDAS Regulation）でも電子署名指令の定義は引き継がれており、”Advanced Electronic Signature”に対して電子署名指令とほぼ同等の定義が与えられているが、略称”AdES”が用いられていないのは電子署名指令と同様である。またeIDAS 規則では自然人が生成する電子署名（Electronic Signature）に加え、法人が生成する e シール（Electronic Seal）の概念を導入し、”Advanced Electronic Seal”の要件を定義している。その後、ETSI では”ETSI TS 119 122-1 V1.0.1 (2015-07)”や”ETSI TS 119 102-1 V1.0.1(2015-07)”などの規格から、”AdES”を略称ではなく固有名詞として扱い、CMS、XML、PDF それぞれに対する署名として”CAdES Digital Signature”、”XAdES Digital Signature”、”PAdESDigital Signature”を、又その総称として”AdES Digital Signature”を用いるようになった。
“AdES”が”Advanced Electronic Signature”あるいは”Advanced Electronic Seal”のどちらの略称であるかが区別できないこと、両者の要件を満たす共通技術としてデジタル署名（Digital Signature）が想定されていること、ETSI が制定する規格がデジタル署名を対象としていることなどからそのような対応となったと考えられる。
署名レベル（signature level）:先進電子署名において、プロファイル定義されている 4 つの署名のレベル（生成段階）を示す。
証明書の認証パス検証（certification path validation）:証明書チェーンの有効性を確認する処理。
(署名検証)制約（constraints）／検証制約（validation constraint）:先進電子署名の有効性を検証するときに署名検証アプリケーション（SVA）が照合する、規則、値、範囲、計算結果の抽象的に定式化したもの。形式的な署名ポリシー、設定ファイル、あるいは SVA の処理に組み込まれたものとして定義できる。
署名対象データ（data to be signed）:署名されるデータ（例えば、文書や文書の部分）。注：署名対象データは、公開鍵暗号技術による署名処理の入力となる。署名対象データと署名属性を入力として与える方法の仕様は、署名フォーマットごとに標準規格で定義される。
駆動アプリケーション（Driving Application (DA)）:SVA と呼ばれる電子署名検証のためのアプリケーションに対して検証対象や制約情報を与えて検証を依頼するアプリケーション。SVA は DA に対して検証結果を返す。
署名ポリシー（signature policy）:署名の生成や検証のための規則の集合。これに基づいて、特定のトランザクションの文脈における署名の有効性が決定する。
署名検証（signature verification）:検証対象のデータに対して公開鍵暗号技術により、改ざんがないことを確認する処理。
署名有効性検証（signature validation）:署名の有効性を確認する処理。証明書の有効性検証や、署名検証を含め、署名がローカルなあるいは共通の署名ポリシーが要求することに従っているかどうかを総合的に確認することを含む処理。注：verification と validation の違い
・verification：正しいこと／事実であることを確かめる／実証する／検証すること
・validation：有効であること／妥当であることを認める／確認する／認証すること
署名検証アプリケーション（Signature Validation Application (SVA)）:本書に定義された署名有効性検証処理を実装したアプリケーション。注：署名有効性検証アプリケーションは、駆動アプリケーション（DA）との間で検証結果をやり取りする。
検証情報（validation data）:署名者や検証者によって収集された、署名の有効性検証に必要なデータ。注：証明書、失効情報（CRL や OCSP Response）、タイムスタンプなどを含む。
検証者（verifier）:署名の有効性検証や検証を行うエンティティ。
3.2 略語
BES 基本的な電子署名それ認証局
CRL 証明書失効リスト
DA 運転アプリケーション
EPES 明示的なポリシーベースの電子署名
LT 長期からアーカイブタイムスタンプ付きの長期
LTV 長期検証OCSPオンライン証明書ステータスプロトコル
OID オブジェクト識別子
PKIX Public Key Infrastructure using X. 509、IETF PKIX ワーキンググループ
RSA Rivest,Shamir,Adleman による公開鍵暗号方式全て署名検証アプリケーション
TSA タイムスタンプ機関
TSTタイムスタンプトークン
URI ユニフォームリソース識別子
4 デジタル署名
4.1 デジタル署名の概念モデル
4.1.1 デジタル署名の基本原理
紙文書や物理的な媒体における署名（サイン）や押印は、署名対象の作成者を示すとともに、署名対象が真正であることを示すためのものである。電子文書など電子データにおいても、その作成者（文責）と非改ざん性を証明するために、様々な電子署名方式が考案されている。中でも公開鍵暗号を用いたデジタル署名は、技術の整備と標準化が進み、最も普及している署名方式と言える。デジタル署名では、公開鍵暗号の署名鍵で生成した署名は、対となる検証鍵でのみ有効性を検証できる。また署名鍵を署名者のみが保有する秘密鍵（Private key:私有鍵とも呼ばれる）とすることで、他人が同じ鍵を生成できず、検証鍵を公開して公開鍵（Public key）とすることで、誰でも検証可能となる。つまり、秘密鍵を保有する人が署名したことと、検証結果により元のデータの改ざん有無が分かる。
図 4.1.1-1 公開鍵暗号による署名・検証なお、公開鍵暗号の一種である RSA 暗号の場合、署名処理として暗号化、検証処理として復号が行われる。
4.1.2 電子証明書と認証局、公開鍵基盤(PKI)
署名の本人性を確保する上での前提事項は以下の2点である。
１ 署名者本人以外が秘密鍵を使用できないこと
２公開鍵が、署名者の所有する秘密鍵とペアとなるものであることが担保できること
本人以外が使用できないことについては、一般的にはIC カードなどに格納して本人が適切に管理することにより実現される。その上で署名の本人性を担保するには、公開鍵が誰のものであるかを保証することが重要となる。“信頼できる第三者機関”（Trusted Third Party、以下 TTP）が公開鍵の所有者（ペアとなる秘密鍵の所有者）を保証するモデルが認証局モデルである。認証局（CA）は利用者（秘密鍵の所有者）の本人確認を実施した上で公開鍵の所有名義人であることを証明する公開鍵証明書の発行を行い、利用者と公開鍵の紐付けを保証する。公開鍵証明書には発行元の認証局のデジタル署名が付与され、一般的には電子証明書とも呼ばれる（本書では以下、証明書と記す）。
本人確認等を行い、利用者と鍵の紐付けを担う機能を取り出して登録局（RA）と呼ぶことがある。
図 4.1.2-1 認証局と公開鍵証明書
【コラム２】■電子署名の法的定義電子署名法（電子署名及び認証業務に関する法律（平成 12 年 5 月 31 日法律第百二号））2 条 1 項にて、「電子署名」は、以下のとおり規定されている。
―――「電子署名」とは、電磁的記録に記録することができる情報について行われる措置であって、次の要件のいずれにも該当するものをいう。
一 当該情報が当該措置を行った者の作成に係るものであることを示すためのものであること。
二 当該情報について改変が行われていないかどうかを確認することができるものであること。(一部省略)―――
つ まり、本人性が確認できること、及び、改ざん検知ができることが電子署名の要件となっている。従って、電子署名の有効性を検証する場合は、「本人性の確認」、「署名対象データの非改ざん性の確認」の2点を実施する必要がある。また、同法は、自然人を対象としており、電子署名に法的有効性を与えている(同 3 条)。
なお、同法による認定を受けた特定認証業務(認定認証業務とも呼ばれる)では証明書の有効期間は5年を超えないもの（同法、施行規則第6条）とされており、認定以外の認証業務においても、署名に用いる証明書の有効期間の基準とされている。なお、認証局同士が連携して信用関係を構築することがある。階層型の信用関係の場合、上位の認証局が下位の認証局の証明書を発行し、最上位の認証局（ルートCA）は自分で自分を証明する自己署名証明書を発行する。上位の認証局に証明される認証局は中間CA（IntermediateCA）と呼ばれる。
また、署名者は秘密鍵を安全に管理する必要があるが、秘密鍵の紛失や、秘密鍵の活性化に用いるパスワードの漏洩などにより、秘密鍵が危殆化（本人性の証明に使えなくなる状態）する可能性がある。その場合、署名者は認証局に失効申請を行い、これを受けた認証局は無効となった証明書のシリアル番号を記載した失効情報に認証局の電子署名を付与して開示する。この失効情報は証明書失効リスト（CRL：Certificate Revocation List)と呼ばれ、その更新頻度は失効した証明書の追加に合わせて実施される不定期な更新と、定期更新がある。
図 4.1.2-2 認証局の階層構造と公開鍵証明書
4.1.3 デジタル署名のメカニズムと基本要件
デジタル署名の署名データは、署名対象文書に対して、署名鍵を用いて署名アルゴリズムによる所定の署名処理を施したものである。RSA 署名の場合、署名対象文書に対して、ハッシュ関数にて演算実施、得られたハッシュ値を公開鍵暗号方式により署名者の秘密鍵を用いて暗号化したものとなる。
署名の有効性を検証する際は、署名データを署名者の公開鍵で検証処理を行う。RSA 署名の場合、公開鍵で復号して得られたハッシュ値と、署名対象文書からハッシュ演算をして得られるハッシュ値を比較し、双方のハッシュ値の一致を確認することにより、公開鍵と秘密鍵の紐付け、及び、署名対象文書が改ざんされていないことが確認できる。図 4.1.3-1 署名と署名検証（RSA 署名の場合）に RSA 署名のメカニズムを示す。
図 4.1.3-1 署名と署名検証（RSA 署名の場合）
また、署名を実施する際には、その目的に応じ、以下の要件に留意する必要がある。
（１）署名文書の利用用途に応じた適切な証明書を用いること
目的に応じて利用できる証明書の範囲（例、認定認証業務など）が示されている場合それに従うこと。認証局が開示する「証明書ポリシー」（Certificate Policy、以下 CP）に発行基準や用途が規定されているので、該当する認証局から署名者本人に対して発行された正当な証明書を利用する必要がある。
（2） 署名を実施する際に証明書の有効期間を越えていないこと
証明書の有効期間は発行時点に設定されているが、電子署名を実施する時点においてこの有効期間を越えていないことが必要となる。
（3） 失効していない証明書を用いること
署名時点で失効していない証明書の秘密鍵を用いる必要がある。
（4） 署名文書の利用期間を通じて、署名の正当性が確認可能であること。
法定保存期間等、署名文書の真正性の維持継続が必要な期間、署名の検証を可能とする必要がある（証明書の有効期間を越えて署名検証を行う場合は、後述の AdESフォーマットなどを採用する必要がある。）。
なお、署名に用いられるハッシュ関数や暗号アルゴリズムは、計算機関連の技術進化とともに解読のリスクが高まるため、署名の正当性確認を可能とするためには、より長い鍵、より強度の高いアルゴリズムに移行していかなければならない。
【コラム３】■署名の基本要件（4）の規定例
国税関係書類においては、電子帳簿保存法施行規則（第 3 条第 5 項第 2 号ロ(3)）にて定められ、同法取扱通達 4-26 にてその方法について解説されている。また、医療関係書類では、厚生労働省の「医療情報システムの安全管理に関するガイドライン第 5.1 版」6.12 節にて定められ、法定保存期間等の一定の期間、電子署名の検証が継続できる必要があるとされている。
4.1.4 署名データの形式
署名データは標準規格により、署名対象のデータとそのハッシュ値を暗号化した署名値及び各種パラメータ（属性）を含めて、下図の論理構成として規定されている。
図 4.1.4-1 署名データの論理構成
署名対象データと署名データは 1 つのファイルに統合して作成することもできるが、独立した 2 つのファイルとして作成することもできる。署名対象データと署名データの形式には、図4.1.4-2 に示されるように、以下の 3 つに大別でき、利用形態に応じて選択することができる。
図 4.1.4-2 署名対象データと署名データの形式
それぞれ、以下のような特徴がある。
（1）分離形式（Detached 型）署名対象データとは独立して、署名データを作成する形式。署名対象データの種別は問わず、あらゆるファイル形式に対して署名データが作成できる。既存アプリケーションで署名対象データを取り扱っている場合など、アプリケーション側への影響が少なくて済む。一方、署名対象データと署名データを紐付けて管理する必要がある。
（2） 包含形式（Enveloped 型）署名データの中に署名対象データを格納（内包）して作成する形式。署名対象ファイルと署名データが 1 つのファイルとなるので扱いやすい。一方、アプリケーションなどで署名対象データを利用する場合、署名データから、署名対象データを取り出す必要がある。
（3）付属フォーム（エンベロープタイプ）
署名データが署名対象データの中に含まれる（包含）形で作成する形式。(2)と同様に 1 つのファイルを管理すればよいので扱いが容易。一方で、署名対象データのファイル形式が、電子署名をサポートしていることが必要となり、作成できるファイル形式には制限がある（例：PDFやXML など。）。
4.2 時刻の保証と長期署名フォーマット
4.2.1 時刻情報とタイムスタンプ局
署名の要件として、署名時点での証明書の有効性が問われることとなるが、そのためには署名時刻等を保証する客観的な時刻情報が必要となる。署名を生成するコンピュータの時刻情報を使用すると、故意か否かに関わらず、正確性が保証されない。この役割を担う信頼できる第三者機関（TTP）がタイムスタンプ局（Time Stamp Authority：TSA）である。電子文書に正確な時刻情報を含むタイムスタンプトークン（TST）を付与することにより、タイムスタンプ時刻以前からその電子文書が存在していたことと、それ以降、改ざんされていないことが証明可能となる。
図 4.2.1-1 タイムスタンプ局の概要（デジタル署名方式(RFC3161)の場合）
4.2.2 長期的な署名の担保と署名の延長
鍵や証明書には有効期間があり、法定保存期間が定められた文書を保存する場合など、有効期間を越えて、署名検証が可能であることが必要となる。その際、特に「証明書検証の継続性」に対して留意する必要がある。また通常、認証局は証明書の有効期間を越えて失効情報を公開しないことが多い。すなわち、失効情報には失効した証明書のシリアル番号が記載されているが、多くの認証局では失効情報の肥大化をさけるため、失効した証明書の有効期間が過ぎるとそれらのシリアル番号は失効情報から消去される。従って、証明書の有効期間を越えて証明書の有効性の確認ができないことがある。従って、署名検証を継続する必要がある場合は、失効情報を確保しておく必要がある。このような問題を解決するために、電子署名の有効性を証明書の有効期間や失効、さらに、署名に用いた暗号アルゴリズムが脆弱化した後も維持できる署名規格として、AdES (先進電子署名)がある。このフォーマットに示されるように、証明書検証に必要な失効情報等のデータを合わせて保存し、タイムスタンプを付与することが有効である。その手順の概要は、以下となる。
（1） 署名対象データ全体に対して電子署名を付与
（2） 署名直後にタイムスタンプ(署名タイムスタンプ)を付与し、署名時刻を特定しておく
（3） 証明書検証に必要となる、以下の検証情報を収集格納する。なお、証明書チェーン上の認証局は、署名者の証明書を発行する認証局とタイムスタンプ局に証明書を発行する認証局の 2 つの認証ドメインにおける全ての認証局となることに留意されたい。
・タイムスタンプ局の証明書・署名者の証明書
・証明書チェーン上の認証局の証明書
・上記全ての認証局の失効情報
（4） 上記の署名対象文書や署名値、検証情報全体に対してタイムスタンプ（アーカイブタイムスタンプ）を付与
図 4.2.2-1 長期署名フォーマットによる署名延長に上記手順のフローイメージを示す。ここで、各タイムスタンプの役割は、以下である。
・ 署名タイムスタンプ
署名が存在した時刻を特定可能にするために、署名値に付与されるタイムスタンプ
・ アーカイブタイムスタンプ
暗号アルゴリズムの危殆化、認証局の変更、証明書の期限切れや失効があったとしても将来検証できるように、署名対象及び検証情報を包括的に保護するためのタイムスタンプ。署名の検証可能な期間を延長するために使用する。
・ コンテントタイムスタンプ(オプション)
署名対象データそのものに対して、オプションで付与可能なタイムスタンプ。署名タイムスタンプは、署名時点以降の署名対象データの存在証明となるが、コンテントタイムスタンプは署名タイムスタンプより前に行い、署名対象データが「いつから」存在したのかを示すことができる。
・ ドキュメントタイムスタンプ
PAdES に用いることができる DocTimeStamp で指定される汎用的なタイムスタンプのための PDF フィールドであり、PDF 文書に対してデジタル署名をせずに直接行うタイムスタンプ、署名タイムスタンプ、アーカイブタイムスタンプの 3 つの用途に用いることができる。どの用途であるかは、データのコンテキストで判断する必要がある。PAdES では、署名と署名タイムスタンプを CAdES-T 形式でも与えることができ、その場合は、署名タイムスタンプ用途のドキュメントタイムスタンプは使用しない。
図 4.2.2-1 長期署名フォーマットによる署名延長
署名検証に必要となる情報には、署名対象データと署名値以外に、関連する証明書や失効情報、また、署名文書の利用目的に応じたトラストアンカーの制限や暗号アルゴリズムの有効性に関する情報などの様々な情報が必要となる。これら、署名検証に必要となる前提条件のことを、検証制約（Validation constraints）と呼び、以下のようなものが挙げられる（5.2 参照）。
・ 署名文書の利用目的に合致した証明書を発行する認証局のトラストアンカー
・ 証明書パスに含まれる全ての証明書、証明書の利用用途などの制約
・ 失効情報
・ タイムスタンプ
・ 検証基準時刻
・ 有効と認められる暗号アルゴリズムの制約
・ 署名データを構成する要素に対する制約
4.2.3 AdES フォーマット
AdES では前述のとおり、署名の後、署名時刻を確定するため署名タイムスタンプを付し、その後、署名及びタイムスタンプが失効していないことを示す検証情報を付加し、期限切れ等で失効する前にアーカイブ用のタイムスタンプを付す。さらに期限切れ等が発生する前に、検証情報を付加してアーカイブタイムスタンプを重ねるライフサイクルとなる。
図 4.2.3-1 署名データのライフサイクル
各フェーズにおけるデータフォーマットの論理的な構成は以下のとおりである。
- 署名者による署名を付した署名データ（AdES-BES）
図 4.2.3-2 署名者による署名（AdES-BES）
(２)署名タイムスタンプを付した署名データ（AdES-T）
図 4.2.3-3 署名タイムスタンプ付き署名（AdES-T）
（３）検証情報を付加した署名データ（AdES-X-Long）
図 4.2.3-4 検証情報付き署名（AdES-X-Long）
AdES-X-Long はアーカイブタイムスタンプを付与する前段として、必要な検証情報が付与された状態である。ここでAdES-X-Long の検証情報は、タイムスタンプを付していないデータのため、改ざんの危険性がある。通常は、速やかにアーカイブタイムスタンプを付与するか、用途に従った処理を行うことになる。
【コラム４】■電子処方箋における AdES-X-Long の利用
2 018 年 7 月に厚労省から公開された「電子処方箋 CDA 記述仕様 第１版（平成 30 年7 月）」に基づき、JAHIS（一般社団法人保健医療福祉情報システム工業会）では電子処方箋実装ガイドを定めている。その規約においては、処方を行った医師が電子処方箋に署名を付与した後、処方箋と医師の署名の両者を署名対象に含めた文書全体に対して調剤を行った薬剤師が署名を付与することとしている。この際、医師の署名を XAdES-X-Long の形式とした上で薬剤師が署名を付すことにより、医師の署名の検証情報を保存可能としている。
(4) アーカイブ用のタイムスタンプを付した署名データ（AdES-A）
(5) 2 回目のアーカイブ用タイムスタンプを付した署名データ（AdES-A）
また、AdES フォーマットは、署名対象ファイル種別に応じて以下の種類が規定されている。
■CadES
汎用的な署名ファイル形式であるCMS（Cryptographic Message Syntax）をベースとしたAdES。署名対象データのファイルの形式は限定されないため、広く様々なファイルへ電子署名を付与できる。分離形式、内包形式の電子署名に用いられる。
■XAdESXML
ファイルを対象とした電子署名形式であるXML署名をベースとするAdES。分離形式、内包形式、包含形式の全てに用いることができる。
■PAdESPDF
ファイルの内部構造の中へ署名データを埋め込む包含形式のAdES。署名対象ファイルはPDF 形式に限定されるが、署名された PDF ファイルを単独で扱うことができ、Adobe®Reader®でも検証できる利点がある。
5 デジタル署名の検証
5.1 署名検証の概念モデル
5.1.1 署名検証の基本要件
署名検証の基本要件は、署名の基本要件に対応して、署名の本人性と非改ざん性を確認することとなる。前者は「証明書検証」、後者は「署名値の検証」と定義され、前者は署名の基本要件である（1）～（4）を適切に確認し、後者は署名対象データの署名値を公開鍵で検証処理することで確認する。ここで署名検証はデジタル署名を付与し、一定期間経過した後に行われる行為であることに着目してみると、いつ時点における署名の有効性を確認するのかその時刻の設定によっては、証明書の失効や暗号アルゴリズムの脆弱化などの要因により、検証結果に影響を及ぼすことが考えられる。
いつ時点における署名の有効性を検証するのか、本書ではその時刻を「検証基準時刻（validation reference time）」と定義している（5.2.7 参照）。例えば本来の署名検証の目的は署名時点における電子署名の有効性を確認することにあるので、検証基準時刻は“署名を付与した時点”とすることが理想であるが、通常、署名を付与した時刻を客観的に証明することができない。そこで、検証基準時刻はタイムスタンプを併用するなどによる客観的な署名の時刻となり、それが確認できない場合は、署名検証を実施する現在時刻となる。
証明書検証に際しては電子署名の基本要件で述べた以下の 4 点を確認することになる。
（1） 署名文書の利用用途に応じた適切な証明書を用いていたこと
（2） 署名当時に証明書の有効期間が切れていなかったこと
（3） 失効していない証明書を用いて署名していたこと
（4） 署名文書の利用期間を通じて、上記（1）～（3）が確認可能であること。図 5.1.1-1 では、(1)から(3)を図示しているが、(1)及び、(2)に関して、署名時刻がいつであったのか客観的に示すためにタイムスタンプが利用されること、また署名時点での証明書の有効性を確認するために失効情報が保管されることが必要である。
5.1.2 検証のアプリケーションモデル
署名データの検証処理の実装には、PCやデバイス等で実行されるグラフィカルユーザインタフェースを備えたソフトウェアや、コマンドラインツール、他のアプリケーションに組み込まれるライブラリやミドルウェア、WebアプリケーションやWeb サービスなど様々な方法が考えられる。そのような様々な実装を概念的なモデルとして表現するために、この規格では駆動アプリケーション（DA：Driving Application）と署名検証アプリケーション（SVA：SignatureValidation Application）に分けて考える（図 5.1.2-1）。
署名検証アプリケーションとは、入力された署名データの検証を行い、署名データの判定結果やレポート内容を出力するモジュールのことを言う。署名検証アプリケーションは、駆動アプリケーションから入力された署名データを検証し、検証レポートを駆動アプリケーションに返す。駆動アプリケーションは検証レポートに基づいて検証者に検証結果の表示を行う。ソフトウェアの構成によっては駆動アプリケーションと署名検証アプリケーションが一体となっている場合もある。本書では署名検証アプリケーションが実行すべき署名データの検証項目に関する要件を定めるものとする。
図 5.1.2-1 署名検証アプリケーションの概念モデル
検証レポートには署名データの判定結果や詳細なレポート内容が含まれる。検証制約は署名検証アプリケーションが署名データの有効性を判断するときの条件を示すものである。検証制約には、例えば、検証者が信頼するトラストアンカー、証明書の検証情報（中間CA証明書や失効情報）、証明書ポリシーや暗号制約などがある。検証制約は駆動アプリケーションを介して検証者が設定できる場合や、署名ポリシー等の記述に従い駆動アプリケーションが署名検証アプリケーションに入力する場合や、署名検証アプリケーションや駆動アプリケーションのコードに組み込まれている場合もある。証明書の検証情報については検証処理の実行時にオンラインで取得する場合もある。
5.1.3 署名判定結果の概念モデル
署名データの判定結果には以下の種類がある。
● VALID (有効)
署名者による署名やタイムスタンプの対象となったデータの改ざんがなく、かつ、署名者やタイムスタンプを発行したタイムスタンプ局の身元が信頼できると判断された状態。検証すべき項目の全てがVALID であるとき、署名データ全体をVALID と判定する。VALID である署名データは少なくとも以下の全ての内容を満たしている。
➢ 署名者による署名やタイムスタンプのハッシュ値や署名値が正しく検証できること。
➢ 署名者の証明書やタイムスタンプ局の証明書が信頼できること。例えば、信頼する認証局から発行されていることや、有効期間内にあること、失効されていないこと等。
● INVALID (無効)
検証すべき項目のうち少なくとも1 つが INVALID と判断された場合、署名データ全体をINVALID と判定する。
● INDETERMINATE (未確定)
入手された情報による設定では VALID もしくはINVALIDと判定するには不十分である。例えば、署名検証アプリケーションの実行時に検証に必要な失効情報を入手できず、証明書の失効状態を確認することができなかった場合には、INDETERMINATE として判定される。INDETERMINATE と判定された署名データは、他の証拠となる情報と照らし合わせた場合に、VALID もしくは INVALID として判定することもできる。
なお、検証すべき項目に１つでも INVALID があれば、全体として INVALIDであり、処理を終了できる。しかし、他にも INVALIDの項目が存在する可能性があり、どこに問題があったかを知ることは検証として有用なことがあるため、検証処理を継続することは意味がある。逆にINVALID の結果からは、他にINVALID の項目がなかったのか、処理を打ち切ったかが分からないため、どちらの実装であるかを供給者の適合宣言書に記して、明確にすべきである。
5.1.4 要求レベル（必須とオプション）の考え方
本書における検証要件のレベルを以下のように定める。検証要件には、電子署名としてセキュリティを担保するために制約条件の違いなどに依存せず最低限実行しなければならないもの、用途に依存するがセキュリティを担保するためには意味があるもの、用途に依存して実行要否を決定するものに分けられ、それぞれのフィールドを、必須、存在時必須、オプションと規定する。各々の処理方法は以下とする。
・ 必須[M（Mandatory）]
この検証項目は必ず実行しなければならない。この検証項目に必要なフィールドが署名データに存在しない場合には INVALID と判定する。
・存在時必須[E（存在する場合は必須）]の場合に存在する必要があります該当するフィールドが署名データに存在する場合には、この検証項目は必ず実行しなければならない。該当するフィールドが存在しない場合には、この検証項目をスキップしてよい。
・オプション [O（Optional）]
この検証項目を実行するか否かはアプリケーションの要件に依存する。なお、後述の署名データの構成要素におけるM（Mandatory）/O（Optional）は、署名生成時の選択基準である（PAdES の場合は、禁止[P（Prohibited）]もある）。
また、本書の規定を基にして、さらに用途を限定したプロファイルを策定する場合、[Optional]の検証項目を[Mandatory if Exists] 又は[Mandatory]に、[Mandatory if Exists]の検証項目を[Mandatory]に再定義することは可能とする。しかし、[Mandatory]もしくは[Mandatory if Exists]の項目はセキュリティを担保するために必要な項目であり、これらを検証しない実装は供給者の適合宣言書に記して、その制約を明確にする必要がある。
5.2 検証プロセス
5.2.1 検証プロセスの考え方
検証は、前述のとおり、署名値の検証（非改ざん性の確認）、証明書の検証（本人性の確認）、及びそれらが署名生成されてからの使用期間中、有効であったことの確認をすることである。署名の延長を考慮すると、AdESの各フォーマットに対応する必要がある。フォーマットの詳細と準拠する規約を5.3 に示す。署名を延長した場合は、検証の基準となる時刻が重要であり、各フォーマットにおける検証基準時刻の考え方を5.4に示す。検証にあたっては、署名データの要素として、署名、タイムスタンプ、証明書を検証することになる。署名について5.5 に、タイムスタンプについて5.6に、証明書について5.7に示す。
図 5.2.1-1 署名検証プロセス
なお、実際の利用用途に応じて、署名の使い方や扱いに制約を加えることがあり、検証もその制約に対応して行う必要がある。その場合、署名検証アプリケーションには、検証対象となる署名データ（署名対象のコンテンツを含む）だけでなく、外部からの情報を参照する必要がある場合がある。また、署名利用分野の必要に応じて検証結果を規約で定める規定値と異なる値としたい場合、差分を制約条件として与えることが考えられる。これらの情報を総称して検証制約と呼ぶ。検証制約の与え方としては次の方法が考えられる。
– 署名ポリシー（[i.2][i.3][i.4]準拠）
– 設定ファイル（独自形式）
– 実装ロジックへの埋め込み
次項以降に検証制約とその関連情報を示す。
5.2.2 トラストアンカー署名
データに検証情報としてルート証明書が含まれる場合がある。ところが、署名データに含まれていることを根拠にルート証明書を署名（タイムスタンプ、失効情報を含む）検証時に信頼できると、あるいは過去の署名生成時に信頼していたと判断することはできない。従って、信頼点については現在のもの／過去のものを問わず、検証処理に外部から与える必要がある。なお、欧州では認証局や各種サービスの情報を公的に一覧として整備し、確認できるようにした Trusted List がある。
5.2.3 証明書
署名データにトラストアンカーにいたる認証パス上の証明書のセットが含まれる場合とそうでない場合がある。含まれない場合、署名検証アプリケーションに外部から与える必要がある。認証パスが複数存在する場合、通るべきパスに制限を加える必要がある場合がある。このような場合、検証処理に外部から制約条件を与える必要がある。また、証明書内の要素に対して既定値ではオプショナルなものを検証する必要がある場合や、その要素の値がある条件を満たす必要がある場合がある。このような場合も、それらの条件を検証処理に外部から制約として与える必要がある。
5.2.4 失効情報
有効期限が切れていない証明書の失効状態を確認するために、失効情報を署名検証アプリケーションに外部から与える必要がある。署名データ（タイムスタンプ含む）に検証情報として失効情報が含まれる場合があり、それが対象となる署名データ（タイムスタンプ含む）の失効情報として適切なとき（検証基準時刻の観点から適切なタイミングに発行されているとき）にはそれを利用することができる。適切な（すなわち、検証に利用が許容される）タイミングとしては、署名やタイムスタンプ生成後、猶予期間を経ていること、次のタイムスタンプ付与又は検証の時点で、失効情報の発行周期以内で最も新しい（鮮度が高い）ものであることが求められる（詳細は 5.4 を参照）。なお、実際には、ルートCA や中間CAの失効情報、OCSPのタイミングなど、状況に応じて考慮が必要となる。
5.2.5 暗号アルゴリズムの脆弱性に関する情報
署名データ（証明書、失効情報、タイムスタンプ等を含む）の生成には各種暗号アルゴリズムが用いられ、その種別はOID等で署名データに含まれる。ところが、各暗号アルゴリズムが利用された時点で脆弱でなかったことを示す根拠は署名データには含まれない。従って、各暗号アルゴリズムが利用された時点で脆弱でなかったことを確認するためには外部の情報を参照する必要がある。実際には、暗号アルゴリズムの利用箇所は多岐にわたるとともに、その安全性の基準等が明確でないため、何らかの制約を設けない限り確認は困難となる。その課題と解決策案は「付属書 C」に述べる。
5.2.6 タイムスタンプ
適用領域や法制度の要請等により、信頼すべきタイムスタンプを選別する必要がある場合がある。信頼すべきタイムスタンプであるか否かを判断するために、タイムスタンプトークンに含まれるタイムスタンプポリシー、発行者、信頼点、精度等の要素に関する制約を外部から与える必要がある場合がある。
5.2.7 検証基準時刻（validation reference time）
証明書の有効性や暗号アルゴリズムの非脆弱性を判断する際に基準とする時刻（検証基準時刻と呼ぶ）は検証対象により適切に選ぶ必要がある。対象となる証明書についての検証基準時刻は、その証明書をタイムスタンプ対象（MessageImprint）の計算対象に含む有効なタイムスタンプトークンのうち、最も古いものの示す時刻であり、該当するタイムスタンプがない場合、検証処理を実行する時刻となり、検証処理に外部から与える必要がある。また、暗号アルゴリズムについての検証基準時刻は、対象となる暗号アルゴリズムにより計算された結果を MessageImprint の計算対象に含む有効なタイムスタンプトークンのうち、最も古いものの示す時刻であり、該当するタイムスタンプがない場合、検証処理を実行する時刻となり、検証処理に外部から与える必要がある。検証基準時刻における検証の考え方を整理すると、以下となる。
• 署名、コンテントタイムスタンプ
・ 署名タイムスタンプがなければ現在時刻で検証
・ 署名タイムスタンプがあればその時刻で検証
• 署名タイムスタンプ
・ アーカイブタイムスタンプがなければ現在時刻で検証
・ アーカイブタイムスタンプがあれば最も古いアーカイブタイムスタンプの時刻で検証• アーカイブタイムスタンプ群・ 自分より新しいアーカイブタイムスタンプがなければ、現在時刻でそのアーカイブタイムスタンプを検証
・自分より新しいアーカイブタイムスタンプがあれば、その直後のアーカイブタイムスタンプの時刻で検証
5.2.8 署名要素に対する制約
適用領域や法制度等の要請により、署名データを構成する各種要素について、規約において検証必須として規定されている要素の検証を不要としたり、逆に検証オプションとして規定されている要素の検証を必須としたりする場合がある。このようなときに外部より検証制約としてそれらの条件を指定することができる。ただし、本書で必須と規定している要素の検証を不要とすることは、安全性の観点から望ましくない。
5.3 検証データの全体構造
この節では署名データの各形式における論理的な構成と各要素の検証方法が記述された節への参照関係について述べる。
5.3.1署名者による署名(AdES-BES)
署名者による署名（AdES-BES）は署名者による署名のみが付与された基本的な形式である。AdES-BES の論理的な構造と、検証要件の各節との関係を図 5.3.1-1 に示す。AdES-BES の仕様が記述された各規格の一覧を表 5.3.1-1 に示す。
5.3.2 署名タイムスタンプ付き署名(AdES-T)
署名タイムスタンプ付き署名（AdES-T）は署名者による署名(AdES-BES) とともに署名タイムスタンプを付与した形式である。AdES-T の論理的な構造と、検証要件の各節との関係を図5.3.2-1に示す。AdES-T の仕様が記述された各規格の一覧を表5.3.2-1に示す。
5.3.3 検証情報付き署名(AdES-X-Long)
検証情報付き署名（AdES-X-Long）は、署名タイムスタンプ付き署名（AdES-T）に検証情報を格納した形式である。検証情報（証明書チェーン、OCSP レスポンス及びCRL 等）を格納することにより、認証局が存在しなくなったとしても検証情報付き署名単独で署名や署名タイムスタンプの検証を行うことができる。AdES-X-Long 論理的な構造と、検証要件の各節との関係を図5.3.3-1 に示す。AdES-X-Longの仕様が記述された各規格の一覧を表5.3.3-1に示す。
5.3.4 アーカイブ付き署名(AdES-A)
アーカイブ付き署名(AdES-A)は検証情報付き署名（AdES-X-Long）にアーカイブ用のタイムスタンプ(アーカイブタイムスタンプ、LongTermValidation タイムスタンプ、ドキュメントタイムスタンプ)を格納した形式である。AdES-A の論理的な構造と、検証要件の各節との関係を図5.3.4-1 に示す。AdES-A の仕様が記述された各規格の一覧を表5.3.4-1 に示す。
5.4 検証基準時刻と検証の観点
署名データの有効性を判断する場合、署名やタイムスタンプ、証明書などの有効性を確認するときの基準となる時刻（検証基準時刻）が重要である。特に、長期保存の場合には複数のタイムスタンプが用いられていることで時刻の関係が複雑となり、不適切な検証基準時刻での検証を行った場合には、不正に生成された署名データを受け入れてしまう危険性もある。この節では、検証対象と検証基準時刻の関係を示す。
5.4.1 AdES-BES 検証における検証基準時刻と検証の観点
AdES-BES の生成プロセスと検証プロセスの関係を図5.4.1-1図5.4.1-1 に示す。図 5.4.1-1の時間軸に沿って生成プロセスと生成されるデータ、検証プロセスを示している。AdES-BESでは署名生成時刻が保証されないため、検証者が検証を行う時刻に基づき有効性を判断する。AdES-BES 検証における検証基準時刻の考え方と有効性を判断すべき項目を表5.4.1-1に示す。
5.4.2 AdES-T 検証における検証基準時刻と検証の観点
AdES-T の生成プロセスと検証プロセスの関係を図 5.4.2-1 に示す。図 5.4.2-1 の時間軸に沿って生成プロセスと生成されるデータ、検証プロセスを示している。AdES-T 検証における検証基準時刻の考え方と有効性を判断すべき項目を表 5.4.2-1 に示す。
5.4.3 AdES-X-Long 検証における検証基準時刻と検証の観点
AdES-X-Long の生成プロセスと検証プロセスの関係を図 5.4.2-1 に示す。図 5.4.2-1 の時間軸に沿って生成プロセスと生成されるデータ、検証プロセスを示している。AdES-X-Long 検証における検証基準時刻の考え方と有効性を判断すべき項目を表 5.4.2-1 に示す。AdES-X-Long は署名データ内に格納された証明書や失効情報を用いて検証を行うことができる。AdES-X-Long は署名タイムスタンプ付き署名(AdES-T)の検証基準時刻と同様に考える。なお、生成から時間が経過し、格納された検証情報の改ざんの危険性がある場合にはこれをアーカイブ付き署名等に利用することはできない。
5.4.4 AdES-A検証における検証基準時刻と検証の観点
5.5 署名の検証要件
もしES がアーカイブ情報を有している場合には、検証基準時刻として最も古いタイムスタンプ時刻を利用する。それ以外の場合には、検証基準時刻として有効な検証時刻又は現在時刻を利用する。詳しくは 5.4 を参照。
5.5.1 アルゴリズムの有効性の確認
検証制約により、検証基準時刻において利用している暗号アルゴリズムの脆弱性が見つかっておらず有効であることを確認する。
5.5.2 CAdES の検証要件
CAdES 署名は、検証基準時刻において次の検証要件に従い検証する。
5.5.3 XAdES の検証要件
XAdES 署名は、検証基準時刻において次の検証要件に従い検証する。
【コラム５】■XAdES バージョン定義と規格
XAdESのバージョンは XML 名前空間（namespace）で指定され、その定義は ETSI TS 101903 となる。2002 年 2 月に ETSI TS 101 903 V1.1.1が公開された後で、V1.2.2、V1.3.2、V1.4.1 と合計 4 つのバージョンがある。このうちV1.1.1とV1.2.2は、V1.3.2 以降との互換性が無い為に利用してはいけない。V1.4.1は V1.3.2 がベースとなり、追加要素を加えたものである。その為に V1.4.1を利用する場合に正確にはV1.4.1＋V1.3.2の要素が必要となる。ETSI TS101903 以外の規格ではどのXAdES バージョンを利用しているかをよく理解して利用する必要がある。特にW3C NoteはV1.1.1のままであり使ってはいけない。ETSI EN319 132-1 V1.1.0 (2016-04) がETSI 最新の仕様ではあるが、XAdES バージョンとしてはV1.4.1である。
【コラム６】■XAdESのSigningCertificate要素とSigningCertificateV2 要素
XAdESのSigningCertificateV2 要素は ETSI EN 319 132-1 V1.1.0 (2016-04) から追加された新しい要素であるが名前空間は V1.3.2 となっている。これは SigningCertificateV2要素が、ETSI TS 101 903 V1.3.2 (2006-03) で定義されていた SigningCertificate 要素をそのまま置き換える目的の為に追加された要素であるからである。従来の IssuerSerial 要素下の X509IssuerName 要素では、署名証明書（X.509バイナリ）のIssuer 部からテキスト形式（RFC 2253 準拠）に変換した識別名を利用していた。しかしながら色々な事情がありこの識別名が一意にならない問題があった。この為にSigningCertificate/IssuerSerial/X509IssuerName を使った検証を行わない検証器がほとんどであった。SigningCertificateV2 要素では新たに IssuerSerialV2 要素として、Issuer と Serial を、署名証明書（X.509 バイナリ）からバイナリ（ASN.1/DER）のまま抜き出して結合する方式となった。これにより SigningCertificateV2 要素を使うことで Issuer（発行者）名が一意となるので間違いなく検証が出来るようになった。以上から過去互換性の為に SigningCertificate 要素を使い続けることに問題は無いが、新しく実装する場合には SigningCertificateV2 要素が推奨される。
【コラム７】■PDF バージョンと電子署名
PDFのバージョンは現在1.0～2.0までが存在する。1.0～1.7までは Adobe 社が策定して仕様公開していたがその後 ISO に移管され、ISO 32000-1 で PDF1.7が正式仕様となり、ISO32000-2でPDF2.0が正式仕様となった。なお PDF 電子署名の仕様は PDF1.3 で追加された。PDF ファイルではファイルの先頭に PDF バージョンが埋め込まれているが、残念ながらファイル本体の仕様と一致しない場合が多い。PAdES 仕様は PDF2.0（ISO 32000-2）で追加されたが、ファイルの先頭で宣言されるバージョンは PDF1.7 以前の場合もあるが、これは検証エラーの対象とはならない。PAdES 仕様が ETSI で定義された時には、PDF1.7（ISO 32000-1）をベースとして PAdES 用の新しい仕様を追加したものとなっている。ETSI TS 102 778-1 V1.1.1 と ETSI EN 319142-1 V1.1.1 はいずれもPDF1.7プラス PAdES 仕様となっている。その後 PDF2.0（ISO 32000-2）が発行された時に PAdES 仕様も PDF2.0 として吸収された。
5.6 タイムスタンプの検証要件
5.6.1 タイムスタンプ
タイムスタンプは、次の検証要件に従い検証する。ここに示す検証要件は、RFC 5280 X.509証明書インターネットプロファイル、RFC 5652 CMS、RFC 3161 タイムスタンププロトコルに準じた検証内容であり、本書に固有の検証要件はない。
5.6.2 署名タイムスタンプ
(1) 署名タイムスタンプの検証基準時刻
もし電子署名がアーカイブ情報を有している場合には、検証基準時刻として最も古いタイムスタンプ時刻を利用する。それ以外の場合には、検証基準時刻として有効な検証時刻又は現在時刻を利用する。詳しくは 5.4 を参照。
- 署名タイムスタンプの検証要件
署名タイムスタンプを、検証基準時刻において次の検証要件に従い検証する。
5.6.4 ドキュメントタイムスタンプ
ドキュメントタイムスタンプは PDF のようなドキュメントに対してタイムスタンプのみを署名とは別に付与する方式のタイムスタンプである。執筆時点においてはPAdESの DocTimeStamp（PAdES-DT）仕様のみとなる。PAdES の DocTimeStamp は、PAdES-T や PAdES-A では署名タイムスタンプ的にもアーカイブタイムスタンプ的としても利用が可能である。ここでは署名抜きでドキュメントタイムスタンプを利用する PAdES-DT 仕様（ISO 14533-3 Annex B.2）について解説する。PAdES-DT 仕様も長期署名化（LTA 化）による有効期限の延長が可能となっている。CAdES 署名の代わりに DocTimeStamp のみを指定した後で、DSS/VRI 辞書とアーカイブタイムスタンプとしての DocTimeStamp を追加することで長期署名化が可能となる。DocTimeStamp 署名辞書とDSS/VRI 辞書に関しては「5.5.4 PAdES の検証要件」を参照。
5.7 証明書の検証要件
署名やタイムスタンプの検証では署名値の検証で利用する証明書の検証を行う必要がある。証明書を検証するには、トラストアンカーとなるルート証明書までの証明書パスを辿り、有効期限、失効確認、証明書や CRL の拡張領域などを確認する必要がある。また、それらを確認するときに利用する検証基準時刻は署名フォーマット形式（AdES-BES、AdES-T、AdES-A）ごとに異なり、署名者証明書、TSA 証明書それぞれにおける検証要件も異なる。なお、署名者証明書及び TSA 証明書の検証で利用する情報は次のとおりである。
・ 署名者証明書もしくはTSA証明書
・トラストアンカーを含む証明書及び失効情報のセット
・制約条件
以下に、証明書検証の検証要件及び検証基準時刻について署名フォーマット形式ごとに解説する。本節で用いる記号の意味は以下のとおりである。
Tv：検証処理を実行した時刻
Ts：署名タイムスタンプの時刻
Ta(k)：第 k 世代のアーカイブ（ドキュメント）タイムスタンプの時刻
5.7.1 AdES-BES における証明書
