Re: [secdir] draft-ietf-appsawg-json-pointer-07 SECDIR Review

Mark Nottingham <> Wed, 02 January 2013 04:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D86A521F8E1F; Tue, 1 Jan 2013 20:12:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.783
X-Spam-Status: No, score=-103.783 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sREKAOqNRg3Q; Tue, 1 Jan 2013 20:12:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1BBDC21F8E1E; Tue, 1 Jan 2013 20:12:42 -0800 (PST)
Received: from (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id BFCE8509B5; Tue, 1 Jan 2013 23:12:39 -0500 (EST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Wed, 02 Jan 2013 15:12:35 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Donald Eastlake <>
X-Mailer: Apple Mail (2.1499)
Subject: Re: [secdir] draft-ietf-appsawg-json-pointer-07 SECDIR Review
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Jan 2013 04:12:43 -0000

Thanks for the review; replies below.

On 31/12/2012, at 2:11 PM, Donald Eastlake <> wrote:

> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
> This draft describes two closely related syntaxes for pointers to
> objects within a JSON (JavaScript Object Notation) document. One is a
> JSON string syntax, the other is a URI fragment identifier for URIs
> defined to take such a fragment identifier.
> Security:
> I do not see any security problems with this document. The syntax
> appears to be unambiguously specified, including ABNF, and the
> Security Considerations Section is adequate and touches on the
> potential pit-falls that JSON pointers can contain NULs.
> Miscellaneous:
> I found significant ambiguity in the semantics of a JSON pointer
> string. Is the result of the successful evaluation ("evaluation" is a
> term used in the draft) of such a pointer string a structure that
> points into a JSON document or is it the objection pointed to? It
> mostly seems to be an object but it is specifically provided that
> array references could point beyond the end of an array and at least
> in that case perhaps some sort of pointer structure would be returned
> with the error condition. It probably doesn't matter, because these
> syntaxes are intended to be used in a variety of applications and it
> will be up to the application to clarify the semantics.

I think it's purposefully ambiguous, to accommodate a variety of applications.

> Minor:
> The expansion for the acronym JSON should be given in the title and abstract.


> In the first line of the second paragraph of Section 6, I found the
> word "nominate" kind of odd. Why not "specify" or "select" or "use"?


> None of the Authors Addresses given includes a postal address.


Mark Nottingham