While I realize this WG is focused on the technical implementation of transparency, I think it is helpful to review what has been proposed or implemented by clients for transparency.
As with my prior email, I think I have all these facts right, but I would appreciate feedback if I got them wrong. I've numbered them to help with replies but there is no meaning to the order. 1) At least one client has announced an intent to require certificates to be included in CT to be trusted, as the default state. Currently a subset of certificates have this requirement, but the intent from clients appears to be to set this as the default rule for all certificates at some point. 2) Clients have said they will exclude certificates that do not chain to roots included in the default trust list from this requirement. (It is a unclear what happens if a user adds a CA that is cross-signed by a public CA as a locally installed trust anchor.) 3) No client, as far as I know, allows scoping a trust anchor when it is added. Adding a local trust anchor trusts it for the entire DNS hierarchy. 4) All clients that allow adding local trust anchors give these anchors super powers, such as overriding public key pinning. There is no way to prevent a local trust anchor from having this power. 5) Some clients or client OSes make it extremely hard for users to add local trust anchors. 6) At least one client has proposed to have a client setting, available only via "enterprise policy" which allows excluding domain subtrees from the CT requirement. 7) Not all client software packages that have announced they are considering a CT-by-default rule have integration with common enterprise police management systems. 8) On Windows, many popular versions (such as Windows 10 Home) do not have policy support. 9) There is no ability to allow only certain policies to be set. If you enable a policy administrator access to set a domain whitelist they can also disable numerous security features and install browser extensions. Thanks, Peter _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
