> -----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. 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. > > 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). > I think there are at least three options > > 1. As you say, users (or admins might be a little safer) configure > domains to be opted-out. > > 2. Private certs are issued by private CAs (I mean the CA certificate, > of course) which are marked "do not log". This option will not be > available for default CAs. > > 3. Private certs are issued under a name-constrained intermediate > which is logged. > > BTW, Rick, this has come up before, I thought on public lists, but > perhaps I am misremembering. I prefer 3, BTW, because it is not a > mechanism which users can be conned into invoking. _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
