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


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.)

2.1.1.  The report-uri Directive

The first mention of HSTS in Section2.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.

          "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 [4].

    Header field name:  Expect-CT

    Applicable protocol:  http

    Status:  standard

As per 3864, I think this field has to have the value "experimental":

       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

Best Regards,


Received on Tuesday, 31 July 2018 13:03:07 UTC