Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7518

JSON Web Algorithms (JWA)

Pages: 69
Proposed Standard
Errata
Part 3 of 4 – Pages 32 to 53
First   Prev   Next

Top   ToC   RFC7518 - Page 32   prevText

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.
Top   ToC   RFC7518 - Page 33
   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.
Top   ToC   RFC7518 - Page 34
   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.
Top   ToC   RFC7518 - Page 35
   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
Top   ToC   RFC7518 - Page 36
   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
Top   ToC   RFC7518 - Page 37
   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
Top   ToC   RFC7518 - Page 38
   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
Top   ToC   RFC7518 - Page 39
   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
Top   ToC   RFC7518 - Page 40
   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
Top   ToC   RFC7518 - Page 41
   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
Top   ToC   RFC7518 - Page 42
   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
Top   ToC   RFC7518 - Page 43
   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.
Top   ToC   RFC7518 - Page 44

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.
Top   ToC   RFC7518 - Page 45
   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].
Top   ToC   RFC7518 - Page 46

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
Top   ToC   RFC7518 - Page 47
   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
Top   ToC   RFC7518 - Page 48
   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 "-".
Top   ToC   RFC7518 - Page 49
      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.
Top   ToC   RFC7518 - Page 50

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.
Top   ToC   RFC7518 - Page 51

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
Top   ToC   RFC7518 - Page 52
   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.
Top   ToC   RFC7518 - Page 53

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.


(page 53 continued on part 4)

Next Section