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] > 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
