Re: [Uta] smtp-sts-04 JSON

[Viktor Dukhovni <[e-mail]>]

> On Apr 25, 2017, at 8:31 AM, Salz, Rich <[e-mail]> wrote:
> 
>> 
>> There's no reason for an RFC to describe trivial lists of pairs.
> 
> Sure there is, because folks will want whitespace, want to linearize it, support Unicode, etc.

As soon as you ask for a generally applicable syntax you end with
ASN.1, JSON, XML, ...  There's no shortage of power tools, but our
needs here are trivial, and the sensible thing to do is to specify
the simplest grammar that meets all the needs.

   * No nested lists
   * No multiple objects
   * No DTDs
   * No separate string, array, integer types
   * No complex libraries with CVEs (https://www.suse.com/security/cve/CVE-2015-8863/)

Parsing a line that contains a key and a value is trivial.  There's a bit
of mostly irrelevant bike-shedding over whether that syntax should be:

	<KEY> 1*<WSP> VALUE 0*<WSP> <CRLF>
or
	<KEY> 0*<WSP> = 0*<WSP> <VALUE> 0*<WSP> <CRLF>

where <CRLF> is either of <CR><LF> or just <LF>, and
each character of KEY and VALUE is ASCII alphanumeric
or one of ".", "-", "+".  The value encoding is "xtext"
from https://tools.ietf.org/html/rfc3461#section-4, but
none of the STSv1 keys require or shall permit hex-encoded
xtext characters.  Thus "+" may appear only in presently
ignored keys from some future update of the protocol in
which some additional policy element requires extended
characters.

Therefore parsers don't need, and will likely never need
to actually implement xtext, that's just there to avoid
objections that we may need (however unlikely) something
more general some day.

Speaking of extensibility, I don't see any reasonable
migration path from STSv1 to STSv2, except by changing
the .well-known URI, in which case putting the version
in the policy, rather than the URL is of little value.

I doubt any site will want to shut out all the deployed
STSv1 clients by switching to a hypothetical STSv2.

Therefore, we can either put a list of supported STS
versions in the DNS TXT record or live with STSv1 for
ever (likely the simplest approach, just add more
key/value pairs as needed and maintain a backwards
compatible interface).

A needlessly complex alternative is either multiple
blocks of key/value pairs separated by a blank line
with block specific to its own STS version, which
must come first, or, worse still, a list of JSON
objects.

-- 
	Viktor.