| Network Working Group | T. Looker, Ed. |
| Internet-Draft | Mattr |
| Intended status: Standards Track | January 15, 2020 |
| Expires: July 18, 2020 |
JSON Web Message
draft-looker-jwm-01
JSON Web Message (JWM) is a flexible way to encode application-level messages in JSON for transfer over a variety of transport protocols. JWMs use JSON Web Encryption (JWE) to protect integrity, achieve confidentiality, and achieve repudiable authentication; alternatively or in addition, they use JSON Web Signatures (JWS) to associate messages with a non-repudiable digital signature.
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 https://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 July 18, 2020.
Copyright (c) 2020 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 (https://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.
JSON Web Message (JWM) is a flexible way to encode application-level messages in JSON for transfer over a variety of transport protocols. JWMs use JSON Web Encryption (JWE) to protect integrity, achieve confidentiality, and achieve repudiable authentication; alternatively or in addition, they use JSON Web Signatures (JWS) to associate messages with a non-repudiable digital signature. JWMs are inspired by JWTs [RFC7519]; more details about this relationship are documented in Section 2.1.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 RFC 8174 when, and only when, they appear in all capitals, as shown here.
The terms "JSON Web Signature (JWS)", "Base64url Encoding", "Header Parameter", "JOSE Header", "JWS Payload", "JWS Signature", "JWS Compact Serialization" and "JWS JSON Serialization" are defined by the JWS specification [RFC7515].
The terms "JSON Web Encryption (JWE)", "JWE Compact Serialization" and "JWE JSON Serialization" are defined by the JWE specification [RFC7516].
The terms "StringOrURI", "NumericDate" are defined by the JWT specification [RFC7519].
The following terms are defined by this specification:
JWMs conceptually share parallels to JWTs:
JWMs also deviate from JWTs in important ways that prevent a converged specification.
In the spirit of specification re-use and promoting ease of understanding, this specification's structure is inspired by [RFC7519].
The following example JOSE Header declares that the object is a JWM, and the JWM is a JWS that has been digitally signed using ECDSA with the curve p-256 and SHA-256 as the hashing algorithm ("ES256"). The signer of the JWM has indicated that the key used to sign the JWM is identified by "Ef1sFuyOozYm3CEY4iCdwqxiSyXZ5Br-eUDdQXk6jaQ" (with line breaks for display purposes only):
{"typ":"JWM",
"kid":"Ef1sFuyOozYm3CEY4iCdwqxiSyXZ5Br-eUDdQXk6jaQ",
"alg":"ES256"}
Base64url encoding the octets of the UTF-8 representation of the JOSE Header yields this encoded JOSE Header value (with line breaks for display purposes only):
eyJ0eXAiOiJKV00iLCJraWQiOiJFZjFzRnV5T296WW0zQ0VZNGlDZHdxeGlTeVhaNUJyLWVVRGRRWGs2amFRIiwiYWxnIjoiRVMyNTYifQ
The following is an example of a JWM Attributes Set (with line breaks for display purposes only):
{"id":"urn:uuid:ef5a7369-f0b9-4143-a49d-2b9c7ee51117",
"type":"hello-world-message-type",
"from":"urn:uuid:8abdf5fb-621e-4cf5-a595-071bc2c91d82",
"expires_time":1516239022,
"created_time":1516269022,
"body":{"message": "Hello world!"}}
Base64url encoding the octets of the UTF-8 the JWS Payload yields this encoded JWS Payload (with line breaks for display purposes only):
eyJpZCI6InVybjp1dWlkOmVmNWE3MzY5LWYwYjktNDE0My1hNDlkLTJiOWM3ZWU1MTExNyIsInR5cGUiOiJoZWxsby13b3JsZC1tZXNzYWdlLXR5cGUiLCJmcm9tIjoidXJuOnV1aWQ6OGFiZGY1ZmItNjIxZS00Y2Y1LWE1OTUtMDcxYmMyYzkxZDgyIiwiZXhwaXJ5IjoxNTE2MjM5MDIyLCJ0aW1lX3N0YW1wIjoxNTE2MjY5MDIyLCJib2R5Ijp7Im1lc3NhZ2UiOiJIZWxsbyB3b3JsZCEifX0
Computing the signature of the encoded JOSE Header and encoded JWS Payload with the ECDSA with the curve p-256 and SHA-256 as the hashing algorithm and base64url encoding the value in the manner specified in [RFC7515] yields this encoded JWS Signature:
UDE7NsEJyhiewrX2_Z9OdIdB2ZREauoPoUAKdEmW72d8H_ivkjC1p7G16WHunBMq1zFkanINTil3-H1FlhbzsQ
Compact Serialization (with line breaks for display purposes only):
eyJ0eXAiOiJKV00iLCJraWQiOiJFZjFzRnV5T296WW0zQ0VZNGlDZHdxeGlTeVhaNUJyLWVVRGRRWGs2amFRIiwiYWxnIjoiRVMyNTYifQ
.
eyJpZCI6InVybjp1dWlkOmVmNWE3MzY5LWYwYjktNDE0My1hNDlkLTJiOWM3ZWU1MTExNyIsInR5cGUiOiJoZWxsby13b3JsZC1tZXNzYWdlLXR5cGUiLCJmcm9tIjoidXJuOnV1aWQ6OGFiZGY1ZmItNjIxZS00Y2Y1LWE1OTUtMDcxYmMyYzkxZDgyIiwiZXhwaXJ5IjoxNTE2MjM5MDIyLCJ0aW1lX3N0YW1wIjoxNTE2MjY5MDIyLCJib2R5Ijp7Im1lc3NhZ2UiOiJIZWxsbyB3b3JsZCEifX0
.
UDE7NsEJyhiewrX2_Z9OdIdB2ZREauoPoUAKdEmW72d8H_ivkjC1p7G16WHunBMq1zFkanINTil3-H1FlhbzsQ
JSON Serialization: (with line breaks for display purposes only):
{
"payload": "eyJpZCI6InVybjp1dWlkOmVmNWE3MzY5LWYwYjktNDE0My1hNDl
kLTJiOWM3ZWU1MTExNyIsInR5cGUiOiJoZWxsby13b3JsZC1tZXNzYWdlLXR5cG
UiLCJmcm9tIjoidXJuOnV1aWQ6OGFiZGY1ZmItNjIxZS00Y2Y1LWE1OTUtMDcxY
mMyYzkxZDgyIiwiZXhwaXJ5IjoxNTE2MjM5MDIyLCJ0aW1lX3N0YW1wIjoxNTE2
MjY5MDIyLCJib2R5Ijp7Im1lc3NhZ2UiOiJIZWxsbyB3b3JsZCEifX0",
"signatures": [
{
"protected": "eyJ0eXAiOiJKV00iLCJraWQiOiJFZjFzRnV5T296WW0zQ
0VZNGlDZHdxeGlTeVhaNUJyLWVVRGRRWGs2amFRIiwiYWxnIjoiRVMyNTYi
fQ",
"signature": "rwhHoGJZRyLliF2jPqGXMddBLWlJls4XqSO21GH2itlwh
3d3Zb2jAtqA93s9Lb6ktXoxqHxNy4Lbirtr3pCHQA"
}
]
}
The following example JOSE Header declares that the object is a JWM, and the JWM is a JWE that has been encrypted using AES in Galois/Counter Mode (GCM) with 256-bit for content encryption (with line breaks for display purposes only):
{
"typ":"JWM",
"enc":"A256GCM"
}
The following JOSE Header declares that the sender has used Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES+A256KW) for key agreement with AES based key wrapping to encrypt the content encryption key (CEK). The keys required to perform the opposite Diffie-Helman are identified by the key id of "PGoXzs0NWaR_meKgTZLbEuDoSVTaFuyrbWI7V9dpjCg" along with the ephemeral public key declared by the JSON object "epk". The encrypted CEK is represented by the "encrypted_key" field (with line breaks for display purposes only):
{
"kid": "PGoXzs0NWaR_meKgTZLbEuDoSVTaFuyrbWI7V9dpjCg",
"alg": "ECDH-ES+A256KW",
"epk": {
"kty": "EC",
"crv": "P-256",
"x": "-Nh7ShRB_xaCBZRdIiVCul3SoR0Yw4TGEQqqGij1vJs",
"y": "9tLx81PMfQkrOw8yuI2YwI0o7MtNzaCGfCBbZBW5YrM"
}
}
Because the JWE features a single recipient, the two JOSE headers are combined into a single JOSE header, that can be represented as the following.
{
"typ": "JWM",
"enc": "A256GCM",
"kid": "PGoXzs0NWaR_meKgTZLbEuDoSVTaFuyrbWI7V9dpjCg",
"alg": "ECDH-ES+A256KW",
"epk": {
"kty": "EC",
"crv": "P-256",
"x": "-Nh7ShRB_xaCBZRdIiVCul3SoR0Yw4TGEQqqGij1vJs",
"y": "9tLx81PMfQkrOw8yuI2YwI0o7MtNzaCGfCBbZBW5YrM"
}
}
The following is an example of a JWM Attributes Set (with line breaks for display purposes only):
{"id":"urn:uuid:ef5a7369-f0b9-4143-a49d-2b9c7ee51117",
"type":"hello-world-message-type",
"from":"urn:uuid:8abdf5fb-621e-4cf5-a595-071bc2c91d82",
"expires_time":1516239022,
"created_time":1516269022,
"body":{"message": "Hello world!"}}
Encrypting the above plaintext for the recipient yields the following ciphertext in base64url form.
awEW6ssGMbQxmvv4FPf0smom4QvPNrgLaxFiMMRXmUTgcs6mLcSJDbUhwLfGfnEeu2a0bcGLRt7tTuQij5RBIe6sflhIgOjpr3VAHdZBYJbF Jg9dCMW_hVk0iLytmFV5BhvqXUXDAckwwTU41PcS2_qO5uqdIe24teP8Bd_IbVeVnaUwrEEBGJvxYDTefdZ4gryrzKFsLLBD5Fr9TsCFEddg0RL xaXFGX1YT8Jm6Ahm-jd6Ol9qIpWx-8PMaFcZl7h4sPiAGVPiaaCyzTsMy8KW0Nmz3cEFqjEm4Ipc
Composing this information into a valid JWE leads to the following possible expressions
Compact Serialization (with line breaks for display purposes only):
eyJ0eXAiOiJKV00iLCJlbmMiOiJBMjU2R0NNIiwia2lkIjoiUEdvWHpzME5XYVJfbWVLZ1RaTGJFdURvU1ZUYUZ1eXJiV0k3VjlkcGpDZyIsImFsZyI6I kVDREgtRVMrQTI1NktXIiwiZXBrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoiZGdMdy1wOG5kZ0xRSmhZeWhUaGhpVDRhbmJlRjhaak1MYXRxR 2dXVGxHSSIsInkiOiJ3MkNfcjUzekdUdVZscDhQVndFZjViWWI0TWo4bXVjNTVtMHh6VkVMN1o0In19
.
rAiydPRY_cciOmaQ-tnNiacHWn2Z2GqDgf0FcG4nK2L_KsPd1V1OSA
.
EIY6u2ahL0MI28ah
.
awEW6ssGMbQxmvv4FPf0smom4QvPNrgLaxFiMMRXmUTgcs6mLcSJDbUhwLfGfnEeu2a0bcGLRt7tTuQij5RBIe6sflhIgOjpr3VAHdZBYJbF Jg9dCMW_hVk0iLytmFV5BhvqXUXDAckwwTU41PcS2_qO5uqdIe24teP8Bd_IbVeVnaUwrEEBGJvxYDTefdZ4gryrzKFsLLBD5Fr9TsCFEddg0RL xaXFGX1YT8Jm6Ahm-jd6Ol9qIpWx-8PMaFcZl7h4sPiAGVPiaaCyzTsMy8KW0Nmz3cEFqjEm4Ipc
.
fp_tT_6qsQK2d9szRAwWgA
JSON Serialization (with line breaks for display purposes only):
{
"protected": "eyJ0eXAiOiJKV00iLCJlbmMiOiJBMjU2R0NNIiwi
a2lkIjoiUEdvWHpzME5XYVJfbWVLZ1RaTGJFdURvU1ZUYUZ1eXJiV0
k3VjlkcGpDZyIsImFsZyI6IkVDREgtRVMrQTI1NktXIiwiZXBrIjp7
Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoiLU5oN1NoUkJfeG
FDQlpSZElpVkN1bDNTb1IwWXc0VEdFUXFxR2lqMXZKcyIsInkiOiI5
dEx4ODFQTWZRa3JPdzh5dUkyWXdJMG83TXROemFDR2ZDQmJaQlc1WX
JNIn19",
"recipients": [
{
"encrypted_key": "J1Fs9JaDjOT_5481ORQWfEZmHy7OjE3p
TNKccnK7hlqjxbPalQWWLg"
}
],
"iv": "u5kIzo0m_d2PjI4m",
"ciphertext": "qGuFFoHy7HBmkf2BaY6eREwzEjn6O_FnRoXj2H-
DAXo1PgQdfON-_1QbxtnT8e8z_M6Gown7s8fLtYNmIHAuixqFQnSA4
fdMcMSi02z1MYEn2JC-1EkVbWr4TqQgFP1EyymB6XjCWDiwTYd2xpK
oUshu8WW601HLSgFIRUG3-cK_ZSdFaoWosIgAH5EQ2ayJkRB_7dXuo
6_AYdIzMahvPz0n1yHHBlYBuYeR58V-x85ACeCGtzL2OptPa2TmWdA
9Bi1MK6TYGZKezc6rpCK_VRSnLXhFwa1C3T0QBes",
"tag": "doeAoagwJe9BwKayfcduiw"
}
The JWM Attributes Set represents a JSON object whose members are the attributes conveyed by the JWM. The Attribute Names within a JWM Attributes Set MUST be unique; JWM parsers MUST either reject JWMs with duplicate Attribute Names or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 ("The JSON Object") of ECMAScript 5.1 [ECMAScript].
The set of attributes that a JWM must contain to be considered valid is context dependent and is outside the scope of this specification. Specific applications of JWMs will require implementations to understand and process some attributes in particular ways. However, in the absence of such requirements, all attributes that are not understood by implementations MUST be ignored.
There are three classes of JWM Attribute Names: Registered Attribute Names, Public Attribute Names and Private Attribute Names.
The following Attribute Names are registered in the IANA "JSON Web Message Attributes" registry established by Section 7. None of the attributes defined below are intended to be mandatory to use or implement in all cases, but rather they provide a starting point for a set of useful, interoperable attributes. Applications using JWMs should define which specific Attributes they use and when they are required or optional.
The "id" attribute is used to define a unique identifier for a JWM. The "id" attribute value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to another JWM. The processing of this attribute is generally application specific. The "id" attribute value is a case-sensitive string containing a StringOrURI value. Use of this attribute is OPTIONAL.
The "type" attribute is used to define the type of the message. The processing of this attribute is generally application specific. The "type" attribute value is a case-sensitive string containing a StringOrURI value. The "type" attribute value can be used by applications to inform the structure and content of the "message body" and indicate the presence of other JWM attributes. Use of this attribute is OPTIONAL.
The "body" attribute is used to define a location for application level message content. The "body" attribute value is a JSON object conforming to RFC 7159 [RFC7159]. The processing of this attribute is generally application specific. Use of this attribute is OPTIONAL.
The "to" attribute is used to define the intended recipients of the JWM. The "to" attribute value is an array of case-sensitive strings each containing a StringOrURI value. The processing of this attribute is generally application specific. Use of this attribute is OPTIONAL.
The "from" attribute is used to define the sender of the JWM. The "from" attribute value is a case-sensitive string containing a StringOrURI value. The processing of this attribute is generally application specific. Use of this attribute is OPTIONAL.
The "thread_id" attribute is used to associate the JWM to a group of related messages often referred to as a thread. The "thread_id" attribute value is a case-sensitive string containing a StringOrURI value. The processing of this attribute is generally application specific. Use of this attribute is OPTIONAL.
The "created_time" attribute is used to define the time in which the message was created. The "created_time" attributes value MUST be a number containing a NumericDate value. The processing of this attribute is generally application specific. Use of this attribute is OPTIONAL.
The "expires_time" attribute is used to define the lifespan or lifetime of the JWM. The "expires_time" attributes value MUST be a number containing a NumericDate value. The processing of this attribute is generally application specific. Use of this attribute is OPTIONAL.
The "reply_url" attribute is used to define a url to which a response to the message can be sent. The "reply_url" attribute value is a case-sensitive string containing a StringOrURI value. The processing of this attribute is generally application specific. Use of this attribute is OPTIONAL.
The "reply_to" attribute is used to define who a response to the message should be sent to. The "reply_to" attribute value is a case-sensitive string containing an array of case-sensitive strings containing StringOrURI values. The processing of this attribute is generally application specific. Use of this attribute is OPTIONAL.
Attribute Names can be defined at will by those using JWMs. However, in order to prevent collisions, any new Attribute Name should either be registered in the IANA "JSON Web Message Attributes" registry established by Section 7 or be a Public Name: a value that contains a Collision-Resistant Name. In each case, the definer of the name or value needs to take reasonable precautions to make sure they are in control of the part of the namespace they use to define the Attribute Name.
A producer and consumer of a JWM MAY agree to use Attribute Names that are Private Names: names that are not Registered Attribute Names Section 3.1 or Public Attribute Names Section 3.2. Unlike Public Attribute Names, Private Attribute Names are subject to collision and should be used with caution.
For a JWM object, the members of the JSON object represented by the JOSE Header describe the cryptographic operations applied to the JWM and optionally, additional properties of the JWM. Depending upon whether the JWM is a JWS or JWE, the corresponding rules for the JOSE Header values apply.
This specification further specifies the use of the following header parameters in both the cases where the JWM is a JWS and where it is a JWE.
The "typ" (type) Header Parameter defined by [RFC7515] and [RFC7516] is used by JWM applications to declare the media type [IANA.MediaTypes] of this complete JWM. This is intended for use by the JWM application when values that are not JWMs could also be present in an application data structure that can contain a JWM object; the application can use this value to disambiguate among the different kinds of objects that might be present. It will typically not be used by applications when it is already known that the object is a JWM. This parameter is ignored by JWM implementations; any processing of this parameter is performed by the JWM application. If present, it is RECOMMENDED that its value be "JWM" to indicate that this object is a JWM. While media type names are not case sensitive, it is RECOMMENDED that "JWM" always be spelled using uppercase characters for compatibility with legacy implementations. Use of this Header Parameter is OPTIONAL.
The "cty" (content type) Header Parameter defined by [RFC7515] and [RFC7516] is used by this specification to convey structural information about the JWM.
In the normal case in which nested signing or encryption operations are not employed, the use of this Header Parameter is NOT RECOMMENDED. In the case that nested signing or encryption is employed, this Header Parameter MUST be present; in this case, the value MUST be "JWM", to indicate that a Nested JWM is carried in this JWM. While media type names are not case sensitive, it is RECOMMENDED that "JWM" always be spelled using uppercase characters for compatibility with legacy implementations.
In some applications using encrypted JWMs, it is useful to have an unencrypted representation of some attributes. This might be used, for instance, in application processing rules to determine whether and how to process the JWM before it is decrypted.
This specification allows Attributes present in the JWM Attributes Set to be replicated as JOSE Header Parameters in a JWM that is a JWE, as needed by the application. If such replicated attributes are present, the application receiving them SHOULD verify that their values are identical, unless the application defines other specific processing rules for these attributes. It is the responsibility of the application to ensure that only attributes that are safe to be transmitted in an unencrypted manner are replicated as JOSE Header Parameter values in the JWM.
To create a JWM, the following steps are performed. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.
When validating a JWM, the following steps are performed. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. If any of the listed steps fail, then the JWM MUST be rejected; that is, treated by the application as an invalid input.
Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWM can be successfully validated, unless the algorithms used in the JWM are acceptable to the application, it SHOULD reject the JWM.
These rules are identical to those applied to JWTs outlined in Section 7.3 of [RFC7519].
This section defines which algorithms and features of this specification are mandatory to implement. Applications using this specification can impose additional requirements upon implementations that they use.
Support for digitally signed JWMs using JWS is REQUIRED. Of the signature and MAC algorithms specified in JSON Web Algorithms [RFC7518], only ECDSA using the P-256 curve and SHA-256 hash algorithm ("ES256") MUST be implemented by conforming JWM implementations. It is RECOMMENDED that implementations also support ECDSA using the P-521 curve and the SHA-512 hash algorithm ("ES512") and EdDSA using the Ed25519 curve and SHA-512 hash algorithm. Support for other algorithms and key sizes is OPTIONAL.
Support for encrypted JWMs using JWE is also REQUIRED. Of the encryption algorithms specified in [RFC7518], using Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES) to agree upon a key and using this key to to perform key wrapping of a Content Encryption Key ("ECDH-ES+A128KW" and "ECDH-ES+A256KW") MUST be supported. With regards to content encryption, AES in Galois/Counter Mode (GCM) with 128-bit and 256-bit keys ("A128GCM" and "A256GCM") MUST also be supported.
Usage of the "none" algorithm identifier in a JWM as defined in the JOSE Web Algorithms section 3.6 [RFC7518] MUST be considered invalid.
Support for Nested JWMs is also REQUIRED.
The name requested (e.g., "type"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short – that is, not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.
Brief description of the attribute (e.g., "Message Type").
For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
o Attribute Name: "id"
o Attribute Description: Message ID
o Change Controller:
o Specification Document(s):
o Attribute Name: "type"
o Attribute Description: Message Type
o Change Controller:
o Specification Document(s):
o Attribute Name: "body"
o Attribute Description: Message Body
o Change Controller:
o Specification Document(s):
o Attribute Name: "to"
o Attribute Description: Message Recipients
o Change Controller:
o Specification Document(s):
o Attribute Name: "from"
o Attribute Description: Message From
o Change Controller:
o Specification Document(s):
o Attribute Name: "thread_id"
o Attribute Description: Message Thread ID
o Change Controller:
o Specification Document(s):
o Attribute Name: "created_time"
o Attribute Description: Message Created Time
o Change Controller:
o Specification Document(s):
o Attribute Name: "expires_time"
o Attribute Description: Message Expiry Time
o Change Controller:
o Specification Document(s):
o Attribute Name: "reply_url"
o Attribute Description: Message Reply URL
o Change Controller:
o Specification Document(s):
o Attribute Name: "reply_to"
o Attribute Description: Message Reply To
o Change Controller:
o Specification Document(s):
All of the security issues that are pertinent to any cryptographic application must be addressed by JWM/JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys and employing countermeasures to various attacks.
All the security considerations in the JWS specification also apply to JWM, as do the JWE security considerations when encryption is employed. In particular, Sections 10.12 ("JSON Security Considerations") and 10.13 ("Unicode Comparison Security Considerations") of [RFC7515] apply equally to the JWM Attributes Set in the same manner that they do to the JOSE Header.
The contents of a JWM cannot be relied upon in a trust decision unless its contents have been cryptographically secured and bound to the context necessary for the trust decision. In particular, the key(s) used to sign and/or encrypt the JWM will typically need to verifiably be under the control of the party identified by the associated cryptographic operation.
While syntactically the signing and encryption operations for Nested JWMs may be applied in any order, if both signing and encryption are necessary, normally producers should sign the message and then encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions.
Note that potential concerns about security issues related to the order of signing and encryption operations are already addressed by the underlying JWS and JWE specifications; in particular, because JWE only supports the use of authenticated encryption algorithms, cryptographic concerns about the potential need to sign after encryption that apply in many contexts do not apply to this specification.
A JWM may contain privacy-sensitive information. When this is the case, measures MUST be taken to prevent disclosure of this information to unintended parties. One way to achieve this is to use an encrypted JWM and authenticate the recipient. Another way is to ensure that JWMs containing unencrypted privacy-sensitive information are only transmitted using protocols utilizing encryption that support endpoint authentication, such as Transport Layer Security (TLS). Omitting privacy-sensitive information from a JWM is the simplest way of minimizing privacy issues.
The authors of this specification would like to acknowledge the following individuals for the significant contribution of ideas and time spent reviewing this document:
Kyle Den Hartog
Daniel Hardman
| [ECMAScript] | Ecma International, "ECMAScript Language Specification, 5.1 Edition", ECMA Standard 262, June 2011. |
| [IANA.MediaTypes] | IANA, "Media Types" |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC7159] | Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014. |
| [RFC7515] | Jones, M., Bradley, J. and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015. |
| [RFC7516] | Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015. |
| [RFC7518] | Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015. |
| [RFC7519] | Jones, M., Bradley, J. and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |