To support what Jeremy and Rick said, I'll point out that it's entirely possible to spin up multiple logs for different uses of X.509 certificates. I understand that different X.509 certificates are used by different client software, each kind of client software could use a different set of logs (and these sets would be monitored differently depending on the application). Nothing prevents the logs to be based on the same software and infrastructure.
Specifically: * There's already a reference implementation for a CT log server as open-source code (and we're working on a more robust version). * Given Ben's interest in binary transparency and general transparency, I believe he won't outright reject running extra logs for other cert types (on Google's infrastructure). * Code for general transparency service would allow running a transparency log for arbitrary binary blobs. Ben may be able to share some details on such an effort. On Mon, Jul 21, 2014 at 9:44 PM, Jeremy Rowley <[email protected]> wrote: > Because of the differences in root program requirements, operational > requirements, and verification needs, from my experience, most client and > code signing systems already fork from the SSL cert systems. Client certs > are especially different in their issuance process. For most CAs, I imagine > it’s more work to add CT support for the three base certificate types than > simply enable it for SSL. > > > > Jeremy > > > > *From:* Trans [mailto:[email protected]] *On Behalf Of *Kyle Hamilton > *Sent:* Monday, July 21, 2014 2:00 PM > *To:* Rick Andrews; [email protected]; [email protected]; [email protected] > > *Subject:* Re: [Trans] List of Roots Accepted by Log Servers > > > > Until there's adequate support in SCT for all types of certs, there is > > no drive to add SCT to other protocols and clients. Therefore, there > > will never be a requirement for it. Ultimately, the unwillingness to > > support it now shall only guarantee that it will never be required. > > > > But unless and until Google wants to step up and actively promote it, I > > guess Google gets a lack of it. Therefore, according to your argument, > > Google now has de facto administrative control over Internet security > > infrastructure administration and buildout. > > > > Value might be perceived because of the lack of cost to modify ****all** > > issuance systems to be on the same code base, as opposed to forking them > > all. However, as a reminder, forks increase maintenance cost and > > decrease capacity, capability, and interoperability across multiple > > systems -- particularly on previously-enabled systems that haven't yet > > been fully brought into production. > > > > -Kyle H > > On 7/21/2014 8:08 AM, Rick Andrews wrote: > > True. The point I'm trying to make is that we're a long way from requiring > SCTs for all types of certs, SSL and non-SSL. Until all applications require > SCTs for all types of certs, I see no reason to add the complexity of logging > all certs. At this point in time, Google wants SCTs for EV SSL certs, and > that's what I'm shooting for. Chrome knows which roots are enabled for EV, > and so those are the only roots that log servers MUST accept. > > > > Other CAs might want to log all their certs. Relying parties might want to > push every cert they see into log servers. But I see value in limiting which > of my roots are accepted by log servers, and I'd like the ability to control > that. > > > > -Rick > > > > -----Original Message----- > > From: Gervase Markham [mailto:[email protected] <[email protected]>] > > Sent: Monday, July 21, 2014 2:33 AM > > To: Rick Andrews; Mehner, Carl; [email protected] > > Subject: Re: [Trans] List of Roots Accepted by Log Servers > > > > On 19/07/14 02:02, Rick Andrews wrote: > > 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. > > > > Not implying anything about your security, Rick, but one of the benefits of > CT is that people who don't realise that they've lost control of their > private keys can find out! :-) > > > > Gerv > > _______________________________________________ > > 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
