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

[Carl Wallace <[e-mail]>]

On 12/16/14, 4:35 PM, "Nico Williams" <[e-mail]> wrote:

>On Tue, Dec 16, 2014 at 03:44:05PM -0500, Carl Wallace wrote:
>> On 12/16/14, 2:37 PM, "Nico Williams" <[e-mail]> wrote:
>> >It's not.  I just don't think one should encode JSON text sequences
>>this
>> >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
>>wait
>> 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.