Re: [Json] Security Considerations

Stefan Drees <stefan@drees.name> Sun, 09 June 2013 08:49 UTC

Return-Path: <stefan@drees.name>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419BB21F8E9D for <json@ietfa.amsl.com>; Sun, 9 Jun 2013 01:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.212
X-Spam-Level:
X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bwe-Y3-yk6Ef for <json@ietfa.amsl.com>; Sun, 9 Jun 2013 01:49:31 -0700 (PDT)
Received: from mout.web.de (mout.web.de [212.227.17.12]) by ietfa.amsl.com (Postfix) with ESMTP id 38DA121F8D31 for <json@ietf.org>; Sun, 9 Jun 2013 01:49:30 -0700 (PDT)
Received: from newyork.local.box ([93.129.74.105]) by smtp.web.de (mrweb002) with ESMTPSA (Nemesis) id 0Mg7Zl-1UxvX33Wzd-00NdSj; Sun, 09 Jun 2013 10:49:29 +0200
Message-ID: <51B44197.2000006@drees.name>
Date: Sun, 09 Jun 2013 10:49:27 +0200
From: Stefan Drees <stefan@drees.name>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: John Levine <johnl@taugh.com>
References: <20130609042518.11918.qmail@joyce.lan>
In-Reply-To: <20130609042518.11918.qmail@joyce.lan>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V02:K0:KD4f+I+Pxs+qAOA5pqhOp/n2NK4lKbERzxtTf5JClX5 NvWPxEzW9rca8LcICcFkkbxVP0X6W3PhBxzhxa5vJJ5x1Zxmhs brDt9dndXSldet6cO3kNhw1JUXdpcPM249JKQXfLQePF8SYdpz 7vcYK6jaCpmQu/MGbaAPzxKpwHbkECcJ5vOQFQ6kH5iqDxJwJm 9CpCcY0w+RRQKAnm5ftEA==
Cc: json@ietf.org
Subject: Re: [Json] Security Considerations
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stefan@drees.name
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Jun 2013 08:49:37 -0000

On 2013-06-09 06:25, John Levine wrote:
>>     An implementation may set limits on any of the following: the size
>>     of texts that it accepts, the maximum depth of nesting, the range of
>>     numbers, and the length and character contents of strings.
>
> Probably should say something about the precision of numbers.  With a
> limited precision internal representation, two numbers that are
> different in the JSON could end up equal internally.

yes, thus I propose as NEW:

"""
4.  Parsers

    A JSON parser transforms JSON text into another representation,
    MUST accept all texts that conform to the JSON grammar and MUST be
    prepared to either accept duplicate names in objects or reject the
    complete JSON text containing these.
    A JSON parser MAY accept non-JSON forms or extensions.

    An implementation may set limits on any of the following: the size
    of texts that it accepts, the maximum depth of nesting, the range
    and precision of numbers, and the length and character contents of
    strings.

"""

I think simply extending the caveat for numbers to range and precision
is sufficient, as integral numbers are to be considered having precision 
0 and it all starts with a "may" ;-)

Stefan.