ヘッダー引数

JWS

仕様書

構文

[9] JSON Web Signature (JWS) は、 デジタル的に RFC 4949 署名されまたは RFC 4949 MAC されたメッセージです。 >>8, >>22

[21] JWS には、一貫性保護のない非保安JWSが含まれます。

[23] JWS は、 RFC 7159 JSON データや base64url を使って記述されます。 JSON は、その定めるところにより、 値の前後に空白を挿入できます。 JSON >>22

[24] JWS は、論理的に JOSEヘッダーJWSペイロードJWS署名で構成されます。

[25] JWS
JOSEヘッダー
JWS保護ヘッダーJWS非保護ヘッダー
JWSペイロード
JWS署名

[11] JWSペイロード (JWS Payload) は、 保安される (secured) オクテット列すなわち (aka) メッセージ (message) です。 ペイロードは、 任意のオクテット列を含められます。 >>8

[12] JWS署名 (JWS Signature) は、 JWS保護ヘッダーJWSペイロードに関する RFC 4949 デジタル署名RFC 4949 MAC です。 >>8

[16] JWS署名入力 (JWS Signing Input) は、 RFC 4949 デジタル署名または RFC 4949 MAC 計算への入力です。 この値は、

  1. RFC 20 ASCII (RFC 7515 BASE64URL (RFC 3629 UTF8 (JWS保護ヘッダー)))
  2. .
  3. RFC 7515 BASE64URL (JWSペイロード)

... を順に連結した結果です。 >>8

[20] StringOrURI は、 JSON文字列値であって、 任意の文字列値であっても構わないものの、 : が含まれる場合は RFC 3986 URI でなければならないものです。 比較は、 大文字・小文字区別ありで変形や正準化なく行います。 >>8

[62] alg耐衝突名かつ StringOrURI とされています。


[173] JWS のうち JWSペイロードを含めない、 つまり JWS 生成後に JWS簡潔直列化にあっては該当部分を空文字列とし、 JWS JSON直列化にあっては payload を削除したものを扱うのが時に有用なのであって、 受信者も別の手段で JWSペイロード相当の情報を入手し、 容易に JWS を再構築し得るものである、 と仕様書に敢えて言及があります >>172

[174] しかしなぜか本体仕様とは別に簡単に説明されているに過ぎず、 しかも送受信者がそのような簡単な操作で標準的な JWS のライブラリーの入出力を改変して実現可能だ、 と JWS 本体ではなく応用側で実装するべきものとしています。 本当にそのような需要があるのなら、 こうした取ってつけた説明ではなく JWS 本体仕様に組み込んで詳細に規定するべきで、不可解です。

直列化

[27] JWS は、 JWS簡潔直列化JWS JSON直列化の 2種類の表現方法があります >>31JWS JSON直列化の方が高い記述能力を持ちます。

[32] JWS を使う応用は、 どちらの直列化を使うか、 どの直列化機能 (feature) を使うかを、 規定する必要があります。 JWS の実装は、 対応したい応用で必要な機能のみ実装する必要があります。 >>31

[33] 例えば、 「JWS JSON直列化で署名か MAC の値は1つだけ対応する」 のような定めが可能です。 >>31

JWS簡潔直列化

[17] JWS簡潔直列化 (JWS Compact Serialization) は、 JWS を簡潔で URL 安全な文字列として表現したものです。 >>8

[28] JWS簡潔直列化では、 JWS非保護ヘッダーを使うことが出来ません。 JOSEヘッダー = JWS保護ヘッダーです。 >>8, >>22

[29] JWS簡潔直列化は、 次のものを順に連結したものです。 >>22, >>31

  1. RFC 7515 BASE64URL (RFC 3629 UTF8 (JWS保護ヘッダー))
  2. .
  3. RFC 7515 BASE64URL (JWSペイロード)
  4. .
  5. RFC 7515 BASE64URL (JWS署名)

[34] 署名MAC は1つだけしか指定できません。 >>31

[145] MIME型application/jose です。 JWS または JWE の簡潔直列化を表します。 >>142

JWS JSON直列化

[18] JWS JSON直列化 (JWS JSON Serialization) は、 JWSJSONオブジェクトとして表現したものです。 JWS簡潔直列化と違って、 複数の RFC 4949 デジタル署名RFC 4949 MAC一方又は両方を同じ内容に適用できます。 簡潔性や URL 安全性は重視していません。 >>8

[30] JWS JSON直列化では、 JWS保護ヘッダーJWS非保護ヘッダーの両方を使うことができます >>8, >>22。 どちらか一方は存在しなければなりません >>22JOSEヘッダーは両者全体で構成されます >>8, >>22

[35] 一般構文と呼ばれるものと、平坦化構文と呼ばれるものの2種類があります。 >>31

[146] MIME型application/jose+json です。 JWS または JWE の JSON 直列化を表します。 JSONオブジェクトUTF-8 で符号化するべきです>>142

[147] なぜ UTF-8 以外の余地を残しているのか謎です。

一般構文

[36] (完全)一般JWS JSON直列化構文 ((fully) general JWS JSON serialization syntax) は、 次のような最上位の JSONオブジェクトです。 >>31

[38] JSONオブジェクト
payload
RFC 7516 BASE64URL (JWSペイロード)。 必須>>31
signatures
JSONオブジェクト配列でなければなりません
[40] JSON配列

[41]JSONオブジェクトは、 JWSペイロードJWS保護ヘッダー署名MAC を表します。 >>31

[39] JSONオブジェクト
protected
JWS保護ヘッダー値が空でない時、 RFC 7515 BASE64URL (RFC 3629 UTF8 (JWS保護ヘッダー)) でなければなりませんヘッダー引数値は一貫性保護されます。 そうでないとき、 省略しなければなりません>>31
header
JWS非保護ヘッダー値が空でない時、 JWS非保護ヘッダーたる JSON 値でなければなりませんヘッダー引数値は一貫性保護されません。 そうでないとき、 省略しなければなりません>>31
signature
RFC 5715 BASE64URL (JWS署名) でなければなりません>>31
その他
他のメンバーを指定できます。 実装は、理解できないものを無視しなければなりません>>31

[42] protected または header の一方または両方がなければなりません。 最低でも alg ヘッダー引数が必要です。 >>31

[43] 署名MAC 値の作成や検証に使うヘッダー引数は、 protectedheader合同して得られる JOSEヘッダーです。 両者のヘッダー引数の名前は、互いに素でなければなりません>>31

その他
他のメンバーを指定できます。 実装は、理解できないものを無視しなければなりません>>31 (protected, header, signature も禁止はされていません。)

平坦化構文

[37] 平滑化JWS JSON直列化構文 (flattened JWS JSON serialization syntax) は、 単一のデジタル署名MAC の場合に最適化したもので、 次のような最上位 JSONオブジェクトです。 >>31

[44] JSONオブジェクト
payload
RFC 7516 BASE64URL (JWSペイロード)。 必須>>31
protected
JWS保護ヘッダー値が空でない時、 RFC 7515 BASE64URL (RFC 3629 UTF8 (JWS保護ヘッダー)) でなければなりませんヘッダー引数値は一貫性保護されます。 そうでないとき、 省略しなければなりません>>31
header
JWS非保護ヘッダー値が空でない時、 JWS非保護ヘッダーたる JSON 値でなければなりませんヘッダー引数値は一貫性保護されません。 そうでないとき、 省略しなければなりません>>31
signature
RFC 5715 BASE64URL (JWS署名) でなければなりません>>31
その他
他のメンバーを指定できます。 実装は、理解できないものを無視しなければなりませんsignatures があってはなりません>>31

[45] protected または header の一方または両方がなければなりません。 最低でも alg ヘッダー引数が必要です。 >>31

[46] 署名MAC 値の作成や検証に使うヘッダー引数は、 protectedheader合同して得られる JOSEヘッダーです。 両者のヘッダー引数の名前は、互いに素でなければなりません>>31

JOSE ヘッダー

[10] JOSEヘッダー (JOSE Header) は、 使用する RFC 4949 デジタル署名RFC 4949 MAC演算引数を記述する JSONオブジェクトです。 >>8, >>47 更に追加の情報も含めることが出来ます。 >>47

[13] ヘッダー引数 (Header Parameter) は、 JOSEヘッダーメンバーたる名前 (name) (value) です。 >>8

[48] ヘッダー引数の名前は、JOSEヘッダー内で固有でなければなりませんJWS 構文解析器は、 JWSヘッダー引数の重複を含む時、 これを拒絶するか、 または重複するメンバー名について字句的に最後のもののみ採用する JavaScript JSON.parse と同じ挙動の JSON 構文解析器を使うかしなければなりません>>47, >>148 さらに、 JWS保護ヘッダーJWS非保護ヘッダーの間でも同名があってはなりません (>>43, >>46)。

[49] JSONオブジェクトは、 {"name": "value1", "name": "value2"} のごとく同名のメンバーを複数含めることが出来ます。 JWS はこれを拒絶するか、最後の value2 のみ採用することを求めています。 挙動に曖昧性が認められるのは、 相互運用性の火種であり、 とりわけセキュリティー技術には好ましからざる性質です。 どちらとも実装し得る JSON 仕様側の問題といえなくもないですが。 JSON の標準的な実装である JSON.parse の挙動、すなわちエラーとせず最後のもののみを採用するのが好ましいと考えられます。

[26] JWSJOSEヘッダーのメンバーは、 JWS保護ヘッダーJWS非保護ヘッダーの各メンバーの合同です。 >>22

[14] JWS保護ヘッダー (JWS Protected Header) は、 JWS署名RFC 4949 デジタル署名または RFC 4949 MAC演算によって一貫性保護されたヘッダー引数を含む JSONオブジェクトです。 >>8

[15] JWS非保護ヘッダー (JWS Unprotected Header) は、 一貫性保護されていないヘッダー引数を含む JSONオブジェクトです。 >>8


[50] 実装は、理解しなければならないと規定されたヘッダー引数を、 理解し処理しなければなりません。 >>47

[51] それ以外は、理解できない場合無視しなければなりません。 ただし、 crit が適用されるものを除きます。 >>47

crit ヘッダー引数

[70] ヘッダー引数 crit (critical) は、 JWSJWA仕様書に対する拡張が使われていて、 これを理解して処理しなければならないことを示すものです。 >>69


[71] 値は、 当該拡張を使う JOSEヘッダーヘッダー引数名の配列です。 >>69

[73] 生成器は、 JWSJWA仕様書で定められたヘッダー引数名を指定してはなりません>>69

[74] 生成器は、 ヘッダー引数名を重複して指定したり、 JOSEヘッダー内に出現しないヘッダー引数名を指定したりしてはなりません>>69


[79] crit の使用は任意です。 >>69

[75] 生成器は、 空の配列を指定してはなりません>>69

[78] crit を使う場合、 JWS保護ヘッダーに含めなければなりません>>69 JWS非保護ヘッダーでは使えません。


[80] 実装は、ヘッダー引数 crit を理解し処理しなければなりません>>69

[76] 受信者は、 crit の値が制約 (>>73, >>74, >>75) 違反のとき、 当該 JWS非妥当とみなして構いません>>69

[77] なぜ必須でないのか不明です。 これでは相互運用性の罠です。

[72] 受信者が指定されたヘッダー引数のいずれかを理解対応していない場合には、 当該 JWS非妥当です。 >>69

ヘッダー引数の一覧

[56] ヘッダー引数

ヘッダー引数名の登録

[52] ヘッダー引数名には、 登録ヘッダー引数名公開ヘッダー引数名私的ヘッダー引数名の3種類 (class) があります。 >>47 この「class」は互いに素のようにも感じられますが、 仕様書の定義が曖昧で意図を掴みかねます。

[53] 登録ヘッダー引数名 (Registered Header Parameter name) は、 IANA登録簿に登録されたものです >>47IANA登録簿JWSJWE で共通で、一方または両方で使用するかを指定できます >>142JWSJWE の両方で使うものを定める場合、用法が一貫していなければなりません >>47

[143] 登録するヘッダー引数名は、 短く、原則として8文字以下であるべきとされています。 >>142

[144] 一般にヘッダー引数名は大文字・小文字区別ありですが、 登録時に指定専門家が必要と認めた場合を除き、 大文字・小文字不区別で既存の名称と一致するものは登録できません。 >>142

[54] 公開ヘッダー引数名 (Public Header Parameter name) >>47 が何であるか仕様書はなぜか明確に述べていませんが、 登録ヘッダー引数名でも私的ヘッダー引数名でもないものとみられます。

[57] 公開ヘッダー引数名に関する仕様書の節には、 次のようにあります。 JWS 利用者は、 RFC 7515 にない追加のヘッダー引数名を定義できますが、 IANA登録簿に登録するか、 または Public Name (耐衝突名が含まれる値) であるかとするべき (should) です。 いずれにせよ、 定義者は、 名前を定義するため使う名前空間の部分に関して、 制御下に置かれるべく十分に注意を払う必要があります。 >>47 (この Public Name が公開ヘッダー引数名を指しているとも解せます。 主語の利用者が誰を指すか明らかではありませんが (私的ヘッダー引数名との違いに注意)、 JWS を利用する技術の仕様策定者とみるべきでしょうか。)

[58] 新しいヘッダー引数の追加は、相互運用性の低下を招き得るため、 慎重にするべき (should) です。 >>47

[55] 私的ヘッダー引数名 (Private Header Parameter name) >>47 が何であるか仕様書はなぜか不明瞭にしていますが、 仕様書私的ヘッダー引数名の節には、 JWS の生成者と消費者は Private Names (登録ヘッダー引数名でない名前) や公開ヘッダー引数名を使うことに合意して構わない >>47 とあります。 この Private Names が私的ヘッダー引数名とも解し得ますが、 「登録ヘッダー引数名でない」 ならそれは公開ヘッダー引数名を含むとも考えられ、 だとすると敢えて公開ヘッダー引数名に言及しているのが不審です。 公開ヘッダー引数名と違って私的ヘッダー引数名は衝突の恐れがあり、 注意して使うべきである >>47 とされており、だとすると両者は互いに素であるとも思われます。

[59] この通りヘッダー引数名には3つの分類がありますが、 仕様書は注意せよと言っているだけで、 利用の制限も特になく、 定義も曖昧で、 実質的な違いはないといって良いでしょう。

[60] 相互運用性を考慮すると、 JWS を使う応用は、 それぞれどれを実装しなければならないか定め、 それ以外は実装してはならないと定める必要がありそうです。 JWS の実装は、 その適用対象の応用に合わせ、 不要なものを生成せず、 対応が求められていないものを無視することを徹底するべきでしょう。

処理

作成

[82] JWSを作成 (create a JWS) するには、 JWSペイロードJSONオブジェクトまたは null JWS保護ヘッダーJSONオブジェクトまたは null JWS非保護ヘッダーを、 次のようにします。 >>81

  1. [87] Assert: JOSEヘッダー (JWS保護ヘッダーJWS非保護ヘッダー) には alg ヘッダー引数が含まれなければなりません
  2. [83] 符号化ペイロード値を、 RFC 7515 BASE64URL (JWSペイロード) の結果に設定します。
  3. [84] 符号化ヘッダー値を、空文字列に設定します。
  4. [85] 符号化ヘッダー値nullない場合、
    1. [86] RFC 7515 BASE64URL (RFC 3629 UTF8 (JWS保護ヘッダー)) の結果に設定します。
  5. [88] JWS署名を、JWS署名を計算した結果に設定します。
    JWS署名入力
    RFC 20 ASCII (符号化ヘッダー値)、 .符号化ペイロード値順に連結した結果
    JOSEヘッダー
    JWS保護ヘッダーJWS非保護ヘッダー
  6. [89] 符号化署名値を、 RFC 7515 BASE64URL (JWS署名) の結果に設定します。
  7. [90] 符号化保護ヘッダーJWS非保護ヘッダー符号化ペイロード値符号化署名値について、 直列化した結果を返します。

[128] BOM を生成するべきか否か仕様書から明らかではありません。一般的には Encoding StandardUTF-8符号化のように BOM を生成しないものと解されています。

検証

[91] JWS検証 (validate) するには、 JWS を、 次のようにします。 >>81

  1. [92] 結果を、 JWS を構文解析した結果に設定します。
  2. [93] 結果失敗の場合、
    1. [94] を返し、ここで停止します。
  3. [95] ヘッダーバイト列を、 結果符号化ヘッダー値RFC 7515 base64url復号した結果に設定します。
  4. [96] ヘッダーバイト列失敗の場合、
    1. [97] を返し、ここで停止します。
  5. [99] ヘッダー文字列を、 ヘッダーバイト列RFC 3629 UTF-8 復号した結果に設定します。
  6. [100] ヘッダー文字列失敗の場合、
    1. [101] を返し、ここで停止します。
  7. [98] JWS保護ヘッダーを、 ヘッダー文字列RFC 7159 JSON として構文解析した結果に設定します。
  8. [102] JWS保護ヘッダーJSONオブジェクトない場合、
    1. [103] を返し、ここで停止します。
  9. [104] 結果JWS非保護ヘッダーnullない場合、
    1. [105] 結果JWS非保護ヘッダーのメンバーとJWS保護ヘッダーのメンバーについて、 メンバー名 (= ヘッダー引数名) に重複がある場合、
      1. [106] を返し、ここで停止します。
  10. [107] 結果JWS保護ヘッダーJWS保護ヘッダーについて、 JWS の規定により対応しなければならないとされるもの、 指定されたアルゴリズムにより対応しなければならないとされるもの、 crit ヘッダー引数で指定されたものについて、 実装が理解し処理できるヘッダー引数であること、 その値もまた理解し処理できるものであることを確認します。そうでない場合、
    1. [108] を返し、ここで停止します。
  11. [109] ペイロードバイト列を、 結果符号化ペイロード値RFC 7515 base64url復号した結果に設定します。
  12. [110] ペイロードバイト列失敗の場合、
    1. [111] を返し、ここで停止します。
  13. [112] 署名バイト列を、 結果符号化署名値RFC 7515 base64url復号した結果に設定します。
  14. [113] 署名バイト列失敗の場合、
    1. [114] を返し、ここで停止します。
  15. [115] JWS署名を、JWS署名を計算した結果に設定します。
    JWS署名入力
    RFC 20 ASCII (結果符号化ヘッダー値)、 .結果符号化ペイロード値順に連結した結果
    JOSEヘッダー
    JWS保護ヘッダー結果JWS非保護ヘッダー
  16. [116] 署名バイト列JWS署名ない場合、
    1. [117] を返し、ここで停止します。
  17. [119] ペイロード文字列を、 ペイロードバイト列RFC 3629 UTF-8 復号した結果に設定します。
  18. [120] ペイロード文字列失敗の場合、
    1. [121] を返し、ここで停止します。 仕様書になし
  19. [122] JWSペイロードを、 ペイロード文字列RFC 7159 JSONとして構文解析した結果に設定します。
  20. [123] JWSペイロードJSONオブジェクトない場合、
    1. [124] を返し、ここで停止します。 仕様書になし
  21. [118] JWS保護ヘッダー結果JWS非保護ヘッダーJWSペイロードを返します。

[125] JWS署名が複数含まれる時、 どれを検証するか、すべてを検証するかは応用が決めることとされています。 最低でも1つは検証しを返すことを確認しなければなりません>>81

[126] 検証結果がであっても、 アルゴリズム応用の期待するものでなければ、 非妥当とみなすべきです>>81

[127] UTF-8JSON復号について、参照している仕様が明確に方法を定めていないため、 相互運用性の問題が生じるおそれがあります。仕様書の厳密な解釈に従うことは避け、 明確な規定のある Encoding Standard BOMなしUTF-8復号または失敗ECMAScript JSON.stringify に倣うべきでしょう。

アルゴリズムと鍵

[134] JWS署名の計算に使われるアルゴリズムは、 alg ヘッダー引数に指定することになっています。 生成器は、これを指定しなければなりませんalg の値が受信器対応しているアルゴリズムでないとき、 妥当ではありません >>47検証失敗します。

[135] つまり、相互運用性のため、 応用は送受信者が対応しなければならないアルゴリズムを明確かつ限定的に規定しなければなりません。

[149] アルゴリズムの実装によってはJWS署名値内に含まれるアルゴリズムを使って検証する場合があります。 その場合でもそれが alg と一致しているか確認しなければなりません。 さもなくば alg に強いアルゴリズムを指定し、 実際には弱いアルゴリズムで攻撃することが可能となってしまいます。 >>148


[132] RFC 4949 デジタル署名または RFC 4949 MAC は、 必要なを決定できないとき、失敗します。 >>129, >>47

[130] 受信器は、 JWS の演算で使用するを、 ヘッダー引数 jku, jwk, kid, x5u, x5c, x5t, x5t#S256 の値から決定することもできますし、 JWS 仕様書の定めない別の方法で決めても構いません。

[131] 生成器は、 他の方法によってが決定されるべき場合を除き、 十分な情報をヘッダー引数に含めるべきです>>129

[137] x5ujku のように、 の決定にネットワークアクセスが発生し得るものもあります。 その場合、の選択に不定の時間を要することがあり、 パフォーマンスや実装戦略上、エラー処理上の特段の配慮が必要となります。 またの取得を試みた事実が送信者側または送信者の指定した第三者 (改竄を想定し得るケースでは、悪意ある第三者) に伝わり得ることにも注意が必要となります。 こうした懸念を排除できる場合を除き、 応用は外部からを取得する方法を認めるべきではありません。 汎用的な JWS の実装は、 明示的に求められない限り、 こうした手法を有効にするべきではありません。

[133] これらヘッダー引数の情報を使って信頼決定 (trust decision) する場合にあっては、 これらヘッダー引数一貫性保護しなければなりません >>129。 (つまり JWS保護ヘッダーとしなければなりません。) しかし信頼決定に使われる情報がだけの場合にあっては、 これらヘッダー引数一貫性保護せずとも構いません >>129。 なぜなら、が違えば検証失敗するからです >>129

[136] ところがこの要件が満たされない時受信者がこれを失敗とみなさなければならないという規定はありません。 セキュリティーの根幹に関わる部分がこんな曖昧でいいのでしょうか。

[151] 選択は、応用次第で異なる方法で行われ得るのであって、 仕様書には一定の指針が示されているものの、 すべての情報源を使う必要もなく、 適用し得るすべてのを使う必要もなく、 また順序もその通りである必要はないものとされています。 ともかく、指針として、次のようにします。 >>150

  1. [152] 適用し得るを探します。情報源には次のものが含まれ得ます。
  2. [159] 集めたから適切なものを選択します。
    • [160] 例えば、 kidx5t が合致するもののみを選ぶことができます。
    • [161] 応用alg, use, key_ops を使う場合、これらの値に合わないものを除外します。
    • [162] その他応用規定の方法で適当なもののみ選んで構いませんし、 応用次第でまったく除外しなくても構いません。
  3. [164] 整列します。
    • [165] 例えば、 kidx5t に合致するものを、それ以外より先に試すことにできます。
    • [163] その他特定条件のものを優先しても構いませんし、 応用次第でまったく順序を改めなくても構いません。
  4. [166] について、信頼決定します。
    • [167] 応用の信頼条件に満たない鍵を使った署名は、拒絶します。
    • [168] 信頼条件とは、例えば、 鍵の出所、 URL から取得したにあってはTLS証明書妥当であったか否か、 X.509証明書中のにあっては妥当な証明書鎖に裏付けられたものか否か、 その他応用の有する情報を用い得ます。
  5. [169] について、 JWSRFC 4949 デジタル署名RFC 4949 MAC の検証を試みたり、 JWE解読を試みたりします。
    • [170] 得られたをすべて試みても構いませんし、 上限数を設定しても構いません。
[171] デジタル署名MAC の検証や解読に失敗するなら、 信頼決定するまでもありませんから、 応用次第で信頼決定を後回しにすることもできます。 >>150

取得プロトコル

[63] JWSjku, x5uURL を指定して別ファイルを参照できます。 JWSの取得プロトコルには次のような制約が規定されています。

[64] 資源取得 (acquire) に使うプロトコルは、 一貫性保護を提供するものでなければなりません>>47

[66] 取得 (retrieve) に使う HTTP GET 要求は、 TLS を使わなければなりません >>47jkux5u に対応する実装は、 TLS に対応しなければなりません >>138

[141] RFC 6125 service identity 検証を実施しなければなりません>>47, >>138

[67] ここで仕様書TLS について RFC 2818 (HTTPS) と RFC 5246 (TLS/1.2) を参照していますが、その意図するところは不明です。 (他の理論上はあり得る方法ではなく) HTTPS を使うことを要求するべきでしょうか。 さらに RFC 6125 が参照されていますが、 RFC 6125 自身は HTTPS に適用されるとはしておらず、 適用する場合 HTTPS仕様書の改訂が必要になることを述べています。 service identity 現時点でそのような改訂版はありません。 これは JWS に関して RFC 6125 を適用するべき特別の規定と解すべきなのか、 勇み足なのか、判断しかねます。 (現実の実装状況がどうなっているのかはまた別の問題であります。)

[140] TLS については、 実装するべき版は時代により変化し得るものであって、執筆時点では RFC 5246 TLS/1.2 である >>138 と明記されています。

[139] TLS では機密性 (confidentiality) 保護と一貫性保護を提供する ciphersuite を使わなければなりません。 適切な ciphersuite については RFC 6176 その他現行の IETF TLS working group 出版物を参照するべきです。 RFC 7572 も参照するべきです。 >>138

[68] こうした要件を満たし現実的に運用可能なプロトコルとなると、 HTTPS (URL schemehttps:) をおいて他にはありません。 (理論上は FTP over TLS なども該当し得ますが、 相互運用性に問題があります。)

[65] 一昔前ならこうした要件は保安輸送路といわれていました。

応用

[6] JWS応用

歴史

[1] JSON Web Signature (JWS) ( ( 版)) http://openid.net/specs/draft-jones-json-web-signature-04.html

[2] draft-ietf-jose-json-web-signature-19 - JSON Web Signature (JWS) ( ( 版)) http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-19

[3] IETF 提案標準 RFC 7515 として出版されました。

[4] RFC 7797 - JSON Web Signature (JWS) Unencoded Payload Option ( 版) https://tools.ietf.org/html/rfc7797

[5] RFC 8055 - Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm () https://tools.ietf.org/html/rfc8055