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

Carl Wallace <> Wed, 17 December 2014 02:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7E6871A0248 for <>; Tue, 16 Dec 2014 18:14:06 -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 VwRkBV2oANb4 for <>; Tue, 16 Dec 2014 18:14:04 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B71B1A0140 for <>; Tue, 16 Dec 2014 18:14:04 -0800 (PST)
Received: by with SMTP id r5so11197240qcx.41 for <>; Tue, 16 Dec 2014 18:14:03 -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=KZ3HyPkty8P9vWnfUHvltozK1/QFASwrp9yGkEK6glI=; b=igaGklWEIgUorPOKlxkfJDSKFRD3K7qH05lqNwoEmztvojJR0KKUdCiGZ0NV0B/nVG Ib18y0w/qSmVnZ//l7YvnqktrqLfaLEl5rE0pkXlBME616K/R7AxICSSKt/c8GRytQeF EplqnbvqGOj1m9pp39fBcpg50qjcbnLC/BMdmcnYT3Ktaj7NyTFoIgmxEjhCBQE2Zlqm pdsALVRlyjX1IRVsDQEP25k/c2EoImo9hW+vgOfJ/vSBxHKokimEWBDzJ3sDJIU1v1Hn cgL4yzRdJSjIOnLSRoswQh7txnMCquD+VICTFqb9qloGJIhV+3AUzyeEgcHNEyTsLmBw EsRA==
X-Gm-Message-State: ALoCoQkIIjWV+ELedJ73bYvdyiTTLf/TCruqBa0p2LaazuXENjwKEGYcHnWfyi6VoNtSDs9EC2oz
X-Received: by with SMTP id l4mr67364341qgf.91.1418782443726; Tue, 16 Dec 2014 18:14:03 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id t5sm2659822qad.5.2014. (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Dec 2014 18:14:03 -0800 (PST)
User-Agent: Microsoft-MacOutlook/
Date: Tue, 16 Dec 2014 21:13:55 -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: <20141216213533.GI3241@localhost>
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 02:14:06 -0000

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 unnecessarily
rigid for a document defining a data structure. I still think the solution
is to remove the delimiters added by the JSON text sequence encoder in the
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.