検証可能なクレデンシャル偽造防御 v1.0

ウィットネスリスト・クレデンシャルは、 credentialSubjectがWitnessList型であり、 ウィットネスリストのプロパティ （witnessSeed、witnessLength、 witnessCount、およびencodedWitnesses）を直接保持する 検証可能な クレデンシャルである。発行者は、ウィットネスリスト・クレデンシャルに署名するために 別の鍵ペアを使用するべきであり（SHOULD）、かつ ポスト量子署名方式を使用してもよい（MAY）。 これは、それが提供する保護は、通常の署名鍵が侵害された後でも検証できる場合にのみ 意味を持つためである。

クレデンシャルのtype配列は、 WitnessListCredentialを含まなければならない（MUST）。

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/vc-forgery-defense/v1rc1"
  ],
  "id": "https://issuer.example/witnesses/1",
  "type": ["VerifiableCredential", "WitnessListCredential"],
  "issuer": "did:example:issuer",
  "validFrom": "2024-01-15T00:00:00Z",
  "credentialSubject": {
    "type": "WitnessList",
    "witnessSeed": "26ea4078-968d-4d98-aba7-695610c0dfb6",
    "witnessLength": 128,
    "witnessCount": 131072,
    "encodedWitnesses": "uQYF16SSSbR_LrMZFbFvbGkn8B7ggEZtov3KVL..."
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "comment": "MAY use a post-quantum cryptosuite here",
    "verificationMethod": "did:example:issuer#pq-key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z..."
  }
}

WitnessListCredentialsが発行者によって 空間制約のある媒体（大規模なクレデンシャルをWeb経由で配布する場合など）で配布される場合、 それらをCBOR-LD でエンコードし、バイトとして送信することが推奨される（RECOMMENDED）。

明示モードで使用される場合、保護対象の 検証可能な クレデンシャルは、その credentialStatus配列内に（または唯一の credentialStatus値として） ウィットネスリスト・ エントリを含んでもよい（MAY）。

エントリのtypeはWitnessListEntryでなければならない（MUST）。 検証可能なクレデンシャル・ビット文字列ステータス リストの statusListCredentialプロパティのパターンに従い、このエントリは、 明示的なwitnessListCredentialプロパティを通じて ウィットネスリスト・クレデンシャルを参照し、 その値はそのクレデンシャルのURLである。エントリのidが存在する場合、 それはエントリの任意の（OPTIONAL）一意識別子であり、 リストの場所の特定には使用されない。

witnessListCredential

REQUIRED。このクレデンシャルのウィットネスリスト・ クレデンシャルへ逆参照されるURL。このプロパティは、 検証可能なクレデンシャル・ビット文字列 ステータスリストにおける statusListCredentialに相当する。

witnessIndex

REQUIRED。参照されるリスト内におけるこのクレデンシャルの ウィットネスの位置を指定する正の整数（1始まり）。 0より大きくなければならず（MUST）、 witnessCountを超えてはならない（MUST NOT）。

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://w3id.org/vc-forgery-defense/v1rc1"
  ],
  "id": "https://issuer.example/credentials/1234",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "did:example:issuer",
  "validFrom": "2024-01-15T00:00:00Z",
  "credentialStatus": [
    {
      "id": "https://issuer.example/status/1#94567",
      "type": "BitstringStatusListEntry",
      "statusPurpose": "revocation",
      "statusListIndex": "94567",
      "statusListCredential": "https://issuer.example/status/1"
    },
    {
      "type": "WitnessListEntry",
      "witnessListCredential": "https://issuer.example/witnesses/1",
      "witnessIndex": 94567
    }
  ],
  "credentialSubject": {
    "id": "did:example:holder",
    "degree": {"type": "BachelorDegree", "name": "Computer Science"}
  },
  "proof": { ... }
}

次のアルゴリズムは、N個のクレデンシャルハッシュの集合に対する ウィットネスリストを生成する。 入力は、望ましいwitnessIndex値の順序に並べられた N個のハッシュの配列、およびウィットネス長b（デフォルト128）である。 出力は、ウィットネスシードおよびエンコード済みウィットネスである。

1. 暗号学的に安全な乱数生成器を使用して、UUID v4値seedを生成する [RFC4122]。
2. seedBytesを、seedの16バイト表現とする。 これは、ハイフンを除去した16進数字をビッグエンディアンのバイト列として デコードすることによって得られる。
3. dataを、N × bビットのゼロ化されたビット配列とする。
4. 0からN-1まで（両端を含む）の各整数iについて:
   1. msgを、入力配列のi番目のクレデンシャルハッシュとする。
   2. hashを、連結seedBytes || msgに適用された SHA-256 [FIPS-180-4]の出力とする。
   3. wを、 hashの最上位bビットとする。
   4. wを、dataのビットオフセット (i − 1) × bに、最上位ビット優先で書き込む。
5. encodedWitnessesを、dataのmultibase-base64urlエンコードとし、 接頭辞文字uを前置したものとする [MULTIBASE]。
6. seedおよびencodedWitnessesを返す。

次のアルゴリズムは、 ウィットネスリストの生成の出力を、 署名済みの検証可能なクレデンシャルにラップする。

1. 入力Nおよびbを用いて ウィットネスリストの生成を実行し、 seedおよびencodedWitnessesを生成する。
2. 次を持つ未署名のクレデンシャルを構築する:
   • typeはWitnessListCredentialを含む
   • credentialSubject.typeをWitnessListに設定する
   • credentialSubject.witnessSeedを seedに設定する
   • credentialSubject.witnessLengthを bに設定する
   • credentialSubject.witnessCountを Nに設定する
   • credentialSubject.encodedWitnessesを encodedWitnessesに設定する
3. クレデンシャルに署名する。量子鍵侵害を含む鍵侵害に対する保護が必要な場合、 発行者は、ポスト量子署名方式と、保護対象のクレデンシャルに署名するために 使用されるものとは別の鍵ペアを使用するべきである（SHOULD）。
4. 署名済みクレデンシャルを返す。

次のアルゴリズムは、指定されたクレデンシャルのウィットネスが 有効であることを検証する。入力は、解決済みの ウィットネスリスト・クレデンシャル、 クレデンシャルハッシュ、および ウィットネスインデックスiである。

1. ウィットネスリスト・クレデンシャル上の すべての証明を検証する。いずれかの証明が失敗した場合、エラーを返す。
2. subjectを、ウィットネスリスト・クレデンシャルの credentialSubjectとする。
3. seedをsubject.witnessSeedとする。
4. bをsubject.witnessLengthとする。
5. Nをsubject.witnessCountとする。
6. i < 1またはi > Nの場合、 インデックスが範囲外であることを示すエラーを返す。
7. encodedWitnessesを subject.encodedWitnessesとする。
8. encodedWitnessesが文字 uで始まることを検証する。そうでなければ、エラーを返す。
9. dataを、encodedWitnessesの最初の文字の後の部分文字列を base64urlデコードした結果とする。
10. dataから、オフセット(i − 1) × bから i × b − 1までのビットを、最上位ビット優先で抽出する。 これをstoredWとする。
11. seedBytesを、seedの16バイト表現とする。 これは、ハイフンを除去した16進数字をビッグエンディアンのバイト列として デコードすることによって得られる。
12. msgを入力クレデンシャルハッシュとする。
13. hashを、 seedBytes || msgのSHA-256 [FIPS-180-4]とする。
14. computedWを、 hashの最上位bビットとする。
15. storedWがcomputedWと等しい場合、 validを返す。そうでなければinvalidを返す。

暗黙モードでは、保護対象のクレデンシャルは変更されない。 クレデンシャル自体にはウィットネスリストへの参照は現れない。 検証者は、通常はクレデンシャルの既存の credentialStatusエントリから導出される帯域外情報を使用して、 ウィットネスリストの場所を特定し、ステータスリストインデックスを ウィットネスインデックスとして再利用する。

このモードでは次が要求される（REQUIRES）:

• 保護対象のクレデンシャルが、ウィットネスリスト内の位置と1対1で対応する インデックスを持つBitstringStatusListEntry（または同等のもの）を 持っていること。
• 発行者が、たとえばwell-knownエンドポイントまたはDID文書内のエントリなど、 指定されたステータスリストURLを対応するウィットネスリスト・クレデンシャル URLにマップする発見機構を公開していること。

// Protected credential has:
//   credentialStatus.statusListCredential = "https://issuer.example/status/1"
//   credentialStatus.statusListIndex      = "94567"

// Verifier discovers witness list URL from issuer metadata:
// GET https://issuer.example/.well-known/witness-lists
// -> { "https://issuer.example/status/1":
//      "https://issuer.example/witnesses/1" }

// Witness index = 94567 (same as status list index)
// Run: Verify a Credential Witness with i = 94567

明示モードでは、保護対象のクレデンシャルは そのcredentialStatus内に ウィットネスリスト・エントリを含む。 そのエントリのwitnessListCredentialプロパティは ウィットネスリスト・クレデンシャルURLを与え、 witnessIndexはリスト内の1始まりの位置を指定する。 発見機構は必要ない。

明示モードは、（失効用のBitstringStatusListEntryなどの） 他のcredentialStatusエントリと共存してもよい（MAY）。 両方が存在する場合、witnessIndexはステータスリストインデックスと 等しくなくてもよい。

スタンドアロンモードでは、ウィットネスリストは いかなるステータスリスト基盤からも独立して使用される。 クレデンシャルへのウィットネスインデックスの割り当ては、 特定のアプリケーションまたはユースケースによって定義される。 ウィットネスリスト・クレデンシャルは、クレデンシャル、アプリケーション層のレコード、 または外部レジストリから参照されてもよい（MAY）が、 参照機構はこの仕様の範囲外である。

量子能力を持つ敵対者は、従来型（たとえばECDSA）の公開鍵に対応する秘密鍵を 復元できる。発行者がウィットネスリスト・クレデンシャルを ポスト量子署名方式で署名している場合、ポスト量子鍵が安全なままである限り、 検証者は、そのリスト上のクレデンシャルの署名鍵が破られた後でも ウィットネスリストを信頼できる。

発行者は、それが対象とするクレデンシャルが高い価値または長い有効期間を持つ場合、 ウィットネスリスト・クレデンシャルにポスト量子署名方式で署名するべきである （SHOULD）。

ウィットネスシードは、ウィットネスリスト・クレデンシャルの credentialSubject内に現れ、そのウィットネスリスト・クレデンシャルを取得する 任意の主体に見える。これは設計上のものであり、検証者はウィットネスを再計算するために シードを必要とする。検証を特定の検証者集合に制限したい発行者は、 ウィットネスリスト・クレデンシャルの配布をそれに応じて制限するべきである（SHOULD）。

インデックスiにある偽造クレデンシャルは、 bをウィットネス長とすると、 確率2^−bでウィットネス検証に合格する。 デフォルトのb = 128では、この確率はおよそ2.9 × 10⁻³⁹である。

実装は、bが32未満の値を受け入れてはならない（MUST NOT）。 高価値のクレデンシャルには、最小値64が推奨される（RECOMMENDED）。

ウィットネスは、一般に衝突耐性を持つように計算されるべきである （SHOULD）が、第二原像耐性を持つように計算されなければならない （MUST）。

検証者は、その内容を信頼する前に、ウィットネスリスト・ クレデンシャル上の証明を検証しなければならない（MUST）。 検証者は、ネットワーク露出およびサービス拒否リスクを低減するため、 解決済みウィットネスリスト・クレデンシャルをその有効期間中キャッシュするべきである （SHOULD）。

リストが対象とする発行済み 検証可能なクレデンシャルの数に witnessCountを正確に合わせると、 発行者のプロセスに関する情報が2つの方法で漏えいする:

• ある時点のウィットネス総数は、その時点でいくつの発行済みVCが存在するかを 攻撃者に知らせる。
• 時間の経過に伴うウィットネス総数を追跡すると、単位時間あたりに いくつのVCが発行されているかが攻撃者に知られる。

最初の漏えいを軽減するため、発行者は固定されたwitnessCount 値を使用するべきであり（SHOULD）、すべてのウィットネスリスト全体で ウィットネスの総数が変化しないようにし、任意データのウィットネスプレースホルダーを、 時間の経過とともにVCに対応するウィットネスで置き換えていく。

これは最初の漏えいを軽減するには十分である。しかし、攻撃者は依然として、 時間の経過に伴いどのウィットネス値が変化するかを追跡することで、 いくつのウィットネスが「本物」であり、いくつのVCが発行されているかを 追跡できる。この問題に対処するため、発行者はWitnessListCredentialを更新するたびに、 ランダムウィットネスシードを再生成しなければならない（MUST）。

公開されたウィットネスリスト・クレデンシャルを、攻撃者が改変版に置き換えられる場合、 その攻撃者は偽造防止機構を迂回できる。発行者は、完全性が保護されたチャネル上で ウィットネスリスト・クレデンシャルを公開しなければならず（MUST）、 短い有効期間と頻繁な再発行を組み合わせて使用するべきである（SHOULD）。

発行者はウィットネスリスト・クレデンシャルの 唯一の作成者であり、 リストが更新されるたびにウィットネスシードを 再生成することが要求される（REQUIRED） （7.5 発行者情報の漏えいを参照）。したがって、発行者は、 以前に発行したクレデンシャルについて、そのクレデンシャルの ウィットネスが存在しない、または変更された 新しいウィットネスリスト・クレデンシャルを公開することで、 そのクレデンシャルを否認できる。検証者が最新のリストに対して ウィットネスを再計算すると不一致となり、 他の点では真正なクレデンシャルを拒否する。偽造とは異なり、この動作は 正当な発行者に可能であり、公開された各リストは有効に署名されたクレデンシャルであるため、 この仕組みだけでは防止できない。

後の否認を超えて発行の証拠を残す必要がある依拠当事者は、 依拠したウィットネスリスト・クレデンシャルを、 その証明および有効期間とともに保持（キャッシュまたはアーカイブ）するべきである （SHOULD）。各 ウィットネスリスト・クレデンシャルは、それ自体が validFrom値を持つ署名済みの 検証可能なクレデンシャルであるため、 否認前に公開されたリストに対して検証されたクレデンシャルは、 その以前のリスト時点では真正であったことを引き続き示すことができる。 キャッシュされた署名済みリストは、発行者がその時点でクレデンシャルを証明したことを示す 持続的な証拠である。公開リストに対する独立したアーカイブ、公証、または透明性ログによる ウィットネスは、発行者の公開履歴を否認不能にすることで、この保証を強化する。

witnessCount値は、バッチ内のクレデンシャルの最大数を明らかにする。 発行者は、個々の保持者がリスト内の位置によって識別されないように、 大きな集合サイズ（少なくとも131072エントリ）を使用しなければならない （MUST）。そのような集合内のすべてのスロットは、 ウィットネスを作成するために使用されるハッシュが検証可能なクレデンシャルに 対応しているかどうかにかかわらず、埋められていなければならない。

ウィットネスリスト・クレデンシャルを取得することは、 検証が行われていることをホストに明らかにする可能性のあるネットワーク要求を生成する。 検証者は、ウィットネスリスト・クレデンシャルをキャッシュするべきであり（SHOULD）、 リストを取得する際にプライバシー保護ネットワークトランスポートを使用してもよい （MAY）。発行者は、相関能力を低減するため、CDNまたは コンテンツアドレス指定システムを通じてウィットネスリストを提供するべきである （SHOULD）。