> -----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. > >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. > >> > 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. _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
