Subversion Repositories specifications

[/] [json_web_encryption/] [1.0/] [draft-jones-json-web-encryption.html] - Rev 547

Compare with Previous | Blame | View Log

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>JSON Web Encryption (JWE)</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="JSON Web Encryption (JWE)">
<meta name="keywords" content="RFC, Request for Comments, I-D, Internet-Draft, Assertion, Simple Web Token, Security Token, SWT, JavaScript Object Notation, JSON, JSON Web Token, JWT, JSON Web Signature, JWS, JSON Web Encryption, JWE, JSON Web Key, JWK">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type='text/css'><!--
        body {
                font-family: verdana, charcoal, helvetica, arial, sans-serif;
                font-size: small; color: #000; background-color: #FFF;
                margin: 2em;
        }
        h1, h2, h3, h4, h5, h6 {
                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
                font-weight: bold; font-style: normal;
        }
        h1 { color: #900; background-color: transparent; text-align: right; }
        h3 { color: #333; background-color: transparent; }

        td.RFCbug {
                font-size: x-small; text-decoration: none;
                width: 30px; height: 30px; padding-top: 2px;
                text-align: justify; vertical-align: middle;
                background-color: #000;
        }
        td.RFCbug span.RFC {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: bold; color: #666;
        }
        td.RFCbug span.hotText {
                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: normal; text-align: center; color: #FFF;
        }

        table.TOCbug { width: 30px; height: 15px; }
        td.TOCbug {
                text-align: center; width: 30px; height: 15px;
                color: #FFF; background-color: #900;
        }
        td.TOCbug a {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
                font-weight: bold; font-size: x-small; text-decoration: none;
                color: #FFF; background-color: transparent;
        }

        td.header {
                font-family: arial, helvetica, sans-serif; font-size: x-small;
                vertical-align: top; width: 33%;
                color: #FFF; background-color: #666;
        }
        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
        td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
        a.info {
                /* This is the key. */
                position: relative;
                z-index: 24;
                text-decoration: none;
        }
        a.info:hover {
                z-index: 25;
                color: #FFF; background-color: #900;
        }
        a.info span { display: none; }
        a.info:hover span.info {
                /* The span will display just on :hover state. */
                display: block;
                position: absolute;
                font-size: smaller;
                top: 2em; left: -5em; width: 15em;
                padding: 2px; border: 1px solid #333;
                color: #900; background-color: #EEE;
                text-align: left;
        }

        a { font-weight: bold; }
        a:link    { color: #900; background-color: transparent; }
        a:visited { color: #633; background-color: transparent; }
        a:active  { color: #633; background-color: transparent; }

        p { margin-left: 2em; margin-right: 2em; }
        p.copyright { font-size: x-small; }
        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

        ol.text { margin-left: 2em; margin-right: 2em; }
        ul.text { margin-left: 2em; margin-right: 2em; }
        li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */
        em     { font-style: italic; }
        strong { font-weight: bold; }
        dfn    { font-weight: bold; font-style: normal; }
        cite   { font-weight: normal; font-style: normal; }
        tt     { color: #036; }
        tt, pre, pre dfn, pre em, pre cite, pre span {
                font-family: "Courier New", Courier, monospace; font-size: small;
        }
        pre {
                text-align: left; padding: 4px;
                color: #000; background-color: #CCC;
        }
        pre dfn  { color: #900; }
        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
        pre .key { color: #33C; font-weight: bold; }
        pre .id  { color: #900; }
        pre .str { color: #000; background-color: #CFF; }
        pre .val { color: #066; }
        pre .rep { color: #909; }
        pre .oth { color: #000; background-color: #FCF; }
        pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */
        table.all, table.full, table.headers, table.none {
                font-size: small; text-align: center; border-width: 2px;
                vertical-align: top; border-collapse: collapse;
        }
        table.all, table.full { border-style: solid; border-color: black; }
        table.headers, table.none { border-style: none; }
        th {
                font-weight: bold; border-color: black;
                border-width: 2px 2px 3px 2px;
        }
        table.all th, table.full th { border-style: solid; }
        table.headers th { border-style: none none solid none; }
        table.none th { border-style: none; }
        table.all td {
                border-style: solid; border-color: #333;
                border-width: 1px 2px;
        }
        table.full td, table.headers td, table.none td { border-style: none; }

        hr { height: 1px; }
        hr.insert {
                width: 80%; border-style: none; border-width: 0;
                color: #CCC; background-color: #CCC;
        }
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">M. Jones</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">Microsoft</td></tr>
<tr><td class="header">Intended status: Standards Track</td><td class="header">E. Rescorla</td></tr>
<tr><td class="header">Expires: June 15, 2012</td><td class="header">RTFM, Inc.</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">J. Hildebrand</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">Cisco Systems, Inc.</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">December 13, 2011</td></tr>
</table></td></tr></table>
<h1><br />JSON Web Encryption (JWE)<br />draft-jones-json-web-encryption-02</h1>

<h3>Abstract</h3>

<p>
        JSON Web Encryption (JWE) is a means of representing encrypted
        content using JSON data structures.  Related signature
        capabilities are described in the separate JSON Web Signature
        (JWS) specification.
      
</p>
<h3>Requirements Language</h3>

<p>
        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 <a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., &ldquo;Key words for use in RFCs to Indicate Requirement Levels,&rdquo; March&nbsp;1997.</span><span>)</span></a> [RFC2119].
      
</p>
<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted  in full
conformance with the provisions of BCP&nbsp;78 and BCP&nbsp;79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF).  Note that other groups may also distribute
working documents as Internet-Drafts.  The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as &ldquo;work in progress.&rdquo;</p>
<p>
This Internet-Draft will expire on June 15, 2012.</p>

<h3>Copyright Notice</h3>
<p>
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors.  All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>&nbsp;
Introduction<br />
<a href="#anchor2">2.</a>&nbsp;
Terminology<br />
<a href="#anchor3">3.</a>&nbsp;
JSON Web Encryption (JWE) Overview<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#ExampleJWE">3.1.</a>&nbsp;
Example JWE<br />
<a href="#anchor4">4.</a>&nbsp;
JWE Header<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#ReservedHeaderParameterName">4.1.</a>&nbsp;
Reserved Header Parameter Names<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#PublicHeaderParameterName">4.2.</a>&nbsp;
Public Header Parameter Names<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#PrivateHeaderParameterName">4.3.</a>&nbsp;
Private Header Parameter Names<br />
<a href="#sec.encryption">5.</a>&nbsp;
Message Encryption<br />
<a href="#sec.decryption">6.</a>&nbsp;
Message Decryption<br />
<a href="#sec.encrypt_cek">7.</a>&nbsp;
CEK Encryption<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#sec.asymmetric_encryption">7.1.</a>&nbsp;
Asymmetric Encryption<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#sec.symmetric_encryption">7.2.</a>&nbsp;
Symmetric Encryption<br />
<a href="#sec.msg-composition">8.</a>&nbsp;
Composition<br />
<a href="#Encrypting">9.</a>&nbsp;
Encrypting JWEs with Cryptographic Algorithms<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#EncryptingWithTBD">9.1.</a>&nbsp;
Encrypting a JWE with TBD<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#MoreAlgs">9.2.</a>&nbsp;
Additional Algorithms<br />
<a href="#IANA">10.</a>&nbsp;
IANA Considerations<br />
<a href="#Security">11.</a>&nbsp;
Security Considerations<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor5">11.1.</a>&nbsp;
Unicode Comparison Security Issues<br />
<a href="#TBD">12.</a>&nbsp;
Open Issues and Things To Be Done (TBD)<br />
<a href="#rfc.references1">13.</a>&nbsp;
References<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#rfc.references1">13.1.</a>&nbsp;
Normative References<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#rfc.references2">13.2.</a>&nbsp;
Informative References<br />
<a href="#JWEExamples">Appendix&nbsp;A.</a>&nbsp;
JWE Examples<br />
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#TBDExample">A.1.</a>&nbsp;
JWE Example using TBD Algorithm<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor8">A.1.1.</a>&nbsp;
Encrypting<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor9">A.1.2.</a>&nbsp;
Decrypting<br />
<a href="#algxref">Appendix&nbsp;B.</a>&nbsp;
Algorithm Identifier Cross-Reference<br />
<a href="#Acknowledgements">Appendix&nbsp;C.</a>&nbsp;
Acknowledgements<br />
<a href="#anchor10">Appendix&nbsp;D.</a>&nbsp;
Document History<br />
<a href="#rfc.authors">&#167;</a>&nbsp;
Authors' Addresses<br />
</p>
<br clear="all" />

<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.&nbsp;
Introduction</h3>

<p>
        JSON Web Encryption (JWE) is a compact encryption format
        intended for space constrained environments such as HTTP
        Authorization headers and URI query parameters.  It provides a
        wrapper for encrypted content using JSON <a class='info' href='#RFC4627'>RFC 4627<span> (</span><span class='info'>Crockford, D., &ldquo;The application/json Media Type for JavaScript Object Notation (JSON),&rdquo; July&nbsp;2006.</span><span>)</span></a> [RFC4627] data structures.  The JWE
        encryption mechanisms are independent of the type of content
        being encrypted.  A related signature capability is described
        in a separate JSON Web Signature (JWS) <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, &ldquo;JSON Web Signature (JWS),&rdquo; December&nbsp;2011.</span><span>)</span></a>
        specification.
      
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.&nbsp;
Terminology</h3>

<p>
        </p>
<blockquote class="text"><dl>
<dt>JSON Web Encryption (JWE)</dt>
<dd>
            A data structure representing an encrypted version of a
            Plaintext.  The structure consists of three parts: the JWE
            Header, the JWE Encrypted Key, and the JWE Ciphertext.
          
</dd>
<dt>Plaintext</dt>
<dd>
            The bytes to be encrypted - a.k.a., the message.
          
</dd>
<dt>Ciphertext</dt>
<dd>
            The encrypted version of the Plaintext.
          
</dd>
<dt>Content Encryption Key (CEK)</dt>
<dd>
            A symmetric key generated to encrypt the Plaintext for the
            recipient to produce the Ciphertext, which is encrypted to
            the recipient as the JWE Encrypted Key.
          
</dd>
<dt>JWE Header</dt>
<dd>
            A string representing a JSON object that describes the
            encryption operations applied to create the JWE Encrypted
            Key and the JWE Ciphertext.
          
</dd>
<dt>JWE Encrypted Key</dt>
<dd>
            The Content Encryption Key (CEK) is encrypted with the
            intended recipient's key and the resulting encrypted
            content is recorded as a byte array, which is referred to
            as the JWE Encrypted Key.
          
</dd>
<dt>JWE Ciphertext</dt>
<dd>
            A byte array containing the Ciphertext.
          
</dd>
<dt>Encoded JWE Header</dt>
<dd>
            Base64url encoding of the bytes of the
            UTF-8 <a class='info' href='#RFC3629'>RFC 3629<span> (</span><span class='info'>Yergeau, F., &ldquo;UTF-8, a transformation format of ISO 10646,&rdquo; November&nbsp;2003.</span><span>)</span></a> [RFC3629]
            representation of the JWE Header.
          
</dd>
<dt>Encoded JWE Encrypted Key</dt>
<dd>
            Base64url encoding of the JWE Encrypted Key.
          
</dd>
<dt>Encoded JWE Ciphertext</dt>
<dd>
            Base64url encoding of the JWE Ciphertext.
          
</dd>
<dt>Header Parameter Names</dt>
<dd>
            The names of the members within the JWE Header.
          
</dd>
<dt>Header Parameter Values</dt>
<dd>
            The values of the members within the JWE Header.
          
</dd>
<dt>Base64url Encoding</dt>
<dd>
            For the purposes of this specification, this term always
            refers to the URL- and filename-safe Base64 encoding
            described in <a class='info' href='#RFC4648'>RFC 4648<span> (</span><span class='info'>Josefsson, S., &ldquo;The Base16, Base32, and Base64 Data Encodings,&rdquo; October&nbsp;2006.</span><span>)</span></a> [RFC4648],
            Section 5, with the (non URL-safe) '=' padding characters
            omitted, as permitted by Section 3.2.  (See Appendix C of
            <a class='info' href='#JWS'>[JWS]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, &ldquo;JSON Web Signature (JWS),&rdquo; December&nbsp;2011.</span><span>)</span></a> for notes on implementing base64url
            encoding without padding.)
          
</dd>
</dl></blockquote><p>
      
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.&nbsp;
JSON Web Encryption (JWE) Overview</h3>

<p>
        JWE represents encrypted content using JSON data
        structures and base64url encoding.  The representation
        consists of three parts: the JWE Header, the JWE Encrypted Key,
        and the JWE Ciphertext.  The three parts are
        base64url-encoded for transmission, and typically represented
        as the concatenation of the encoded strings in that order,
        with the three strings being separated by period ('.')
        characters.
      
</p>
<p>
        JWE utilizes encryption to ensure the confidentiality of the
        contents of the Plaintext.  JWE does not add a content
        integrity check if not provided by the underlying encryption
        algorithm.  If such a check is needed, an algorithm providing
        it such as AES-GCM <a class='info' href='#NIST-800-38D'>[NIST&#8209;800&#8209;38D]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Recommendation for Block Cipher Modes of Operation:     Galois/Counter Mode (GCM) and GMAC,&rdquo; December&nbsp;2001.</span><span>)</span></a> can be used,
        or alternatively, it can be provided through composition by
        encrypting a representation of the signed content.
      
</p>
<a name="ExampleJWE"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.&nbsp;
Example JWE</h3>

<p>
          The following example JWE Header declares that:
          </p>
<ul class="text">
<li>
              the Content Encryption Key is encrypted to the recipient
              using the RSA-PKCS1_1.5 algorithm to produce the JWE
              Encrypted Key,
            
</li>
<li>
              the Plaintext is encrypted using the AES-256-GCM
              algorithm to produce the JWE Ciphertext,
            
</li>
<li>
              the specified 64-bit Initialization Vector with the
              base64url encoding <tt>__79_Pv6-fg</tt> was used, and
            
</li>
<li>
              the thumbprint of the X.509 certificate that corresponds
              to the key used to encrypt the JWE has the base64url
              encoding <tt>7noOPq-hJ1_hCnvWh6IeYI2w9Q0</tt>.
            
</li>
</ul><p>
        
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{"alg":"RSA1_5",
 "enc":"A256GCM",
 "iv":"__79_Pv6-fg",
 "x5t":"7noOPq-hJ1_hCnvWh6IeYI2w9Q0"}</pre></div>
<p>
          Base64url encoding the bytes of the UTF-8 representation of
          the JWE Header yields this Encoded JWE Header value
          (with line breaks for display purposes only):
        
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>eyJhbGciOiJSU0ExXzUiLA0KICJlbmMiOiJBMjU2R0NNIiwNCiAiaXYiOiJfXzc5
X1B2Ni1mZyIsDQogIng1dCI6Ijdub09QcS1oSjFfaENudldoNkllWUkydzlRMCJ9</pre></div>
<p>
          TBD: Finish this example by showing generation of a Content
          Encryption Key (CEK), using the CEK to encrypt the Plaintext
          to produce the Ciphertext (and base64url encoding it), and
          using the recipient's key to encrypt the CEK to produce the
          JWE Encrypted Key (and base64url encoding it).
        
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.&nbsp;
JWE Header</h3>

<p>
        The members of the JSON object represented by the JWE Header
        describe the encryption applied to the Plaintext and optionally
        additional properties of the JWE.
        The Header Parameter Names within this object MUST be unique.
        Implementations MUST understand the
        entire contents of the header; otherwise, the JWE MUST be
        rejected for processing.
      
</p>
<a name="ReservedHeaderParameterName"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1.&nbsp;
Reserved Header Parameter Names</h3>

<p>
          The following header parameter names are reserved.  All the
          names are short because a core goal of JWE is for the
          representations to be compact.
        
</p>
<p>
          TBD: Describe the relationship between the JWS and JWE header
          parameters - especially the <tt>alg</tt>
          parameter, which can contain either signature algorithms
          (from JWS) or encryption algorithms (from JWE), and the key
          reference parameters <tt>jku</tt>, <tt>kid</tt>, <tt>x5u</tt>,
          and <tt>x5t</tt>.
        
</p><br /><hr class="insert" />
<a name="HeaderParameterTable"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left"><col align="left"><col align="left">
<tr><th align="left">Header Parameter Name</th><th align="left">JSON Value Type</th><th align="left">Header Parameter Syntax</th><th align="left">Header Parameter Semantics</th></tr>
<tr>
<td align="left">alg</td>
<td align="left">string</td>
<td align="left">StringOrURI</td>
<td align="left">
            The <tt>alg</tt> (algorithm) header
            parameter identifies the cryptographic algorithm used to
            secure the JWE Encrypted Key.  A list of defined <tt>alg</tt> values is presented in <a class='info' href='#AlgTable'>Table&nbsp;3<span> (</span><span class='info'>JWE Defined &quot;alg&quot; Parameter Values</span><span>)</span></a>.
            The processing of the <tt>alg</tt>
            (algorithm) header parameter requires that the value MUST
            be one that is both supported and for which there exists a
            key for use with that algorithm associated with the
            intended recipient.  The <tt>alg</tt>
            value is case sensitive.
            This header parameter is REQUIRED.
          </td>
</tr>
<tr>
<td align="left">enc</td>
<td align="left">string</td>
<td align="left">StringOrURI</td>
<td align="left">
            The <tt>enc</tt> (encryption
            method) header parameter identifies the symmetric
            encryption algorithm used to secure the Ciphertext.  A
            list of defined <tt>enc</tt> values is
            presented in <a class='info' href='#EncTable'>Table&nbsp;4<span> (</span><span class='info'>JWE Defined &quot;enc&quot; Parameter Values</span><span>)</span></a>.  The
            processing of the <tt>enc</tt>
            (encryption method) header parameter requires that the
            value MUST be one that is supported.  The <tt>enc</tt> value is case sensitive.  This
            header parameter is REQUIRED.
          </td>
</tr>
<tr>
<td align="left">iv</td>
<td align="left">string</td>
<td align="left">String</td>
<td align="left">
            Initialization Vector (<tt>iv</tt>)
            value for algorithms requiring it, represented as a
            base64url encoded string.
            This header parameter is OPTIONAL.
          </td>
</tr>
<tr>
<td align="left">epk</td>
<td align="left">object</td>
<td align="left">JWK Key Object</td>
<td align="left">
            Ephemeral Public Key (<tt>epk</tt>)
            value created by the originator for the use in ECDH-ES
            <a class='info' href='#RFC6090'>RFC 6090<span> (</span><span class='info'>McGrew, D., Igoe, K., and M. Salter, &ldquo;Fundamental Elliptic Curve Cryptography Algorithms,&rdquo; February&nbsp;2011.</span><span>)</span></a> [RFC6090]
            encryption.  This key is represented in the same manner as
            a JSON Web Key <a class='info' href='#JWK'>[JWK]<span> (</span><span class='info'>Jones, M., &ldquo;JSON Web Key (JWK),&rdquo; December&nbsp;2011.</span><span>)</span></a> JWK Key Object value,
            containing <tt>crv</tt> (curve), <tt>x</tt>, and <tt>y</tt>
            members.  The inclusion of the JWK Key Object <tt>alg</tt> (algorithm) member is OPTIONAL.
            This header parameter is OPTIONAL.
          </td>
</tr>
<tr>
<td align="left">zip</td>
<td align="left">string</td>
<td align="left">String</td>
<td align="left">
            Compression algorithm (<tt>zip</tt>)
            applied to the Plaintext before encryption, if any.
            This specification defines the value <tt>GZIP</tt> to refer to the encoding format
            produced by the file compression program "gzip" (GNU zip)
            as described in <a class='info' href='#RFC1952'>[RFC1952]<span> (</span><span class='info'>Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and G. Randers-Pehrson, &ldquo;GZIP file format specification version 4.3,&rdquo; May&nbsp;1996.</span><span>)</span></a>; this format is
            a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
            If no <tt>zip</tt> parameter is present, or its
            value is <tt>none</tt>, no compression
            is applied to the Plaintext before encryption.  The <tt>zip</tt> value is case sensitive.  This
            header parameter is OPTIONAL.
          </td>
</tr>
<tr>
<td align="left">jku</td>
<td align="left">string</td>
<td align="left">URL</td>
<td align="left">
            The <tt>jku</tt> (JSON Web Key URL)
            header parameter is an absolute URL that refers to a
            resource for a set of JSON-encoded public keys, one of
            which corresponds to the key that was used to encrypt the
            JWE.
            The keys MUST be encoded as described in the JSON Web Key
            (JWK) <a class='info' href='#JWK'>[JWK]<span> (</span><span class='info'>Jones, M., &ldquo;JSON Web Key (JWK),&rdquo; December&nbsp;2011.</span><span>)</span></a> specification.
            The protocol used to acquire the resource MUST provide
            integrity protection.  An HTTP GET request to retrieve the
            certificate MUST use TLS <a class='info' href='#RFC2818'>RFC
            2818<span> (</span><span class='info'>Rescorla, E., &ldquo;HTTP Over TLS,&rdquo; May&nbsp;2000.</span><span>)</span></a> [RFC2818] <a class='info' href='#RFC5246'>RFC 5246<span> (</span><span class='info'>Dierks, T. and E. Rescorla, &ldquo;The Transport Layer Security (TLS) Protocol Version 1.2,&rdquo; August&nbsp;2008.</span><span>)</span></a> [RFC5246] with
            server authentication <a class='info' href='#RFC6125'>RFC
            6125<span> (</span><span class='info'>Saint-Andre, P. and J. Hodges, &ldquo;Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),&rdquo; March&nbsp;2011.</span><span>)</span></a> [RFC6125].
            This header parameter is OPTIONAL.
          </td>
</tr>
<tr>
<td align="left">kid</td>
<td align="left">string</td>
<td align="left">String</td>
<td align="left">
            The <tt>kid</tt> (key ID) header
            parameter is a hint indicating which key was used to
            encrypt the JWE.  This
            allows originators to explicitly signal a change of key to
            recipients.  The interpretation of the
            contents of the <tt>kid</tt> parameter
            is unspecified.
            This header parameter is OPTIONAL.
          </td>
</tr>
<tr>
<td align="left">x5u</td>
<td align="left">string</td>
<td align="left">URL</td>
<td align="left">
            The <tt>x5u</tt> (X.509 URL) header
            parameter is an absolute URL that refers to a resource for
            the X.509 public key certificate or certificate chain
            corresponding to the key used to encrypt the JWE.
            The identified resource MUST provide a representation of
            the certificate or certificate chain that conforms to
            <a class='info' href='#RFC5280'>RFC 5280<span> (</span><span class='info'>Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, &ldquo;Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,&rdquo; May&nbsp;2008.</span><span>)</span></a> [RFC5280] in PEM encoded form
            <a class='info' href='#RFC1421'>RFC 1421<span> (</span><span class='info'>Linn, J., &ldquo;Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures,&rdquo; February&nbsp;1993.</span><span>)</span></a> [RFC1421].
            The protocol used to acquire the resource MUST provide
            integrity protection.  An HTTP GET request to retrieve the
            certificate MUST use TLS <a class='info' href='#RFC2818'>RFC
            2818<span> (</span><span class='info'>Rescorla, E., &ldquo;HTTP Over TLS,&rdquo; May&nbsp;2000.</span><span>)</span></a> [RFC2818] <a class='info' href='#RFC5246'>RFC 5246<span> (</span><span class='info'>Dierks, T. and E. Rescorla, &ldquo;The Transport Layer Security (TLS) Protocol Version 1.2,&rdquo; August&nbsp;2008.</span><span>)</span></a> [RFC5246] with
            server authentication <a class='info' href='#RFC6125'>RFC
            6125<span> (</span><span class='info'>Saint-Andre, P. and J. Hodges, &ldquo;Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS),&rdquo; March&nbsp;2011.</span><span>)</span></a> [RFC6125].
            This header parameter is OPTIONAL.
          </td>
</tr>
<tr>
<td align="left">x5t</td>
<td align="left">string</td>
<td align="left">String</td>
<td align="left">
            The <tt>x5t</tt> (x.509 certificate
            thumbprint) header parameter provides a base64url encoded
            SHA-1 thumbprint (a.k.a. digest) of the DER encoding of
            the X.509 certificate that corresponds to the key that was
            used to encrypt the JWE.
            This header parameter is OPTIONAL.
          </td>
</tr>
<tr>
<td align="left">typ</td>
<td align="left">string</td>
<td align="left">String</td>
<td align="left">
            The <tt>typ</tt> (type) header
            parameter is used to declare the type of the encrypted
            content.
            The <tt>typ</tt> value is case sensitive.
            This header parameter is OPTIONAL.
          </td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 1: Reserved Header Parameter Definitions&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>
          Additional reserved header parameter names MAY be defined
          via the IANA JSON Web Encryption Header Parameters registry,
          as per <a class='info' href='#IANA'>Section&nbsp;10<span> (</span><span class='info'>IANA Considerations</span><span>)</span></a>.  The syntax values used above
          are defined as follows:
        
</p><br /><hr class="insert" />
<a name="SyntaxDefinitions"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">Syntax Name</th><th align="left">Syntax Definition</th></tr>
<tr>
<td align="left">String</td>
<td align="left">
            Any string value MAY be used.
          </td>
</tr>
<tr>
<td align="left">StringOrURI</td>
<td align="left">
            Any string value MAY be used but a value containing a ":"
            character MUST be a URI as defined in <a class='info' href='#RFC3986'>RFC 3986<span> (</span><span class='info'>Berners-Lee, T., Fielding, R., and L. Masinter, &ldquo;Uniform Resource Identifier (URI): Generic Syntax,&rdquo; January&nbsp;2005.</span><span>)</span></a> [RFC3986].
          </td>
</tr>
<tr>
<td align="left">URL</td>
<td align="left">
            A URL as defined in <a class='info' href='#RFC1738'>RFC 1738<span> (</span><span class='info'>Berners-Lee, T., Masinter, L., and M. McCahill, &ldquo;Uniform Resource Locators (URL),&rdquo; December&nbsp;1994.</span><span>)</span></a> [RFC1738].
          </td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 2: Header Parameter Syntax Definitions&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<a name="PublicHeaderParameterName"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4.2"></a><h3>4.2.&nbsp;
Public Header Parameter Names</h3>

<p>
          Additional header parameter names can be defined by those
          using JWE. However, in order to prevent collisions, any new
          header parameter name or algorithm value SHOULD either be
          defined in the IANA JSON Web Encryption Header Parameters
          registry or be defined as a URI that contains a collision
          resistant namespace.  In each case, the definer of the name
          or value needs to take reasonable precautions to make sure they
          are in control of the part of the namespace they use to
          define the header parameter name.
        
</p>
<p>
          New header parameters should be introduced sparingly, as
          they can result in non-interoperable JWEs.
        
</p>
<a name="PrivateHeaderParameterName"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.4.3"></a><h3>4.3.&nbsp;
Private Header Parameter Names</h3>

<p>
          A producer and consumer of a JWE may agree to any header
          parameter name that is not a Reserved Name <a class='info' href='#ReservedHeaderParameterName'>Section&nbsp;4.1<span> (</span><span class='info'>Reserved Header Parameter Names</span><span>)</span></a> or a Public
          Name <a class='info' href='#PublicHeaderParameterName'>Section&nbsp;4.2<span> (</span><span class='info'>Public Header Parameter Names</span><span>)</span></a>. Unlike Public
          Names, these private names are subject to collision and
          should be used with caution.
        
</p>
<p>
          New header parameters should be introduced sparingly, as
          they can result in non-interoperable JWEs.
        
</p>
<a name="sec.encryption"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.&nbsp;
Message Encryption</h3>

<p>The message encryption process is as follows:
</p>
<p></p>
<ol class="text">
<li>
            Generate a random Content Encryption Key (CEK). The CEK
            MUST have a length at least equal to that of the required
            encryption keys and MUST be generated randomly.  See <a class='info' href='#RFC4086'>RFC 4086<span> (</span><span class='info'>Eastlake, D., Schiller, J., and S. Crocker, &ldquo;Randomness Requirements for Security,&rdquo; June&nbsp;2005.</span><span>)</span></a> [RFC4086] for considerations on
            generating random values.
          
</li>
<li>
            Encrypt the CEK for the recipient (see <a class='info' href='#sec.encrypt_cek'>Section&nbsp;7<span> (</span><span class='info'>CEK Encryption</span><span>)</span></a>).
          
</li>
<li>
            Generate a random IV (if required for the algorithm).
          
</li>
<li>
            Compress the Plaintext if a <tt>zip</tt> parameter was included.
          
</li>
<li>
            Serialize the (compressed) Plaintext into a bitstring M.
          
</li>
<li>
            Encrypt M using the CEK and IV to form the bitstring C.
          
</li>
<li>
            Set the Encoded JWE Ciphertext equal to the base64url encoded
            representation of C.
          
</li>
<li>
            Create a JWE Header containing the encryption
            parameters used.
            Note that white space is explicitly allowed
            in the representation and no canonicalization is performed
            before encoding.
          
</li>
<li>
            Base64url encode the bytes of the UTF-8 representation of
            the JWE Header to create the Encoded JWE Header.
          
</li>
<li>
            The three encoded parts, taken together, are the result of
            the encryption.
          
</li>
</ol>

<a name="sec.decryption"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.&nbsp;
Message Decryption</h3>

<p>The message decryption process is the reverse of the encryption
      process.  If any of these steps fails, the JWE MUST be rejected.
</p>
<p>
        </p>
<ol class="text">
<li>
            The Encoded JWE Header, the Encoded JWE Encrypted Key, and
            the Encoded JWE Ciphertext MUST be successfully base64url
            decoded following the restriction that no padding
            characters have been used.
          
</li>
<li>
            The resulting JWE Header MUST be completely valid
            JSON syntax conforming to <a class='info' href='#RFC4627'>RFC
            4627<span> (</span><span class='info'>Crockford, D., &ldquo;The application/json Media Type for JavaScript Object Notation (JSON),&rdquo; July&nbsp;2006.</span><span>)</span></a> [RFC4627].
          
</li>
<li>
            The resulting JWE Header MUST be validated to only include
            parameters and values whose syntax and semantics are both
            understood and supported.
          
</li>
<li>
            Verify that the JWE Header appears to reference a key
            known to the recipient.
          
</li>
<li>
            Decrypt the JWE Encrypted Key to produce the CEK.
          
</li>
<li>
            Decrypt the binary representation of the JWE Ciphertext
            using the CEK.
          
</li>
<li>
            Uncompress the result of the previous step, if a <tt>zip</tt> parameter was included.
          
</li>
<li>
            Output the result.
          
</li>
</ol><p>
      
</p>
<a name="sec.encrypt_cek"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7"></a><h3>7.&nbsp;
CEK Encryption</h3>

<p>
        JWE supports two forms of CEK encryption:
      
</p>
<p>
        </p>
<ul class="text">
<li>
            Asymmetric encryption under the recipient's public key.
          
</li>
<li>
            Symmetric encryption under a shared key.
          
</li>
</ul><p>
      
</p>
<a name="sec.asymmetric_encryption"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.1"></a><h3>7.1.&nbsp;
Asymmetric Encryption</h3>

<p>
          In the asymmetric encryption mode, the CEK is encrypted
          under the recipient's public key. The asymmetric encryption
          modes defined for use with this in this specification are
          listed in in <a class='info' href='#AlgTable'>Table&nbsp;3<span> (</span><span class='info'>JWE Defined &quot;alg&quot; Parameter Values</span><span>)</span></a>.
        
</p>
<a name="sec.symmetric_encryption"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.7.2"></a><h3>7.2.&nbsp;
Symmetric Encryption</h3>

<p>
          In the symmetric encryption mode, the CEK is encrypted under
          a symmetric key shared between the sender and receiver.
          
          The symmetric encryption modes defined for use with this in
          this specification are listed in in <a class='info' href='#AlgTable'>Table&nbsp;3<span> (</span><span class='info'>JWE Defined &quot;alg&quot; Parameter Values</span><span>)</span></a>.
          For GCM, the random 64-bit IV is prepended to the ciphertext.
        
</p>
<a name="sec.msg-composition"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.8"></a><h3>8.&nbsp;
Composition</h3>

<p>
        This document does not specify a combination signed and
        encrypted mode. However, because the contents of a message can
        be arbitrary, encryption and data origin authentication
        can be provided by recursively encapsulating multiple JWE and
        JWS messages. In general, senders SHOULD sign the message and
        then encrypt the result (thus encrypting the signature). This
        prevents attacks in which the signature is stripped, leaving
        just an encrypted message, as well as providing privacy for
        the signer.
      
</p>
<a name="Encrypting"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.9"></a><h3>9.&nbsp;
Encrypting JWEs with Cryptographic Algorithms</h3>

<p>
        JWE uses cryptographic algorithms to encrypt the Content
        Encryption Key (CEK) and the Plaintext.  This section
        specifies a set of specific algorithms for these purposes.
      
</p>
<p>
        The table below <a class='info' href='#AlgTable'>Table&nbsp;3<span> (</span><span class='info'>JWE Defined &quot;alg&quot; Parameter Values</span><span>)</span></a> is the set of
        <tt>alg</tt> header parameter values that
        are defined by this specification.  These algorithms are used
        to encrypt the CEK, which produces the JWE Encrypted Key.
      
</p><br /><hr class="insert" />
<a name="AlgTable"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">alg Parameter Value</th><th align="left">Encryption Algorithm</th></tr>
<tr>
<td align="left">RSA1_5</td>
<td align="left">RSA using RSA-PKCS1-1.5 padding, as defined in <a class='info' href='#RFC3447'>RFC 3447<span> (</span><span class='info'>Jonsson, J. and B. Kaliski, &ldquo;Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,&rdquo; February&nbsp;2003.</span><span>)</span></a> [RFC3447]</td>
</tr>
<tr>
<td align="left">RSA-OAEP</td>
<td align="left">RSA using Optimal Asymmetric Encryption Padding (OAEP), as
        defined in <a class='info' href='#RFC3447'>RFC 3447<span> (</span><span class='info'>Jonsson, J. and B. Kaliski, &ldquo;Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,&rdquo; February&nbsp;2003.</span><span>)</span></a> [RFC3447]</td>
</tr>
<tr>
<td align="left">ECDH-ES</td>
<td align="left">Elliptic Curve Diffie-Hellman Ephemeral Static, as defined
        in <a class='info' href='#RFC6090'>RFC 6090<span> (</span><span class='info'>McGrew, D., Igoe, K., and M. Salter, &ldquo;Fundamental Elliptic Curve Cryptography Algorithms,&rdquo; February&nbsp;2011.</span><span>)</span></a> [RFC6090], and using the
        Concat KDF, as defined in <a class='info' href='#NIST-800-56A'>[NIST&#8209;800&#8209;56A]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised),&rdquo; March&nbsp;2007.</span><span>)</span></a>,
        where the Digest Method is SHA-256</td>
</tr>
<tr>
<td align="left">A128KW</td>
<td align="left">Advanced Encryption Standard (AES) Key Wrap Algorithm using
        128 bit keys, as defined in <a class='info' href='#RFC3394'>RFC
        3394<span> (</span><span class='info'>Schaad, J. and R. Housley, &ldquo;Advanced Encryption Standard (AES) Key Wrap Algorithm,&rdquo; September&nbsp;2002.</span><span>)</span></a> [RFC3394]</td>
</tr>
<tr>
<td align="left">A256KW</td>
<td align="left">Advanced Encryption Standard (AES) Key Wrap Algorithm using
        256 bit keys, as defined in <a class='info' href='#RFC3394'>RFC
        3394<span> (</span><span class='info'>Schaad, J. and R. Housley, &ldquo;Advanced Encryption Standard (AES) Key Wrap Algorithm,&rdquo; September&nbsp;2002.</span><span>)</span></a> [RFC3394]</td>
</tr>
<tr>
<td align="left">A128GCM</td>
<td align="left">Advanced Encryption Standard (AES) using 128 bit keys in
        Galois/Counter Mode, as defined in <a class='info' href='#FIPS-197'>[FIPS&#8209;197]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Advanced Encryption Standard (AES),&rdquo; November&nbsp;2001.</span><span>)</span></a>
        and <a class='info' href='#NIST-800-38D'>[NIST&#8209;800&#8209;38D]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Recommendation for Block Cipher Modes of Operation:    Galois/Counter Mode (GCM) and GMAC,&rdquo; December&nbsp;2001.</span><span>)</span></a></td>
</tr>
<tr>
<td align="left">A256GCM</td>
<td align="left">Advanced Encryption Standard (AES) using 256 bit keys in
        Galois/Counter Mode, as defined in <a class='info' href='#FIPS-197'>[FIPS&#8209;197]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Advanced Encryption Standard (AES),&rdquo; November&nbsp;2001.</span><span>)</span></a>
        and <a class='info' href='#NIST-800-38D'>[NIST&#8209;800&#8209;38D]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Recommendation for Block Cipher Modes of Operation:    Galois/Counter Mode (GCM) and GMAC,&rdquo; December&nbsp;2001.</span><span>)</span></a></td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 3: JWE Defined "alg" Parameter Values&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>
        The table below <a class='info' href='#EncTable'>Table&nbsp;4<span> (</span><span class='info'>JWE Defined &quot;enc&quot; Parameter Values</span><span>)</span></a> is the set of
        <tt>enc</tt> header parameter values that
        are defined by this specification.  These algorithms are used
        to encrypt the Plaintext, which produces the Ciphertext.
      
</p><br /><hr class="insert" />
<a name="EncTable"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left">
<tr><th align="left">enc Parameter Value</th><th align="left">Symmetric Encryption Algorithm</th></tr>
<tr>
<td align="left">A128CBC</td>
<td align="left">Advanced Encryption Standard (AES) using 128 bit keys in
        Cipher Block Chaining mode, as defined in <a class='info' href='#FIPS-197'>[FIPS&#8209;197]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Advanced Encryption Standard (AES),&rdquo; November&nbsp;2001.</span><span>)</span></a>
        and <a class='info' href='#NIST-800-38A'>[NIST&#8209;800&#8209;38A]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Recommendation for Block Cipher Modes of Operation,&rdquo; December&nbsp;2001.</span><span>)</span></a></td>
</tr>
<tr>
<td align="left">A256CBC</td>
<td align="left">Advanced Encryption Standard (AES) using 256 bit keys in
        Cipher Block Chaining mode, as defined in <a class='info' href='#FIPS-197'>[FIPS&#8209;197]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Advanced Encryption Standard (AES),&rdquo; November&nbsp;2001.</span><span>)</span></a>
        and <a class='info' href='#NIST-800-38A'>[NIST&#8209;800&#8209;38A]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Recommendation for Block Cipher Modes of Operation,&rdquo; December&nbsp;2001.</span><span>)</span></a></td>
</tr>
<tr>
<td align="left">A128GCM</td>
<td align="left">Advanced Encryption Standard (AES) using 128 bit keys in
        Galois/Counter Mode, as defined in <a class='info' href='#FIPS-197'>[FIPS&#8209;197]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Advanced Encryption Standard (AES),&rdquo; November&nbsp;2001.</span><span>)</span></a>
        and <a class='info' href='#NIST-800-38D'>[NIST&#8209;800&#8209;38D]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Recommendation for Block Cipher Modes of Operation:    Galois/Counter Mode (GCM) and GMAC,&rdquo; December&nbsp;2001.</span><span>)</span></a></td>
</tr>
<tr>
<td align="left">A256GCM</td>
<td align="left">Advanced Encryption Standard (AES) using 256 bit keys in
        Galois/Counter Mode, as defined in <a class='info' href='#FIPS-197'>[FIPS&#8209;197]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Advanced Encryption Standard (AES),&rdquo; November&nbsp;2001.</span><span>)</span></a>
        and <a class='info' href='#NIST-800-38D'>[NIST&#8209;800&#8209;38D]<span> (</span><span class='info'>National Institute of Standards and Technology (NIST), &ldquo;Recommendation for Block Cipher Modes of Operation:    Galois/Counter Mode (GCM) and GMAC,&rdquo; December&nbsp;2001.</span><span>)</span></a></td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 4: JWE Defined "enc" Parameter Values&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<p>
        Of these algorithms, only RSA-PKCS1-1.5 with 2048 bit keys,
        AES-128-CBC, and AES-256-CBC MUST be implemented by conforming
        implementations.  It is RECOMMENDED that implementations also
        support ECDH-ES with 256 bit keys, AES-128-GCM, and
        AES-256-GCM.  Support for other algorithms and key sizes is
        OPTIONAL.
      
</p>
<a name="EncryptingWithTBD"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.9.1"></a><h3>9.1.&nbsp;
Encrypting a JWE with TBD</h3>

<p>
          TBD: Descriptions of the particulars of using each specified
          algorithm go here.
        
</p>
<a name="MoreAlgs"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.9.2"></a><h3>9.2.&nbsp;
Additional Algorithms</h3>

<p>
          Additional algorithms MAY be used to protect JWEs with
          corresponding <tt>alg</tt> and <tt>enc</tt> header parameter values being
          defined to refer to them. New <tt>alg</tt> and <tt>enc</tt>
          header parameter values SHOULD either be defined in the IANA
          JSON Web Encryption Algorithms registry or be a URI that
          contains a collision resistant namespace.  In particular,
          it is permissible to use the algorithm identifiers defined in
          <a class='info' href='#W3C.REC-xmlenc-core-20021210'>XML Encryption<span> (</span><span class='info'>Eastlake, D. and J. Reagle, &ldquo;XML Encryption Syntax and Processing,&rdquo; December&nbsp;2002.</span><span>)</span></a> [W3C.REC&#8209;xmlenc&#8209;core&#8209;20021210],
          <a class='info' href='#W3C.CR-xmlenc-core1-20110303'>XML Encryption 1.1<span> (</span><span class='info'>Hirsch, F., Roessler, T., Reagle, J., and D. Eastlake, &ldquo;XML Encryption Syntax and Processing Version 1.1,&rdquo; March&nbsp;2011.</span><span>)</span></a> [W3C.CR&#8209;xmlenc&#8209;core1&#8209;20110303],
          and related specifications as <tt>alg</tt>
          and <tt>enc</tt> values.
        
</p>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.10"></a><h3>10.&nbsp;
IANA Considerations</h3>

<p>
        This specification calls for:

        </p>
<ul class="text">
<li>
            A new IANA registry entitled "JSON Web Encryption Header
            Parameters" for reserved header parameter names is defined
            in <a class='info' href='#ReservedHeaderParameterName'>Section&nbsp;4.1<span> (</span><span class='info'>Reserved Header Parameter Names</span><span>)</span></a>.
            Inclusion in the registry is RFC Required in the <a class='info' href='#RFC5226'>RFC 5226<span> (</span><span class='info'>Narten, T. and H. Alvestrand, &ldquo;Guidelines for Writing an IANA Considerations Section in RFCs,&rdquo; May&nbsp;2008.</span><span>)</span></a> [RFC5226] sense for reserved JWE
            header parameter names that are intended to be
            interoperable between implementations.  The registry will
            just record the reserved header parameter name and a
            pointer to the RFC that defines it. This specification
            defines inclusion of the header parameter names defined in
            <a class='info' href='#HeaderParameterTable'>Table&nbsp;1<span> (</span><span class='info'>Reserved Header Parameter Definitions</span><span>)</span></a>.
          
</li>
<li>
            A new IANA registry entitled "JSON Web Encryption
            Algorithms" for values used with the <tt>alg</tt> and <tt>enc</tt> header parameters is
            defined in <a class='info' href='#MoreAlgs'>Section&nbsp;9.2<span> (</span><span class='info'>Additional Algorithms</span><span>)</span></a>. Inclusion in
            the registry is RFC Required in the <a class='info' href='#RFC5226'>RFC 5226<span> (</span><span class='info'>Narten, T. and H. Alvestrand, &ldquo;Guidelines for Writing an IANA Considerations Section in RFCs,&rdquo; May&nbsp;2008.</span><span>)</span></a> [RFC5226] sense. The registry will
            record the <tt>alg</tt> or <tt>enc</tt> value and a pointer to the RFC
            that defines it.  This specification defines inclusion of
            the algorithm values defined in <a class='info' href='#AlgTable'>Table&nbsp;3<span> (</span><span class='info'>JWE Defined &quot;alg&quot; Parameter Values</span><span>)</span></a> and <a class='info' href='#EncTable'>Table&nbsp;4<span> (</span><span class='info'>JWE Defined &quot;enc&quot; Parameter Values</span><span>)</span></a>.
          
</li>
</ul><p>
      
</p>
<a name="Security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.11"></a><h3>11.&nbsp;
Security Considerations</h3>

<p>
        TBD: Lots of work to do here. We need to remember to look into
        any issues relating to security and JSON parsing. One wonders
        just how secure most JSON parsing libraries are. Were they
        ever hardened for security scenarios? If not, what kind of
        holes does that open up? Also, we need to walk through the
        JSON standard and see what kind of issues we have especially
        around comparison of names.  For instance, comparisons of
        header parameter names and other parameters must occur after
        they are unescaped. Need to also put in text about: Importance
        of keeping secrets secret. Rotating keys. Strengths and
        weaknesses of the different algorithms.
      
</p>
<p>
        TBD: Need to put in text about why strict JSON validation is
        necessary.  Basically, that if malformed JSON is received then
        the intent of the sender is impossible to reliably discern.
        One example of malformed JSON that MUST be rejected is
        an object in which the same member name occurs multiple times.
      
</p>
<p>
        TBD: We need a section on generating randomness in browsers
        - it's easy to screw up.
      
</p>
<p>
        When utilizing TLS to retrieve information, the authority
        providing the resource MUST be authenticated and the
        information retrieved MUST be free from modification.
      
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.11.1"></a><h3>11.1.&nbsp;
Unicode Comparison Security Issues</h3>

<p>
          Header parameter names in JWEs are Unicode strings.  For
          security reasons, the representations of these names must be
          compared verbatim after performing any escape processing (as
          per <a class='info' href='#RFC4627'>RFC 4627<span> (</span><span class='info'>Crockford, D., &ldquo;The application/json Media Type for JavaScript Object Notation (JSON),&rdquo; July&nbsp;2006.</span><span>)</span></a> [RFC4627], Section 2.5).
        
</p>
<p>
          This means, for instance, that these JSON strings must
          compare as being equal ("enc", "\u0065nc"), whereas these
          must all compare as being not equal to the first set or to
          each other ("ENC", "Enc", "en\u0043").
        
</p>
<p>
          JSON strings MAY contain characters outside the Unicode
          Basic Multilingual Plane.  For instance, the G clef
          character (U+1D11E) may be represented in a JSON string as
          "\uD834\uDD1E".  Ideally, JWE implementations SHOULD ensure
          that characters outside the Basic Multilingual Plane are
          preserved and compared correctly; alternatively, if this is
          not possible due to these characters exercising limitations
          present in the underlying JSON implementation, then input
          containing them MUST be rejected.
        
</p>
<a name="TBD"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.12"></a><h3>12.&nbsp;
Open Issues and Things To Be Done (TBD)</h3>

<p>
        The following items remain to be done in this draft:

        </p>
<ul class="text">
<li>
            Describe the relationship between the JWE, JWS, and JWT
            header parameters.  In particular, point out that the set of
            "alg" values defined by each must be compatible and
            non-overlapping.
          
</li>
<li>
            Consider whether we want to define composite
            signing/encryption operations (as was the consensus to do
            at IIW, as documented at http://self-issued.info/?p=378).
            This would provide both confidentiality and integrity.
          
</li>
<li>
            Consider whether reusing the JWS <tt>jku</tt>, <tt>kid</tt>,
            <tt>x5u</tt>, and <tt>x5t</tt> parameters is the right thing to
            do, particularly as it effectively precludes specifying
            composite operations.
          
</li>
<li>
            Consider whether to add parameters for directly including
            keys in the header, either as JWK Key Objects, or X.509
            cert values, or both.
          
</li>
<li>
            Consider whether to add version numbers.
          
</li>
<li>
            Consider which of the open issues from the JWS and JWT specs
            also apply here.
          
</li>
<li>
            Think about how to best describe the concept currently
            described as "the bytes of the UTF-8 representation of".
            Possible terms to use instead of "bytes of" include "byte
            sequence", "octet series", and "octet sequence".  Also
            consider whether we want to add an overall clarifying
            statement somewhere in each spec something like "every
            place we say 'the UTF-8 representation of X', we mean 'the
            bytes of the UTF-8 representation of X'".  That would
            potentially allow us to omit the "the bytes of" part
            everywhere else.
          
</li>
<li>
            Finish the Security Considerations section.
          
</li>
<li>
            Write a note in the Security Considerations section about
            how <tt>x5t</tt> (x.509 certificate
            thumbprint) should be deprecated because of known problems
            with SHA-1.
          
</li>
<li>
            Should StringOrURI use IRIs rather than RFC 3986 URIs?
          
</li>
<li>
            Provide a more robust description of the use of the IV.
            The current statement "For GCM, the random 64-bit IV is
            prepended to the ciphertext" in the Symmetric Encryption
            section is almost certainly out of place.
          
</li>
<li>
            It would be good to say somewhere, in normative language,
            that eventually the algorithms and/or key sizes currently
            specified will no longer be considered sufficiently secure
            and will be removed.  Therefore, implementers MUST be
            prepared for this eventuality.
          
</li>
<li>
            Should we define the use of RFC 5649 key wrapping
            functions, which allow arbitrary key sizes, in addition to
            the current use of RFC 3394 key wrapping functions, which
            require that keys be multiples of 64 bits?  Is this needed
            in practice?
          
</li>
</ul><p>
      
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.13"></a><h3>13.&nbsp;
References</h3>

<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>13.1.&nbsp;Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="FIPS-197">[FIPS-197]</a></td>
<td class="author-text">National Institute of Standards and Technology (NIST), &ldquo;Advanced Encryption Standard (AES),&rdquo; FIPS&nbsp;PUB 197, November&nbsp;2001.</td></tr>
<tr><td class="author-text" valign="top"><a name="JWK">[JWK]</a></td>
<td class="author-text"><a href="mailto:mbj@microsoft.com">Jones, M.</a>, &ldquo;<a href="http://tools.ietf.org/html/draft-jones-json-web-key">JSON Web Key (JWK)</a>,&rdquo; December&nbsp;2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="JWS">[JWS]</a></td>
<td class="author-text"><a href="mailto:mbj@microsoft.com">Jones, M.</a>, <a href="mailto:balfanz@google.com">Balfanz, D.</a>, <a href="mailto:ve7jtb@ve7jtb.com">Bradley, J.</a>, <a href="mailto:yarong@microsoft.com">Goland, Y.</a>, <a href="mailto:jpanzer@google.com">Panzer, J.</a>, <a href="mailto:n-sakimura@nri.co.jp">Sakimura, N.</a>, and <a href="mailto:pt@fb.com">P. Tarjan</a>, &ldquo;<a href="http://tools.ietf.org/html/draft-jones-json-web-signature">JSON Web Signature (JWS)</a>,&rdquo; December&nbsp;2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="NIST-800-38A">[NIST-800-38A]</a></td>
<td class="author-text">National Institute of Standards and Technology (NIST), &ldquo;Recommendation for Block Cipher Modes of Operation,&rdquo; NIST&nbsp;PUB 800-38A, December&nbsp;2001.</td></tr>
<tr><td class="author-text" valign="top"><a name="NIST-800-38D">[NIST-800-38D]</a></td>
<td class="author-text">National Institute of Standards and Technology (NIST), &ldquo;Recommendation for Block Cipher Modes of Operation:
          Galois/Counter Mode (GCM) and GMAC,&rdquo; NIST&nbsp;PUB 800-38D, December&nbsp;2001.</td></tr>
<tr><td class="author-text" valign="top"><a name="NIST-800-56A">[NIST-800-56A]</a></td>
<td class="author-text">National Institute of Standards and Technology (NIST), &ldquo;Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised),&rdquo; NIST&nbsp;PUB 800-56A, March&nbsp;2007.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1421">[RFC1421]</a></td>
<td class="author-text"><a href="mailto:104-8456@mcimail.com">Linn, J.</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc1421">Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures</a>,&rdquo; RFC&nbsp;1421, February&nbsp;1993 (<a href="http://www.rfc-editor.org/rfc/rfc1421.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1738">[RFC1738]</a></td>
<td class="author-text"><a href="mailto:timbl@info.cern.ch">Berners-Lee, T.</a>, <a href="mailto:masinter@parc.xerox.com">Masinter, L.</a>, and <a href="mailto:mpm@boombox.micro.umn.edu">M. McCahill</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc1738">Uniform Resource Locators (URL)</a>,&rdquo; RFC&nbsp;1738, December&nbsp;1994 (<a href="http://www.rfc-editor.org/rfc/rfc1738.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC1952">[RFC1952]</a></td>
<td class="author-text"><a href="mailto:ghost@aladdin.com">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>,&rdquo; RFC&nbsp;1952, May&nbsp;1996 (<a href="http://www.rfc-editor.org/rfc/rfc1952.txt">TXT</a>, <a href="http://www.rfc-editor.org/rfc/rfc1952.ps">PS</a>, <a href="http://www.rfc-editor.org/rfc/rfc1952.pdf">PDF</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,&rdquo; BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2818">[RFC2818]</a></td>
<td class="author-text">Rescorla, E., &ldquo;<a href="http://tools.ietf.org/html/rfc2818">HTTP Over TLS</a>,&rdquo; RFC&nbsp;2818, May&nbsp;2000 (<a href="http://www.rfc-editor.org/rfc/rfc2818.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3394">[RFC3394]</a></td>
<td class="author-text">Schaad, J. and R. Housley, &ldquo;<a href="http://tools.ietf.org/html/rfc3394">Advanced Encryption Standard (AES) Key Wrap Algorithm</a>,&rdquo; RFC&nbsp;3394, September&nbsp;2002 (<a href="http://www.rfc-editor.org/rfc/rfc3394.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3447">[RFC3447]</a></td>
<td class="author-text">Jonsson, J. and B. Kaliski, &ldquo;<a href="http://tools.ietf.org/html/rfc3447">Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</a>,&rdquo; RFC&nbsp;3447, February&nbsp;2003 (<a href="http://www.rfc-editor.org/rfc/rfc3447.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3629">[RFC3629]</a></td>
<td class="author-text">Yergeau, F., &ldquo;<a href="http://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of ISO 10646</a>,&rdquo; STD&nbsp;63, RFC&nbsp;3629, November&nbsp;2003 (<a href="http://www.rfc-editor.org/rfc/rfc3629.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3986">[RFC3986]</a></td>
<td class="author-text"><a href="mailto:timbl@w3.org">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com">Fielding, R.</a>, and <a href="mailto:LMM@acm.org">L. Masinter</a>, &ldquo;<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>,&rdquo; STD&nbsp;66, RFC&nbsp;3986, January&nbsp;2005 (<a href="http://www.rfc-editor.org/rfc/rfc3986.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc3986.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc3986.xml">XML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4086">[RFC4086]</a></td>
<td class="author-text">Eastlake, D., Schiller, J., and S. Crocker, &ldquo;<a href="http://tools.ietf.org/html/rfc4086">Randomness Requirements for Security</a>,&rdquo; BCP&nbsp;106, RFC&nbsp;4086, June&nbsp;2005 (<a href="http://www.rfc-editor.org/rfc/rfc4086.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4627">[RFC4627]</a></td>
<td class="author-text">Crockford, D., &ldquo;<a href="http://tools.ietf.org/html/rfc4627">The application/json Media Type for JavaScript Object Notation (JSON)</a>,&rdquo; RFC&nbsp;4627, July&nbsp;2006 (<a href="http://www.rfc-editor.org/rfc/rfc4627.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4648">[RFC4648]</a></td>
<td class="author-text">Josefsson, S., &ldquo;<a href="http://tools.ietf.org/html/rfc4648">The Base16, Base32, and Base64 Data Encodings</a>,&rdquo; RFC&nbsp;4648, October&nbsp;2006 (<a href="http://www.rfc-editor.org/rfc/rfc4648.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC5226">[RFC5226]</a></td>
<td class="author-text">Narten, T. and H. Alvestrand, &ldquo;<a href="http://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>,&rdquo; BCP&nbsp;26, RFC&nbsp;5226, May&nbsp;2008 (<a href="http://www.rfc-editor.org/rfc/rfc5226.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC5246">[RFC5246]</a></td>
<td class="author-text">Dierks, T. and E. Rescorla, &ldquo;<a href="http://tools.ietf.org/html/rfc5246">The Transport Layer Security (TLS) Protocol Version 1.2</a>,&rdquo; RFC&nbsp;5246, August&nbsp;2008 (<a href="http://www.rfc-editor.org/rfc/rfc5246.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC5280">[RFC5280]</a></td>
<td class="author-text">Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, &ldquo;<a href="http://tools.ietf.org/html/rfc5280">Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</a>,&rdquo; RFC&nbsp;5280, May&nbsp;2008 (<a href="http://www.rfc-editor.org/rfc/rfc5280.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6090">[RFC6090]</a></td>
<td class="author-text">McGrew, D., Igoe, K., and M. Salter, &ldquo;<a href="http://tools.ietf.org/html/rfc6090">Fundamental Elliptic Curve Cryptography Algorithms</a>,&rdquo; RFC&nbsp;6090, February&nbsp;2011 (<a href="http://www.rfc-editor.org/rfc/rfc6090.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6125">[RFC6125]</a></td>
<td class="author-text">Saint-Andre, P. and J. Hodges, &ldquo;<a href="http://tools.ietf.org/html/rfc6125">Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</a>,&rdquo; RFC&nbsp;6125, March&nbsp;2011 (<a href="http://www.rfc-editor.org/rfc/rfc6125.txt">TXT</a>).</td></tr>
</table>

<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>13.2.&nbsp;Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="I-D.rescorla-jsms">[I-D.rescorla-jsms]</a></td>
<td class="author-text">Rescorla, E. and J. Hildebrand, &ldquo;<a href="http://tools.ietf.org/html/draft-rescorla-jsms-00">JavaScript Message Security Format</a>,&rdquo; draft-rescorla-jsms-00 (work in progress), March&nbsp;2011 (<a href="http://www.ietf.org/internet-drafts/draft-rescorla-jsms-00.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="JCA">[JCA]</a></td>
<td class="author-text">Oracle, &ldquo;<a href="http://download.java.net/jdk7/docs/technotes/guides/security/SunProviders.html">Java Cryptography Architecture</a>,&rdquo; 2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="JSS">[JSS]</a></td>
<td class="author-text">Bradley, J. and N. Sakimura (editor), &ldquo;<a href="http://jsonenc.info/jss/1.0/">JSON Simple Sign</a>,&rdquo; September&nbsp;2010.</td></tr>
<tr><td class="author-text" valign="top"><a name="JWT">[JWT]</a></td>
<td class="author-text"><a href="mailto:mbj@microsoft.com">Jones, M.</a>, <a href="mailto:balfanz@google.com">Balfanz, D.</a>, <a href="mailto:ve7jtb@ve7jtb.com">Bradley, J.</a>, <a href="mailto:yarong@microsoft.com">Goland, Y.</a>, <a href="mailto:jpanzer@google.com">Panzer, J.</a>, <a href="mailto:n-sakimura@nri.co.jp">Sakimura, N.</a>, and <a href="mailto:pt@fb.com">P. Tarjan</a>, &ldquo;<a href="http://tools.ietf.org/html/draft-jones-json-web-token">JSON Web Token (JWT)</a>,&rdquo; December&nbsp;2011.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC5652">[RFC5652]</a></td>
<td class="author-text">Housley, R., &ldquo;<a href="http://tools.ietf.org/html/rfc5652">Cryptographic Message Syntax (CMS)</a>,&rdquo; STD&nbsp;70, RFC&nbsp;5652, September&nbsp;2009 (<a href="http://www.rfc-editor.org/rfc/rfc5652.txt">TXT</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="W3C.CR-xmlenc-core1-20110303">[W3C.CR-xmlenc-core1-20110303]</a></td>
<td class="author-text">Hirsch, F., Roessler, T., Reagle, J., and D. Eastlake, &ldquo;<a href="http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303">XML Encryption Syntax and Processing Version 1.1</a>,&rdquo; World Wide Web Consortium CR&nbsp;CR-xmlenc-core1-20110303, March&nbsp;2011 (<a href="http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303">HTML</a>).</td></tr>
<tr><td class="author-text" valign="top"><a name="W3C.REC-xmlenc-core-20021210">[W3C.REC-xmlenc-core-20021210]</a></td>
<td class="author-text">Eastlake, D. and J. Reagle, &ldquo;<a href="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210">XML Encryption Syntax and Processing</a>,&rdquo; World Wide Web Consortium Recommendation&nbsp;REC-xmlenc-core-20021210, December&nbsp;2002 (<a href="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210">HTML</a>).</td></tr>
</table>

<a name="JWEExamples"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.&nbsp;
JWE Examples</h3>

<p>
        This section provides several examples of JWEs.
      
</p>
<a name="TBDExample"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.1"></a><h3>A.1.&nbsp;
JWE Example using TBD Algorithm</h3>

<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.1.1"></a><h3>A.1.1.&nbsp;
Encrypting</h3>

<p>
            TBD: Demonstrate encryption steps with this algorithm
          
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.A.1.2"></a><h3>A.1.2.&nbsp;
Decrypting</h3>

<p>
            TBD: Demonstrate decryption steps with this algorithm
          
</p>
<a name="algxref"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.B"></a><h3>Appendix B.&nbsp;
Algorithm Identifier Cross-Reference</h3>

<p>
        This appendix contains a table cross-referencing the <tt>alg</tt> and <tt>enc</tt>
        values used in this specification with the equivalent
        identifiers used by other standards and software packages.
        See
        <a class='info' href='#W3C.REC-xmlenc-core-20021210'>XML Encryption<span> (</span><span class='info'>Eastlake, D. and J. Reagle, &ldquo;XML Encryption Syntax and Processing,&rdquo; December&nbsp;2002.</span><span>)</span></a> [W3C.REC&#8209;xmlenc&#8209;core&#8209;20021210],
        <a class='info' href='#W3C.CR-xmlenc-core1-20110303'>XML Encryption 1.1<span> (</span><span class='info'>Hirsch, F., Roessler, T., Reagle, J., and D. Eastlake, &ldquo;XML Encryption Syntax and Processing Version 1.1,&rdquo; March&nbsp;2011.</span><span>)</span></a> [W3C.CR&#8209;xmlenc&#8209;core1&#8209;20110303],
        and <a class='info' href='#JCA'>Java Cryptography Architecture<span> (</span><span class='info'>Oracle, &ldquo;Java Cryptography Architecture,&rdquo; 2011.</span><span>)</span></a> [JCA] for more
        information about the names defined by those documents.

      
</p><br /><hr class="insert" />
<a name="algxreftable"></a>
<table class="full" align="center" border="0" cellpadding="2" cellspacing="2">
<col align="left"><col align="left"><col align="left"><col align="left">
<tr><th align="left">Algorithm</th><th align="left">JWE</th><th align="left">XML ENC</th><th align="left">JCA</th></tr>
<tr>
<td align="left">RSA using RSA-PKCS1-1.5 padding</td>
<td align="left">RSA1_5</td>
<td align="left">http://www.w3.org/2001/04/xmlenc#rsa-1_5</td>
<td align="left">RSA/ECB/PKCS1Padding</td>
</tr>
<tr>
<td align="left">RSA using Optimal Asymmetric Encryption Padding (OAEP)</td>
<td align="left">RSA-OAEP</td>
<td align="left">http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p</td>
<td align="left">RSA/ECB/OAEPWithSHA-1AndMGF1Padding</td>
</tr>
<tr>
<td align="left">Elliptic Curve Diffie-Hellman Ephemeral Static</td>
<td align="left">ECDH-ES</td>
<td align="left">http://www.w3.org/2009/xmlenc11#ECDH-ES</td>
<td align="left">TBD</td>
</tr>
<tr>
<td align="left">Advanced Encryption Standard (AES) Key Wrap Algorithm <a class='info' href='#RFC3394'>RFC 3394<span> (</span><span class='info'>Schaad, J. and R. Housley, &ldquo;Advanced Encryption Standard (AES) Key Wrap Algorithm,&rdquo; September&nbsp;2002.</span><span>)</span></a> [RFC3394] using 128 bit keys</td>
<td align="left">A128KW</td>
<td align="left">http://www.w3.org/2001/04/xmlenc#kw-aes128</td>
<td align="left">TBD</td>
</tr>
<tr>
<td align="left">Advanced Encryption Standard (AES) Key Wrap Algorithm <a class='info' href='#RFC3394'>RFC 3394<span> (</span><span class='info'>Schaad, J. and R. Housley, &ldquo;Advanced Encryption Standard (AES) Key Wrap Algorithm,&rdquo; September&nbsp;2002.</span><span>)</span></a> [RFC3394] using 256 bit keys</td>
<td align="left">A256KW</td>
<td align="left">http://www.w3.org/2001/04/xmlenc#kw-aes256</td>
<td align="left">TBD</td>
</tr>
<tr>
<td align="left">Advanced Encryption Standard (AES) using 128 bit keys in
        Cipher Block Chaining mode</td>
<td align="left">A128CBC</td>
<td align="left">http://www.w3.org/2001/04/xmlenc#aes128-cbc</td>
<td align="left">AES/CBC/PKCS5Padding</td>
</tr>
<tr>
<td align="left">Advanced Encryption Standard (AES) using 256 bit keys in
        Cipher Block Chaining mode</td>
<td align="left">A256CBC</td>
<td align="left">http://www.w3.org/2001/04/xmlenc#aes256-cbc</td>
<td align="left">AES/CBC/PKCS5Padding</td>
</tr>
<tr>
<td align="left">Advanced Encryption Standard (AES) using 128 bit keys in
        Galois/Counter Mode</td>
<td align="left">A128GCM</td>
<td align="left">http://www.w3.org/2009/xmlenc11#aes128-gcm</td>
<td align="left">AES/GCM/NoPadding</td>
</tr>
<tr>
<td align="left">Advanced Encryption Standard (AES) using 256 bit keys in
        Galois/Counter Mode</td>
<td align="left">A256GCM</td>
<td align="left">http://www.w3.org/2009/xmlenc11#aes256-gcm</td>
<td align="left">AES/GCM/NoPadding</td>
</tr>
</table>
<br clear="all" />
<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b>&nbsp;Table 5: Algorithm Identifier Cross-Reference&nbsp;</b></font><br /></td></tr></table><hr class="insert" />

<a name="Acknowledgements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.C"></a><h3>Appendix C.&nbsp;
Acknowledgements</h3>

<p>
        Solutions for encrypting JSON content were also explored by
        <a class='info' href='#JSS'>[JSS]<span> (</span><span class='info'>Bradley, J. and N. Sakimura (editor), &ldquo;JSON Simple Sign,&rdquo; September&nbsp;2010.</span><span>)</span></a> and <a class='info' href='#I-D.rescorla-jsms'>[I&#8209;D.rescorla&#8209;jsms]<span> (</span><span class='info'>Rescorla, E. and J. Hildebrand, &ldquo;JavaScript Message Security Format,&rdquo; March&nbsp;2011.</span><span>)</span></a>,
        both of which significantly influenced this draft.  This draft
        attempts to explicitly reuse as much from
        <a class='info' href='#W3C.CR-xmlenc-core1-20110303'>XML Encryption 1.1<span> (</span><span class='info'>Hirsch, F., Roessler, T., Reagle, J., and D. Eastlake, &ldquo;XML Encryption Syntax and Processing Version 1.1,&rdquo; March&nbsp;2011.</span><span>)</span></a> [W3C.CR&#8209;xmlenc&#8209;core1&#8209;20110303]
        and <a class='info' href='#RFC5652'>RFC 5652<span> (</span><span class='info'>Housley, R., &ldquo;Cryptographic Message Syntax (CMS),&rdquo; September&nbsp;2009.</span><span>)</span></a> [RFC5652] as possible, while utilizing
        simple compact JSON-based data structures.
      
</p>
<p>
        Special thanks are due to John Bradley and Nat Sakimura for
        the discussions that helped inform the content of this
        specification and to Eric Rescorla and Joe Hildebrand for
        allowing the reuse of some of the text from <a class='info' href='#I-D.rescorla-jsms'>[I&#8209;D.rescorla&#8209;jsms]<span> (</span><span class='info'>Rescorla, E. and J. Hildebrand, &ldquo;JavaScript Message Security Format,&rdquo; March&nbsp;2011.</span><span>)</span></a> in this document.
      
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<a name="rfc.section.D"></a><h3>Appendix D.&nbsp;
Document History</h3>

<p>
        -02
        </p>
<ul class="text">
<li>
           Update to use short JWK Key Object names in Ephemeral
           Public Keys.
          
</li>
<li>
            Moved "MUST" requirements from the Overview to later in
            the spec.
          
</li>
<li>
            Respect line length restrictions in examples.
          
</li>
<li>
            Applied other editorial improvements.
          
</li>
</ul><p>
      
</p>
<p>
        -01
        </p>
<ul class="text">
<li>
            Changed type of Ephemeral Public Key (<tt>epk</tt>) from string to JSON object, so
            that a JWK Key Object value can be used directly.
          
</li>
<li>
            Specified that the Digest Method for ECDH-ES is SHA-256.
            (The specification was previously silent about the choice
            of digest method.)
          
</li>
<li>
            The <tt>jku</tt> and <tt>x5u</tt> URLs are now required to be
            absolute URLs.
          
</li>
<li>
            Removed this unnecessary language from the <tt>kid</tt> description: "Omitting this
            parameter is equivalent to setting it to an empty string".
          
</li>
<li>
            Use the same language as RFC 2616 does when describing
            <tt>GZIP</tt> message compression.
          
</li>
</ul><p>
      
</p>
<p>
        -00
        </p>
<ul class="text">
<li>
            First encryption draft based upon consensus decisions at
            IIW documented at http://self-issued.info/?p=378.  The
            ability to provide encryption for JSON Web Tokens (JWTs)
            <a class='info' href='#JWT'>[JWT]<span> (</span><span class='info'>Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, J., Sakimura, N., and P. Tarjan, &ldquo;JSON Web Token (JWT),&rdquo; December&nbsp;2011.</span><span>)</span></a> is a primary use case.
          
</li>
</ul><p>
      
</p>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></table>
<h3>Authors' Addresses</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Michael B. Jones</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Microsoft</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:mbj@microsoft.com">mbj@microsoft.com</a></td></tr>
<tr><td class="author" align="right">URI:&nbsp;</td>
<td class="author-text"><a href="http://self-issued.info/">http://self-issued.info/</a></td></tr>
<tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Eric Rescorla</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">RTFM, Inc.</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:ekr@rtfm.com">ekr@rtfm.com</a></td></tr>
<tr cellpadding="3"><td>&nbsp;</td><td>&nbsp;</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Joe Hildebrand</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Cisco Systems, Inc.</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:jhildebr@cisco.com">jhildebr@cisco.com</a></td></tr>
</table>
</body></html>

Compare with Previous | Blame