First off, I have a general comment that there seem to be some places in the document where it is implicitly assumed that the HTTPS client and server trust each other to behave correctly and are "only" truing to detect misbehavior by other parties (i.e., CAs or parties subverting the CA infrastructure, etc.), to the exclusion of having the client and server retain some level of distrust or sanity checking of each other. I'm not sure that the client wants to always trust the server, given that the scheme is positing a universe where some clients will sometimes successfully connect to hostile servers supplied with fraudulent certificates (that validate) by the attacker.
In a related vein, in 3.1.2, should the server be allowed to exclude SCTs that it considers legitimate? What are the consequences if the server misbehaves and shares "other data that they may learn from the submission of SCTs by HTTP clients"? I'm also a little confused by the last paragraph of 3.1.2, "the selection MUST NOT be influenced by potential HTTPS clients connecting directly to the auditor". It seems like the only risk of allowing a client to request monitoring for a given site is additional resource usage by the server (assuming the client is aware of the privacy considerations of making such a request). I suspect that there is a valid concern here, but the text as written may be overly broad. I seem to be missing a normative reference for various terminology and conventions (e.g., "the timestamp, as a number", which I assume is milliseconds since the epoch, excluding leap seconds, in decimal, to match the other specs). The formatting in 4.1.3 seems funky; it looks like a list has been condensed into running text (including bullet symbols) -Ben _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
