On 29 October 2012 10:10, Ben Laurie <[email protected]> wrote: >> I believe in your plan each browser will be a CT client. Aside from the fact >> that the white list is an attractive target for hackers, I don't see how the >> average user is going to know how to configure this white list. I'm reminded >> of Adam's arguments against Convergence >> (http://www.imperialviolet.org/2011/09/07/convergence.html). > > This is why I think the best solution is to issue private certs > through a name constrained intermediate which is logged.
Or, as I mentioned above, through a private CA which is marked as "do not log". I would not expect users to configure this, rather the sysadmins of their corp machines. BTW, a domain whitelist seems like a terrible idea: then attackers could freely forge certificates in that whitelist, even if it was configured correctly. > >>> I think there are at least three options >>> >>> 1. As you say, users (or admins might be a little safer) configure >>> domains to be opted-out. >>> >>> 2. Private certs are issued by private CAs (I mean the CA certificate, >>> of course) which are marked "do not log". This option will not be >>> available for default CAs. >>> >>> 3. Private certs are issued under a name-constrained intermediate >>> which is logged. >>> >>> BTW, Rick, this has come up before, I thought on public lists, but >>> perhaps I am misremembering. I prefer 3, BTW, because it is not a >>> mechanism which users can be conned into invoking. _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
