On 19 July 2014 01:12, Mehner, Carl <[email protected]> wrote: > Hi Rick, > > I think that it might be best to have a glut of roots for now. This way, you > (as a CA) can monitor the logs to see if anyone has issued a cert that could > be valid for SSL off of any “inappropriate” root and I (as a host operator) > can monitor to see if someone has issued anything off that (or any) root for > our domain. At least until all the major browsers/platforms require CT for > all SSL connections. Otherwise, someone could issue a cert for our domain > that could be used for SSL transport of data between a server and a non-CT > validating client (which I expect to remain in plentiful supply for several > years).
Indeed, one of the nice things about CT (I think) is that it confers some level of herd immunity, even for non-validating clients. > On the other hand, even though it's predominantly for TLS, that is not the > only thing that CT is useful for. I would not mind a window into who is > issuing s/mime certs, code signing certs, and any number of other cert types > for our domain in order to put a stop to issuance against our standards and > policy. So perhaps casting the widest net of roots that, as Ben says, does > not “suddenly become spammy” would be best. Although, as Jeremy pointed out, > this could increase log size by quite a bit. Log size isn't inherently a problem, unless it becomes truly massive. Each doubling adds a single hash to inclusion proofs. STH consistency proof size is related to the growth in the log, and so doubling in size would tend to also add a single hash to those (on average). The main problem is for monitors, but even so, the size of logs we're currently looking at are easily managed by monitors. > > -carl > > ________________________________ > From: Trans [[email protected]] on behalf of Rick Andrews > [[email protected]] > Sent: Friday, July 18, 2014 1:11 PM > To: [email protected] > Subject: EXTERNAL: [Trans] List of Roots Accepted by Log Servers > > I finally got around to reading the list of roots accepted by the pilot and > aviator log servers (using the get-roots command). I see a number of our > roots that seem inappropriate to me, meaning that we have never issued SSL > certs (EV or non-EV) from those roots, and never intend to. It seems to me > that Google cast a wide net to add all relevant roots to kickstart the log > servers (perhaps bootstrapped from Mozilla’s root list?), but at some point > (before CT is “live”) I would like to see the list trimmed. > > My thinking is that if I somehow issue an SSL cert from a root that I did not > intend to use for SSL, I would prefer to catch that as quickly as possible; > ideally, when the log server refuses to give me an SCT. Is Google willing to > remove roots from pilot and aviator? > > I think we need a somewhat formal way for CAs to provide log server operators > their list of roots, and update that over time. For example, we have a few > new roots that we expect to be using in the next few months, and I need to > make sure they’re added to log servers before I start using them. If log > server operators provide an service level agreement (SLA) for such changes, > that would be great. > > Comments? > > -Rick > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
