I have a small contribution to this discussion, about CBOR, and then some stuff on encoding and submission formats.
> On May 5, 2016, at 1:34 AM, Aaron Zauner <[email protected]> wrote: > > Hi Chris, > > Appreciate the feedback. > >> On 05 May 2016, at 05:04, Chris Newman <[email protected]> wrote: >> >> I am opposed to using CBOR. CBOR is not well deployed. Most codebases need >> XML and JSON parsers but do not need CBOR parsers. So choosing CBOR >> significantly increases the code complexity. My codebase has a JSON and XML >> parser but no CBOR parser. I would strongly prefer to keep it that way, so >> CBOR would introduce an unnecessary deployment barrier. > > To be upfront: I'm not, and never have been, a particular fan of CBOR myself. > But I think some kind of binary format would be useful. CBOR is a newer format but it corrects the deficiencies of other prior formats. Comparing it to the so-called problems in ASN.1 is shortsighted. > >> Binary formats have an extremely poor track record for security-sentive >> applications. ASN.1 BER/DER has been an utter disaster for real-world >> security in PKIX (there are probably hundreds of CVE reports due to ASN.1 >> parser bugs including many in TLS/SSL/PKIX stacks). And there are many thousands of such reports due to parsing bugs and programmer incompetence for text formats like SQL, HTML, and XML. The common thread is not binary vs. text; the common thread is that it’s a security-sensitive program. >> We should not repeat this design error in a security-sensitive context again. > > There're very simple binary formats (CBOR is rather complex). We don't have > to use ASN.1 nor BER nor DER. And I would never want to go that way. Actually CBOR is pretty simple. There are only eight major types: positive integer, negative integer, binary string, utf-8 string, array, map, tag, and special types. You can implement a parser in less than 1K. And a big advantage of (many) binary formats in general is that they do not require data payloads to be re-encoded, e.g., in base64, which requires unnecessarily enlarging the payloads. To get to where the topic is today: if JSON is the way this draft is going, then JSON-as-CBOR is possible. JSON is just a strict subset of CBOR, so it should be pretty easy to define this in JSON, and leave the option of the wire format being in CBOR as a flag or media type field. Reading draft-brotman-smtp-tlsrpt-00, I suggest the following: Section 3. Reporting Policy should have an additional field: "f": Accepted formats of the report. This parameter is ASCII and case-insensitive; each accepted format type is indicated by one ASCII character. Values can be “j” for JSON, “c” for CBOR, and “jc” or “cj” for both. Unrecognized values can be ignored. Implementations are expected to accept JSON. In both the https and mailto upload formats, it is desirable to specify the format (specifically, the media type) of the submission. Currently this could be inferred from the current draft -> RFC 7469 -> RFC 7159, but I think it should be clearer. Specifically: is the format a single MIME content with application/json (in the case of a JSON report), and by extension, application/cbor (in the case that CBOR is acceptable) and application/xml (in the case of possible XML), or can the body be multipart/mixed? Are there other headers that ought to be specified? For example, when doing mailto, what if the mailto URI has “?subject=foo”? While we are on the topic of mailto, what if the local-part is EAI? Does that mean that the rua directive is UTF-8 encoded, or must the local-part be percent-encoded when in mailto? (Note that in the formulation above, I specifically called out “f” as being in ASCII. Since URIs are ASCII, I would think that non-ASCII characters in URIs would need to be percent-encoded, and that the domain of “rua” should suitably be limited to ASCII.) Sean _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
