2012/10/24 Phillip Hallam-Baker <[email protected]> > > 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? >
(Keynectis) I'd like to. Not just as a CA, but also as a log holder. I can only fly over it for now, though. Frustration. And we also have deployment constraints, certification constraints (CC EAL4+ and local ones), and a lot of customers to satisfy. > 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. Agreed. > 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. > That's when IETF considers costs at all... -- Erwann.
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
