概要
「署名保証ガイドライン第1.00版（JNSA SAG-1:2026）」の2.1.章ではまず署名サービスの基本モデルを整理しています。整理に当たって署名サービスを前提にしています。手元に署名鍵を持つローカル署名方式は「サービス」ではないと言う話はあるかもしれませんが、署名用に証明書や検証用にCRL/OCSPを発行したりすると言う意味ではサービスとしています。
最初に署名サービス全体を3つの利用フェーズに分けています。「登録フェーズ」「署名フェーズ」「検証フェーズ」です。これが認証サービスなら「登録フェーズ」と「認証フェーズ」の2つになるのでしょうが、署名の場合には検証が含まれると共に実は最も大事だったりします。まずは署名サービスの基本モデルを図として示します。
図2-1 署名サービスの基本モデル
利用者は「申請者」「署名者」「検証者」に、署名サービスは「登録機能/ISF」「署名機能/SSF」「検証機能/VSF」の、それぞれ3つに分かれます。利用されるエンティティとしては署名データが「署名情報」「検証情報」に、署名クレデンシャルとして「署名鍵」「認証情報」の、それぞれ2つに分かれます。
署名の利用手順
表2-1に書かれた3つのフェーズと各フェーズ中の手順を整理しています。
| A）登録フェーズ：申請者が利用 | |
|---|---|
| 手順0 |
登録申請 申請者が署名サービス利用時に身元確認サービス機能へ登録申請をおこなう。 |
| 手順1 |
申請者身元確認 申請者が署名サービス利用時にISFに自身の属性情報を提示して身元確認をおこなう。 |
| 手順2 |
署名クレデンシャル紐付け 申請者の身元確認後に署名クレデンシャル（署名鍵or認証情報）の提供または申請者が所有するクレデンシャルとの紐付けをおこなう。これにより申請者は署名者となる。 |
| B）署名フェーズ：署名者が利用 | |
|---|---|
| 手順3 |
署名クレデンシャル利用 署名者は署名時に署名クレデンシャルを署名サービス機能に提示して当人認証をおこなう。SSFは署名クレデンシャルを確認して署名者当人であることを確認する。 |
| 手順4 |
署名プロセス（署名情報生成） 署名者に署名対象の確認を求め、署名クレデンシャル利用等により署名情報を生成する。 |
| C）検証フェーズ：検証者が利用 | |
|---|---|
| 手順5 |
検証プロセス（検証情報提供） 検証者は署名者より受け取った署名対象と署名情報に対して検証をおこなう。 |
手順1は認証の身元確認と同等であり、手順3もほぼ当人認証と同等となる。その意味ではA）の登録フェーズと、B）の署名フェーズでおこなっていることは電子認証とあまり変わりません。電子署名で異なっているのはC）の検証フェーズと言えます。これは電子認証で検証をおこなっていないことを意味しているのではありません。電子認証では当人認証時にサービス自身で検証をおこなっていますが、電子署名が検証は署名者とは別の第三者である検証者がおこない、かつ別フェーズ（同時では無い）である点が大きく異なっています。
用語説明
1. 利用者（User）
電子認証では利用者（User）は全て同じ自然人になりますが、電子署名では全く別の第三者である検証者がいる点が大きな差異となります。まあVCのIHVモデルで言うところの、H（Holder）が署名者であり、V（Verifier）が検証者と言えます。
1.1. 申請者（Applicant）
申請者は身元確認する為の属性等を提示する必要がある。署名サービス事業者に申請し身元確認後に署名クレデンシャルを紐付けて署名者となる。
1.2. 署名者（Signer）
身元確認され、当人に紐付く署名クレデンシャルを所有する者を署名者とする。署名対象を確認し署名クレデンシャルにより当人であることを確認して署名することで署名情報を生成することができる。
1.1. 検証者（Verifier）
署名データ（署名情報と検証情報）を検証して署名対象と署名者（検証者に開示される署名者のアイデンティティ）への紐付け（意思）と非改ざんを確認する。通常は署名者ではない第三者の検証者による検証プロセスを想定する。
2. 署名サービス（Signature Service）
署名サービスは3つの機能に分かれます。署名サービス機能（SSF）は必須となりますが、他の2つである身元確認サービス機能（ISF）と検証サービス機能（VSF）は別の外部サービスとすることもあります。
2.1. 身元確認サービス機能（ISF：Identity Service Function）
申請者の身元確認をおこない署名クレデンシャルを紐付けることで署名者とする。ISFは外部のCSP（Credential Service Provider）を利用する場合もある。
2.2. 署名サービス機能（SSF：Signature Service Function）
署名クレデンシャルを持つ署名者へ署名手順を提供し署名情報を生成する。SSPは最低限SSFを提供する必要がある（ISF/VSFは外部利用が可能）。
2.3. 検証サービス機能（VSF：Verification Service Function）
検証者に対して署名対象の検証に必要となる検証情報または検証結果を提供する。VSFは外部のVSP（Verification Service Provider）を利用する場合もあるが通常はSSPが提供することが多い。
3. 署名データ（Signature Data）
電子署名は署名対象となる電子データを後から保証するので、検証可能な署名データが必要となります。署名時（署名フェーズ）で提供される署名情報と、検証時（検証フェーズ）で提供される検証情報に分けています。PKIベースのデジタル署名で言えば、署名情報は「署名値」や「電子証明書」を含む署名データであり、検証情報は「CRL」や「OSCP」等の有効性確認情報となります。
3.1. 署名情報（Signature Information）
署名時にSSFが生成/提供する署名対象と署名者の紐付け（意思）と非改ざんを保証する情報群であり、署名対象と共に提供される。
3.2. 検証情報（Verification Information）
検証時に（つまり後から）VSFから提供される署名者の有効性情報等の情報群。
4. 署名クレデンシャル（Signature Credential）
クレデンシャルと言う単語は色々と誤解を招く可能性があります。DS-511ではクレデンシャルでは無く認証器（Authenticator）と呼んでいると理解しています。電子署名において例えば従来のローカル署名の場合には署名鍵がクレデンシャルまたは認証器の役目を果たしていると言えます。しかしながら署名鍵には当人認証だけではなく、署名値を生成して証拠とする機能があるために認証情報（認証器）とは分けて整理しています。いずれか一方または両方を利用して電子署名をおこないます。
4.1. 署名鍵（Signing Key）
署名者当人のみ利用可能な（鍵管理された）暗号技術に基づいた署名に用いる鍵。
4.2. 認証情報（Authentication Factors）
署名者当人を認証する為の署名者当人のみ利用可能な情報。
おわりに
電子署名の基本モデルはある意味では電子認証の基本モデルを拡張したものと言えるかもしれません。なぜ署名クレデンシャルを署名鍵と認証情報（認証器）に分けるんだと言えば、実は次回説明する電子署名方式の分類時に意味があると言っておきます。当人認証の技術を使った電子署名が増えてきており、従来のローカル署名方式と統合した整理をおこなうために、ある意味苦肉の策として分けているのです。この辺りは次回の「署名方式の整理」で説明しましょう。
署名保証ガイドライン解説シリーズ
| 章 | タイトル | 概要 |
|---|---|---|
| 0 | リリースしました！ | 署名保証ガイドライン第1.00版の概要 |
| 1 | 電子署名（と電子認証）の要件 | 電子署名（電子認証）とは？ |
| 2.1 | 署名サービスの基本モデル | 電子署名の基本モデルの定義 |
| 2.2 | 各種署名方式の整理 | ローカル署名と認証技術を使った様々な署名 |
| 2.3 | 電子署名の保証レベル | SxAL（SIAL/SPAL/SDAL/SOAL）の解説 |
| 3 | 電子署名のリスク管理（仮） | リスク管理と保証レベルの選択 |
| A | 適合宣言と情報公開（仮） | 信頼と情報公開 |
| B | 承認目的署名と発行元保証署名（仮） | eシール的署名とは |
| C | 電子委任（仮） | 委任状モデルと問合せモデル |
| D | トラスト設計（仮） | 署名と認証による設計 |