Comments on draft-stark-expect-ct-00

Overall:
Is there a reason to not have this be attached to the HSTS header (or,
I guess more weakly to HPKP)?  The syntax seems like it allows it. It
seems like we go to all the trouble of making these headers extensible
(indeed, the syntax in S 2.1) seems almost identical to HSTS but then
we define a new header each time.

At least, it would be nice to merge the report-uri function/description.

I am probably missing something, but I don't see the text that defines
what the actual semantics of enforcing CT are. The document says stuff
like "The UA evaluates each connection to an Expect-CT host for
compliance with the UA's Certificate Transparency (CT) policy" which
leads me to believe that different UAs might have different policies.
Assuming I am correct, this seems like a recipe for interop problems,
even with the compliance checking in S 2.3.1. Consider the case where
a UA's policy is that you must have CT for every cert in the chain
and the operator has two certs, one from a CA which has CT for every
cert in the chain and another from a CA which has CT just for the EE
cert. If the client gets Expect-CT from a host with the first cert,
then it will fail trying to connect to a host with the second cert.


S 2.1.3.
What's the rationale for not caching the directive in report-only mode.
If the purpose of the report-only mode is to tell you when you have
nonconforming servers, then don't you want to be able to turn it on
on server A and detect hwen server B is broken? That seems like it
doesn't work if you don't cache.

-Ekr