draft-ietf-jose-use-cases-01.txt   draft-ietf-jose-use-cases-02.txt 
JOSE R. Barnes JOSE R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational May 26, 2013 Intended status: Informational May 29, 2013
Expires: November 27, 2013 Expires: November 30, 2013
Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)
draft-ietf-jose-use-cases-01.txt draft-ietf-jose-use-cases-02
Abstract Abstract
Many Internet applications have a need for object-based security Many Internet applications have a need for object-based security
mechanisms in addition to security mechanisms at the network layer or mechanisms in addition to security mechanisms at the network layer or
transport layer. In the past, the Cryptographic Message Syntax has transport layer. In the past, the Cryptographic Message Syntax has
provided a binary secure object format based on ASN.1. Over time, provided a binary secure object format based on ASN.1. Over time,
the use of binary object encodings such as ASN.1 has been overtaken the use of binary object encodings such as ASN.1 has been overtaken
by text-based encodings, for example JavaScript Object Notation. by text-based encodings, for example JavaScript Object Notation.
This document defines a set of use cases and requirements for a This document defines a set of use cases and requirements for a
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 27, 2013. This Internet-Draft will expire on November 30, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 5
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements on Application Protocols . . . . . . . . . . . . 6
4.1. Security Tokens and Authorization . . . . . . . . . . . . 6 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Security Tokens . . . . . . . . . . . . . . . . . . . . . 7
4.3. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Emergency Alerting . . . . . . . . . . . . . . . . . . . . 11 5.3. Federation . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Web Cryptography . . . . . . . . . . . . . . . . . . . . . 13 5.4. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Small Devices . . . . . . . . . . . . . . . . . . . . . . 14 5.5. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.6. Emergency Alerting . . . . . . . . . . . . . . . . . . . . 13
5.1. Functional Requirements . . . . . . . . . . . . . . . . . 15 5.7. Web Cryptography . . . . . . . . . . . . . . . . . . . . . 14
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 16 5.8. Small Devices . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Functional Requirements . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6.2. Security Requirements . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Appendix B. Document History . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Internet applications rest on the layered architecture of the Internet applications rest on the layered architecture of the
Internet, and take advantage of security mechanisms at all layers. Internet, and take advantage of security mechanisms at all layers.
Many applications rely primarily on channel-based security Many applications rely primarily on channel-based security
technologies, which create a secure channel at the IP layer or technologies, which create a secure channel at the IP layer or
transport layer over which application data can flow transport layer over which application data can flow
[RFC4301][RFC5246]. These mechanisms, however, cannot provide end- [RFC4301][RFC5246]. These mechanisms, however, cannot provide end-
to-end security in some cases. For example, in protocols with to-end security in some cases. For example, in protocols with
skipping to change at page 3, line 52 skipping to change at page 3, line 52
[W3C.REC-xml-1998][RFC4627]. [W3C.REC-xml-1998][RFC4627].
Many current applications thus have much more robust support for Many current applications thus have much more robust support for
processing objects in these text-based formats than ASN.1 objects; processing objects in these text-based formats than ASN.1 objects;
indeed, many lack the ability to process ASN.1 objects at all. To indeed, many lack the ability to process ASN.1 objects at all. To
simplify the addition of object-based security features to these simplify the addition of object-based security features to these
applications, the IETF JSON Object Signing and Encryption (JOSE) applications, the IETF JSON Object Signing and Encryption (JOSE)
working group has been chartered to develop a secure object format working group has been chartered to develop a secure object format
based on JSON. While the basic requirements for this object format based on JSON. While the basic requirements for this object format
are straightforward -- namely, confidentiality and integrity are straightforward -- namely, confidentiality and integrity
mechanisms, encoded in JSON -- early discussions in the working group mechanisms, encoded in JSON -- discussions in the working group
indicated that many applications hoping to use the formats define in indicated that different applications hoping to use the formats
JOSE have additional requirements. This document summarizes the use defined by JOSE have different requirements. This document
cases for JOSE envisioned by those applications and the resulting summarizes the use cases for JOSE envisioned by those potential
requirements for security mechanisms and object encoding. applications and the resulting requirements for security mechanisms
and object encodings.
Some systems that use XML have specified the use of XML-based Some systems that use XML have specified the use of XML-based
security mechanisms for object security, namely XML Digital security mechanisms for object security, namely XML Digital
Signatures and XML Encryption Signatures and XML Encryption
[W3C.CR-xmldsig-core2-20120124][W3C.CR-xmlenc-core1-20120313]. These [W3C.CR-xmldsig-core2-20120124][W3C.CR-xmlenc-core1-20120313]. These
mechanisms are defined for use with several security token systems mechanisms are defined for use with several security token systems
(e.g., SAML, WS-Federation, and OpenID connect (e.g., SAML [OASIS.saml-core-2.0-os] and WS-Federation
[OASIS.saml-core-2.0-os][WS-Federation][OpenID.Messages]) and the CAP [WS-Federation]) and the CAP emergency alerting format [CAP]. In
emergency alerting format [CAP]. In practice, however, XML-based practice, however, XML-based secure object formats introduce similar
secure object formats introduce similar levels of complexity to levels of complexity to ASN.1, so developers that lack the tools or
ASN.1, so developers that lack the tools or motivation to handle motivation to handle ASN.1 aren't likely to use XML security either.
ASN.1 aren't able to use XML security either. This situation This situation motivates the creation of a JSON-based secure object
motivates the creation of a JSON-based secure object format that is format that is simple enough to implement and deploy that it can be
simple enough to implement and deploy that it can be easily adopted easily adopted by developers with minimal effort and tools.
by developers with minimal effort and tools.
2. Definitions 2. Definitions
This document makes extensive use of standard security terminology This document makes extensive use of standard security terminology
[RFC4949]. In addition, because the use cases for JOSE and CMS are [RFC4949]. In addition, because the use cases for JOSE and CMS are
similar, we will sometimes make analogies to some CMS concepts similar, we will sometimes make analogies to some CMS concepts
[RFC5652]. [RFC5652].
The JOSE working group charter calls for the group to define three The JOSE working group charter calls for the group to define three
basic JSON object formats: basic JSON object formats:
1. Confidentiality-protected object format 1. Confidentiality-protected object format
2. Integrity-protected object format 2. Integrity-protected object format
3. A format for expressing public keys 3. A format for expressing keys
In the below, we will refer to these as the "encrypted object In this document, we will refer to these as the "signed object
format", the "signed object format", and the "key format", format", the "encrypted object format", and the "key format",
respectively. In general, where there is no need to distinguish respectively. The JOSE working group items intended to describe
between asymmetric and symmetric operations, we will use the terms these formats are JSON Web Signature (JWS), JSON Web Encryption
"signing", "signature", etc. to denote both true digital signatures (JWE), and JSON Web Key (JWK), respectively
involving asymmtric cryptography as well as message authentication [I-D.ietf-jose-json-web-signature]
codes using symmetric keys(MACs). [I-D.ietf-jose-json-web-encryption] [I-D.ietf-jose-json-web-key].
Algorithms and algorithm identifiers used by JWS, JWE, and JWK are
defined in JSON Web Algorithms (JWS)
[I-D.ietf-jose-json-web-algorithms].
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 using
symmetric keys (MACs).
In the lifespan of a secure object, there are two basic roles, an In the lifespan of a secure object, there are two basic roles, an
entity that creates the object (e.g., encrypting or signing a entity that creates the object (e.g., encrypting or signing a
payload), and an entity that uses the object (decrypting, verifying). payload), and an entity that uses the object (decrypting, verifying).
We will refer to these roles as "sender" and "recipient", We will refer to these roles as "sender" and "recipient",
respectively. Note that while some requirements and use cases may respectively. Note that while some requirements and use cases may
refer to these as single entities, each object may have multiple refer to these as single entities, each object may have multiple
entities in each role. For example, a message may be signed by entities in each role. For example, a message may be signed by
multiple senders, or decrypted by multiple recipients. multiple senders, or decrypted by multiple recipients.
3. Basic Requirements 3. Basic Requirements
Obviously, for the encrypted and signed object formats, the necessary Obviously, for the encrypted and signed object formats, the necessary
protections will be created using appropriate cryptographic protections will be created using appropriate cryptographic
skipping to change at page 5, line 26 skipping to change at page 5, line 35
and MACs or digital signatures for integrity protection. In both and MACs or digital signatures for integrity protection. In both
cases, it is necessary for the JOSE format to support both symmetric cases, it is necessary for the JOSE format to support both symmetric
and asymmetric operations. and asymmetric operations.
o The JOSE encrypted object format must support object encryption in o The JOSE encrypted object format must support object encryption in
the case where the sender and receiver share a symmetric key. the case where the sender and receiver share a symmetric key.
o The JOSE encrypted object format must support object encryption in o The JOSE encrypted object format must support object encryption in
the case where the sender has only a public key for the receiver. the case where the sender has only a public key for the receiver.
o The JOSE signed object format must integrity protection using o The JOSE signed object format must support integrity protection
Message Authentication Codes (MACs), for the case where the sender using Message Authentication Codes (MACs), for the case where the
and receiver share only a symmetric key. sender and receiver share only a symmetric key.
o The JOSE signed object format must integrity protection using o The JOSE signed object format must support integrity protection
digital signatures, for the case where the receiver has only a using digital signatures, for the case where the receiver has only
public key for the sender. 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 confusing 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.
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 In cases where two entities are going to be exchanging several JOSE
objects, it might be helpful to pre-negotiate some parameters so that objects, it might be helpful to pre-negotiate some parameters so that
they do not have to be signaled in every JOSE object. However, in they do not have to be signaled in every JOSE object. However, so as
order to not interfere with endpoints that do not support pre- not to confuse endpoints that do not support pre-negotiation, it is
negotiation, it is necessary to signal when pre-negotiated parameters useful to signal when pre-negotiated parameters are in use in those
are in use. cases.
o The JOSE signed and encrypted object formats must include a field o It should be possible to extend the base JOSE signed and encrypted
that indicates that pre-negotiated parameters are to be used to object formats to indicate that pre-negotiated parameters are to
process the object. This field may also provide an indication of be used to process the object. This extension should also provide
which parameters are to be used. a means of indicating of which parameters are to be used.
The purpose of the key format is to provide the recipient with The purpose of the key format is to provide the recipient with
sufficient information to use the encoded key to process sufficient information to use the encoded key to process
cryptographic messages. Thus it is necessary to include additional cryptographic messages. Thus it is sometimes necessary to include
parameters along with the bare key. additional parameters along with the bare key.
o The JOSE key format must include all algorithm parameters o The JOSE key format must enable inclusion of all algorithm
necesssary to use the encoded key, including an identifier for the parameters necessary to use the encoded key, including an
algorithm with which the key is used as well as any additional identifier for the algorithm with which the key is used as well as
parameters required by the algorithm (e.g., elliptic curve any additional parameters required by the algorithm (e.g.,
parameters). elliptic curve parameters).
4. Use Cases 4. Requirements on Application Protocols
Based on early discussions of JOSE, several working groups developing The JOSE secure object formats describe how cryptographic processing
application-layer protocols have expressed a desire to use JOSE in is done on secured content, ensuring that the recipient an object is
their designs for end-to-end security features. In this section, we able to properly decrypt an encrypted object or verify a signature.
summarize the use cases proposed by these groups and discuss the In order to make use of JOSE, however, applications will need to
requirements that they imply for the JOSE object formats. specify several aspects of how JOSE is to be used:
4.1. Security Tokens and Authorization o What application data are 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
5. Use Cases
Several 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 Security tokens are a common use case for object-based security, for
example, SAML assertions [OASIS.saml-core-2.0-os]. Security tokens example, SAML assertions [OASIS.saml-core-2.0-os]. Security tokens
are used to convey information about a subject entity ("claims" or are used to convey information about a subject entity ("claims" or
"assertions") from an issuer to a recipient. The security features "assertions") from an issuer to a recipient. The security features
of a token format enable the recipient to verify that the claims came of a token format enable the recipient to verify that the claims came
from the issuer and, if the object is confidentiality-protected, that from the issuer and, if the object is confidentiality-protected, that
they were not visible to other parties. they were not visible to other parties.
Security tokens are used in federation protocols such as SAML 2.0, Security tokens are used in federation protocols such as SAML 2.0
WS-Federation, and OpenID Connect [OASIS.saml-core-2.0-os], WS-Federation [WS-Federation], Mozilla
[OASIS.saml-core-2.0-os][WS-Federation][OpenID.Messages], as well as Persona [Persona], and OpenID Connect [OpenID.Messages], as well as
in resource authorization protocols such as OAuth 2.0 [RFC6749]. In in resource authorization protocols such as OAuth 2.0 [RFC6749],
some cases, security tokens are used for client authentication and including for OAuth bearer tokens [RFC6750]. In some cases, security
for access control tokens are used for client authentication and for access control
[I-D.ietf-oauth-jwt-bearer][I-D.ietf-oauth-saml2-bearer]. [I-D.ietf-oauth-jwt-bearer][I-D.ietf-oauth-saml2-bearer].
JSON Web Token (JWT) [I-D.ietf-oauth-json-web-token] 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 The OAuth protocol defines a mechanism for distributing and using
authorization tokens using HTTP [RFC6749]. A Client that wishes to authorization tokens using HTTP [RFC6749]. A Client that wishes to
access a protected resource requests authorization from the Resource access a protected resource requests authorization from the Resource
Owner. If the Resource Owner allows this access, he directs an Owner. If the Resource Owner allows this access, he directs an
Authorization Server to issue an access token to the Client. When Authorization Server to issue an access token to the Client. When
the Client wishes to access the protected resource, he presents the the Client wishes to access the protected resource, he presents the
token to the relevant Resource Server, which verifies the validity of token to the relevant Resource Server, which verifies the validity of
the token before providing access to the protected resource. the token before providing access to the protected resource.
+---------------+ +---------------+ +---------------+ +---------------+
skipping to change at page 8, line 9 skipping to change at page 9, line 9
requirements for signed and encrypted object formats, whether the requirements for signed and encrypted object formats, whether the
signing and encryption are provided using asymmetric or symmetric signing and encryption are provided using asymmetric or symmetric
cryptography. The choice of which mechanism is applied will depend cryptography. The choice of which mechanism is applied will depend
on the relationship between the two servers, namely whether they on the relationship between the two servers, namely whether they
share a symmetric key or only public keys. share a symmetric key or only public keys.
Authentication requirements will also depend on deployment Authentication requirements will also depend on deployment
characteristics. Where there is a relatively strong binding between characteristics. Where there is a relatively strong binding between
the resource server and the authorization server, it may suffice for the resource server and the authorization server, it may suffice for
the Authorization Server issuing a token to be identified by the key the Authorization Server issuing a token to be identified by the key
used to sign the token. This requires that the token carry either used to sign the token. This requires that the protocol carry either
the public key of the Authorization Server or an identifier for the the public key of the Authorization Server or an identifier for the
public or symmetric key. public or symmetric key. In JWT, the "client_id" parameter
identifies the key to be used.
There may also be more advanced cases, where the Authorization There may also be more advanced cases, where the Authorization
Server's key is not known in advance to the Resource Server. This Server's key is not known in advance to the Resource Server. This
may happen, for instance, if an entity instantiated a collection of may happen, for instance, if an entity instantiated a collection of
Authorization Servers (say for load balancing), each of which has an Authorization Servers (say for load balancing), each of which has an
independent key pair. In these cases, it may be necessary to also independent key pair. In these cases, it may be necessary to also
include a certificate or certificate chain for the Authorization include a certificate or certificate chain for the Authorization
Server, so that the Resource Server can verify that the Authorization Server, so that the Resource Server can verify that the Authorization
Server is an entity that it trusts. Server is an entity that it trusts.
The HTTP transport for OAuth imposes a particular constraint on the The HTTP transport for OAuth imposes a particular constraint on the
encoding. In the OAuth protocol, tokens frequently need to be passed encoding. In the OAuth protocol, tokens frequently need to be passed
as query parameters in HTTP URIs [RFC2616], after having been as query parameters in HTTP URIs [RFC2616], after having been
base64url encoded [RFC4648]. While there is no specified limit on base64url encoded [RFC4648]. While there is no specified limit on
the length of URIs (and thus of query parameters), in practice URIs the length of URIs (and thus of query parameters), in practice, URIs
of more than around 2,000 characters are rejected by some user of more than 2,048 characters are rejected by some user agents. For
agents. So this use case requires that a JOSE object have some mobile browsers, this limit is even smaller. So this use case
sufficiently small size even after signing, possibly encrypting, requires that a JOSE object have sufficiently small size even after
while still being simple to include in an HTTP URI query parameter. signing, possibly encrypting, while still being simple to include in
an HTTP URI query parameter.
Two related security token systems have similar requirements: 5.3. Federation
o The JSON Web Token format (JWT) is a security token format based Security tokens and OAuth are used in two federated identity
on JSON and JOSE [I-D.ietf-oauth-json-web-token]. It is used with protocols, which have similar requirements to the general
both OpenID Connect and OAuth. Because JWTs are often used in considerations discussed above:
contexts with limited space (e.g., HTTP query parameters), it is a
core requirement for JWTs, and thus JOSE, to have a compact
representation.
o The OpenID Connect protocol is a simple, REST/JSON-based identity o The OpenID Connect protocol [OpenID.Messages] is a simple, REST/
federation protocol layered on OAuth 2.0 [OpenID.Messages]. It JSON-based identity federation protocol layered on OAuth 2.0. It
uses the JWT and JOSE formats both to represent security tokens uses the JWT and JOSE formats both to represent security tokens
and to provide security for other protocol messages (signing and and to provide security for other protocol messages (performing
optionally encryption). 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.
4.2. XMPP o The Mozilla Persona [Persona] system is a simple single-sign-on
(SSO) protocol that uses JWTs that are signed JOSE JWS objects to
represent information about identities, applications, and keys for
participating entities. Persona distributes the keys used as
claims in JWT messages and not by using JOSE header parameters.
5.4. XMPP
The Extensible Messaging and Presence Protocol (XMPP) routes messages The Extensible Messaging and Presence Protocol (XMPP) routes messages
from one end client to another by way of XMPP servers [RFC6120]. from one end client to another by way of XMPP servers [RFC6120].
There are typically two servers involved in delivering any given There are typically two servers involved in delivering any given
message: The first client (Alice) sends a message for another client message: The first client (Alice) sends a message for another client
(B) to her server (A). Server A uses Bob's identity and the DNS to (B) to her server (A). Server A uses Bob's identity and the DNS to
locate the server for Bob's domain (B), then delivers the message to locate the server for Bob's domain (B), then delivers the message to
that server. Server B then routes the message to Bob. that server. Server B then routes the message to Bob.
+-------+ +----------+ +----------+ +-----+ +-------+ +----------+ +----------+ +-----+
skipping to change at page 9, line 32 skipping to change at page 10, line 40
processing S/MIME objects. processing S/MIME objects.
The XMPP working group is in the process of developing a new end-to- 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 end encryption system with an encoding based on JOSE and a clearer
key management system [I-D.miller-xmpp-e2e]. The process of sending key management system [I-D.miller-xmpp-e2e]. The process of sending
an encrypted message in this system involves two steps: First, the an encrypted message in this system involves two steps: First, the
sender generates a symmetric Content Encryption Key (CEK), encrypts sender generates a symmetric Content Encryption Key (CEK), encrypts
the message content, and sends the encrypted message to the desired the message content, and sends the encrypted message to the desired
set of recipients. Second, each recipient "dials back" to the set of recipients. Second, each recipient "dials back" to the
sender, providing his public key; the sender then responds with the sender, providing his public key; the sender then responds with the
relevent CEK, wrapped with the recipient's public key. relevant CEK, wrapped with the recipient's public key.
+-------+ +----------+ +----------+ +-----+ +-------+ +----------+ +----------+ +-----+
| Alice |<->| Server A |<->| Server B |<->| Bob | | Alice |<->| Server A |<->| Server B |<->| Bob |
+-------+ +----------+ +----------+ +-----+ +-------+ +----------+ +----------+ +-----+
| | | | | | | |
|------------Encrypted--message--------->| |------------Encrypted--message--------->|
| | | | | | | |
|<---------------Public-key--------------| |<---------------Public-key--------------|
| | | | | | | |
|---------------Wrapped CEK------------->| |---------------Wrapped CEK------------->|
skipping to change at page 11, line 5 skipping to change at page 12, line 22
Finally, it's worth noting that XMPP is based on XML, not JSON. So 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 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 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 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 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 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, base64url encoding, but for XMPP messages of medium-to-large size,
this could impose a fair degree of overhead. this could impose a fair degree of overhead.
4.3. ALTO 5.5. ALTO
Application-Layer Traffic Optimization (ALTO) is a system for Application-Layer Traffic Optimization (ALTO) is a system for
distributing network topology information to end devices, so that distributing network topology information to end devices, so that
those devices can modify their behavior to have a lower impact on the those devices can modify their behavior to have a lower impact on the
network [RFC6708]. The ALTO protocol distributes topology network [RFC6708]. The ALTO protocol distributes topology
information in the form of JSON objects carried in HTTP information in the form of JSON objects carried in HTTP
[RFC2616][I-D.ietf-alto-protocol]. The basic version of ALTO is [RFC2616][I-D.ietf-alto-protocol]. The basic version of ALTO is
simply a client-server protocol, so simple use of HTTPS suffices for simply a client-server protocol, so simple use of HTTPS suffices for
this case [RFC2818]. However, there is beginning to be some this case [RFC2818]. However, there is beginning to be some
discussion of use cases for ALTO in which these JSON objects will be discussion of use cases for ALTO in which these JSON objects will be
skipping to change at page 11, line 46 skipping to change at page 13, line 15
In addition, because ALTO objects are also encoded as JSON, they are In addition, because ALTO objects are also encoded as JSON, they are
already safe for inclusion in a JOSE object. Signed JOSE objects already safe for inclusion in a JOSE object. Signed JOSE objects
will likely carry the signed data in a string alongside the will likely carry the signed data in a string alongside the
signature. JSON objects have the property that they can be safely signature. JSON objects have the property that they can be safely
encoded in JSON strings. All they require is that unnecessary white encoded in JSON strings. All they require is that unnecessary white
space be removed, a much simpler transformation than, say base64url space be removed, a much simpler transformation than, say base64url
encoding. This raises the question of whether it might be possible encoding. This raises the question of whether it might be possible
to optimize the JOSE encoding for certain "JSON-safe" cases. to optimize the JOSE encoding for certain "JSON-safe" cases.
4.4. Emergency Alerting 5.6. Emergency Alerting
Emergency alerting is an emerging use case for IP networks Emergency alerting is an emerging use case for IP networks
[I-D.ietf-atoca-requirements]. Alerting systems allow authorities to [I-D.ietf-atoca-requirements]. Alerting systems allow authorities to
warn users of impending danger by sending alert messages to connected warn users of impending danger by sending alert messages to connected
devices. For example, in the event of hurricane or tornado, alerts devices. For example, in the event of hurricane or tornado, alerts
might be sent to all devices in the path of the storm. might be sent to all devices in the path of the storm.
The most critical security requirement for alerting systems is that The most critical security requirement for alerting systems is that
it must not be possible for an attacker to send false alerts to it must not be possible for an attacker to send false alerts to
devices. Such a capability would potentially allow an attacker to devices. Such a capability would potentially allow an attacker to
skipping to change at page 13, line 4 skipping to change at page 14, line 36
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Device | | Device | | Device | | Device | | Device | | Device | | Device | | Device |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 4: Delivering an emergency alert Figure 4: Delivering an emergency alert
In order to verify alert signatures, recipients must be provisioned In order to verify alert signatures, recipients must be provisioned
with the proper public keys for trusted alert authorities. This with the proper public keys for trusted alert authorities. This
trust may be "piece-wise" along the path the alert takes. For trust may be "piece-wise" along the path the alert takes. For
example, the alert relays operated by networks might have a full set example, the alert relays operated by networks might have a full set
of ceritificates for all alert originators, while end devices may of certificates for all alert originators, while end devices may only
only trust their local alert relay. Or devices might require that a trust their local alert relay. Or devices might require that a
device be signed by an authorized originator and by its local device be signed by an authorized originator and by its local
network's relay. network's relay.
This scenario creates a need for multiple signatures on alert This scenario creates a need for multiple signatures on alert
documents, so that an alert can bear signatures from any or all of 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 the entities that processed it along the path. In order to minimize
complexity, these signatures should be "modular", in the sense that a complexity, these signatures should be "modular", in the sense that a
new signature can be added without a need to alter or recompute new signature can be added without a need to alter or recompute
previous signatures. previous signatures.
4.5. Web Cryptography 5.7. Web Cryptography
The W3C Web Cryptography API defines a standard cryptographic API for The W3C Web Cryptography API defines a standard cryptographic API for
the web [WebCrypto]. If a browser exposes this API, then JavaScript the Web [WebCrypto]. If a browser exposes this API, then JavaScript
provided as part of a web page can ask the browser to perform provided as part of a Web page can ask the browser to perform
cryptographic operations, such as digest, MAC, encryption, or digital cryptographic operations, such as digest, MAC, encryption, or digital
signing. signing.
One of the key reasons to have the browser perform cryptographic One of the key reasons to have the browser perform cryptographic
operations to avoid allowing JavaScript code to access the keying operations is to avoid allowing JavaScript code to access the keying
material used for these operations. For example, this separation material used for these operations. For example, this separation
would prevent code injected through a cross-site scripting (XSS) would prevent code injected through a cross-site scripting (XSS)
attack from reading and exfiltrating keys stored within a browser. attack from reading and exfiltrating keys stored within a browser.
While the malicious code could still use the key while running in the While the malicious code could still use the key while running in the
browser, this vulnerability can only be exercised while the browser, this vulnerability can only be exercised while the
vulnerable page is active in a user's browser. vulnerable page is active in a user's browser.
However, the WebCryptography API also provides a key export However, the WebCryptography API also provides a key export
functionality, which can allow JavaScript to extract a key from the functionality, which can allow JavaScript to extract a key from the
API in wrapped form. For example, the JavaScript might provide a API in wrapped form. For example, the JavaScript might provide a
skipping to change at page 14, line 12 skipping to change at page 15, line 44
forms of keys. Obviously, the public key from an asymmetric key pair forms of keys. Obviously, the public key from an asymmetric key pair
can be freely imported to and exported from the browser, so there 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 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 format to express private keys and symmetric keys. For non-public
keys, the primary need is for a wrapped form, where the keys, the primary need is for a wrapped form, where the
confidentiality and integrity of the key is assured confidentiality and integrity of the key is assured
cryptographically; these protections should also apply to any cryptographically; these protections should also apply to any
attributes of the key. It may also be useful to define a direct, attributes of the key. It may also be useful to define a direct,
unwrapped format, for use within a security boundary. unwrapped format, for use within a security boundary.
4.6. Small Devices 5.8. Small Devices
A small, low power device maker has decided on using the output of A small, low power device maker has decided on using the output of
the JOSE working group as their encryption and authentication the JOSE working group as their encryption and authentication
framework. The device maker has a limited availability of both real framework. The device maker has a limited availability of both real
estate for gates and power. For this reason there are a number of estate for gates and power. For this reason there are a number of
short cuts and design decisions that have been made in order to short cuts and design decisions that have been made in order to
minimize these needs. minimize these needs.
The design team has determined that the use of message authentication The design team has determined that the use of message authentication
codes (MAC) is going to be sufficient to provide the necessary codes (MAC) is going to be sufficient to provide the necessary
skipping to change at page 15, line 9 skipping to change at page 16, line 41
function is used when is based on the AES-CBC is used to derive function is used when is based on the AES-CBC is used to derive
the required MAC key. The MAC key is then used to compute the MAC the required MAC key. The MAC key is then used to compute the MAC
value for the message. value for the message.
In a similar manner the KDF function can used to compute an AEAD In a similar manner the KDF function can used to compute an AEAD
algorithm key when the system needs to provide confidentially for the algorithm key when the system needs to provide confidentially for the
message. The controller, being a larger device will perform the message. The controller, being a larger device will perform the
exponentiation step and use a random number generator to generate the exponentiation step and use a random number generator to generate the
sender nonce value. sender nonce value.
5. Requirements 6. Requirements
This section summarizes the requirements from the above uses cases, This section summarizes the requirements from the above uses cases,
and lists further requirements not directly derived from the above and lists further requirements not directly derived from the above
use cases. There are also some constraints that are not hard use cases. There are also some constraints that are not hard
requrirements, but which are still desireable properties for the JOSE requirements, but which are still desirable properties for the JOSE
system to have. system to have.
5.1. Functional Requirements 6.1. Functional Requirements
F1 Define formats for secure objects that provide the following F1 Define formats for secure objects that provide the following
security properties: security properties:
* Digital signature (integrity/authentication under an asymmetric * Digital signature (integrity/authentication under an asymmetric
key pair) key pair)
* Message authentication (integrity/authentication under a * Message authentication (integrity/authentication under a
symmetric key) symmetric key)
skipping to change at page 16, line 19 skipping to change at page 18, line 5
them cryptographically them cryptographically
F7 Allow for wrapped keys to be separated from a secure object that F7 Allow for wrapped keys to be separated from a secure object that
uses a symmetric key. In such cases, cryptographic components of uses a symmetric key. In such cases, cryptographic components of
the secure object other than the wrapped key (e.g., ciphertext, the secure object other than the wrapped key (e.g., ciphertext,
MAC values) must be independent of the wrapped form of the key. MAC values) must be independent of the wrapped form of the key.
For example, if an encrypted object is prepared for multiple For example, if an encrypted object is prepared for multiple
recipients, then only the wrapped key may vary, not the recipients, then only the wrapped key may vary, not the
ciphertext. ciphertext.
5.2. Security Requirements 6.2. Security Requirements
S1 Provide key management functions for all symmetric keys, including S1 Provide mechanisms to avoid repeated use of the same symmetric key
encryption keys and MAC keys. It should be possible to use any of for encryption or MAC computation. Instead, long-lived keys
the key management techniques provided in CMS [RFC5652]: 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 transport (wrapping for a public key)
* Key encipherment (wrapping for a symmetric key) * Key encipherment (wrapping for a symmetric key)
* Key agreement (wrapping for a DH public key) * Key agreement (wrapping for a DH public key)
* Password-based encryption (wrapping under a derived key) * Password-based encryption (wrapping under a key derived from a
password)
S2 Use cryptographic algorithms in a manner compatible with major S2 Use cryptographic algorithms in a manner compatible with major
validation processes. For example, if a FIPS standard allows validation processes. For example, if a FIPS standard allows
algorithm A to be used for purpose X but not purpose Y, then JOSE algorithm A to be used for purpose X but not purpose Y, then JOSE
should not recommend using algorithm A for purpose Y. should not recommend using algorithm A for purpose Y.
S3 Support operation with or without pre-negotiation. It must be S3 Support operation with or without pre-negotiation. It must be
possible to create or process a secure object without any possible to create or process secure objects without any
configuration beyond key provisioning. If it is possible to configuration beyond key provisioning. If it is possible for keys
negotiate parameters out of band, then the object must signal that to be derived from application context, it must be possible for a
pre-negotiated parameters are to be used. recipient to recognize when it does not have the appropriate key.
5.3. Desiderata 6.3. Desiderata
D1 Maximize compatibility with the W3C WebCrypto specification, e.g., D1 Maximize compatibility with the W3C WebCrypto specifications,
by using the same identifiers for algorithms. e.g., by coordinating with the WebCrypto working group to
encourage alignment of algorithms and algorithm identifiers.
D2 Avoid JSON canonicalization to the extent possible possible. That D2 Avoid JSON canonicalization to the extent possible. That is, all
is, all other things being equal, techniques that rely on fixing a other things being equal, techniques that rely on fixing a
serialization of an object (e.g., by base64url encoding it) are serialization of an object (e.g., by base64url encoding it) are
preferred over those that require converting an object to a preferred over those that require converting an object to a
canonical form. canonical form.
6. Acknowledgements
Thanks to Matt Miller for discussions related to XMPP end-to-end
security model, and to Mike Jones for considerations related to
security tokens and XML security. Thanks to Mark Watson for raising
the need for representing symmetric keys and binding attributes to
them.
7. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
8. Security Considerations 8. Security Considerations
The primary focus of this document is the requirements for a JSON- The primary focus of this document is the requirements for a JSON-
based secure object format. At the level of general security based secure object format. At the level of general security
considerations for object-based security technologies, the security considerations for object-based security technologies, the security
considerations for this format are the same as for CMS [RFC5652]. considerations for this format are the same as for CMS [RFC5652].
The primary difference between the JOSE format and CMS is that JOSE The primary difference between the JOSE format and CMS is that JOSE
is based on JSON, which does not have a canonical representation. is based on JSON, which does not have a canonical representation.
The lack of a canonical form means that it is difficult to determine The lack of a canonical form means that it is difficult to determine
whether two JSON objects represent the same information, which could whether two JSON objects represent the same information, which could
lead to vulnerabilities in some usages of JOSE. lead to vulnerabilities in some usages of JOSE.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-16 (work in progress), May 2013.
[I-D.ietf-atoca-requirements]
Schulzrinne, H., Norreys, S., Rosen, B., and H.
Tschofenig, "Requirements, Terminology and Framework for
Exigent Communications", draft-ietf-atoca-requirements-03
(work in progress), March 2012.
[I-D.ietf-oauth-json-web-token]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token-07 (work in
progress), April 2013.
[I-D.miller-xmpp-e2e]
Miller, M., "End-to-End Object Encryption for the
Extensible Messaging and Presence Protocol (XMPP)",
draft-miller-xmpp-e2e-05 (work in progress),
February 2013.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. RFC 4949, August 2007.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
skipping to change at page 18, line 37 skipping to change at page 19, line 47
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO) Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", RFC 6708, September 2012. Requirements", RFC 6708, September 2012.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012. RFC 6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012.
[W3C.CR-xmldsig-core2-20120124] [W3C.CR-xmldsig-core2-20120124]
Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P., Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P.,
Hirsch, F., Cantor, S., and T. Roessler, "XML Signature Hirsch, F., Cantor, S., and T. Roessler, "XML Signature
Syntax and Processing Version 2.0", World Wide Web Syntax and Processing Version 2.0", World Wide Web
Consortium CR CR-xmldsig-core2-20120124, January 2012, Consortium CR CR-xmldsig-core2-20120124, January 2012,
<http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>. <http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>.
[W3C.CR-xmlenc-core1-20120313] [W3C.CR-xmlenc-core1-20120313]
Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch, Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch,
"XML Encryption Syntax and Processing Version 1.1", World "XML Encryption Syntax and Processing Version 1.1", World
skipping to change at page 19, line 17 skipping to change at page 20, line 31
[WebCrypto] [WebCrypto]
Sleevi, R. and D. Dahl, "Web Cryptography API", Sleevi, R. and D. Dahl, "Web Cryptography API",
January 2013. January 2013.
9.2. Informative References 9.2. Informative References
[CAP] Botterell, A. and E. Jones, "Common Alerting Protocol [CAP] Botterell, A. and E. Jones, "Common Alerting Protocol
v1.1", October 2005. v1.1", October 2005.
[I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-16 (work in progress), May 2013.
[I-D.ietf-atoca-requirements]
Schulzrinne, H., Norreys, S., Rosen, B., and H.
Tschofenig, "Requirements, Terminology and Framework for
Exigent Communications", draft-ietf-atoca-requirements-03
(work in progress), March 2012.
[I-D.ietf-jose-json-web-algorithms]
Jones, M., "JSON Web Algorithms (JWA)",
draft-ietf-jose-json-web-algorithms-11 (work in progress),
May 2013.
[I-D.ietf-jose-json-web-encryption]
Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
Encryption (JWE)", draft-ietf-jose-json-web-encryption-11
(work in progress), May 2013.
[I-D.ietf-jose-json-web-key]
Jones, M., "JSON Web Key (JWK)",
draft-ietf-jose-json-web-key-11 (work in progress),
May 2013.
[I-D.ietf-jose-json-web-signature]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature-11
(work in progress), May 2013.
[I-D.ietf-oauth-json-web-token]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token-08 (work in
progress), May 2013.
[I-D.ietf-oauth-jwt-bearer] [I-D.ietf-oauth-jwt-bearer]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and (JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-jwt-bearer-05 Authorization Grants", draft-ietf-oauth-jwt-bearer-05
(work in progress), March 2013. (work in progress), March 2013.
[I-D.ietf-oauth-saml2-bearer] [I-D.ietf-oauth-saml2-bearer]
Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Profile for OAuth 2.0 Client Authentication and Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-saml2-bearer-16 Authorization Grants", draft-ietf-oauth-saml2-bearer-16
(work in progress), March 2013. (work in progress), March 2013.
[I-D.miller-xmpp-e2e]
Miller, M., "End-to-End Object Encryption for the
Extensible Messaging and Presence Protocol (XMPP)",
draft-miller-xmpp-e2e-05 (work in progress),
February 2013.
[ITU.X690.1994] [ITU.X690.1994]
International Telecommunications Union, "Information International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994. X.690, 1994.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005. 2.0-os, March 2005.
[OpenID.Messages] [OpenID.Messages]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Sakimura, N., Bradley, J., Jones, M., de Medeiros, B.,
Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0", Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0",
June 2012, May 2013,
<http://openid.net/specs/ <http://openid.net/specs/
openid-connect-messages-1_0.html>. openid-connect-messages-1_0.html>.
[Persona] Mozilla, "Mozilla Persona", April 2013.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. Transport Layer Security", RFC 3207, February 2002.
[RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption
skipping to change at page 20, line 28 skipping to change at page 22, line 37
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[WS-Federation] [WS-Federation]
Kaler, C., McIntosh, M., Goodner, M., and A. Nadalin, Kaler, C., McIntosh, M., Goodner, M., and A. Nadalin, "Web
"OpenID Connect Messages 1.0", May 2009, <http:// Services Federation Language (WS-Federation) Version 1.2",
docs.oasis-open.org/wsfed/federation/v1.2/os/ May 2009, <http://docs.oasis-open.org/wsfed/federation/
ws-federation-1.2-spec-os.html>. v1.2/os/ws-federation-1.2-spec-os.html>.
Appendix A. Acknowledgements
Thanks to Matt Miller for discussions related to XMPP end-to-end
security model, and to Mike Jones for considerations related to
security tokens and XML security. Thanks to Mark Watson for raising
the need for representing symmetric keys and binding attributes to
them.
Appendix B. Document History
[[ to be removed by the RFC editor before publication as an RFC ]]
-02
o Referenced the JWS, JWE, JWK, and JWA specifications making the
"signed object format", "encrypted object format", "key format",
and algorithms resulting from these use cases concrete.
o Added "Requirements on Application Protocols" section.
o Broke former huge "Security Tokens and Authorization" Use Case
section into "Security Tokens", "OAuth", and "Federation" Use Case
sections.
o Cited Mozilla Persona as a single-sign-on (SSO) system using JWTs
and JOSE data formats.
o Spelling and grammar corrections.
-01
o Added the "Small Devices" use case
-00
o Created the initial IETF draft based upon
draft-barnes-jose-use-cases-01 with some additions.
Author's Address Author's Address
Richard Barnes Richard Barnes
BBN Technologies BBN Technologies
1300 N 17th St 1300 N 17th St
Arlington, VA 22209 Arlington, VA 22209
US US
Email: rlb@ipv.sx Email: rlb@ipv.sx
 End of changes. 54 change blocks. 
159 lines changed or deleted 279 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/