メインコンテンツまでスキップ

5. Producing and Consuming JWSs (JWSの生成と使用)

5.1 Message Signature or MAC Computation (メッセージ署名またはMACの計算)​

JWSを作成するには、以下の手順を実行します。入力と出力の間に依存関係がない場合、手順の順序は重要ではありません。

  1. JWS Payloadとして使用されるコンテンツを作成します。

  2. エンコードされたペイロード値BASE64URL(JWS Payload)を計算します。

  3. 必要なHeader Parametersのセットを含むJSONオブジェクトを作成します。これらは一緒にJOSE Header（JWS Protected Headerおよび/またはJWS Unprotected Header）を構成します。

  4. エンコードされたヘッダー値BASE64URL(UTF8(JWS Protected Header))を計算します。JWS Protected Headerが存在しない場合（これはJWS JSON Serializationを使用していて"protected"メンバーが存在しない場合にのみ発生します）、この値を空文字列とします。

  5. 使用されている特定のアルゴリズムに対して定義された方法で、JWS Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload))に対してJWS Signatureを計算します。"alg" (algorithm、アルゴリズム) Header Parameterは、JOSE Headerに存在しなければならず (MUST)、そのアルゴリズム値は、JWS Signatureの構築に使用されるアルゴリズムを正確に表す必要があります。

  6. エンコードされた署名値BASE64URL(JWS Signature)を計算します。

  7. JWS JSON Serializationを使用している場合は、実行される各デジタル署名またはMAC操作について、このプロセス（手順3-6）を繰り返します。

  8. 必要なシリアライゼーション出力を作成します。この結果のJWS Compact Serializationは、BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) || '.' || BASE64URL(JWS Signature)です。JWS JSON Serializationはセクション7.2で説明されています。

5.2 Message Signature or MAC Validation (メッセージ署名またはMACの検証)​

JWSを検証する場合は、以下の手順を実行します。入力と出力の間に依存関係がない場合、手順の順序は重要ではありません。リストされた手順のいずれかが失敗した場合、署名またはMACを検証できません。

複数のJWS Signature値が存在する場合、JWSを受け入れるためにどのJWS Signature値が正常に検証される必要があるかを決定するのは、アプリケーション次第です。場合によっては、すべての署名が正常に検証される必要があり、そうでない場合はJWSは無効と見なされます。他の場合には、特定のJWS Signature値のみが正常に検証される必要があります。ただし、すべての場合において、少なくとも1つのJWS Signature値が正常に検証されなければならず (MUST)、そうでない場合はJWSを無効として扱わなければなりません (MUST)。

  1. JWS表現を解析して、JWSコンポーネントのシリアライズされた値を抽出します。JWS Compact Serializationを使用する場合、これらのコンポーネントは、JWS Protected Header、JWS Payload、およびJWS Signatureのbase64urlエンコードされた表現です。JWS JSON Serializationを使用する場合、これらのコンポーネントには、エンコードされていないJWS Unprotected Header値も含まれます。JWS Compact Serializationを使用する場合、JWS Protected Header、JWS Payload、およびJWS Signatureは、この順序でbase64urlエンコードされた値として表現され、各値と次の値の間は単一のピリオド（'.'）文字で区切られ、正確に2つの区切りピリオド文字が使用されます。JWS JSON Serializationはセクション7.2で説明されています。

  2. JWS Protected Headerのエンコードされた表現をbase64urlデコードし、改行、空白、またはその他の追加文字を使用しないという制限に従います。

  3. 結果のオクテット列が、RFC 7159 [RFC7159] に準拠した完全に有効なJSONオブジェクトのUTF-8エンコード表現であることを検証します。このJSONオブジェクトをJWS Protected Headerとします。

  4. JWS Compact Serializationを使用している場合は、JOSE HeaderをJWS Protected Headerとします。それ以外の場合、JWS JSON Serializationを使用している場合は、JOSE Headerを対応するJWS Protected HeaderとJWS Unprotected Headerのメンバーの和集合とし、これらはすべて完全に有効なJSONオブジェクトでなければなりません。この手順で、結果のJOSE Headerに重複したHeader Parameter名が含まれていないことを検証します。JWS JSON Serializationを使用する場合、この制限には、同じHeader Parameter名がJOSE Headerを共同で構成する異なるJSONオブジェクト値にも出現してはならない (MUST NOT) ことが含まれます。

  5. 実装が、本仕様で要求されているか、使用されているアルゴリズムで要求されているか、"crit" Header Parameter値で要求されているかにかかわらず、サポートする必要があるすべてのフィールドを理解し処理でき、これらのパラメータの値も理解およびサポートされていることを検証します。

  6. JWS Payloadのエンコードされた表現をbase64urlデコードし、改行、空白、またはその他の追加文字を使用しないという制限に従います。

  7. JWS Signatureのエンコードされた表現をbase64urlデコードし、改行、空白、またはその他の追加文字を使用しないという制限に従います。

  8. 使用されているアルゴリズムに対して定義された方法で、JWS Signing Input ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload))に対してJWS Signatureを検証します。このアルゴリズムは、存在しなければならない (MUST) "alg" (algorithm、アルゴリズム) Header Parameterの値によって正確に表される必要があります (MUST)。アルゴリズム検証のセキュリティに関する考慮事項については、セクション10.6を参照してください。検証が成功したかどうかを記録します。

  9. JWS JSON Serializationを使用している場合は、表現に含まれる各デジタル署名またはMAC値について、このプロセス（手順4-8）を繰り返します。

  10. 手順9のすべての検証が成功しなかった場合は、JWSを無効として扱わなければなりません (MUST)。それ以外の場合、JWS JSON Serializationの場合は、どの検証が成功し、どれが失敗したかを示す結果をアプリケーションに返します。JWS Compact Serializationの場合、結果は単にJWSが正常に検証されたかどうかを示すことができます。

最後に、特定のコンテキストでどのアルゴリズムを使用できるかを決定するのは、アプリケーション次第であることに注意してください。JWSを正常に検証できる場合でも、JWSで使用されるアルゴリズムがアプリケーションにとって受け入れ可能でない限り、JWSを無効として扱うべきです (SHOULD)。

5.3 String Comparison Rules (文字列比較規則)​

JWSの処理では、必然的に既知の文字列をJSONオブジェクトのメンバーおよび値と比較する必要があります。たとえば、アルゴリズムが何であるかを確認する際、Unicode文字列"alg"をJOSE Headerのメンバー名に対してチェックして、一致するHeader Parameter名が存在するかどうかを確認します。次に、同じプロセスを使用して、"alg" Header Parameterの値がサポートされているアルゴリズムを表しているかどうかを判断します。

RFC 7159 [RFC7159] のセクション8.3では、メンバー名の比較を実行するためのJSON規則について説明しています。実行される唯一の文字列比較操作は等価と非等価であるため、同じ規則を使用してメンバー名とメンバー値を既知の文字列と比較できます。

これらの比較規則は、メンバーの定義がそのメンバー値に対して異なる比較規則を使用することを明示的に述べている場合を除き、すべてのJSON文字列比較に使用しなければなりません (MUST)。本仕様で定義されているメンバーのうち、"typ"および"cty"メンバー値のみがこれらの比較規則を使用しません。

一部のアプリケーションでは、大文字小文字を区別する値に大文字小文字を区別しない情報が含まれる場合があります。たとえば、DNS名を"kid" (key ID、鍵ID) 値の一部として含めることができます。これらの場合、複数の当事者が同じ値を生成して比較できるようにする必要がある場合、アプリケーションは、大文字小文字を区別しない部分を表現するための正規の大文字小文字を定義する規約を定義する必要がある場合があります（たとえば、小文字にする）。（ただし、他のすべての当事者が、独立して生成された値と比較しようとせずに、生産当事者が発行した値をそのまま使用する場合、生産者が使用する大文字小文字は関係ありません。）

セクション10.12のJSONセキュリティに関する考慮事項およびセクション10.13のUnicodeセキュリティに関する考慮事項も参照してください。

に最終更新