JSON Web Encryption (JWE)
draft-ietf-jose-json-web-encryption-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.

------

I really wish you would have factored out what's common between JWS and JWE so you didn't have so much repeated text.

1: Lose the last paragraph. It's not a core goal. Certainly not in the charter.

3.1: Failure to have an unprotected header in the compact serialization means that these things are not round-trippable. That's very unfortunate and I think a failure of the protocol.

3.2:

  In the JWE JSON Serialization, a JWE object is represented as the
  combination of these eight values...

That's not true, and potentially confusing. In the JSON Serialization, the JWE
object is represented as a JSON object with 8 members:

  protected, whose value is BASE64URL(UTF8(JWE Protected Header)),
  unprotected, whose value is JWE Shared Unprotected Header...

etc.

3.3:

- Add "If this were part of an Protected Header, it would be encoded as..."

Please show the regular JSON Serialization, not just the compact. The compact
is lousy as an overview example. If you want to add the compact after the JSON,
that's OK.

4.1.2: Change "MUST reject" to "will be unable to decrypt". Strike the last sentence of the first paragraph.

5.1:

It looks like steps 1, 2, 3, and 6 are actually one big step. They should
probably be combined and clarified in some way.

4 and 5 could be reasonably combined.

19 - Delete everything after the first sentence (and optionally point to
section 7).

5.2: If these things are steps, start with the verb. See 2 below as an example,
but look at the other steps as well.

  1 - Say what to parse out and refer to section 7. Again, don't privilege
  compact.

  4 could be significantly shortened if you didn't separate the
  serializations. Just make it the union. If some of the members are absent
  (for whatever reason), that's fine.

  4 and 5 should be combined.

  8-11 seem like they could be combined/refactored in some useful way.

  (I'll also note here that the "recipient" construct is still weird to me.
  It's just a "key owner" or something like that, right?)

  14 and 15 - Ditch the parenthetical.

  18 is kind of silly. If decryption failed, it failed. No need to
  additionally "reject" (whatever that is supposed to mean). The second and
  third sentences are just implementation detail. Delete 18.

9: It took me a bit to figure out why this section is here. This is only a
problem for the Compact Serialization. The second bullet makes this clear: For
the JSON Serialization, the answer is, "They're different if they're
different." I suggest rewriting this section to make it clear that you're
trying to help folks who need to distinguish between compact serializations.

Appendix A: Leaving the JSON Serialization until the end and putting a compact
serialization in every example stinks. Let's not make it harder for
implementers to figure out how to use the JSON Serialization.

[Ballot comment]
There are a bunch of comments here that also apply to JWS. It's a real shame you did not factor out what's common between these documents and not repeat everything in a slightly different way. I'm sure that there will be a change in one document that won't get changed in the other. Such is life.

1: Lose the last paragraph. It's not a core goal. Certainly not in the charter.

3: "base64url encoded for transmission"? Why is "transmission" in here? These things are in base64url independent of transmission aren't they?

3.1: A pointer to section 7.1 is probably appropriate here.

3.2:

  In the JWE JSON Serialization, a JWE object is represented as the
  combination of these eight values...

That's not true, and potentially confusing. In the JSON Serialization, the JWE object is represented as a JSON object with 8 members:

  protected, whose value is BASE64URL(UTF8(JWE Protected Header)),
  unprotected, whose value is JWE Shared Unprotected Header...
 
etc.

3.3: As in JWS:

- "If this were part of an Protected Header, it would be encoded as..."

Please show the regular JSON Serialization, not just the compact. The compact is lousy as an overview example. If you want to add the compact after the JSON, that's OK.

4.1.2: So I want to understand the "MUST reject" as used here. What happens if the implementation doesn't reject? Is the decrypt simply going to fail (in which case the MUST reject is not helpful), or is there some attack vector here?

5.1:

It looks like steps 1, 2, 3, and 6 are actually one big step. They should probably be combined and clarified in some way.

4 and 5 could be reasonably combined.

18 is not a step.

20 - Delete everything after the first sentence (and optionally point to section 7).

5.2: If these things are steps, start with the verb. See 2 below as an example, but look at the other steps as well.

  1 - Say what to parse out and refer to section 7. Again, don't privilege compact.

  2 - Make the verb first:

        Decode the base64url encoding of JWE Protected Header, the JWE
        Encrypted Key, the JWE Initialization Vector, the JWE
        Ciphertext, the JWE Authentication Tag, and the JWE AAD. The
        decoding MUST follow the restriction that no padding characters
        have been used.

  4 could be significantly shortened if you didn't separate the serializations. Just make it the union. If some of the members are absent (for whatever reason), that's fine.

  4 and 5 should be combined.

  9-12 seem like they could be combined/refactored in some useful way.

  (I'll also note here that the "recipient" construct is still weird to me. It's just a "key owner" or something like that, right?)

  15 and 16 - Ditch the parenthetical.

  19 is kind of silly. If decryption failed, it failed. No need to additionally "reject" (whatever that is supposed to mean). The second and third sentences are just implementation detail. Delete 19.

9: It took me a bit to figure out why this section is here. This is only a problem for the Compact Serialization. The second bullet makes this clear: For the JSON Serialization, the answer is, "They're different if they're different." I suggest rewriting this section to make it clear that you're trying to help folks who need to distinguish between compact serializations.

Appendix A: Leaving the JSON Serialization until the end and putting a compact serialization in every example stinks. Let's not make it harder for implementers to figure out how to use the JSON Serialization.

[Ballot comment]
This question is almost certainly due to my thick-headedness with respect to authentication algorithms, but:

  16.  Let the Additional Authenticated Data encryption parameter be
        ASCII(Encoded Protected Header).  However if a JWE AAD value is
        present (which can only be the case when using the JWE JSON
        Serialization), instead let the Additional Authenticated Data
        encryption parameter be ASCII(Encoded Protected Header || '.' ||
        BASE64URL(JWE AAD)).

  17.  Decrypt the JWE Ciphertext using the CEK, the JWE Initialization
        Vector, the Additional Authenticated Data value, and the JWE
        Authentication Tag (which is the Authentication Tag input to the
        calculation) using the specified content encryption algorithm,
        returning the decrypted plaintext and validating the JWE
        Authentication Tag in the manner specified for the algorithm,
        rejecting the input without emitting any decrypted output if the
        JWE Authentication Tag is incorrect.

How does it make sense for the AAD encryption parameter to consist of ASCII and BASE64 text?  How would a decryption algorithm use this?  I know nothing about AAD parameters in encryption algorithms, so I realize this is probably a very naive question.

[Ballot comment]

1.1/3.1/7.1: I think you should define BASE64URL(null) as
null so that one knows that one can see ".." in compact
representations, e.g if there this is no AAD or IV. Adding an
example of such would be good too. Or, if ".." is not
allowed, then you need to say that clearly.  (This could be
clarified loads of ways, I don't care which you pick.)

[Ballot discuss]
Overall, this document is in much more solid shape than when it began.  Thanks to the WG for a lot of hard work.  I only have one remaining concern, that should hopefully be easy to address.

Section 7.2.
I've had several implementors trying to use JWE in the JSON serialization ask why it was necessary to include a "recipients" array in cases where there's only one recipient.  It seems like this is going to be a major barrier to deployment and re-use, so I would propose including the following text:
"""
In cases where the JWE is encrypted for only one recipient, the "recipients" array will contain a single object.  In such cases, the elements of the "recipients" array MAY be included at the top level of the JWE object.  If the generator of a JWE chooses to use this representation then all unprotected header parameters MUST be carried in the "header" field, and the "unprotected" field MUST be absent.  A JSON-formatted JWE that contains a "recipients" field MUST NOT contain a "header" or "encrypted_key" field, and vice versa.
"""
This may also require some other changes where "recipients" is relied on, e.g., in Section 9.

[Ballot comment]
Section 3.3.
Why doesn't this example include the JSON encoding?

Section 4.1.3.
"This Header Parameter MUST be integrity protected"
Why is this the case?  There is no security reason that "zip" must be integrity-protected, and this requirement isn't made for any other parameter.

Section 7.2.
The requirement that the "recipients" field MUST be present seems odd.  What's the justification for this?

Appendix A seems kind of unnecessary given draft-ietf-jose-cookbook.

[Ballot comment]
== Section 2 ==
It seems a bit odd that some of these terms are re-defined by this document rather than re-using existing definitions, e.g. from RFC 4949 (plaintext, ciphertext, etc.). Was that deliberate?

== Section 4.1 ==
"As indicated by the common registry, JWSs and JWEs share a common
  Header Parameter space; when a parameter is used by both
  specifications, its usage must be compatible between the
  specifications."

Since both the JWS and JWE specifications are on their way to becoming RFCs, would it make more sense to say "its usage is compatible between the specifications"? Or is this for the future when new parameters may get defined?

[Ballot comment]
-- Section 5.2 --

  Finally, note that it is an application decision which algorithms are
  acceptable in a given context.  Even if a JWE can be successfully
  decrypted, unless the algorithms used in the JWE are acceptable to
  the application, it SHOULD reject the JWE.

It's a small point, but what does it mean for an algorithm to be
"acceptable", if not to define this very point?  That is, if I accept (don't
reject) a decryption with algorithm X, doesn't that *mean* that algorithm X
is acceptable to me?

-- Section 7.2 --

  recipients
      The "recipients" member value MUST be an array of JSON objects.
      Each object contains information specific to a single recipient.
      This member MUST be present, even if the array elements contain
      only the empty JSON object "{}" (which can happen when all Header
      Parameter values are shared between all recipients and when no
      encrypted key is used, such as when doing Direct Encryption).

I'm not sure how to read this.  Which of these is a correct version of the
"recipients" member for the case in the second sentence?:

a.  "recipients": {}
b.  "recipients": [{}]
c.  "recipients": []

Can you word this to make the answer clearer in the text?

-- Section 9 --

  o  If the object is using the JWS JSON Serialization or the JWE JSON
      Serialization, the members used will be different.  JWSs have a
      "signatures" member and JWEs do not.  JWEs have a "recipients"
      member and JWSs do not.

But you say that unrecognized members should be ignored, so an object that
contains both a "signatures" member and a "recipients" member would be
considered valid, but might be judged to be either one or the other,
depending upon the order of the checking.  Does this matter?  Possibly not,
but I wanted to ask.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-jose-json-web-encryption-31.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA notes that the action requested in the IANA Considerations Section of this document is 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 action below can be completed.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

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, thirteen new header parameter names are added as follows:

+------------------+--------------------------------------+-----------+-------------------+
| Header Parameter |                                      | Usage    | Reference        |
|    Name        | Description                          | Location  |                  |
+------------------+--------------------------------------------------+-------------------+
| alg              | Algorithm                            | JWE      | [ RFC-to-be ]    |
| enc              | Encryption Algorithm                | JWE      | [ RFC-to-be ]    |
| zip              | Compression Algorithm                | JWE      | [ RFC-to-be ]    |
| jku              | JWK Set URL                          | JWE      | [ RFC-to-be ]    |
| jwk              | JSON Web Key                        | JWE      | [ RFC-to-be ]    |
| kid              | Key ID                              | JWE      | [ RFC-to-be ]    |
| x5u              | X.509 URL                            | JWE      | [ RFC-to-be ]    |
| x5c              | X.509 Certificate Chain              | JWE      | [ RFC-to-be ]    |
| x5t#S256        | X.509 Certificate SHA-256 Thumbprint | JWE      | [ RFC-to-be ]    |
| typ              | Type                                | JWE      | [ RFC-to-be ]    |
| cty              | Content Type                        | JWE      | [ RFC-to-be ]    |
| crit            | Critical                            | JWE      | [ RFC-to-be ]    |
+------------------+--------------------------------------------------+-------------------+

IANA understands that this is the only action 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 Encryption (JWE)) 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 Encryption (JWE)'
  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


  JSON Web Encryption (JWE) represents encrypted content using
  JavaScript Object Notation (JSON) based data structures.
  Cryptographic algorithms and identifiers for use with this
  specification are described in the separate JSON Web Algorithms (JWA)
  specification and IANA registries defined by that specification.
  Related digital signature and MAC capabilities are described in the
  separate JSON Web Signature (JWS) specification.




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

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


No IPR declarations have been submitted directly on this I-D.

JSON Web Encryption (JWE) writeup:

(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 Algorithms (JWA), JSON Web Signature (JWS), 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, JSON Web Encryption (JWE), represents encrypted content 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.

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. Note, the
document shepherd did not validate the examples in the appendices.

(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 specification
with two serializations for JWE objects. This specification has been implemented
and adopted in some communities (most especially OpenID).

(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?

All authors have confirmed that they have no relevant 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.

There are no IPR disclosures filed for this document.

(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 a solid WG consensus, however there are some issues for
which consensus was difficult with strong proponents on both sides of the issues.

(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 was identified. This nit is related to downrefs to algorithm
documents and are discussed further in (15).

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

(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 is one down-reference to an information document.  This is an algorithm
document so this is normal procedure. 
 
        RFC 1951 - DEFLATE Compressed Data Format Specification version 1.3

(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 adds entries to the following IANA registry:
      JSON Web Signature and Encryption Header Parameters (defined in JWS)

(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.

This document does not create any new IANA registries.

(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.