#130: Support Delegation of SCT Feedback/STH Pollination
Comment (by [email protected]): Quick sanity check: Does delegation mean that the HTTPS server instructs its client to use a certain URL for report back, a URL that most probably has a host part (in the RFC1738 section 3.3 sense) that is not the same as the host part of the visited URL? Assuming yes, I've thought of SCT Feedback as something collected by the very same server as served the SCT and cert chain the client wants to report about. That server may, or even should, let auditors and monitors learn about what's collected. It must do so in a privacy preserving manner (that isn't fully laid out in the gossip draft). Having the client go to another server for reporting is bad not only from a privacy perspective but also from a blocking perspective. The idea with performing the reporting in the same TLS session as the ordinary request(s) will not translate to a delegation scenario AFAICT. As for STH Pollination, I don't know yet. Seems less problematic but I would probably want my browser not to connect to any domain (URL host part) that I haven't requested. Think "refusing third party content". -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-trans-threat- [email protected] | [email protected] Type: defect | Status: new Priority: major | Milestone: Component: gossip | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/130#comment:3> trans <http://tools.ietf.org/trans/> _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
