Re: [secdir] secdir review of draft-ietf-json-text-sequence-11

Carl Wallace <> Wed, 17 December 2014 11:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2FBF91A8949 for <>; Wed, 17 Dec 2014 03:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6S9f9-MG-W7x for <>; Wed, 17 Dec 2014 03:51:50 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5B0D1A8942 for <>; Wed, 17 Dec 2014 03:51:49 -0800 (PST)
Received: by with SMTP id dc16so953362qab.37 for <>; Wed, 17 Dec 2014 03:51:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=0aBt14hBwd2fn1wNJl6sOiCGfp41M9mFExjWiTib7TE=; b=KP8ltJsvyKstpYCUIGeBbRDKSbnkA/L6bdjd9DZvCTH7S+/JEKPdzVGVnKFROL/IfI B+UdZAOKQNJM6SqV58uZNETcjPfqAcunRmf4ZgjBvMwRQ3cfSEEUxNJAbTpQAz72kfmk c3v2uxWHUc13VDqPeMRFyWFd9W7Ddjyyt9sJlCrveuqVxf4liNyjvLEeRYT3jEwCqxMR 774DlKcNIo4d7c+FQ988zAbc1qq7oHUn0eBImqUWpVDkJ1aZD9viCAtOmDA+rjevvfAg xvLiPVCRv/r5XMd+GaTuIzcwNBc7OiynY1iEEFZ3Q4Bsa5SEeHSyxun8zV16RvZ5NId6 zjfQ==
X-Gm-Message-State: ALoCoQmYrhY/w8esfqrcBZXhQDz5ZgsVLBktHpR5ECZ87A89tNIattZQBc1EZS8IYii8MbzRlZMT
X-Received: by with SMTP id k5mr75556607qaj.2.1418817108726; Wed, 17 Dec 2014 03:51:48 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id l7sm3621903qai.37.2014. (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 17 Dec 2014 03:51:48 -0800 (PST)
User-Agent: Microsoft-MacOutlook/
Date: Wed, 17 Dec 2014 06:51:41 -0500
From: Carl Wallace <>
To: Nico Williams <>
Message-ID: <>
Thread-Topic: [secdir] secdir review of draft-ietf-json-text-sequence-11
References: <> <20141216000109.GP3241@localhost> <> <20141216163238.GT3241@localhost> <> <20141216174829.GZ3241@localhost> <> <20141216193707.GE3241@localhost> <> <20141216213533.GI3241@localhost> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Subject: Re: [secdir] secdir review of draft-ietf-json-text-sequence-11
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Dec 2014 11:52:03 -0000

Sorry for the self-reply, there was also some additional text to add
clarifying incremental parsing does not cut across multiple JSON text
sequence elements (in addition to a note regarding fitness for detached
signatures and any <LF> notes).

On 12/16/14, 9:13 PM, "Carl Wallace" <> wrote:

>On 12/16/14, 4:35 PM, "Nico Williams" <> wrote:
>>On Tue, Dec 16, 2014 at 03:44:05PM -0500, Carl Wallace wrote:
>>> On 12/16/14, 2:37 PM, "Nico Williams" <> wrote:
>>> >It's not.  I just don't think one should encode JSON text sequences
>>> >way.  After lunch I'll propose text explicitly requiring sequence
>>> >encoders to also invoke the JSON text encoder.
>>> Most of the words in this now very long thread stem from this. I will
>>> to review new text. I don’t think there is any lack of clarify on the
>>> signature issue. Most of the remainder is related to the document’s
>>> recognition of <RS>123<RS> as a detectable truncation problem but not
>>> <RS>123<LF><RS> where the truncation occurred prior to invoking the
>>> sequence encoder.
>>In section 2.2, add before the last paragraph:
>>   JSON text sequence encoders are expected to ensure that the sequence
>>   elements are properly formed. When the JSON text sequence encoder
>>   does the JSON text encoding, the sequence elements will naturally be
>>   properly formed. When the JSON text sequence encoder accepts
>>   already-encoded JSON texts, the JSON text sequence encoder ought to
>>   to parse them before adding them to a sequence.
>I don’t think this is quite there as parsing the already encoded texts
>does not necessarily detect truncation. Even where the text sequence
>encoder does the JSON text encoding it may do so on an incomplete value
>due to crash or administrative process termination depending on the how
>the JSON text sequence parser is situated relative to the JSON text
>element source.  I am at a loss to supply alternate text because the text
>would cement an arrangement of the encoders that is probably
>rigid for a document defining a data structure. I still think the
>is to remove the delimiters added by the JSON text sequence encoder in
>JSON text sequence decoder.  This seems cleaner to me.  It would probably
>require the encoder to reject inputs that have not been properly
>terminated or perhaps have a flag to auto-add <ws> to non-self-delimited
>top level values before adding the <LF> where such is safe to do.
>As you have noted, the existing text that has been agreed to by the WG so
>I will defer to you, the WG and the ADs on the <LF> point. I think you
>already agreed to add some text highlighting the fact that text sequence
>elements are poor targets for detached signatures due to the fact that
>encoding the element in the sequence changes it.