Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)
draft-ietf-jose-use-cases-03

Abstract

多くのインターネット上のアプリケーションは, ネットワークレイヤーやトランスポートレイヤーでのセキュリティメカニズムに加えて, オブジェクトベースのセキュリティメカニズムを必要とする. かつては Cryptographic Message Syntax (CMS) が ASN.1 に基づいたバイナリレベルでのセキュアオブジェクトフォーマットを提供していた. しかしながら時代の変化とともに ASN.1 のようなバイナリオブジェクトエンコーディングは時代遅れとなり, JSON などのテキストベースエンコーディングが主流となった. 本ドキュメントでは, 現在実用化されている様々なアプリケーションレイヤーセキュリティメカニズムをもとに, JSON ベースのセキュアオブジェクトフォーマットの各種ユースケースと要件をまとめる.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on April 18, 2014.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

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.

Table of Contents

1.  Introduction
2.  Definitions
3.  Basic Requirements
4.  Requirements on Application Protocols
5.  Use Cases
    5.1.  Security Tokens
    5.2.  OAuth
    5.3.  Federation
    5.4.  XMPP
    5.5.  ALTO
    5.6.  Emergency Alerting
    5.7.  Web Cryptography
    5.8.  Constrained Devices
        5.8.1.  Example: MAC based on ECDH-derived key
        5.8.2.  Object security for CoAP
6.  Requirements
    6.1.  Functional Requirements
    6.2.  Security Requirements
    6.3.  Desiderata
7.  IANA Considerations
8.  Security Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
    9.3.  翻訳プロジェクト
Appendix A.  Acknowledgements
Appendix B.  Document History
Appendix C.  翻訳者
§  Author's Address

1.  Introduction

インターネット上のアプリケーションは, インターネットを構成する各レイヤーにおけるセキュリティメカニズムを活用できる. 多くのアプリケーションは, IPSec や TLS などの, チャネルベースのセキュリティに大きく依存している. これらのセキュリティメカニズムは, アプリケーションデータが流れる IP レイヤーやトランスポートレイヤーにおいてセキュアチャネルを確立するものである. [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) [RFC5246] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) しかしながらこれらのセキュリティメカニズムは状況によっては end-to-end のセキュリティを保証しない. 例えば, アプリケーションレイヤーに仲介者が存在する場合は, チャネルベースのセキュリティプロトコルでは, 仲介者同士の間を流れるメッセージを改竄しようとするアタッカーからの攻撃は防ぐことができても, 仲介者自身がメッセージを改竄 / 盗聴することは防げない. こういったケースでは, オブジェクトベースのセキュリティメカニズムを用いてアプリケーションデータをセキュアオブジェクトに埋め込み, 信頼できない主体がデータを扱ってもセキュリティを確保できるようにする必要がある.

上記のようなプロトコルとして現在最も広く利用されているのは, Secure/Multipurpose Internet Mail Extensions (S/MIME) である. Email メッセージは, 通常一連の Mail Transfer Agents (MTA) を仲介者として, 受信者に届けられる. これら MTA は通常チャネルベースのセキュリティメカニズムを用いて通信を保護する (例: STARTTLS [RFC3207] (Hoffman, P., “SMTP Service Extension for Secure SMTP over Transport Layer Security,” February 2002.)) が, こういった仕組みは MTA 自身がメッセージを改竄 / 盗聴することを防ぐものではない. 信頼できない MTA が存在する状況でも end-to-end のセキュリティを確保するには, S/MIME を利用してメッセージボディーをセキュアオブジェクトに内包し, 情報の機密性 (confidentiality), 完全性 (integrity), 送信者認証 (data origin authentication) を確保することが有効である.

S/MIME は Cryptographic Message Syntax for secure objects (CMS) [RFC5652] (Housley, R., “Cryptographic Message Syntax (CMS),” September 2009.) をベースにしている. CMS は Abstract Syntax Notation 1 (ASN.1) を用いて定義され, 慣習的に ASN.1 Distinguished Encoding Rules (DER) でエンコードされる. DER では保護されるメッセージと関連パラメーターはバイナリエンコーディングされる. [ITU.X690.2002] (International Telecommunications Union, “Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER),” 2002.) 近年では ASN.1 (やその他の汎用オブジェクトに対するバイナリエンコーディング) が利用されるケースは減少し, Extensible Markup Language (XML) [W3C.REC‑xml] (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.) や JavaScript Object Notation (JSON) [RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) といったテキストベースのフォーマットの利用が増加している.

最近の多くのアプリケーションは ASN.1 オブジェクトよりも遥かにテキストベースフォーマットのオブジェクトの処理に長けており, そもそも ASN.1 オブジェクトを処理できないものも多い. オブジェクトベースのセキュリティの実装を単純化するため, IETF JSON Object Signing and Encryption (JOSE) ワーキンググループでは JSON ベースのセキュアオブジェクトフォーマットを策定している. その名前が示す通り, ここで策定されているのは JSON エンコードされたオブジェクトの機密性 (confidentiality), 完全性 (integrity) を確保するためのフォーマットである. しかしながら, ワーキンググループ内での議論の結果, JOSE で定義されるフォーマットを利用するアプリケーションごとに, そのフォーマットに対する要件が異なることも分かった. よって本ドキュメントでは, JOSE フォーマットを利用する可能性のあるアプリケーションを想定し, セキュリティメカニズムとオブジェクトエンコーディングに対する要件をまとめる.

XML を利用するシステムでは, XML ベースのオブジェクトベースセキュリティメカニズムである XML Digital Signatures および XML Encryption を利用するものもある. [W3C.xmldsig‑core] (Eastlake, D., Reagle , J., and D. Solo, “XML-Signature Syntax and Processing,” October 2000.) [W3C.xmlenc‑core] (Eastlake, D. and J. Reagle , “XML Encryption Syntax and Processing,” August 2002.) これらは SAML [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.) や WS-Federation [WS‑Federation] (Kaler, C., McIntosh, M., Goodner, M., and A. Nadalin, “Web Services Federation Language (WS-Federation) Version 1.2,” May 2009.) などのセキュリティトークンや CAP 緊急アラートフォーマット [CAP] (Botterell, A. and E. Jones, “Common Alerting Protocol v1.1,” October 2005.) での利用を想定して定義されたものである. しかし現実には XML ベースのセキュアオブジェクトフォーマットは ASN.1 と同レベルの複雑性を持ち, ASN.1 を扱えない / 扱いたくないデベロッパーがこういった XML ベースのセキュリティメカニズムを利用することは考えづらい. こういった背景が, JSON ベースのセキュアオブジェクトフォーマット策定に至る動機となっている. JSON ベースであれば, 実装や利用も容易であり, 開発者はわずかな労力とツールのみでそれを取り入れることができるであろう.

2.  Definitions

この文書は[RFC4949] (Shirey, R., “Internet Security Glossary, Version 2,” August 2007.)に記載される標準セキュリティ用語を広範囲に活用するものである. JOSEとCMSのユースケースは似ていることから, いくつかのCMSのコンセプトについて[RFC5652] (Housley, R., “Cryptographic Message Syntax (CMS),” September 2009.)を例に説明する.

JOSEワーキンググループでは３つのJSONオブジェクトフォーマットを定義する.

1. 機密性保護オブジェクトフォーマット
2. 完全性保護オブジェクトフォーマット
3. 鍵表現フォーマット

この文書では, 上記をそれぞれ"署名済みオブジェクトフォーマット", "暗号化オブジェクトフォーマット", "鍵フォーマット"と呼ぶ. これらのフォーマットを表現することを目的としたJOSEワーキンググループの仕様はそれぞれJSON Web Signature (JWS)[I‑D.ietf‑jose‑json‑web‑signature] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Signature (JWS),” October 2013.), JSON Web Encryption (JWE)[I‑D.ietf‑jose‑json‑web‑encryption] (Jones, M., Rescorla, E., and J. Hildebrand, “JSON Web Encryption (JWE),” October 2013.), JSON Web Key (JWK)[I‑D.ietf‑jose‑json‑web‑key] (Jones, M., “JSON Web Key (JWK),” October 2013.)である. JWS, JWE, JWKで使用されるアルゴリズムやアルゴリズム識別子はJSON Web Alogrithms (JWA) [I‑D.ietf‑jose‑json‑web‑algorithms] (Jones, M., “JSON Web Algorithms (JWA),” October 2013.) で定義されている.

通常, 非対称/対称な処理を区別する必要がない場面では, 共通鍵を使ったメッセージ認証コード(MAC) と公開鍵暗号を含むデジタル署名についても同様に"署名", "シグネチャ"などの用語を用いる

セキュアオブジェクトの存続期間には, オブジェクトを生成するエンティティ (例：ペイロードを暗号化もしくは署名する側) とオブジェクトを利用するエンティティ (例：復号化, 検証をする側) の２つの基本的なロールが存在する. これらのロールをそれぞれ"送信者", "受信者"と呼ぶことにする. 要件やユースケースによってはこれらのロールを単一エンティティが担うことを明記するかもしれないが, 同一ロールに複数のエンティティが存在する可能性があることに留意すること. たとえば, メッセージは複数の送信者によって署名されたり, 複数の受信者によって復号化される可能性がある.

3.  Basic Requirements

言うまでもなく, 暗号化および署名済みオブジェクトフォーマットに対し, 機密性のためには対称あるいは非対称暗号化, 完全性保護のためにはMACあるいはデジタル署名といった, 適切な暗号メカニズムを用いることで, 必要な保護が形成される. 両方のケースで, 対称および非対称処理の両方のサポートがJOSEフォーマットには必要である.

• JOSE暗号化オブジェクトフォーマットは, 送信者と受信者が対称鍵を共有しているケースでのオブジェクト暗号化をサポートしなければならない.
• JOSE暗号化オブジェクトフォーマットは, 送信者が受信者の公開鍵のみを所持しているケースでのオブジェクト暗号化をサポートしなければならない.
• JOSE署名済みオブジェクトフォーマットは, 送信者と受信者が対称鍵のみを共有しているケースでのメッセージ認証コード (MAC) を用いた完全性保護をサポートしなければならない.
• JOSE署名済みオブジェクトフォーマットは, 受信者が送信者の公開鍵のみを所持しているケースでのデジタル署名を用いた完全性保護をサポートしなければならない.

いくつかのアプリケーションでは, JOSEオブジェクトの処理に用いる鍵が, JOSEオブジェクトの中で直接提示されるのではなく, アプリケーションのコンテキストを通じて提示される. しかし, 混乱を避けるために, 必要なコンテキストが不足しているエンドポイントは, 不足を認識し, 問題なく失敗処理を行える必要がある. 鍵以外, JOSEオブジェクトは事前ネゴシエーションをサポートしない. 全ての暗号パラメータはJOSEオブジェクトの中に直接記述されなければならない.

• JOSE署名済みおよび暗号化オブジェクトフォーマットは, 対象のオブジェクトの処理に必要な鍵を持っているかどうか, そしてその鍵はそのオブジェクト自身によって提示されているか, あるいはなんらかのout-of-bandメカニズムによって提示されているかどうかについて実装が認識するためのプロセスを定義しなければならない.
• JOSEで利用される各アルゴリズムについて, そのアルゴリズムを使用するJOSEオブジェクトが内包しなければならないパラメータを定義する必要がある.

二つのエンティティが複数のJOSEオブジェクトを交換しようとするケースで, 全てのJOSEオブジェクトで個々にパラメータを記述しなくても済むように, いくつかのパラメータについて事前にネゴシエーションをすることは有用かもしれない. しかし, 事前ネゴシエーションをサポートしないエンドポイントと混同しないように, これらのケースでは事前にネゴシエーションされたパラメータを使用していることを示すことは有益である.

• オブジェクトの処理に事前ネゴシエーションされたパラメータが使用されることを示すことができるように, 基本のJOSE署名済みおよび暗号化オブジェクトフォーマットを拡張できるようにすべきである. この拡張は, どのパラメータが使用されるのかを示す手段も提供すべきである.

鍵フォーマットの目的は, 暗号メッセージ処理用の符号化された鍵を使用するために十分な情報を受信者に提供することである. そのため, 時には純粋な鍵だけではなく追加のパラメータを含める必要がある.

• JOSE鍵フォーマットは符号化された鍵を使用するために必要な全てのアルゴリズムパラメータを含めることが出来なければならない. そのパラメータには, アルゴリズムで必要となる追加のパラメータ (例: 楕円曲線パラメータ) とともに, その鍵が使用されるアルゴリズムの識別子も含まれる.

4.  Requirements on Application Protocols

各 JOSE セキュアオブジェクトフォーマット仕様は, 保護対象コンテンツに対する暗号処理を詳細に定め, JOSE オブジェクトの受信者が, 適切に暗号化されたオブジェクトを復号したり, 署名を検証したりできることを保証する. しかしながら, JOSE を利用する各アプリケーション側でも, 以下のような点については独自に定める必要がある.

• 保護対象となるアプリケーションコンテンツ
• 利用される暗号アルゴリズム
• エンティティ間での鍵確立手法
• 利用される鍵が JOSE オブジェクト内に明示的に示されているのか, アプリケーションのコンテキストにより決まるのか

5.  Use Cases

アプリケーションレイヤーのプロトコルについて策定しているワーキンググループにはJOSEデータフォーマットをエンドツーエンドのセキュリティ機能の設計で利用したいという要望を表明しているところもある. この章では, このようなグループが提案したユースケースをとりまとめ, JOSEオブジェクトフォーマットに求められる要件について説明する.

5.1.  Security Tokens

セキュリティトークンはオブジェクトベースのセキュリティではよくあるユースケースである. 例えばSAMLのアサーション [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.)がある. セキュリティトークンは発行者から受信者へ対象のエンティティ ("クレーム"または"アサーション") に関する情報を渡すために使われる. トークンフォーマットのセキュリティ機能により, 受信者はクレームが発行者により発行され, 完全性が保護されているオブジェクトの場合は他のパーティから読み取れないことを検証することができる.

セキュリティトークンはOAuth2.0[RFC6749] (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.)とそれに含まれるOAuth bearer tokens [RFC6750] (Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.) などのリソース認可のプロトコルだけでなく, SAML 2.0 [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.), WS-Federation [WS‑Federation] (Kaler, C., McIntosh, M., Goodner, M., and A. Nadalin, “Web Services Federation Language (WS-Federation) Version 1.2,” May 2009.), Mozilla Persona [Persona] (Mozilla, “Mozilla Persona,” April 2013.), OpenID Connect [OpenID.Messages] (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) などのフェデレーションプロトコルで利用される. あるケースでは, セキュリティトークンはクライアント認証やアクセス制御 [I‑D.ietf‑oauth‑jwt‑bearer] (Jones, M., Campbell, B., and C. Mortimore, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2013.)[I‑D.ietf‑oauth‑saml2‑bearer] (Campbell, B., Mortimore, C., and M. Jones, “SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants,” July 2013.)に利用される.

JSON Web Token (JWT) [I‑D.ietf‑oauth‑json‑web‑token] (Jones, M., Bradley, J., and N. Sakimura, “JSON Web Token (JWT),” October 2013.) はJSONおよびJOSEをベースとしたセキュリティートークンフォーマットである. JWTはMozilla Persona, OpenID Connect, OAuthと共に利用される. JWTは限定された場面 (例: HTTPクエリパラメータ) で主に利用されていたためJWTの主要な要件となり, それゆえJOSEは短くURLセーフな形式になっている.

5.2.  OAuth

OAuthプロトコルは, HTTP [RFC6749] (Hardt, D., “The OAuth 2.0 Authorization Framework,” October 2012.) を用いた認可トークンの流通と利用のメカニズムを定義している. 保護リソースへアクセスしたいクライアントは, リソースオーナーからの認可を要求する. このアクセスを許可する場合, リソースオーナーは認可サーバーに対し, クライアントへアクセストークンを発行するよう指示する. クライアントは, 保護リソースにアクセスしたいとき, 関係するリソースサーバーにそのトークンを提示する. そしてリソースサーバーは保護リソースへのアクセスを提供する前にそのトークンの妥当性を検証する.

              +---------------+          +---------------+
              |               |          |               |
              |   Resource    |<........>| Authorization |
              |    Server     |          |     Server    |
              |               |          |               |
              +---------------+          +---------------+
                           ^                |
                           |                |
                           |                |
                           |                |
                           |                |
              +------------|--+          +--|------------+
              |            +----------------+            |
              |               |          |   Resource    |
              |     Client    |          |     Owner     |
              |               |          |               |
              +---------------+          +---------------+

実質的にこのプロセスは, クライアントおよびリソースオーナー経由で, 認可サーバー(オブジェクトの送信者)からリソースサーバー(受信者)へトークンを移すことである (リソースオーナーを経由するのはこのプロトコルが利用しているHTTPのメカニズムに起因している). そこで, 信頼できない中間者経由でアプリケーションオブジェクトを転送するケースが出てくる.

このアプリケーションには二つの不可欠なセキュリティ要件がある. 完全性とデータ生成元の認証である. 完全性保護は, リソースオーナーとクライアントがトークン内に符合化されたパーミッションを変更できないようするために必要である. リソースオーナーは究極的には認可を付与するエンティティではあるが, 例えばリソースオーナーが所有していないリソースへのアクセス権の付与も出来てしまうため, 認可トークンの変更に対しては信頼できない.

データ生成元の認証は, トークンが信頼できる認可サーバーによって生成されたものかどうかをリソースサーバーが検証できるようにするために必要である.

認可サーバーがリソースオーナーやクライアントに対してパーミッション情報を不可視としたい場合, 機密性保護も必要となるかもしれない. 例えば, ソーシャルネットワーキングに関連したパーミッションはプライベートな情報と見なされるかもしれない. しかし, OAuthは下位層で用いているHTTPトランザクションがTLSによって保護されていることを元々要求していることには注意すること. よってトークンはリソースサーバーとクライアント以外のエンティティに対する機密性保護に関しては既に達成されている.

署名と暗号化が対称暗号または非対称暗号のいずれを用いて提供されるのかに関わらず, 機密性および完全性のニーズは, 署名済みおよび暗号化オブジェクトフォーマットの基本要件に合致している. どちらのメカニズムを採用するかの選択は, 二つのサーバ間の関係, すなわちそれらが対称鍵を共有するのか, 公開鍵のみを共有するのかに依存するだろう.

認証の要件はデプロイの特性にも依存するだろう. リソースサーバーと認可サーバーの結びつけが相対的に強いところでは, トークンを発行した認可サーバを識別するにはトークンの署名に用いた鍵だけで十分かもしれない. これは, 認可サーバーの公開鍵, あるいは公開鍵か対称鍵の識別子をプロトコルが伝送することを必要とする. OAuthでは client_id パラメータが, 使用される鍵を識別する.

リソースサーバーは事前に認可サーバーの鍵を知らないといったような, より高度なケースも存在するかもしれない. 例えば一つのエンティティが(負荷分散のために)複数の認可サーバーをインスタンス化する場合, それらが個々に独立した鍵ペアを持っている例が挙げられる. このようなケースの場合, 対象の認可サーバーが信頼するエンティティかどうかをリソースサーバーが検証できるように, 認可サーバーの証明書または証明書チェーンを含める必要もあるかもしれない.

OAuthにとってHTTPトランスポートはエンコーディングに関して特定の制約を課している. OAuthプロトコルでは, base64urlエンコーディング [RFC4648] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) が実施された上で, トークンはHTTP URI [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) 内のクエリーパラメータとして頻繁にやり取りされる. URI (従ってクエリパラメータも) の長さには制限が規定されていないが, 実際にはいくつかのユーザーエージェントでは2048文字超のURIは拒否される. いくつかのモバイルブラウザでは, この制限はさらに小さな値となっている. そのためこのユースケースでは, JOSEオブジェクトに対して, URIクエリパラメータに含むことが可能なようシンプルであることと同時に, 署名後 (場合によっては暗号化も) でも十分に小さなサイズであることを要求する.

5.3.  Federation

セキュリティトークンは2つのアイデンティティフェデレーションプロトコルで用いられている. これら2つの要件は, 前節で述べたものと似ている.

• OpenID Connect [OpenID.Messages] (Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” May 2013.) は, OAuth 2.0 をベースとした REST/JSON ベースのシンプルなアイデンティティフェデレーションプロトコルである. OpenID Connect では, JWT および JOSE フォーマットがセキュリティトークンおよびその他のプロトコルメッセージの保護 (署名およびオプショナルで暗号化) の為に利用されている. OpenID Connect は, 暗号アルゴリズムのネゴシエーションや鍵情報の配送の為に, JWT/JOSE ヘッダーパラメーターとしては定義されていない要素を利用している.
• Mozilla Persona [Persona] (Mozilla, “Mozilla Persona,” April 2013.) は, アイデンティティ情報やアプリケーション情報, 関与する各エンティティの鍵情報などの表現形式として, JOSE JWS オブジェクトとして署名された JWT を利用した, シンプルなシングルサインオン (SSO) プロトコルである. Persona は鍵配送のために JOSE ヘッダーパラメータではなく JWT メッセージ中の属性を利用する.

5.4.  XMPP

Extensible Messaging and Presence Protocol (XMPP) は末端のクライアントから他の端末へXMPP serversの仕様に従ってメッセージを送信するプロトコルである. [RFC6120] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” March 2011.) 一般的には任意の送信メッセージに2つのサーバが関与する. あるクライアント(Alice) は他のクライアント (Bob) 宛のメッセージをサーバ(A)へ送信する. サーバAはBobのIDとDNSによってBobのドメイン(B)を持つサーバを特定し, メッセージをそのサーバへ送信する. その後サーバBはBobへメッセージを送信する.

         +-------+   +----------+   +----------+   +-----+
         | Alice |-->| Server A |-->| Server B |-->| Bob |
         +-------+   +----------+   +----------+   +-----+

信頼できない中間者の問題については特にXMPPにとって深刻である. なぜならば, 現時点で多くの適用例では, XMPPドメインの所有者がドメインのサーバの処理を他のエンティティに委託しているためである. この環境では, ドメイン所有者の個人情報がドメインのオペレーターに露出してしまう明白なリスクが存在する. XMPPはS/MIMEを利用して端末間セキュリティのメカニズム[RFC3923] (Saint-Andre, P., “End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP),” October 2004.)を既に定義しているが, キー管理の問題やS/MIMEオブジェクトの処理が難しいこともあり, 普及させることはできなかった.

XMPPワーキンググループはJOSEベースのエンコーディングとより明快なキー管理のシステムを利用した新しい端末間暗号化システムの策定に取り組んでいる. [I‑D.miller‑xmpp‑e2e] (Miller, M., “End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP),” June 2013.) このシステム上で暗号化メッセージを送信するプロセスは２つのステップからなる. 1つ目は, 送信者は対象な Content Encryption Key (CEK)を生成してメッセージコンテンツを暗号化して, 暗号メッセージを届けたい先の受信者へ送信する. 2つ目は, 各受信者は自身の公開鍵を提示することで受信者へ「コールバック」を行い, 送信者は受信者の公開鍵で変換された関連のあるCEKを受け取る. message to the desired set of recipients. Second, each recipient "dials back" to the sender, providing his public key; the sender then responds with the relevant CEK, wrapped with the recipient's public key.

         +-------+   +----------+   +----------+   +-----+
         | Alice |<->| Server A |<->| Server B |<->| Bob |
         +-------+   +----------+   +----------+   +-----+
             |             |              |           |
             |------------Encrypted--message--------->|
             |             |              |           |
             |<---------------Public-key--------------|
             |             |              |           |
             |---------------Wrapped CEK------------->|
             |             |              |           |

このシステムがJOSEフォーマットから要求する主要な事項は, コンテンツ部の暗号化による機密性保護に加え, 共有鍵より導出したMACによる完全性の検証機能である. しかしながら, 暗号コンテンツの送受信での鍵交換を区別するためには, JOSE暗号化オブジェクトフォーマットに暗号ペイロードとは区別して共通鍵を含むメッセージを伝達できるような仕組みが要求される. さらに, 暗号オブジェクトにはコンテンツの暗号化に利用した鍵のタグが必要になる. そうすることで受信者(Bob)は送信者(Alice)へ鍵を含んだメッセージを送信する際にタグを提示することができる.

XMPPの重要な他の特徴は, 複数の受信者へのメッセージの同時配信を許可していることである. 上記のダイアグラムで言うと, サーバAはサーバB (Bobのサーバ) だけでなくほかのユーザの所有するサーバC, D, Eなどへもメッセージを配信できる. そのようなケースでは, 上記の仕組みに示される複数の「コールバック」のトランザクションを回避するため, XMPPシステムは受信者の公開鍵をキャッシュすることがあり, それにより鍵はこの後のメッセージの内容と共に送信することができる. このことによりJOSE暗号オブジェクトフォーマットは複数バージョンものCEKの発行をサポートしなくてはならない. (CMS EnvelopedData structureでは複数の受信者情報の構造を含むことができるが)

XMPPの端末間セキュリティシステムの最新のドラフトでは, 各パーティはXMPPメッセージ伝達システム内にある他パーティの信用情報にもとづいて認証される. 送信者は, "Alice"という識別子宛のメッセージ (具体的には, 鍵交換のためのリクエスト) を受け取ることができ, またその識別子宛のメッセージ (ラップされた鍵情報) を送信できるため, 受信者に認証される. 同様に, 受信者はオリジナルの暗号メッセージと元の鍵交換のリクエストを送ることができるため, 送信者に認証される. そのため, ここでの認証で要求されるのはXMPPのルーティングが正しく行われることだけでなく, TLSが全てのホップにおいて使われることである. それに加えて, ３ホップ中いずれかにおいて中間者によってBobになりすまして暗号メッセージの鍵情報を取得できてしまうため, 強い認証強度のTLSチャネルが要求される.

この認証は比較的脆弱 (TLSを用いた３つのホップに依存しているため) でエンドポイントでは検証できない. そのためXMPPワーキンググループは最終受信者のためになんらかのクレデンシャルを導入することも考えられる. そのようなケースでは, そういったクレデンシャルをJOSEオブジェクトと関連づける方法も必要となるであろう.

最終的に, XMPPがJSONではなくXMLベースであることに意味はない. そのため, JOSEを利用するときは, XMPPはXML内にJSONオブジェクトを含めて送信される. したがって, JOSEオブジェクトはXMLに含まれても問題ないような方法でエンコードされることが望ましい. そうでなければ, XMLとしてパースされないように明示するため, 明示的なCDATAの指定をパーサーに対して行わければならない. この要件を満たすひとつの方法としては, base64urlエンコードをかけることがあげられるが, 中〜大サイズのXMPPメッセージにとっては, これによりかなりのオーバーヘッドを強いる可能性がある.

5.5.  ALTO

Application-Layer Traffic Optimization (ALTO) は, エンド端末に対する分散ネットワークトポロジー情報のためのシステムであり, これによりエンド端末はネットワークへのインパクトを抑えつつ自らの動作を修正することが可能となる [RFC6708] (Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, “Application-Layer Traffic Optimization (ALTO) Requirements,” September 2012.) . ALTOプロトコルは, HTTP [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) で搬送するJSONオブジェクトの形態でトポロジー情報を分配する [I‑D.ietf‑alto‑protocol] (Alimi, R., Penno, R., and Y. Yang, “ALTO Protocol,” October 2013.) . 元々の版のALTOはシンプルなクライアントサーバプロトコルであり, このケースではHTTPSを単純に使用するだけで十分である [RFC2818] (Rescorla, E., “HTTP Over TLS,” May 2000.) . しかし, クライアントに到達する前に複数の中間サーバを経由してこれらのJSONオブジェクトが分配されるというALTOのユースケースの議論が始まり, 一方でクライアントがオブジェクトのオリジナルの送信元を認証する機能は依然として維持する必要があった. 元々のALTOプロトコルでも「ALTO情報を取得するALTOクライアントは, その受け取ったALTO情報が適切なALTOサーバーによって生成されたものかどうかの検証ができなければならない」という言及があった.

このケースでのセキュリティ要件は明確である. ALTOペイロードを搬送するJOSEオブジェクトは, オリジナルの送信元サーバーのデジタル署名が付随している必要があり, そしてそのサーバーのアイデンティティを証明できなければならないだろう. ALTO情報は一般に公開されるものであるため, このケースでは機密性に関する要件はない.

より興味深い議題はエンコーディングに関することである. ALTOオブジェクトは前述の2つのケースよりもペイロードが大きくなる可能性があり, そのサイズは数メガバイトにまでなると考えられる. このような大きなオブジェクトの処理は, シングルパスで実施できた方がより高速に処理できる. そしてそれは, JSON構造内でフィールドが特定の順番であることをJOSEオブジェクトが要求することで可能となるだろう.

加えて, ALTOオブジェクトはJSONとしてエンコードされているため, JOSEオブジェクト内に安全に包含することが可能である. 署名済みのJOSEオブジェクトは, 署名とともに署名されたデータを搬送するだろう. JSONオブジェクトは, JSON文字列内に安全にエンコードされて格納されることが可能という性質を持っている. これに関する要件は, 不必要な空白は取り除くことだけであり, 例えばbase64urlエンコーディングよりもかなりシンプルな変換である. このことは, 特定の「JSON-safe」なケースでのJOSEエンコーディングを最適化できるかどうかという議題に繋がる.

最終的に, 「分離署名 (detached signature)」メカニズム, つまり署名情報を保護対象のコンテンツから分離してエンコードする方法が, ALTOにとっては望ましいかもしれない. これはALTOプロトコルで, 署名をHTTPSのヘッダ, 署名されたコンテンツをHTTPSのエンティティボディに含めることを可能とするだろう.

5.6.  Emergency Alerting

緊急警報 (Emergency alerting) は IP ネットワークの緊急利用を行うものである [I‑D.ietf‑atoca‑requirements] (Schulzrinne, H., Norreys, S., Rosen, B., and H. Tschofenig, “Requirements, Terminology and Framework for Exigent Communications,” March 2012.). 差し迫った危険が察知されると, アラートシステムはユーザーのデバイスにアラートメッセージを送り, 危険を通知する. ハリケーンやトルネードなどが発生した場合には, その通り道にあたる場所のすべてのデバイスに対してアラートが送られることもある.

アラートシステムへの最大の要件は, アタッカーが誤報を送信することができないようにすることである. アタッカーによる誤報送信が行われると, アタッカーが広範囲にパニックを起こすことが可能になるであろう. 通常アラートシステムはこういったアタックを防ぐため, メッセージ送信元を厳格に管理し, なおかつメッセージ受信側ではメッセージ送信元の検証を行う. 前者はアラート送信元のローカルセキュリティとして実施され, 後者はアラートメッセージへのデジタル署名 (チャネルベースまたはオブジェクトベース) を用いて実現される. オブジェクトベースのデジタル署名を採用した場合は, 署名はセキュアオブジェクト内にエンコードされる. チャネルベースのデジタル署名を採用した場合は, アラートメッセージを認証済かつ完全性が保護されたチャネルを経由して送ることで, "署名済" であるとして扱う.

アラートは一般的に一連の中間者を経由してエンドユーザーに届けられる. 例えば, ある国家が運営する天気予報サービスがハリケーンのアラートを送信する場合には, まずアラートメッセージを国家のゲートウェイに送り, ネットワークオペレーターがそれをエンドユーザーにブロードキャストするであろう.

        +------------+    +------------+    +------------+
        | Originator |    | Originator |    | Originator |
        +------------+    +------------+    +------------+
              |                 .                 .
              +-----------------+..................
                                |
                                V
                           +---------+
                           | Gateway |
                           +---------+
                                |
                   +------------+------------+
                   |                         |
                   V                         V
              +---------+               +---------+
              | Network |               | Network |
              +---------+               +---------+
                   |                         |
            +------+-----+            +------+-----+
            |            |            |            |
            V            V            V            V
        +--------+   +--------+   +--------+   +--------+
        | Device |   | Device |   | Device |   | Device |
        +--------+   +--------+   +--------+   +--------+

アラートメッセージへの署名を検証するためには, 受信者が信頼できるアラート送信者の正規の公開鍵を所有している必要がある. ここで成り立っている信頼関係は, アラートの送信経路にそった区分的なものかもしれない. 例えば, 各ネットワークで運営されるアラート中継機それぞれがすべてのアラート送信元の証明書を所有していても, 末端のデバイスではローカルネットワーク内の中継機のみを信頼しているかもしれない. もしくは末端デバイスがメッセージ送信者およびローカルネットワーク中継機双方に署名されたメッセージを要求するかもしれない.

このケースでは, 1つのアラートメッセージに対して複数の署名を付与する必要がでてくる. そうすることで, アラートメッセージはその送信経路の任意 / 全てのエンティティによる署名を含むことができるようになる. なるべく複雑なことを避けるためには, ここでの署名はモジュール化され, ある署名を付ける際にそれ以前の署名を変更したり再計算する必要のないようにすべきである.

5.7.  Web Cryptography

W3C Web Cryptography APIではWeb用の標準暗号API [WebCrypto] (Sleevi, R. and D. Dahl, “Web Cryptography API,” January 2013.)を定義している. もしブラウザがこのAPIを使えるようにした場合, ウェブページの一部として実行されたJavaScriptがブラウザにダイジェスト, MAC, 暗号化, デジタル署名などの処理を実行させることが可能となる.

ブラウザが暗号処理を実行することの主要な理由の一つに, JavaScriptコードによって暗号処理に利用されるの鍵情報にアクセスできないようにすることが挙げられる. 例えば, この分離によって, クロスサイトスクリプティング(XSS)によって注入されたコードがブラウザ内に保持された鍵を読み取ったり抜き取ったりすることを防げるだろう. 悪意のあるコードがブラウザ上で実行し続けている間は鍵を依然として利用可能である一方, この脆弱性はユーザのブラウザ上で脆弱なページがアクティブな間のみ有効である.

しかしながら, WebCryptGraphy API は鍵のエクスポート機能も提供する. それによりJavascriptでAPIをラップされた形式で鍵を抜き出すことができる. 例えば, JavaScriptは別のデバイスが保持する対になる秘密鍵の代わりに公開鍵を提供したかもしれない. それにより, APIが提供する鍵は新しいデバイスへ安全に鍵を転送するのに使うことができる. こうして悪意のあるコードが鍵をエクスポートできるようにする可能性があるが, ユーザへの通知や同意の検証を考慮にいれても, 明示的なエクスポート処理を必要とすることが制御のポイントとなっている.

Web CryptGraphy API はブラウザが自身の扱う鍵の利用を制限することを強いることも許可している. 例えば, 対象鍵は暗号化のみでMACには利用できないこと注目されがちである. 鍵がラップされた形式でエクスポートされる際, これらの属性は鍵と一緒にもっていかれるべきである.

Web CryptGraphy API はこのようにして, いくつかの鍵の形式を表現するフォーマットが必要とされる. 言うまでもなく, 非対称な鍵のペアから公開鍵は自由にインポートでき, ブラウザよりエクスポート可能であるため, 公開鍵を表現するためのフォーマットが必要である. 秘密鍵や対象鍵を表現できるようなフォーマットもまた必要とされている. 公開鍵以外の形式のため, まず第一に必要なものは鍵を暗号的に機密性および完全性が保証されているような、ラップされた形式である. ダイレクトでラップされていないフォーマットを定義することもまた, セキュリティ的に閉じた環境での利用に有用であるかもしれない.

5.8.  Constrained Devices

このセクションでは [I‑D.ietf‑lwig‑terminology] (Bormann, C., Ersue, M., and A. Keranen, “Terminology for Constrained Node Networks,” July 2013.) に定義されている制約のあるデバイスでのユースケースを示す. このタイプのデバイスでの典型的な問題には, 限られたメモリ, 限られた電源, 低い処理能力, そして通信プロトコルでの厳しいサイズ制限が挙げられる.

5.8.1.  Example: MAC based on ECDH-derived key

小さく低電力なデバイスのメーカーがJOSEワーキンググループの成果を暗号化や認証のフレームワークとして採用することを決定したとしよう. このデバイスメーカーではゲートと電力の双方に関して共に予算の限りがある. このため, これらの必要量を最小化するために多数のショートカットと設計決定がなされてきた.

設計チームは, メッセージ認証コード (MAC) を使用することで必要な認証の提供には十分だろうと決定した. しかし彼らはMACは使用するが, 単一の共有秘密鍵を長期間使用することは望まない. 代わりに, 彼らは以下に提案する検証可能な共有秘密鍵を計算により求める方式を採用する.

• Elliptic-Curve Diffie-Hellman (ECDH) 鍵は, デバイスの製造時に (もしくは導入時の設定処理の一環として) 生成される.
• コントローラー用のECDH公開鍵は, 設定時にセットされる.
• 設定システムは, ECDHの計算を行い, 結果の共有秘密鍵をデバイスに設定する. このプロセスは, 必要な指数計算をデバイス上で実施する必要をなくす. この計算された共有秘密鍵の保護に関するセキュリティ要件は, ECDH秘密鍵の保護に関する要件と同等である.
• カウンターと増分値はデバイス上に設定される.
• デバイスがメッセージを送信する際, カウンターはインクリメントされ, 新たなMAC鍵がECDH秘密鍵とカウンター値から計算される. 必要なMAC鍵を導出するために, AES-CBCをベースとした独自の鍵導出関数 (KDF) を用いる. そしてMAC鍵は, メッセージのMAC値を計算するのに用いられる.

システムがメッセージの機密性を提供する必要があるとき, 同様の方法でKDFは, AEADアルゴリズム鍵を計算するためにも利用できる. より大きなデバイスのコントローラーでは, 指数計算のステップを実施したり, 送信元ナンス値を生成するために乱数生成器を使用するだろう.

5.8.2.  Object security for CoAP

このユースケースでは, C0/C1 クラス ([I‑D.ietf‑lwig‑terminology] (Bormann, C., Ersue, M., and A. Keranen, “Terminology for Constrained Node Networks,” July 2013.) 参照) の制約下にあるデバイスを扱う. これらのデバイスは, CoAP プロトコルで RESTful リクエスト/レスポンスをやりとりする [I‑D.ietf‑core‑coap] (Shelby, Z., Hartke, K., and C. Bormann, “Constrained Application Protocol (CoAP),” June 2013.). 問題を単純化するため, 全てのコミュニケーションはユニキャストであるものとする. つまり, ここで述べるセキュリティ対策はマルチキャストやブロードキャストをカバーするものではない.

ここで対象としているような環境では, セッションベースのセキュリティ (four-pass authentication プロトコル等) は高コストすぎる可能性がある. データの受信や送信 (特に送信) には多くの電力が必要であり, 特にワイヤレスデバイスではこれが問題となる. 従ってただ平文の CoAP リクエスト/レスポンスペイロードのみを JWE オブジェクトに置き換えるてセキュアにするということは, 重要な代替案である. そこには保護レベルとパフォーマンスのトレードオフが存在する. (CoAP ヘッダーは保護対象にならない)

単純な例では, センサータイプのデバイスから返される CoAP GET レスポンスが挙げられる. センサーの取得データは, プライバシーセンシティブであったりビジネスセンシティブであることもあり, 完全性保護と暗号化のどちらもが必要となりうる.

しかしながら, 一部には取得データが非常に短い (数バイト) ものもあり, このようなケースでは, デフォルトの暗号化および完全性保護アルゴリズム (128 bit AES with HMAC_SHA256 等) を利用すると, たとえ JWE ヘッダーを無視したとしても劇的にペイロードサイズを大きくしてしまう可能性がある.

またある種のセンサーの取得情報は突然価値が下がることもある. 例としては交通情報や環境データなどが挙げられる. こういうケースでは, 状況に応じてセキュリティオーバーヘッドを低減可能になっている必要がある.

以上のことから JWE/JWS プロファイルとして以下のような要件が挙げられる.

• セキュアオブジェクトのサイズは可能な限り小さく保たれるべきである. データ受信には, 公開鍵暗号処理よりもはるかに多くの電力コストがかかる. これは特にワイヤレス環境で顕著である.
• 完全性保護: デジタル署名フィールドを持つなど完全性保護をサポートし, 公開鍵署名/共通鍵メッセージ認証コードをともにサポートすべきである.
• 暗号化: 完全性保護の追加オプションとして暗号化をサポートすべきである. また特定のフィールドを暗号化対象から外して完全性検証および復号化を行える様にすべきである.
• 暗号スイート: 制約付きデバイスのユースケースをサポートするため, 多様な暗号スイートをサポートすべきである. 例えば
  • 複数のブロックサイズでのブロック暗号化 (標準の128bitに加えて96bitなど)
  • ブロックサイズ調整のためのパディングでメッセージサイズを増大させることのない AES-GCM などのブロック暗号モード
  • 暗号化と MAC 計算を同時にサポートする暗号スイート (ブロック暗号の AEAD モード等)

6.  Requirements

この章では前章のユースケースの要件を要約を行い, またユースケースから直接的には得られないもう一歩進んだ要件を並べる. JOSEのシステムが採用するのに依然として望ましい特長ではあるが, 厳しい要件ではない制約もまたある.

6.1.  Functional Requirements

F1

下記のセキュリティ特性を備えたセキュアオブジェクトのためのフォーマットを定義すること

• デジタル署名 (非対象鍵のペアによる完全性保護/認証)
• メッセージ認証 (対象鍵による完全性保護/認証)
• 認証付き暗号化

つまり, このワーキンググループによって定義されたセキュアオブジェクトはCMS SignedData, CMS AuthenticatedData, CMS EnvelopedData, CMS AuthEnvelopedDataオブジェクトと同等のセキュリティ特性を提供するべきだ[RFC5652] (Housley, R., “Cryptographic Message Syntax (CMS),” September 2009.) [RFC5083] (Housley, R., “Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type,” November 2007.).

F2

非対称暗号アルゴリズムのための公開鍵と秘密鍵と関連付けられた属性を付帯し, ラップされた形式の秘密鍵を含むフォーマットを定義すること.

F3

ラップされた鍵とされていない鍵の両者を扱えるような関連属性を持つ対象鍵のためのフォーマットを定義すること.

F4

上記オブジェクト個別のJSONシリアライズ機能を定義すること. JSON ABNF syntax [RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.) によると, この変換でのオブジェクトは正しくなければならない.

F5

暗号化署名済みオブジェクトフォーマットのためのコンパクトでURLセーフなテキストシリアライズ機能を定義すること.

F6

ラップされた鍵と関連付けられた属性を暗号的にオブジェクトにひもづけられるようにすること.

F7

ラップされた鍵が対象鍵を利用するセキュアオブジェクトから区別されるようにすること. そのようなケースでは, ラップされた鍵 (例：暗号文, MAC値) 以外のセキュアオブジェクトの暗号コンポーネントは鍵形式とは非依存でなくてはならない. 例えば, 暗号化オブジェクトが複数の受信者宛に準備された場合, 暗号文ではなくラップされた鍵のみが変わる.

F8

この文書記載の要件に合わせようとして, 特に大量のアプリケーションの内容が保護されるような場合に, 余計なオーバーヘッドを強いないようにすること.

6.2.  Security Requirements

S1

暗号化やMACの計算に同じ対称鍵を繰り返し使用することを避けるためのメカニズムを提供すること. その代わりに, 長期間有効な鍵は鍵ラップのためだけに用いるべきであり, 直接暗号化やMACに用いるべきではない. CMS [RFC5652] (Housley, R., “Cryptographic Message Syntax (CMS),” September 2009.) で提供されているいずれかの鍵管理手法を用いるべきである.

• 鍵配送 (公開鍵のラップ)
• 鍵暗号化 (対称鍵のラップ)
• 鍵合意 (DH公開鍵のラップ)
• パスワードベース暗号化 (パスワードから導出された鍵によるラップ)

S2

長期間有効な対称鍵を暗号操作に直接用いる場合 (すなわち要件S1に合致しない場合), 鍵の生存期間を制限する必要がある等の, 鍵管理の実践に関するデプロイガイダンスを提供すること.

S3

主要な検証プロセスに準拠した方法で暗号アルゴリズムを使用すること. 例えばFIPS標準がアルゴリズムAは目的Yではなく目的Xに対して用いることとしている場合, JOSEは目的Yに対するアルゴリズムAの使用を推奨すべきではない.

S4

事前ネゴシエーションを伴うケース, 伴わないケースの双方をサポートすること. 鍵のプロビジョニングを超えるいかなる設定も, セキュアオブジェクトの生成や処理に必要とされるべきではない. 鍵がアプリケーションのコンテキストから導出可能な場合, 受信者自身が適切な鍵を所持しているかどうかを認識可能でなければならない.

6.3.  Desiderata

D1

W3C WebCrypto 仕様との互換性を最大化する. WebCrypto ワーキンググループと協調し, サポートするアルゴリズムの選択やアルゴリズム識別子の決定を行うことなどが考えられる.

D2

可能な限り JSON 正規化を避ける. その他の条件が同じであれば, オブジェクトを正規化するよりも, Base64 URL エンコーディングなどでオブジェクトをシリアライゼーションする方が好まれる.

D3

可能な限り JOSE 暗号処理の入出力をアプリケーションによってコントロール可能にする. JOSE 特有の手順は可能な限り減らすべきである. こうすることにより JOSE のフレキシビリティは向上し, 多くの暗号プロトコルが持つ多様なニーズに応えられるようになる. 例えば, 再暗号化や再署名の処理無しに JOSE オブジェクトを CMS などのレガシーフォーマットに変換する, といったニーズも発生するかもしれない.

7.  IANA Considerations

This document makes no request of IANA.

8.  Security Considerations

本ドキュメントの主目的は JSON ベースのセキュアオブジェクトフォーマットが満たすべき要件をまとめることである. このフォーマットに関する Security Consideratios は, 一般的なオブジェクトベースのセキュリティテクノロジーに関するレベルでは CMS [RFC5652] (Housley, R., “Cryptographic Message Syntax (CMS),” September 2009.) のそれに準じる. JOSE フォーマットと CMS の最大の違いは, JOSE が JSON ベースであることである. JSON は正規化された表現形式が存在しないため, 2つの JSON オブジェクトが同じ情報を表現しているのかどうかを判断することは難しく, それが JOSE を利用する上で脆弱性につながることもあるかもしれない.

9.  References

9.1. Normative References

9.2. Informative References

9.3. 翻訳プロジェクト

Appendix A.  Acknowledgements

Thanks to Matt Miller for discussions related to XMPP end-to-end security model, and to Mike Jones for considerations related to security tokens and XML security. Thanks to Mark Watson for raising the need for representing symmetric keys and binding attributes to them. Thanks to Ludwig Seitz for contributing the constrained device use case.

Appendix B.  Document History

[[ to be removed by the RFC editor before publication as an RFC ]]

-03

• Replaced the "small device" case with the "constrained device" case
• Added S2 to cover cases where the WG decides not to implement S1
• Addressed multiple other WGLC comments

-02

• Referenced the JWS, JWE, JWK, and JWA specifications making the "signed object format", "encrypted object format", "key format", and algorithms resulting from these use cases concrete.
• Added "Requirements on Application Protocols" section.
• Broke former huge "Security Tokens and Authorization" Use Case section into "Security Tokens", "OAuth", and "Federation" Use Case sections.
• Cited Mozilla Persona as a single-sign-on (SSO) system using JWTs and JOSE data formats.
• Spelling and grammar corrections.

-01

• Added the "Small Devices" use case

-00

• Created the initial IETF draft based upon draft-barnes-jose-use-cases-01 with some additions.

Appendix C.  翻訳者

本仕様の翻訳は, OpenIDファウンデーションジャパン (OpenIDファウンデーションジャパン, “OpenIDファウンデーションジャパン,” .) [oidfj] 翻訳・教育ワーキンググループ (OpenIDファウンデーションジャパン, “翻訳・教育ワーキンググループ,” .) [oidfj‑trans]を主体として, 有志のメンバーによって行われました. 質問や修正依頼などについては, Githubレポジトリー (OpenIDファウンデーションジャパン, “Githubレポジトリー,” .) [oidfj‑github] にご連絡ください.

• Nov Matake (GREE, Inc.)
• Satoshi Yagi
• Yusuke Kondo

Author's Address