JSON Web Algorithms (JWA)
draft-ietf-jose-json-web-algorithms-40

[Ballot comment]
I've got some suggestions for improvements below, but overall I cannot support this document, so I'm entering an ABSTAIN. I don't think this WG has actually fulfilled its charter with regard to this document set. The WG was supposed to produce a "JSON syntax that can be used by applications to describe secure data objects". I don't believe it did that. Instead, it produced a compact serialization for a particular purpose and then backed into a JSON syntax. The compact serialization drove the effort and produced IMO a substandard JSON serialization. I don't believe that (reliable) interoperable implementations of the JSON serialization will be possible using this document set. However, there is at least rough consensus that these documents are usable as-is, and I don't think there's anything to be gained by holding them up any further.

I hope the WG will adopt some of the remaining comments, but my intention is not to discuss this any further. If you wish to address any of the comments and need clarification, I'm glad to help with that.

------

3.1/4.1/5.1/6.1: The implementation requirements do not belong in this document. They should be removed.

3.2ff: None of these algorithm requirements (using MUSTs) really belong in this document. These are requirements for any new crypto algorithm that should be documented elsewhere. They are not JOSE specific.

4.8: I think the MUST for UTF-8 is seriously problematic. Because different system normalize UTF-8 strings differently, there is no way that just saying "MUST use UTF-8" makes for any kind of interoperability unless you go into much more detail. I think you should either (a) just say that it is an octet string or (b) refer to PRECIS.

4.8.1.1: s/UTF-8/ASCII

5.2.2.1:

OLD
      Here we denote the number of octets in the MAC_KEY as
      MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN;

NEW
      MAC_KEY_LEN is the number of octets in MAC_KEY and ENC_KEY_LEN is
      the number of octets in ENC_KEY.

OLD
      The number of octets in the input key K MUST be the sum of
      MAC_KEY_LEN and ENC_KEY_LEN.

NEW
      The number of octets in the input key K MUST be the sum of
      MAC_KEY_LEN and ENC_KEY_LEN.

The following is completely redundant:

      When generating the secondary keys
      from K, MAC_KEY and ENC_KEY MUST NOT overlap.

[Ballot comment]

I'm clearing but think it's still a bad plan to include the
unimplemented >2 prime RSA support here. It's even
worse to have it as you do where implementations that
don't support this are allowed to use the key pair
nonetheless - that seems designed to lead to a lack
of security or else horrible performance. You should
say that if you don't support >2 prime RSA then you MUST
barf on all such keys. However, based on my belief
that this won't get used in any case, I'm willing to hold
my nose and clear.

-- older comments below, I didn't check them vs. -37
and there's no need to worry about them unless you
want to.


First point was a discuss, now a comment:

(2) Instructions to DEs: would registering DES be considered
ok or not? What about myJustInventedPrivateAlg?  What about a
request for 10 ccTLD specific Algs? I think these need a bit
more clarity wrt cryptographic "goodness." As a nit, "makes
sense" isn't going to help too much, we've seen that
reasonable folks can differ on that here. Again I don't
recall that discussion on the list, but please point me at it
if it happened.

- Unlike others, I do think implementation requirements are
needed. The WG did specifically discuss this (a lot) and
landed where it did. I don't think the IESG should second
guess that without specific evidence that it'd cause damage.
(Richard's points were made previously I believe.)

- 3.3 (and elsewhere) says 2048 bits or larger. I guess that
2049 bit keys might not work for many implementations and are
not a great idea (as Bleichenbacher works quicker against
such lengths if I recall correctly). Could be worth a note
somewhere even though I guess most folks know what's what.

- 4.1 (and elsewhere): adding table captions with numbers
would be good. Col 1 of the final 3 rows are unfortunate.

- Surprised there was no need for integer DH. Can be added
later I guess.

- 6.2.1: Given that the point compression IPR is now expired
(right?) did the WG consider now allowing that? I wondered
how much work it would be to add now, vs to add later. If
"later" would cause a lot of duplication, then maybe "now"
would actually be worth it. ("Later" might also be fine
considering the current work in CFRG on additional curves.)

- 6.3.1.1: allowing the extra 0x00 would be a better choice
IMO, but whatever. Those were historically added so that
buggy decoders wouldn't wrongly think numbers negative, which
could still happen maybe.

- 7.1, 2nd para: why not RSA2048 earlier then?

- 7.1.1: It might help the DE if the template here required
references to well know academic crypto conference
publications that consider cryptanalysis of the alg in
question, e.g. from crypto, or eurocrypt etc. One good rule
of thumb here is that if there are no such references then
you really should not register the thing.

- 8.3: Is 65537 considered a "low" e?  "Low" is too vague
there.

- 8.5: I'd prefer there was no none. The WG did discuss it
though, so I'll hold my nose.

- 8.6: suggesting a CA as a cure for oversized keys is odd, I
think those are separable things and e.g. TOFU might be just
as or more effective then X.509 here.

- Appendix A:  Thanks for that! It'll save folks a lot of
time. Might be better presented as a set of records and not
as a fixed width table.

- I think most of the secdir stuff has been handled (and
thanks for that) so I'm fine that the authors and AD are on
top of that.

[Ballot discuss]

Sent mail Oct 21 asking if list are ok with inclusion really.
Will clear if an answer comes back.

Sorry to pile on, but I guess such a detailed and broad piece
of work is likely to attract many comments and discusses.
Mine should be cleared up easily enough I hope.

(1) 6.3.2.7: Hmm, where was that discussed on the list?  I
think it'd be better if >2 prime RSA was considered a
separate algorithm. (I vaguely recall some IPR with such
moduli for some uses too, but not sure.) I'd recommend
dropping the whole "oth" parameter entirely.  (I'll clear
this discuss once its clear that this was discussed by the
WG, I just want to check as I don't recall it.)

(2) cleared

[Ballot discuss]

Sorry to pile on, but I guess such a detailed and broad piece
of work is likely to attract many comments and discusses.
Mine should be cleared up easily enough I hope.

(1) 6.3.2.7: Hmm, where was that discussed on the list?  I
think it'd be better if >2 prime RSA was considered a
separate algorithm. (I vaguely recall some IPR with such
moduli for some uses too, but not sure.) I'd recommend
dropping the whole "oth" parameter entirely.  (I'll clear
this discuss once its clear that this was discussed by the
WG, I just want to check as I don't recall it.)

(2) cleared

[Ballot comment]

First point was a discuss, now a comment:

(2) Instructions to DEs: would registering DES be considered
ok or not? What about myJustInventedPrivateAlg?  What about a
request for 10 ccTLD specific Algs? I think these need a bit
more clarity wrt cryptographic "goodness." As a nit, "makes
sense" isn't going to help too much, we've seen that
reasonable folks can differ on that here. Again I don't
recall that discussion on the list, but please point me at it
if it happened.

- Unlike others, I do think implementation requirements are
needed. The WG did specifically discuss this (a lot) and
landed where it did. I don't think the IESG should second
guess that without specific evidence that it'd cause damage.
(Richard's points were made previously I believe.)

- 3.3 (and elsewhere) says 2048 bits or larger. I guess that
2049 bit keys might not work for many implementations and are
not a great idea (as Bleichenbacher works quicker against
such lengths if I recall correctly). Could be worth a note
somewhere even though I guess most folks know what's what.

- 4.1 (and elsewhere): adding table captions with numbers
would be good. Col 1 of the final 3 rows are unfortunate.

- Surprised there was no need for integer DH. Can be added
later I guess.

- 6.2.1: Given that the point compression IPR is now expired
(right?) did the WG consider now allowing that? I wondered
how much work it would be to add now, vs to add later. If
"later" would cause a lot of duplication, then maybe "now"
would actually be worth it. ("Later" might also be fine
considering the current work in CFRG on additional curves.)

- 6.3.1.1: allowing the extra 0x00 would be a better choice
IMO, but whatever. Those were historically added so that
buggy decoders wouldn't wrongly think numbers negative, which
could still happen maybe.

- 7.1, 2nd para: why not RSA2048 earlier then?

- 7.1.1: It might help the DE if the template here required
references to well know academic crypto conference
publications that consider cryptanalysis of the alg in
question, e.g. from crypto, or eurocrypt etc. One good rule
of thumb here is that if there are no such references then
you really should not register the thing.

- 8.3: Is 65537 considered a "low" e?  "Low" is too vague
there.

- 8.5: I'd prefer there was no none. The WG did discuss it
though, so I'll hold my nose.

- 8.6: suggesting a CA as a cure for oversized keys is odd, I
think those are separable things and e.g. TOFU might be just
as or more effective then X.509 here.

- Appendix A:  Thanks for that! It'll save folks a lot of
time. Might be better presented as a set of records and not
as a fixed width table.

- I think most of the secdir stuff has been handled (and
thanks for that) so I'm fine that the authors and AD are on
top of that.

[Ballot discuss]

Sorry to pile on, but I guess such a detailed and broad piece
of work is likely to attract many comments and discusses.
Mine should be cleared up easily enough I hope.

(1) 6.3.2.7: Hmm, where was that discussed on the list?  I
think it'd be better if >2 prime RSA was considered a
separate algorithm. (I vaguely recall some IPR with such
moduli for some uses too, but not sure.) I'd recommend
dropping the whole "oth" parameter entirely.  (I'll clear
this discuss once its clear that this was discussed by the
WG, I just want to check as I don't recall it.)

(2) Instructions to DEs: would registering DES be considered
ok or not? What about myJustInventedPrivateAlg?  What about a
request for 10 ccTLD specific Algs? I think these need a bit
more clarity wrt cryptographic "goodness." As a nit, "makes
sense" isn't going to help too much, we've seen that
reasonable folks can differ on that here. Again I don't
recall that discussion on the list, but please point me at it
if it happened.

[Ballot comment]

- Unlike others, I do think implementation requirements are
needed. The WG did specifically discuss this (a lot) and
landed where it did. I don't think the IESG should second
guess that without specific evidence that it'd cause damage.
(Richard's points were made previously I believe.)

- 3.3 (and elsewhere) says 2048 bits or larger. I guess that
2049 bit keys might not work for many implementations and are
not a great idea (as Bleichenbacher works quicker against
such lengths if I recall correctly). Could be worth a note
somewhere even though I guess most folks know what's what.

- 4.1 (and elsewhere): adding table captions with numbers
would be good. Col 1 of the final 3 rows are unfortunate.

- Surprised there was no need for integer DH. Can be added
later I guess.

- 6.2.1: Given that the point compression IPR is now expired
(right?) did the WG consider now allowing that? I wondered
how much work it would be to add now, vs to add later. If
"later" would cause a lot of duplication, then maybe "now"
would actually be worth it. ("Later" might also be fine
considering the current work in CFRG on additional curves.)

- 6.3.1.1: allowing the extra 0x00 would be a better choice
IMO, but whatever. Those were historically added so that
buggy decoders wouldn't wrongly think numbers negative, which
could still happen maybe.

- 7.1, 2nd para: why not RSA2048 earlier then?

- 7.1.1: It might help the DE if the template here required
references to well know academic crypto conference
publications that consider cryptanalysis of the alg in
question, e.g. from crypto, or eurocrypt etc. One good rule
of thumb here is that if there are no such references then
you really should not register the thing.

- 8.3: Is 65537 considered a "low" e?  "Low" is too vague
there.

- 8.5: I'd prefer there was no none. The WG did discuss it
though, so I'll hold my nose.

- 8.6: suggesting a CA as a cure for oversized keys is odd, I
think those are separable things and e.g. TOFU might be just
as or more effective then X.509 here.

- Appendix A:  Thanks for that! It'll save folks a lot of
time. Might be better presented as a set of records and not
as a fixed width table.

- I think most of the secdir stuff has been handled (and
thanks for that) so I'm fine that the authors and AD are on
top of that.

[Ballot discuss]
Moving this first one from a comment to a discuss in light of Richard's comment:

3.1/4.1/5.1/6.1: Why are there implementation requirements in this document? I am also curious, as Richard is, whether these are going to be used at all, and I'd like to hear the explanation that the WG had for including these. Are implementation requirements for JOSE different from implementation requirements for any other use of signing or encryption for each of these algorithms? Don't we already have a separate general registry of algorithms and their implementation statuses? Why are these necessary?

4.6.2: AlgorithmID. UTF-8 has me worried here. It has me more worried in 4.8, but we'll talk about that later. Here, aren't all "enc" and "alg" values US-ASCII anyway? Saying US-ASCII here would solve the problem, so unless you think you're going to have the MötleyCrüe algorithm, perhaps we can avoid any concerns for this case. (My concern is that you can have "interesting" UTF-8 strings with ZERO-WIDTH JOINERs and other nonsense that you probably don't mean to address.

4.8:

  The PBES2 password input is an
  octet sequence; if the password to be used is represented as a text
  string rather than an octet sequence, the UTF-8 encoding of the text
  string MUST be used as the octet sequence.

This one worries me a lot. It's one thing to say that the password is an octet sequence and the application above is responsible for collecting it from the user and passing it in the correct form. But to say down here in the guts that it MUST be UTF-8 brings up all sorts of ugly questions regarding normalization. I don't think you want to touch this with a 10-foot-pole. I certainly thing you want to stay away from that MUST.

4.8.1.1: Same as 4.6.2.

[Ballot comment]
For the life of me, I can't figure out why this document set uses the terminology "JSON Web Foo". Seems like buzzword nonsense. I would have much preferred "JOSE Foo" for each one.

3.2:

  A key of the same size as the hash output (for instance, 256 bits for
  "HS256") or larger MUST be used with this algorithm.

Is this specific to JOSE, or is this a general requirement for use of SHA-2? If the latter, a reference would be better than a MUST in here.

[There are many things in the document that look like algorithm requirements and not JOSE requirements. I've noted a few more below, but these should be looked for generally. If something is part of the definition of the algorithm and documented elsewhere, no need to have requirements language, let alone a description of how to run the algorithm, in this document; that should be an external reference.]

In the 5th paragraph (the one right after the table), strike everything after the first sentence. Decoding and encoding are things that are JWS specific and should not be in this document.

3.3/3.5/4/2/4.3:

  A key of size 2048 bits or larger MUST be used with this algorithm.

Is this specific to JOSE, or is this a general requirement for use of RSA?

3.6: This section seems to be for the JWS document, not this one. If you want to define the "None" algorithm, go ahead and do that, but describing its use in JWS doesn't belong here.

4.6:

  A new ephemeral public key value MUST be generated for each key
  agreement operation.

Again, specific to JOSE, or requirement of ECDH-ES?

  In Direct Key Agreement mode, the output of the Concat KDF MUST be a
  key of the same length as that used by the "enc" algorithm.

and

  In Key Agreement with Key Wrapping mode, the output of the Concat KDF
  MUST be a key of the length needed for the specified key wrapping
  algorithm.
 
s/MUST/will?

4.6.1.2/4.6.1.3: These are not very well defined, and it's not clear why they need to be base64ed. What are they?

5.2.2.1:

      Here we denote the number of octets in the MAC_KEY as
      MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN;

Oh, dear. That's a pretty convoluted way of saying (I think) "MAC_KEY_LEN is the number of octets in MAC_KEY and ENC_KEY_LEN is the number of octets in ENC_KEY." If you mean something different, you best explain.

      the values of these parameters are specified by the Authenticated
      Encryption algorithms in Sections 5.2.3 through 5.2.5.
      The number of octets in the input key K MUST be the sum of
      MAC_KEY_LEN and ENC_KEY_LEN.
     
"MUST"? Do you mean "is"?
     
      When generating the secondary keys
      from K, MAC_KEY and ENC_KEY MUST NOT overlap.
     
Isn't that completely redundant? If length of K is the sum of MAC_KEY_LEN and ENC_KEY_LEN, then MAC_KEY and ENC_KEY *can't* overlap.
     
6.2: s/MUST be/is

[Ballot discuss]
Section 3.2.
"This computed HMAC value is then compared to the result of base64url decoding the received encoded JWS Signature value."
Need to add:
"In order to avoid timing attacks, the comparison of the computed HMAC value to the JWS Signature value MUST be done in a constant-time manner."

Section 3.6.
I'm not going to object to "none", even though I think it's a very dangerous feature because of the risk of confusion between Secured and Unsecured JWS. But there needs to be stronger guidance:
1. An implementation SHOULD NOT support "none" unless the implementor knows that it will be used in application context s that require it.
2. If an implementation does support "none", then it MUST NOT accept it as part of generic JWS validation.  Instead, it should require the application to explicitly signal that an Unsecured JWS is expected for a given validation operation.

Section 4.2.
Systems that support RSAES-PKCS1-V1_5 key unwrap are commonly vulnerable to oracle attacks based on whether they accept the wrapped key or not.  See, e.g.,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25431
http://cryptosense.com/choice-of-algorithms-in-the-w3c-crypto-api/
In light of that, it seems irresponsible to include this algorithm without extensive security precautions, and especially irresponsible for it to be REQUIRED.  It's been dropped from WebCrypto, and is being dropped from TLS in v1.3.

Section 6.3.1.
The descriptions of these parameters are really vague, especially when it comes to the "oth" parameters.  Please cite a reference that provides more detail, e.g., RFC 3447.

Section 6.3.2.6.
This section defines the wrong parameter.

[Ballot comment]
Section 1.1.
The pointer for BASE64URL should be to JWS.  One level of indirection, please :)

Section 3.1, 4.1, and 5.1.
As I said in the working group, the implementation requirements in these registries should be removed.  They are unnecessary for interoperability, and highly likely to be ignored by implementors, both because (1) many implementations are for specific applications that do not require all of the REQUIRED algorithms, and (2) many implementations use cryptographic libraries that do not support some REQUIRED algorithms.  I have personally written more than one JWS/JWE implementation that ignored these requirements, for exactly these reasons.  (This would be a DISCUSS for me, if not for my having made this argument already in the WG.)

Section 3.2.
"A key of the same size as the hash output (for instance, 256 bits for "HS256") or larger MUST be used with this algorithm."
A pointer to Section 3 of RFC 2104 here would be helpful.  I was surprised at this requirement, given that FIPS 198 says "The size of the key, K, shall be equal to or greater than L/2, where L is the size of the hash function output."

Section 3.4.
It might be worth noting that though this format seems ad-hoc, it is the same used by WebCrypto.

Section 4.7.1.1.
Shouldn't you require that this field MUST encode a 16-octet / 128-bit value?

[Ballot discuss]
4.6.2: AlgorithmID. UTF-8 has me worried here. It has me more worried in 4.8, but we'll talk about that later. Here, aren't all "enc" and "alg" values US-ASCII anyway? Saying US-ASCII here would solve the problem, so unless you think you're going to have the MötleyCrüe algorithm, perhaps we can avoid any concerns for this case. (My concern is that you can have "interesting" UTF-8 strings with ZERO-WIDTH JOINERs and other nonsense that you probably don't mean to address.

4.8:

  The PBES2 password input is an
  octet sequence; if the password to be used is represented as a text
  string rather than an octet sequence, the UTF-8 encoding of the text
  string MUST be used as the octet sequence.

This one worries me a lot. It's one thing to say that the password is an octet sequence and the application above is responsible for collecting it from the user and passing it in the correct form. But to say down here in the guts that it MUST be UTF-8 brings up all sorts of ugly questions regarding normalization. I don't think you want to touch this with a 10-foot-pole. I certainly thing you want to stay away from that MUST.

4.8.1.1: Same as 4.6.2.

[Ballot comment]
For the life of me, I can't figure out why this document set uses the terminology "JSON Web Foo". Seems like buzzword nonsense. I would have much preferred "JOSE Foo" for each one.

3.1/4.1/5.1/6.1: Why are there implementation requirements in this document? Are implementation requirements for JOSE different from implementation requirements for any other use of signing or encryption for each of these algorithms? Don't we already have a separate general registry of algorithms and their implementation statuses?

3.2:

  A key of the same size as the hash output (for instance, 256 bits for
  "HS256") or larger MUST be used with this algorithm.

Is this specific to JOSE, or is this a general requirement for use of SHA-2? If the latter, a reference would be better than a MUST in here.

[There are many things in the document that look like algorithm requirements and not JOSE requirements. I've noted a few more below, but these should be looked for generally. If something is part of the definition of the algorithm and documented elsewhere, no need to have requirements language, let alone a description of how to run the algorithm, in this document; that should be an external reference.]

In the 5th paragraph (the one right after the table), strike everything after the first sentence. Decoding and encoding are things that are JWS specific and should not be in this document.

3.3/3.5/4/2/4.3:

  A key of size 2048 bits or larger MUST be used with this algorithm.

Is this specific to JOSE, or is this a general requirement for use of RSA?

3.6: This section seems to be for the JWS document, not this one. If you want to define the "None" algorithm, go ahead and do that, but describing its use in JWS doesn't belong here.

4.6:

  A new ephemeral public key value MUST be generated for each key
  agreement operation.

Again, specific to JOSE, or requirement of ECDH-ES?

  In Direct Key Agreement mode, the output of the Concat KDF MUST be a
  key of the same length as that used by the "enc" algorithm.

and

  In Key Agreement with Key Wrapping mode, the output of the Concat KDF
  MUST be a key of the length needed for the specified key wrapping
  algorithm.
 
s/MUST/will?

4.6.1.2/4.6.1.3: These are not very well defined, and it's not clear why they need to be base64ed. What are they?

5.2.2.1:

      Here we denote the number of octets in the MAC_KEY as
      MAC_KEY_LEN, and the number of octets in ENC_KEY as ENC_KEY_LEN;

Oh, dear. That's a pretty convoluted way of saying (I think) "MAC_KEY_LEN is the number of octets in MAC_KEY and ENC_KEY_LEN is the number of octets in ENC_KEY." If you mean something different, you best explain.

      the values of these parameters are specified by the Authenticated
      Encryption algorithms in Sections 5.2.3 through 5.2.5.
      The number of octets in the input key K MUST be the sum of
      MAC_KEY_LEN and ENC_KEY_LEN.
     
"MUST"? Do you mean "is"?
     
      When generating the secondary keys
      from K, MAC_KEY and ENC_KEY MUST NOT overlap.
     
Isn't that completely redundant? If length of K is the sum of MAC_KEY_LEN and ENC_KEY_LEN, then MAC_KEY and ENC_KEY *can't* overlap.
     
6.2: s/MUST be/is

[Ballot comment]
== Section 3.4 ==
"Signing and validation with the ECDSA P-384 SHA-384 and ECDSA P-521
  SHA-512 algorithms is performed identically to the procedure for
  ECDSA P-256 SHA-256 -- just using the corresponding hash algorithms
  with correspondingly larger result values.  For ECDSA P-384 SHA-384,
  R and S will be 384 bits each, resulting in a 96 octet sequence.  For
  ECDSA P-521 SHA-512, R and S will be 521 bits each, resulting in a
  132 octet sequence."

For the ECDSA P-521 SHA-512 case, how does the result amount to 132 octets? Is there padding inserted into R and S?

== Section 7 ==

Do we use iesg@iesg.org? I usually use iesg@ietf.org.

== Section 8.4 ==
"An Initialization Vector value MUST never be used multiple times with
  the same AES GCM key."

I think what was intended here was s/MUST never/MUST NOT/

[Ballot comment]
I have one comment.  I'm making it non-blocking, but I think it really does need to be clarified, so please chat with me about it:

-- Section 7.1 --

  The implementation requirements of an algorithm MAY be changed over
  time by the Designated Experts(s) 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, with the new
  specification defining the revised implementation requirements level.

1 (minor). The "MAY" does not refer to a protocol option, and I think it should not be a 2119 key word.

2 (the real point). I don't understand how the two sentences relate to each other.  The first sentence seems to say that the DE(s) can change implementation requirements on their own.  The second says it has to be done using Specification Required (which doesn't really need to be said, as that's the policy for the registry anyway).

Which is it?  If it's Specification Required, then anyone can propose a change, using a specification, and the DE(s) will review that as they do any other registration request.

This comment also applies to Sections 7.4 and 7.6.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-jose-json-web-algorithms-31.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA notes that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of other documents.  In particular, IANA notes that draft-ietf-jose-json-web-signature is required to be approved -- and its IANA Actions completed -- before the second action below can be completed.  IANA also notes that draft-ietf-jose-json-web-key is required to be approved -- and its IANA Actions completed -- before the fifth action below can be completed.

IANA also has a question about the sixth action requested in the IANA Considerations section of the document.

IANA understands that, upon approval of this document, there are six actions which IANA must complete.

IANA understands that, for the new registries created below, the following registry maintenance rules will be applied:

Values are registered on a Specification Required [RFC5226] basis after a two-week review period on the [TBD]@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 Expert(s) may approve registration once they are satisfied that such a specification will be published.

Registration requests must be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for access token type: example"). We understand that anyone requesting registration from IANA should be directed to the mailing list, and that a designated expert will contact us upon approval of any request.

First, in a location to be determined, IANA will create a new registry called the JSON Web Signature and Encryption Algorithms Registry.  The registry records the algorithm name, the algorithm usage locations, implementation requirements, and a reference to the specification that defines it. 

There are initial registrations in this new registry as follows:

+---------------------+-----------------+----------------+-------------------+
| Algorithm          | Algorithm Usage | Implementation | Reference        |
|    Name            |    Location    |  Requirements  |                  |
+---------------------+-----------------+----------------+-------------------+
| HS256                alg              Required        [ RFC-to-be ]      |
| HS384                alg              Optional        [ RFC-to-be ]      |
| HS512                alg              Optional        [ RFC-to-be ]      |
| RS256                alg              Recommended      [ RFC-to-be ]      |
| RS384                alg              Optional        [ RFC-to-be ]      |
| RS512                alg              Optional        [ RFC-to-be ]      |
| ES256                alg              Recommended+    [ RFC-to-be ]      |
| ES384                alg              Optional        [ RFC-to-be ]      |
| ES512                alg              Optional        [ RFC-to-be ]      |
| PS256                alg              Optional        [ RFC-to-be ]      |
| PS384                alg              Optional        [ RFC-to-be ]      |
| PS512                alg              Optional        [ RFC-to-be ]      |
| none                alg              Optional        [ RFC-to-be ]      |
| RSA1_5              alg              Required        [ RFC-to-be ]      |
| RSA-OAEP            alg              Optional        [ RFC-to-be ]      |
| RSA-OAEP-256        alg              Optional        [ RFC-to-be ]      |
| A128KW              alg              Recommended      [ RFC-to-be ]      |
| A192KW              alg              Optional        [ RFC-to-be ]      |
| A256KW              alg              Recommended      [ RFC-to-be ]      |
| dir                  alg              Recommended      [ RFC-to-be ]      |
| ECDH-ES              alg              Recommended+    [ RFC-to-be ]      |
| ECDH-ES+A128KW      alg              Recommended      [ RFC-to-be ]      |
| ECDH-ES+A192KW      alg              Recommended      [ RFC-to-be ]      |
| ECDH-ES+A256KW      alg              Recommended      [ RFC-to-be ]      |
| A128GCMKW            alg              Optional        [ RFC-to-be ]      |
| A192GCMKW            alg              Optional        [ RFC-to-be ]      |
| A256GCMKW            alg              Optional        [ RFC-to-be ]      |
| PBES2-HS256+A128KW  alg              Optional        [ RFC-to-be ]      |
| PBES2-HS384+A192KW  alg              Optional        [ RFC-to-be ]      |
| PBES2-HS512+A256KW  alg              Optional        [ RFC-to-be ]      |
| A128CBC-HS256        enc              Required        [ RFC-to-be ]      |
| A192CBC-HS384        enc              Optional        [ RFC-to-be ]      |
| A256CBC-HS512        enc              Required        [ RFC-to-be ]      |
| A128GCM              enc              Recommended      [ RFC-to-be ]      |
| A192GCM              enc              Optional        [ RFC-to-be ]      |
| A256GCM              enc              Recommended      [ RFC-to-be ]      |
+---------------------+-----------------+----------------+-------------------+

Second, in the JSON Web Signature and Encryption Header Parameters registry created by the approval of draft-ietf-jose-json-web-signature and the completion of the IANA Actions within it, seven new header parameter names are added as follows:

+------------------+---------------------------+-----------------------------+-------------------+
| Header Parameter |                          | Usage                      | Reference        |
|    Name        | Description              | Location                    |                  |
+------------------+---------------------------+-----------------------------+-------------------+
| epk              | Ephemeral Public Key      | JWE                        | [ RFC-to-be ]    |
| apu              | Agreement PartyUInfo      | JWE                        | [ RFC-to-be ]    |
| apv              | Agreement PartyVInfo      | JWE                        | [ RFC-to-be ]    |
| iv              | Initialization Vector    | JWE                        | [ RFC-to-be ]    |
| tag              | Authentication Tag        | JWE                        | [ RFC-to-be ]    |
| p2s              | PBES2 salt                | JWE                        | [ RFC-to-be ]    |
| p2c              | PBES2 count              | JWE                        | [ RFC-to-be ]    |
+------------------+---------------------------+-----------------------------+-------------------+

Third, in a location to be determined, IANA will create a new registry called the JSON Web Encryption Compression Algorithms Registry.  The registration rules for the new reqistry are noted above.  The registry records the compression algorithm value and a reference to the specification that defines it.

There is an initial registration in this new registry as follows:

+----------------------+-------------------------+
| Compression          | Reference              |
| Algorithm            |                        |
+----------------------+-------------------------+
| DEF                  | [ RFC-to-be ]          |
+----------------------+-------------------------+

Fourth, in a location to be determined, IANA will create a new registry called the JSON Web Key Types Registry.  The registration rules for the new reqistry are noted above.  The registry records the "kty" value, implementation requirements, and a reference to the specification that defines it.

There are initial registrations in this new registry as follows:

+---------------+----------------------+-------------------------+
| kty Parameter | Implementation      |                        |
| Value        | Requirements        | Reference              |
+---------------+----------------------+-------------------------+
| EC            | Recommended+        | [ RFC-to-be ]          |
| RSA          | Required            | [ RFC-to-be ]          |
| oct          | Required            | [ RFC-to-be ]          |
+---------------+----------------------+-------------------------+

Fifth, in the JSON Web Key Parameters registry created by the approval of draft-ietf-jose-json-web-key and the completion of the IANA Actions within it, fourteen new parameter names are added as follows:

+-----------+-----------------------------+-------+--------------------------+-----------------+
| Parameter |                            | "KTY" | Information              |                |
| Name      | Description                | Value | Class                    | Reference      |
+-----------+-----------------------------+-------+--------------------------+-----------------+
| crv      | Curve                      | EC    | Public                  | [ RFC-to-be ]  |
| x        | X Coordinate                | EC    | Public                  | [ RFC-to-be ]  |
| y        | Y Coordinate                | EC    | Public                  | [ RFC-to-be ]  |
| d        | ECC Private Key            | EC    | Private                  | [ RFC-to-be ]  |
| n        | Modulus                    | RSA  | Public                  | [ RFC-to-be ]  |
| e        | Exponent                    | RSA  | Public                  | [ RFC-to-be ]  |
| d        | Private Exponent            | RSA  | Private                  | [ RFC-to-be ]  |
| p        | First Prime Factor          | RSA  | Private                  | [ RFC-to-be ]  |
| q        | Second Prime Factor        | RSA  | Private                  | [ RFC-to-be ]  |
| dp        | First Factor CRT Exponent  | RSA  | Private                  | [ RFC-to-be ]  |
| dq        | Second Factor CRT Exponent  | RSA  | Private                  | [ RFC-to-be ]  |
| qi        | First CRT Coefficient      | RSA  | Private                  | [ RFC-to-be ]  |
| oth      | Other Primes Info          | RSA  | Private                  | [ RFC-to-be ]  |
| k        | Key Value                  | oct  | Private                  | [ RFC-to-be ]  |
+-----------+-----------------------------+-------+--------------------------+-----------------+

Sixth, in a location to be determined, IANA will create a new registry called the JSON Web Key Elliptic Curve Registry.  The registration rules for the new registry are noted above.  The registry records the curve name, implementation requirements, and a reference to the specification that defines it.

There are three initial registrations in this new registry as follows:

+----------+------------------------+---------------------+
| Curve    | Implementation        |                    |
| Name    | Requirements          | Reference          |
+----------+------------------------+---------------------+
| P-256    | Recommended+          | [ RFC-to-be ]      |
| P-384    | Optional              | [ RFC-to-be ]      |
| P-521    | Optional              | [ RFC-to-be ]      |
+----------+------------------------+---------------------+

IANA Question --> should the curve name "P-521" actually be "P-512"?


IANA understands that these six actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (JSON Web Algorithms (JWA)) to Proposed Standard


The IESG has received a request from the Javascript Object Signing and
Encryption WG (jose) to consider the following document:
- 'JSON Web Algorithms (JWA)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-09-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The JSON Web Algorithms (JWA) 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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1962/
  http://datatracker.ietf.org/ipr/1966/

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?

This document is being requested for publication as a Proposed Standard. The
document was produced with the expectation that it would be widely used in
conjunction with the JSON Web Signature (JWS), JSON Web Encryption (JWE),
and JSON Web Key (JWK) documents as part of a suite of documents providing
security services for JSON. As such, it is reasonable for these documents to
progress on the standards track. The intended status is shown on the title page. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This document, the JSON Web Algorithms (JWA) 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 establishes several IANA registries for these identifiers.

Working Group Summary:

The document has clear working group consensus for publication, and has
been reviewed by several WG participants since its initial adoption as a
working group item. The question of what cryptographic algorithms should be
included was somewhat difficult as it is for any process trying to determine
which algorithms should be included. The considerations included what is
implemented, available, broadly used, and adequate from a security
perspective. The issue of algorithms that are potentially less desirable but
more broadly implemented was considered.

Document Quality:

This document has been reviewed and revised many times. There are multiple
implementations of this document. Some of these are listed at:
https://openid.net/developers/libraries/ (see the JWT/JWS/JWE/JWK/JWA
Implementations section). There were no specific external expert reviews
conducted; however, the WGLC notification was sent to the W3C WebCrypto
working group.

Personnel:

Karen O'Donoghue is acting as the Document Shepherd.  Kathleen Moriarty is
the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

The document shepherd has followed the working group process and reviewed
the final document and feels this document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document shepherd does not have any concerns about the reviews that
were performed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP,
XML, or internationalization? If so, describe the review that took place.

This document doesnÕt require any special reviews beyond those planned
during the IESG review process. As a security specification, additional security
reviews during this process are expected.

(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should
be aware of? For example, perhaps he or she is uncomfortable with certain
parts of the document, or has concerns whether there really is a need for it. In
any event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

The Document Shepherd is comfortable with this document as a stable set of
algorithms and the definition of registries for the addition of further
algorithms. There has also been some coordination with the W3C WebCrypto
working group regarding the definition and use of these registries. The
documents represent the consensus of the working group.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

The author has confirmed that he has dealt with all appropriate IPR
disclosures.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

Certicom Corporation has filed an IPR discloser on draft-ietf-jose-json-web-
algorithms dealing with elliptical curve technologies.  These patents are the
normal IPR disclosure from Certicom and received only a brief discussion. The
group was notified of an additional possible patent from IBM, but no discloser
was ever filed and no discussion was ever held on the patent. (The patent
appears to be a mechanical transformation of XML digital signatures and
mapping it onto JSON.)

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or does
the WG as a whole understand and agree with it?

The document represents strong WG consensus, but as in all things involving
cryptographic algorithms these days, there were some dissenting opinions
along the way.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate email
messages to the Responsible Area Director.

There have been no threats of anyone appealing the documents.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

The following nit errors were identified. These nits are all related to downrefs
to algorithm documents and are discussed further in (15).

JWA
** Downref: Normative reference to an Informational RFC: RFC 2104
** Downref: Normative reference to an Informational RFC: RFC 2898
** Downref: Normative reference to an Informational RFC: RFC 3394
** Downref: Normative reference to an Informational RFC: RFC 6090

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

There are no formal review criteria for this document.

(13) Have all references within this document been identified as either
normative or informative?

All references are tagged as normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are on track for completion or are completed.

(15) Are there downward normative references (see RFC 3967)? If so, list
these downward references to support the Area Director in the Last Call
procedure.

There are a number of down-references to information documents.  These are
all algorithm documents so this is normal procedure. 

JSON-Web-Algorithms:
        RFC 2104 - HMAC: Keyed-Hashing for Message Authentication
        RFC 2898 - PKCS #5: Password-Based Cryptography Specification Version
2.0
        RFC 3394 - Advanced Encryption Standard (AES) Key Wrap Algorithm
        RFC 6090 - Fundamental Elliptic Curve Cryptography Algorithms

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this information
is not in the document, explain why the WG considers it unnecessary.

These documents are all first time documents.  They will not change the status
of any existing documents.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that
newly created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested
(see RFC 5226).

This document defines the following IANA registries including a name, initial
entries, and future allocation procedures:
JSON Web Signature and Encryption Algorithms Registry
JSON Web Encryption Compression Algorithms Registry
JSON Web Key Types Registry
JSON Web Key Elliptic Curve Registry

Additionally, this document adds entries to the following IANA registries:
JSON Web Signature and Encryption Header Parameters (defined in JWS)
JSON Web Key Parameters Registry (defined in JWK)

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

All of the registries created by these documents are designated as requiring
Expert Review.  The registries to be created are:

JSON-Web-Algorithms:
* JSON Web Signature Encryption Algorithm Registry
* JSON Web Encryption Compression Algorithm Registry
* JSON Web Key Types Registry
* JSON Web Key Elliptic Curve Registry

At this time it is known that there will be new allocations from the W3C
WebCrypto WG and the IETF OAuth WG.  Selection of expert reviewers needs to
be broader than the current set of authors give the potential scope of the
registry.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal language,
such as XML code, BNF rules, MIB definitions, etc.

There are no formal language sections in these documents.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?

This document is being requested for publication as a Proposed Standard. The
document was produced with the expectation that it would be widely used in
conjunction with the JSON Web Signature (JWS), JSON Web Encryption (JWE),
and JSON Web Key (JWK) documents as part of a suite of documents providing
security  services for JSON. As such, it is reasonable for these documents to
progress on the standards track. The intended status is shown on the title page. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This document, the JSON Web Algorithms (JWA) 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.

Working Group Summary:

The document has clear working group consensus for publication, and has
been reviewed by several WG participants since its initial adoption as a
working group item. The question of what cryptographic algorithms should be
included was somewhat difficult as it is for any process trying to determine
which algorithms should be included. The considerations included what is
implemented, available, broadly used, and adequate from a security
perspective. The issue of algorithms that are potentially less desirable but
more broadly implemented was considered.

Document Quality:

This document has been reviewed and revised many times. There are multiple
implementations of this document. Some of these are listed at:
https://openid.net/developers/libraries/ (see the JWT/JWS/JWE/JWK/JWA
Implementations section). There were no specific external expert reviews
conducted; however, the WGLC notification was sent to the W3C WebCrypto
working group.

Personnel:

Karen O'Donoghue is acting as the Document Shepherd.  Kathleen Moriarty is
the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

The document shepherd has followed the working group process and reviewed
the final document and feels this document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document shepherd does not have any concerns about the reviews that
were performed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP,
XML, or internationalization? If so, describe the review that took place.

This document doesnÕt require any special reviews beyond those planned
during the IESG review process. As a security specification, additional security
reviews during this process are expected.

(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should
be aware of? For example, perhaps he or she is uncomfortable with certain
parts of the document, or has concerns whether there really is a need for it. In
any event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

The Document Shepherd is comfortable with this document as a stable set of
algorithms and the definition of registries for the addition of further
algorithms. There has also been some coordination with the W3C WebCrypto
working group regarding the definition and use of these registries. The
documents represent the consensus of the working group.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

The author has confirmed that he has dealt with all appropriate IPR
disclosures.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

Certicom Corporation has filed an IPR discloser on draft-ietf-jose-json-web-
algorithms dealing with elliptical curve technologies.  These patents are the
normal IPR disclosure from Certicom and received only a brief discussion. The
group was notified of an additional possible patent from IBM, but no discloser
was ever filed and no discussion was ever held on the patent. (The patent
appears to be a mechanical transformation of XML digital signatures and
mapping it onto JSON.)

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or does
the WG as a whole understand and agree with it?

The document represents strong WG consensus, but as in all things involving
cryptographic algorithms these days, there were some dissenting opinions
along the way.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate email
messages to the Responsible Area Director.

There have been no threats of anyone appealing the documents.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

The following nit errors were identified. These nits are all related to downrefs
to algorithm documents and are discussed further in (15).

JWA
** Downref: Normative reference to an Informational RFC: RFC 2104
** Downref: Normative reference to an Informational RFC: RFC 2898
** Downref: Normative reference to an Informational RFC: RFC 3394
** Downref: Normative reference to an Informational RFC: RFC 6090

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

There are no formal review criteria for this document.

(13) Have all references within this document been identified as either
normative or informative?

All references are tagged as normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

All normative references are on track for completion or are completed.

(15) Are there downward normative references (see RFC 3967)? If so, list
these downward references to support the Area Director in the Last Call
procedure.

There are a number of down-references to information documents.  These are
all algorithm documents so this is normal procedure. 

JSON-Web-Algorithms:
        RFC 2104 - HMAC: Keyed-Hashing for Message Authentication
        RFC 2898 - PKCS #5: Password-Based Cryptography Specification Version
2.0
        RFC 3394 - Advanced Encryption Standard (AES) Key Wrap Algorithm
        RFC 6090 - Fundamental Elliptic Curve Cryptography Algorithms

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this information
is not in the document, explain why the WG considers it unnecessary.

These documents are all first time documents.  They will not change the status
of any existing documents.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that
newly created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested
(see RFC 5226).

This document defines the following IANA registries including a name, initial
entries, and future allocation procedures:
JSON Web Signature and Encryption Algorithms Registry
JSON Web Encryption Compression Algorithms Registry
JSON Web Key Types Registry
JSON Web Key Elliptic Curve Registry

Additionally, this document adds entries to the following IANA registries:
JSON Web Signature and Encryption Header Parameters (defined in JWS)
JSON Web Key Parameters Registry (defined in JWK)

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

All of the registries created by these documents are designated as requiring
Expert Review.  The registries to be created are:

JSON-Web-Algorithms:
* JSON Web Signature Encryption Algorithm Registery
* JSON Web Encryption Compression Algorithm Registry
* JSON Web Key Types Registry
* JSON Web Key Elliptic Curve Registry

At this time it is known that there will be new allocations from the W3C
WebCrypto WG and the IETF OAuth WG.  Selection of expert revewers needs to
be broader than the current set of authors give the potential scope of the
registry.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal language,
such as XML code, BNF rules, MIB definitions, etc.

There are no formal language sections in these documents.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is being requested for publication as a Proposed Standard. The document was produced with the expectation that it would be widely used in conjunction with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) documents as part of a suite of documents providing security  services for JSON. As such, it is reasonable for these documents to progress on the standards track. The intended status is shown on the title page. 

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document, the JSON Web Algorithms (JWA) 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.

Working Group Summary:

The document has clear working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item. The question of what cryptographic algorithms should be included was somewhat difficult as it is for any process trying to determine which algorithms should be included. The considerations included what is implemented, available, broadly used, and adequate from a security perspective. The issue of algorithms that are potentially less desirable but more broadly implemented was considered.

Document Quality:

This document has been reviewed and revised many times. There are multiple implementations of this document. Some of these are listed at: https://openid.net/developers/libraries/ (see the JWT/JWS/JWE/JWK/JWA Implementations section). There were no specific external expert reviews conducted; however, the WGLC notification was sent to the W3C WebCrypto working group.

Personnel:

Karen O'Donoghue is acting as the Document Shepherd.  Kathleen Moriarty is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has followed the working group process and reviewed the final document and feels this document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document shepherd does not have any concerns about the reviews that were performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document doesn’t require any special reviews beyond those planned during the IESG review process. As a security specification, additional security reviews during this process are expected.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The Document Shepherd is comfortable with this document as a stable set of algorithms and the definition of registries for the addition of further algorithms. There has also been some coordination with the W3C WebCrypto working group regarding the definition and use of these registries. The documents represent the consensus of the working group.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The author has confirmed that he has dealt with all appropriate IPR disclosures.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Certicom Corporation has filed an IPR discloser on draft-ietf-jose-json-web-algorithms dealing with elliptical curve technologies.  These patents are the normal IPR disclosure from Certicom and received only a brief discussion. The group was notified of an additional possible patent from IBM, but no discloser was ever filed and no discussion was ever held on the patent. (The patent appears to be a mechanical transformation of XML digital signatures and mapping it onto JSON.)

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document represents strong WG consensus, but as in all things involving cryptographic algorithms these days, there were some dissenting opinions along the way.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.

There have been no threats of anyone appealing the documents.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The following nit errors were identified. These nits are all related to downrefs to algorithm documents and are discussed further in (15).

JWA
** Downref: Normative reference to an Informational RFC: RFC 2104
** Downref: Normative reference to an Informational RFC: RFC 2898
** Downref: Normative reference to an Informational RFC: RFC 3394
** Downref: Normative reference to an Informational RFC: RFC 6090

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no formal review criteria for this document.

(13) Have all references within this document been identified as either normative or informative?

All references are tagged as normative or informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are on track for completion or are completed.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are a number of down-references to information documents.  These are all algorithm documents so this is normal procedure. 

JSON-Web-Algorithms:
        RFC 2104 - HMAC: Keyed-Hashing for Message Authentication
        RFC 2898 - PKCS #5: Password-Based Cryptography Specification Version 2.0
        RFC 3394 - Advanced Encryption Standard (AES) Key Wrap Algorithm
        RFC 6090 - Fundamental Elliptic Curve Cryptography Algorithms

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

These documents are all first time documents.  They will not change the status of any existing documents.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

This document defines the following IANA registries including a name, initial entries, and future allocation procedures:
JSON Web Signature and Encryption Algorithms Registry
JSON Web Encryption Compression Algorithms Registry
JSON Web Key Types Registry
JSON Web Key Elliptic Curve Registry

Additionally, this document adds entries to the following IANA registries:
JSON Web Signature and Encryption Header Parameters (defined in JWS)
JSON Web Key Parameters Registry (defined in JWK)

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

All of the registries created by these documents are designated as requiring Expert Review.  The registries to be created are:

JSON-Web-Algorithms:
* JSON Web Signature Encryption Algorithm Registery
* JSON Web Encryption Compression Algorithm Registry
* JSON Web Key Types Registry
* JSON Web Key Elliptic Curve Registry

At this time it is known that there will be new allocations from the W3C WebCrypto WG and the IETF OAuth WG.  Selection of expert revewers needs to be broader than the current set of authors give the potential scope of the registry.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There are no formal language sections in these documents.

This represents a combined writeup for four documents

JWA - draft-ietf-jose-json-web-algorithms
JWE - draft-ietf-jose-json-web-encryption
JWK - draft-ietf-jose-json-web-key
JWS - draft-ietf-jose-json-web-signature

********************************

(1) These documents are being requested for progress at at Proposed Standard.  The documents were produced in the expectation that they will be widely used to provide security services for JSON documents, as such it is reasonable for these documents to progress on the standards track.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

(JWA) This document, the JSON Web Algorithms (JWA) 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.

(JWE) This document, JSON Web Encryption (JWE), represents encrypted content using JavaScript Object Notation (JSON) based data structures.

(JWK) This document, JSON Web Key (JWK), is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key.  This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs.

(JWS) This document, JSON Web Signature (JWS), represents content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) based data structures. 

Working Group Summary:

The document has clear working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item.

(JWA) The question of what cryptographic algorithms should be included was somewhat difficult as it is for any process trying to determine which algorithms should be included. The considerations included what is implemented, available, broadly used, and adequate from a security perspective. The issue of algorithms that are potentially less desirable but more broadly implemented was considered.

Document Quality:

There are multiple implementations of all four documents. There were no specific external expert reviews conducted. The WGLC notification was sent to the W3C WebCrypto working group.

Personnel:

Karen O'Donoghue is acting as the Document Shepard.  Kathleen Morirty  is the Responsible Area Director

(3) The document shepherd has followed the working group process and reviewed the final documents and feels these documents are ready for IESG review. Further discussion and changes may result from IESG and IETF review, but the documents as they stand are ready for publication.

(4) The document shepherd does not have any concerns about the reviews that were performed.

(5) JSON-Web-Signture and JSON-Web-Key register new Media Types.  A request for review has been sent to the media type review mailing list.

(6) The Document Shepherd is comfortable with these documents as a stable set of specifications that have been implemented and adopted in some communities (most especially OpenID). There has also been some attempt to coordinate with the W3C WebCrypto working group. The documents are not perfect, but they do represent the consensus of the working group. There is a minority contingent of recognized experts that believe there are a number of issues in the documents. However, these specifications have been widely implemented and deployed in the OpenID community.

(7) All authors have confirmed that they have dealt with all appropriate IPR disclosures.

(8) Certicom Corporation has filed an IPR discloser on draft-ietf-jose-json-web-algorithms and draft-ietf-jose-json-web-signature dealing with elliptical curve technologies.  These patents are the normal IPR disclosure from Certicom and received only a brief discussion. The group was notified of an additional possible patent from IBM, but no discloser was ever filed and no discussion was ever held on the patent. (The patent appears to be a mechanical transformation of XML digital signatures and mapping it onto JSON.)

(9) The majority of the documents represent a solid WG consensus, however there are some issues for which consensus was reached more by fatigue, with strong proponents on both sides of the issues.

(10) There have been no threats of anyone appealing the documents.

(11) The following nit errors were identified. These nits are all related to downrefs to algorithm documents and are discussed further in (15).

JWA
** Downref: Normative reference to an Informational RFC: RFC 2104
** Downref: Normative reference to an Informational RFC: RFC 2898
** Downref: Normative reference to an Informational RFC: RFC 3394
** Downref: Normative reference to an Informational RFC: RFC 6090

JWE
** Downref: Normative reference to an Informational RFC: RFC 1951

JWK
** Downref: Normative reference to an Historic RFC: RFC 1421
** Downref: Normative reference to an Informational RFC: RFC 2818

JWS
** Downref: Normative reference to an Historic RFC: RFC 1421
** Downref: Normative reference to an Informational RFC: RFC 2818


(12) JSON-Web-Signture and JSON-Web-Key register new Media Types.  A request for review has been sent to the media type review mailing list.

(13) All references are tagged as normative or informative.

(14) All normative references are on track for completion or are completed.

(15) There are a number of down-references to information documents.  These are all algorithm documents so this is normal procedure.  There is one down-reference to an Historic document.

JSON-Web-Algorithms:
        RFC 2104 - HMAC: Keyed-Hashing for Message Authentication
        RFC 2898 - PKCS #5: Password-Based Cryptography Specification Version 2.0
        RFC 3394 - Advanced Encryption Standard (AES) Key Wrap Algorithm
        RFC 6090 - Fundamental Elliptic Curve Cryptography Algorithms

JSON-Web-Encryption:
        RFC 1951 - DEFLATE Compressed Data Format Specification version 1.3

JSON-Web-Key:
        RFC 1421 - Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures  (Historic)
        RFC 2818 - HTTP Over TLS

JSON-Web-Signature:
        RFC 1421 - Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures
        RFC 2818 - HTTP Over TLS

(16) These documents are all first time documents.  They will not change the status of any existing documents.

(17) The chairs have walked through all of the documents to verify that all of the items that need to be registered have been called out in the IANA considerations section and that they are consistant between what is in the text and what is in the registration templates.  The WG was careful to try and call out the necessary information needed to do adaquate review on new items for the registry.

(18) All of the registries created by these documents are designated as requiring Expert Review.  The registries to be created are:

JSON-Web-Algorithms:
* JSON Web Signature Encryption Algorithm Registery
* JSON Web Encryption Compression Algorithm Registry
* JSON Web Key Types Registry
* JSON Web Key Elliptic Curve Registry

JSON-Web-Key:
* JSON Web Key Parameters Registry
* JSON Web Key Use Registry
* JSON Web Key Operations Registry
* JSON Web Key Set Parameters Registry

JSON-Web-Signature:
* JSON Web Signature and Encryption Header Parameters Registry

At this time it is known that there will be new allocations from the W3C WebCrypto group and the OAuth WG.  The major concern is going to be the fact that if the authors of the current drafts are selected as the reviewers, it is not going to lead to independent reviewers.  However it is not clear where the pool of reviewers should be drawn from if the current authors are excluded.

(19) There are no formal language sections in these documents.