Skip to main content

Last Call Review of draft-ietf-json-i-json-05

Request Review of draft-ietf-json-i-json
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-01-14
Requested 2015-01-02
Authors Tim Bray
Draft last updated 2015-01-08
Completed reviews Genart Last Call review of -05 by Meral Shirazipour (diff)
Genart Telechat review of -05 by Meral Shirazipour (diff)
Secdir Last Call review of -05 by Tero Kivinen (diff)
Opsdir Last Call review of -05 by Jürgen Schönwälder (diff)
Assignment Reviewer Tero Kivinen
State Completed
Review review-ietf-json-i-json-05-secdir-lc-kivinen-2015-01-08
Reviewed revision 05 (document currently at 06)
Result Ready
Completed 2015-01-08
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes the restricted version of the JSON called
Internet JSON. This version of JSON is subset of the full JSON
restricting some uses of the full JSON (i.e it says they MUST use
UTF-8, and then it has several MUST NOTs and SHOULD NOTs limiting some
versions of JSON).

During the review process of the draft-ietf-jose-json-* there was lots
of complains about those documents by secdir reviewers, because the
text in the drafts which said that duplicate names can be parsed in
several different ways. This document forbids having duplicate
names, i.e. makes it MUST NOT.

The security considerations section is very short only saying:

   All the security considerations which apply to JSON (see RFC 7159)
   apply to I-JSON.  There are no additional security considerations
   specific to I-JSON.

And the security considerations section in RFC7159 is also quite
short, only warning about not using the eval when parsing json.

I agree that as this is only restricting the use of JSON, this does
not give any new security ocnsiderations, although I would have
expected the original JSON to have bit longer security considerations
section (especially as the format is not very simple and there are
easy ways to mess up things, but on the other hand most of security
considerations issues are going to be in the applications or protocols
using the JSON, not the actual JSON definition itself).

Anyways it might be good idea to add text to the security
considerations section, that as I-JSON restricts and limits some of
the dangerous formats of the original JSON, it might be considered to
be more secure than the original JSON, and perhaps also mention that
security critical usages of the JSON should use I-JSON instead of JSON
(perhaps even provide references to the jose specifications).

In general I think the document is ready.
kivinen at