[要約] RFC 7165は、JSON Object Signing and Encryption (JOSE) 技術の使用事例と要件を定義しています。この文書の目的は、WebアプリケーションやインターネットプロトコルでJSON形式のデータを安全に署名、暗号化するための標準化された方法を提供することです。利用場面には、認証情報の交換、メッセージの完全性と機密性の保護、デジタル署名などがあります。関連するRFCには、RFC 7515 (JSON Web Signature), RFC 7516 (JSON Web Encryption), RFC 7517 (JSON Web Key), および RFC 7518 (JSON Web Algorithms) が含まれます。これらは、JOSEフレームワークを構成する技術的な基盤と詳細を提供します。
Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 7165 Mozilla
Category: Informational April 2014
ISSN: 2070-1721
Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)
JSONオブジェクトの署名と暗号化（JOSE）の使用例と要件
Abstract
概要
Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. For many years, the Cryptographic Message Syntax (CMS) has provided a binary secure object format based on ASN.1. Over time, binary object encodings such as ASN.1 have become less common than text-based encodings, such as the JavaScript Object Notation (JSON). This document defines a set of use cases and requirements for a secure object format encoded using JSON, drawn from a variety of application security mechanisms currently in development.
多くのインターネットアプリケーションでは、ネットワーク層またはトランスポート層でのセキュリティメカニズムに加えて、オブジェクトベースのセキュリティメカニズムが必要です。長年にわたり、暗号メッセージ構文（CMS）は、ASN.1に基づくバイナリのセキュアオブジェクトフォーマットを提供してきました。時間の経過とともに、ASN.1などのバイナリオブジェクトエンコーディングは、JavaScript Object Notation（JSON）などのテキストベースのエンコーディングほど一般的ではなくなりました。このドキュメントでは、現在開発中のさまざまなアプリケーションセキュリティメカニズムから抽出された、JSONを使用してエンコードされた安全なオブジェクト形式の一連の使用例と要件を定義します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7165.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7165で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements on Application Protocols . . . . . . . . . . . . 6
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Security Tokens . . . . . . . . . . . . . . . . . . . . . 7
5.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. OpenID Connect . . . . . . . . . . . . . . . . . . . . . 9
5.4. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.6. Emergency Alerting . . . . . . . . . . . . . . . . . . . 13
5.7. Web Cryptography . . . . . . . . . . . . . . . . . . . . 15
5.8. Constrained Devices . . . . . . . . . . . . . . . . . . . 16
5.8.1. Example: MAC Based on ECDH-Derived Key . . . . . . . 16
5.8.2. Object Security for CoAP . . . . . . . . . . . . . . 17
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Functional Requirements . . . . . . . . . . . . . . . . . 18
6.2. Security Requirements . . . . . . . . . . . . . . . . . . 19
6.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Internet applications rest on the layered architecture of the Internet and take advantage of security mechanisms at all layers. Many applications rely primarily on channel-based security technologies such as IPsec and Transport Layer Security (TLS), which create a secure channel at the IP layer or transport layer over which application data can flow [RFC4301] [RFC5246]. These mechanisms, however, cannot provide end-to-end security in some cases. For example, in protocols with application-layer intermediaries, channel-based security protocols would protect messages from attackers between intermediaries, but not from the intermediaries themselves. These cases require object-based security technologies, which embed application data within a secure object that can be safely handled by untrusted entities.
インターネットアプリケーションは、インターネットの階層化アーキテクチャに基づいており、すべての層でセキュリティメカニズムを利用します。多くのアプリケーションは、主にIPsecやトランスポート層セキュリティ（TLS）などのチャネルベースのセキュリティ技術に依存しており、アプリケーションデータが流れるIP層またはトランスポート層に安全なチャネルを作成します[RFC4301] [RFC5246]。ただし、これらのメカニズムでは、エンドツーエンドのセキュリティを提供できない場合があります。たとえば、アプリケーション層の仲介者を使用するプロトコルでは、チャネルベースのセキュリティプロトコルは仲介者間の攻撃者からメッセージを保護しますが、仲介者自体からは保護しません。これらのケースには、信頼できないエンティティによって安全に処理できる安全なオブジェクト内にアプリケーションデータを埋め込むオブジェクトベースのセキュリティテクノロジーが必要です。
The most well-known example of such a protocol today is the use of Secure/Multipurpose Internet Mail Extensions (S/MIME) protections within the email system [RFC5751] [RFC5322]. An email message typically passes through a series of intermediate Mail Transfer Agents (MTAs) en route to its destination. While these MTAs often apply channel-based security protections to their interactions (e.g., STARTTLS [RFC3207]), these protections do not prevent the MTAs from interfering with the message. In order to provide end-to-end security protections in the presence of untrusted MTAs, mail users can use S/MIME to embed message bodies in a secure object format that can provide confidentiality, integrity, and data origin authentication.
今日、そのようなプロトコルの最もよく知られている例は、電子メールシステム[RFC5751] [RFC5322]内でのSecure / Multipurpose Internet Mail Extensions（S / MIME）保護の使用です。電子メールメッセージは通常、一連の中間のMail Transfer Agent（MTA）を経由して宛先に送られます。これらのMTAは、インタラクションにチャネルベースのセキュリティ保護（STARTTLS [RFC3207]など）を適用することがよくありますが、これらの保護によってMTAがメッセージに干渉するのを防ぐことはできません。信頼できないMTAが存在する場合にエンドツーエンドのセキュリティ保護を提供するために、メールユーザーはS / MIMEを使用して、機密性、整合性、およびデータ発信元認証を提供できる安全なオブジェクト形式でメッセージ本文を埋め込むことができます。
S/MIME is based on the Cryptographic Message Syntax (CMS) for secure objects [RFC5652]. CMS is defined using Abstract Syntax Notation 1 (ASN.1) and typically encoded using the ASN.1 Distinguished Encoding Rules (DER), which define a binary encoding of the protected message and associated parameters [ITU.X690.2002]. In recent years, usage of ASN.1 has decreased (along with other binary encodings for general objects), while more applications have come to rely on text-based formats such as the Extensible Markup Language (XML) [W3C.REC-xml] or the JavaScript Object Notation (JSON) [RFC7159].
S / MIMEは、セキュリティで保護されたオブジェクトの暗号化メッセージ構文（CMS）に基づいています[RFC5652]。 CMSは、Abstract Syntax Notation 1（ASN.1）を使用して定義され、通常、保護されたメッセージと関連パラメーターのバイナリエンコーディングを定義するASN.1 Distinguished Encoding Rules（DER）を使用してエンコードされます[ITU.X690.2002]。近年、ASN.1の使用は（一般的なオブジェクトの他のバイナリエンコーディングと共に）減少しましたが、Extensible Markup Language（XML）[W3C.REC-xml]などのテキストベースのフォーマットに依存するアプリケーションが増えています。またはJavaScript Object Notation（JSON）[RFC7159]。
Many current applications thus have much more robust support for processing objects in these text-based formats than ASN.1 objects; indeed, many lack the ability to process ASN.1 objects at all. To simplify the addition of object-based security features to these applications, the IETF JSON Object Signing and Encryption (JOSE) working group has been chartered to develop a secure object format based on JSON. While the basic requirements for this object format are straightforward -- namely, confidentiality and integrity mechanisms encoded in JSON -- discussions in the working group indicated that different applications hoping to use the formats defined by JOSE have different requirements. This document summarizes the use cases for JOSE envisioned by those potential applications and the resulting requirements for security mechanisms and object encodings.
したがって、現在の多くのアプリケーションは、ASN.1オブジェクトよりも、これらのテキストベースの形式でオブジェクトを処理するためのより強力なサポートを備えています。実際、多くの場合、ASN.1オブジェクトを処理する機能がまったくありません。これらのアプリケーションへのオブジェクトベースのセキュリティ機能の追加を簡素化するために、IETF JSON Object Signing and Encryption（JOSE）ワーキンググループは、JSONに基づく安全なオブジェクト形式を開発するために設立されました。このオブジェクト形式の基本的な要件は単純です-つまり、JSONでエンコードされた機密性と整合性のメカニズム-ワーキンググループでの議論は、JOSEによって定義された形式を使用することを期待するさまざまなアプリケーションにはさまざまな要件があることを示しました。このドキュメントは、これらの潜在的なアプリケーションによって想定されるJOSEの使用事例と、セキュリティメカニズムおよびオブジェクトエンコーディングの結果として生じる要件を要約しています。
Some systems that use XML have specified the use of XML-based security mechanisms for object security, namely XML Digital Signatures and XML Encryption [W3C.xmldsig-core] [W3C.xmlenc-core]. These mechanisms are used by several security token systems (e.g., Security Assertion Markup Language (SAML) [OASIS.saml-core-2.0-os], Web Services Federation [WS-Federation]), and the Common Alerting Protocol (CAP) emergency alerting format [CAP]. In practice, however, XML-based secure object formats introduce similar levels of complexity to ASN.1 (e.g., due to the need for XML canonicalization), so developers that lack the tools or motivation to handle ASN.1 aren't likely to use XML security either. This situation motivates the creation of a JSON-based secure object format that is simple enough to implement and deploy that it can be easily adopted by developers with minimal effort and tools.
XMLを使用する一部のシステムは、オブジェクトセキュリティのためのXMLベースのセキュリティメカニズム、つまりXMLデジタル署名とXML暗号化[W3C.xmldsig-core] [W3C.xmlenc-core]の使用を指定しています。これらのメカニズムは、いくつかのセキュリティトークンシステム（たとえば、セキュリティアサーションマークアップ言語（SAML）[OASIS.saml-core-2.0-os]、Webサービスフェデレーション[WS-Federation]）、およびCommon Alerting Protocol（CAP）緊急時に使用されます。警告フォーマット[CAP]。ただし、実際には、XMLベースの安全なオブジェクト形式は、ASN.1に同様のレベルの複雑さをもたらします（たとえば、XMLの正規化が必要なため）。そのため、ASN.1を処理するツールや動機がない開発者は、 XMLセキュリティを使用します。この状況は、JSONベースの安全なオブジェクト形式の作成を動機づけ、実装とデプロイが簡単で、最小限の労力とツールで開発者が簡単に採用できるようにします。
This document makes extensive use of standard security terminology [RFC4949]. In addition, because the use cases for JOSE and CMS are similar, we will sometimes make analogies to some CMS concepts [RFC5652].
このドキュメントでは、標準のセキュリティ用語[RFC4949]を幅広く使用しています。さらに、JOSEとCMSのユースケースは類似しているため、CMSの概念[RFC5652]に類似する場合があります。
The JOSE working group charter calls for the group to define three basic JSON object formats:
JOSEワーキンググループチャーターは、グループに3つの基本的なJSONオブジェクト形式を定義するよう要求します。
1. Integrity-protected object format
1. 整合性保護されたオブジェクト形式
2. Confidentiality-protected object format
2. 機密保護されたオブジェクト形式
3. A format for expressing keys
3. キーを表現するためのフォーマット
In this document, we will refer to these as the "signed object format", the "encrypted object format", and the "key format", respectively. The JOSE working group items intended to describe these formats are JSON Web Signature [JWS], JSON Web Encryption [JWE], and JSON Web Key [JWK], respectively. Algorithms and algorithm identifiers used by JWS, JWE, and JWK are defined in JSON Web Algorithms [JWA].
このドキュメントでは、これらをそれぞれ「署名付きオブジェクト形式」、「暗号化オブジェクト形式」、「鍵形式」と呼びます。これらの形式を説明するためのJOSEワーキンググループの項目は、それぞれJSON Web Signature [JWS]、JSON Web Encryption [JWE]、JSON Web Key [JWK]です。 JWS、JWE、およびJWKで使用されるアルゴリズムとアルゴリズム識別子は、JSON Web Algorithms [JWA]で定義されています。
In general, where there is no need to distinguish between asymmetric and symmetric operations, we will use the terms "signing", "signature", etc., to denote both true digital signatures involving asymmetric cryptography as well as Message Authentication Codes (MACs) using symmetric keys.
一般に、非対称操作と対称操作を区別する必要がない場合は、「署名」、「署名」などの用語を使用して、非対称暗号とメッセージ認証コード（MAC）を含む真のデジタル署名の両方を示します。対称鍵を使用する。
In the lifespan of a secure object, there are two basic roles, an entity that creates the object (e.g., encrypting or signing a payload) and an entity that uses the object (decrypting and verifying). We will refer to these roles as "sender" and "recipient", respectively. Note that while some requirements and use cases may refer to these as single entities, each object may have multiple entities in each role. For example, a message may be signed by multiple senders or decrypted by multiple recipients.
安全なオブジェクトの存続期間には、2つの基本的な役割があります。オブジェクトを作成するエンティティ（ペイロードの暗号化や署名など）と、オブジェクトを使用するエンティティ（復号化と検証）です。これらの役割をそれぞれ「送信者」と「受信者」と呼びます。一部の要件とユースケースではこれらを単一のエンティティと呼ぶ場合がありますが、各オブジェクトには各ロールに複数のエンティティがある場合があります。たとえば、メッセージは複数の送信者によって署名されたり、複数の受信者によって復号化されたりする場合があります。
For the encrypted and signed object formats, the necessary protections will be created using appropriate cryptographic mechanisms: symmetric or asymmetric encryption for confidentiality and MACs or digital signatures for integrity protection. In both cases, it is necessary for the JOSE format to support both symmetric and asymmetric operations.
暗号化および署名されたオブジェクト形式の場合、必要な保護は適切な暗号化メカニズムを使用して作成されます：機密性のための対称または非対称暗号化と整合性保護のためのMACまたはデジタル署名。どちらの場合も、JOSEフォーマットで対称操作と非対称操作の両方をサポートする必要があります。
o The JOSE encrypted object format must support object encryption in the case where the sender and receiver share a symmetric key.
o JOSE暗号化オブジェクト形式は、送信者と受信者が対称鍵を共有する場合のオブジェクト暗号化をサポートする必要があります。
o The JOSE encrypted object format must support object encryption in the case where the sender has only a public key for the receiver.
o JOSE暗号化オブジェクト形式は、送信者が受信者の公開鍵しか持っていない場合にオブジェクト暗号化をサポートする必要があります。
o The JOSE signed object format must support integrity protection using MACs, for the case where the sender and receiver share only a symmetric key.
o JOSE署名付きオブジェクト形式は、送信者と受信者が対称鍵のみを共有する場合のために、MACを使用した整合性保護をサポートする必要があります。
o The JOSE signed object format must support integrity protection using digital signatures, for the case where the receiver has only a public key for the sender.
o JOSE署名付きオブジェクト形式は、受信者が送信者の公開鍵しか持っていない場合、デジタル署名を使用した整合性保護をサポートする必要があります。
In some applications, the key used to process a JOSE object is indicated by application context, instead of directly in the JOSE object. However, in order to avoid confusion, endpoints that lack the necessary context need to be able to recognize this and fail cleanly. Other than keys, JOSE objects do not support pre-negotiation; all cryptographic parameters must be expressed directly in the JOSE object.
一部のアプリケーションでは、JOSEオブジェクトの処理に使用されるキーは、JOSEオブジェクト内で直接ではなく、アプリケーションコンテキストによって示されます。ただし、混乱を避けるために、必要なコンテキストが不足しているエンドポイントは、これを認識して完全に失敗する必要があります。キー以外のJOSEオブジェクトは事前交渉をサポートしていません。すべての暗号化パラメーターは、JOSEオブジェクトで直接表現する必要があります。
o The JOSE signed and encrypted object formats must define the process by which an implementation recognizes whether it has the key required to process a given object, whether the key is specified by the object or by some out-of-band mechanism.
o JOSEで署名および暗号化されたオブジェクト形式は、特定のオブジェクトを処理するために必要なキーがあるかどうか、実装がオブジェクトまたは特定のアウトオブバンドメカニズムによって指定されているかどうかを実装が認識するプロセスを定義する必要があります。
o Each algorithm used for JOSE must define which parameters are required to be present in a JOSE object using that algorithm.
o JOSEに使用される各アルゴリズムは、そのアルゴリズムを使用してJOSEオブジェクトに存在する必要があるパラメーターを定義する必要があります。
In cases where two entities are going to be exchanging several JOSE objects, it might be helpful to pre-negotiate some parameters so that they do not have to be signaled in every JOSE object. However, so as not to confuse endpoints that do not support pre-negotiation, it is useful to signal when pre-negotiated parameters are in use in those cases.
2つのエンティティーが複数のJOSEオブジェクトを交換する場合、すべてのJOSEオブジェクトでシグナルを送信する必要がないように、いくつかのパラメーターを事前にネゴシエートすると役立つ場合があります。ただし、事前ネゴシエーションをサポートしていないエンドポイントを混同しないように、事前ネゴシエーションされたパラメーターがそのような場合にいつ使用されているかを通知すると便利です。
o It should be possible to extend the base JOSE signed and encrypted object formats to indicate that pre-negotiated parameters are to be used to process the object. This extension should also provide a means of indicating which parameters are to be used.
o 基本のJOSE署名および暗号化オブジェクト形式を拡張して、事前に交渉されたパラメーターがオブジェクトの処理に使用されることを示すことができるはずです。この拡張は、使用するパラメータを示す手段も提供する必要があります。
The purpose of the key format is to provide the recipient with sufficient information to use the encoded key to process cryptographic messages. Thus, it is sometimes necessary to include additional parameters along with the bare key.
キー形式の目的は、暗号化されたキーを使用して暗号メッセージを処理するために十分な情報を受信者に提供することです。したがって、時々、裸のキーとともに追加のパラメータを含める必要があります。
o The JOSE key format must enable inclusion of all algorithm parameters necessary to use the encoded key, including an identifier for the algorithm with which the key is used as well as any additional parameters required by the algorithm (e.g., elliptic curve parameters).
o JOSEキー形式では、暗号化キーの使用に必要なすべてのアルゴリズムパラメーターを含めることができる必要があります。これには、キーが使用されるアルゴリズムの識別子や、アルゴリズムに必要な追加パラメーター（楕円曲線パラメーターなど）が含まれます。
The JOSE secure object formats describe how cryptographic processing is done on secured content, ensuring that the recipient of an object is able to properly decrypt an encrypted object or verify a signature. In order to make use of JOSE, however, applications will need to specify several aspects of how JOSE is to be used:
JOSEセキュアオブジェクトフォーマットは、セキュリティで保護されたコンテンツで暗号処理がどのように行われるかを記述し、オブジェクトの受信者が暗号化されたオブジェクトを適切に復号化または署名を検証できるようにします。ただし、JOSEを利用するには、アプリケーションでJOSEの使用方法のいくつかの側面を指定する必要があります。
o What application content is to be protected
o 保護するアプリケーションコンテンツ
o Which cryptographic algorithms are to be used
o 使用する暗号アルゴリズム
o How application protocol entities establish keys
o アプリケーションプロトコルエンティティがキーを確立する方法
o Whether keys are to be explicitly indicated in JOSE objects or associated by application context
o キーがJOSEオブジェクトで明示的に示されるか、アプリケーションコンテキストによって関連付けられるか
o Which serialization(s) of JOSE objects are to be used
o 使用するJOSEオブジェクトのシリアル化
Several IETF working groups developing application-layer protocols have expressed a desire to use the JOSE data formats in their designs for end-to-end security features. In this section, we summarize the use cases proposed by these groups and discuss the requirements that they imply for the JOSE object formats.
アプリケーション層プロトコルを開発しているいくつかのIETFワーキンググループは、エンドツーエンドのセキュリティ機能の設計でJOSEデータ形式を使用したいという要望を表明しています。このセクションでは、これらのグループによって提案されたユースケースを要約し、JOSEオブジェクト形式に対してそれらが意味する要件について説明します。
Security tokens are a common use case for object-based security, for example, SAML assertions [OASIS.saml-core-2.0-os]. Security tokens are used to convey information about a subject entity ("claims" or "assertions") from an issuer to a recipient. The security features of a token format enable the recipient to verify that the claims came from the issuer and, if the object is confidentiality protected, that they were not visible to other parties.
セキュリティトークンは、SAMLアサーション[OASIS.saml-core-2.0-os]などのオブジェクトベースのセキュリティの一般的な使用例です。セキュリティトークンは、サブジェクトエンティティに関する情報（「クレーム」または「アサーション」）を発行者から受信者に伝えるために使用されます。トークン形式のセキュリティ機能により、受信者は、クレームが発行者からのものであること、およびオブジェクトが機密保護されている場合、他の当事者には見えないことを確認できます。
Security tokens are used in federation protocols such as SAML 2.0 [OASIS.saml-core-2.0-os], WS-Federation [WS-Federation], Mozilla Persona [Persona], and OpenID Connect [OpenID.Core], as well as in resource authorization protocols such as OAuth 2.0 [RFC6749], including for OAuth bearer tokens [RFC6750]. In some cases, security tokens are used for client authentication and for access control [JWT-BEARER] [SAML2].
セキュリティトークンは、SAML 2.0 [OASIS.saml-core-2.0-os]、WS-Federation [WS-Federation]、Mozilla Persona [Persona]、OpenID Connect [OpenID.Core]などのフェデレーションプロトコルで使用されています。 OAuth 2.0 [RFC6749]などのリソース認証プロトコル（OAuthベアラートークン[RFC6750]を含む）。場合によっては、セキュリティトークンがクライアント認証とアクセス制御[JWT-BEARER] [SAML2]に使用されます。
JSON Web Token [JWT] is a security token format based on JSON and JOSE. It is used with Mozilla Persona, OpenID Connect, and OAuth. Because JWTs are often used in contexts with limited space (e.g., HTTP query parameters), it is a core requirement for JWTs, and thus JOSE, to have a compact, URL-safe representation.
JSON Web Token [JWT]は、JSONおよびJOSEに基づくセキュリティトークン形式です。 Mozilla Persona、OpenID Connect、およびOAuthで使用されます。 JWTは、スペースが限られているコンテキスト（HTTPクエリパラメータなど）で使用されることが多いため、コンパクトでURLセーフな表現を持つことは、JWT、つまりJOSEのコア要件です。
The OAuth protocol defines a mechanism for distributing and using authorization tokens using HTTP [RFC6749]. A client that wishes to access a protected resource requests authorization from the resource owner. If the resource owner allows this access, he directs an authorization server to issue an access token to the client. When the client wishes to access the protected resource, he presents the token to the relevant resource server, which verifies the validity of the token before providing access to the protected resource.
OAuthプロトコルは、HTTP [RFC6749]を使用して認証トークンを配布および使用するためのメカニズムを定義します。保護されたリソースへのアクセスを希望するクライアントは、リソース所有者に承認を要求します。リソース所有者がこのアクセスを許可した場合、彼は許可サーバーにクライアントにアクセストークンを発行するように指示します。クライアントは保護されたリソースへのアクセスを希望する場合、関連するリソースサーバーにトークンを提示し、保護されたリソースへのアクセスを提供する前にトークンの有効性を検証します。
+---------------+ +---------------+
| | | |
| Resource |<........>| Authorization |
| Server | | Server |
| | | |
+---------------+ +---------------+
^ |
| |
| |
| |
| |
+------------|--+ +--|------------+
| +----------------+ |
| | | Resource |
| Client | | Owner |
| | | |
+---------------+ +---------------+
Figure 1: The OAuth Process
図1：OAuthプロセス
In effect, this process moves the token from the authorization server (as a sender of the object) to the resource server (recipient) via the client as well as the resource owner (the latter because of the HTTP mechanics underlying the protocol). As with email, we have a case where an application object is transported via untrusted intermediaries.
実際、このプロセスは、トークンを承認サーバー（オブジェクトの送信者として）からリソースサーバー（受信者）に、クライアントとリソース所有者（後者はプロトコルの基礎となるHTTPメカニズムのため）を介して移動します。電子メールと同様に、アプリケーションオブジェクトが信頼できない仲介者を介して転送される場合があります。
This application has two essential security requirements: integrity and data origin authentication. Integrity protection is required so that the resource owner and the client cannot modify the permission encoded in the token. Although the resource owner is ultimately the entity that grants authorization, it is not trusted to modify the authorization token, since this could, for example, grant access to resources not owned by the resource owner.
このアプリケーションには、整合性とデータ発信元認証という2つの重要なセキュリティ要件があります。リソースの所有者とクライアントがトークンにエンコードされた権限を変更できないように、整合性保護が必要です。リソース所有者は最終的には承認を付与するエンティティですが、たとえば、リソース所有者が所有していないリソースへのアクセスを許可する可能性があるため、承認トークンを変更することはできません。
Data origin authentication is required so that the resource server can verify that the token was issued by a trusted authorization server.
リソースサーバーがトークンが信頼された承認サーバーによって発行されたことを確認できるようにするには、データオリジン認証が必要です。
Confidentiality protection may also be needed if the authorization server is concerned about the visibility of permissions information to the resource owner or client. For example, permissions related to social networking might be considered private information. Note, however, that OAuth already requires that the underlying HTTP transactions be protected by TLS, so tokens are already confidentiality protected from entities other than the resource owner and client.
許可サーバーがリソース所有者またはクライアントへの許可情報の可視性を懸念している場合は、機密保護も必要になる場合があります。たとえば、ソーシャルネットワーキングに関連する権限は、個人情報と見なされる場合があります。ただし、OAuthではすでに、基になるHTTPトランザクションをTLSで保護する必要があるため、トークンは既にリソースの所有者とクライアント以外のエンティティから保護されています。
The confidentiality and integrity needs are met by the basic requirements for signed and encrypted object formats, whether the signing and encryption are provided using asymmetric or symmetric cryptography. The choice of which mechanism is applied will depend on the relationship between the two servers, namely whether they share a symmetric key or only public keys.
署名と暗号化が非対称暗号化と対称暗号化のどちらを使用して提供されるかにかかわらず、機密性と整合性のニーズは、署名および暗号化されたオブジェクト形式の基本要件によって満たされます。適用するメカニズムの選択は、2つのサーバー間の関係、つまり、対称鍵を共有するか、公開鍵のみを共有するかによって異なります。
Authentication requirements will also depend on deployment characteristics. Where there is a relatively strong binding between the resource server and the authorization server, it may suffice for the authorization server issuing a token to be identified by the key used to sign the token. This requires that the protocol carry either the public key of the authorization server or an identifier for the public or symmetric key. In OAuth, the "client_id" parameter (external to the token) identifies the key to be used.
認証要件は、展開の特性にも依存します。リソースサーバーと承認サーバーの間に比較的強力なバインディングがある場合、トークンを発行する承認サーバーがトークンの署名に使用されるキーによって識別されることで十分です。これには、プロトコルが許可サーバーの公開鍵か、公開鍵または対称鍵の識別子のいずれかを運ぶ必要があります。 OAuthでは、「client_id」パラメーター（トークンの外部）が使用するキーを識別します。
There may also be more advanced cases where the authorization server's key is not known in advance to the resource server. This may happen, for instance, if an entity instantiated a collection of authorization servers (say for load balancing), each of which has an independent key pair. In these cases, it may be necessary to also include a certificate or certificate chain for the authorization server, so that the resource server can verify that the authorization server is an entity that it trusts.
承認サーバーのキーがリソースサーバーに事前に知られていない、より高度なケースもあります。これは、たとえば、エンティティが承認サーバーのコレクション（たとえば、負荷分散など）をインスタンス化した場合に発生する可能性があり、それぞれに独立したキーペアがあります。これらの場合、リソースサーバーが承認サーバーが信頼するエンティティであることをリソースサーバーが確認できるように、承認サーバーの証明書または証明書チェーンも含める必要がある場合があります。
The HTTP transport for OAuth imposes a particular constraint on the encoding. In the OAuth protocol, tokens frequently need to be passed as query parameters in HTTP URIs [RFC2616] after having been base64url encoded [RFC4648]. While there is no specified limit on the length of URIs (and thus of query parameters), in practice, URIs of more than 2,048 characters are rejected by some user agents. So this use case requires that JOSE objects be sufficiently small, even after being signed and possibly encrypted.
OAuthのHTTPトランスポートは、エンコーディングに特定の制約を課します。 OAuthプロトコルでは、トークンはbase64urlエンコード[RFC4648]された後、HTTP URI [RFC2616]でクエリパラメータとして渡される必要があることがよくあります。 URI（およびクエリパラメータ）の長さに特定の制限はありませんが、実際には、2,048文字を超えるURIは一部のユーザーエージェントによって拒否されます。したがって、このユースケースでは、署名され、場合によっては暗号化された後でも、JOSEオブジェクトが十分に小さいことが必要です。
The OpenID Connect protocol [OpenID.Core] is a simple, REST/JSON-based identity federation protocol layered on OAuth 2.0. It uses the JWT and JOSE formats both to represent security tokens and to provide security for other protocol messages (performing signing and optionally encryption). OpenID Connect negotiates the algorithms to be used and distributes information about the keys to be used using protocol elements that are not part of the JWT and JOSE header parameters.
OpenID Connectプロトコル[OpenID.Core]は、OAuth 2.0に階層化されたシンプルなREST / JSONベースのIDフェデレーションプロトコルです。 JWTおよびJOSE形式を使用して、セキュリティトークンを表し、他のプロトコルメッセージにセキュリティを提供します（署名およびオプションで暗号化を実行します）。 OpenID Connectは、使用されるアルゴリズムをネゴシエートし、JWTおよびJOSEヘッダーパラメーターの一部ではないプロトコル要素を使用して、使用されるキーに関する情報を配布します。
In the OpenID Connect context, it is possible for the recipient of a JWT to accept it without integrity protection in the JWT itself. In such cases, the recipient chooses to rely on transport security rather than object security. For example, if the payload is delivered over a TLS-protected channel, the recipient may regard the protections provided by TLS as sufficient, so JOSE protection would not be required.
OpenID Connectコンテキストでは、JWTの受信者がJWT自体の整合性保護なしでそれを受け入れることができます。このような場合、受信者はオブジェクトのセキュリティではなく、トランスポートのセキュリティに依存することを選択します。たとえば、ペイロードがTLSで保護されたチャネルを介して配信される場合、受信者はTLSによって提供される保護を十分であると見なす可能性があるため、JOSE保護は必要ありません。
However, even in this case, it is desirable to associate some metadata with the JWT payload (claim set), such as the content type, or other application-specific metadata. In a signed or encrypted object, these metadata values could be carried in a header with other metadata required for signing or encryption. It would thus simplify the design of OpenID Connect if there could be a JOSE object format that does not apply cryptographic protections to its payload, but allows a header to be attached to the payload in the same way as a signed or encrypted object.
ただし、この場合でも、コンテンツタイプや他のアプリケーション固有のメタデータなど、一部のメタデータをJWTペイロード（クレームセット）に関連付けることが望ましいです。署名または暗号化されたオブジェクトでは、これらのメタデータ値は、署名または暗号化に必要な他のメタデータと一緒にヘッダーで運ばれる可能性があります。したがって、ペイロードに暗号化保護を適用しないJOSEオブジェクト形式があり、署名または暗号化されたオブジェクトと同じ方法でペイロードにヘッダーを添付できる場合、OpenID Connectの設計を簡素化します。
The Extensible Messaging and Presence Protocol (XMPP) routes messages from one end client to another by way of XMPP servers [RFC6120]. There are typically two servers involved in delivering any given message: The first client (Alice) sends a message for another client (Bob) to her server (A). Server A uses Bob's identity and the DNS to locate the server for Bob's domain (B) and then delivers the message to that server. Server B then routes the message to Bob.
Extensible Messaging and Presence Protocol（XMPP）は、XMPPサーバー[RFC6120]を介して、あるエンドクライアントから別のエンドクライアントにメッセージをルーティングします。通常、特定のメッセージの配信には2つのサーバーが関与します。最初のクライアント（Alice）は、別のクライアント（Bob）へのメッセージを自分のサーバー（A）に送信します。サーバーAはボブのIDとDNSを使用してボブのドメイン（B）のサーバーを特定し、メッセージをそのサーバーに配信します。次に、サーバーBはメッセージをボブにルーティングします。
+-------+ +----------+ +----------+ +-----+
| Alice |-->| Server A |-->| Server B |-->| Bob |
+-------+ +----------+ +----------+ +-----+
Figure 2: Delivering an XMPP Message
図2：XMPPメッセージの配信
The untrusted-intermediary problems are especially acute for XMPP because in many current deployments, the holder of an XMPP domain outsources the operation of the domain's servers to a different entity. In this environment, there is a clear risk of exposing the domain holder's private information to the domain operator. XMPP already has a defined mechanism for end-to-end security using S/MIME, but it has failed to gain widespread deployment [RFC3923], in part because of key management challenges and in part because of the difficulty of processing S/MIME objects.
現在の多くの展開では、XMPPドメインの所有者がドメインのサーバーの運用を別のエンティティに外部委託しているため、信頼できない仲介者の問題はXMPPにとって特に深刻です。この環境では、ドメイン所有者の個人情報がドメインオペレーターに公開されるリスクが明らかにあります。 XMPPにはS / MIMEを使用したエンドツーエンドのセキュリティのメカニズムがすでに定義されていますが、一部には主要な管理上の課題があり、一部にはS / MIMEオブジェクトを処理することが困難であるため、広範囲に展開することはできませんでした[RFC3923]。 。
The XMPP working group is in the process of developing a new end-to-end encryption system with an encoding based on JOSE and a clearer key management system [XMPP-E2E]. The process of sending an encrypted message in this system involves two steps: First, the sender generates a symmetric Session Master Key (SMK), encrypts the message content (including a per-message Content Master Key), and sends the encrypted message to the desired set of recipients.
XMPPワーキンググループは、JOSEに基づくエンコーディングとより明確なキー管理システム[XMPP-E2E]を備えた新しいエンドツーエンドの暗号化システムを開発中です。このシステムで暗号化されたメッセージを送信するプロセスには2つのステップが含まれます。最初に、送信者は対称セッションマスターキー（SMK）を生成し、メッセージコンテンツ（メッセージごとのコンテンツマスターキーを含む）を暗号化し、暗号化されたメッセージを必要な受信者のセット。
Second, each recipient "dials back" to the sender, providing his public key. The sender then responds with the relevant SMK, wrapped with the recipient's public key.
次に、各受信者は送信者に「ダイヤルバック」し、自分の公開鍵を提供します。次に、送信者は、受信者の公開鍵でラップされた関連するSMKで応答します。
+-------+ +----------+ +----------+ +-----+
| Alice |<->| Server A |<->| Server B |<->| Bob |
+-------+ +----------+ +----------+ +-----+
| | | |
|------------Encrypted message---------->|
| | | |
|<---------------Public key--------------|
| | | |
|---------------Wrapped SMK------------->|
| | | |
Figure 3: Delivering a Secure XMPP Message
図3：安全なXMPPメッセージの配信
The main thing that this system requires from the JOSE formats is confidentiality protection via content encryption, plus an integrity check via a MAC derived from the same symmetric key. The separation of the key exchange from the transmission of the encrypted content, however, requires that the JOSE encrypted object format allow wrapped symmetric keys to be carried separately from the encrypted payload. In addition, the encrypted object will need to have a tag for the key that was used to encrypt the content, so that the recipient (Bob) can present the tag to the sender (Alice) when requesting the wrapped key.
このシステムがJOSEフォーマットで必要とする主なものは、コンテンツの暗号化による機密保護と、同じ対称鍵から派生したMACによる整合性チェックです。ただし、暗号化されたコンテンツの送信から鍵交換を分離するには、JOSE暗号化オブジェクト形式で、ラップされた対称鍵を暗号化されたペイロードとは別に伝送できる必要があります。さらに、暗号化されたオブジェクトには、コンテンツの暗号化に使用されたキーのタグが必要です。これにより、ラップされたキーを要求するときに受信者（Bob）が送信者（Alice）にタグを提示できます。
Another important feature of XMPP is that it allows for the simultaneous delivery of a message to multiple recipients. In the diagrams above, Server A could deliver the message not only to Server B (for Bob) but also to Servers C, D, E, etc., for other users. In such cases, to avoid the multiple "dial back" transactions implied by the above mechanism, XMPP systems will likely reuse a given SMK for multiple individual messages, refreshing the SMK on a periodic and/or event-driven basis (e.g., when the recipient's presence changes). They might also cache public keys for end recipients, so that wrapped keys can be sent along with content on future messages. This implies that the JOSE encrypted object format must support the provision of multiple versions of the same wrapped SMK (much as a CMS EnvelopedData structure can include multiple RecipientInfo structures).
XMPPのもう1つの重要な機能は、複数の受信者へのメッセージの同時配信を可能にすることです。上の図では、サーバーAはメッセージをサーバーB（ボブの場合）だけでなく、他のユーザーのサーバーC、D、Eなどにも配信できます。このような場合、上記のメカニズムが意味する複数の「ダイヤルバック」トランザクションを回避するために、XMPPシステムは複数の個々のメッセージに対して特定のSMKを再利用し、定期的またはイベントドリブンベースでSMKを更新します（たとえば、受信者のプレゼンスが変更されます）。また、エンド受信者の公開鍵をキャッシュして、ラップされた鍵を将来のメッセージのコンテンツとともに送信できるようにすることもできます。これは、JOSE暗号化オブジェクト形式が同じラップされたSMKの複数のバージョンのプロビジョニングをサポートする必要があることを意味します（CMS EnvelopedData構造に複数のRecipientInfo構造を含めることができるため）。
In the current draft of the XMPP end-to-end security system, each party is authenticated by virtue of the other party's trust in the XMPP message routing system. The sender is authenticated to the receiver because he can receive messages for the identifier "Alice" (in particular, the request for wrapped keys) and can originate messages for that identifier (the wrapped key). Likewise, the receiver is authenticated to the sender because he received the original encrypted message and originated the request for a wrapped key. So, the authentication here requires not only that XMPP routing be done properly, but also that TLS be used on every hop. Moreover, it requires that the TLS channels have strong authentication, since a man in the middle on any of the three hops can masquerade as Bob and obtain the key material for an encrypted message.
XMPPエンドツーエンドセキュリティシステムの現在のドラフトでは、各当事者は、XMPPメッセージルーティングシステムにおける他の当事者の信頼によって認証されます。送信者は、識別子「アリス」のメッセージ（特に、ラップされたキーの要求）を受信し、その識別子（ラップされたキー）のメッセージを発信できるため、受信者に対して認証されます。同様に、受信者は暗号化された元のメッセージを受信し、ラップされたキーの要求を発信したため、送信者に対して認証されます。したがって、ここでの認証では、XMPPルーティングが適切に行われるだけでなく、すべてのホップでTLSが使用される必要があります。さらに、3つのホップのいずれかの中間にいる人がボブになりすまし、暗号化されたメッセージのキーマテリアルを取得できるため、TLSチャネルには強力な認証が必要です。
Because this authentication is quite weak (depending on the use of TLS on three hops) and unverifiable by the endpoints, it is possible that the XMPP working group will integrate some sort of credentials for end recipients, in which case there would need to be a way to associate these credentials with JOSE objects.
この認証は非常に弱く（3ホップでのTLSの使用に依存）、エンドポイントで検証できないため、XMPPワーキンググループがエンド受信者のある種の資格情報を統合する可能性があります。この場合、これらの資格情報をJOSEオブジェクトに関連付ける方法。
Finally, it's worth noting that XMPP is based on XML, not JSON. So by using JOSE, XMPP will be carrying JSON objects within XML. It is thus a desirable property for JOSE objects to be encoded in such a way as to be safe for inclusion in XML. Otherwise, an explicit CDATA indication must be given to the parser to indicate that it is not to be parsed as XML. One way to meet this requirement would be to apply base64url encoding, but for XMPP messages of medium-to-large size, this could impose a fair degree of overhead.
最後に、XMPPはJSONではなくXMLに基づいていることに注意してください。したがって、JOSEを使用することにより、XMPPはXML内でJSONオブジェクトを運ぶことになります。したがって、JOSEオブジェクトをXMLに安全に含めることができるようにエンコードすることは、JOSEオブジェクトにとって望ましい特性です。それ以外の場合、XMLとして解析しないことを示すために、明示的なCDATA指示をパーサーに与える必要があります。この要件を満たす1つの方法は、base64urlエンコーディングを適用することですが、中規模から大規模のXMPPメッセージの場合、これはある程度のオーバーヘッドを課す可能性があります。
Application-Layer Traffic Optimization (ALTO) is a system for distributing network topology information to end devices, so that those devices can modify their behavior to have a lower impact on the network [RFC6708]. The ALTO protocol distributes topology information in the form of JSON objects carried in HTTP [RFC2616] [ALTO]. The basic version of ALTO is simply a client-server protocol, so simple use of HTTPS suffices for this case [RFC2818]. However, there is beginning to be some discussion of use cases for ALTO in which these JSON objects will be distributed through a collection of intermediate servers before reaching the client, while still preserving the ability of the client to authenticate the original source of the object. Even the base ALTO protocol notes that "ALTO Clients obtaining ALTO information through redistribution must be able to validate the received ALTO information" to ensure that it was generated by an appropriate ALTO server.
Application-Layer Traffic Optimization（ALTO）は、ネットワークトポロジー情報をエンドデバイスに配信するためのシステムです。これにより、これらのデバイスは動作を変更して、ネットワークへの影響を軽減できます[RFC6708]。 ALTOプロトコルは、HTTP [RFC2616] [ALTO]で伝送されるJSONオブジェクトの形式でトポロジ情報を配布します。 ALTOの基本バージョンは単なるクライアント/サーバープロトコルなので、この場合はHTTPSの単純な使用で十分です[RFC2818]。ただし、ALTOの使用例については、これらのJSONオブジェクトが中間サーバーのコレクションを介してクライアントに到達する前に配布される一方で、オブジェクトの元のソースを認証するクライアントの機能を維持するという議論が始まっています。ベースのALTOプロトコルでさえ、「再配布を通じてALTO情報を取得するALTOクライアントは、受信したALTO情報を検証して、適切なALTOサーバーによって生成されたことを確認できる必要がある」と述べています。
In this case, the security requirements are straightforward. JOSE objects carrying ALTO payloads will need to bear digital signatures from the originating servers, which will be bound to certificates attesting to the identities of the servers. There is no requirement for confidentiality in this case, since ALTO information is generally public.
この場合、セキュリティ要件は簡単です。 ALTOペイロードを運ぶJOSEオブジェクトは、元のサーバーからのデジタル署名を保持する必要があります。これは、サーバーのIDを証明する証明書にバインドされます。 ALTOの情報は一般に公開されているため、この場合は機密性の要件はありません。
The more interesting questions are encoding questions. ALTO objects are likely to be much larger than payloads in the two cases above, with sizes of up to several megabytes. Processing of such large objects can be done more quickly if it can be done in a single pass, which may be possible if JOSE objects require specific orderings of fields within the JSON structure.
より興味深い質問はエンコードの質問です。 ALTOオブジェクトは、上記の2つのケースでペイロードよりはるかに大きく、サイズが最大で数メガバイトになる可能性があります。そのような大きなオブジェクトの処理は、シングルパスで実行できる場合はより迅速に実行できます。JOSEオブジェクトがJSON構造内のフィールドの特定の順序を必要とする場合に可能です。
In addition, because ALTO objects are also encoded as JSON, they are already safe for inclusion in a JOSE object. Signed JOSE objects will likely carry the signed data in a string alongside the signature. JSON objects have the property that they can be safely encoded in JSON strings. All they require is that unnecessary white space be removed, a much simpler transformation than, say, base64url encoding. This raises the question of whether it might be possible to optimize the JOSE encoding for certain "JSON-safe" cases.
さらに、ALTOオブジェクトもJSONとしてエンコードされているため、JOSEオブジェクトに含めても安全です。署名されたJOSEオブジェクトは、署名とともに、署名されたデータを文字列で運ぶ可能性があります。 JSONオブジェクトには、JSON文字列に安全にエンコードできるというプロパティがあります。彼らが必要とするのは、不要な空白を削除することだけです。たとえば、base64urlエンコーディングよりもはるかに単純な変換です。これは、特定の「JSONセーフ」なケースに対してJOSEエンコーディングを最適化できるかどうかという疑問を提起します。
Finally, it may be desirable for ALTO to have a "detached signature" mechanism, that is, a way to encode signature information separate from the protected content. This would allow the ALTO protocol to include the signature in an HTTPS header, with the signed content as the HTTPS entity body.
最後に、ALTOには「切り離された署名」メカニズム、つまり保護されたコンテンツとは別に署名情報をエンコードする方法があることが望ましい場合があります。これにより、ALTOプロトコルは、署名されたコンテンツをHTTPSエンティティボディとして、HTTPSヘッダーに署名を含めることができます。
Emergency alerting is an emerging use case for IP networks [ALERT-REQ]. Alerting systems allow authorities to warn users of impending danger by sending alert messages to connected devices. For example, in the event of a hurricane or tornado, alerts might be sent to all devices in the path of the storm.
緊急警報は、IPネットワーク[ALERT-REQ]の新しい使用例です。警報システムにより、当局は警報メッセージを接続されたデバイスに送信することにより、差し迫った危険をユーザーに警告することができます。たとえば、ハリケーンや竜巻が発生した場合、嵐の経路にあるすべてのデバイスにアラートが送信される可能性があります。
The most critical security requirement for alerting systems is that it must not be possible for an attacker to send false alerts to devices. Such a capability would potentially allow an attacker to create wide-spread panic. In practice, alert systems prevent these attacks both by controls on sending messages at points where alerts are originated, and by having recipients of alerts verify that the alert was sent by an authorized source. The former type of control is implemented with local security on hosts from which alerts can be originated. The latter type is implemented by digital signatures on alert messages (using channel-based or object-based mechanisms). With an object-based mechanism, the signature value is encoded in a secure object. With a channel-based mechanism, the alert is "signed" by virtue of being sent over an authenticated, integrity-protected channel.
アラートシステムの最も重要なセキュリティ要件は、攻撃者が誤ったアラートをデバイスに送信できないようにする必要があることです。このような機能により、攻撃者は広範囲にパニックを引き起こす可能性があります。実際には、アラートシステムは、アラートが発信されたポイントでメッセージを送信することを制御することによって、およびアラートの受信者にアラートが許可されたソースによって送信されたことを確認させることによって、これらの攻撃を防ぎます。前者のタイプの制御は、アラートを発信できるホストのローカルセキュリティで実装されます。後者のタイプは、アラートメッセージのデジタル署名によって実装されます（チャネルベースまたはオブジェクトベースのメカニズムを使用）。オブジェクトベースのメカニズムでは、署名値は安全なオブジェクトにエンコードされます。チャネルベースのメカニズムでは、認証され、整合性が保護されたチャネルを介して送信されるため、アラートに「署名」されます。
Alerts typically reach end recipients via a series of intermediaries. For example, while a national weather service might originate a hurricane alert, it might first be delivered to a national gateway and then to network operators, who broadcast it to end subscribers.
アラートは通常、一連の仲介者を介して最終受信者に到達します。たとえば、全国の気象サービスがハリケーンアラートを発信するとしても、最初に全国のゲートウェイに配信され、次にネットワークオペレーターに配信されて、それをエンドサブスクライバーにブロードキャストします。
+------------+ +------------+ +------------+
| Originator | | Originator | | Originator |
+------------+ +------------+ +------------+
| . .
+-----------------+..................
|
V
+---------+
| Gateway |
+---------+
|
+------------+------------+
| |
V V
+---------+ +---------+
| Network | | Network |
+---------+ +---------+
| |
+------+-----+ +------+-----+
| | | |
V V V V
+--------+ +--------+ +--------+ +--------+
| Device | | Device | | Device | | Device |
+--------+ +--------+ +--------+ +--------+
Figure 4: Delivering an Emergency Alert
図4：緊急警報の配信
In order to verify alert signatures, recipients must be provisioned with the proper public keys for trusted alert authorities. This trust may be "piece-wise" along the path the alert takes. For example, the alert relays operated by networks might have a full set of certificates for all alert originators, while end devices may only trust their local alert relay. Or, devices might require that a device be signed by an authorized originator and by its local network's relay.
アラートの署名を確認するには、信頼できるアラート機関の適切な公開鍵を受信者にプロビジョニングする必要があります。この信頼は、警告がたどる経路に沿って「区分的」である場合があります。たとえば、ネットワークで運用されているアラートリレーには、すべてのアラートの発信者用の完全な証明書セットがあり、エンドデバイスはローカルのアラートリレーのみを信頼している場合があります。または、承認された発信者とローカルネットワークのリレーによる署名が必要なデバイスもあります。
This scenario creates a need for multiple signatures on alert documents, so that an alert can bear signatures from any or all of the entities that processed it along the path. In order to minimize complexity, these signatures should be "modular" in the sense that a new signature can be added without a need to alter or recompute previous signatures.
このシナリオでは、アラートドキュメントに複数の署名が必要になるため、パスに沿ってアラートを処理したエンティティのいずれかまたはすべてからのアラートに署名を付けることができます。複雑さを最小限に抑えるために、これらの署名は、以前の署名を変更または再計算する必要なしに新しい署名を追加できるという意味で「モジュラー」である必要があります。
The W3C Web Cryptography API defines a standard cryptographic API for the Web [WebCrypto]. If a browser exposes this API, then JavaScript provided as part of a Web page can ask the browser to perform cryptographic operations, such as digest, MAC, encryption, or digital signing.
W3C Web暗号化APIは、Webの標準的な暗号化API [WebCrypto]を定義しています。ブラウザーがこのAPIを公開する場合、Webページの一部として提供されるJavaScriptはブラウザーに、ダイジェスト、MAC、暗号化、デジタル署名などの暗号化操作を実行するように要求できます。
One of the key reasons to have the browser perform cryptographic operations is to avoid allowing JavaScript code to access the keying material used for these operations. For example, this separation would prevent code injected through a cross-site scripting (XSS) attack from reading and exfiltrating keys stored within a browser. While the malicious code could still use the key while running in the browser, this vulnerability can only be exercised while the malicious code is active in a user's browser.
ブラウザに暗号化操作を実行させる主な理由の1つは、JavaScriptコードがこれらの操作に使用されるキー情報にアクセスできないようにすることです。たとえば、この分離により、クロスサイトスクリプティング（XSS）攻撃を通じて挿入されたコードが、ブラウザー内に格納されたキーを読み取ったり、漏えいしたりすることを防ぎます。悪意のあるコードがブラウザで実行されている間もキーを使用する可能性はありますが、この脆弱性は、ユーザーのブラウザで悪意のあるコードがアクティブになっているときにのみ実行できます。
However, the Web Cryptography API also provides a key export functionality, which can allow JavaScript to extract a key from the API in wrapped form. For example, JavaScript code might provide a public key for which the corresponding private key is held by another device. The wrapped key provided by the API could then be used to safely transport the key to the new device. While this could potentially allow malicious code to export a key, the need for an explicit export operation provides a control point, allowing for user notification or consent verification.
ただし、Web暗号化APIはキーエクスポート機能も提供します。これにより、JavaScriptはAPIからキーをラップされた形式で抽出できます。たとえば、JavaScriptコードは、対応する秘密キーが別のデバイスによって保持されている公開キーを提供する場合があります。 APIによって提供されるラップされたキーを使用して、キーを新しいデバイスに安全に転送できます。これにより、悪意のあるコードがキーをエクスポートできる可能性がありますが、明示的なエクスポート操作が必要なため、ユーザーに通知したり同意を確認したりできるコントロールポイントが提供されます。
The Web Cryptography API also allows browsers to impose limitations on the usage of the keys it handles. For example, a symmetric key might be marked as usable only for encryption, and not for MAC. When a key is exported in wrapped form, these attributes should be carried along with it.
また、Web暗号化APIを使用すると、ブラウザーは、それが処理するキーの使用法に制限を課すことができます。たとえば、対称キーは、MACではなく、暗号化にのみ使用可能としてマークされる場合があります。キーがラップされた形式でエクスポートされる場合、これらの属性も一緒に運ばれる必要があります。
The Web Cryptography API thus requires formats to express several forms of keys. Obviously, the public key from an asymmetric key pair can be freely imported to and exported from the browser, so there needs to be a format for public keys. There is also a need for a format to express private keys and symmetric keys. For non-public keys, the primary need is for a wrapped form, where the confidentiality and integrity of the key is assured cryptographically; these protections should also apply to any attributes of the key. It may also be useful to define a direct, unwrapped format for use within a security boundary.
したがって、Web暗号化APIでは、いくつかの形式のキーを表現するためのフォーマットが必要です。明らかに、非対称キーペアの公開キーはブラウザに自由にインポートおよびエクスポートできるため、公開キーの形式が必要です。秘密鍵と対称鍵を表現するためのフォーマットも必要です。非公開鍵の場合、主な必要性は、鍵の機密性と完全性が暗号で保証されるラップされたフォームです。これらの保護は、キーのすべての属性にも適用されます。また、セキュリティ境界内で使用するための直接のラップされていない形式を定義することも役立ちます。
This section describes use cases for constrained devices as defined in [CONSTRAINED]. Typical issues with this type of device are limited memory, limited power supply, low processing power, and severe message size limitations for the communication protocols.
このセクションでは、[CONSTRAINED]で定義されている制約付きデバイスの使用例について説明します。このタイプのデバイスの一般的な問題は、メモリの制限、電源の制限、処理能力の低下、通信プロトコルのメッセージサイズの制限です。
Suppose a small, low power device maker has decided on using the output of the JOSE working group as their encryption and authentication framework. The device maker has a limited budget for both gates and power. For this reason there are a number of short cuts and design decisions that have been made in order to minimize these needs.
小規模な低電力デバイスメーカーが、暗号化および認証フレームワークとしてJOSEワーキンググループの出力を使用することを決定したとします。デバイスメーカーは、ゲートと電力の両方について限られた予算しか持っていません。このため、これらのニーズを最小限に抑えるために、多くのショートカットと設計上の決定が行われています。
The design team has determined that the use of MACs is going to be sufficient to provide the necessary authentication. However, although a MAC is going to be used, they do not want to use a single long-term shared secret. Instead, they have adopted the following proposal for computing a shared secret that can be validated:
設計チームは、必要な認証を提供するにはMACの使用で十分であると判断しました。ただし、MACを使用する予定ですが、長期的な共有秘密を1つ使用することは望んでいません。代わりに、検証可能な共有秘密を計算するために次の提案を採用しました。
o An Elliptic-Curve Diffie-Hellman (ECDH) key pair is generated for the device at the time of manufacturing. (Or, as part of the configuration process during installation.)
o 製造時にデバイスの楕円曲線Diffie-Hellman（ECDH）鍵ペアが生成されます。 （または、インストール時の構成プロセスの一部として。）
o An ECDH public key for the controller is configured at the time of configuration.
o コントローラーのECDH公開鍵は、構成時に構成されます。
o The configuration system performs the ECDH computation and configures the device with the resulting shared secret. This process eliminates the need for the device to be able to perform the required ECDH processing. The security requirements on protecting this computed shared secret are the same as the requirements on protecting the private ECDH key.
o 構成システムはECDH計算を実行し、結果の共有秘密を使用してデバイスを構成します。このプロセスにより、デバイスが必要なECDH処理を実行できるようにする必要がなくなります。この計算された共有シークレットを保護するためのセキュリティ要件は、プライベートECDHキーを保護するための要件と同じです。
o A counter and an increment value are configured onto the device.
o カウンターと増分値がデバイスに構成されます。
o When a message is to be sent by the device, the counter is incremented and a new MAC key is computed from the ECDH secret and the counter value. A custom Key Derivation Function (KDF) based on AES-CBC is used to derive the required MAC key. The MAC key is then used to compute the MAC value for the message.
o メッセージがデバイスによって送信される場合、カウンターがインクリメントされ、新しいMACキーがECDHシークレットとカウンター値から計算されます。 AES-CBCに基づくカスタム鍵導出関数（KDF）を使用して、必要なMAC鍵を導出します。次に、MACキーを使用してメッセージのMAC値を計算します。
In a similar manner, the KDF function can be used to compute an Authenticated Encryption with Associated Data (AEAD) algorithm key when the system needs to provide confidentiality for the message. The controller, being a larger device, will perform the ECDH step and use a random number generator to generate the sender nonce value.
同様に、システムがメッセージの機密性を提供する必要がある場合、KDF関数を使用して、関連データ付き認証暗号化（AEAD）アルゴリズムキーを計算できます。コントローラーはより大きなデバイスであり、ECDHステップを実行し、乱数ジェネレーターを使用して送信側のnonce値を生成します。
This use case deals with constrained devices of class C0/C1 (see [CONSTRAINED]). These devices communicate using RESTful requests and responses transferred using the Constrained Application Protocol [CoAP]. To simplify matters, all communication is assumed to be unicast; i.e., these security measures don't cover multicast or broadcast.
このユースケースは、クラスC0 / C1の制約されたデバイスを扱います（[制約]を参照）。これらのデバイスは、制約付きアプリケーションプロトコル[CoAP]を使用して転送されたRESTful要求および応答を使用して通信します。問題を簡単にするために、すべての通信はユニキャストであると想定されています。つまり、これらのセキュリティ対策はマルチキャストやブロードキャストには対応していません。
In this type of setting, it may be too costly to use session-based security (e.g., to run a 4-pass authentication protocol) since receiving and in particular sending consumes a lot of power, especially for wireless devices. Therefore, to just secure the CoAP payload by replacing a plaintext payload of a request or response with a JWE object is an important alternative solution, which allows a trade-off between protection (the CoAP headers are not protected) and performance.
このタイプの設定では、特にワイヤレスデバイスの場合、受信および特に送信に多くの電力が消費されるため、セッションベースのセキュリティを使用する（4パス認証プロトコルを実行するなど）にはコストがかかりすぎる場合があります。したがって、要求または応答のプレーンテキストペイロードをJWEオブジェクトで置き換えることによってCoAPペイロードを保護することは、保護（CoAPヘッダーは保護されない）とパフォーマンスの間のトレードオフを可能にする重要な代替ソリューションです。
In a simple setting, consider the payload of a CoAP GET response from a sensor type device. The information in a sensor reading may be privacy or business sensitive and needs both integrity protection and encryption.
簡単な設定で、センサータイプデバイスからのCoAP GET応答のペイロードを検討します。センサーの読み取り値の情報はプライバシーまたはビジネス上の機密情報である可能性があり、整合性保護と暗号化の両方が必要です。
However, some sensor readings are very short, say, a few bytes, and in this case, default encryption and integrity protection algorithms (such as 128-bit AES-CBC with HMAC_SHA256) may cause a dramatic expansion of the payload, even disregarding JWE headers.
ただし、いくつかのセンサーの読み取り値は非常に短く、たとえば数バイトであり、この場合、デフォルトの暗号化および整合性保護アルゴリズム（HMAC_SHA256を使用した128ビットAES-CBCなど）は、JWEを無視しても、ペイロードを劇的に拡張する可能性がありますヘッダー。
Also, the value of certain sensor readings may decline rapidly, e.g., traffic or environmental measurements, so it must be possible to reduce the security overhead.
また、特定のセンサーの読み取り値（トラフィックや環境の測定値など）が急速に低下する可能性があるため、セキュリティのオーバーヘッドを減らすことが可能でなければなりません。
This leads to the following requirements that could be covered by specific JWE/JWS profiles:
これにより、特定のJWE / JWSプロファイルで対応できる次の要件が発生します。
o The size of the secure object shall be as small as possible. Receiving an object may cost orders of magnitude more in terms of power than performing, say, public key cryptography on the object, in particular in a wireless setting.
o 安全なオブジェクトのサイズはできるだけ小さくする必要があります。オブジェクトを受信すると、特にワイヤレス設定で、オブジェクトに対して公開鍵暗号化を実行するよりも、電力の点で桁違いにコストがかかる場合があります。
o Integrity protection: The object shall be able to support integrity protection, i.e., have a field containing a digital signature, both public key signatures and keyed MACs shall be supported.
o 完全性保護：オブジェクトは完全性保護をサポートできる必要があります。つまり、デジタル署名を含むフィールドがあり、公開鍵署名と鍵付きMACの両方がサポートされます。
o Encryption: The object shall be able to support encryption as an optional addition to integrity protection. It shall be possible to exclude certain fields from encryption, which are needed before verifying integrity or decrypting the object.
o 暗号化：オブジェクトは、完全性保護へのオプションの追加として暗号化をサポートできる必要があります。完全性を検証したりオブジェクトを復号化する前に必要な特定のフィールドを暗号化から除外することが可能です。
o Cipher suites: It should be possible to support a variety of cipher suites to support the constrained devices' use cases. For example:
o 暗号スイート：制約されたデバイスの使用例をサポートするために、さまざまな暗号スイートをサポートできるはずです。例えば：
* Block ciphers with block sizes of, e.g., 96 bits, in addition to the standard 128 bits.
* 標準の128ビットに加えて、ブロックサイズが96ビットなどのブロック暗号。
* Modes of operation for block ciphers that do not expand the message size to a block boundary, such as AES-GCM.
* AES-GCMなど、メッセージサイズをブロック境界に拡張しないブロック暗号の動作モード。
* Cipher suites that support combined encryption and MAC calculation (i.e., AEAD modes for block ciphers).
* 暗号化とMAC計算の組み合わせをサポートする暗号スイート（つまり、ブロック暗号のAEADモード）。
This section summarizes the requirements from the above use cases and lists further requirements not directly derived from the above use cases. There are also some constraints that are not hard requirements but that are still desirable properties for the JOSE system to have.
このセクションでは、上記のユースケースの要件をまとめ、上記のユースケースから直接派生していないその他の要件を示します。厳しい要件ではないが、JOSEシステムが持つべき望ましい特性であるいくつかの制約もあります。
F1 Define formats for secure objects that provide the following security properties:
F1次のセキュリティプロパティを提供するセキュアオブジェクトのフォーマットを定義します。
* Digital signature (integrity/authentication under an asymmetric key pair)
* デジタル署名（非対称鍵ペアでの完全性/認証）
* Message authentication (integrity/authentication under a symmetric key)
* メッセージ認証（対称鍵での完全性/認証）
* Authenticated encryption
* 認証された暗号化
F2 Define a format for public keys and private keys for asymmetric cryptographic algorithms, with associated attributes, including a wrapped form for private keys.
F2秘密キーのラップされたフォームを含む、関連する属性を使用して、非対称暗号アルゴリズムの公開キーと秘密キーの形式を定義します。
F3 Define a format for symmetric keys with associated attributes, allowing for both wrapped and unwrapped keys.
F3関連付けられた属性を持つ対称キーの形式を定義し、ラップされたキーとラップされていないキーの両方を使用できるようにします。
F4 Define a JSON serialization for each of the above objects. An object in this encoding must be valid according to the JSON ABNF syntax [RFC7159].
F4上記の各オブジェクトのJSONシリアル化を定義します。このエンコーディングのオブジェクトは、JSON ABNF構文[RFC7159]に従って有効である必要があります。
F5 Define a compact, URL-safe text serialization for the encrypted and signed object formats.
F5暗号化および署名されたオブジェクト形式に対して、コンパクトでURLセーフなテキストのシリアル化を定義します。
F6 Allow for attributes associated to wrapped keys to be bound to them cryptographically.
F6ラップされたキーに関連付けられた属性を暗号化してそれらにバインドできるようにします。
F7 Allow for wrapped keys to be separated from a secure object that uses a symmetric key. In such cases, cryptographic components of the secure object other than the wrapped key (e.g., ciphertext, MAC values) must be independent of the wrapped form of the key. For example, if an encrypted object is prepared for multiple recipients, then only the wrapped key may vary, not the ciphertext.
F7ラップされた鍵を、対称鍵を使用する安全なオブジェクトから分離できるようにします。このような場合、ラップされた鍵以外のセキュアオブジェクトの暗号化コンポーネント（暗号文、MAC値など）は、鍵のラップされた形式とは無関係である必要があります。たとえば、暗号化されたオブジェクトが複数の受信者に対して準備されている場合、ラップされるキーのみが異なり、暗号文は異なります。
F8 Do not impose more overhead than is required to meet the requirements in this document, especially when a large amount of application content is being protected.
F8特に大量のアプリケーションコンテンツが保護されている場合は、このドキュメントの要件を満たすために必要なオーバーヘッドよりも多くのオーバーヘッドを課さないでください。
S1 Provide mechanisms to avoid repeated use of the same symmetric key for encryption or MAC computation. Instead, long-lived keys should be used only for key wrapping, not for direct encryption/ MAC. It should be possible to use any of the key management techniques provided in CMS [RFC5652]:
S1暗号化またはMAC計算に同じ対称鍵を繰り返し使用することを回避するメカニズムを提供します。代わりに、存続期間の長い鍵は、直接暗号化/ MACではなく、鍵のラッピングにのみ使用する必要があります。 CMS [RFC5652]で提供される鍵管理技術のいずれかを使用することが可能であるべきです：
* Key transport (wrapping for a public key)
* 鍵のトランスポート（公開鍵のラッピング）
* Key encipherment (wrapping for a symmetric key)
* 鍵の暗号化（対称鍵のラッピング）
* Key agreement (wrapping for a Diffie-Hellman (DH) public key)
* 鍵合意（Diffie-Hellman（DH）公開鍵のラッピング）
* Password-based encryption (wrapping under a key derived from a password)
* パスワードベースの暗号化（パスワードから派生したキーでのラップ）
S2 Where long-lived symmetric keys are used directly for cryptographic operations (i.e., where requirement S1 is not met), provide deployment guidance on key management practices, such as the need to limit key lifetimes.
S2長期間有効な対称キーが暗号化操作に直接使用される場合（つまり、要件S1が満たされない場合）、キーの有効期間を制限する必要性など、キー管理の実践に関する導入ガイダンスを提供します。
S3 Use cryptographic algorithms in a manner compatible with major validation processes. For example, if typical validation standards allow algorithm A to be used for purpose X but not purpose Y, then JOSE should not recommend using algorithm A for purpose Y.
S3主要な検証プロセスと互換性のある方法で暗号アルゴリズムを使用します。たとえば、一般的な検証標準でアルゴリズムAを目的Xに使用できるが目的Yには使用できない場合、JOSEはアルゴリズムAを目的Yに使用することを推奨しません。
S4 Support operation with or without pre-negotiation. It must be possible to create or process secure objects without any configuration beyond key provisioning. If it is possible for keys to be derived from application context, it must be possible for a recipient to recognize when it does not have the appropriate key.
S4事前交渉ありまたはなしの操作をサポートします。キーのプロビジョニング以外の構成を行わなくても、安全なオブジェクトを作成または処理できる必要があります。キーがアプリケーションコンテキストから派生できる場合、適切なキーがない場合に受信者がそれを認識できる必要があります。
D1 Maximize compatibility with the W3C Web Crypto specifications, e.g., by coordinating with the Web Crypto working group to encourage alignment of algorithms and algorithm identifiers.
D1 W3C Web Crypto仕様との互換性を最大化します。たとえば、Web Cryptoワーキンググループと調整して、アルゴリズムとアルゴリズム識別子の調整を促進します。
D2 Avoid JSON canonicalization to the extent possible. That is, all other things being equal, techniques that rely on fixing a serialization of an object (e.g., by encoding it with base64url) are preferred over those that require converting an object to a canonical form.
D2 JSONの正規化は可能な限り避けてください。つまり、他のすべての条件が同じである場合、オブジェクトのシリアル化の修正に依存する手法（base64urlでエンコードするなど）は、オブジェクトを標準形式に変換する必要がある手法よりも優先されます。
D3 Maximize the extent to which the inputs and outputs of JOSE cryptographic operations can be controlled by the applications, as opposed to involving processing specific to JOSE. This allows JOSE the flexibility to address the needs of many cryptographic protocols. For example, in some cases, it might allow JOSE objects to be translated to legacy formats such as CMS without the need for re-encryption or re-signing.
D3 JOSE固有の処理を伴うのではなく、JOSE暗号操作の入力と出力をアプリケーションで制御できる範囲を最大化します。これにより、JOSEは多くの暗号化プロトコルのニーズに対応する柔軟性を実現します。たとえば、場合によっては、再暗号化や再署名を行うことなく、JOSEオブジェクトをCMSなどのレガシー形式に変換できる場合があります。
The primary focus of this document is the requirements for a JSON-based secure object format. At the level of general security considerations for object-based security technologies, the security considerations for this format are the same as for CMS [RFC5652]. The primary difference between the JOSE format and CMS is that JOSE is based on JSON, which does not have a canonical representation. The lack of a canonical form means that it is difficult to determine whether two JSON objects represent the same information, which could lead to vulnerabilities in some usages of JOSE.
このドキュメントの主な焦点は、JSONベースの安全なオブジェクト形式の要件です。オブジェクトベースのセキュリティ技術の一般的なセキュリティの考慮事項のレベルでは、この形式のセキュリティの考慮事項はCMS [RFC5652]の場合と同じです。 JOSE形式とCMSの主な違いは、JOSEがJSONに基づいていることです。これには、正規表現がありません。正規の形式がないことは、2つのJSONオブジェクトが同じ情報を表しているかどうかを判断することが難しいことを意味し、JOSEの一部の使用で脆弱性につながる可能性があります。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007.
[RFC4949] Shirey、R。、「インターネットセキュリティ用語集、バージョン2」、RFC 4949、2007年8月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、2011年3月。
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, September 2012.
[RFC6708]キーゼル、S。、プレビディ、S。、スティームリング、M。、ウウンディ、R.、Y。ヤン、「アプリケーションレイヤートラフィック最適化（ALTO）要件」、RFC 6708、2012年9月。
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012.
[RFC6749] Hardt、D。、「The OAuth 2.0 Authorization Framework」、RFC 6749、2012年10月。
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014.
[RFC7159]ブレイ、T。、「JavaScript Object Notation（JSON）データ交換フォーマット」、RFC 7159、2014年3月。
[W3C.REC-xml] Bray, T., Maler, E., Paoli, J., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126/>.
[W3C.REC-xml] Bray、T.、Maler、E.、Paoli、J。、およびC. Sperberg-McQueen、「Extensible Markup Language（XML）1.0（Fifth Edition）」、W3C勧告、2008年11月、< http://www.w3.org/TR/2008/REC-xml-20081126/>。
[WebCrypto] Dahl, D. and R. Sleevi, "Web Cryptography API", W3C Working Draft, January 2013, <http://www.w3.org/TR/2013/WD-WebCryptoAPI-20130108/>.
[WebCrypto] Dahl、D。、およびR. Sleevi、「Web Cryptography API」、W3Cワーキングドラフト、2013年1月、<http://www.w3.org/TR/2013/WD-WebCryptoAPI-20130108/>。
[ALERT-REQ] Schulzrinne, H., Norreys, S., Rosen, B., and H. Tschofenig, "Requirements, Terminology and Framework for Exigent Communications", Work in Progress, March 2012.
[ALERT-REQ] Schulzrinne、H.、Norreys、S.、Rosen、B。、およびH. Tschofenig、「要件、用語、および緊急通信のフレームワーク」、作業中、2012年3月。
[ALTO] Alimi, R., Ed., Penno, R., Ed., and Y. Yang, Ed., "ALTO Protocol", Work in Progress, March 2014.
[ALTO] Alimi、R。、編、Penno、R。、編、Y。Yang、編、「ALTOプロトコル」、Work in Progress、2014年3月。
[CAP] Botterell, A. and E. Jones, "Common Alerting Protocol, v1.1", OASIS Standard CAP-V1.1, October 2005, <http://www.oasis-open.org/committees/download.php/15135/ emergency-CAPv1.1-Corrected_DOM.pdf>.
[CAP] Botterell、A。およびE. Jones、「Common Alerting Protocol、v1.1」、OASIS Standard CAP-V1.1、2005年10月、<http://www.oasis-open.org/committees/download。 php / 15135 / emergency-CAPv1.1-Corrected_DOM.pdf>。
[CONSTRAINED] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained Node Networks", Work in Progress, March 2014.
[制約] Bormann、C.、Ersue、M。、およびA. Keranen、「制約付きノードネットワークの用語」、進行中の作業、2014年3月。
[CoAP] Shelby, Z., Hartke, K., and C. Bormann, "Constrained Application Protocol (CoAP)", Work in Progress, June 2013.
[CoAP] Shelby、Z.、Hartke、K.、およびC. Bormann、「Constrained Application Protocol（CoAP）」、Work in Progress、2013年6月。
[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)", ITU-T Recommendation X.690, July 2002.
[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）」、ITU-T勧告X .690、2002年7月。
[JWA] Jones, M., "JSON Web Algorithms (JWA)", Work in Progress, March 2014.
[JWA] Jones、M。、「JSON Web Algorithms（JWA）」、Work in Progress、2014年3月。
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", Work in Progress, March 2014.
[JWE]ジョーンズ、M.、J。ヒルデブランド、「JSON Web Encryption（JWE）」、作業中、2014年3月。
[JWK] Jones, M., "JSON Web Key (JWK)", Work in Progress, March 2014.
[JWK]ジョーンズ、M。、「JSON Web Key（JWK）」、作業中、2014年3月。
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", Work in Progress, March 2014.
[JWS] Jones、M.、Bradley、J。、およびN.崎村、「JSON Web Signature（JWS）」、Work in Progress、2014年3月。
[JWT-BEARER] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", Work in Progress, March 2014.
[JWT-BEARER]ジョーンズ、M。、キャンベル、B。、およびC.モルティモア、「OAuth 2.0クライアント認証および承認付与のためのJSON Web Token（JWT）プロファイル」、2014年3月、作業中。
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", Work in Progress, March 2014.
[JWT] Jones、M.、Bradley、J。、およびN.崎村、「JSON Web Token（JWT）」、Work in Progress、2014年3月。
[OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Maler, E., and R. Philpott, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", Oasis Standard, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf>.
[OASIS.saml-core-2.0-os] Cantor、S.、Kemp、J.、Maler、E。、およびR. Philpott、「OASIS Security Assertion Markup Language（SAML）V2.0のアサーションとプロトコル」、 Oasis Standard、2005年3月、<http://docs.oasis-open.org/security/saml/v2.0/ saml-core-2.0-os.pdf>。
[OpenID.Core] Bradley, J., de Medeiros, B., Jones, M., Mortimore, C., and N. Sakimura, "OpenID Connect Core 1.0", December 2013, <http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Core] Bradley、J.、de Medeiros、B.、Jones、M.、Mortimore、C.、N。Sakimura、「OpenID Connect Core 1.0」、2013年12月、<http://openid.net/ specs / openid-connect-core-1_0.html>。
[Persona] Mozilla Developer Network, "Mozilla Persona", April 2013, <https://developer.mozilla.org/en-US/docs/Persona>.
[ペルソナ] Mozilla Developer Network、「Mozilla Persona」、2013年4月、<https://developer.mozilla.org/en-US/docs/Persona>。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207] Hoffman、P。、「Secure SMTP over Transport Layer SecurityのSMTPサービス拡張」、RFC 3207、2002年2月。
[RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)", RFC 3923, October 2004.
[RFC3923] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）のエンドツーエンドの署名とオブジェクト暗号化」、RFC 3923、2004年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, October 2012.
[RFC6750]ジョーンズ、M。およびD.ハート、「OAuth 2.0 Authorization Framework：Bearer Token Usage」、RFC 6750、2012年10月。
[SAML2] Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants", Work in Progress, March 2014.
[SAML2] Campbell、B.、Mortimore、C。、およびM. Jones、「OAuth 2.0クライアント認証および承認付与のためのSAML 2.0プロファイル」、2014年3月、作業中。
[W3C.xmldsig-core] Eastlake, D., Reagle, J., and D. Solo, "XML-Signature Syntax and Processing", W3C Recommendation, June 2008, <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>.
[W3C.xmldsig-core] Eastlake、D.、Reagle、J。、およびD. Solo、「XML-Signature Syntax and Processing」、W3C勧告、2008年6月、<http://www.w3.org/TR/ 2008 / REC-xmldsig-core-20080610 />。
[W3C.xmlenc-core] Eastlake, D. and J. Reagle, "XML Encryption Syntax and Processing", W3C Candidate Recommendation, December 2002, <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/>.
[W3C.xmlenc-core] Eastlake、D。およびJ. Reagle、「XML暗号化構文および処理」、W3C候補の推奨、2002年12月、<http://www.w3.org/TR/2002/REC-xmlenc- core-20021210 />。
[WS-Federation] Goodner, M., Kaler, C., McIntosh, M., and A. Nadalin, "Web Services Federation Language (WS-Federation) Version 1.2", Oasis Standard, May 2009, <http://docs.oasis-open.org/ wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html>.
[WS-Federation] Goodner、M.、Kaler、C.、McIntosh、M。、およびA. Nadalin、「Web Services Federation Language（WS-Federation）Version 1.2」、Oasis Standard、2009年5月、<http：// docs.oasis-open.org/ wsfed / federation / v1.2 / os / ws-federation-1.2-spec-os.html>。
[XMPP-E2E] Miller, M., "End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP)", Work in Progress, June 2013.
[XMPP-E2E] Miller、M。、「Extensible Messaging and Presence Protocol（XMPP）のエンドツーエンドのオブジェクト暗号化と署名」、作業中、2013年6月。
Thanks to Matt Miller for discussions related to the 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.
XMPPのエンドツーエンドのセキュリティモデルに関する議論についてはMatt Millerに、セキュリティトークンとXMLセキュリティに関する考慮事項についてはMike Jonesに感謝します。対称キーを表現し、それらに属性をバインドする必要性を高めてくれたMark Watsonに感謝します。制約のあるデバイスの使用例を提供してくれたLudwig Seitzに感謝します。
Author's Address
著者のアドレス
Richard Barnes Mozilla 331 E. Evelyn Ave. Mountain View, CA 94041 US
リチャードバーンズMozilla 331 E. Evelyn Ave. Mountain View、CA 94041 US
EMail: rlb@ipv.sx