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

[Carl Wallace <[e-mail]>]

On 12/17/14, 6:41 PM, "Nico Williams" <[e-mail]> wrote:

>On Wed, Dec 17, 2014 at 12:55:23PM -0600, Nico Williams wrote:
>> On Tue, Dec 16, 2014 at 09:13:55PM -0500, Carl Wallace wrote:
>> >                                          [...]. 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.
>> 
>> Tolerating a missing LF seems like a fine thing to do if the top-level
>> value was nonetheless valid and delimited.
>> 
>> On the other hand it adds some ambiguity if some sequence parser
>> implementations can tolerate it and others can't.

The suggestion is not to tolerate a missing <LF> but to not always add
them in the text sequence encoder in the first place. The <LF> addition
would essentially be an extension of the JSON text encoder (albeit
implemented in the text sequence encoder).  There would be no ambiguity.
The parser would always leave it in. Where integrity mechanisms are used,
the auto-<LF> would need to be turned off and the source responsible for
properly terminating inputs to the text sequence encoder.

>
>I continue to think that the best thing to do is have a recommendation
>as to how to handle ambiguities, and point them out.
>
>Therefore I don't think we should say that the parser MUST strip the
>trailing LF, but SHOULD (or MAY not strip it) would be fine, and should
>address the concern about alterations to JSON texts that can then affect
>cryptographic integrity protection.

Thinking more about stripping out the <LF>, that won’t always work either
for the same reason you have the parser reject non-self-delimited texts
that do not end with a <LF>. The text sequence encoder could terminate
before the <LF> is written possibly leaving a <LF> added by the source
exposed (and removed by a decoder). The parser really can’t know if the
JSON encoder or JSON text sequence encoder added a trailing <LF>.