Re:ゼロから始める長期署名

#はじめに
長期署名（先進電子署名）と言えば今から10～15年程前に最初のブームがありましたがベンダーの期待に反してあまり注目されたと言うイメージがありません。ところが新型コロナの影響だと思いますが最近具体的に長期署名を使いたいと言うご相談を多く受けるようになりました。しかし長期署名について今更説明している最近の書籍や情報が無く、また10年経つと電子署名業界での見方も微妙にアップデートされていて色々分からないとのこと…と言うことで…

「ここから始めましょう。イチから…いいえゼロから！」 by レム

え～と私ですが一応ISO等で長期署名関連仕様の標準化にも携わりつつ、自社製品として長期署名ライブラリの開発もしているプログラマです。では始めましょう。

#目次
はじめに
1. 長期署名とは
1-1. 電子証明書の有効期限
1-2. 暗号アルゴリズムの危殆化
1-3. 長期だけじゃ無い先進電子署名
1-4. まとめ：長期署名は何故必要
2. 長期署名レベルと作成手順
2-1. AdES-BES：デジタル署名のみ
2-2. AdES-T：署名タイムスタンプ追加
2-3. AdES-X-Long：検証情報の埋め込み
2-4. AdES-A：保管タイムスタンプ追加（延長）
3. 長期署名フォーマットの種類
3-1. PAdES：PDF長期署名フォーマット
3-2. XAdES：XML長期署名フォーマット
3-3. CAdES：CMS長期署名フォーマット
3-4. JAdES：JSON長期署名フォーマット
3-5. ASiC：ZIP長期署名コンテナ
4. FAQ：長期署名のよくある質問
4-1. 有効期限が切れた署名は無効ですか？
4-2. 欧州eIDASとの相互運用性はありますか？
おわりに

##1. 長期署名とは

最初に説明抜きで長期署名を利用する目的を2つ挙げておきます。他にもメリットがありますが大きくはこの2つが利用する為の主目的でしょう。

• 電子証明書の有効期限後も電子署名の有効性を延長して保証する。
• 暗号アルゴリズム危殆化後も電子署名の有効性を延長して保証する。

どちらも有効性保証の「延長」が関係しています。つまり電子署名の有効性を長期間にわたり延長して保証することができる署名フォーマット（データ書式）が「長期署名」と言うわけです。これまでも電子署名として、XML署名/CMS（PKCS#7）署名/PDF署名等の署名フォーマットが存在していましたが、これらは長期署名ではありませんでした。これら既存の電子署名を拡張することで長期署名の仕様が策定されました。長期署名はXAdES(XML)/CAdES(CMS)/PAdES(PDF)等の長期署名フォーマットとして、欧州の標準化団体であるETSIにより標準化されました。

###1-1. 電子証明書の有効期限

**「電子証明書の有効期限」**とはどういう意味でしょうか。電子証明書の信頼性を保証する技術としてデジタル署名とPKI（公開鍵基盤）がありますが、後述する暗号アルゴリズム危殆化の問題があるので無限に有効な電子証明書の発行はそもそも不可能と言う理由がまずあります。また電子証明書に紐づいた署名鍵（秘密鍵）を所有者（自然人）が管理する場合に紛失や盗難の可能性がありリスク的に長期間の保証をするよりも短期間で署名鍵を更新した方が良いと言う理由もあります。以上から電子証明書（X.509）には有効期限が設定されます。自然人に発行される電子証明書の有効期間は1～数年程度であることが多いです。一方でサーバ上の安全な署名鍵管理ハードウェア（HSM）により署名鍵の盗難の恐れが無い場合（例：タイムスタンプサービス用のTSA証明書）は10年以上の有効期間の電子証明書も発行されます。

さて電子証明書には失効と言う仕組みがあります。有効期限の前であっても失効した電子証明書は無効となり使うことができなくなります。失効理由には紛失・盗難・記載属性変更等があります。電子証明書を発行した認証局（CA）は、技術的にはCRL（RFC 5280）とOCSP（RFC 6960）と言う2つの方法で検証者に電子証明書の失効有無を知らせます。

• CRL：失効リスト公開 / Certificate Revocation List
• 失効した電子証明書のリストをWebやLDAPで公開
• OCSP：ステータス問合せ / Online Certificate Status Protocol
• 電子証明書のステータスをHTTPリクエストで取得

多くの認証局では、失効情報（CRL/OCSP）は電子証明書の有効期間内のみ提供されます。長期間の保証をする為には署名時刻において電子証明書が失効していなかったと言う情報（CRL/OCSP）を有効期間内に保存しておく必要があります。長期署名ではCRL/OCSPに加えてトラストアンカーであるルート証明書までの認証パスの電子証明書群をまとめて検証情報と呼びます。長期署名では検証情報（証明書/CRL/OCSP）を長期署名フォーマット内に保存することで、電子証明書の期限切れ後も有効性を保証します。

###1-2. 暗号アルゴリズムの危殆化

**「暗号アルゴリズムの危殆化」**とはどういう意味でしょうか。暗号アルゴリズムは以下の2つの理由のいずれかまたは両方によって危殆化します。

• 新しい解読方法が見つかるまたは見つかる恐れが出た。
• CPU高速化等により力業で解読できるようになりそうまたはなった。

どちらも年を重ねるごとにリスクが増大して行きます。暗号の世界ではアルゴリズムが危殆化する前に以下の2つのどちらかの対処を行います。

• 同じ暗号方式だが鍵長等を増やす。
• 例：RSA公開鍵暗号の鍵長を1024bitから2048bitに変更する。
• 新しい暗号方式に移行する。
• 例：SHA-1ハッシュ方式からSHA-2ハッシュ方式に変更する。

日本においては CRYPTREC暗号リスト（電子政府推奨暗号リスト） が公開され不定期ですが更新されて行きます。最新のCRYPTREC暗号リストにある暗号アルゴリズムは、その時点において安全と考えて構いません。海外では、米国ではNIST（SP-800台）やRFCが暗号活用の文書を出していますし、欧州ではENISAが中心となって同様の文書を発行しています。

長期署名ではデジタル署名（正確にはタイムスタンプ）を重ねて行き、新しく追加されるデジタル署名の暗号アルゴリズムとして最新のものを使うことで、暗号アルゴリズムの危殆化に対応することができるようになっています。長期署名は、長期間保管するとその間に暗号アルゴリズムの危殆化があることを想定している署名フォーマットと言えます。

###1-3. 長期だけじゃ無い先進電子署名

長期署名は英語ではAdESです。これは当初は "Advanced Electronic Signature" の略でした。直訳すると先進電子署名（高度電子署名と訳す場合もある）ですが、長期保管向きの仕様であるとして日本では長期署名と訳されることが多くなりました。個人的にはこれは意訳であって目的が分かりやすいけれどミスリードする可能性があると考えています。何故かと言えばAdESの本来の目的は、長期署名以外に既存の古い電子署名フォーマットを見直した上で置き換えることにあったのではないかと考えている為です。長期保管をしなくても、例えばXML署名ではなくXAdES長期署名を使うべきです。タイムスタンプが利用可能であったり、署名証明書の保護が必須になっていたりと利点が幾つもあります。後述しますが長期署名では、既存の電子署名と長期署名フォーマットをAdES-BESとして定義しています。

#####読み物：電子署名とデジタル署名
電子署名とデジタル署名は同じものでしょうか？実はもともと長期署名を策定したETSIでは最初はAdESはAdvanced Electronic Signatureの略としていました。つまり電子署名の１種だったのです。しかし欧州ではeIDASにより用語や仕様が明確化されました。この時に電子署名（Electronic Signature）は電子シール（Electronic Seal）と共に法的（または用途や目的）な意味合いの用語となり技術用語では無くなりました。技術用語としては電子署名（Electronic Signature）は使わず、デジタル署名（Digital Signature）が正しいとなりました。これによりAdESは略語では無く固有名詞として使われることで AdES Digital Signature となりました。これを日本語化するなら先進デジタル署名か長期デジタル署名と呼ぶべきでしょう。現在では例えば XAdES も欧州では正式には XAdES Digital Signature です。

電子署名を法的/用途/目的の用語として考えるなら、最近では暗号技術を使わない認証記録型の電子署名（例：DocuSign）や、事業者が署名をする立会人型電子署名、等も電子署名と言えます。ここでは署名者本人がデジタル署名する本人型電子署名を前提に話を進めます。

###1-4. まとめ：長期署名は何故必要

まとめるまでも無いですが長期署名は、電子証明書の有効期限後であっても（1-1）、暗号アルゴリズム危殆化後であっても（1-2）、電子署名の有効性を延長して保証することができます。つまり有効性（トラスト）を長期間にわたり延長し続けて保証できる点が最大の利点です。

また既存のデジタル署名フォーマット（XML署名/CMS/PKCS#7/PDF署名等）と同じく短期利用を目的としたフォーマットレベル（AdES-BES：後述）があるので、**従来の電子（デジタル）署名もそのまま置き換える（1-3）**ことが可能です。利用目的が短期であっても従来に無い利点があり、短期長期関係無く長期署名フォーマットを使うことを推奨します。

##2. 長期署名レベルと作成手順

次に長期署名フォーマットの構造と作成手順を見てみましょう。長期署名フォーマットでは作成する順番に合わせてレベルが決められており、その順番に作成する必要があります。長期署名フォーマットは最終的に長期保管に利用する AdES-A（アーカイブタイムスタンプ付き）を含む4つのレベルがあります。なお下の表において、署名レベルの中にある括弧内の名称は、欧州eIDASのBaseline署名仕様における名称です。過去の仕様では他にもAdES-CやAdES-Xと言ったレベルもありましたが、現在ではAdES-X-Longが推奨され、AdES-CとAdES-Xは非推奨となっていますので使わないようにしましょう。

レベル	構造	作成方法
AdES-BES (AdES-B)	デジタル署名のみ	署名鍵と電子証明書を使ってデジタル署名することで作成
AdES-T (AdES-T)	AdES-BES ＋ 署名タイムスタンプ	署名後すぐにタイムスタンプ追加 ※ 検証時の署名時刻として利用
AdES-X-Long (AdES-LT)	AdES-T ＋ 検証情報	証明書有効期間内に、デジタル署名とタイムスタンプの検証情報（証明書/CRL/OCSP）を集めて追加
AdES-A (AdES-LTA)	AdES-X-Long ＋ アーカイブタイムスタンプ	証明書有効期間内に、全体を守る為のタイムスタンプ追加 ※ これで署名の有効期間が延長される ※ 繰り返しタイムスタンプを追加して再延長も可能

長期署名フォーマットは成長する署名フォーマットです。レベルで言うと、AdES-BESからAdES-Tへ、AdES-TからAdES-X-Longへ、AdES-X-LongからAdES-Aへ…と前のレベルのデータを内包するように要素を追加して成長して行きます。

###2-1. AdES-BES：デジタル署名のみ

作成に必要になる物：署名鍵（秘密鍵）と紐づいた電子証明書（公開鍵）

デジタル署名を付与したフォーマットですが署名値の対象となるのは、署名対象のハッシュ値と署名属性となります。署名属性として署名鍵と紐づいた（対になった）電子証明書等を指定して埋め込みます。署名時刻として署名したシステムやPCのローカル時刻文字列を埋め込むことも可能です。ただしローカル時刻はタイムスタンプ（RFC 3161方式）に比較すると信頼性が落ちるので基本的に検証時に署名時刻としては扱いません。欧州ではこのローカル時刻をクレーム（主張）時刻と呼ぶ場合もあります。署名対象が1バイトでも変更された場合には検証して検知が可能です。

署名鍵がICカードに入っている場合にはICカードの外に署名鍵を取り出すことは出来ません。このように署名鍵を閉じたハードウェアの中に入れて運用する仕組みをHSM（ハードウェア・セキュリティ・モジュール）と呼びます。この場合はHSMの中でデジタル署名を行う必要があります。最近では署名鍵をサーバ上に置いたHSMに入れてサービスを提供する運用方法が増えておりこれはリモート署名（クラウド署名と呼ばれる場合もある）と呼ばれます。リモート署名ではサーバ上の署名鍵を使う為に電子認証による当人確認を行うことで当人性を保証します。このようにAdES-BESを作成する場合には署名鍵をどこに置いて使うのかによって仕組みが異なります。長期署名システムではまず署名鍵をどこに置いて運用するのかを検討する必要があります。大きく分けると、ローカル署名・クライアント署名・リモート署名の3種類があります。

種類	長期署名フォーマット作成（署名Lib）	署名値計算（HSM利用）
ローカル署名	クライアント（署名アプリ等）	クライアント
クライアント署名	サーバ（要クライアント連携）	クライアント
リモート署名	サーバ（要HSM連携）	サーバ

なおクライアント署名は標準化された言葉では無く私が考えた名称です。署名鍵はHSMに入れて使うことが推奨されますが、簡易に行う場合には、クライアント側ではWindows証明書ストアに入れて使うこともあるでしょうし、サーバ側ではPKCS#12形式で保管されている場合もあります。それぞれどのようなリスクがありどの程度の信用が必要か等を検討して長期署名システムを設計してください。

このAdES-BES形式はそのまま既存の電子署名フォーマットを置き換えることが可能です。例えばXML署名とXAdES-BES署名は同じ用途に用いることが可能です。ただしXML署名と違い、XAdES-BES署名では署名証明書も保護（XML署名でもオプションで対応は可能）していますし、必要に応じて後から署名タイムスタンプを追加することも可能です。現在のXML署名の利用フォーマットを見ると署名証明書を含まずかつ守っていないことが多く、私個人的には新規に作成される署名システムにおいて古いXML署名をわざわざ使うことは避けるべきだと考えています。

###2-2. AdES-T：署名タイムスタンプ追加

作成に必要になる物：タイムスタンプサーバ

AdES-BESを守るようにデジタル署名ベースのRFC 3161形式のタイムスタンプを追加します。検証時に信頼された署名時刻として利用されることもあり署名タイムスタンプと呼ばれます。通常はAdES-BESで作成された署名値に対してカウンタ署名として付与されます。PAdESの場合は少し異なる場合がありますが後述します。「誰が」と「いつ（署名時刻）」を保証できるので、AdES-Tフォーマットは長期保証が不要である場合、例えば電子申請等に良く使われます。

RFC 3161形式のタイムスタンプをHTTP/HTTPS通信にて付与するサーバをタイムスタンプサーバと呼びますが、これをサービスとして監査も受けている第三者が運営しているケースが最も信頼性が高くなります。署名者の手が届かないサーバで時刻が保証されるからです。タイムスタンプサーバを自前で運用する場合にはサーバ時刻が詐称されている可能性があります。自前でタイムスタンプサーバを運用するのであれば、時刻が変更されないようなポリシーと運用規定を用意しましょう。

日本において第三者が運用しているタイムスタンプサービスは基本的に有償サービスです。長期署名システムにおいて、電子証明書の発行とタイムスタンプサービスの利用にランニング費用が必要となります。この辺りのランニング費用をいかに低く抑えられるのかと言う点を含めて長期署名システムを検討する必要があります。

プログラマであればちょっとタイムスタンプを使ってみたいと思っても、無償かつ無登録で利用可能となるタイムスタンプサーバはほとんどありません。そこで私が開発したOpenSSLを使ったフリーのタイムスタンプサーバFreeTSAを公開しています。タイムスタンプと使ってみたい方はお試しください。なおTSA証明書がオレオレ認証局ですので実務には利用できませんのであくまでお試し用となります。

FreeTSA：JNSA PKI SandBox Project - FreeTSA Project -

###2-3. AdES-X-Long：検証情報の埋め込み

作成に必要になる物：検証情報（認証パス証明書群＋CRL/OCSP）

長期署名（AdES）の初期には検証情報を外部に置き参照するフォーマットであるAdES-C等もありましたが、検証情報そのものを埋め込むこのAdES-X-Longが標準となりました。現在欧州ではAdES-C/AdES-Xは非推奨となっており、eIDASではAdES-X-Longのみが認められています。検証情報は認証局（CA）から提供される以下の2つの要素群を合わせた情報となります。

1. 証明書群（認証パス：信頼済みルート証明書までのチェーン構築用）
2. 失効情報群（CRLかOCSP：ルートを除く各証明書毎に必要）

これら検証情報を署名フォーマット中に埋め込む形式がAdES-X-Longとなります。ただ署名を長期間有効にする方法は長期署名フォーマット以外にもあります。例えば検証情報を別途安全に保管しておき、AdES-Tを検証する時に外部から保管した検証情報を提供することもできます。同じ認証局が発行した署名証明書を使い大量の署名文書を保管するような場合で、失効情報にCRLを使うなら（OCSPは個別に必要だがCRLは共通して利用可能）、1セットの検証情報により全ての署名が一括検証できる為に効率が良い場合があります。

一方で、AdES-X-Longとして個別に検証情報を全て埋め込む場合には1つの長期署名フォーマットのファイル内で検証に必要となる検証情報が全て提供されるので、ファイル単体で保管するだけで良い等の利点があります。契約書のように個別に運用される文書の場合にはやはり長期署名フォーマットの方が扱いが楽で便利でしょう。

と言うことで検証情報を一部しか含まない利用パターンも考えられますが、AdES-X-Longの定義としては「アーカイブタイムスタンプを追加することでAdES-Aに出来る状態」すなわち全ての検証情報を埋め込んだ形式と言えます。AdES-X-LongはAdES-Aを作成する為の中間フォーマットと言うことですね。この為にAdES-X-Longの形で利用することはあまり無いと言えますが、日本では電子処方箋のXAdESではAdES-X-Longも利用されています。

失効情報のうちCRLに関しては**猶予期間（Grace Period）**をどう考えるかと言う問題があります。CRLの発行は認証局（CA）によって違いますが24時間おきに発行されることが一般的です。これは認証局によっては失効が生じるまで発行しないと言うポリシーもあり得るので、認証局の認証局運用規定（CPS）を確認する必要があります。厳密に長期署名を解釈するならば、署名時刻より後に発行されたCRLが必要です。それはCRLが更新されるまでに盗難等により失効するかもしれないからです。これを猶予期間と言います。24時間のCRL発行間隔の場合には24時間待てば新しいCRLが発行されるので、AdES-BES/Tの作成後に24時間待ってAdES-X-Long化する必要があります。

ただし通常であればそのような微妙なタイミングで失効することは稀であり、猶予期間を設けずAdES-BES/Tの作成後すぐにAdES-X-Long化すると言う考え方もあります。これもリスクを考えて運用ポリシーとしてどうするのか考える必要があると言うことになります。

なおOCSPの場合には通常であれば認証局のデータベースからすぐに情報を引き出せるので猶予期間を考える必要が無いことになります。AdES-BES/Tの作成後すぐにOCSPを取得しても署名時刻後の失効状態を得ることができると言うことになります。過去にはCRLベースのOCSPレスポンダ（失効の有無をデータベースからではなくCRLから取得する構成）もありましたが、現在そのような認証局はほとんど無いでしょう。以前は日本の認証局ではCRL運用がほとんどでしたが、最近ではOCSP運用または併用が増えて来ています。

###2-4. AdES-A：保管タイムスタンプ追加（延長）

作成に必要になる物：タイムスタンプサーバ

AdES-Aこそが長期署名フォーマットそのものと言えます。署名証明書と署名タイムスタンプの検証に必要となる全ての検証情報を埋め込んだAdES-X-Longに対してアーカイブタイムスタンプを追加することでそれら全てを守り保証することが出来ます。電子署名の有効期限としては、アーカイブタイムスタンプの追加後には最後のアーカイブタイムスタンプに使われているTSA証明書の有効期限までに延長されます。

また大事なことですが、アーカイブタイムスタンプは重ねて追加して行くことが可能です。新しいアーカイブタイムスタンプを重ねる前には、1つ前のアーカイブタイムスタンプのTSA証明書に関する検証情報を埋め込んでから新しいアーカイブタイムスタンプを追加することになります。これにより電子署名の新しい有効期限は最後に追加したアーカイブタイムスタンプのTSA証明書の有効期限までに延長されて行きます。成長する署名フォーマットと言う意味がお分かり頂けたでしょうか。

もちろん有効期限だけでは無く利用している暗号アルゴリズムやハッシュアルゴリズムの危殆化の恐れがある場合には、その時最新の暗号アルゴリズムやハッシュアルゴリズムを使ってアーカイブタイムスタンプを追加することで、その中の電子署名の危殆化を回避することが可能となります。

つまりTSA証明書の有効期限切れするか利用している暗号アルゴリズムの危殆化の前に新しいアーカイブタイムスタンプを追加すれば、電子署名の有効性が延長されることになります。長期署名に限らず長期間保管されるようなフォーマットでは特に暗号アルゴリズムの危殆化へ対応する仕組みはこれから必須となるでしょう。

##3. 長期署名フォーマットの種類

長期署名フォーマットとしては、PAdES（PDF）/XAdES（XML）/CAdES（CMS）/JAdES（JSON）の4つがあり、更に長期署名フォーマットを利用したコンテナフォーマットとしてASiC（ZIP）があります。これらは全て欧州の標準化団体であるETSIのESIにて策定されたものです。最初はTS（Technical Specification）として発行されたのですが、その後eIDASの為にEN（European Standard）として再発行されました。ただしEN仕様は欧州独自のBaseline署名と言うプロファイルとなっており細かい仕様で異なる箇所があります。

仕様	形式	署名対象
PAdES	PDF	PDFファイル（添付ファイルは可能） ※ 内部でCAdES-T形式を利用 ※ Adobe Readerで検証が可能（要注意）
XAdES	XML	XMLまたは任意形式ファイル ※ 複数署名対象に1つの署名が可能
CAdES	CMS	バイナリ等の任意形式ファイル
JAdES	JSON	JSONまたは任意形式ファイル ※ 2021年に仕様化されたばかり
ASiC	ZIP	任意形式ファイルをZIPでまとめて長期署名化 ※ XAdESやCAdESやタイムスタンプを利用
仕様には、全体の仕様を全てまとめたベース仕様（仕様リンクの前に**[B]を追加）と、ベース仕様を制限して使いやすくしたプロファイル仕様**（仕様リンクの前に**[P]**を追加）に分かれます。ベース仕様は共通して利用可能であり最新の仕様を使うべきです。プロファイルは、日本であればJIS（国内）プロファイル仕様やISO（国際）プロファイル仕様を、欧州のeIDASとの相互運用が必要であればEN（欧州）プロファイル仕様を選択します。この辺りどのベース仕様とプロファイル仕様を選べば良いかは長期署名フォーマット毎に異なるので各項目で個別に説明します。なお各仕様へのリンクは現時点での最新にしたつもりですが、新しいバージョンが出ている可能性もありますので、必ず検索してみて最新版を参照するようにしましょう。

###3-1. PAdES：PDF長期署名フォーマット

おそらく最近最も使われている長期署名フォーマットがPDFベースのPAdESでしょう。電子契約書等に対する長期署名として利用されています。最大の利点は検証器として Adobe Reader (Acrobat) が使えることでしょうか。しかし気を付ける必要があるのは Adobe Reader の検証が必ずしも正しいか…と言うとそうは言い切れない場合があることです。**異なるベンダーの検証器における検証結果は同じになるとは限りません。**Adobe Reader で正常（VALID）と表示されても不正（INVALID）であるケースもありますし、当然その逆のケースもあります。これを避けるにはその検証器において何を検証しているのか検証項目や内容を統一する必要があります。

実はISO 14533の長期署名プロファイルのシリーズでは適合宣言書が付録として付いています。PAdESであればISO 14533-3となります。最低でもこの適合性宣言書を検証器毎に用意して欲しいのですが、Adobe Reader では用意されていません。また適合宣言書では主に長期署名生成時の項目リストである為に、本当であれば検証時の項目リストが欲しいのですがこれはまだ標準化されていません。JNSAにて検証ガイドラインが発行される予定です。是非一読されることをお勧めします。Adobe Reader も検証項目について公開してくれると良いのですが。また検証について基本的な知識を得たいまたは入門編として「電子署名検証を10分で説明してみる」と言う資料を昔作って公開しているのでご覧ください。

閑話休題。PAdESはETSIにて最初コンテストが行われて複数仕様の中からAdobe社提案の現在のフォーマットが採用されたものです。その時にはPDF仕様は既にAdobe社からISOに移管されており、ISO 32000-1（PDF1.7）に新たにPAdES仕様を追加したものがETSIのTS/EN仕様です。その後ISO 32000-2（PDF2.0）が発行され、ISO 32000-2にはPAdES仕様も取り込まれました。ISO 14533-3は更にISO 32000-2をベース仕様としたプロファイル仕様です。PAdES仕様はまだJIS化されていないこともあり、PAdESに関する仕様を参照するならISO 32000-2とISO 14533-3を見ることを推奨します。

PDF署名はPAdES以前は内部にPKCS#7形式の署名データを埋め込んでいました。PAdESからはPKCS#7にかわってCAdES形式が採用されています。PKCS#7でもCAdESでも署名タイムスタンプ付きに出来るので、正確にはCAdES-BES形式またはCAdES-T形式が署名データとして使われることになります。更に署名データとしてタイムスタンプトークン（RFC 3161）も利用可能となっています。これによりPAdESではデジタル署名を使わずタイムスタンプだけを付与することが可能になっています。

種類	/Type	/SubFilter	説明
PAdES-Basic	/Sig	/adbe.pkcs7.detached	古い署名データ形式（非推奨）
PAdES-Enhanced	/Sig	/ETSI.CAdES.detached	CAdESを使った形式（推奨）
PAdES-DT	/DocTimeStamp	/ETSI.RFC3161	タイムスタンプ用（推奨）

CAdESを使うならCAdES-Aを埋め込めば良いのでは？と言う疑問もあるかと思います。しかしながらPDF署名ではByteRange要素により署名データのサイズが固定されているので、CAdESを後から成長して大きくすることが出来ません。PAdES-X-Longの検証情報はCAdESの外にPDFオブジェクトとして埋め込みます。この為にPAdES仕様はPDF要素の定義が含まれることになりました。PDF署名/PAdESの技術的な仕様について詳しく知りたい方は、「なんとなく分かった気になるPDF電子署名仕様入門2」を公開していますのでご覧ください。

ISO 32000-2やAdobe Readerの表示でLTV（Long Term Validation）と言う名前が出てきます。これは全ての検証情報がPDFに埋め込まれている状態を意味しています。PDF署名は長期署名仕様以前から存在していたこともあり、複数署名が可能であったり同じことを複数のやり方で実現可能であったりと仕様の幅が大きいと言う特長があります。これはPDF仕様には良くあることなのですがかなりノウハウや知識が必要であったりと一筋縄ではいかない面があります。本格的に利用されるのだれば専門家に意見やコンサルを求められることを推奨します。

ISO仕様：
[B] ISO 32000-2:2020 / Portable document format — Part 2: PDF 2.0
[P] ISO 14533-3:2017 / Long term signature profiles for PDF Advanced Electronic Signatures (PAdES)
EN（European Standard）仕様：
[B] ETSI EN 319 142-1 V1.1.1 (2016-04) : PAdES digital signatures; Building blocks ...
[P] ETSI EN 319 142-2 V1.1.1 (2016-04) : PAdES digital signatures; Additional ...
TS（Technical Specification）仕様：
[B] ETSI TS 102 778-1 V1.1.1 (2009-07) : PDF Advanced Electronic Signature Profiles

###3-2. XAdES：XML長期署名フォーマット

XMLを使った長期署名フォーマットXAdESは、フォーマット自体はXMLですが署名対象はXMLに限らずバイナリを含む任意のデータが使用可能です。また署名対象は複数をURIにて指定可能となっておりどの対象が改ざんされたかも検知することができます。以下の図は4つの署名対象（電子文書）を指定した場合のXAdESフォーマット構造となります。

またManifest要素を使うことで署名対象をハッシュツリー化することも可能となり、これにより大量の署名対象を効率良く長期署名化することが出来ます。

XMLはテキスト形式なので内容の確認が容易でもあり、XML署名/XAdESは多くのコンテナやデータで使われています。サーバにて大量なファイルやデータに対して一括して署名するような用途で良く使われています。他にも「古今東西XML署名フォーマット」として色々なコンテナやデータでのXML署名/XAdESの例を説明していますのでご興味があればご覧ください。

XAdESを使う上で注意が必要な点としてはXAdESのバージョンがあります。XAdES仕様（XML名前空間）は ETSI TS 101 903 でずっと定義されています。XAdESの仕様としてはV1.3.2以降が現在も有効ですが、可能ならV1.4.1を使いましょう。V1.4.1にてタイムスタンプの検証情報の格納場所も定義され、V1.4.1がXAdESの完成形と言えます。なおV1.4.1はV1.3.2への追加要素で構成されているので、その意味では最新の仕様はV1.3.2＋V1.4.1と言えます。

バージョン	利用	説明
V1.1.1	非推奨	古い仕様であり多くの検証器が非対応であり利用しない方が良い ※ W3C Note 20 February 2003 がV1.1.1のままなので注意！
V1.2.2	非推奨	古い仕様であり多くの検証器が非対応であり利用しない方が良い
V1.3.2	可能	XAdESの基本的な要素が定義され現在も使われている ※ JIS X 5093:2008 がV1.3.2のまま（少し古い）
V1.4.1	推奨	V1.3.2に追加要素を加えた形で、利用が推奨される最新仕様 ※ ISO/DIS 14533-2 / ETSI EN 319 132

XAdESにはデファクトとなるような検証器がありません。一般的には署名付与する同じライブラリに含まれる検証器が使われることが多いでしょう。過去には日本や欧州において相互プラグテスト（お互いに署名の付与と検証を行う試験）を行っていましたが、日本でもまたやりたいですね。XAdESに関して参照する仕様として、プロファイル仕様はISO/DIS 14533-2（2021年中には正式のISO 14533-2:2021になる予定、私が書いてますw）を推奨します。ベース仕様はETSI EN 319 132を見ましょう。

ISO仕様：
[P] ISO/DIS 14533-2 / profiles for XML Advanced Electronic Signatures (XAdES)
EN（European Standard）仕様：
[B] ETSI EN 319 132-1 V1.1.1 (2016-04) : XAdES digital signatures; Building blocks ...
[P] ETSI EN 319 132-2 V1.1.1 (2016-04) : XAdES digital signatures; Extended ...
TS（Technical Specification）仕様：
[B] ETSI TS 101 903 V1.4.1 (2009-06) : XML Advanced Electronic Signatures (XAdES)

###3-3. CAdES：CMS長期署名フォーマット

電子署名/PKIの世界では昔からバイナリのASN.1のBER/DER形式が良く使われていました。署名データフォーマットもPKCS#7とその進化形であるCMSが使われてきました。CMSを長期署名化したものがCAdESとなります。長期署名フォーマットとしては最初に仕様化されたものであり、仕様的にはXMLかバイナリかを除けばXAdESとも共通点が多い仕様となっています。

しかしながら現在CAdESが最も使われているのはおそらくPAdESの埋め込み署名データとしてではないでしょうか。この場合にはCAdES-Tまでが必要となります。実はCAdES-Aのアーカイブタイムスタンプには複数のバージョンが存在しており仕様も少し複雑になっています。CAdES単体で長期署名フォーマットとして利用するにはこの辺りも知っておく必要があるでしょう。

CAdESに関して参照する仕様として、プロファイル仕様はISO 14533-1:2014を推奨します。ベース仕様はETSI EN 319 122を見ましょう。

ISO仕様：
[P] ISO 14533-1:2014 / Long term signature profiles for CMS Advanced Electronic Signatures (CAdES)
EN（European Standard）仕様：
[B] ETSI EN 319 122-1 V1.1.1 (2016-04) : CAdES digital signatures; Building blocks ...
[P] ETSI EN 319 122-2 V1.1.1 (2016-04) : CAdES digital signatures; Extended ...
TS（Technical Specification）仕様：
[B] ETSI TS 101 733 V2.2.1 (2013-04) : CMS Advanced Electronic Signatures (CAdES)

###3-4. JAdES：JSON長期署名フォーマット

JSONはXML代わりインターネットプロトコルで使われている形式です。JSONにはJWS（RFC 7515）と言う電子署名の標準仕様があり、JWT（トークン）用の JWS Compact Serialization 仕様と、JWS JSON Serialization と言うJSON署名方式があります。JAdESは両方に対応したJSON長期署名フォーマットです。2021年3月に最初の公式仕様が公開されたばかりで実際に利用されるのはこれからでしょう。XAdESの用途を置き換えるように使われて行くのではないかと個人的には予想しています。ETSI TS 119 182-1 の付録CではXAdES要素とJAdESタグの比較表があるのもそう言う意味だと思います。これから注目される長期署名フォーマットですね。

IETF（JWS）仕様：
RFC 7515 : JSON Web Signature (JWS)
EN（European Standard）仕様：
※ これから出てくると思われる。
TS（Technical Specification）仕様：
[B] ETSI TS 119 182-1 V1.1.1 (2021-03) : JAdES digital signatures; Building blocks ...

###3-5. ASiC：ZIP長期署名コンテナ

ZIP圧縮により複数のファイルをまとめるZIPコンテナは各種データフォーマットで利用されています。例えば電子書籍のフォーマットであるEPUCや、オフィス文書のフォーマットであるOOXML（.docx/.pptx/.xlsx）もZIPコンテナです。他にもメールする時にも皆さんファイルをまとめてZIP圧縮して1つのZIPファイルにしていると思います。「古今東西XML署名フォーマット」でも一般的なZIPコンテナでのXML署名の例を紹介しています。

欧州ではZIPコンテナに対してXAdES/CAdES/タイムスタンプトークン等を埋め込むことでZIP長期署名コンテナとして標準化をしています。ただあまり日本では使われていませんね。これまでの主なZIPコンテナは電子署名としてXML署名が使われることが多かったのですが、欧州ではXAdES以外にも各長期署名フォーマットの利用が出来る仕様となっています。しかしこの為にASiCの使い方は面倒になっている気がします。素直にXAdES（これからはJAdES？）やタイムスタンプを使ったASiC仕様をメインにした方が良いように個人的には思います。

ASiCは欧州向けで他ではあまり使われていないこともあり、ISOやIETFの標準にはなっていません。仕様を確認する場合にはETSIのドキュメントを参照してください。

EN（European Standard）仕様：
[B] ETSI EN 319 162-1 V1.1.1 (2016-04) : Associated Signature Containers (ASiC); Building blocks ...
[P] ETSI EN 319 162-2 V1.1.1 (2016-04) : Associated Signature Containers (ASiC); Additional ...
[B] TS（Technical Specification）仕様：
ETSI TS 102 918 V1.3.1 (2013-06) : Associated Signature Containers (ASiC)

##4. FAQ：長期署名のよくある質問

最後に良く聞かれる質問に関して幾つか回答を。

###4-1. 有効期限が切れた署名は無効ですか？

一番多い質問が有効期限切れに関するものです。長期署名は有効期間内に延長の為のアーカイブタイムスタンプを追加するわけですが、延長せずに有効期限切れになった長期署名ファイルはどういう扱いになるのかと言う質問です。

答える前に検証結果の種類について解説します。検証した結果としては、VALID（有効）とINVALID（無効/不正）以外に、INDTERMINATE（不明）と言う状態があります。これは Adobe Reader の検証結果でも同じです。この辺りは「電子署名検証を10分で説明してみる」でも説明しています。

検証結果	説明
VALID 有効	全ての検証に成功した状態。改ざんも無く署名証明書とTSA証明書も有効であった。
INDETERMINATE 不明	改ざんは無かったが、署名証明書とTSA証明書のPKI検証を行う為の情報が不足しており、有効性が確認できない状態。
INVALID 無効/不正	改ざんがあったか、署名時に署名証明書が失効していた等により検証に失敗した状態。この場合には署名は無効となり保証出来ない。

結論から先に言ってしまうと、有効期限切れになった長期署名ファイルは私としては**INDETERMINATE（不明）**であると考えています。ただし一番外側のアーカイブタイムスタンプで利用している暗号アルゴリズムの危殆化がしていないと言う条件付きです。また暗号アルゴリズムの危殆化はしていなくとも、長期署名の仕組みで見た場合には無効ではあるので、検証器によってはINVALID（無効/不正）と返すケースもあると思います。

アーカイブタイムスタンプに利用しているRFC 3161形式のタイムスタンプはサーバ署名の一種と言えます。有償のサービスでは署名鍵（秘密鍵）をHSMに入れて管理していますし、TSA証明書の有効期限が切れた後にはきちんと署名鍵は削除されていますので、不正利用されることはまず無いと言えるでしょう。このように厳格な運用が行われているからこそTSA証明書の有効期間は10年もの長い期間を許されています。余談ですが利用者が自分で管理する署名鍵（ICカードやPKCS#12ファイル）ではせいぜい1年から5年くらいまでの有効期間となっています。

閑話休題。このようにきちんと管理と運用がされている署名やタイムスタンプは有効期限が切れたと言っても署名値により改ざんの確認は有効と言えますし、ただちにINVALID（無効/不正）とは言えないでしょう。また外部から別途検証情報を持ってくればVALID（有効）にすることも可能ですので、検証情報が不足しているINDETERMINATE（不明）と考えるべきです。ただこの辺りは検証ポリシーにも依存するので厳しい検証ポリシーだとINVALID（無効/不正）と判定される可能性があることは理解しておくべきです。

最も注意すべき点はやはり一番外側のアーカイブタイムスタンプで利用している暗号アルゴリズムの危殆化の有無です。危殆化する恐れがある場合には有効期限に関係無く新しく安全な暗号アルゴリズムを使ったアーカイブタイムスタンプを追加して保証を延長する必要があります。有効期限の問題よりも暗号アルゴリズムの危殆化の問題の方が大きいと考えるべきです。

長期署名の運用を考える場合に有効期限をどう考えるかはきちんと考えておきましょう。最も安全な運用ポリシーは有効期限が切れる前にアーカイブタイムスタンプを追加することです。あまり厳密に考えないのであれば暗号アルゴリズムの危殆化までは延長しないと言う運用ポリシーもありでしょう。あまり厳しくしすぎると利便性を損なうこともあり、利用する目的と要求されるリスクを考えた上で運用ポリシーを策定してください。

###4-2. 欧州eIDASとの相互運用性はありますか？

欧州のeIDASでは単純に電子署名と言うだけではなく、eIDによる認証インフラや、サーバー類の運用ポリシーも含む広範囲の仕様となっています。この為に一部では一般とは異なる考え方も含まれます。最も大きな違いは署名時刻に関してとなります。日本においては一般的に、AdES-BESでは検証における現在時刻を利用し、AdES-Tでは署名タイムスタンプ時刻を検証に利用します。AdES-BESであっても署名時刻を示すローカル時刻（システム時刻）は文字列として含むことができます（eIDASでは必須）。XAdESであればSigningTime要素ですし、PAdESであれば署名辞書の/M要素がローカル時刻による署名時刻です。

欧州ではAdES-BES（欧州ではAdES-B）の検証において、ローカル時刻である署名時刻を検証時刻として利用して良いとなっています。これはサーバーの運用規定として時刻同期が義務付けられている為に、システムのローカル時刻であっても信用できると言うことからそうなっているそうです。この為にeIDASの長期署名プロファイルではシステムのローカル時刻を含むことが必須となっていますが、ISOの長期署名プロファイルでは任意となっている違いがあります。

このように細かな属性の幾つかの必須と任意の指定がeIDAS（ETSI ENのBaseline）とISOのプロファイルでは異なります。しかしながら日本においてもシステムのローカル時刻を入れることは可能ですし、欧州と同じサーバー運用規定を順守することも可能でしょう。この辺りを気を付けていれば相互運用は可能となります。

#おわりに

以上で簡単ですが長期署名をゼロから（？）まとめてみましたがいかがだったでしょうか。長期署名と言うか先進デジタル署名は長期に限らず全ての用途において標準となるべき仕様だと考えています。XAdESであればXML署名から追加すべき要素は少しだけですし難易度もそれ程高く無いと思います。PAdESはPDF自体の難しさもあって難易度高めでノウハウも必要となりますが色々なベンダーからサービスやライブラリが出ていますのでうまく使って利用しましょう。これからはJSONベースのJAdESも色々と使えそうで楽しみな長期署名フォーマットですね。

最近では電子署名法の解釈も変化が出てきており、立会人がデジタル署名をする立会人型電子署名や、更には米国型のデジタル署名ではない認証記録型電子署名も使われるようになってきました。とは言えやはりPKIを使ったデジタル署名は、信頼性や実績と言う意味で今でも重要な技術だと思います。また時間があればPAdESであったり認証記録型電子署名について記事を書ければと考えています。応えられるかどうかは分かりませんが要望や質問があれば書いて頂ければ目は通しますのでよろしければ書いてください。また少し古い資料になりますが電子署名とPKIについてハンズオン形式でまとめた「JNSA PKI SandBox Project」も公開していますのでよろしければご覧ください。それでは長期署名も是非使ってみてください！エンジョイ電子署名！

2021-04-15追記

長期署名の検証ガイドラインがJNSA電子署名WGの署名検証TFから公開されました！「デジタル署名検証ガイドライン」です。CAdES/XAdES/PAdESについての検証方法や項目に注意点やコラムまで盛り沢山の内容となっています。検証実装者はもちろんデジタル署名に興味がある技術者の方は必見です。ご活用ください！以下リンクから！

JNSA電子署名WG 署名検証TF
「デジタル署名検証ガイドライン」

【宣伝】
ここまでは一般的な話でまとめてきましたが最後の最後に宣伝を。私の会社「有限会社ラング・エッジ」では、「PDF長期署名ライブラリLE:PAdES:Lib」と、「XML長期署名ライブラリLE:XAdES:Lib」と、クライアント署名の拡張モジュール「クライアント署名拡張LE:Client:Sign」を販売しています。ご興味がありましたら是非お問合せください。また長期署名に関するコンサルや受託開発もお請けしていますのでこちらもよろしくお願いしますm(_ _)m