On 31 October 2012 23:57, Rick Andrews <rick_andr...@symantec.com> wrote: >> -----Original Message----- >> From: Ben Laurie [mailto:b...@google.com] >> Sent: Monday, October 29, 2012 3:10 AM >> To: Rick Andrews >> Cc: Rob Stradling; therightkey@ietf.org; Paul Hoffman >> Subject: Re: [therightkey] Other solutions to the problem >> >> On 26 October 2012 22:31, Rick Andrews <rick_andr...@symantec.com> >> wrote: >> >> -----Original Message----- >> >> From: Ben Laurie [mailto:b...@google.com] >> >> Sent: Friday, October 26, 2012 1:51 AM >> >> To: Rob Stradling >> >> Cc: Rick Andrews; therightkey@ietf.org; Paul Hoffman >> >> Subject: Re: [therightkey] Other solutions to the problem >> >> >> >> On 26 October 2012 09:24, Rob Stradling <rob.stradl...@comodo.com> >> >> wrote: >> >> > On 26/10/12 00:58, Rick Andrews wrote: >> >> > <snip> >> >> > >> >> >> AFAICT, for CT to really work it will require participation from >> >> every CA >> >> >> whose roots are in browsers. I think you're underestimating how >> hard >> >> it will >> >> >> be to achieve that. >> >> > >> >> > >> >> > Rick, >> >> > >> >> > Ultimately, assuming the RFC5878 TLS extension gains widespread >> >> support in >> >> > server and client software, CT won't _require_ participation from >> any >> >> CA. >> >> > Each certificate holder will be able to configure their server to >> >> send their >> >> > certificate's CT proof to each client. >> > >> > I see, so the certificate holder can submit their newly-minted >> certificate to a log server to get a CT proof. Instead of requiring the >> participation of every CA, you now require the participation of every >> certificate holder. >> >> No, it is an option. > > I understand that. I was trying to point out that for CT to be effective, you > either need all CAs to participate, or for every CA that doesn't participate, > their customers who want protection have to participate directly. I feel > that's a pretty high bar to surmount.
Its only software. The process of participating in CT for a server operator is: 1. Run command line tool once, giving it your certificate as input and an SCT file as output. 2. Add one line of configuration to your server config. Not exactly rocket science. If people _really_ find it hard, we could build it into the servers so there was no manual step at all. >> >You might say that not every certificate holder will need or want CT, >> but I would guess that the number that would want the protection would >> be far greater than the number of CAs. >> >> Given that the plan is browsers will refuse non-CTed certs, I imagine >> most holder of certificates used by the public will want CT. > > Do you have agreements with the major browser vendors to do this? It's > possible that not all of them will be on board. In practice, only one major browser needs to participate to give herd immunity. Obviously it would be nice if they all did, but it is not an urgent problem. >> >> > But with participation from the CAs, it should be possible to >> realize >> >> the CT >> >> > dream far sooner. And (even in a future world where RFC5878 is >> >> supported >> >> > everywhere) if the CA takes care of CT proof distribution, then >> that >> >> makes >> >> > life easier for the certificate holder. >> >> > >> >> > >> >> >> Further, no one has yet brought up the privacy issue. CAs sell a >> lot >> >> of >> >> >> certificates to companies for their internal use. Some of them >> may >> >> object to >> >> >> publishing all their internal domain names. >> >> > >> >> > >> >> > This has been a concern for Comodo too, so I spoke to AGL about it >> a >> >> few >> >> > weeks ago. AIUI, the plan is that CT clients will have a user- >> >> configurable >> >> > whitelist (empty by default) of domain names for which CT proofs >> will >> >> not be >> >> > required. Participating CAs should allow customers to opt-out >> from >> >> having >> >> > their certs automatically logged with CT. >> > >> > I believe in your plan each browser will be a CT client. Aside from >> the fact that the white list is an attractive target for hackers, I >> don't see how the average user is going to know how to configure this >> white list. I'm reminded of Adam's arguments against Convergence >> (http://www.imperialviolet.org/2011/09/07/convergence.html). >> >> This is why I think the best solution is to issue private certs >> through a name constrained intermediate which is logged. > > I agree. I'm glad we agree on something! _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
