On 1 November 2012 11:22, Phillip Hallam-Baker <hal...@gmail.com> wrote: > Zero net admin steps is probably a necessary criteria. What you think not > hard might as well be rocket science to most.
Maybe, but the rocket science involved in getting a cert in the first place is far worse. > > > On Thu, Nov 1, 2012 at 5:10 AM, Ben Laurie <b...@google.com> wrote: >> >> 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 > > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
