Re: [therightkey] Other solutions to the problem

[Ben Laurie <[e-mail]>]

On 1 November 2012 11:22, Phillip Hallam-Baker <[e-mail]> 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 <[e-mail]> wrote:
>>
>> On 31 October 2012 23:57, Rick Andrews <[e-mail]> wrote:
>> >> -----Original Message-----
>> >> From: Ben Laurie [mailto:[e-mail]]
>> >> Sent: Monday, October 29, 2012 3:10 AM
>> >> To: Rick Andrews
>> >> Cc: Rob Stradling; [e-mail]; Paul Hoffman
>> >> Subject: Re: [therightkey] Other solutions to the problem
>> >>
>> >> On 26 October 2012 22:31, Rick Andrews <[e-mail]>
>> >> wrote:
>> >> >> -----Original Message-----
>> >> >> From: Ben Laurie [mailto:[e-mail]]
>> >> >> Sent: Friday, October 26, 2012 1:51 AM
>> >> >> To: Rob Stradling
>> >> >> Cc: Rick Andrews; [e-mail]; Paul Hoffman
>> >> >> Subject: Re: [therightkey] Other solutions to the problem
>> >> >>
>> >> >> On 26 October 2012 09:24, Rob Stradling <[e-mail]>
>> >> >> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/therightkey
>
>
>
>
> --
> Website: http://hallambaker.com/
>