rfc7638.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc number="7638" category="std" submissionType="IETF" consensus="yes" ipr="trust200902">

  <front>
    <title>JSON Web Key (JWK) Thumbprint</title>

    <author fullname="Michael B. Jones" initials="M.B." surname="Jones">
      <organization>Microsoft</organization>
      <address>
        <email>mbj@microsoft.com</email>
        <uri>http://self-issued.info/</uri>
      </address>
    </author>

    <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
      <organization>Nomura Research Institute</organization>
      <address>
        <email>n-sakimura@nri.co.jp</email>
        <uri>http://nat.sakimura.org/</uri>
      </address>
    </author>
    <date month="September" year="2015" />

    <area>Security</area>
    <workgroup>JOSE Working Group</workgroup>

    <keyword>JavaScript Object Notation</keyword>
    <keyword>JSON</keyword>
    <keyword>JSON Web Key</keyword>
    <keyword>JWK</keyword>
    <keyword>Thumbprint</keyword>
    <keyword>Fingerprint</keyword>
    <keyword>Digest</keyword>

    <abstract>
      <t>
        This specification defines a method for computing a hash value
        over a JSON Web Key (JWK).
        It defines which fields in a JWK are used in the hash computation,
        the method of creating a canonical form for those fields,
        and how to convert the resulting Unicode string into a byte sequence to be hashed.
        The resulting hash value can be used for identifying or selecting the key
        represented by the JWK that
        is the subject of the thumbprint.
      </t>
    </abstract>

  </front>

  <middle>
    <section title="Introduction" anchor="Introduction">
      <t>
        This specification defines a method for computing a hash value (a.k.a. digest)
        over a JSON Web Key (JWK) <xref target="JWK"/>.
        It defines which fields in a JWK are used in the hash computation,
        the method of creating a canonical form for those fields,
        and how to convert the resulting Unicode string into a byte sequence to be hashed.
        The resulting hash value can be used for identifying or selecting the key
        represented by the JWK that
        is the subject of the thumbprint, for instance,
        by using the base64url-encoded JWK Thumbprint value
        as a <spanx style="verb">kid</spanx> (key ID) value.
      </t>

      <section title='Notational Conventions' anchor="NotationalConventions">
        <t>
          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
          "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
          and "OPTIONAL" in this document are to be interpreted as
          described in
          "Key words for use in RFCs to Indicate Requirement Levels" <xref target='RFC2119' />.
          The interpretation should only be applied when the terms appear in all capital letters.
        </t>
      </section>

    </section>

    <section title="Terminology" anchor="Terminology">
      <t>
        This specification uses the same terminology as the
        "JSON Web Key (JWK)" <xref target="JWK"/>,
        "JSON Web Signature (JWS)" <xref target="JWS"/>,
        and
        "JSON Web Algorithms (JWA)" <xref target="JWA"/>
        specifications.
      </t>

      <t>
        This term is defined by this specification:
      </t>

      <t>
        <list style="hanging">
          <t hangText="JWK Thumbprint">
            <vspace/>
            The digest value for a JWK.
          </t>
        </list>
      </t>
    </section>

    <section title="JSON Web Key (JWK) Thumbprint" anchor="jkt">
      <t>
        The thumbprint of a JSON Web Key (JWK) is computed as follows:
        <list style="numbers">
          <t>
            Construct a JSON object <xref target="RFC7159"/>
            containing only the required members of a JWK representing the key
            and with no whitespace or line breaks before or after any syntactic elements
            and with the required members ordered lexicographically
            by the Unicode <xref target="UNICODE"/> code points of the member names.
            (This JSON object is itself a legal JWK representation of the key.)
          </t>
          <t>
            Hash the octets of the UTF-8 representation of this JSON object with
            a cryptographic hash function H.
            For example, SHA-256 <xref target="SHS"/> might be used as H.
            See <xref target="HashFunction"/> for a discussion on
            the choice of hash function.
          </t>
        </list>
        The resulting value is the JWK Thumbprint with H of the JWK.
        The details of this computation are further described in subsequent sections.
      </t>

      <section title="Example JWK Thumbprint Computation" anchor="Example">
        <t>
          This section demonstrates the JWK Thumbprint computation for the JWK below
          (with the long line broken for display purposes only):
        </t>
        <figure><artwork><![CDATA[
  {
   "kty": "RSA",
   "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx4cbbfAAt
         VT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMstn6
         4tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FD
         W2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n9
         1CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINH
         aQ-G_xBniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
   "e": "AQAB",
   "alg": "RS256",
   "kid": "2011-04-29"
  }
]]></artwork></figure>
        <t>
          As defined in
          "JSON Web Key (JWK)" <xref target="JWK"/> and
          "JSON Web Algorithms (JWA)" <xref target="JWA"/>,
          the required members for an RSA public key are:
        </t>
        <t>
          <?rfc subcompact="yes"?>
          <list style="symbols">
            <t><spanx style="verb">kty</spanx></t>
            <t><spanx style="verb">n</spanx></t>
            <t><spanx style="verb">e</spanx></t>
          </list>
          <?rfc subcompact="no"?>
        </t>
        <t>
          Therefore, these are the members used in the thumbprint computation.
        </t>
        <t>
          Their lexicographic order, per <xref target="HashInput"/>, is:
        </t>
        <t>
          <?rfc subcompact="yes"?>
          <list style="symbols">
            <t><spanx style="verb">e</spanx></t>
            <t><spanx style="verb">kty</spanx></t>
            <t><spanx style="verb">n</spanx></t>
          </list>
          <?rfc subcompact="no"?>
        </t>
        <t>
          Therefore, the JSON object constructed as an intermediate step
          in the computation is as follows
          (with the line broken for display purposes only):
        </t>
        <figure><artwork><![CDATA[
  {"e":"AQAB","kty":"RSA","n":"0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2
  aiAFbWhM78LhWx4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCi
  FV4n3oknjhMstn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65Y
  GjQR0_FDW2QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n
  91CbOpbISD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_x
  BniIqbw0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw"}
]]></artwork></figure>
        <t>
          The octets of the UTF-8 representation of this JSON object are:
        </t>
        <t>
          [123, 34, 101, 34, 58, 34, 65, 81, 65, 66, 34, 44, 34, 107, 116, 121, 34, 58, 34, 82, 83, 65, 34, 44, 34, 110, 34, 58, 34, 48, 118, 120, 55, 97, 103, 111, 101, 98, 71, 99, 81, 83, 117, 117, 80, 105, 76, 74, 88, 90, 112, 116, 78, 57, 110, 110, 100, 114, 81, 109, 98, 88, 69, 112, 115, 50, 97, 105, 65, 70, 98, 87, 104, 77, 55, 56, 76, 104, 87, 120, 52, 99, 98, 98, 102, 65, 65, 116, 86, 84, 56, 54, 122, 119, 117, 49, 82, 75, 55, 97, 80, 70, 70, 120, 117, 104, 68, 82, 49, 76, 54, 116, 83, 111, 99, 95, 66, 74, 69, 67, 80, 101, 98, 87, 75, 82, 88, 106, 66, 90, 67, 105, 70, 86, 52, 110, 51, 111, 107, 110, 106, 104, 77, 115, 116, 110, 54, 52, 116, 90, 95, 50, 87, 45, 53, 74, 115, 71, 89, 52, 72, 99, 53, 110, 57, 121, 66, 88, 65, 114, 119, 108, 57, 51, 108, 113, 116, 55, 95, 82, 78, 53, 119, 54, 67, 102, 48, 104, 52, 81, 121, 81, 53, 118, 45, 54, 53, 89, 71, 106, 81, 82, 48, 95, 70, 68, 87, 50, 81, 118, 122, 113, 89, 51, 54, 56, 81, 81, 77, 105, 99, 65, 116, 97, 83, 113, 122, 115, 56, 75, 74, 90, 103, 110, 89, 98, 57, 99, 55, 100, 48, 122, 103, 100, 65, 90, 72, 122, 117, 54, 113, 77, 81, 118, 82, 76, 53, 104, 97, 106, 114, 110, 49, 110, 57, 49, 67, 98, 79, 112, 98, 73, 83, 68, 48, 56, 113, 78, 76, 121, 114, 100, 107, 116, 45, 98, 70, 84, 87, 104, 65, 73, 52, 118, 77, 81, 70, 104, 54, 87, 101, 90, 117, 48, 102, 77, 52, 108, 70, 100, 50, 78, 99, 82, 119, 114, 51, 88, 80, 107, 115, 73, 78, 72, 97, 81, 45, 71, 95, 120, 66, 110, 105, 73, 113, 98, 119, 48, 76, 115, 49, 106, 70, 52, 52, 45, 99, 115, 70, 67, 117, 114, 45, 107, 69, 103, 85, 56, 97, 119, 97, 112, 74, 122, 75, 110, 113, 68, 75, 103, 119, 34, 125]
        </t>
        <t>
          Using SHA-256 <xref target="SHS"/> as the hash function H,
          the JWK SHA-256 Thumbprint value is the SHA-256 hash of these octets, specifically:
        </t>
        <t>
[55, 54, 203, 177, 120, 124, 184, 48, 156, 119, 238, 140, 55, 5, 197, 225,
 111, 251, 158, 133, 151, 21, 144, 31, 30, 76, 89, 177, 17, 130, 245, 123]
        </t>
        <t>
          The base64url encoding <xref target="JWS"/> of this JWK SHA-256 Thumbprint value
          (which might, for instance, be used as a <spanx style="verb">kid</spanx> (key ID) value) is:
        </t>
        <figure><artwork><![CDATA[
  NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs
]]></artwork></figure>
      </section>

      <section title="JWK Members Used in the Thumbprint Computation" anchor="MembersUsed">
        <t>
          Only the required members of a key's representation are used
          when computing its JWK Thumbprint value.
          As defined in
          "JSON Web Key (JWK)" <xref target="JWK"/> and
          "JSON Web Algorithms (JWA)" <xref target="JWA"/>,
          the required members for an elliptic curve public key
          for the curves specified in Section 6.2.1.1 of RFC 7518 <xref target="JWA"/>,
          in lexicographic order, are:
        </t>
        <t>
          <?rfc subcompact="yes"?>
          <list style="symbols">
            <t><spanx style="verb">crv</spanx></t>
            <t><spanx style="verb">kty</spanx></t>
            <t><spanx style="verb">x</spanx></t>
            <t><spanx style="verb">y</spanx></t>
          </list>
          <?rfc subcompact="no"?>
        </t>
        <t>
          The required members for an RSA public key, in lexicographic order, are:
        </t>
        <t>
          <?rfc subcompact="yes"?>
          <list style="symbols">
            <t><spanx style="verb">e</spanx></t>
            <t><spanx style="verb">kty</spanx></t>
            <t><spanx style="verb">n</spanx></t>
          </list>
          <?rfc subcompact="no"?>
        </t>
        <t>
          The required members for a symmetric key, in lexicographic order, are:
        </t>
        <t>
          <?rfc subcompact="yes"?>
          <list style="symbols">
            <t><spanx style="verb">k</spanx></t>
            <t><spanx style="verb">kty</spanx></t>
          </list>
          <?rfc subcompact="no"?>
        </t>
        <t>
          As other <spanx style="verb">kty</spanx> (key type) values are defined,
          the specifications defining them
          should be similarly consulted to determine which members,
          in addition to <spanx style="verb">kty</spanx>, are required.
        </t>

        <section title="JWK Thumbprint of a Private Key" anchor="Private">
          <t>
            The JWK Thumbprint of a JWK representing a private key is computed as
            the JWK Thumbprint of a JWK representing the corresponding public key.
            This has the intentional benefit that the same JWK Thumbprint value
            can be computed both by parties using either the public or private key.
            The JWK Thumbprint can then be used to refer to both keys of the key pair.
            Application context can be used to determine if
            the public or private key is the one being referred to
            by the JWK Thumbprint.
          </t>
          <t>
            This specification defines the method of computing JWK Thumbprints
            of JWKs representing private keys for interoperability reasons
            -- so that different implementations computing JWK Thumbprints
            of private keys will produce the same result.
          </t>
        </section>

        <section title="Why Not Include Optional Members?" anchor="WhyNotOptional">
          <t>
            Optional members of JWKs are intentionally not included in
            the JWK Thumbprint computation so that their absence or presence
            in the JWK does not alter the resulting value.
            The JWK Thumbprint value is a digest of
            the members required to represent the key as a JWK --
            not of additional data that may also accompany the key.
          </t>

          <t>
            Optional members are not included so that the JWK Thumbprint refers to
            a key -- not a key with an associated set of key attributes.
            Different application contexts might or might not include different subsets of optional attributes
            about the key in the JWK.  If these were included in the calculation of
            the JWK thumbprint, the values would be different for those JWKs, even
            though the keys are the same.  The benefit of including only the JWK required
            members is that the JWK Thumbprint of
            any JWK representing the key remains the same,
            regardless of any other attributes that are present.
        </t>
        <t>
            Different kinds of thumbprints could be defined by other specifications
            that might include some or all additional JWK members, if use cases
            arise where such different kinds of thumbprints would be useful.
            See Section 9.1 of RFC 7517 <xref target="JWK"/> for notes on some ways
            to cryptographically bind attributes to a key.
          </t>
        </section>

      </section>

      <section title="Order and Representation of Members in Hash Input" anchor="HashInput">
        <t>
          The required members in the input to the hash function are
          ordered lexicographically by the Unicode code points of the member names.
        </t>
        <t>
          Characters in member names and member values MUST be represented
          without being escaped.
          This means that thumbprints of JWKs that require such characters
          are not defined by this specification.
          (This is not expected to limit the applicability of this specification,
          in practice, as the members of JWK representations
          are not expected to use any of these characters.)
          The characters specified as requiring escaping
          by Section 7 of <xref target="RFC7159"/>
          are quotation mark, reverse solidus (a.k.a. backslash),
          and the control characters U+0000 through U+001F.
        </t>
        <t>
          If the JWK key type uses members whose values are themselves JSON objects,
          then the members of those objects MUST likewise be lexicographically ordered.
          (As of the time of this writing, none are defined that do.)
        </t>
        <t>
          If the JWK key type uses members whose values are JSON numbers, and
          if those numbers are integers, then they MUST be represented
          as a JSON number as defined in Section 6 of <xref target="RFC7159"/>
          without including a fraction part or exponent part.
          For instance, the value <spanx style="verb">1.024e3</spanx> MUST be
          represented as <spanx style="verb">1024</spanx>.
          This means that thumbprints of JWKs using numbers that are not integers
          are not defined by this specification.
          Also, as noted in "The I-JSON Message Format" <xref target="RFC7493"/>,
          implementations cannot expect an integer
          whose absolute value is greater than 9007199254740991
          (i.e., that is outside the range [-(2**53)+1, (2**53)-1])
          to be treated as an exact value.
          (As of the time of this writing, none are defined that use JSON numbers.)
        </t>
        <t>
          See <xref target="PracticalConsiderations"/> for a discussion of
          further practical considerations pertaining to the
          representation of the hash input.
        </t>
      </section>

      <section title="Selection of Hash Function" anchor="HashFunction">
        <t>
          A specific hash function must be chosen by an application
          to compute the hash value of the hash input.
          For example, SHA-256 <xref target="SHS"/> might be used as the hash function
          by the application.
          While SHA-256 is a good default choice at the time of this writing,
          the hash function of choice can be expected to change over time
          as the cryptographic landscape evolves.
        </t>
        <t>
          Note that in many cases, only the party that creates a key will
          need to know the hash function used.
          A typical usage is for the producer of the key
          to use the base64url-encoded JWK Thumbprint value
          as a <spanx style="verb">kid</spanx> (key ID) value.
          In this case, the consumer of the <spanx style="verb">kid</spanx> treats it
          as an opaque value that it uses to select the key.
        </t>
        <t>
          However, in some cases, multiple parties will be reproducing
          the JWK Thumbprint calculation and comparing the results.
          In these cases, the parties will need to know which hash function was used
          and use the same one.
        </t>
      </section>

      <section title="JWK Thumbprints of Keys Not in JWK Format" anchor="AnyKeys">
        <t>
          Note that a key need not be in JWK format to create
          a JWK Thumbprint of it.  The only prerequisites are that
          the JWK representation of the key be defined
          and the party creating the JWK Thumbprint be in possession
          of the necessary key material.
          These are sufficient to create the hash input
          from the JWK representation of the key,
          as described in <xref target="HashInput"/>.
        </t>
      </section>

    </section>

    <section title="Practical JSON and Unicode Considerations"
             anchor="PracticalConsiderations">
      <t>
        Implementations will almost certainly use functionality
        provided by the platform's JSON support
        when parsing the JWK and emitting the JSON object used as
        the hash input.
        As a practical consideration,
        future JWK member names and values should be avoided for which different
        platforms or libraries might emit different representations.
        As of the time of this writing, all defined JWK member names and values
        use only printable ASCII characters, which should not exhibit this problem.
        Note however, that JSON.stringify() cannot be counted on to lexicographically sort
        the members of JSON objects, so while it could be used to emit
        some kinds of member values, different code is likely to be needed
        to perform the sorting.
      </t>
      <t>
        In particular, while the operation of
        lexicographically ordering member names by their Unicode code points
        is well defined, different platform sort functions may produce different results
        for non-ASCII characters, in ways that may not be obvious to developers.
        If writers of future specifications defining new
        JWK key type values choose to restrict themselves to printable ASCII member names and values
        (which are for machine and not human consumption anyway),
        some future interoperability problems might be avoided.
      </t>
      <t>
        However, if new JWK members are defined that use non-ASCII member names or values,
        their definitions should specify the exact Unicode code point sequences
        used to represent them.
        This is particularly important in cases in which Unicode normalization could result in
        the transformation of one set of code points into another under any circumstances.
      </t>
      <t>
        Use of escaped characters in JWKs for which JWK Thumbprints will be computed should be avoided.
        Use of escaped characters in the hash input JWKs derived from these original JWKs is prohibited.
      </t>
      <t>
        There is a natural representation to use for numeric values
        that are integers.
        However, this specification does not attempt to define
        a standard representation for numbers that are not integers or
        that contain an exponent component.
        This is not expected to be a problem in practice,
        as the required members of JWK representations
        are expected to use only numbers that are integers.
      </t>
      <t>
        Use of number representations containing fraction or exponent parts
        in JWKs for which JWK Thumbprints will be computed should be avoided.
      </t>
       <t>
        All of these practical considerations are really an instance of Jon Postel's principle:
        "Be liberal in what you accept, and conservative in what you send."
      </t>
    </section>

    <section anchor="X.509Comparison" title="Relationship to Digests of X.509 Values">
      <t>
        JWK Thumbprint values are computed on the JWK members required to represent a key,
        rather than all members of a JWK that the key is represented in.
        Thus, they are more analogous to applications that use digests of
        X.509 Subject Public Key Info (SPKI) values, which are defined in
        Section 4.1.2.7 of <xref target="RFC5280"/>,
        than to applications that use digests of complete certificate values, as the
        <spanx style="verb">x5t</spanx> (X.509 certificate SHA-1 thumbprint)
        <xref target="JWS"/>
        value defined for X.509 certificate objects does.
        While logically equivalent to a digest of the SPKI representation of the key,
        a JWK Thumbprint is computed over a JSON representation of that key,
        rather than over an ASN.1 representation of it.
      </t>
    </section>

    <section title="IANA Considerations" anchor="IANA">
      <t>
        This specification adds to the instructions for the Designated Experts
        of the following IANA registries, all of which are in the
        "JSON Object Signing and Encryption (JOSE)" registry
        <xref target="IANA.JOSE"/>:
        <?rfc subcompact="yes"?>
        <list style="symbols">
          <t>
            JSON Web Key Types
          </t>
          <t>
            JSON Web Key Elliptic Curve
          </t>
          <t>
            JSON Web Key Parameters
          </t>
        </list>
        <?rfc subcompact="no"?>
      </t>
      <t>
        IANA has added a link to this specification in the Reference sections
        of these registries.
      </t>

      <t>
        For these registries, because of the practical JSON and Unicode considerations
        described in <xref target="PracticalConsiderations"/>, the Designated Experts must either:
      </t>
      <t>
        (a) require that JWK member names and values being registered use only
        printable ASCII characters excluding double quote ('"') and backslash ('\')
        (the Unicode characters with code points U+0021, U+0023 through U+005B, and
        U+005D through U+007E), or
      </t>
      <t>
        (b) if new JWK members or values are defined that
        use other code points, require that their definitions specify the exact
        Unicode code point sequences used to represent them.
        Furthermore, proposed registrations that use Unicode code points that can only
        be represented in JSON strings as escaped characters must not be accepted.
      </t>
    </section>

    <section title="Security Considerations" anchor="Security">
      <t>
        The JSON Security Considerations and Unicode Comparison Security Considerations described in
        Sections 10.12 and 10.13 of "JSON Web Signature (JWS)" <xref target="JWS"/>
        also apply to this specification.
      </t>
      <t>
        Also, as described in <xref target="PracticalConsiderations"/>,
        some implementations may produce incorrect results if esoteric or escaped
        characters are used in the member names.
        The security implications of this appear to be limited for JWK Thumbprints
        of public keys, because while it may result in implementations failing
        to identify the intended key, it should not leak information.
        The information in a public key is already public in nature, by definition.
      </t>
      <t>
        A hash of a symmetric key has the potential to leak information about the key value.
        Thus, the JWK Thumbprint of a symmetric key should typically be concealed from parties
        not in possession of the symmetric key, unless in the application context,
        the cryptographic hash used, such as SHA-256, is known to provide sufficient protection
        against disclosure of the key value.
      </t>
      <t>
        A JWK Thumbprint will only uniquely identify a particular key if a single unambiguous
        JWK representation for that key is defined and used when computing the JWK Thumbprint.
        (Such representations are defined for all the key types defined
        in "JSON Web Algorithms (JWA)" <xref target="JWA"/>.)
        For example, if an RSA key were to use "e":"AAEAAQ" (representing [0, 1, 0, 1]) rather than
        the specified correct representation of "e":"AQAB" (representing [1, 0, 1]),
        then a different thumbprint value would be produced for what could be effectively the same key,
        at least for implementations that are lax in validating the JWK values that they accept.
        Thus, JWK Thumbprint values can only be relied upon to be unique for a given key
        if the implementation also validates that the correct representation of the key is used.
      </t>
      <t>
        Even more insidious is that an attacker may supply a key that is a transformation
        of a legal key in order to have it appear to be a different key.
        For instance, if a legitimate RSA key uses a modulus value N and an attacker
        supplies a key with modulus 3*N, the modified key would still work
        about 1/3 of the time, but would appear to be a different key.
        Thus, while thumbprint values are valuable for identifying legitimate keys,
        comparing thumbprint values is not a reliable means of excluding (blacklisting)
        the use of particular keys (or transformations thereof).
      </t>
    </section>

   </middle>

  <back>
    <references title="Normative References">


      <reference anchor="IANA.JOSE" target="http://www.iana.org/assignments/jose">
        <front>
          <title>JSON Object Signing and Encryption (JOSE)</title>
          <author>
            <organization>IANA</organization>
          </author>
          <date/>
        </front>
        <format target="http://www.iana.org/assignments/jose"
                type="HTML" />
      </reference>


     <reference anchor="JWA" target="http://www.rfc-editor.org/info/rfc7518">

<front>
<title>JSON Web Algorithms (JWA)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications.  It defines several IANA registries for these identifiers.</t></abstract>
</front>
<seriesInfo name='RFC' value='7518'/>
<seriesInfo name='DOI' value='10.17487/RFC7518'/>
</reference>


      <reference anchor="JWK" target="http://www.rfc-editor.org/info/rfc7517">

<front>
<title>JSON Web Key (JWK)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<date year='2015' month='May' />
<abstract><t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key.  This specification also defines a JWK Set JSON data structure that represents a set of JWKs.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t></abstract>
</front>
<seriesInfo name='RFC' value='7517'/>
<seriesInfo name='DOI' value='10.17487/RFC7517'/>
</reference>


      <reference anchor="JWS" target="http://www.rfc-editor.org/info/rfc7515">

<front>
<title>JSON Web Signature (JWS)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<author initials='J.' surname='Bradley' fullname='J. Bradley'><organization /></author>
<author initials='N.' surname='Sakimura' fullname='N. Sakimura'><organization /></author>
<date year='2015' month='May' />
<abstract><t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t></abstract>
</front>
<seriesInfo name='RFC' value='7515'/>
<seriesInfo name='DOI' value='10.17487/RFC7515'/>
</reference>


<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference  anchor='RFC7159' target='http://www.rfc-editor.org/info/rfc7159'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials='T.' surname='Bray' fullname='T. Bray' role='editor'><organization /></author>
<date year='2014' month='March' />
</front>
<seriesInfo name='RFC' value='7159'/>
<seriesInfo name='DOI' value='10.17487/RFC7159'/>
</reference>

      <reference anchor="SHS" target="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">
        <front>
          <title>Secure Hash Standard (SHS)</title>

          <author>
            <organization>National Institute of Standards and
            Technology</organization>
          </author>

          <date month="March" year="2012" />
        </front>
        <seriesInfo name="FIPS" value="PUB 180-4" />
        <format target="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf" type="PDF" />
      </reference>

      <reference anchor="UNICODE" target="http://www.unicode.org/versions/latest/">
        <front>
          <title abbrev="Unicode">The Unicode Standard</title>
          <author>
            <organization>The Unicode Consortium</organization>
            <address />
          </author>
          <date />
        </front>
        <!--
        <annotation>
          Note that this reference is to the latest version of Unicode,
          rather than to a specific release.  It is not expected that future changes in
          the UNICODE specification will impact the syntax of JSON or the UTF-8 encoding.
        </annotation>
        -->
      </reference>

    </references>

    <references title="Informative References">

      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml' ?>

      <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7493.xml' ?>

    </references>

    <section numbered="no" title='Acknowledgements' anchor='Acknowledgements'>
      <t>
        James Manger and John Bradley participated in discussions
        that led to the creation of this specification.
        Thanks also to
        Joel Halpern,
        Barry Leiba,
        Adam Montville,
        Kathleen Moriarty,
        and Jim Schaad
        for their reviews of this specification.
      </t>
    </section>

  </back>
</rfc>