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. >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. >> > 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 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
