I think there are two questions here: 1) Is there industry interest in support for some form of CA transparency? 2) Is the Ben, Adam, Chris et. al. proposal the approach to take?
If the answer to the first one is 'no' then there is no point in a BOF because it would be like having a WG to decide what colour to paint the White House, however interested the participants might be in the proceedings they would have no practical effect. The second question is not nearly so important as the first. There has to be some demonstration that the subject area is an IETF problem rather than an IRTF one but discussions on which approach or which approaches to take would seem to me to be exactly the sort of thing that should be considered at the BOF. So the point raised by Denis seems to be an argument for a BOF rather than against one. He is interested in the subject area but is proposing a different approach. Given that the plan is to shut PKIX down in the near future, I don't see how it can address any of the OCSP responder approaches to transparency. In addition to the proposal made by Denis, there is the proposal I made with Rob and other folk have also raised from time to time. It would seem to me that this set of approaches is something that would be better served by addressing them in a new WG rather than trying to squeak them in before PKIX sets up shop. PKIX never had a monopoly on X.509v3 extensions so closing PKIX should not mean the end of development there. Comodo is interested in CA transparency, whether we could support a proposal that requires us to share our customer lists with competitors is a different matter. There might well be a deployment deadlock situation inherent in the protocol, I can well imagine a situation in which all the major CAs are willing to deploy after someone else agrees to go first. Another proposal that probably deserves some consideration is a germ of an idea that Rick Andrews proposed on the CABForum public list (so I will feel free to raise it here). Rick proposed that national CAs issue a statement that they only issue certificates for one country and so all others should be ignored. Now there are many problems with that particular proposal, I don't think that national constraints give a lot of leverage. But it is possible that some form of 'CA root profile' or 'Certificate signing certificate profile' that goes beyond client-enforceable constraints might have value. This gets to a problem I am having on my home network right now. It is very difficult to work out what part of the system is causing the periodic network storms because none of the components on the network provide a description of what 'normal' operation actually is. Every device on my network has the ability to perform a SYN flood attack at periodic intervals. That seems like a very bad idea to me. I think that Transparency is the next big idea in Computer Security. Addressing core PKI first seems like the best approach as it is the point where we get the most leverage. Where my approach differs from Ben's is that he is proposing a scheme (call it Strong Transparency) that allows clients to tell when they are being spoofed and I am more interested in the problem of how to make it possible for any party with the requisite resources to tell when someone might be being spoofed (Weak Transparency). The difference between strong and weak transparency is the resources that we can bring to the task and the outcomes we can accept. Strong transparency is limited to the information on hand at the client processed according to set rules, Weak transparency can engage information from any source whatsoever and apply proprietary analysis. Since the only actions a client can take have a significant impact on the user (warnings, deny access to site), Strong transparency requires a very high degree of confidence in the result. False positives are much less important in Weak transparency as the action taken is most likely to be 'tell a human analyst who makes personal contact with the CA in question'. Another possibility is that we might bridge the gap between the two by using some scheme like Omnibroker that moves the task of establishing network connections out of the client completely. That provides the immediate protection that ST offers while retaining the flexibility advantage of WT. My view is that Weak Transparency is the low hanging fruit here and Strong Transparency is a hard problem. I am willing to spend time on Strong Transparency but only if that does not preclude the Weak Transparency approach. I think we can definitely get some form of WT deployed that justifies the effort involved. Getting WT deployment will help rather than hinder deployment of ST as it will provide the necessary testbed to tell what works and how well it works. Given the reluctance of the browser providers to deploy revocation checking properly, I have a hard time believing that browsers are going to be hard failing on CT irregularities. So I rather suspect that what we will end up with is a WT system plus a distributed catenate certificate notary infrastructure that we don't use for this particular task but is useful for many other tasks. _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
