Matt, Jeremy, Matt asked "Why would a root CA operator have added their root cert to a browser trust store if they weren't intending to issue trusted certificates?" Because we also issue client auth certificates, S/MIME certificates, code signing certificates, timestamping certificates, etc. If Google had filtered out just those roots without the "This certificate can identify websites" bit set, that would have eliminated a lot of the irrelevant roots.
Matt also asked "I'm planning on publishing operator contact details in or near the log itself -- send an e-mail to the address in there and you'll get a response within the MMD. Seem reasonable?" Yes, definitely. Jeremy, if we don't want to add our certs to a specific log, you're right that we can avoid using that log. But CT allows anyone (the CA, the owner of the cert, an interested party) to log any cert in any log server. By keeping all these roots in a log server, we're allowing any type of cert to be added to the log. We may get there someday, but that's not the intent for this first use of CT. We're focused on EV SSL certs. Let's not force monitors and auditors to wade through irrelevant certs. -Rick -----Original Message----- From: Trans [mailto:[email protected]] On Behalf Of Jeremy Rowley Sent: Friday, July 18, 2014 1:32 PM To: 'Matt Palmer'; '[email protected]' Subject: Re: [Trans] List of Roots Accepted by Log Servers Although I can see the appeal for a process with Google operated logs, I don't think there is much value in creating a system to add/remove roots from a log at a CA's request. If CAs don't want to include their cert on a specific log, the CA shouldn't ever hit the log with a pre-cert. For our log, we are simply going to enable roots as we see appropriate, most liked based on the certs trusted in both Mozilla and MS (but we are still debating this issue). Jeremy -----Original Message----- From: Trans [mailto:[email protected]] On Behalf Of Matt Palmer Sent: Friday, July 18, 2014 2:17 PM To: [email protected] Subject: Re: [Trans] List of Roots Accepted by Log Servers I can't speak for Google, but I'll speak as an intending log operator. On Fri, Jul 18, 2014 at 11:11:24AM -0700, Rick Andrews wrote: > 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'd be willing to remove root certs from the logs I run if requested, based on a suitably authenticated communication from the CA operator. I wonder, though, why a root CA certificate would end up in a log in the first place if it wasn't intended to produce publically-trusted certificates. Like you, I've been led to believe that Google scraped one or more browser trust stores for the list of certs on pilot/aviator. Why would a root CA operator have added their root cert to a browser trust store if they weren't intending to issue trusted certificates? If the root was added for a non-web-server trust bit, I see that as being within the purview of CT, because I'd like to be able to audit for the issuance of code signing and e-mail certificates as well. > 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. I'm planning on publishing operator contact details in or near the log itself -- send an e-mail to the address in there and you'll get a response within the MMD. Seem reasonable? - Matt -- You know you have a distributed system when the crash of a computer you’ve never heard of stops you from getting any work done. -- Leslie Lamport "Security Engineering: A Guide to Building Dependable Distributed Systems" _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
