# 電子署名の仕組みについて
※「そもそも電子署名とは？」の部分ついて弊社側の理解を確認させてください
1. https://www.itis.nssol.nipponsteel.com/blog/contracthub/hint07.html
-- 図6
2. https://www.meti.go.jp/shingikai/external_economy/infura_kaigaitenkai/pdf/005_03_00.pdf
-- スライド23
- 証明書について
-- AuthCert API (認証用証明書)
--- 上記1の図6で登場する公開鍵のこと？
-- SignCert API (署名用証明書)
--- 上記1の図6で登場する秘密鍵のこと？
-- 基本はAPIを利用して署名すると思われるが、何に利用するのか？

## (xID長澤回答）

**回答**
* **AuthCert API (認証用証明書)** = 認証用秘密鍵に対応する認証用公開鍵を含んだ電子証明書です。認証用秘密鍵で作成された署名を検証するために使用します。
* **SignCert API (署名用証明書)** = 署名用秘密鍵に対応する署名用公開鍵を含んだ電子証明書です。署名用秘密鍵で作成された署名を検証するために使用します。
* **基本はAPIを利用して署名すると思われるが、何に利用するのか？** = 電子署名を検証するために必要です。または、長期署名フォーマット（PAdES/XAdES）として電子署名と電子文書を保管する場合には、検証情報として同一ファイルに含めることがあります。

**以下参考**
参考として以下のエントリが比較的正確に電子署名や公開鍵暗号について記載しているかと思いますので、参考まで。
* [2つの公開鍵暗号(公開鍵暗号の基礎知識)](https://qiita.com/angel_p_57/items/897bf94160be8d637585)
* [電子署名の基礎知識](https://qiita.com/angel_p_57/items/437ca6235defc938b97d)
* [「電子署名=『秘密鍵で暗号化』」という良くある誤解の話](https://qiita.com/angel_p_57/items/d7ffb9ec13b4dde3357d)

**署名を行うための事前準備（証明書発行）**
1. 署名者が①秘密鍵を作成
2. 署名者が②公開鍵を作成
3. 署名者が①で署名した③電子証明書発行要求（CSR）を認証局に送付
4. 認証局が③受理→④電子証明書（Certificate）発行
※④はプロファイルと`②=公開鍵を含んでいる`

**署名と検証の流れ**
1. 署名者が⑤被署名データ（DigestHash）準備
2. 署名者が①を用いて⑤から⑥署名値（電子署名）を計算
3. 署名者が検証者に④⑤⑥を共有
4. 検証者は④を用いて⑤⑥を検証

# 署名フロー
## 一人目の署名
※access_tokenは取得済みとする
### Userinfo API
-- 他のAPIで使用する'''userdataid''' を取得
-- 公的個人認証が済んでいない方をNGとする場合、 '''xid_verified''' の値（= false）で判断してよいか？
--- Verification APIレスポンスの '''verificationStatus''' と同じ値？
### HashSigning API
-- リクエスト： '''digest''' （対象PDFのダイジェストハッシュ&&base64エンコード）★
-- レスポンス： '''signatureID''' （署名結果の確認に利用）
### SignatureStatus API （2種類）
-- bigint型とタイプ指定型の違いは？（使い分けなど）
-- レスポンス： '''signature''' （署名データ）
--- この値は上記★を認証局発行の秘密鍵で暗号化したもの？
--- この値を署名結果として保存しておけばよい？
## 二人目の署名
- 基本は一人目と同じフローになると思われるが、上記★におけるdigestの元ファイルは？
-- API Docsで「この値は重複しない一意値である必要があります」とのこと
-- 単純に同じ元ファイルを使用して値を生成すると同じ値になると思われるので、一人目の署名データを加味する必要がある？

## （xID長澤回答）
### Userinfo API
* **公的個人認証が済んでいない方をNGとする場合、 ```xid_verified```の値（= false）で判断してよいか？** = はいその認識で問題ございません。
* **Verification APIレスポンスの ```verificationStatus```と同じ値？** = `xid_verified`はOIDCでの認可時点での公的個人認証実施の有無を、`verificationStatus`はAPIコール時点での公的個人認証実施の有無をそれぞれ意味しています。
### SignatureStatus API （2種類）
* **bigint型とタイプ指定型の違いは？（使い分けなど）** = 基本的にはクライアント様側のデータ取り扱いの判断で使い分けていただくものとなります。base64型での取り扱いが多いかと存じます。
* **この値は上記★を認証局発行の秘密鍵で暗号化したもの？** = 利用者の署名用秘密鍵で作成した電子署名です。
* **この値を署名結果として保存しておけばよい？** = 電子署名において、後から署名の正しさを検証できるということは重要な要素です。そのため、以下の情報とともに保管するか長期署名フォーマットをサポートすることをお勧めしています。
* 電子文書
* 電子文書から作成されたDigestHash
* 電子署名
* 当該電子署名を作成した秘密鍵に対応する電子証明書
* **単純に同じ元ファイルを使用して値を生成すると同じ値になると思われるので、一人目の署名データを加味する必要がある？** = はい、1人目の電子署名等を含んだファイルに対して署名を行う流れです。特に電子契約に電子署名を活用する場合、ファイル内に電子署名等を記録する場合が多いです。そのため、2人目の署名のターゲットとなるファイルは1目の時とはデータが異なることとなります。

# 署名を証明するために必要な情報
▼e-signの電子契約証明書で表示されている項目を提示すればよいか？
- ファイル名
- ファイルサイズ
- 署名者
-- アカウントレベル
-- 署名日時
-- 署名の有効性
--- どこで取得？
-- 証明書の発行機関　
--- どこで取得？固定値？
-- 署名者の電子証明書ID
--- どこで取得？AuthCert？
-- 発行機関ID
--- どこで取得？
-- 署名の対象
--- 上記★の値？
-- 電子署名
--- SignatureStatus APIのレスポンスsignatureの値？

▼e-sign上の「電子署名を含む確認」(ASIC-E形式)に相当する情報について
- ASIC-E形式は利用せず、単体のPDFファイル1つ1つに署名する場合において、対象ファイルと署名を一体に表現するための方法は？
-- PDFに署名データを書き込む？

## （xID長澤回答）
* **e-signの電子契約証明書で表示されている項目を提示すればよいか？** = まず、技術的な観点から電子署名を検証するためには、電子文書、ダイジェスト、電子署名、電子証明書等が同一ファイルに記録されていることが望ましいです。その国際的な企画が長期署名フォーマット（PAdES/XAdES）で、どの程度の検証情報が記録されているかによってレベル分けされています。他方、法廷の現場では、データで証拠提出やデータによる検証を行うことは稀で、基本的には紙ベースで提出することが常であると、当社顧問弁護士の見解をいただいております。そのため、e-signでは、長期署名フォーマットとしての「データ」であるASICファイルと、プリントアウトされることを想定した「電子契約証明書」の双方を準備しています。（技術的な本質に立つと、「電子契約証明書」は十分に改ざん可能であり、それ単体で検証はできない。）
* **「電子契約証明書」**の内容について** = 以下に整理します。
* 署名用電子証明書から取得している項目
* 証明書の発行機関
* 署名者の電子証明書ID
* 発行機関ID
* 電子署名 = SignatureStatus APIのレスポンスsignatureの値
* 署名の対象 = ダイジェストハッシュ値
* 署名の有効性 = 各種情報を用いて検証を行なっている
* 署名日時 = データ作成日時、タイムスタンプではない（e-signの場合）
* アカウントレベル = xIDの公的個人認証済みか否かに依存

# その他、気になる点
## xid値について
-- 利用者を一意に識別したい場合、どの値を使う？
-- Userinfo APIレスポンスのsub
--- この値は変更される？
-- Userdata APIレスポンスのxid
--- 「※公的個人認証未実施の利用者が公的個人認証を実施した場合変更されます」
-- Verification APIレスポンスのverifiedXID
--- 現在のxid値
--- 「当該の利用者が既に公的個人認証を実施して本人確認済みの場合、新しい xid 値が返却されます」
--- 公的個人認証「前」の状態でリクエストしたところ空の値が返却された（公的個人認証「後」じゃないと値は入らない？）
-- PreviousIDs APIレスポンスのusedXIDs
--- 「公的個人認証実施前のxidを配列で返します」
--- 「公的個人認証前後で利用者の同一性を保ちたい場合にはこちらのエンドポイントを利用してください」
--- 公的個人認証「前」の状態で試したところNullが返却された。（公的個人認証「前」でも値が返却されるのでは？）
--- なぜ配列？
## エラーレスポンスについて
-- APIドキュメントにエラーレスポンスの例が載っていないようなので、もしサンプルがあれば教えてほしい。（現状、トークン期限切れエラー等が発生したときにどういうレスポンスが来るかわからないので、実際に発生させるしかなさそうという状況です）
## 脆弱性診断について
-- 脆弱性診断を行う際にはスケジュールを共有するのか
-- 脆弱性診断は専門業者に依頼する予定なのだが、担当者がマイナンバーカードを持っていない可能性がある。仮にマイナンバーカードを持っていない場合はどのようにテストを実施すればよいのか
## シノケン様からの問い合わせ
-- グレーゾーン解消制度について
--- xID社でも同様の認定を取得する予定はあるのか
--- 国・地方公共団体ともクラウドサイン可能に?グレーゾーン解消制度による電子署名法・契約事務取扱規則の適法性確認
--- https://www.cloudsign.jp/media/20210208-grayzone-keiyakujimu/

## （xID長澤回答）
### xid値について
* **利用者を一意に識別したい場合、どの値を使う？**
* 以下の3つは全てxid値であり、利用者特定の識別子です。しかしどの時点での値かが異なります。
* sub・・・認可時点でのxid値
* xid・・・認可時点でのxid値
* verifiedXID・・・現在のxid値（公的個人認証済みの場合のみ）
* xIDアプリでメール認証済み→本人確認済みに変更された場合にのみ一度だけxid値が更新されます。
* 認可時点でxid_verified = trueであれば、xid値が変わることはありません。
* 認可時点でxid_verified = falseの場合、認可セッション期間中（access_tokenの有効期間中）にxid値が更新される可能性があります。
* 本人確認状態及びbxidの更新の有無は、Verification APIで判別可能です。
* 更新前のxid値はPreviousIDs APIで取得可能です。xid値の更新が発生してない場合にはnullを返します。
* PreviousIDs APIの返却値には複数のxid値が含まれます。例えば、2台の端末を所有しており、それぞれで異なるメール認証済みのxIDを作成したとします。そして、その後、双方の端末で公的個人認証を実施し他場合、更新後のxid値は同一の1つに対して、更新前のxidは2つとなるためです。

### エラーレスポンスについて
改めてまとめて共有させていただきます。
一例として、トークン期限切れの場合には、401 Unauthorizedを返却します。

### 脆弱性診断について
* **脆弱性診断を行う際にはスケジュールを共有するのか** = 可能であればお知らせいただけると助かります。また、負荷テスト等を実施する際にも、事前にお知らせください。
* **仮にマイナンバーカードを持っていない場合はどのようにテストを実施すればよいのか** = 現時点ではマイナンバーカードに関連する機能についてはマイナンバーカードの所有が必要です。署名検証事業者に対してテストカードの配布はあるものの、2次貸与が不可であり、弊社でも有効・失効・有効期限切れの各種1枚のみ貸与されている状況です。

### シノケン様からの問い合わせ
別途お話しさせてください。