doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc7165.txt b/doc/rfc/rfc7165.txt
new file mode 100644
index 0000000..4abff17
--- /dev/null
+++ b/doc/rfc/rfc7165.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+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)
+
+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.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes                        Informational                     [Page 1]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   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
+
+
+
+
+
+
+
+
+
+
+Barnes                        Informational                     [Page 2]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+1.  Introduction
+
+   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.
+
+   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.
+
+   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].
+
+   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
+
+
+
+Barnes                        Informational                     [Page 3]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   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.
+
+   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.
+
+2.  Definitions
+
+   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].
+
+   The JOSE working group charter calls for the group to define three
+   basic JSON object formats:
+
+   1.  Integrity-protected object format
+
+   2.  Confidentiality-protected object format
+
+   3.  A format for expressing keys
+
+   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].
+
+   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
+
+
+
+Barnes                        Informational                     [Page 4]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   asymmetric cryptography as well as Message Authentication Codes
+   (MACs) using symmetric keys.
+
+   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.
+
+3.  Basic Requirements
+
+   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.
+
+   o  The JOSE encrypted object format must support object encryption in
+      the case where the sender and receiver share a symmetric key.
+
+   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  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  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.
+
+   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.
+
+   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.
+
+
+
+
+Barnes                        Informational                     [Page 5]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   o  Each algorithm used for JOSE must define which parameters are
+      required to be present in a JOSE object using that algorithm.
+
+   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.
+
+   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.
+
+   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).
+
+4.  Requirements on Application Protocols
+
+   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:
+
+   o  What application content is to be protected
+
+   o  Which cryptographic algorithms are to be used
+
+   o  How application protocol entities establish keys
+
+   o  Whether keys are to be explicitly indicated in JOSE objects or
+      associated by application context
+
+   o  Which serialization(s) of JOSE objects are to be used
+
+
+
+
+
+
+
+Barnes                        Informational                     [Page 6]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+5.  Use Cases
+
+   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.
+
+5.1.  Security Tokens
+
+   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.
+
+   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].
+
+   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.
+
+5.2.  OAuth
+
+   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.
+
+
+
+
+
+
+
+
+
+Barnes                        Informational                     [Page 7]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+                 +---------------+          +---------------+
+                 |               |          |               |
+                 |   Resource    |<........>| Authorization |
+                 |    Server     |          |     Server    |
+                 |               |          |               |
+                 +---------------+          +---------------+
+                              ^                |
+                              |                |
+                              |                |
+                              |                |
+                              |                |
+                 +------------|--+          +--|------------+
+                 |            +----------------+            |
+                 |               |          |   Resource    |
+                 |     Client    |          |     Owner     |
+                 |               |          |               |
+                 +---------------+          +---------------+
+
+                        Figure 1: The OAuth Process
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+Barnes                        Informational                     [Page 8]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   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.
+
+   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.
+
+   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.
+
+5.3.  OpenID Connect
+
+   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.
+
+   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
+
+
+
+Barnes                        Informational                     [Page 9]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   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.
+
+   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.
+
+5.4.  XMPP
+
+   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.
+
+            +-------+   +----------+   +----------+   +-----+
+            | Alice |-->| Server A |-->| Server B |-->| Bob |
+            +-------+   +----------+   +----------+   +-----+
+
+                   Figure 2: Delivering an XMPP Message
+
+   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.
+
+   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.
+
+
+
+Barnes                        Informational                    [Page 10]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   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.
+
+            +-------+   +----------+   +----------+   +-----+
+            | Alice |<->| Server A |<->| Server B |<->| Bob |
+            +-------+   +----------+   +----------+   +-----+
+                |             |              |           |
+                |------------Encrypted message---------->|
+                |             |              |           |
+                |<---------------Public key--------------|
+                |             |              |           |
+                |---------------Wrapped SMK------------->|
+                |             |              |           |
+
+                Figure 3: Delivering a Secure XMPP Message
+
+   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.
+
+   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).
+
+   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
+
+
+
+Barnes                        Informational                    [Page 11]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   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.
+
+   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.
+
+   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.
+
+5.5.  ALTO
+
+   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.
+
+   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.
+
+
+
+Barnes                        Informational                    [Page 12]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   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.
+
+   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.
+
+   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.
+
+5.6.  Emergency Alerting
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Barnes                        Informational                    [Page 13]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   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
+
+   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.
+
+
+
+
+Barnes                        Informational                    [Page 14]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+5.7.  Web Cryptography
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+Barnes                        Informational                    [Page 15]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+5.8.  Constrained Devices
+
+   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.
+
+5.8.1.  Example: MAC Based on ECDH-Derived Key
+
+   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.
+
+   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:
+
+   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  An ECDH public key for the controller is configured at the time of
+      configuration.
+
+   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  A counter and an increment value are configured onto the device.
+
+   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.
+
+
+
+
+
+
+
+
+Barnes                        Informational                    [Page 16]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   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.
+
+5.8.2.  Object Security for CoAP
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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:
+
+   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.
+
+
+
+
+
+
+Barnes                        Informational                    [Page 17]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   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  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  Cipher suites: It should be possible to support a variety of
+      cipher suites to support the constrained devices' use cases.  For
+      example:
+
+      *  Block ciphers with block sizes of, e.g., 96 bits, in addition
+         to the standard 128 bits.
+
+      *  Modes of operation for block ciphers that do not expand the
+         message size to a block boundary, such as AES-GCM.
+
+      *  Cipher suites that support combined encryption and MAC
+         calculation (i.e., AEAD modes for block ciphers).
+
+6.  Requirements
+
+   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.
+
+6.1.  Functional Requirements
+
+   F1 Define formats for secure objects that provide the following
+      security properties:
+
+      *  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.
+
+
+
+
+Barnes                        Informational                    [Page 18]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   F3 Define a format for symmetric keys with associated attributes,
+      allowing for both wrapped and unwrapped keys.
+
+   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].
+
+   F5 Define a compact, URL-safe text serialization for the encrypted
+      and signed object formats.
+
+   F6 Allow for attributes associated to wrapped keys to be bound to
+      them cryptographically.
+
+   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.
+
+   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.
+
+6.2.  Security Requirements
+
+   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]:
+
+      *  Key transport (wrapping for a public key)
+
+      *  Key encipherment (wrapping for a symmetric key)
+
+      *  Key agreement (wrapping for a Diffie-Hellman (DH) public key)
+
+      *  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.
+
+
+
+
+
+Barnes                        Informational                    [Page 19]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   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.
+
+   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.
+
+6.3.  Desiderata
+
+   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.
+
+   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.
+
+   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.
+
+7.  Security Considerations
+
+   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.
+
+
+
+
+
+
+
+
+Barnes                        Informational                    [Page 20]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", RFC
+              4949, August 2007.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, September 2009.
+
+   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
+              Protocol (XMPP): Core", RFC 6120, March 2011.
+
+   [RFC6708]  Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
+              Y. Yang, "Application-Layer Traffic Optimization (ALTO)
+              Requirements", RFC 6708, September 2012.
+
+   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
+              6749, October 2012.
+
+   [RFC7159]  Bray, T., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", RFC 7159, March 2014.
+
+   [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/>.
+
+   [WebCrypto]
+              Dahl, D. and R. Sleevi, "Web Cryptography API", W3C
+              Working Draft, January 2013,
+              <http://www.w3.org/TR/2013/WD-WebCryptoAPI-20130108/>.
+
+8.2.  Informative References
+
+   [ALERT-REQ]
+              Schulzrinne, H., Norreys, S., Rosen, B., and H.
+              Tschofenig, "Requirements, Terminology and Framework for
+              Exigent Communications", Work in Progress, March 2012.
+
+   [ALTO]     Alimi, R., Ed., Penno, R., Ed., and Y. Yang, Ed., "ALTO
+              Protocol", Work in Progress, March 2014.
+
+   [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>.
+
+
+
+Barnes                        Informational                    [Page 21]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   [CONSTRAINED]
+              Bormann, C., Ersue, M., and A. Keranen, "Terminology for
+              Constrained Node Networks", Work in Progress, March 2014.
+
+   [CoAP]     Shelby, Z., Hartke, K., and C. Bormann, "Constrained
+              Application Protocol (CoAP)", Work in Progress, June 2013.
+
+   [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.
+
+   [JWA]      Jones, M., "JSON Web Algorithms (JWA)", Work in Progress,
+              March 2014.
+
+   [JWE]      Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
+              Work in Progress, March 2014.
+
+   [JWK]      Jones, M., "JSON Web Key (JWK)", Work in Progress, March
+              2014.
+
+   [JWS]      Jones, M., Bradley, J., and N. Sakimura, "JSON Web
+              Signature (JWS)", Work in Progress, March 2014.
+
+   [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]      Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
+              (JWT)", Work in Progress, March 2014.
+
+   [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>.
+
+   [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>.
+
+   [Persona]  Mozilla Developer Network, "Mozilla Persona", April 2013,
+              <https://developer.mozilla.org/en-US/docs/Persona>.
+
+
+
+Barnes                        Informational                    [Page 22]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   [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.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
+              Transport Layer Security", RFC 3207, February 2002.
+
+   [RFC3923]  Saint-Andre, P., "End-to-End Signing and Object Encryption
+              for the Extensible Messaging and Presence Protocol
+              (XMPP)", RFC 3923, October 2004.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, October 2006.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              October 2008.
+
+   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+              Mail Extensions (S/MIME) Version 3.2 Message
+              Specification", RFC 5751, January 2010.
+
+   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
+              Framework: Bearer Token Usage", RFC 6750, October 2012.
+
+   [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.
+
+   [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.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/>.
+
+
+
+
+
+
+Barnes                        Informational                    [Page 23]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+   [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>.
+
+   [XMPP-E2E] Miller, M., "End-to-End Object Encryption and Signatures
+              for the Extensible Messaging and Presence Protocol
+              (XMPP)", Work in Progress, June 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes                        Informational                    [Page 24]
+
+RFC 7165                     JOSE Use Cases                   April 2014
+
+
+Appendix A.  Acknowledgements
+
+   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.
+
+Author's Address
+
+   Richard Barnes
+   Mozilla
+   331 E. Evelyn Ave.
+   Mountain View, CA  94041
+   US
+
+   EMail: rlb@ipv.sx
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes                        Informational                    [Page 25]
+