Why wouldn’t the rest be relevant? Particularly, if one goal of redaction is to remove private information from logs but the log operator is not permitted to set policy to exclude certificates that chain to an included root, then it seems very relevant to the redaction discussion.
From: Trans [mailto:[email protected]] On Behalf Of Ryan Sleevi Sent: Wednesday, March 8, 2017 6:24 AM To: Peter Bowen <[email protected]> Cc: [email protected] Subject: Re: [Trans] Non-redaction options On Wed, Mar 8, 2017 at 1:34 AM, Peter Bowen <[email protected] <mailto:[email protected]> > wrote: 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. Regardless of factual accuracy/inaccuracy, and despite the dangerous foray into policy here, I think many of the points, as posed, attempt to suggest a contradiction to / ignoring the Immutable Laws of Computer Security. That is, I would argue that 4, 5, 6, 7, 8, 9 are not relevant to the discussion when considering such basic statements Law #6 "Your computer is only as secure as the administrator is trustworthy" or Law #2 "If a bad guy can alter the operating system of your computer, it's not your computer anymore" Nor, for the most part, do I think they're relevant for/and or necessary for a discussion of redaction, beyond statement #1.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
