Carl, Unless I've lost control over my private keys, I don't need to monitor CT logs to see if anyone else has issued an SSL cert from one of my inappropriate roots. I can just look in my database.
Within the CA/Browser Forum, there's been a lot of discussion about how to define an SSL cert, but unfortunately every browser (and every non-browser app that acts as a TLS client) seems to have a different definition, and it doesn't seem likely that we'll ever reach consensus. My point is that for the moment, CT is a browser initiative, and one browser is building support for it. You're not alone in thinking that CT is useful beyond TLS; there's been a lot of discussion about where else it might be used. However, I think it's prudent to work out the kinks with a limited set of certs first, which is why I think Google decided to limit it to Chrome-based EV SSL for now. -Rick -----Original Message----- From: Mehner, Carl [mailto:[email protected]] Sent: Friday, July 18, 2014 5:12 PM To: Rick Andrews; [email protected] Subject: RE: List of Roots Accepted by Log Servers 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). 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. -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
