7.  IANA Considerations

   The following registration procedure is used for all the registries
   established by this specification.

   The registration procedure for values is Specification Required
   [RFC5226] after a three-week review period on the
   jose-reg-review@ietf.org mailing list, on the advice of one or more
   Designated Experts.  However, to allow for the allocation of values
   prior to publication, the Designated Experts may approve registration
   once they are satisfied that such a specification will be published.

   Registration requests sent to the mailing list for review should use
   an appropriate subject (e.g., "Request to register algorithm:
   example").

   Within the review period, the Designated Experts will either approve
   or deny the registration request, communicating this decision to the
   review list and IANA.  Denials should include an explanation and, if
   applicable, suggestions as to how to make the request successful.

   Registration requests that are undetermined for a period longer than
   21 days can be brought to the IESG's attention (using the
   iesg@ietf.org mailing list) for resolution.

   Criteria that should be applied by the Designated Experts include
   determining whether the proposed registration duplicates existing
   functionality, whether it is likely to be of general applicability or
   useful only for a single application, and whether the registration
   description is clear.

   IANA must only accept registry updates from the Designated Experts
   and should direct all requests for registration to the review mailing
   list.

   It is suggested that multiple Designated Experts be appointed who are
   able to represent the perspectives of different applications using
   this specification, in order to enable broadly informed review of
   registration decisions.  In cases where a registration decision could
   be perceived as creating a conflict of interest for a particular
   Expert, that Expert should defer to the judgment of the other
   Experts.

7.1.  JSON Web Signature and Encryption Algorithms Registry

   This specification establishes the IANA "JSON Web Signature and
   Encryption Algorithms" registry for values of the JWS and JWE "alg"
   (algorithm) and "enc" (encryption algorithm) Header Parameters.  The
   registry records the algorithm name, the algorithm description, the
   algorithm usage locations, the implementation requirements, the
   change controller, and a reference to the specification that defines
   it.  The same algorithm name can be registered multiple times,
   provided that the sets of usage locations are disjoint.

   It is suggested that the length of the key be included in the
   algorithm name when multiple variations of algorithms are being
   registered that use keys of different lengths and the key lengths for
   each need to be fixed (for instance, because they will be created by
   key derivation functions).  This allows readers of the JSON text to
   more easily make security decisions.

   The Designated Experts should perform reasonable due diligence that
   algorithms being registered either are currently considered
   cryptographically credible or are being registered as Deprecated or
   Prohibited.

   The implementation requirements of an algorithm may be changed over
   time as the cryptographic landscape evolves, for instance, to change
   the status of an algorithm to Deprecated or to change the status of
   an algorithm from Optional to Recommended+ or Required.  Changes of
   implementation requirements are only permitted on a Specification
   Required basis after review by the Designated Experts, with the new
   specification defining the revised implementation requirements level.

7.1.1.  Registration Template

   Algorithm Name:
      The name requested (e.g., "HS256").  This name is a case-sensitive
      ASCII string.  Names may not match other registered names in a
      case-insensitive manner unless the Designated Experts state that
      there is a compelling reason to allow an exception.

   Algorithm Description:
      Brief description of the algorithm (e.g., "HMAC using SHA-256").

   Algorithm Usage Location(s):
      The algorithm usage locations.  This must be one or more of the
      values "alg" or "enc" if the algorithm is to be used with JWS or
      JWE.  The value "JWK" is used if the algorithm identifier will be
      used as a JWK "alg" member value, but will not be used with JWS or
      JWE; this could be the case, for instance, for non-authenticated
      encryption algorithms.  Other values may be used with the approval
      of a Designated Expert.

   JOSE Implementation Requirements:
      The algorithm implementation requirements for JWS and JWE, which
      must be one the words Required, Recommended, Optional, Deprecated,
      or Prohibited.  Optionally, the word can be followed by a "+" or
      "-".  The use of "+" indicates that the requirement strength is
      likely to be increased in a future version of the specification.
      The use of "-" indicates that the requirement strength is likely
      to be decreased in a future version of the specification.  Any
      identifiers registered for non-authenticated encryption algorithms
      or other algorithms that are otherwise unsuitable for direct use
      as JWS or JWE algorithms must be registered as "Prohibited".

   Change Controller:
      For Standards Track RFCs, list the "IESG".  For others, give the
      name of the responsible party.  Other details (e.g., postal
      address, email address, home page URI) may also be included.

   Specification Document(s):
      Reference to the document or documents that specify the parameter,
      preferably including URIs that can be used to retrieve copies of
      the documents.  An indication of the relevant sections may also be
      included but is not required.

   Algorithm Analysis Documents(s):
      References to a publication or publications in well-known
      cryptographic conferences, by national standards bodies, or by
      other authoritative sources analyzing the cryptographic soundness
      of the algorithm to be registered.  The Designated Experts may
      require convincing evidence of the cryptographic soundness of a
      new algorithm to be provided with the registration request unless
      the algorithm is being registered as Deprecated or Prohibited.
      Having gone through working group and IETF review, the initial
      registrations made by this document are exempt from the need to
      provide this information.

7.1.2.  Initial Registry Contents

   o  Algorithm Name: "HS256"
   o  Algorithm Description: HMAC using SHA-256
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Required
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.2 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "HS384"
   o  Algorithm Description: HMAC using SHA-384
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.2 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "HS512"
   o  Algorithm Description: HMAC using SHA-512
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.2 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "RS256"
   o  Algorithm Description: RSASSA-PKCS1-v1_5 using SHA-256
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Recommended
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.3 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "RS384"
   o  Algorithm Description: RSASSA-PKCS1-v1_5 using SHA-384
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.3 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "RS512"
   o  Algorithm Description: RSASSA-PKCS1-v1_5 using SHA-512
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.3 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "ES256"
   o  Algorithm Description: ECDSA using P-256 and SHA-256
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Recommended+
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.4 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "ES384"
   o  Algorithm Description: ECDSA using P-384 and SHA-384
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.4 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "ES512"
   o  Algorithm Description: ECDSA using P-521 and SHA-512
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.4 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "PS256"
   o  Algorithm Description: RSASSA-PSS using SHA-256 and MGF1 with
      SHA-256
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.5 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "PS384"
   o  Algorithm Description: RSASSA-PSS using SHA-384 and MGF1 with
      SHA-384
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.5 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "PS512"
   o  Algorithm Description: RSASSA-PSS using SHA-512 and MGF1 with
      SHA-512
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.5 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "none"
   o  Algorithm Description: No digital signature or MAC performed
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 3.6 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "RSA1_5"
   o  Algorithm Description: RSAES-PKCS1-v1_5
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Recommended-
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.2 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "RSA-OAEP"
   o  Algorithm Description: RSAES OAEP using default parameters
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Recommended+
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.3 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "RSA-OAEP-256"
   o  Algorithm Description: RSAES OAEP using SHA-256 and MGF1 with
      SHA-256
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.3 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "A128KW"
   o  Algorithm Description: AES Key Wrap using 128-bit key
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Recommended
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.4 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "A192KW"
   o  Algorithm Description: AES Key Wrap using 192-bit key
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.4 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "A256KW"
   o  Algorithm Description: AES Key Wrap using 256-bit key
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Recommended
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.4 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "dir"
   o  Algorithm Description: Direct use of a shared symmetric key
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Recommended
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.5 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "ECDH-ES"
   o  Algorithm Description: ECDH-ES using Concat KDF
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Recommended+
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.6 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "ECDH-ES+A128KW"
   o  Algorithm Description: ECDH-ES using Concat KDF and "A128KW"
      wrapping
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Recommended
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.6 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "ECDH-ES+A192KW"
   o  Algorithm Description: ECDH-ES using Concat KDF and "A192KW"
      wrapping
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.6 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "ECDH-ES+A256KW"
   o  Algorithm Description: ECDH-ES using Concat KDF and "A256KW"
      wrapping
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Recommended
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.6 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "A128GCMKW"
   o  Algorithm Description: Key wrapping with AES GCM using 128-bit key
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.7 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "A192GCMKW"
   o  Algorithm Description: Key wrapping with AES GCM using 192-bit key
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.7 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "A256GCMKW"
   o  Algorithm Description: Key wrapping with AES GCM using 256-bit key
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.7 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "PBES2-HS256+A128KW"
   o  Algorithm Description: PBES2 with HMAC SHA-256 and "A128KW"
      wrapping
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.8 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "PBES2-HS384+A192KW"
   o  Algorithm Description: PBES2 with HMAC SHA-384 and "A192KW"
      wrapping
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.8 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "PBES2-HS512+A256KW"
   o  Algorithm Description: PBES2 with HMAC SHA-512 and "A256KW"
      wrapping
   o  Algorithm Usage Location(s): "alg"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.8 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "A128CBC-HS256"
   o  Algorithm Description: AES_128_CBC_HMAC_SHA_256 authenticated
      encryption algorithm
   o  Algorithm Usage Location(s): "enc"
   o  JOSE Implementation Requirements: Required
   o  Change Controller: IESG
   o  Specification Document(s): Section 5.2.3 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "A192CBC-HS384"
   o  Algorithm Description: AES_192_CBC_HMAC_SHA_384 authenticated
      encryption algorithm
   o  Algorithm Usage Location(s): "enc"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 5.2.4 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "A256CBC-HS512"
   o  Algorithm Description: AES_256_CBC_HMAC_SHA_512 authenticated
      encryption algorithm
   o  Algorithm Usage Location(s): "enc"
   o  JOSE Implementation Requirements: Required
   o  Change Controller: IESG
   o  Specification Document(s): Section 5.2.5 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "A128GCM"
   o  Algorithm Description: AES GCM using 128-bit key
   o  Algorithm Usage Location(s): "enc"
   o  JOSE Implementation Requirements: Recommended
   o  Change Controller: IESG
   o  Specification Document(s): Section 5.3 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "A192GCM"
   o  Algorithm Description: AES GCM using 192-bit key
   o  Algorithm Usage Location(s): "enc"
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 5.3 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

   o  Algorithm Name: "A256GCM"
   o  Algorithm Description: AES GCM using 256-bit key
   o  Algorithm Usage Location(s): "enc"
   o  JOSE Implementation Requirements: Recommended
   o  Change Controller: IESG
   o  Specification Document(s): Section 5.3 of RFC 7518
   o  Algorithm Analysis Documents(s): n/a

7.2.  Header Parameter Names Registration

   This section registers the Header Parameter names defined in Sections
   4.6.1, 4.7.1, and 4.8.1 of this specification in the IANA "JSON Web
   Signature and Encryption Header Parameters" registry established by
   [JWS].

7.2.1.  Registry Contents

   o  Header Parameter Name: "epk"
   o  Header Parameter Description: Ephemeral Public Key
   o  Header Parameter Usage Location(s): JWE
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.6.1.1 of RFC 7518

   o  Header Parameter Name: "apu"
   o  Header Parameter Description: Agreement PartyUInfo
   o  Header Parameter Usage Location(s): JWE
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.6.1.2 of RFC 7518

   o  Header Parameter Name: "apv"
   o  Header Parameter Description: Agreement PartyVInfo
   o  Header Parameter Usage Location(s): JWE
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.6.1.3 of RFC 7518

   o  Header Parameter Name: "iv"
   o  Header Parameter Description: Initialization Vector
   o  Header Parameter Usage Location(s): JWE
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.7.1.1 of RFC 7518

   o  Header Parameter Name: "tag"
   o  Header Parameter Description: Authentication Tag
   o  Header Parameter Usage Location(s): JWE
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.7.1.2 of RFC 7518

   o  Header Parameter Name: "p2s"
   o  Header Parameter Description: PBES2 Salt Input
   o  Header Parameter Usage Location(s): JWE
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.8.1.1 of RFC 7518

   o  Header Parameter Name: "p2c"
   o  Header Parameter Description: PBES2 Count
   o  Header Parameter Usage Location(s): JWE
   o  Change Controller: IESG
   o  Specification Document(s): Section 4.8.1.2 of RFC 7518

7.3.  JSON Web Encryption Compression Algorithms Registry

   This specification establishes the IANA "JSON Web Encryption
   Compression Algorithms" registry for JWE "zip" member values.  The
   registry records the compression algorithm value and a reference to
   the specification that defines it.

7.3.1.  Registration Template

   Compression Algorithm Value:
      The name requested (e.g., "DEF").  Because a core goal of this
      specification is for the resulting representations to be compact,
      it is RECOMMENDED that the name be short -- not to exceed 8
      characters without a compelling reason to do so.  This name is
      case sensitive.  Names may not match other registered names in a
      case-insensitive manner unless the Designated Experts state that
      there is a compelling reason to allow an exception.

   Compression Algorithm Description:
      Brief description of the compression algorithm (e.g., "DEFLATE").

   Change Controller:
      For Standards Track RFCs, list "IESG".  For others, give the name
      of the responsible party.  Other details (e.g., postal address,
      email address, home page URI) may also be included.

   Specification Document(s):
      Reference to the document or documents that specify the parameter,
      preferably including URIs that can be used to retrieve copies of
      the documents.  An indication of the relevant sections may also be
      included but is not required.

7.3.2.  Initial Registry Contents

   o  Compression Algorithm Value: "DEF"
   o  Compression Algorithm Description: DEFLATE
   o  Change Controller: IESG
   o  Specification Document(s): JSON Web Encryption (JWE) [JWE]

7.4.  JSON Web Key Types Registry

   This specification establishes the IANA "JSON Web Key Types" registry
   for values of the JWK "kty" (key type) parameter.  The registry
   records the "kty" value, implementation requirements, and a reference
   to the specification that defines it.

   The implementation requirements of a key type may be changed over
   time as the cryptographic landscape evolves, for instance, to change
   the status of a key type to Deprecated or to change the status of a
   key type from Optional to Recommended+ or Required.  Changes of
   implementation requirements are only permitted on a Specification
   Required basis after review by the Designated Experts, with the new
   specification defining the revised implementation requirements level.

7.4.1.  Registration Template

   "kty" Parameter Value:
      The name requested (e.g., "EC").  Because a core goal of this
      specification is for the resulting representations to be compact,
      it is RECOMMENDED that the name be short -- not to exceed 8
      characters without a compelling reason to do so.  This name is
      case sensitive.  Names may not match other registered names in a
      case-insensitive manner unless the Designated Experts state that
      there is a compelling reason to allow an exception.

   Key Type Description:
      Brief description of the Key Type (e.g., "Elliptic Curve").

   Change Controller:
      For Standards Track RFCs, list "IESG".  For others, give the name
      of the responsible party.  Other details (e.g., postal address,
      email address, home page URI) may also be included.

   JOSE Implementation Requirements:
      The key type implementation requirements for JWS and JWE, which
      must be one the words Required, Recommended, Optional, Deprecated,
      or Prohibited.  Optionally, the word can be followed by a "+" or
      "-".  The use of "+" indicates that the requirement strength is
      likely to be increased in a future version of the specification.
      The use of "-" indicates that the requirement strength is likely
      to be decreased in a future version of the specification.

   Specification Document(s):
      Reference to the document or documents that specify the parameter,
      preferably including URIs that can be used to retrieve copies of
      the documents.  An indication of the relevant sections may also be
      included but is not required.

7.4.2.  Initial Registry Contents

   This section registers the values defined in Section 6.1.

   o  "kty" Parameter Value: "EC"
   o  Key Type Description: Elliptic Curve
   o  JOSE Implementation Requirements: Recommended+
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.2 of RFC 7518

   o  "kty" Parameter Value: "RSA"
   o  Key Type Description: RSA
   o  JOSE Implementation Requirements: Required
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.3 of RFC 7518

   o  "kty" Parameter Value: "oct"
   o  Key Type Description: Octet Sequence
   o  JOSE Implementation Requirements: Required
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.4 of RFC 7518

7.5.  JSON Web Key Parameters Registration

   This section registers the parameter names defined in Sections 6.2,
   6.3, and 6.4 of this specification in the IANA "JSON Web Key
   Parameters" registry established by [JWK].

7.5.1.  Registry Contents

   o  Parameter Name: "crv"
   o  Parameter Description: Curve
   o  Used with "kty" Value(s): "EC"
   o  Parameter Information Class: Public
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.2.1.1 of RFC 7518

   o  Parameter Name: "x"
   o  Parameter Description: X Coordinate
   o  Used with "kty" Value(s): "EC"
   o  Parameter Information Class: Public
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.2.1.2 of RFC 7518

   o  Parameter Name: "y"
   o  Parameter Description: Y Coordinate
   o  Used with "kty" Value(s): "EC"
   o  Parameter Information Class: Public
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.2.1.3 of RFC 7518

   o  Parameter Name: "d"
   o  Parameter Description: ECC Private Key
   o  Used with "kty" Value(s): "EC"
   o  Parameter Information Class: Private
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.2.2.1 of RFC 7518

   o  Parameter Name: "n"
   o  Parameter Description: Modulus
   o  Used with "kty" Value(s): "RSA"
   o  Parameter Information Class: Public
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.3.1.1 of RFC 7518

   o  Parameter Name: "e"
   o  Parameter Description: Exponent
   o  Used with "kty" Value(s): "RSA"
   o  Parameter Information Class: Public
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.3.1.2 of RFC 7518

   o  Parameter Name: "d"
   o  Parameter Description: Private Exponent
   o  Used with "kty" Value(s): "RSA"
   o  Parameter Information Class: Private
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.3.2.1 of RFC 7518

   o  Parameter Name: "p"
   o  Parameter Description: First Prime Factor
   o  Used with "kty" Value(s): "RSA"
   o  Parameter Information Class: Private
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.3.2.2 of RFC 7518

   o  Parameter Name: "q"
   o  Parameter Description: Second Prime Factor
   o  Used with "kty" Value(s): "RSA"
   o  Parameter Information Class: Private
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.3.2.3 of RFC 7518

   o  Parameter Name: "dp"
   o  Parameter Description: First Factor CRT Exponent
   o  Used with "kty" Value(s): "RSA"
   o  Parameter Information Class: Private
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.3.2.4 of RFC 7518

   o  Parameter Name: "dq"
   o  Parameter Description: Second Factor CRT Exponent
   o  Used with "kty" Value(s): "RSA"
   o  Parameter Information Class: Private
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.3.2.5 of RFC 7518

   o  Parameter Name: "qi"
   o  Parameter Description: First CRT Coefficient
   o  Used with "kty" Value(s): "RSA"
   o  Parameter Information Class: Private
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.3.2.6 of RFC 7518

   o  Parameter Name: "oth"
   o  Parameter Description: Other Primes Info
   o  Used with "kty" Value(s): "RSA"
   o  Parameter Information Class: Private
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.3.2.7 of RFC 7518

   o  Parameter Name: "k"
   o  Parameter Description: Key Value
   o  Used with "kty" Value(s): "oct"
   o  Parameter Information Class: Private
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.4.1 of RFC 7518

7.6.  JSON Web Key Elliptic Curve Registry

   This section establishes the IANA "JSON Web Key Elliptic Curve"
   registry for JWK "crv" member values.  The registry records the curve
   name, implementation requirements, and a reference to the
   specification that defines it.  This specification registers the
   parameter names defined in Section 6.2.1.1.

   The implementation requirements of a curve may be changed over time
   as the cryptographic landscape evolves, for instance, to change the
   status of a curve to Deprecated or to change the status of a curve
   from Optional to Recommended+ or Required.  Changes of implementation
   requirements are only permitted on a Specification Required basis
   after review by the Designated Experts, with the new specification
   defining the revised implementation requirements level.

7.6.1.  Registration Template

   Curve Name:
      The name requested (e.g., "P-256").  Because a core goal of this
      specification is for the resulting representations to be compact,
      it is RECOMMENDED that the name be short -- not to exceed 8
      characters without a compelling reason to do so.  This name is
      case sensitive.  Names may not match other registered names in a
      case-insensitive manner unless the Designated Experts state that
      there is a compelling reason to allow an exception.

   Curve Description:
      Brief description of the curve (e.g., "P-256 Curve").

   JOSE Implementation Requirements:
      The curve implementation requirements for JWS and JWE, which must
      be one the words Required, Recommended, Optional, Deprecated, or
      Prohibited.  Optionally, the word can be followed by a "+" or "-".

      The use of "+" indicates that the requirement strength is likely
      to be increased in a future version of the specification.  The use
      of "-" indicates that the requirement strength is likely to be
      decreased in a future version of the specification.

   Change Controller:
      For Standards Track RFCs, list "IESG".  For others, give the name
      of the responsible party.  Other details (e.g., postal address,
      email address, home page URI) may also be included.

   Specification Document(s):
      Reference to the document or documents that specify the parameter,
      preferably including URIs that can be used to retrieve copies of
      the documents.  An indication of the relevant sections may also be
      included but is not required.

7.6.2.  Initial Registry Contents

   o  Curve Name: "P-256"
   o  Curve Description: P-256 Curve
   o  JOSE Implementation Requirements: Recommended+
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.2.1.1 of RFC 7518

   o  Curve Name: "P-384"
   o  Curve Description: P-384 Curve
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.2.1.1 of RFC 7518

   o  Curve Name: "P-521"
   o  Curve Description: P-521 Curve
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 6.2.1.1 of RFC 7518

8.  Security Considerations

   All of the security issues that are pertinent to any cryptographic
   application must be addressed by JWS/JWE/JWK agents.  Among these
   issues are protecting the user's asymmetric private and symmetric
   secret keys and employing countermeasures to various attacks.

   The security considerations in [AES], [DSS], [JWE], [JWK], [JWS],
   [NIST.800-38D], [NIST.800-56A], [NIST.800-107], [RFC2104], [RFC3394],
   [RFC3447], [RFC5116], [RFC6090], and [SHS] apply to this
   specification.

8.1.  Cryptographic Agility

   Implementers should be aware that cryptographic algorithms become
   weaker with time.  As new cryptanalysis techniques are developed and
   computing performance improves, the work factor to break a particular
   cryptographic algorithm will be reduced.  Therefore, implementers and
   deployments must be prepared for the set of algorithms that are
   supported and used to change over time.  Thus, cryptographic
   algorithm implementations should be modular, allowing new algorithms
   to be readily inserted.

8.2.  Key Lifetimes

   Many algorithms have associated security considerations related to
   key lifetimes and/or the number of times that a key may be used.
   Those security considerations continue to apply when using those
   algorithms with JOSE data structures.  See NIST SP 800-57
   [NIST.800-57] for specific guidance on key lifetimes.

8.3.  RSAES-PKCS1-v1_5 Security Considerations

   While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not
   to adopt RSASSA-PKCS1-v1_5 for new applications and instead requests
   that people transition to RSASSA-PSS, this specification does include
   RSASSA-PKCS1-v1_5, for interoperability reasons, because it is
   commonly implemented.

   Keys used with RSAES-PKCS1-v1_5 must follow the constraints in
   Section 7.2 of RFC 3447.  Also, keys with a low public key exponent
   value, as described in Section 3 of "Twenty Years of Attacks on the
   RSA Cryptosystem" [Boneh99], must not be used.

8.4.  AES GCM Security Considerations

   Keys used with AES GCM must follow the constraints in Section 8.3 of
   [NIST.800-38D], which states: "The total number of invocations of the
   authenticated encryption function shall not exceed 2^32, including
   all IV lengths and all instances of the authenticated encryption
   function with the given key".  In accordance with this rule, AES GCM
   MUST NOT be used with the same key value more than 2^32 times.

   An IV value MUST NOT ever be used multiple times with the same AES
   GCM key.  One way to prevent this is to store a counter with the key
   and increment it with every use.  The counter can also be used to
   prevent exceeding the 2^32 limit above.

   This security consideration does not apply to the composite AES-CBC
   HMAC SHA-2 or AES Key Wrap algorithms.

8.5.  Unsecured JWS Security Considerations

   Unsecured JWSs (JWSs that use the "alg" value "none") provide no
   integrity protection.  Thus, they must only be used in contexts in
   which the payload is secured by means other than a digital signature
   or MAC value, or they need not be secured.

   An example means of preventing accepting Unsecured JWSs by default is
   for the "verify" method of a hypothetical JWS software library to
   have a Boolean "acceptUnsecured" parameter that indicates "none" is
   an acceptable "alg" value.  As another example, the "verify" method
   might take a list of algorithms that are acceptable to the
   application as a parameter and would reject Unsecured JWS values if
   "none" is not in that list.

   The following example illustrates the reasons for not accepting
   Unsecured JWSs at a global level.  Suppose an application accepts
   JWSs over two channels, (1) HTTP and (2) HTTPS with client
   authentication.  It requires a JWS Signature on objects received over
   HTTP, but accepts Unsecured JWSs over HTTPS.  If the application were
   to globally indicate that "none" is acceptable, then an attacker
   could provide it with an Unsecured JWS over HTTP and still have that
   object successfully validate.  Instead, the application needs to
   indicate acceptance of "none" for each object received over HTTPS
   (e.g., by setting "acceptUnsecured" to "true" for the first
   hypothetical JWS software library above), but not for each object
   received over HTTP.

8.6.  Denial-of-Service Attacks

   Receiving agents that validate signatures and sending agents that
   encrypt messages need to be cautious of cryptographic processing
   usage when validating signatures and encrypting messages using keys
   larger than those mandated in this specification.  An attacker could
   supply content using keys that would result in excessive
   cryptographic processing, for example, keys larger than those
   mandated in this specification.  Implementations should set and
   enforce upper limits on the key sizes they accept.  Section 5.6.1
   (Comparable Algorithm Strengths) of NIST SP 800-57 [NIST.800-57]
   contains statements on largest approved key sizes that may be
   applicable.

8.7.  Reusing Key Material when Encrypting Keys

   It is NOT RECOMMENDED to reuse the same entire set of key material
   (Key Encryption Key, Content Encryption Key, Initialization Vector,
   etc.) to encrypt multiple JWK or JWK Set objects, or to encrypt the
   same JWK or JWK Set object multiple times.  One suggestion for

   preventing reuse is to always generate at least one new piece of key
   material for each encryption operation (e.g., a new Content
   Encryption Key, a new IV, and/or a new PBES2 Salt), based on the
   considerations noted in this document as well as from RFC 4086
   [RFC4086].

8.8.  Password Considerations

   Passwords are vulnerable to a number of attacks.  To help mitigate
   some of these limitations, this document applies principles from RFC
   2898 [RFC2898] to derive cryptographic keys from user-supplied
   passwords.

   However, the strength of the password still has a significant impact.
   A high-entropy password has greater resistance to dictionary attacks.
   [NIST.800-63-2] contains guidelines for estimating password entropy,
   which can help applications and users generate stronger passwords.

   An ideal password is one that is as large as (or larger than) the
   derived key length.  However, passwords larger than a certain
   algorithm-specific size are first hashed, which reduces an attacker's
   effective search space to the length of the hash algorithm.  It is
   RECOMMENDED that a password used for "PBES2-HS256+A128KW" be no
   shorter than 16 octets and no longer than 128 octets and a password
   used for "PBES2-HS512+A256KW" be no shorter than 32 octets and no
   longer than 128 octets long.

   Still, care needs to be taken in where and how password-based
   encryption is used.  These algorithms can still be susceptible to
   dictionary-based attacks if the iteration count is too small; this is
   of particular concern if these algorithms are used to protect data
   that an attacker can have indefinite number of attempts to circumvent
   the protection, such as protected data stored on a file system.

8.9.  Key Entropy and Random Values

   See Section 10.1 of [JWS] for security considerations on key entropy
   and random values.

8.10.  Differences between Digital Signatures and MACs

   See Section 10.5 of [JWS] for security considerations on differences
   between digital signatures and MACs.

8.11.  Using Matching Algorithm Strengths

   See Section 11.3 of [JWE] for security considerations on using
   matching algorithm strengths.

8.12.  Adaptive Chosen-Ciphertext Attacks

   See Section 11.4 of [JWE] for security considerations on adaptive
   chosen-ciphertext attacks.

8.13.  Timing Attacks

   See Section 10.9 of [JWS] and Section 11.5 of [JWE] for security
   considerations on timing attacks.

8.14.  RSA Private Key Representations and Blinding

   See Section 9.3 of [JWK] for security considerations on RSA private
   key representations and blinding.