Various errata from 1.1

[gkellogg]

From RDF 1.1 Errata:

• 16 – N-Quads is a syntactic superset of N-Triples
• 19 – Editorial bug in N-Quads
• 22 – Japanese translation
• 30 – Align blank node labels across NT and TTL
• 32 – Issues with N-Quads/N-Triples canonicalization
• 33 – Ambiguity of canonical N-Triples

[gkellogg]

In an email relevant to erratum 32, @kasei writes:

Within STRING_LITERAL_QUOTE, only the characters U+0022, U+005C, U+000A, U+000D are encoded using ECHAR. ECHAR must not be used for characters that are allowed directly in STRING_LITERAL_QUOTE.

Does this really mean that control characters must be written directly without escaping or encoding (e.g. NULL, BELL, BACKSPACE, etc.)? While their use probably isn’t common in N-Triples documents, the idea of a canonical representation requiring these to be written directly strikes me as ill-advised, as it makes handling of this data more difficult (e.g. having to carefully handle NULL characters vs. NULL terminators, not being able to copy-paste data containing unprintable control characters, etc.).

The ECHAR range is '\' [tbnrf"'\], which doesn't really cover control characters; those would have needed to be represented using UCHAR, which have been explicitly prohibited. We would need to add them back and require them for control characters, to be consistent, but this may be going too far far. But, this would presumably cover \u0000 through \u001F exclusive of those covered by allowed ECHAR.

I suggest we not consider this, unless there is a demonstrated need, as it was considered and resolved in 1.1.

[afs]

We should consider this.

The original motivation for a canonical form was simple processing by text tools - e.g. regex of an NT line.
Now it is for RDF canonicalization and signing. Anything that can be used to confuse makes it a security issue.

The RDF 1.1 NT text includes "Implementers are encouraged to produce this form." so the format was not mandatory. We have some room for improvements.

A change to consider is

• Characters in the codepoint range U+0020 to U+10FFFF MUST NOT be represented by UCHAR.
• Characters in the codepoint range U+0000 to U+001F MUST be represented by ECHAR or represented by UCHAR where ECHAR is not available.

All UCHAR would be better but we are where we are.

This is an outline to show something is possible - the text needs refining.

Process-wise:

I suggest creating an issue for this, label security, and close the errata.
There should be something in the security section.

(We need a better way to track cross document concerns.)

[kasei]

I suggest we not consider this, unless there is a demonstrated need, as it was considered and resolved in 1.1.

@gkellogg – Do you have any pointers to the previous discussions? From the outside of the WG, the handling of the canonical form seemed a bit rushed, and I wasn't left with the feeling that it got a lot of consideration. Would like to look into the reasoning used during 1.1 to end up with the decisions that were made.

[gkellogg]

The discussion in the RDF WG was before my time. Looking through the RDF WG mail archives doesn't provide much, either.

@ericprud was likely involved in the C14N discussions. But, @afs's points about security certainly make a case for revisiting this. @dlongley may have a view on the implications for https://github.com/w3c/rdf-canon, but I suspect that there won't be any tests that overlap with the problem areas.

See #2 (comment) for a suggested change to using ECHAR and UCHAR for canonical N-Quads/Triples.

[gkellogg]

Chatted with @ericprud on Skype. The main motivation for canonicalization in N-Triples was for testing. Best is to create an issue specific to escaping in literals, and note as an issue in the C14N section and in a new Security Considerations section.