One document matched: draft-barnes-jose-use-cases-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-barnes-jose-use-cases-01.txt"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="JOSE Use Cases">Use Cases and Requirements for JSON Object
Signing and Encryption (JOSE)</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Richard Barnes" initials="R.L." surname="Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>9861 Broken Land Parkway</street>
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>US</country>
</postal>
<phone>+1 410 290 6169</phone>
<email>rbarnes@bbn.com</email>
</address>
</author>
<date day="22" month="October" year="2012"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<area>SEC</area>
<workgroup>JOSE</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>cms, s/mime, jose, xmpp, alto, oauth</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Many Internet applications have a need for object-based security
mechanisms in addition to security mechanisms at the network layer or
transport layer. In the past, the Cryptographic Message Syntax has
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 by
text-based encodings, for example JavaScript Object Notation. This
document defines a set of use cases and requirements for a secure object
format encoded using JavaScript Object Notation, drawn from a variety of
application security mechanisms currently in development.</t>
</abstract>
</front>
<middle>
<section anchor="intro-sec" title="Introduction">
<t>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,
which create a secure channel at the IP layer or transport layer over
which application data can flow <xref target="RFC4301"/><xref
target="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.</t>
<t>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 <xref target="RFC5751"/><xref target="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., <xref target="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.</t>
<t>S/MIME is based on the Cryptographic Message Syntax for secure
objects (CMS) <xref target="RFC5652"/>. CMS is defined using Abstract
Syntax Notation 1 (ASN.1) and traditionally encoded using the ASN.1
Distinguished Encoding Rules (DER), which define a binary encoding of
the protected message and associated parameters <xref
target="ITU.X690.1994"/>. 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) or the JavaScript Object Notation
(JSON) <xref target="W3C.REC-xml-1998"/><xref target="RFC4627"/>.</t>
<t>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 -- early discussions in the working group indicated that
many applications hoping to use the formats define in JOSE have
additional requirements. This document summarizes the use cases for JOSE
envisioned by those applications and the resulting requirements for
security mechanisms and object encoding.</t>
<t>Some systems that use XML have specified the use of XML-based
security mechanisms for object security, namely XML Digital Signatures
and XML Encryption <xref target="W3C.CR-xmldsig-core2-20120124"/><xref
target="W3C.CR-xmlenc-core1-20120313"/>. These mechanisms are defined
for use with several security token systems (e.g., SAML, WS-Federation,
and OpenID connect <xref target="OASIS.saml-core-2.0-os"/><xref
target="WS-Federation"/><xref target="OpenID.Messages"/>) and the CAP
emergency alerting format <xref target="CAP"/>. In practice, however,
XML-based secure object formats introduce similar levels of complexity
to ASN.1, so developers that lack the tools or motivation to handle
ASN.1 aren't able 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.</t>
</section>
<section anchor="def-sec" title="Definitions">
<!--
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
-->
<t>This document makes extensive use of standard security terminology
<xref target="RFC4949"/>. In addition, because the use cases for JOSE
and CMS are similar, we will sometimes make analogies to some CMS
concepts <xref target="RFC5652"/>.</t>
<t>The JOSE working group charter calls for the group to define three
basic JSON object formats:<list style="numbers">
<t>Confidentiality-protected object format</t>
<t>Integrity-protected object format</t>
<t>A format for expressing public keys</t>
</list>In the below, we will refer to these as the "encrypted object
format", the "signed object format", and the "key format", respectively.
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 asymmtric cryptography
as well as message authentication codes using symmetric keys(MACs).</t>
<t>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, 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.</t>
</section>
<section title="Basic Requirements">
<t>Obviously, 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.<list style="symbols">
<t>The JOSE encrypted object format MUST support object encryption
in the case where the sender and receiver share a symmetric key.</t>
<t>The JOSE encrypted object format MUST support object encryption
in the case where the sender has only a public key for the
receiver.</t>
<t>The JOSE signed object format MUST integrity protection using
Message Authentication Codes (MACs), for the case where the sender
and receiver share a symmetric key.</t>
<t>The JOSE signed object format MUST integrity protection using
digital signatures, for the case where the receiver has only a
public key for the sender.</t>
</list></t>
<t>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 necessary to include additional parameters along
with the bare key.</t>
<t><list style="symbols">
<t>The JOSE key format MUST include all algorithm parameters
necesssary 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).</t>
</list></t>
</section>
<section anchor="lock-sec" title="Use Cases">
<t>Based on early discussions of JOSE, several working groups developing
application-layer protocols have expressed a desire to use JOSE 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.</t>
<section title="Security Tokens and Authorization">
<t>Security tokens are a common use case for object-based security,
for example, SAML assertions <xref target="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.</t>
<t>Security tokens are used in federation protocols such as SAML 2.0,
WS-Federation, and OpenID Connect <xref
target="OASIS.saml-core-2.0-os"/><xref target="WS-Federation"/><xref
target="OpenID.Messages"/>, as well as in resource authorization
protocols such as OAuth 2.0 <xref target="RFC6749"/>. In some cases,
security tokens are used for client authentication and for access
control <xref target="I-D.ietf-oauth-jwt-bearer"/><xref
target="I-D.ietf-oauth-saml2-bearer"/>.</t>
<t>The OAuth protocol defines a mechanism for distributing and using
authorization tokens using HTTP <xref target="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.</t>
<figure anchor="figOAuth" title="The OAuth process">
<artwork><![CDATA[ +---------------+ +---------------+
| | | |
| Resource |<........>| Authorization |
| Server | | Server |
| | | |
+---------------+ +---------------+
^ |
| |
| |
| |
| |
+------------|--+ +--|------------+
| +----------------+ |
| | | Resource |
| Client | | Owner |
| | | |
+---------------+ +---------------+]]></artwork>
<postamble/>
</figure>
<t>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). So again we have a case
where an application object is transported via untrusted
intermediaries.</t>
<t>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. 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 confidentiality
protection is not strictly necessary for this use case.</t>
<t>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.</t>
<t>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 token carry either the
public key of the Authorization Server or an identifier for the public
or symmetric key.</t>
<t>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.</t>
<t>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 <xref target="RFC2616"/>, after
having been base64url encoded <xref target="RFC4648"/>. While there is
no specified limit on the length of URIs (and thus of query
parameters), in practice URIs of more than around 2,000 characters are
rejected by some user agents. So this use case requires that a JOSE
object have sufficiently small size even after signing, possibly
encrypting, while still being simple to include in an HTTP URI query
parameter.</t>
<t>Two related security token systems have similar requirements:</t>
<t><list style="symbols">
<t>The JSON Web Token format (JWT) is a security token format
based on JSON and JOSE <xref
target="I-D.ietf-oauth-json-web-token"/>. It is used with both
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
representation.</t>
<t>The OpenID Connect protocol is a simple, REST/JSON-based
identity federation protocol layered on OAuth 2.0 <xref
target="OpenID.Messages"/>. It uses the JWT and JOSE formats both
to represent security tokens and to provide security for other
protocol messages (signing and optionally encryption).</t>
</list></t>
</section>
<section title="XMPP">
<t>The Extensible Messaging and Presence Protocol (XMPP) routes
messages from one end client to another by way of XMPP servers <xref
target="RFC6120"/>. There are typically two servers involved in
delivering any given 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 locate the server for Bob's domain (B), then delivers
the message to that server. Server B then routes the message to
Bob.</t>
<figure anchor="fig-xmpp" title="Delivering an XMPP message">
<artwork><![CDATA[
+-------+ +----------+ +----------+ +-----+
| Alice |-->| Server A |-->| Server B |-->| Bob |
+-------+ +----------+ +----------+ +-----+]]></artwork>
</figure>
<t>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 <xref
target="RFC3923"/>, in part because of key management challenges and
because of the difficulty of processing S/MIME objects.</t>
<t>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 <xref target="I-D.miller-xmpp-e2e"/>.
The process of sending an encrypted message in this system involves
two steps: First, the sender generates a symmetric Content Encryption
Key (CEK), encrypts the message content, and sends the encrypted
message to the desired set of recipients. Second, each recipient
"dials back" to the sender, providing his public key; the sender then
responds with the relevent CEK, wrapped with the recipient's public
key.</t>
<figure anchor="fig-xmpp-sec" title="Delivering a secure XMPP message">
<artwork><![CDATA[
+-------+ +----------+ +----------+ +-----+
| Alice |<->| Server A |<->| Server B |<->| Bob |
+-------+ +----------+ +----------+ +-----+
| | | |
|------------Encrypted--message--------->|
| | | |
|<---------------Public-key--------------|
| | | |
|---------------Wrapped CEK------------->|
| | | |]]></artwork>
</figure>
<t>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.</t>
<t>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 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
CEK (much as a CMS EnvelopedData structure can include multiple
RecipientInfo structures).</t>
<t>In the current draft of the XMPP end-to-end security system, each
party is authenticated by virtue of the other party's trust in the
XMPP message routing system. The sender is authenticated to the
receiver because he can receive messages for the identifier "Alice"
(in particular, the request for wrapped keys), and can originate
messages for that identifier (the wrapped key). Likewise, the receiver
is authenticated to the sender because he received the original
encrypted message and originated the request for 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.</t>
<t>Because this authentication is quite weak (depending on the use of
transport-layer security 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.</t>
<t>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.</t>
</section>
<section title="ALTO">
<t>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 <xref target="I-D.ietf-alto-reqs"/>. The ALTO protocol
distributes topology information in the form of JSON objects carried
in HTTP <xref target="RFC2616"/><xref
target="I-D.ietf-alto-protocol"/>. The basic version of ALTO is simply
a client-server protocol, so simple use of HTTPS suffices for this
case <xref target="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 must be
able to validate the received ALTO information to ensure that it was
generated by an appropriate ALTO server."</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Emergency Alerting">
<t>Emergency alerting is an emerging use case for IP networks <xref
target="I-D.ietf-atoca-requirements"/>. Alerting systems allow
authorities to warn users of impending danger by sending alert
messages to connected devices. For example, in the event of hurricane
or tornado, alerts might be sent to all devices in the path of the
storm.</t>
<t>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, as well as by having recipients of alerts verify that
the alert was sent by an authorized source. The former type of control
implemented with local security on hosts from which alerts can be
originated. The latter type implemented by digital signatures on alert
messages (using channel-based or object-based mechanisms).</t>
<t>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.</t>
<t><figure anchor="fig-atoca-sec"
title="Delivering an emergency alert">
<artwork><![CDATA[ +------------+ +------------+ +------------+
| Originator | | Originator | | Originator |
+------------+ +------------+ +------------+
| . .
+-----------------+..................
|
V
+---------+
| Gateway |
+---------+
|
+------------+------------+
| |
V V
+---------+ +---------+
| Network | | Network |
+---------+ +---------+
| |
+------+-----+ +------+-----+
| | | |
V V V V
+--------+ +--------+ +--------+ +--------+
| Device | | Device | | Device | | Device |
+--------+ +--------+ +--------+ +--------+
]]></artwork>
</figure></t>
<t>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
ceritificates 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.</t>
<t>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.</t>
</section>
</section>
<section title="Other Requirements">
<t>[[ For the initial version of this document, this section is a
placeholder, to incorporate any further requirements not directly
derived from the above use cases. ]]</t>
</section>
<section anchor="ack-sec" title="Acknowledgements">
<t>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.</t>
</section>
<section anchor="iana-sec" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
</section>
<section anchor="sec-cons-sec" title="Security Considerations">
<t>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 <xref
target="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.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4627.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6120.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6749.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-alto-protocol.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-alto-reqs.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-atoca-requirements.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-json-web-token.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.miller-xmpp-e2e.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml2/reference.W3C.REC-xml-1998.xml" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml4/reference.W3C.CR-xmldsig-core2-20120124.xml" ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml4/reference.W3C.CR-xmlenc-core1-20120313.xml" ?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5652.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5751.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3207.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3923.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-core-2.0-os.xml' ?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-saml2-bearer.xml' ?>
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-jwt-bearer.xml' ?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml2/reference.ITU.X690.1994.xml" ?>
<reference anchor="CAP">
<front>
<title>Common Alerting Protocol v1.1</title>
<author fullname="" initials="A" surname="Botterell"/>
<author initials="E." surname="Jones"/>
<date month="October" year="2005"/>
</front>
</reference>
<reference anchor="OpenID.Messages"
target="http://openid.net/specs/openid-connect-messages-1_0.html">
<front>
<title>OpenID Connect Messages 1.0</title>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NRI">Nomura Research Institute,
Ltd.</organization>
</author>
<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Ping Identity">Ping Identity</organization>
</author>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Microsoft">Microsoft</organization>
</author>
<author fullname="Breno de Medeiros" initials="B."
surname="de Medeiros">
<organization abbrev="Google">Google</organization>
</author>
<author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
<organization abbrev="Salesforce">Salesforce</organization>
</author>
<author fullname="Edmund Jay" initials="E." surname="Jay">
<organization abbrev="Illumila">Illumila</organization>
</author>
<date day="23" month="June" year="2012"/>
</front>
</reference>
<reference anchor="WS-Federation"
target="http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html">
<front>
<title>OpenID Connect Messages 1.0</title>
<author fullname="Chris Kaler" initials="C." surname="Kaler">
<organization/>
</author>
<author fullname="Michael McIntosh" initials="M." surname="McIntosh">
<organization/>
</author>
<author fullname="Marc Goodner" initials="M." surname="Goodner">
<organization/>
</author>
<author fullname="Anthony Nadalin" initials="A." surname="Nadalin">
<organization/>
</author>
<date day="22" month="May" year="2009"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:22:17 |