Re: AD review of draft-ietf-httpbis-expect-ct-07

Thanks for the feedback! I've addressed this in
https://github.com/httpwg/http-extensions/commit/c2ae923f03a25432c145292b0ceda5f99f750e22,
with a couple clarifications inline.

On Tue, Jul 31, 2018 at 6:06 AM Alexey Melnikov <alexey.melnikov@isode.com>
wrote:

> Hi,
>
> The document is well written, but I have a short list of issues I would
> like to discuss:
>
> 2.1.  Response Header Field Syntax
>
>    Expect-CT           = #expect-ct-directive
>    expect-ct-directive = directive-name [ "=" directive-value ]
>    directive-name      = token
>    directive-value     = token / quoted-string
>
>               Figure 1: Syntax of the Expect-CT header field
>
>    Optional white space ("OWS") is used as defined in Section 3.2.3 of
>
> I don't see "OWS" used above. Should it be used around the "=" character?
>
> It looks like you've copied syntanx from RFC 6797, which used old HTTP
> ABNF with "implied *LWS" rule.
> So you need to update it to explicitly insert OWS. (It is already a part
> of #expect-ct-directive construct though.)
>
This was leftover from mashing up RFC 6797 and 7469, and I think it's
actually just not needed at all anymore (no OWS is intended around the "=").


>
>
>
> 2.1.1.  The report-uri Directive
>
> The first mention of HSTS in Section 2.1.1 needs a reference to [RFC6797].
>
>
>    UAs SHOULD limit the rate at which they send reports.  For example,
>    it is unnecessary to send the same report to the same "report-uri"
>    more than once.
>
> "More than once" in which period. Ever? I think you need to
> elaborate/clarify here.
>
>
> In Section 3.1:
>
>      *  The "serialized_sct" key, with a string value.  If the value of
>          the "version" key is "1", the UA MUST set this value to the
>          base64 encoded [RFC4648] serialized
>
> Which base64 alphabet? There is one in section 4 and another one in
> section 5 of that RFC.
>
Is this really needed? Happy to include it for clarity's sake, but Section
5 of RFC 4648 already says:

This encoding may be referred to as "base64url".  This encoding
should not be regarded as the same as the "base64" encoding and
should not be referred to as only "base64".  Unless clarified
otherwise, "base64" refers to the base 64 in the previous section.

>
>          "SignedCertificateTimestamp" structure from Section 3.2 of
>          [RFC6962].  If the value of the "version" key is "2", the UA
>          MUST set this value to the base64 encoded [RFC4648] serialized
>
> As above.
>
>          "TransItem" structure representing the SCT, as defined in
>          Section 4.5 of [I-D.ietf-trans-rfc6962-bis].
>
>
> 6.1.  Header Field Registry
>
>    This document registers the "Expect-CT" header field in the
>    "Permanent Message Header Field Names" registry located at
>    https://www.iana.org/assignments/message-headers [4].
>
>    Header field name:  Expect-CT
>
>    Applicable protocol:  http
>
>    Status:  standard
>
>
> As per 3864, I think this field has to have the value "experimental":
>
>    Status:
>       Specify "standard", "experimental", "informational", "historic",
>       "obsoleted", or some other appropriate value according to the type
>       and status of the primary document in which it is defined.  For
>       non-IETF specifications, those formally approved by other
>       standards bodies should be labelled as "standard"; others may be
>       "informational" or "deprecated" depending on the reason for
>       registration.
>
> Best Regards,
>
> Alexey
>