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

[Nico Williams <[e-mail]>]

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.

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.

So, how about these changes to section 2.1:

    The ABNF [RFC5234] for the JSON text sequence parser is as given in
    Figure 1.

-     JSON-sequence = *(1*RS possible-JSON)
+     JSON-sequence = *(1*RS possible-JSON LF)
+     LF = %x0A; "line feed" (LF), see RFC20
      RS = %x1E; "record separator" (RS), see RFC20
               ; Also known as: Unicode Character 'INFORMATION SEPARATOR
               ;                TWO' (U+001E)
      possible-JSON = 1*(not-RS); attempt to parse as UTF-8-encoded
                                ; JSON text (see RFC7159)
      not-RS = %x00-1d / %x1f-ff; any octets other than RS

                      Figure 1: JSON text sequence ABNF

    In prose: a series of octet strings, each containing any octet other
-   than a record separator (RS) (0x1E) [RFC0020], all octet strings
-   separated from each other by RS octets.  Each octet string in the
-   sequence is to be parsed as a JSON text in the UTF-8 encoding
-   [RFC3629].
+   than a record separator (RS) (0x1E) [RFC0020], and each such octet
+   string prefixed by an RS octet and suffixed by an LF octet.  Each
+   octet string in the sequence is to be parsed as a JSON text in the
+   UTF-8 encoding [RFC3629].

    If parsing of such an octet string as a UTF-8-encoded JSON text
    fails, the parser SHOULD nonetheless continue parsing the remainder
    of the sequence.  The parser can report such failures to applications
    (which might then choose to terminate parsing of a sequence).
    Multiple consecutive RS octets do not denote empty sequence elements
    between them, and can be ignored.

+   JSON text sequence parsers MAY include the LF suffix (from the
+   sequence encoding) when parsing a JSON text sequence element, but it
+   is best not to when the sequence parser's output is the element JSON
+   texts rather than an internal representation of the parsed element
+   JSON texts.
+
    There is no end of sequence indicator.

?

Nico
--