検証可能なクレデンシャル・データ完全性 1.1

データ完全性証明は、 証明機構、その証明を検証するために必要なパラメータ、および証明値そのものに関する 情報を提供する。この情報はすべて、 The Security Vocabulary などのリンクトデータ語彙を使用して提供される。

オブジェクト上でデータ完全性証明を表現する場合、 proof プロパティを使用しなければならない (MUST)。 検証可能なクレデンシャル 内の proof プロパティは名前付きグラフである。存在する場合、 その値は、以下のプロパティを使用して表現される、単一のオブジェクト、または 順序なしのオブジェクト集合のいずれかでなければならない (MUST):

id

証明の任意の識別子であり、URL [URL] でなければならない (MUST)。たとえば URN としての UUID (urn:uuid:6a1676b8-b51f-11ed-937b-d76685a20ff5) などである。 このプロパティの使用法は、2.1.2 証明 チェーン節でさらに説明される。

type

証明の具体的な型は、URL [URL] に対応付けられる 文字列として指定されなければならない (MUST)。 証明型の例には DataIntegrityProof および Ed25519Signature2020 が含まれる。証明型は、証明を保護および検証するために 他にどのフィールドが必要かを決定する。

proofPurpose

証明が作成された理由は、URL [URL] に対応付けられる 文字列として指定されなければならない (MUST)。証明目的は、その証明が意図されたもの以外の目的に 適用されて悪用されることを防ぐ保護手段として機能する。たとえば、この値がないと、 証明の作成者は、ログイン処理 (authentication) の間に、通常は検証可能な クレデンシャル (assertionMethod) を作成するために使用される暗号材料を 使用するようだまされる可能性があり、その結果、単に Web サイトにログインするという 意図された行為ではなく、作成するつもりのなかった 検証可能な クレデンシャルが作成されてしまう。

verificationMethod

検証メソッドとは、証明を検証するために必要な手段および情報である。 含まれる場合、その値は [URL] に対応付けられる 文字列でなければならない (MUST)。 verificationMethod の包含は任意である (OPTIONAL) が、 含まれない場合は、cryptosuite などの他のプロパティが、 証明を検証するために必要な情報を取得するための仕組みを提供する可能性がある。 verificationMethod がデータ完全性証明内で 表現される場合、その値はデータの実際の場所を指すことに注意する。すなわち、 verificationMethod は、URL を介して、証明を検証するために使用できる 公開鍵の場所を参照する。この 公開鍵データは、 検証メソッドの完全な説明を含む 制御識別子 文書に格納される。

cryptosuite

証明を検証するために使用できる暗号スイートの識別子。詳細については 3. 暗号スイートを参照。証明の type が DataIntegrityProof である場合、cryptosuite は 指定されなければならない (MUST)。それ以外の場合、 cryptosuite は指定してもよい (MAY)。指定される場合、 その値は文字列でなければならない (MUST)。

created

証明が作成された日時は任意であり (OPTIONAL)、含まれる場合は、 [XMLSCHEMA11-2] dateTimeStamp 文字列として指定されなければならない (MUST)。これは、値の末尾に Z で示される協定世界時 (UTC)、または UTC に対するタイムゾーンオフセット付きのいずれかである。 適合するプロセッサは、 オフセットなしで誤ってシリアル化された時刻値を消費することを選択してもよい (MAY)。オフセットなしで誤ってシリアル化された時刻値は UTC として解釈されるものとする。

expires

expires プロパティは任意であり (OPTIONAL)、存在する場合は、 証明がいつ失効するかを指定する。存在する場合、それは [XMLSCHEMA11-2] dateTimeStamp 文字列でなければならない (MUST)。 これは、値の末尾に Z で示される協定世界時 (UTC)、または UTC に対する タイムゾーンオフセット付きのいずれかである。適合するプロセッサは、 オフセットなしで誤ってシリアル化された時刻値を消費することを選択してもよい (MAY)。オフセットなしで誤ってシリアル化された時刻値は UTC として解釈されるものとする。

domain

domain プロパティは任意である (OPTIONAL)。 これは、証明が使用されることを意図された1つ以上のセキュリティドメインを伝える。 指定される場合、関連する値は文字列、または順序なしの文字列集合のいずれかで なければならない (MUST)。検証者は、その値を用いて、 証明が検証者の動作するセキュリティドメインで使用されることを意図していたことを 確保するべきである (SHOULD)。domain パラメータの指定は、 検証者が証明の作成者に知られているセキュリティドメイン内で動作している チャレンジレスポンスプロトコルで有用である。ドメイン値の例には、 domain.example (DNS ドメイン)、https://domain.example:8443 (Web オリジン)、mycorp-intranet (独自のテキスト文字列)、および b31d37d4-dd59-47d3-9dd8-c973da43b63a (UUID) が含まれる。

challenge

文字列値であり、 domain が指定される場合、証明に含めるべきである (SHOULD)。この値は、特定の ドメインおよび時間枠に対して一度だけ 使用される。この値はリプレイ攻撃を軽減するために使用される。 challenge 値の例には、 1235abcd6789、79d34551-ae81-44ae-823b-6dadbab9ebd4、および ruby が含まれる。

proofValue

指定された verificationMethod を使用してデジタル証明を検証するために 必要な、base 符号化されたバイナリデータを表す 文字列値。 この値は、バイナリデータを表すために 制御識別子 v1.0仕様の 2.4 Multibase節で説明される ヘッダーおよび符号化を使用しなければならない (MUST)。 この値の内容は、特定の暗号スイートによって決定され、その暗号スイートの 証明追加アルゴリズムによって生成された 証明値に設定される。暗号スイートによって異なる符号化が指定された 代替プロパティは、デジタル証明を検証するために必要なデータを符号化するため、 このプロパティの代わりに使用してもよい (MAY)。

previousProof

previousProof プロパティは任意である (OPTIONAL)。 存在する場合、それは文字列値または順序なしの文字列値リストでなければならない (MUST)。各値は別の データ完全性証明を識別し、それらすべては、 現在の証明が検証済みと見なされるために、同じく検証されなければならない (MUST)。このプロパティは 2.1.2 証明チェーン節で使用される。

nonce

証明作成者によって提供される任意の (OPTIONAL) 文字列値。このフィールドの一つの用途は、 決定論的に生成される署名の結果として生じるリンク可能性を低下させることで、 プライバシーを高めることである。

次のように、JSON 文書に証明を追加できる:

{
  "myWebsite": "https://hello.world.example/"
};

次の証明は、上記の文書を eddsa-jcs-2022 暗号スイート [DI-EDDSA] を 使用して保護する。この暗号スイートは、JSON Canonicalization Scheme (JCS) [RFC8785] を使用して入力データを変換し、 その後 Edwards Digital Signature Algorithm (EdDSA) を使用してデジタル署名することで、 検証可能なデジタル証明を生成する。

{
  "myWebsite": "https://hello.world.example/",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "created": "2023-03-05T19:23:24Z",
    "verificationMethod": "https://di.example/issuer#z6MkjLrk3gKS2nnkeWcmcxiZPGskmesDpuwRBorgHxUXfxnG",
    "proofPurpose": "assertionMethod",
    "proofValue": "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"
  }
}

同様に、次のような JSON-LD データ文書に証明を追加できる:

{
  "@context": {"myWebsite": "https://vocabulary.example/myWebsite"},
  "myWebsite": "https://hello.world.example/"
};

次の証明は、ecdsa-rdfc-2019 暗号スイート [DI-ECDSA] を 使用して上記の文書を保護する。この暗号スイートは、RDF Dataset Canonicalization Scheme [RDF-CANON] を使用して入力データを変換し、 その後 Elliptic Curve Digital Signature Algorithm (ECDSA) を使用してデジタル署名することで、 検証可能なデジタル証明を生成する。

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://w3id.org/security/data-integrity/v2"
  ],
  "myWebsite": "https://hello.world.example/",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2020-06-11T19:14:04Z",
    "verificationMethod": "https://ldi.example/issuer#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
    "proofPurpose": "assertionMethod",
    "proofValue": "zXb23ZkdakfJNUhiTEdwyE598X7RLrkjnXEADLQZ7vZyUGXX8cyJZRBkNw813SGsJHWrcpo4Y8hRJ7adYn35Eetq"
  }
}

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://w3id.org/security/data-integrity/v2"
  ],
  "myWebsite": "https://hello.world.example/",
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2020-06-11T19:14:04Z",
    // 証明は作成から1か月後に失効する
    "expires": "2020-07-11T19:14:04Z",
    "verificationMethod": "https://ldi.example/issuer#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
    "proofPurpose": "assertionMethod",
    "proofValue": "z98X7RLrkjnXEADJNUhiTEdwyE5GXX8cyJZRLQZ7vZyUXb23ZkdakfRJ7adYY8hn35EetqBkNw813SGsJHWrcpo4"
  }
}

Data Integrity 仕様は、単一の文書内に複数の証明を置く概念をサポートする。 識別される複数証明アプローチには、証明セット (順序なし) と 証明チェーン (順序あり) の2種類がある。

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://w3id.org/security/data-integrity/v2"
  ],
  "myWebsite": "https://hello.world.example/",
  "proof": [{
    // これは集合内の証明の1つである
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2020-11-05T19:23:24Z",
    "verificationMethod": "https://ldi.example/issuer/1#z6MkjLrk3gKS2nnkeWcmcxiZPGskmesDpuwRBorgHxUXfxnG",
    "proofPurpose": "assertionMethod",
    "proofValue": "z4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYVQeVbY8nQAVHMrXFkXJpmEcqdoDwLWxaqA3Q1geV6"
  }, {
    // これは集合内のもう1つの証明である
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2020-11-05T13:08:49Z",
    "verificationMethod": "https://pfps.example/issuer/2#z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP",
    "proofPurpose": "assertionMethod",
    "proofValue": "z5QLBrp19KiWXerb8ByPnAZ9wujVFN8PDsxxXeMoyvDqhZ6Qnzr5CG9876zNht8BpStWi8H2Mi7XCY3inbLrZrm95"
  }]
}

{
  "@context": [
    {"myWebsite": "https://vocabulary.example/myWebsite"},
    "https://w3id.org/security/data-integrity/v2"
],
  "myWebsite": "https://hello.world.example/",
  "proof": [{
    // 'id' 値は、この特定の証明を識別する
    "id": "urn:uuid:60102d04-b51e-11ed-acfe-2fcd717666a7",
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2020-11-05T19:23:42Z",
    "verificationMethod": "https://ldi.example/issuer/1#z6MkjLrk3gKS2nnkeWcmcxiZPGskmesDpuwRBorgHxUXfxnG",
    "proofPurpose": "assertionMethod",
    "proofValue": "zVbY8nQAVHMrXFkXJpmEcqdoDwLWxaqA3Q1geV64oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYVQe"
  }, {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-rdfc-2022",
    "created": "2020-11-05T21:28:14Z",
    "verificationMethod": "https://pfps.example/issuer/2#z6MkGskxnGjLrk3gKS2mesDpuwRBokeWcmrgHxUXfnncxiZP",
    "proofPurpose": "assertionMethod",
    "proofValue": "z6Qnzr5CG9876zNht8BpStWi8H2Mi7XCY3inbLrZrm955QLBrp19KiWXerb8ByPnAZ9wujVFN8PDsxxXeMoyvDqhZ",
    // 'previousProof' 値は、この証明の前にどの証明が検証されるかを識別する
    "previousProof": "urn:uuid:60102d04-b51e-11ed-acfe-2fcd717666a7"
  }]
}

目的を記述する証明は、他の目的に悪用されることを防ぐのに役立つ。 証明の目的は、 検証者が 証明作成者の意図を知ることを可能にし、メッセージが誤って別の目的に 悪用されないようにする。たとえば、単に主張を行う目的で署名された メッセージ (広く共有されることが意図されている可能性がある) が、 サービスへの認証や何らかのアクション (何かを行う capability を呼び出すなど) のための メッセージとして悪用されることを防ぐ。

証明の目的は、 JSON Web Key (JWK) における key_ops 制限、 Web Cryptography API における KeyUsage 制限、および Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile とは 異なる仕組みであることに注意することが重要である。証明の目的は、 証明が作成された理由とその意図された利用ドメインを表すものである一方、 上記の他の仕組みは、私有鍵を何に使用できるかを制限することを意図している。 証明の目的は 証明とともに「移動」するが、鍵制限はそうではない。

次に、一般的に使用される証明の目的値の一覧を示す。

authentication

与えられた証明が、認証プロトコルの目的にのみ使用されることを示す。

assertionMethod

証明が、たとえば 検証可能な クレデンシャルへの署名など、主張を行うためにのみ使用できることを示す。

keyAgreement

証明が、一般的な暗号化ライブラリで使用される Elliptic Curve Diffie Hellman 鍵共有など、鍵共有プロトコルに使用されることを示す。

capabilityDelegation

証明が capability の委任にのみ使用できることを示す。詳細については Authorization Capabilities [ZCAP] 仕様を参照。

capabilityInvocation

証明が capability の呼び出しにのみ使用できることを示す。詳細については Authorization Capabilities [ZCAP] 仕様を参照。

外部リソースへのリンクが 適合する保護済み文書に含まれる場合、 識別されたリソースが証明の作成後に変更されたかどうかを知ることが望ましい。 これは、外部リソースがリモートから取得される場合だけでなく、 検証者が そのリソースのローカルにキャッシュされたコピーを持っている可能性がある場合にも適用される。

適合する保護済み文書によって参照される リソースが、その文書が保護されてから変更されていないことを確認できるようにするため、 実装者は、id プロパティを含む任意のオブジェクトに digestMultibase という名前のプロパティを含めてもよい (MAY)。存在する場合、digestMultibase 値は、 単一の文字列値、 または文字列値の リストでなければならず (MUST)、各値は Multibase 符号化された Multihash 値である。

JSON-LD コンテキストの著者は、他のリソースを参照する文書で使用される コンテキストに digestMultibase を追加し、関連する暗号学的ダイジェストを 含めることが期待される。たとえば、 検証可能なクレデンシャル・データモデル v2.0 の基本コンテキスト (https://www.w3.org/ns/credentials/v2) は digestMultibase プロパティを含む。

リソース完全性で保護されたオブジェクトの例を以下に示す:

{
  ...
  "image": {
    "id": "https://university.example.org/images/58473",
    "digestMultibase": "zQmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n"
  },
  ...
}

実装者は、自身のユースケースに適したハッシュアルゴリズムを選択していることを 確保するため、 FIPS 180-4 Secure Hash Standard および Commercial National Security Algorithm Suite 2.0 などの 適切な情報源を参照することが強く求められる。

JSON-LD 処理を行う実装は、以下の JSON-LD コンテキスト URL をすでに解決済みとして扱い、 解決済み文書が以下の対応するハッシュ値に一致するものとしなければならない (MUST):

上記に列挙された暗号学的ダイジェストは、現代的な UNIX 系 OS のコマンドライン インターフェイスを通じて、次のようなコマンドを実行することで確認できる (<DOCUMENT_URL> を適切な値に置き換える): curl -sL -H "Accept: application/ld+json" <DOCUMENT_URL> | openssl dgst -sha256

上記に列挙された JSON-LD コンテキストが解決するセキュリティ語彙用語は、 https://w3id.org/security# 名前空間内にある。すなわち、この語彙内のすべてのセキュリティ用語は https://w3id.org/security#TERM という形式であり、ここで TERM は用語の名前である。

RDF 処理を行う実装は、語彙 URL の JSON-LD シリアル化を すでに参照解除済みとして扱い、その参照解除済み文書が 以下の対応するハッシュ値に一致するものとしなければならない (MUST)。

https://w3id.org/security# URL を 参照解除する場合、返されるデータのメディアタイプは HTTP コンテンツネゴシエーションに 依存する。これらは次のとおりである:

上記に列挙された暗号学的ダイジェストは、現代的な UNIX 系 OS のコマンドライン インターフェイスを通じて、次のようなコマンドを実行することで確認できる (<MEDIA_TYPE> および <DOCUMENT_URL> を適切な値に置き換える): curl -sL -H "Accept: <MEDIA_TYPE>" <DOCUMENT_URL> | openssl dgst -sha256

アプリケーション固有の語彙および仕様の著者は、自身の JSON-LD コンテキストおよび 語彙ファイルが、上記で説明したキャッシュ手法または機能的に等価な仕組みを用いて 永続的にキャッシュ可能であることを確保すべきである (SHOULD)。

実装は、開発中にアプリケーション固有の JSON-LD コンテキストファイルを ネットワークから読み込んでもよい (MAY) が、 本番環境では、セキュリティおよびプライバシー特性を高めるため、 適合する保護済み文書で使用される JSON-LD コンテキストファイルを永続的にキャッシュすべきである (SHOULD)。処理速度の目標は、上記で説明したような キャッシュ手法または機能的に等価な仕組みによって達成してもよい (MAY)。

デジタルウォレットなど、一部のアプリケーションは、任意の発行者からの任意の 検証可能なクレデンシャル または他のデータ完全性保護済み文書を、任意のコンテキストを用いて保持できるため、 本番環境で JSON-LD コンテキストファイルなど外部リンクされたリソースを 読み込める必要があるかもしれない。これは、時間とともにエコシステムにおける ユーザーの選択肢、スケーラビリティ、および分散型アップグレードを高めることが 期待される。そのようなアプリケーションの著者には、さらなる考慮事項について、 この文書のセキュリティおよびプライバシーの節を読むことが助言される。

JSON-LD コンテキストおよび語彙の処理に関するさらなる情報については、 検証可能な クレデンシャル v2.0: 基本コンテキストおよび 検証可能なクレデンシャル v2.0: 語彙を参照。

Linked Data という用語は、URL などの標準を用いて、ものおよびそのプロパティを 識別し、Web 上で情報を公開、共有、接続するための推奨されるベストプラクティスを 説明するために使用される。情報が Linked Data として提示される場合、 他の関連情報を容易に発見でき、新しい情報を容易にそれへリンクできる。 Linked Data は分散的な方法で拡張可能であり、大規模統合への障壁を大幅に低減する。

Linked Data のさまざまなアプリケーションでの利用が増加するにつれ、 Linked Data 文書の真正性と完全性を検証できる必要がある。本仕様は、 Linked Data の拡張性および合成可能性などの機能を犠牲にすることなく、 数学的証明の使用を通じてデータ文書に認証および完全性保護を追加する。

本仕様を実装する暗号スイートは、 検証可能なクレデンシャル および検証可能な プレゼンテーションを保護するために使用できる。これらのユースケースに 対応する実装者は、その種類の文書を処理する際に追加の確認が適切である可能性が あることに注意すべきである。

証明で使用される 検証 メソッドが、 issuer と 検証可能なクレデンシャルにおいて関連付けられていること、または holder と 検証可能なプレゼンテーションにおいて、 妥当性確認の過程で 関連付けられていることを確保することが重要なユースケースがある。 そのような関連付けを確認する一つの方法は、証明の 検証メソッドの controller プロパティの値が、 issuer または holder を識別するために 使用される URL 値とそれぞれ一致し、 かつ検証メソッドが、証明の目的を踏まえて受け入れ可能な検証関係の下に 表現されていることを確保することである。この特定の関連付けは、 issuer または holder がそれぞれ、 証明を検証するために使用される 検証 メソッドの controller であることを示す。

文書著者および実装者には、証明の有効期間と クレデンシャルの 有効期間の違いを理解することが助言される。前者は created および expires プロパティを用いて表現され、 後者は validFrom および validUntil プロパティを用いて表現される。 これらのプロパティは同じ有効期間を表す場合もあるが、 必ずしも一致するとは限らない。証明を検証する場合、 関心時刻 (現在時刻または任意の他の時刻であり得る) が証明の有効期間内、 すなわち created と expires の間にあることを確保することが重要である。 妥当性確認によって 検証可能なクレデンシャルを 検証する場合、関心時刻が クレデンシャルの 有効期間内、すなわち validFrom と validUntil の間に あることを確保することが重要である。証明の有効期間、 または クレデンシャルの有効期間の いずれかを検証し損なうと、本来拒否されるべきデータを受け入れる結果になる可能性が あることに注意する。

最後に、実装者には、 検証可能なクレデンシャルに 関連付けられた失効情報と、 検証 メソッドの 失効 および有効期限時刻との間には 違いがあることも理解することが強く求められる。 検証 メソッドの 失効および 有効期限時刻は、それぞれ revocation および expires プロパティを用いて表現される。 それらは、秘密鍵が 危殆化した、または期限切れになったなどの事象に関連し、controller の詳細、 たとえばそのセキュリティ慣行や危殆化された可能性のある時期などを明らかにし得る タイミング情報を提供できる。検証可能なクレデンシャルの 失効情報は credentialStatus プロパティを用いて表現される。 これは、個人が 検証可能なクレデンシャルによって 付与される特権を失うなどの事象に関連し、プライバシーを高めるため、 タイミング情報を提供しない。

多くの暗号スイートは、 データ完全性証明を表現する際に同じ基本パターンに 従う。この節では、その一般的な設計パターン、すなわち DataIntegrityProof と呼ばれる 暗号スイート型を規定する。 これは、設計プリミティブおよびソースコードの再利用を通じて、 暗号スイートの 作成および実装の負担を軽減する。

この設計パターンを利用する暗号スイートを指定する場合、 proof 値は次の形式をとる:

type

type プロパティは、文字列 DataIntegrityProof を含まなければならない (MUST)。

cryptosuite

cryptosuite プロパティの値は、 暗号スイートを識別する 文字列で なければならない (MUST)。処理環境が 文字列 サブタイプをサポートする場合、cryptosuite 値のサブタイプは https://w3id.org/security#cryptosuiteString サブタイプでなければならない (MUST)。

proofValue

proofValue プロパティは、 2.1 証明節で規定されているように使用しなければならない (MUST)。

暗号スイートの設計者は、 2.1 証明節で定義された必須の proof 値プロパティを使用しなければならず (MUST)、 自身の暗号スイートに固有の他のプロパティを定義してもよい (MAY)。

次のアルゴリズムは、証明または証明セット/チェーンのいずれかを含む保護済み文書から開始して、 証明セットまたは証明チェーンに証明を段階的に追加する方法を規定する。必須入力は、 保護済みデータ文書 (map securedDocument)、暗号スイート (cryptosuite instance suite)、およびオプションの集合 (map options) である。出力は新しい 保護済みデータ文書 (map) である。このアルゴリズムが文字列を符号化する場合は常に、 UTF-8 符号化を使用しなければならない (MUST)。

1. proof を securedDocument.proof に設定する。 allProofs を空のリストとする。proof がリストである場合、 proof のすべての要素を allProofs にコピーする。proof がオブジェクトである場合、そのオブジェクトのコピーを allProofs に追加する。
2. inputDocument を、proof 属性を取り除いた securedDocument のコピーとする。output を inputDocument のコピーとする。
3. matchingProofs を空のリストとする。
4. options が文字列である previousProof itemを持つ場合、 previousProof と一致する id 属性を持つ allProofs 内の要素を matchingProofs に追加する。previousProof に等しい id を持つ証明が allProofs 内に存在しない場合、エラーを発生させなければならず (MUST)、 PROOF_GENERATION_ERROR のエラー型を伝えるべきである (SHOULD)。
5. options が配列である previousProof itemを持つ場合、その配列の要素と一致する id 属性を持つ allProofs 内の各要素を追加する。 previousProof list のいずれかの要素が、 allProofs のいずれの要素の id 属性にも一致しない id 属性を持つ場合、エラーを発生させなければならず (MUST)、 PROOF_GENERATION_ERROR のエラー型を伝えるべきである (SHOULD)。
6. inputDocument.proof を matchingProofs に設定する。
   注記: この手順は文書および既存の 証明を保護する

   この手順は、名前付き グラフへの参照を追加するとともに、 証明 グラフに含まれるすべてのクレームのコピーを追加する。 この手順は、現在の証明を適用する前に、一致する証明を文書へ 束縛するため重要である。文書の proof 値は、 このアルゴリズムの後の手順で更新される。

7. 4.2 証明の追加節の アルゴリズムの手順1から6を、inputDocument、suite、および options を渡して実行する。例外が発生しない場合、生成された proof 値を allProofs に追加する。それ以外の場合は例外を発生させる。
8. output.proof を allProofs の値に設定する。
9. output を新しい保護済みデータ文書として返す。

次のアルゴリズムは、デジタル証明を検証することによって、 保護済みデータ文書の真正性および完全性を 確認する方法を規定する。このアルゴリズムは次を入力として受け取る:

mediaType

[MIMESNIFF] で定義される メディアタイプ

documentBytes

メディアタイプが mediaType である バイト列

cryptosuite

cryptosuite instance

expectedProofPurpose

任意の文字列であり、 proof が検証者によって期待される理由で証明作成者により生成されたことを 確保するために使用される。一般的な値については、2.2 証明の 目的を参照。

domain

任意の文字列の 集合であり、 証明作成者が証明を特定のセキュリティドメインへ固定するため、および検証者が 証明が異なるセキュリティドメイン間で使用されていないことを確保するために使用する。

challenge

任意の文字列 challengeであり、攻撃者が以前に作成された証明を リプレイしていないことを検証者が確保するために使用する。

このアルゴリズムは、検証結果、すなわち structを返す。その 項目は次のとおりである:

verified

true または false

verifiedDocument

verified が false の場合は Null。そうでない場合は、 入力文書

mediaType

verified が false の場合は Null。そうでない場合は、 メディアタイプであり、 パラメータを含んでもよい (MAY)。

warnings

ProblemDetails のリストであり、 デフォルトでは空のリストである。

errors

ProblemDetails のリストであり、 デフォルトでは空のリストである。

手順が「エラーを発生させなければならない (MUST)」という場合、 それは検証結果が、 verified 値 false および空でない errors リストを伴って 返されなければならないことを意味する。

1. securedDocument を、documentBytes に対して parse JSON bytes to an Infra valueを実行した結果とする。
2. securedDocument が mapではない、または securedDocument.proof がmapではない場合、 エラーを発生させなければならず (MUST)、 PARSING_ERROR のエラー型を伝えるべきである (SHOULD)。
3. proof を securedDocument.proof とする。
4. proof.type、 proof.verificationMethod、および proof.proofPurpose の1つ以上が 存在しない場合、 エラーを発生させなければならず (MUST)、 PROOF_VERIFICATION_ERROR のエラー型を伝えるべきである (SHOULD)。
5. expectedProofPurpose が与えられており、それが proof.proofPurpose と一致しない場合、 エラーを発生させなければならず (MUST)、 PROOF_VERIFICATION_ERROR のエラー型を伝えるべきである (SHOULD)。
6. domain が与えられており、それが proof.domain と同じ 文字列を含まない場合 (単一の文字列は、その 文字列だけを含む 集合として扱う)、 エラーを発生させなければならず (MUST)、 INVALID_DOMAIN_ERROR のエラー型を伝えるべきである (SHOULD)。
7. challenge が与えられており、それが proof.challenge と一致しない場合、 エラーを発生させなければならず (MUST)、 INVALID_CHALLENGE_ERROR のエラー型を伝えるべきである (SHOULD)。
8. cryptosuiteVerificationResult を、 securedDocument を入力として渡して cryptosuite.verifyProof アルゴリズムを 実行した結果とする。
9. 次の項目を持つ 検証結果を返す:

   verified

   cryptosuiteVerificationResult.verified

   verifiedDocument

   cryptosuiteVerificationResult.verifiedDocument

   mediaType

   mediaType

証明セットまたは 証明チェーンでは、 保護済みデータ文書は、 証明のリスト (allProofs) を含む proof 属性を持つ。次のアルゴリズムは、 allProofs 内のすべての証明を検証することで達成される、 保護済みデータ文書の真正性および完全性を 確認する一つの方法を提供する。 他のアプローチも可能であり、特に allProofs に含まれる証明の一部のみを 検証したい場合がある。証明の一部のみを検証する別のアプローチを採る場合、 その部分集合に含まれる previousProof を持つ任意の証明は、それが参照する 証明も検証済みと見なされる場合にのみ、検証済みと見なせることに注意することが重要である。

必須入力は保護済みデータ文書 (securedDocument) である。 allProofs 内の各証明に対応する 検証結果のリストが生成され、 単一の結合された検証結果が出力として返される。 実装は、結合された検証結果とともに、 その他の検証結果および/または任意の その他のメタデータを返してもよい (MAY)。

1. allProofs を securedDocument.proof に設定する。
2. verificationResults を空のリストに設定する。
3. allProofs 内の各 proof について、次の手順を実行する:
   1. matchingProofs を空のリストとする。
   2. proof が previousProof 属性を含み、その属性の値が 文字列である場合、 previousProof の値と一致する id 属性値を持つ allProofs 内の要素を matchingProofs に追加する。 previousProof の値に等しい id 値を持つ証明が allProofs 内に存在しない場合、エラーを発生させなければならず (MUST)、 PROOF_VERIFICATION_ERROR のエラー型を 伝えるべきである (SHOULD)。previousProof 属性が リストである場合、その リストの要素の値と 一致する id 属性値を持つ allProofs 内の各要素を追加する。 previousProof list のいずれかの要素が、 allProofs のいずれの要素の id 属性値にも一致しない id 属性値を持つ場合、エラーを発生させなければならず (MUST)、 PROOF_VERIFICATION_ERROR のエラー型を 伝えるべきである (SHOULD)。
   3. inputDocument を、証明値を取り除いた securedDocument のコピーとし、 その後 inputDocument.proof を matchingProofs に設定する。
      注記: 文書および以前の 証明を保護する

      この手順がどの文書プロパティおよび以前の証明を保護するかについては、 4.3 証明セット/チェーンの追加の手順6の注記を参照。

   4. 4.4 証明の検証節のアルゴリズムの手順4から8を inputDocument に対して実行する。例外が発生しない場合、 cryptosuiteVerificationResult を verificationResults に追加する。
4. successfulVerificationResults を空のリストに設定する。
5. combinedVerificationResult を空の struct とする。 combinedVerificationResult.status を true に、combinedVerificationResult.document を null に、そして combinedVerificationResult.mediaType を null に設定する。
6. verificationResults 内の各 cryptosuiteVerificationResult について:
   1. cryptosuiteVerificationResult.verified が false の場合、 combinedVerificationResult.verified を false に設定する。
   2. それ以外の場合、combinedVerificationResult.document を cryptosuiteVerificationResult.verifiedDocument に設定し、 combinedVerificationResult.mediaType を cryptosuiteVerificationResult.mediaType に設定し、 cryptosuiteVerificationResult を successfulVerificationResults に追加する。
7. combinedVerificationResult.status が false の場合、 combinedVerificationResult.document を null に設定し、 combinedVerificationResult.mediaType を null に設定する。
8. combinedVerificationResult、successfulVerificationResults を返す。

暗号技術は、秘密の使用を通じて情報を保護する。必要な秘密を知っていれば、 特定の情報にアクセスすることは計算上容易になる。同じ情報は、 計算上困難な総当たりの試みがその秘密を推測することに成功した場合にも アクセスできる。すべての現代的な暗号技術は、その計算上困難なアプローチが 時間を通じて困難であり続けることを必要とするが、科学および数学の突破口により、 それが常に成り立つとは限らない。つまり、暗号技術には寿命があるということである。

本仕様は、現在使用されている暗号技術が時間の経過とともに破られる可能性が 非常に高いと主張することで、すべての暗号学的アプローチの陳腐化を見込んでいる。 ソフトウェアシステムは、情報を継続して保護するために、時間の経過に応じて 使用中の暗号技術を変更できなければならない。そのような変更には、必要な秘密の サイズを大きくすることや、使用される暗号プリミティブの変更が含まれる可能性がある。 しかし、暗号パラメータの組み合わせによっては、実際にはセキュリティを低下させる 可能性がある。これらの前提を踏まえると、システムは、安全な暗号パラメータの 異なる組み合わせ、すなわち暗号スイートを互いに区別できる必要がある。 暗号スイートを識別またはバージョン管理する場合、パラメータ、番号、日付などを 含むいくつかのアプローチを採ることができる。

パラメータ方式のバージョン管理は、暗号スイートで用いられる特定の暗号パラメータを 指定する。たとえば、RSASSA-PKCS1-v1_5-SHA1 のような識別子を 使用できる。この方式の利点は、十分に訓練された暗号技術者が、その識別子によって 使われているすべてのパラメータを判断できることである。この方式の欠点は、 この種の識別子を使用する人々の大半が十分に訓練されておらず、したがって 前述の識別子がもはや安全に使用できない暗号スイートであることを理解しないことである。 さらに、この知識不足により、ソフトウェア開発者が暗号スイート識別子の解析を 一般化し、暗号プリミティブの任意の組み合わせを受け入れ可能にしてしまい、 セキュリティ低下につながる可能性がある。理想的には、暗号スイートは、特定の 受け入れ可能な暗号パラメータのプロファイルとしてソフトウェアに実装されるべきである。

番号方式のバージョン管理は、1.0 や 2.1 のような メジャーおよびマイナーバージョン番号を指定する場合がある。番号方式の バージョン管理は、特定の順序を伝え、より高いバージョン番号がより低い バージョン番号より高機能であることを示唆する。このアプローチの利点は、 専門性の低い開発者には理解できない可能性がある複雑なパラメータを取り除き、 アップグレードが適切である可能性を伝える、より単純なモデルにできることである。 このアプローチの欠点は、アップグレードが必要かどうかが明確ではないことである。 ソフトウェアのバージョン番号の増加は、そのソフトウェアが機能し続けるために アップグレードを必要としないことが多いからである。これにより、開発者は 特定のバージョンの使用が安全であると考える可能性があるが、実際にはそうではない。 理想的には、暗号スイートをソフトウェアで使用する開発者に対し、そのスイートの 継続的なセキュリティについて定期的なレビューが必要であることを示す追加の シグナルが与えられるべきである。

日付ベースのバージョン管理は、特定の暗号スイートに対する特定のリリース日を 指定する。年などの日付の利点は、その日付が比較的古いのか新しいのかが 開発者にすぐ分かることである。古い日付を見ることで、開発者はより新しい 暗号スイートを探しに行く可能性があるが、パラメータ方式または番号方式の バージョン管理ではそうならない可能性がある。日付ベースのバージョンの欠点は、 一部の暗号スイートが5〜10年は失効しない可能性があり、開発者がより新しい 暗号スイートを探しに行っても、より新しいものが見つからない可能性があることである。 これは不便かもしれないが、より安全なエコシステムの挙動につながる不便である。

現代的な暗号アルゴリズムは、さまざまなユースケースの多様な要件を満たせるように、 多数の調整可能なパラメータおよびオプションを提供する。たとえば、組み込みシステムは 処理能力とメモリ環境が限られており、特定のアルゴリズムで最強のデジタル署名を 生成するためのリソースを持たない可能性がある。金融取引システムのような 他の環境では、取引が行われている1日だけデータを保護すればよい場合がある一方、 他の環境ではデータを複数十年保護する必要がある場合がある。これらのニーズを 満たすため、暗号アルゴリズム設計者は、多くの場合、暗号アルゴリズムを設定する 複数の方法を提供する。

暗号ライブラリ実装者は、多くの場合、暗号アルゴリズム設計者および仕様著者が 作成した仕様を受け取り、それらのライブラリを使用するアプリケーション開発者に すべてのオプションが利用可能となるように実装する。これは、特定の アプリケーション開発者が特定の暗号配備で必要とする機能の組み合わせが 分からないためである可能性がある。すべてのオプションがアプリケーション開発者に 公開されることが多い。

暗号ライブラリを使用するアプリケーション開発者は、多くの場合、特定の アプリケーションに対して暗号パラメータおよびオプションを適切に選択するために 必要な暗号に関する専門知識および知識を持っていない。この専門知識の不足は、 特定のアプリケーションに対して暗号パラメータおよびオプションを不適切に選択する ことにつながる可能性がある。

本仕様は、暗号ライブラリ実装者よりもアプリケーション開発者を、暗号仕様著者よりも 暗号ライブラリ実装者を、暗号アルゴリズム設計者よりも暗号仕様著者を保護する という構成員の優先順位を設定する。これらの優先順位を踏まえ、次の推奨を行う:

• 暗号アルゴリズム設計者には、暗号ライブラリ実装者が自身のソフトウェア ライブラリについて、より容易に監査可能なセキュリティ攻撃面を持てるように、 オプションおよびパラメータの数を可能な限り少なくすることが助言される [RFC7696]。
• 暗号仕様著者には、可能であれば、暗号アジリティを確保しつつ、下流の ソフトウェアライブラリに対する監査可能なセキュリティ攻撃面を最小限に保つため、 オプションおよびパラメータの数をさらに可能な限り少なくすることが助言される。
• 暗号ライブラリ実装者には、可能であれば、既知の良好なオプションおよび パラメータの組み合わせをアプリケーション開発者に提供することが助言される。 理想的には、楕円曲線デジタル署名などの任意のアルゴリズムクラスについて、 2つの事前設定されたデフォルト構成が存在し、これらの事前設定を使用する際には パラメータおよびオプションを微調整できないようにする。専門家がライブラリの 使用を微調整するためにライブラリオプションを提供することはできるが、一般的な アプリケーション開発者層によるそれらのオプションの使用は推奨されない。
• 暗号ライブラリ実装者は、非推奨および実験的な暗号機能を提供できるが、 ライブラリオプションなどを通じて開発者が明示的に要求した場合に限り、 かつ非推奨または実験的な暗号がアプリケーションで有効になったことを ライブラリが警告するように提供することが助言される。
• アプリケーション開発者には、事前設定された複数の暗号ライブラリ構成から選択し、 暗号オプションおよびパラメータの変更、または実験的または非推奨の暗号の使用を 避けることが助言される。

上記の指針は、有用な暗号オプションおよびパラメータがアーキテクチャの下位層で 提供される一方で、各オプションの利点と欠点のバランスを十分に理解していない 可能性のあるアプリケーション開発者に、それらのオプションおよびパラメータを 公開しないことを意図している。

5.1 暗号スイートのバージョン管理節では、特定の暗号スイートの時宜性に関して 比較的理解しやすい情報を提供する重要性が強調され、 5.2 アプリケーション開発者の保護節では、指定されるオプションの数を 最小化することがさらに強調された。実際、3. 暗号スイート節は、アルゴリズム、変換、ハッシュ化、およびシリアル化の 詳細な指定を含む暗号スイートの要件を列挙している。したがって、暗号スイートの名前が これらの詳細すべてを含む必要はない。これは、 5.1 暗号スイートのバージョン管理節で述べた パラメータ方式のバージョン管理が、必要でも望ましくもないことを意味する。

暗号スイートの推奨される命名規約は、署名アルゴリズム識別子から成る文字列であり、 暗号スイートが互換性のない実装オプションをサポートする場合は、ハイフンで区切られた オプション識別子を続け、さらにハイフンと、そのスイートが提案された概ねの年を 示す指定を続ける。

たとえば、[DI-EDDSA] は EdDSA デジタル署名に基づき、正規化アプローチに基づく2つの互換性のない オプションをサポートし、概ね2022年に提案されたため、2つの異なる 暗号スイート名、eddsa-rdfc-2022 および eddsa-jcs-2022 を持つ。

[DI-ECDSA] は ECDSA デジタル署名に基づき、[DI-EDDSA] と 同じ2つの互換性のない正規化アプローチをサポートし、さらに楕円曲線とハッシュの 2つの代替集合を通じて2つの異なるセキュリティレベル (128ビットおよび192ビット) を サポートするが、暗号スイート名は ecdsa-rdfc-2019 および ecdsa-jcs-2019 の2つだけである。 セキュリティレベルおよび対応する曲線とハッシュは、妥当性確認で使用される 公開鍵のマルチキー形式から決定される。

暗号アジリティとは、 頻繁に接続される情報セキュリティシステムを、 複数の暗号プリミティブおよび/またはアルゴリズム間で切り替えられるように 設計する実践である。暗号アジリティの主な目標は、システムのインフラストラクチャに 破壊的な変更を加えることなく、新しい暗号プリミティブおよびアルゴリズムへ システムが迅速に適応できるようにすることである。したがって、SHA-1 アルゴリズムなどの 特定の暗号プリミティブがもはや安全に使用できないと判断された場合、システムは 単純な設定ファイルの変更を通じて、より新しいプリミティブを使用するように 再設定できる。

暗号アジリティは、情報セキュリティシステム内のクライアントとサーバーが 定期的に接触している場合に最も効果的である。しかし、特定の暗号アルゴリズムによって 保護されるメッセージが、検証可能な クレデンシャルのように長寿命である場合、および/またはクライアント (holder) が サーバー (issuer) に容易に再接触できない可能性がある場合、暗号アジリティは 望ましい保護を提供しない。

暗号レイヤリングとは、 まれに接続される情報セキュリティシステムを、 複数のプリミティブおよび/またはアルゴリズムを同時に用いるように 設計する実践である。暗号レイヤリングの主な目標は、1つ以上の暗号アルゴリズムまたは プリミティブが失敗しても、ペイロード上の暗号学的保護を失うことなくシステムが 生き残れるようにすることである。たとえば、単一の情報片に対して RSA、ECDSA、 Falcon アルゴリズムを並列に使用してデジタル署名することは、これら3つの デジタル署名アルゴリズムのうち2つが失敗しても生き残れる仕組みを提供する。 768ビット鍵を使用する RSA デジタル署名など、特定の暗号学的保護が危殆化した場合でも、 システムは危殆化していない暗号学的保護を引き続き利用して情報を保護できる。 開発者には、1年以上保護する必要がある可能性のあるすべての署名済みコンテンツについて、 この機能を活用することが強く求められる。

本仕様は、両方の形態のアジリティを提供する。一つは暗号アジリティであり、 あるアルゴリズムから別のアルゴリズムへ容易に切り替えられるようにする。 もう一つは暗号レイヤリングであり、複数の暗号アルゴリズムを通常は並列に 同時使用できるようにし、情報を保護するために使用されたそれらのいずれも、 他のものに依存せず、また他のものを必要とせずに使用できるようにしつつ、 デジタル証明形式を開発者にとって使いやすく保つ。

証明には proofValue が含まれ、その中には 暗号学的証明に関連する多数のパラメータを埋め込むことができる。たとえば、 Data Integrity ECDSA Cryptosuites v1.0 仕様の選択的開示アルゴリズムは、 proofValue 内に、選択的に開示可能な各項目につき1つの複数の 暗号署名を含む。これは、アプリケーション開発者にとって技術をより簡単かつ 安全に使用できるようにするために行われている。

本仕様は、仕様著者に対し、アプリケーション層でほとんど必要とされない情報を 抽象化するために単一の値を使用することを強く求める。画像を表す data: URL が、画像レンダリングの多くのパラメータを単一の値にカプセル化するのと 同様に、proofValue プロパティ (および他の類似プロパティ) は、 アプリケーション開発者にとって有用ではない情報を抽象化し、アプリケーションに とって重要であるフィールドの識別を簡素化する。このように情報を抽象化することで、 開発者が扱いやすいデータ構造となり、たとえば、重要なプロパティを追加または 削除するプログラミングエラーによる偶発的な破損によって暗号層に悪影響を与える ことに対して、より影響を受けにくくなる。

本仕様におけるデータ完全性の設計は、一般に暗号層にのみ有用な情報を 単一のプロパティへ抽象化し、アプリケーション開発者の負担を軽減し、 システムのセキュリティを高める。

暗号学的保護処理の間に、保護対象のデータを変換することが有益な場合がある。 このような「インライン」変換により、特定の種類の暗号学的保護が、そのデータが 搬送されるデータ形式に依存しないものになり得る。たとえば、一部の Data Integrity 暗号スイートは RDF Dataset Canonicalization [RDF-CANON] を利用し、初期表現を 正規形 [N-QUADS] へ変換し、それが シリアル化、ハッシュ化、デジタル署名される。保護対象データを表現する任意の構文が この正規形へ変換できる限り、デジタル署名は検証できる。これにより、情報に対する 同じデジタル署名を、各構文ごとに暗号学的証明を作成することなく、JSON、CBOR、 YAML、およびその他の互換構文で表現できる。

さまざまな構文にわたって同じデジタル署名を表現できることは有益である。 なぜなら、システムはしばしば動作に用いるネイティブなデータ形式を持つからである。 たとえば、JSON データを対象に作られているシステムもあれば、CBOR データを対象に 作られているシステムもある。変換がなければ、内部的にデータを CBOR として 処理するシステムは、デジタル署名されたデータ構造を JSON として保存する必要がある (またはその逆)。これはデータの二重保存につながり、データベースに保存された 署名されていない表現が署名済み表現から偶発的に逸脱した場合、セキュリティ攻撃面を 増大させる可能性がある。変換を使用することで、デジタル証明はネイティブな データ形式の中に存在でき、時間の経過とともに検出不能なデータベースのドリフトが 発生することを防ぐ助けとなる。

本仕様は、「インライン」データ変換を利用することで、署名済み情報の重複を 要求しないように設計されている。アプリケーション開発者には、暗号学的に保護された データをアプリケーションのネイティブなデータ形式で扱い、暗号学的証明を 保護対象データから分離して保存しないことが強く求められる。開発者にはまた、 暗号学的に保護されたデータがアプリケーションストレージへ書き込まれ、そこから 読み出される際に改ざんされていないことを定期的に確認することも強く求められる。

RDF Dataset Canonicalization [RDF-CANON] などの一部の変換には、 攻撃者が過剰な処理サイクルを消費するために使用できる入力データセットに対する 緩和策がある。この種類の攻撃は dataset poisoning と呼ばれ、 すべての現代的な RDF Dataset 正規化器は、この種の不正な入力を検出して 処理を停止することが要求される。RDF Dataset Canonicalization のテストスイートには、 そのような緩和策がすべての適合実装に存在することを確保するため、 そのような毒入りデータセットが含まれている。一般的に言えば、変換を使用する 暗号スイート仕様は、この種の攻撃を緩和することが要求され、実装者には、 使用するソフトウェアライブラリがこれらの緩和策を強制することを確保するよう 強く求められる。これらの攻撃は、サーバー上の接続を枯渇させるために 意図的に接続を遅くする HTTP クライアントなど、あらゆるリソース枯渇攻撃と 同じ一般的なカテゴリに属する。実装者には、防御的なセキュリティ戦略を 実装する際に、この種の攻撃を考慮することが助言される。

任意のデータ完全性証明によって 保護されるデータは、変換済みデータである。 変換済みデータは、 特定のcryptosuiteによって指定される 変換アルゴリズムによって 生成される。この保護機構は、入力データに対していかなる種類の 変換も行わない一部のより伝統的なデジタル署名機構とは 異なる。変換の利点は、 5.6 変換節で詳述される。

たとえば、 cryptosuitesである ecdsa-jcs-2019 および eddsa-jcs-2022 は、 JSON Canonicalization Scheme (JCS) を使用してデータを正規化 JSON へ 変換し、それが暗号学的にハッシュ化され、 デジタル署名される。このアプローチの一つの利点は、署名対象の情報の意味に 影響しない空白、タブ、改行などの書式文字を追加または削除しても、 デジタル署名が無効にならないことである。より伝統的なデジタル署名機構には この能力がない。

他のcryptosuitesである ecdsa-rdfc-2019 および eddsa-rdfc-2022 は、 RDF Dataset Canonicalization を使用して、データを正規化された N-Quads [N-QUADS] へ 変換し、 それが暗号学的にハッシュ化され、デジタル署名される。このアプローチの一つの利点は、 暗号署名が、JSON、YAML、CBOR など、さまざまな異なる構文へ、署名を無効にすることなく 移植可能であることである。より伝統的な暗号署名機構にはこの能力がない。

実装者および開発者には、データ完全性証明を含む情報を、 その証明が検証済みであり、 かつ返されるすべてのデータが正常に保護されていることを確認したソフトウェアライブラリの 戻り値として検証済みデータが提供されている場合を除き、信頼しないことが強く求められる。

アプリケーションデータの検査可能性は、システム効率および開発者生産性に影響を与える。 base 符号化されたバイナリデータなど、暗号学的に保護されたアプリケーションデータが、 データベースなどのアプリケーションサブシステムによって容易に処理できない場合、 暗号学的に保護された情報を扱う労力が増加する。たとえば、データベースによって ネイティブに保存およびインデックス化できる暗号学的に保護されたペイロードは、 次のようなより単純なシステムをもたらす:

• 保護された情報に変更を加えることなく、既存の業界標準データベース機能を 利用できるという利点がある。
• データの一方のコピーがメッセージおよびデジタル署名を保持し、もう一方の コピーがメッセージのみを保存およびインデックス化してシステム挙動を駆動する、 データ複製の複雑さを避ける。
• 複数の入れ子になった base 符号化ペイロードを持つ、入れ子のデジタル署名済み データをシリアル化およびデシリアル化するなど、保護された情報を構造的に 変更しなければならない独自解決策の複雑さを避ける。

同様に、複数の上流ネットワークシステムによって処理可能な暗号学的に保護された ペイロードは、セキュリティアーキテクチャを適切に階層化する能力を高める。 たとえば、上流システムが受信ペイロードを繰り返し復号する必要がない場合、 攻撃に能動的に対抗することに特化した上流サブシステムによって処理負荷を分散する システムの能力が高まる。実質的なアクションを行う前には常にデジタル署名を 確認する必要があるが、明らかに不正なリクエストを拒否するために、識別子ベースの レート制限、署名期限の確認、nonce/challenge の確認など、透明なペイロードに対して 他の上流チェックを実行できる。

さらに、開発者がシステム内のデータを容易に閲覧できない場合、システムの正しさを 容易に監査またはデバッグする能力が妨げられる。たとえば、アプリケーション開発者に base 符号化されたアプリケーションデータの切り貼りを要求すると、開発がより困難になり、 すべてのメッセージが手動操作の base 復号ツールを通過する必要があるため、 明らかなバグが見逃される可能性が高まる。

しかし、データを不透明にすることが正しい設計判断である場合もある。 他のアプリケーションサブシステムによって処理される必要のないデータ、および アプリケーション開発者によって変更またはアクセスされる必要のないデータは、 不透明な形式へシリアル化できる。例として、デジタル署名値、暗号鍵パラメータ、 および暗号ライブラリだけがアクセスする必要があり、アプリケーション開発者が 変更する必要のないその他のデータフィールドがある。保存時暗号化を行うデータベースなど、 基盤となるサブシステムが不透明データの基盤となる複雑さをアプリケーション開発者に 露出しない場合にも、データの不透明性が適切である例がある。これらの場合、 アプリケーション開発者は透明なアプリケーションデータ形式を対象に開発を続け、 データベースが長期保存との間でアプリケーションデータを暗号化および復号する 複雑さを管理する。

本仕様は、アプリケーションデータがネイティブ形式のまま残り、不透明化されない一方で、 デジタル署名などの他の暗号データは不透明なバイナリ符号化形式のまま保持される アーキテクチャを提供することを目指す。暗号スイート実装者には、スイートを設計する際に データの不透明性の適切な使用を検討し、アプリケーションデータを不透明にすることと、 アプリケーション層で暗号データへのアクセスを提供することの設計上のトレードオフを 比較検討することが強く求められる。

実装者は、検証メソッドの定義から 制御識別子 文書へ進み、その後、その制御識別子 文書にもその 検証メソッドへの参照が 含まれていることを確保することで、検証メソッドが特定の controller に束縛されていることを確保する。この処理は、 検証メソッドの取得のアルゴリズムで説明される。

実装が証明を検証する場合、証明を生成するために使用された 検証メソッドが 制御識別子 文書に列挙されていることだけでなく、それが検証されている証明を生成するために 使用されることを意図していたことも検証することが不可欠である。この処理は 「検証関係の妥当性確認」として知られる。

検証関係を妥当性確認する処理は、 制御識別子 v1.0 仕様の 3.3 Retrieve Verification Method節で概説されている。

この処理は、私有暗号鍵などの暗号材料が、意図しない目的にアプリケーションによって 誤用されないことを確保するために使用される。暗号材料の誤用の例として、 検証可能なクレデンシャル を発行するために使用されることを意図した私有暗号鍵が、代わりに Web サイトへ ログインするため (すなわち認証のため) に使用される場合がある。検証関係を確認しないことは 危険である。なぜなら、ある暗号材料に対する制限および保護プロファイルは、その 意図された用途によって決定され得るからである。たとえば、一部のアプリケーションは 暗号材料を1つの目的にのみ使用することを信頼されている場合があり、また一部の 暗号材料は、ラップトップ上の暗号化されていないファイルではなく、データセンター内の ハードウェアセキュリティモジュールに保存されるなど、より保護されている場合がある。

実装が証明を検証する場合、 証明の目的が意図された用途と 一致することを検証することが不可欠である。

この処理は、証明がアプリケーションによって意図しない目的に誤用されないことを 確保するために使用される。これは証明作成者にとって危険である。誤用の例として、 検証可能なクレデンシャル における主張を保護するための目的であると記載された証明が、代わりに Web サイトへ ログインするためのauthenticationに使用される場合がある。この場合、 証明作成者は、無制限の数の他の当事者に配布されることを期待して、任意の数の 検証可能なクレデンシャル に証明を添付している。これらの当事者のいずれかが、Web サイトがそのような証明を 意図された目的ではなくauthenticationとして誤って受け入れた場合、 証明作成者として Web サイトにログインできてしまう。

正規化などの変換が実行される方法は、システムのセキュリティ特性に影響を与える 可能性がある。最良の正規化機構の選択は、ユースケースに依存する。多くの場合、 望ましいセキュリティ要件を満たす最も単純な機構が最良の選択である。 この節は、本仕様で参照される2つの主な正規化機構、すなわち JSON Canonicalization Scheme [RFC8785] および RDF Dataset Canonicalization [RDF-CANON] の間で実装者が選択するのに 役立つ、単純な指針を提供しようとするものである。

アプリケーションが JSON のみを使用し、いかなる形式の RDF 意味論にも依存しない場合、 JSON Canonicalization Scheme [RFC8785] を使用する暗号スイートを 使用することは魅力的なアプローチである。

アプリケーションが JSON-LD を使用し、文書の意味論を保護する必要がある場合、 RDF Dataset Canonicalization [RDF-CANON] を使用する暗号スイートを 使用することは魅力的なアプローチである。

実装者には、変換を行わず、データに証明を埋め込む代わりに暗号学的エンベロープで データを包むことによってデータを保護する他の機構も利用可能であることが助言される。 その例には JWTs [RFC7519] および CWTs [RFC8392] がある。 これらのアプローチは、一部のユースケースでは単純さの利点を持つが、本仕様で詳述される アプローチが提供する利点の一部を犠牲にする。

本仕様で使用されるアルゴリズム処理の一つは正規化であり、これは 変換の一種である。正規化とは、意味論的に 等価なさまざまな方法で表現され得る情報を入力として受け取り、すべての出力を 「正規形」と呼ばれる単一の方法で表現する処理である。

正規化を利用する結果として得られる データ完全性証明の セキュリティは、アルゴリズムの正確性に大きく依存する。たとえば、正規化 アルゴリズムが、異なる意味を持つ2つの入力を同じ出力へ変換する場合、著者の意図が 検証者に対して 誤って表現される可能性がある。これは攻撃者によって攻撃ベクトルとして使用され得る。

さらに、入力内の意味論的に関連する情報が出力に存在しない場合、攻撃者は 証明検証を失敗させることなく、そのような情報をメッセージに挿入できる可能性がある。 これは、暗号学的にメッセージへ署名する際によく使用される別の変換である 暗号学的ハッシュ化に似ている。攻撃者が異なる入力から同じ暗号学的ハッシュを 生成できる場合、その暗号学的ハッシュアルゴリズムは安全であるとは見なされない。

実装者には、入力をハッシュ化処理へ 変換するために使用される任意の 正規化アルゴリズムについて、適切な精査を確保することが強く求められる。 適切な精査には、少なくとも、アルゴリズムの正確性に関する査読済み数学的証明との 関連付けが含まれる。複数の実装、および標準化団体における専門家による精査が 望ましい。実装者には、情報正規化に関する正式な訓練を受けている場合、および/または アルゴリズムの正確性に関する査読済み数学的証明を作成できる分野の専門家へ アクセスできる場合を除き、新しい仕組みを考案または使用しないことが強く求められる。

本仕様は、適合する保護済み文書上の証明を 検証する際に、ネットワークリクエストを必要としないように設計されている。 しかし読者は、JSON-LD contexts および 検証 メソッドが、ネットワーク接続を介して取得される可能性のある URL を含み得ることに 注意するかもしれない。この懸念は、検証中または検証後にネットワークから読み込まれる 可能性のある任意の URL に存在する。

可能な限り、実装者には、そのような情報を永続的または積極的にキャッシュし、 ネットワーク経由でそのような URL を取得する必要がある実装の攻撃面を低減することが 強く求められる。たとえば、JSON-LD contexts のキャッシュ手法は、 2.4 コンテキストと語彙節で説明されており、 did:key [DID-KEY] など一部の 検証 メソッドは、ネットワークから取得する必要がまったくない。

特定の HTTP URL ベースの 検証メソッドの インスタンスに初めて遭遇する場合など、キャッシュ済み情報を使用できない場合、 実装者には、ネットワークからリソースを取得する可能性のある任意の処理中に、 サービス拒否攻撃を緩和するための防御策を使用することが注意喚起される。

本仕様で説明される文書を保護する技術は一般化された性質を持つため、 その使用に伴うセキュリティ上の影響は、読者にすぐ明らかではない可能性がある。 完全なソフトウェアシステムで考慮する必要があり得る種類のセキュリティ上の懸念を 理解するため、実装者には、この技術が 検証可能なクレデンシャル エコシステム [VC-DATA-MODEL-2.0] で どのように使用されるかを読むことが強く求められる。詳細については 検証可能なクレデンシャルのセキュリティ上の考慮事項に関する節を参照。

デジタル署名されたペイロードに、複数の検証者によって見られるデータが含まれる場合、 それは相関の点となる。そのようなデータの例は、買い物のロイヤルティカード番号である。 相関可能なデータは検証者による追跡目的に使用でき、場合によってはプライバシー期待に 反する可能性がある。一部のデータが追跡に使用できるという事実は、すぐには明らかで ない可能性がある。そのような相関可能データの例には、静的なデジタル署名や画像の 暗号学的ハッシュが含まれるが、これらに限定されない。

相関可能な追跡データを持たず、同時に特定のやり取りに対してペイロードが信頼できる ことについて一定程度の保証を提供する、デジタル署名されたペイロードを作成することは 可能である。この特性は 非リンク可能性と呼ばれ、デジタル署名されたペイロードに 相関可能なデータが使用されないことを確保しつつ、一定程度の信頼を提供する。 その十分性は各検証者が判断しなければならない。

すべてのユースケースが非リンク可能性を必要とする、または許可するわけではないことを 理解することが重要である。危険物を輸送および保管する組織や個人を相関させる場合など、 規制上または安全上の理由によりリンク可能性および相関が必要となるユースケースがある。 非リンク可能性は、特定のやり取りに対するプライバシー期待がある場合に有用である。

一定程度の非リンク可能性を提供できる仕組みは少なくとも2つある。 第1の方法は、メッセージで使用されるデータ値が将来のメッセージで決して 繰り返されないようにすることである。第2の方法は、繰り返される任意のデータ値が 十分な群衆プライバシーを提供し、そのやり取りにおいて一定程度のプライバシーを 期待するエンティティを相関させることが実質的に不可能になるようにすることである。

非リンク可能性を達成するために、さまざまな方法を使用できる。これらの方法には、 メッセージを、相関目的に使用できる情報を持たない単回使用のベアラートークンにすること、 十分なレベルの群衆プライバシーを確保する属性を使用すること、および、提示される メッセージへの信頼を損なうことなく、メッセージを提示するエンティティが新しい署名を 再生成できる暗号スイートを使用することが含まれる。

選択的開示とは、以前に署名されたメッセージ (すなわち、その作成者によって署名された メッセージ) の受信者が、その部分の検証可能性を損なうことなく、メッセージの一部だけを 明らかにできる技術である。たとえば、車を借りる目的でデジタル運転免許証を 選択的に開示する場合がある。これには、免許証から発行機関、免許番号、生年月日、 および許可された自動車クラスのみを明らかにすることが含まれ得る。この場合、 免許番号は相関可能な情報であるが、運転者の氏名および住所が共有されないため、 ある程度のプライバシーが保持されることに注意する。

すべてのソフトウェアまたは暗号スイートが選択的開示を提供できるわけではない。 メッセージの著者が、その受信者によって選択的に開示可能であることを望む場合、 特定のメッセージで選択的開示を有効にする必要があり、両者は対応可能な 暗号スイートを使用する必要がある。著者はまた、メッセージの特定部分の開示を 必須にする場合もある。メッセージの部分的な内容を選択的に開示したい受信者は、 その技術を実行できるソフトウェアを利用する必要がある。選択的開示をサポートする 暗号スイートの例は bbs-2023 である。

非リンク可能性を保持しない方法で情報を選択的に開示することも可能である。 たとえば、出荷に関連する検査結果を開示したい場合があり、その検査結果には 規制要件により相関可能である必要がある出荷識別子またはロット番号が含まれる 可能性がある。しかし、検査結果全体の開示は必要ではない場合があり、合格/不合格 状態だけを選択的に開示することで十分と見なされる可能性がある。プライバシーを 保持しながら情報を開示することに関する詳細については、 6.1 非リンク可能性を参照。

2.1.2 証明 チェーンで定義される previousProof 機能を使用する場合、 実装は、1つ以上の以前の証明に対してデジタル署名することを要求される。 これは、それらを保護済みペイロードに含めるためである。これにより必然的に、 以前の証明を追加した各エンティティに関連する情報が露出する。

少なくとも、以前の証明の 検証メソッド、たとえば 公開鍵は、証明チェーン内の次の証明の作成者に見られる。これは、以前の証明の作成者が 証明チェーンに含まれることを意図していなかった場合にはプライバシー上の懸念となり得るが、 あらゆる種類の文書に否認不能なデジタル署名を追加する場合には避けられない結果である。

グループ署名など、 より高度な暗号機構を使用して、メッセージ署名者の身元を隠すことは可能であり、 Data Integrity 暗号スイートがこのプライバシー上の懸念を緩和することも可能である。

フィンガープリンティングの懸念は、証明検証中またはその後に ネットワークから読み込まれる可能性のある任意の URL に存在する。本仕様は、 適合する保護済み文書上の 証明を検証する際に、ネットワークリクエストが必要ないように設計されている。 しかし読者は、JSON-LD contexts および 検証 メソッドが、ネットワーク接続を介して取得される可能性のあるリソース URL を含み、 フィンガープリンティングの懸念につながり得ることに注意するかもしれない。

たとえば、適合する保護済み文書の 作成者は、JSON-LD contexts および 検証 メソッドについて、文書ごとに一意の URL を作成する可能性がある。 そのような文書を検証する際、検証者がその情報をネットワークから取得すると、 その文書に対する関心を文書の作成者に明らかにしてしまい、文書の作成者ではない 任意のエンティティに対するプライバシー期待との不一致につながる可能性がある。

実装者には、URL のキャッシュおよびネットワークから URL を取得する際の防御的実装に ついて、5.14 ネットワーク リクエスト節の指針に従うことが強く求められる。 リクエストを行っているクライアントを明らかにせずにネットワークからリソースを 取得するために、 Oblivious HTTP などの技術を使用することが奨励される。さらに、 適合する保護済み文書の作成者が、 プライバシー期待に反する可能性のある方法でフィンガープリンティング URL を 使用しているかどうかを判断するために、ヒューリスティックを使用してもよい。 これらのヒューリスティックは、フィンガープリンティングが疑われる URL を含む文書を 処理する可能性のあるエンティティに警告を表示するために使用できる。

変換、すなわち正規化が実行される方法は、システムのプライバシー特性に影響を与える 可能性がある。最良の正規化機構の選択は、ユースケースに依存する。 この節は、本仕様で参照される2つの主な正規化機構、すなわち JSON Canonicalization Scheme [RFC8785] および RDF Dataset Canonicalization [RDF-CANON] の間で、 プライバシーの観点から実装者が選択するのに役立つ単純な指針を提供しようとするものである。

アプリケーションが保護済み文書内の情報の選択的開示を行う必要がなく、 JSON-LD も利用しない場合、JSON Canonicalization Scheme [RFC8785] は魅力的なアプローチである。

アプリケーションが JSON-LD を使用し、保護済み文書内の情報の選択的開示を 必要とする可能性がある場合、RDF Dataset Canonicalization [RDF-CANON] を使用する暗号スイートを 使用することは魅力的なアプローチである。

実装者には、変換を行わず、データに証明を埋め込む代わりに暗号学的エンベロープで データを包むことによってデータを保護する、他の選択的開示機構も利用可能であることが 助言される。その例には SD-JWTs [SD-JWT] がある。このアプローチは、 一部のユースケースでは単純さの利点を持つが、本仕様で詳述されるアプローチが提供する 利点の一部を犠牲にする。

本仕様で説明される文書を保護する技術は一般化された性質を持つため、 その使用に伴うプライバシー上の影響は、読者にすぐ明らかではない可能性がある。 完全なソフトウェアシステムで考慮する必要があり得る種類のプライバシー上の懸念を 理解するため、実装者には、この技術が 検証可能なクレデンシャル エコシステム [VC-DATA-MODEL-2.0] で どのように使用されるかを読むことが強く求められる。詳細については 検証可能なクレデンシャルのプライバシー上の考慮事項に関する節を参照。

本仕様は、暗号学的証明の有効期間に関連する日付および時刻の表現を可能にする。 この情報は、証明が処理され、許容される時間範囲外であると検出された場合、 個人に間接的に公開される可能性がある。これらの日付および時刻を個人に公開する場合、 実装者には、表示ソフトウェアにおいて 日付および時刻を表現する際の 文化的規範とロケールを考慮に入れることが強く求められる。これらの考慮事項に加え、 情報を受け取る個人の認知的負担を軽減する方法で時刻値を提示することは、推奨される ベストプラクティスである。

たとえば、特定のデジタル署名済み情報集合の有効期限を伝える場合、実装者には、 正確性を最適化する表現ではなく、理解しやすい言葉を使用して有効期限を提示することが 強く求められる。有効期限を「このチケットは3日前に期限切れになりました。」として 提示することは、「このチケットは2023年7月25日午後3時43分に期限切れになりました。」 のような表現よりも望ましい。前者は、後者の時刻よりも理解しやすい相対時刻を提供する。 後者は、個人が頭の中で計算することを必要とし、そのような計算が可能であることを 前提としている。