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

[Carl Wallace <[e-mail]>]

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" <[e-mail]> wrote:

>
>
>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.
>