I had a go at incorporating this, but in the process, I realised it is probably not quite ready yet. I could have a go at editing it myself, but I will definitely not have time before Monday's deadline.
I suspect more revision is required before it can be incorporated. I have comments, but they will probably have to wait a while. I do now have a version that is in xml2rfc format, though - more or less. On 6 March 2015 at 16:12, Stephen Kent <[email protected]> wrote: > Ben, > > Happy to oblige. The revised text is attached. > > As for your comments: > > I still don't really understand this point: the log has no power to check > syntax that is not also available to a client, > > In principle that's true, but in practice we have seen many instances > where client software > fails to perform checks established by standards. Thus logs represent an > opportunity to > do a better job (since they are new code) and perhaps help save clients > from bad code. > > so I don't see how the log checking/not checking syntax is interesting - a > malicious CA presumably cannot know what all clients will do? Because of > this, I also still do not see the real value of logs checking syntax - I am > not fundamentally against it, but it doesn't seem to me to add much. > > A malicious CA can determine (via testing) which clients, by browser type > and version, > fail to perform certain syntactic checks. If the CA is creating a bogus > cert with a > particular set of clients in mind, this may suffice. > > It is not clear to me that gossip has to be mandatory. So long as some > fraction of participants gossip, then clients are protected from > non-targeted attacks. Obviously this does not remove the need to specify > gossip, which is clearly required for CT to fully realise its potential. > > > Remember that IETF standards almost always specify mandatory to implement > (MTI) features, not > mandatory to use (MTU) features. I believe your comment above supports my > argument that gossip needs > to be MTI, but not MTU. > > Steve > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
