> On Jan 26, 2018, at 9:41 AM, Brotman, Alexander
> <[email protected]> wrote:
>
> We uploaded a new version of the TLSRPT a few moments ago. The majority of
> the changes are meant to address comments submitted by Viktor Dukhovni
> (https://www.ietf.org/mail-archive/web/uta/current/msg02388.html). A rough
> list of changes:
>
> - Update to mime type
> - Add dnssec-required
> - TLSA record change
> - Change scale phrasing
> - Make source-of-truth language more clear
> - Change label vs labels
> - Add IP to report
>
> Please let us know if you have any further comments. Thank you.
Thanks. Progress on most of the issues, but some nits remain or were
introduced (especially the MIME changes are not right yet):
Section 4.4, page 11: example policy string:
o "policy-string": A string representation of the policy, whether
TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples:
TLSA: ""_25._tcp.mx.example.com. 3 0 1 \ 1F850A337E6DB9C609C522D13
6A475638CC43E1ED424F8EEC8513D747D1D085D)"" MTA-STS: ""version:
STSv1\nmode: report\nmx: mx1.example.com\nmx: \
mx2.example.com\nmx: mx.backup-example.com\nmax_age: 12345678""
This was incompletely updated and the TLSA example is rather mangled.
This element lacks a proper grammar. The intention seems to be a string
of newline separated elements (I'd prefer a JSON array of strings).
Please provide a better example, and ideally some text describing the
syntax in a bit more detail.
Section 5.1, page 13: file format recommendation:
This section provides an ABNF grammar for an element of the report
that is merely a convenience for when reports arrive in mailbox
read by a human postmaster who saves the attached reports manually.
Such a specific prescription is unnecessary. Better text would just
indicate that each report's filename should ideally identify the
origin of the report and the policy domain plus a unique report id.
The section ends with:
For example, this
is a possible filename for the gzip file of a report to the Policy
Domain "example.net" from the Sending MTA "mail.sender.example.com":
"mail.sender.example.com!example.net!1470013207!1470186007!001.json"
But, if the file is indeed compressed, a more friendly file extension
would be ".json.gz" not ".json".
The new version then confuses the MIME contexts of HTTPS and Email.
It is in HTTPS where "Content-Encoding" is supported, and so no
separate MIME type or MIME type parameter is needed to signal
compression. While Email has no support for "Content-Encoding"
and so it is there a "conversions = gzip" parameter could be
added to the Content-Type.
In either case, there'd be no need for the "application/tlsrpt+gzip"
media type defined in Section 6.4.
Bottom line it looks like the MIME changes were made in haste, and
are incomplete. Please take a closer look at these and decide whether
there's to be a single media type with compression signalled separately,
via Content-Encoding for HTTPS and a new "conversions" parameter (clearly
defined with the proper context) for email.
Please be less prescriptive about the email filename, it is not essential
to interoperability. If the draft is much less prescriptive about the
format of the message subject or attachment filename, there's probably
no need for section 5.6, as there is then no possibility to specify
conflicting metadata in what are essentially free-form courtesy fields
for human consumption.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
