RFC 7797 - JSON Web Signature (JWS) Unencoded Payload Option 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7797
タイトル : RFC 7797 - JSON Web Signature（JWS）エンコードされていないペイロードオプション
翻訳編集 : 自動生成

[要約] RFC 7797は、JSON Web Signature（JWS）の非エンコードペイロードオプションに関する仕様です。このRFCの目的は、JWSのペイロードをエンコードせずに直接使用する方法を提供することです。

Internet Engineering Task Force (IETF)                          M. Jones
Request for Comments: 7797                                     Microsoft
Updates: 7519                                              February 2016
Category: Standards Track
ISSN: 2070-1721

JSON Web Signature (JWS) Unencoded Payload Option

JSON Web Signature（JWS）エンコードされていないペイロードオプション

Abstract

概要

JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url-encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.

JSON Web Signature（JWS）は、JWSのペイロードをbase64urlでエンコードされた値として表し、この値をJWS署名の計算に使用します。これにより、任意のペイロードの整合性が保護されますが、特にペイロードが大きい場合や分離された場合に、base64urlエンコーディングが不要である、および/または採用の妨げとなる使用例が説明されています。この仕様は、ペイロードをbase64url-encodeしないようにJWS署名入力の計算を変更するオプションを定義することにより、これらのユースケースに対応する方法を定義します。このオプションは、JWSの使用が適しているユースケースのセットを広げることを目的としています。

This specification updates RFC 7519 by stating that JSON Web Tokens (JWTs) MUST NOT use the unencoded payload option defined by this specification.

この仕様は、JSON Web Token（JWT）がこの仕様で定義されているエンコードされていないペイロードオプションを使用してはならないことを記述してRFC 7519を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7797.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7797で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  The "b64" Header Parameter  . . . . . . . . . . . . . . . . .   4
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Example with Header Parameters {"alg":"HS256"}  . . . . .   6
     4.2.  Example with Header Parameters
           {"alg":"HS256","b64":false,"crit":["b64"]}  . . . . . . .   7
   5.  Unencoded Payload Content Restrictions  . . . . . . . . . . .   7
     5.1.  Unencoded Detached Payload  . . . . . . . . . . . . . . .   8
     5.2.  Unencoded JWS Compact Serialization Payload . . . . . . .   8
     5.3.  Unencoded JWS JSON Serialization Payload  . . . . . . . .   8
   6.  Using "crit" with "b64" . . . . . . . . . . . . . . . . . . .   9
   7.  Intended Use by Applications  . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  JSON Web Signature and Encryption Header Parameter
           Registration  . . . . . . . . . . . . . . . . . . . . . .  10
       9.1.1.  Registry Contents . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1. Introduction

1. はじめに

The "JSON Web Signature (JWS)" [JWS] specification defines the JWS Signing Input as the input to the digital signature or Message Authentication Code (MAC) computation, with the value ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload)). While this works well in practice for many use cases, including those accommodating arbitrary payload values, other use cases have been described in which base64url-encoding the payload is unnecessary and/or an impediment to adoption, particularly when the payload is large and/or detached.

"JSON Web Signature（JWS）" [JWS]仕様では、JWS署名入力をデジタル署名またはメッセージ認証コード（MAC）計算への入力として定義し、値はASCII（BASE64URL（UTF8（JWS Protected Header））||です。 '。' || BASE64URL（JWS Payload））。これは、任意のペイロード値に対応するなど、多くのユースケースで実際にうまく機能しますが、特にペイロードが大きい場合やペイロードが大きい場合など、base64url-encodingペイロードが不要および/または採用の妨げとなる他のユースケースが説明されていますデタッチ。

This specification introduces a new JWS Header Parameter value that generalizes the JWS Signing Input computation in a manner that makes base64url-encoding the payload selectable and optional. The primary set of use cases where this enhancement may be helpful are those in which the payload may be very large and where means are already in place to enable the payload to be communicated between the parties without modifications. Appendix F of [JWS] describes how to represent JWSs with detached content, which would typically be used for these use cases.

この仕様では、base64urlエンコーディングでペイロードを選択可能およびオプションにする方法でJWS署名入力計算を一般化する新しいJWSヘッダーパラメーター値が導入されています。この機能強化が役立つ主な使用例は、ペイロードが非常に大きくなる可能性があり、変更なしでペイロードをパーティ間で通信できるようにする手段がすでに用意されている場合です。 [JWS]の付録Fでは、分離されたコンテンツでJWSを表す方法について説明します。これは、通常、これらの使用例で使用されます。

The advantages of not having to base64url-encode a large payload are that allocation of the additional storage to hold the base64url-encoded form is avoided and the base64url-encoding computation never has to be performed. In summary, this option can help avoid unnecessary copying and transformations of the potentially large payload, resulting in sometimes significant space and time improvements for deployments.

大きなペイロードをbase64url-encodeする必要がないことの利点は、base64url-encodedフォームを保持するための追加ストレージの割り当てが回避され、base64url-encoding計算を実行する必要がないことです。要約すると、このオプションは、潜在的に大きなペイロードの不必要なコピーと変換を回避するのに役立ち、デプロイメントのスペースと時間を大幅に改善することがあります。

1.1. Notational Conventions

1.1. 表記規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. The interpretation should only be applied when the terms appear in all capital letters.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「は、「RFCで使用して要件レベルを示すためのキーワード」[RFC2119]で説明されているように解釈されます。解釈が適用されるのは、用語がすべて大文字である場合のみです。

BASE64URL(OCTETS) denotes the base64url encoding of OCTETS, per Section 2 of [JWS].

BASE64URL（OCTETS）は、[JWS]のセクション2に従って、OCTETSのbase64urlエンコーディングを示します。

UTF8(STRING) denotes the octets of the UTF-8 [RFC3629] representation of STRING, where STRING is a sequence of zero or more Unicode [UNICODE] characters.

UTF8（STRING）は、STRINGのUTF-8 [RFC3629]表現のオクテットを示します。STRINGは、ゼロ個以上のUnicode [UNICODE]文字のシーケンスです。

ASCII(STRING) denotes the octets of the ASCII [RFC20] representation of STRING, where STRING is a sequence of zero or more ASCII characters.

ASCII（STRING）は、STRINGのASCII [RFC20]表現のオクテットを示します。STRINGは、0個以上のASCII文字のシーケンスです。

The concatenation of two values A and B is denoted as A || B.

2つの値AとBの連結は、A ||として示されます。Ｂ．

2. Terminology

2. 用語

This specification uses the same terminology as the "JSON Web Signature" [JWS] and "JSON Web Algorithms" [JWA] specifications.

この仕様では、「JSON Web Signature」[JWS]および「JSON Web Algorithms」[JWA]仕様と同じ用語を使用しています。

3. The "b64" Header Parameter

3. 「b64」ヘッダーパラメータ

This Header Parameter modifies the JWS Payload representation and the JWS Signing Input computation in the following way:

このヘッダーパラメータは、JWSペイロード表現とJWS署名入力の計算を次のように変更します。

b64 The "b64" (base64url-encode payload) Header Parameter determines whether the payload is represented in the JWS and the JWS Signing Input as ASCII(BASE64URL(JWS Payload)) or as the JWS Payload value itself with no encoding performed. When the "b64" value is "false", the payload is represented simply as the JWS Payload value; otherwise, it is represented as ASCII(BASE64URL(JWS Payload)). The "b64" value is a JSON boolean, with a default value of "true". When used, this Header Parameter MUST be integrity protected; therefore, it MUST occur only within the JWS Protected Header. Use of this Header Parameter is OPTIONAL. If the JWS has multiple signatures and/or MACs, the "b64" Header Parameter value MUST be the same for all of them. Note that unless the payload is detached, many payload values would cause errors parsing the resulting JWSs, as described in Section 5.

b64 "b64"（base64url-encodeペイロード）ヘッダーパラメーターは、ペイロードがJWSおよびJWS署名入力でASCII（BASE64URL（JWS Payload））として表されるか、エンコードが実行されていないJWS Payload値自体として表されるかを決定します。「b64」値が「false」の場合、ペイロードは単にJWSペイロード値として表されます。それ以外の場合は、ASCII（BASE64URL（JWS Payload））として表されます。「b64」値はJSONブール値で、デフォルト値は「true」です。使用する場合、このヘッダーパラメーターは整合性を保護する必要があります。したがって、JWS保護ヘッダー内でのみ発生する必要があります。このヘッダーパラメータの使用はオプションです。 JWSに複数のシグネチャやMACがある場合、「b64」ヘッダーパラメータ値はそれらすべてで同じでなければなりません。セクション5で説明されているように、ペイロードが切り離されていない限り、多くのペイロード値は結果のJWSの解析エラーを引き起こすことに注意してください。

The following table shows the JWS Signing Input computation, depending upon the value of this parameter:

次の表は、このパラメーターの値に応じたJWS署名入力の計算を示しています。

   +-------+-----------------------------------------------------------+
   | "b64" | JWS Signing Input Formula                                 |
   +-------+-----------------------------------------------------------+
   | true  | ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.' ||     |
   |       | BASE64URL(JWS Payload))                                   |
   |       |                                                           |
   | false | ASCII(BASE64URL(UTF8(JWS Protected Header)) || '.') ||    |
   |       | JWS Payload                                               |
   +-------+-----------------------------------------------------------+

4. Examples

4. 例

This section gives examples of JWSs showing the difference that using the "b64" Header Parameter makes. The examples all use the JWS Payload value [36, 46, 48, 50]. This octet sequence represents the ASCII characters "$.02"; its base64url-encoded representation is "JC4wMg".

このセクションでは、「b64」ヘッダーパラメータを使用することによる違いを示すJWSの例を示します。すべての例では、JWSペイロード値[36、46、48、50]を使用しています。このオクテットシーケンスは、ASCII文字「$ .02」を表します。 base64urlでエンコードされた表現は「JC4wMg」です。

The following table shows a set of Header Parameter values without using a false "b64" Header Parameter value and a set using it, with the resulting JWS Signing Input values represented as ASCII characters:

次の表は、偽の「b64」ヘッダーパラメーター値を使用しないヘッダーパラメーター値のセットとそれを使用するセットを示し、結果のJWS署名入力値はASCII文字として表されます。

   +-----------------------------+-------------------------------------+
   | JWS Protected Header        | JWS Signing Input Value             |
   +-----------------------------+-------------------------------------+
   | {"alg":"HS256"}             | eyJhbGciOiJIUzI1NiJ9.JC4wMg         |
   |                             |                                     |
   | {"alg":"HS256","b64":false, | eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2U |
   | "crit":["b64"]}             | sImNyaXQiOlsiYjY0Il19.$.02          |
   +-----------------------------+-------------------------------------+

These examples use the Hash-based Message Authentication Code (HMAC) key from Appendix A.1 of [JWS], which is represented below as a JSON Web Key [JWK] (with line breaks within values for display purposes only):

これらの例では、[JWS]の付録A.1のハッシュベースのメッセージ認証コード（HMAC）キーを使用します。これは、JSON Webキー[JWK]として以下に表されます（表示目的でのみ、値内に改行があります）：

     {
      "kty":"oct",
      "k":"AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75
           aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow"
     }

The rest of this section shows complete representations for the two JWSs above.

このセクションの残りの部分では、上記の2つのJWSの完全な表現を示します。

4.1. Example with Header Parameters {"alg":"HS256"}

4.1. ヘッダーパラメータの例{"alg"： "HS256"}

The complete JWS representation for this example using the JWS Compact Serialization and a non-detached payload (with line breaks for display purposes only) is:

JWSコンパクトシリアライゼーションと分離されていないペイロードを使用したこの例の完全なJWS表現（表示目的のみの改行付き）は次のとおりです。

     eyJhbGciOiJIUzI1NiJ9
     .
     JC4wMg
     .
     5mvfOroL-g7HyqJoozehmsaqmvTYGEq5jTI1gVvoEoQ

Note that this JWS uses only features defined by [JWS] and does not use the new "b64" Header Parameter. It is the "control" so that differences when it is used can be easily seen.

このJWSは[JWS]で定義された機能のみを使用し、新しい「b64」ヘッダーパラメータを使用しないことに注意してください。使用時の違いがわかりやすい「コントロール」です。

The equivalent representation for this example using the flattened JWS JSON Serialization is:

フラット化されたJWS JSONシリアル化を使用したこの例の同等の表現は次のとおりです。

     {
      "protected":
       "eyJhbGciOiJIUzI1NiJ9",
      "payload":
       "JC4wMg",
      "signature":
       "5mvfOroL-g7HyqJoozehmsaqmvTYGEq5jTI1gVvoEoQ"
     }

4.2.  Example with Header Parameters
      {"alg":"HS256","b64":false,"crit":["b64"]}

The complete JWS representation for this example using the JWS Compact Serialization and a detached payload (with line breaks for display purposes only) is:

JWSコンパクトシリアライゼーションと分離されたペイロードを使用したこの例の完全なJWS表現（表示目的のみの改行付き）は次のとおりです。

eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19 . . A5dxf2s96_n5FLueVuW1Z_vh161FwXZC4YLPff6dmDY

eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19。。 A5dxf2s96_n5FLueVuW1Z_vh161FwXZC4YLPff6dmDY

Note that the payload "$.02" cannot be represented in this JWS in its unencoded form because it contains a period ('.') character, which would cause parsing problems. This JWS is therefore shown with a detached payload.

ペイロード "$ .02"にはピリオド（ '。'）文字が含まれているため、このJWSではエンコードされていない形式で表現できないことに注意してください。これにより、解析の問題が発生します。したがって、このJWSは、分離されたペイロードとともに表示されます。

The complete JWS representation for this example using the flattened JWS JSON Serialization and a non-detached payload is:

フラット化されたJWS JSONシリアル化と分離されていないペイロードを使用するこの例の完全なJWS表現は次のとおりです。

     {
      "protected":
       "eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19",
      "payload":
       "$.02",
      "signature":
       "A5dxf2s96_n5FLueVuW1Z_vh161FwXZC4YLPff6dmDY"
     }

If using a detached payload with the JWS JSON Serialization, the "payload" element would be omitted.

JWS JSONシリアル化でデタッチされたペイロードを使用する場合、「payload」要素は省略されます。

5. Unencoded Payload Content Restrictions

5. エンコードされていないペイロードコンテンツの制限

When the "b64" value is "false", different restrictions on the payload contents apply, depending upon the circumstances, as described in this section. The restrictions prevent the use of payload values that would cause errors parsing the resulting JWSs.

「b64」値が「false」の場合、このセクションで説明するように、状況に応じてペイロードの内容に異なる制限が適用されます。制限により、結果のJWSの解析エラーを引き起こすペイロード値の使用が防止されます。

Note that because the character sets that can be used for unencoded non-detached payloads differ between the two serializations, some JWSs using a "b64" value of "false" cannot be syntactically converted between the JWS JSON Serialization and the JWS Compact Serialization. See Section 8 for security considerations on using unencoded payloads.

エンコードされていない非分離ペイロードに使用できる文字セットは2つのシリアライゼーション間で異なるため、「false」の「b64」値を使用する一部のJWSは、JWS JSONシリアライゼーションとJWSコンパクトシリアライゼーションの間で構文的に変換できないことに注意してください。エンコードされていないペイロードの使用に関するセキュリティの考慮事項については、セクション8を参照してください。

5.1. Unencoded Detached Payload

5.1. エンコードされていない切り離されたペイロード

Appendix F of [JWS] describes how to represent JWSs with detached content. A detached payload can contain any octet sequence representable by the application. The payload value will not cause problems parsing the JWS, since it is not represented as part of the JWS. If an application uses a content encoding when representing the payload, then it MUST specify whether the signature or MAC is performed over the content-encoded representation or over the unencoded content.

[JWS]の付録Fは、分離されたコンテンツでJWSを表す方法を説明しています。デタッチされたペイロードには、アプリケーションで表現可能な任意のオクテットシーケンスを含めることができます。ペイロード値はJWSの一部として表されないため、JWSの解析に問題は発生しません。アプリケーションがペイロードを表すときにコンテンツエンコーディングを使用する場合、署名またはMACがコンテンツエンコードされた表現上で実行されるか、エンコードされていないコンテンツ上で実行されるかを指定する必要があります。

5.2. Unencoded JWS Compact Serialization Payload

5.2. エンコードされていないJWSコンパクトシリアライゼーションペイロード

When using the JWS Compact Serialization, unencoded non-detached payloads using period ('.') characters would cause parsing errors; such payloads MUST NOT be used with the JWS Compact Serialization. Similarly, if a JWS using the JWS Compact Serialization and a non-detached payload is to be transmitted in a context that requires URL-safe characters, then the application MUST ensure that the payload contains only the URL-safe characters 'a'-'z', 'A'-'Z', '0'-'9', dash ('-'), underscore ('_'), and tilde ('~'). The payload value is the ASCII representation of the characters in the payload string. The ASCII space character and all printable ASCII characters other than period ('.') (those characters in the ranges %x20-2D and %x2F-7E) MAY be included in a non-detached payload using the JWS Compact Serialization, provided that the application can transmit the resulting JWS without modification.

JWSコンパクトシリアライゼーションを使用する場合、ピリオド（ '。'）文字を使用する、エンコードされていない非分離ペイロードは、解析エラーの原因になります。このようなペイロードは、JWS Compact Serializationと共に使用してはなりません（MUST NOT）。同様に、JWSコンパクトシリアル化と非分離ペイロードを使用するJWSがURLセーフ文字を必要とするコンテキストで送信される場合、アプリケーションはペイロードにURLセーフ文字 'a'-'のみが含まれていることを確認する必要があります。 z '、' A '-' Z '、' 0 '-' 9 '、ダッシュ（'-'）、下線（' _ '）、およびチルダ（'〜 '）。ペイロード値は、ペイロード文字列の文字のASCII表現です。 ASCIIスペース文字およびピリオド（ '。'）以外のすべての印刷可能なASCII文字（％x20-2Dおよび％x2F-7Eの範囲の文字）は、JWSコンパクトシリアライゼーションを使用して、分離されていないペイロードに含めることができます。アプリケーションは結果のJWSを変更せずに送信できます。

No meaning or special semantics are attached to any characters in the payload. For instance, the percent ('%') character represents itself and is not used by JWS objects for percent-encoding [RFC3986]. Applications, of course, are free to utilize content-encoding rules of their choosing, provided that the encoded representations utilize only allowed payload characters.

ペイロード内の文字には、意味や特別なセマンティクスが付加されていません。たとえば、パーセント（ '％'）文字はそれ自体を表し、パーセントエンコード[RFC3986]のJWSオブジェクトでは使用されません。エンコードされた表現が許可されたペイロード文字のみを使用するという条件で、アプリケーションはもちろん、選択したコンテンツエンコーディングルールを自由に使用できます。

5.3. Unencoded JWS JSON Serialization Payload

5.3. エンコードされていないJWS JSONシリアル化ペイロード

When using the JWS JSON Serialization, unencoded non-detached payloads must consist of the octets of the UTF-8 encoding of a sequence of Unicode code points that are representable in a JSON string. The payload value is determined after performing any JSON string escape processing, per Section 8.3 of RFC 7159 [RFC7159], and then UTF-8-encoding the resulting Unicode code points. This means, for instance, that these payloads represented as JSON strings are equivalent ("$.02", "\u0024.02"). Unassigned Unicode code point values MUST NOT be used to represent the payload.

JWS JSONシリアライゼーションを使用する場合、エンコードされていない非分離ペイロードは、JSON文字列で表現可能なUnicodeコードポイントのシーケンスのUTF-8エンコーディングのオクテットで構成されている必要があります。ペイロード値は、RFC 7159 [RFC7159]のセクション8.3に従ってJSON文字列エスケープ処理を実行した後、結果のUnicodeコードポイントをUTF-8エンコードして決定されます。これは、たとえば、JSON文字列として表されるこれらのペイロードは同等であることを意味します（ "$ .02"、 "\ u0024.02"）。ペイロードを表すために、割り当てられていないUnicodeコードポイント値を使用してはなりません（MUST NOT）。

6. Using "crit" with "b64"

6. 「crit」と「b64」の併用

The "crit" Header Parameter MUST be included with "b64" in its set of values when using the "b64" Header Parameter to cause implementations not implementing "b64" to reject the JWS (instead of it being misinterpreted).

「b64」を実装していない実装がJWSを（誤って解釈されるのではなく）拒否するようにするために、「b64」ヘッダーパラメーターを使用する場合は、「crit」ヘッダーパラメーターを値のセットに「b64」とともに含める必要があります。

7. Intended Use by Applications

7. アプリケーションによる使用目的

Application profiles should specify whether "b64" with a "false" value is to be used by the application in each application context or not, with it then being consistently applied in each application context. For instance, an application that uses detached payloads might specify that "b64" with a "false" value always be used. It is NOT RECOMMENDED that this parameter value be dynamically varied with different payloads in the same application context.

アプリケーションプロファイルは、 "false"値を持つ "b64"が各アプリケーションコンテキストでアプリケーションによって使用されるかどうかを指定する必要があり、その後、各アプリケーションコンテキストで一貫して適用されます。たとえば、デタッチされたペイロードを使用するアプリケーションは、常に「false」値を持つ「b64」が使用されることを指定する場合があります。このパラメーター値を、同じアプリケーションコンテキスト内の異なるペイロードで動的に変更することはお勧めしません。

While it is legal to use "b64" with a "true" value, it is RECOMMENDED that "b64" simply be omitted in this case, since it would be selecting the behavior already specified in [JWS].

「b64」を「true」の値で使用することは正当ですが、[JWS]ですでに指定されている動作を選択することになるため、この場合は単に「b64」を省略することをお勧めします。

For interoperability reasons, JSON Web Tokens [JWT] MUST NOT use "b64" with a "false" value.

相互運用性の理由から、JSON Webトークン[JWT]は、「false」値を持つ「b64」を使用してはなりません（MUST NOT）。

8. Security Considerations

8. セキュリティに関する考慮事項

[JWS] base64url-encodes the JWS Payload to restrict the set of characters used to represent it so that the representation does not contain characters used for delimiters in JWS representations. Those delimiters are the period ('.') character for the JWS Compact Serialization and the double-quote ('"') character for the JWS JSON Serialization. When the "b64" (base64url-encode payload) value is "false", these properties are lost. It then becomes the responsibility of the application to ensure that payloads only contain characters that will not cause parsing problems for the serialization used, as described in Section 5. The application also incurs the responsibility to ensure that the payload will not be modified during transmission.

[JWS] base64urlは、JWSペイロードをエンコードして、それを表すために使用される文字のセットを制限し、JWS表現の区切り文字として使用される文字が表現に含まれないようにします。これらの区切り文字は、JWS Compact Serializationのピリオド（ '。'）文字とJWS JSON Serializationの二重引用符（ '"'）文字です。" b64 "（base64url-encodeペイロード）値が" false "の場合、これらのプロパティは失われます。次に、セクション5で説明するように、使用されるシリアル化の解析問題を引き起こさない文字のみがペイロードに含まれるようにすることは、アプリケーションの責任になります。アプリケーションには、ペイロードが確実に実行されないようにする責任もあります。送信中に変更されます。

Note that if a JWS were to be created with a "b64" value of "false" without including the "crit" Header Parameter with "b64" in its set of values and it were to be received by an implementation not supporting the "b64" Header Parameter, then the signature or MAC would still verify but the recipient would believe that the intended JWS Payload value is the base64url decoding of the payload value received, rather than the payload value received itself. For example, if the payload value received were "NDA1", an implementation not supporting this extension would interpret the intended payload as being the base64url decoding of this value, which is "405". Requiring the use of the "crit" Header Parameter with "b64" in the set of values prevents this misinterpretation.

値のセットに「c64」を含む「crit」ヘッダーパラメーターを含めずに「false」の「b64」値でJWSを作成し、「b64」をサポートしない実装がそれを受け取ることに注意してください。 "ヘッダーパラメータの場合、署名またはMACは引き続き検証されますが、受信者は、意図したJWSペイロード値が、受信したペイロード値自体ではなく、受信したペイロード値のbase64urlデコードであると信じます。たとえば、受信したペイロード値が「NDA1」の場合、この拡張機能をサポートしていない実装は、意図したペイロードをこの値のbase64urlデコード（「405」）として解釈します。値のセットに「b64」を含む「crit」ヘッダーパラメータを使用する必要があるため、この誤解を防ぐことができます。

9. IANA Considerations

9. IANAに関する考慮事項

9.1. JSON Web Signature and Encryption Header Parameter Registration

9.1. JSON Web署名と暗号化ヘッダーのパラメーター登録

This specification registers the "b64" Header Parameter defined in Section 3 in the IANA "JSON Web Signature and Encryption Header Parameters" registry [IANA.JOSE] established by [JWS].

この仕様は、[JWS]によって確立されたIANA "JSON Web Signature and Encryption Header Parameters"レジストリ[IANA.JOSE]のセクション3で定義された「b64」ヘッダーパラメーターを登録します。

9.1.1. Registry Contents

9.1.1. レジストリの内容

o Header Parameter Name: "b64" o Header Parameter Description: Base64url-Encode Payload o Header Parameter Usage Location(s): JWS o Change Controller: IESG o Specification Document(s): Section 3 of RFC 7797

o ヘッダーパラメーター名：「b64」oヘッダーパラメーターの説明：Base64url-Encodeペイロードoヘッダーパラメーターの使用場所：JWS o変更コントローラー：IESG o仕様書：RFC 7797のセクション3

10. References

10. 参考文献

10.1. Normative References

10.1. 引用文献

[IANA.JOSE] IANA, "JSON Object Signing and Encryption (JOSE)", <http://www.iana.org/assignments/jose>.

[IANA.JOSE] IANA、「JSON Object Signing and Encryption（JOSE）」、<http://www.iana.org/assignments/jose>。

[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.

[JWA]ジョーンズ、M。、「JSON Web Algorithms（JWA）」、RFC 7518、DOI 10.17487 / RFC7518、2015年5月、<http://www.rfc-editor.org/info/rfc7518>。

[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <http://www.rfc-editor.org/info/rfc7515>.

[JWS]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<http://www.rfc-editor.org / info / rfc7515>。

[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <http://www.rfc-editor.org/info/rfc7519>.

[JWT]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<http://www.rfc-editor.org / info / rfc7519>。

[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80, RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>.

[RFC20] Cerf、V。、「ASCII format for Network Interchange」、STD 80、RFC 20、1969年10月、<http://www.rfc-editor.org/info/rfc20>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.

[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。

[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.

[RFC7159]ブレイ、T。、編、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。

[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.

[UNICODE] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。

10.2. Informative References

10.2. 参考引用

[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <http://www.rfc-editor.org/info/rfc7517>.

[JWK]ジョーンズ、M。、「JSON Web Key（JWK）」、RFC 7517、DOI 10.17487 / RFC7517、2015年5月、<http://www.rfc-editor.org/info/rfc7517>。

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。

Acknowledgements

謝辞

Anders Rundgren, Richard Barnes, Phillip Hallam-Baker, Jim Schaad, Matt Miller, Martin Thomson, and others have all made the case for being able to use a representation of the payload that is not base64url encoded in contexts in which it safe to do so.

Anders Rundgren、Richard Barnes、Phillip Hallam-Baker、Jim Schaad、Matt Miller、Martin Thomson、その他はすべて、安全に実行できるコンテキストでbase64urlエンコードされていないペイロードの表現を使用できるようにしたそう。

Thanks to Sergey Beryozkin, Stephen Farrell, Benjamin Kaduk, James Manger, Kathleen Moriarty, Axel Nennker, Anders Rundgren, Nat Sakimura, Jim Schaad, Robert Sparks, and Matias Woloski for their reviews of the specification, and thanks to Vladimir Dzhuvinov for verifying the examples.

仕様のレビューを提供してくれたSergey Beryozkin、Stephen Farrell、Benjamin Kaduk、James Manger、Kathleen Moriarty、Axel Nennker、Anders Rundgren、Nat Sakimura、Jim Schaad、Robert Sparks、およびMatias Woloskiに感謝します。また、Vladimir Dzhuvinov例。

Author's Address

著者のアドレス

Michael B. Jones Microsoft

マイケルB.ジョーンズマイクロソフト

   Email: mbj@microsoft.com
   URI:   http://self-issued.info/