Benjamin Kaduk's Discuss on draft-ietf-httpbis-expect-ct-07: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-httpbis-expect-ct-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be a trivial discuss to resolve, but affects interoperability
so is still balloted as such.  In Section 3.1:

   o  "validated-certificate-chain": the value is the certificate chain
      as constructed by the UA during certificate chain verification.
      (This may differ from the value of the "served-certificate-chain"
      key.)  The value is provided as an array of strings, which MUST
      appear in the order matching the chain that the UA validated; each
      string in the array is the Privacy-Enhanced Mail (PEM)
      representation of each X.509 certificate as described in
      [RFC7468].

This needs to say whether the end-entity certificate appears first or last
(that is, without assuming what order the UA's chain-validation code uses).
I believe we usually say something like "the first certificate in the chain
represents the end-entity certificate being verified".


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some section-by-section comments:

Section 1

I should probably defer to the HTTP experts in the room, but I was not sure
if it is better to say that we are defining a new "HTTP header field" or a
new "HTTP response header field".

Section 1.1

RFC 8174 has updated BCP 14 boilerplate text.

Section 1.2

The "Certificate Transparency Policy" definition implicitly assumes that
SCTs will be served on TLS connections, as opposed to obtained out of band
(perhaps via a UA-side cache).  This doesn't seem immediately problematic,
but perhaps a more generic definition is advisable.

Section 2.1

Please also note that the '#' ABNF extension is specified in Section 7 of
RFC 7230.
Also, since the 'max-age' directive is required, are the semantics actually
just "#" or would "1#" be more accurate?

   4.  UAs MUST ignore any header fields containing directives, or other
       header field value data, that do not conform to the syntax
       defined in this specification.  In particular, UAs must not
       attempt to fix malformed header fields.

seems like a candidate for RFC2119 "MUST NOT".

Section 2.3.2.2

   If the substring matching the host production from the Request-URI
   (of the message to which the host responded) does not congruently
   match an existing Known Expect-CT Host's domain name, [...]

I'm having trouble parsing "production" -- is this a term of art I need to
look up?

Section 3.1

What's the extension model for the JSON report objects (e.g., if a new
"source" value needs to be defined, or a new CT version is published)?

Also, for the base64 encoded fields, are trailing '='s stripped (or do we
not care)?

Section 3.3

It's strange to say that the server MAY discard reports with "test-report"
set to true, and then not say at all what the server is supposed to do when
"test-report" is false or absent.

Section 5

   Expect-CT can be used to infer what Certificate Transparency policy
   is in use, [...]

In use by whom; the UA?