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]] Sent: Monday, July 21, 2014 2:33 AM To: Rick Andrews; Mehner, Carl; [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/trans
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
