On Wed, Oct 24, 2012 at 7:28 AM, Ben Laurie <[email protected]> wrote: > On 24 October 2012 12:16, Phillip Hallam-Baker <[email protected]> wrote: > > > > > > On Wed, Oct 24, 2012 at 6:18 AM, Ben Laurie <[email protected]> wrote: > >> > >> On 24 October 2012 03:02, Paul Hoffman <[email protected]> wrote: > >> > [[ I changed the subject line because this should be discussed on the > >> > list *before* the meeting. It is not a separate agenda item, yet. ]] > >> > > >> > On Oct 23, 2012, at 6:41 PM, Phillip Hallam-Baker <[email protected]> > >> > wrote: > >> > > >> >> One of the key issues as far as acceptability to CAs is concerned is > >> >> impact on issue processes. In particular it has to be possible to > deploy any > >> >> experimental infrastructure without touching the certificate issue > code. > >> > >> What? Why? Are you saying CAs can't test modified issuance code? > > > > > > Proposing to change that code is like you proposing to change the Google > > search algorithm to make CT work. Just not going to happen. > > That is not what I've heard from others.
Hey, I am not trying to be obstructionist here, just trying to avoid the pitfalls of previous efforts. CT itself is going to be the easy part. The devil is all going to be in the deployment. Other than Comodo and Symantec, how many CAs have a programmer on staff? > That is an audited system. It has a very complex and elaborate QA. It > > extends across the resellers that take the orders and the CA issue > center. > > > > If CT had been proposed twenty years ago it might be viable to put the > proof > > in the cert. Any change now has to work around the existing > infrastructure. > > If your infrastructure can't cope, fine, put it in OCSP, or in a TLS > extension. I don't believe all CAs are unable to modify their > software. > I think it is going to be very hard to get CAs to commit unless there is a general consensus that the other CAs will also commit. Also there is a technical cost and a political cost of making a change. IETF has a tendency to focus only on the technical cost which depends on the extent of the changes and so prefers incremental improvements that are stand alone. But the political cost tends to be more a matter of deciding to do something different and the advantage of doing it. If the political cost is the blocking factor then you will do better with one big request than a series of small ones. -- Website: http://hallambaker.com/
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
