On 24 October 2012 18:09, Rick Andrews <[email protected]> wrote: >> -----Original Message----- >> From: [email protected] [mailto:therightkey- >> [email protected]] On Behalf Of Ben Laurie >> Sent: Wednesday, October 24, 2012 4:29 AM >> To: Phillip Hallam-Baker >> Cc: [email protected]; Paul Hoffman >> Subject: Re: [therightkey] Impact on issue processes >> >> On 24 October 2012 12:16, Phillip Hallam-Baker <[email protected]> >> wrote: >> > >> > >> > On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie <[email protected]> wrote: >> >> >> >> On 24 October 2012 03:02, Paul Hoffman <[email protected]> >> wrote: >> >> > [[ I changed the subject line because this should be discussed on >> the >> >> > list *before* the meeting. It is not a separate agenda item, yet. >> ]] >> >> > >> >> > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker >> <[email protected]> >> >> > wrote: >> >> > >> >> >> One of the key issues as far as acceptability to CAs is concerned >> is >> >> >> impact on issue processes. In particular it has to be possible to >> deploy any >> >> >> experimental infrastructure without touching the certificate >> issue code. >> >> >> >> What? Why? Are you saying CAs can't test modified issuance code? >> > >> > >> > Proposing to change that code is like you proposing to change the >> Google >> > search algorithm to make CT work. Just not going to happen. >> >> That is not what I've heard from others. >> >> > That is an audited system. It has a very complex and elaborate QA. It >> > extends across the resellers that take the orders and the CA issue >> center. >> > >> > If CT had been proposed twenty years ago it might be viable to put >> the proof >> > in the cert. Any change now has to work around the existing >> infrastructure. >> >> If your infrastructure can't cope, fine, put it in OCSP, or in a TLS >> extension. I don't believe all CAs are unable to modify their >> software. > > It's not a question of being unable to modify our software. As a > representative of Symantec, I will tell you that modifying our issuance code > will be a very tough sell, for a number of reasons: > - There's no obvious direct return on investment
So protecting users is not a motivation, then? > - For some types of certificates, speed of issuance is very important. > Getting a CT proof will slow this down and cause it to fail if the log server > isn't up 100% of the time. I'd like to hear more about these certificates - why is speed so important? We redesigned the CT protocol precisely so that getting a proof (which actually now is just a signed timestamp) is quick, and so that we have a service that's easy to keep up. We also intend to run several instances of the log so that in the event of one being down, others can be used (for time critical issuance, you would obviously use them in parallel, and perhaps just take the first one that answers - there's no obligation to use a log's response so dropping the others on the floor would be fine). > - It makes sense to avoid relying on external parties to fulfill part of our > cert issuance process. At this point, it's unclear who would even host a log > service, what SLA they would provide, how much attention they would pay to > performance and availability, disaster recovery, etc. Google will run a log. We have not yet established an SLA, but we will have one, and certainly our aim is to make it as available as is possible. Disaster recovery is also critical, since any error in the log is indistinguishable from malfeasance, at least technically, so we are designing the system with a great deal of robustness and multiple layers of backup. We are not messing around here - the full capabilities of Google's infrastructure are being applied to this problem. > - Symantec would not be interested in hosting a log service because of > unclear ROI. I find it interesting that trust is not considered an ROI. > > -Rick _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
