Some comments: Paragraph1:
It should be noted that in the DigiNotar case the breach was not discovered for several weeks and not reported after discovery and due to the nature of the breach revocation was not possible. In the Comodo case the mis-issue was discovered within minutes and the certificates revoked. This is a very important point to raise since the next paragraph is conculsory, "The main problem, however, is that any CA can issue a certificate for any domain name." 1) one could make a very good argument that the main problem is that the browsers don't implement revocation reliably. 2) CAA has already been created to address this problem. If that was the 'main' problem it would be solved. Unfortunately it isn't. The 'EFF 600' number is unfortunately a XXX and I use the term advisedly. They have accepted that they are mis-measuring the number of CAs but they continue to insist on a number they admit they can't support. Please do not present Fox News figures in what is meant to be a serious report. I regret that I have to use the word 'XXX' here but when a falsehood is presented and then insisted on after being proven untrue, what other description is there? The EFF study conflates all intermediate certs whose subject name is different to the issuer with cross certificates to a CA. In practice 300+ of the certificates they identify as 'CA certificates' are issued by a single CA and none are CA certificates. We have had exhaustive discussion of the issue and no correction from the EFF unfortunately. The fact that they can't measure what they would like to measure from the certificate graph does not mean that they can measure it wrongly in a fashion that inflates it by a factor of ten and present that figure and assert that it is up to others to supply a better figure. The principal problem with Sovereign keys is that it simplifies the trust management problem by assuming that no network manager will ever make a mistake. If they make one mistake they will lose control of their domain in perpetuity. Nobody is ever going to take responsibility for deploying such a scheme on ebay.com or the like. I think that you miss the point of CT which is that Transparency is the principle that the CA can be audited by any party without access to hidden knowledge. That is a groundbreaking concept in trust infrastructure. What the client checks is proof that the certificate was entered into the log, not the log itself. That is an important but subtle point. On DANE among the risks that have to be considered is that there is only one provider of PKI services in DANE. Thus if that provider decides to deny access to a party they have no recourse. Hence the Russian interest in GOST etc. Whether or not you accept that scenario, the folk who do accept it are willing to fracture the Internet over it. On Tue, Oct 22, 2013 at 2:48 AM, Hannes Tschofenig < [email protected]> wrote: > Hi all, > > one item that predates the pervasive surveillance debate is the discussion > about improving the public key infrastructure (but still has relevance in > this discussion, see > https://www.net-security.org/**secworld.php?id=15579<https://www.net-security.org/secworld.php?id=15579> > ). > > Following the workshop at NIST earlier this year the IAB and ISOC have > been reaching out to different players (and are still doing that) to > continue the conversation. > > We have put together a first document that describes the different > proposals (and as you can see the level of detail available for them and > their maturity varies greately). Here is the writeup: > http://tools.ietf.org/html/**draft-tschofenig-iab-webpki-**evolution-00<http://tools.ietf.org/html/draft-tschofenig-iab-webpki-evolution-00> > > The analysis is still a bit weak and requires more work but the proposals > are hopefully captured accurately. Let us know whether there is something > missing. > > We hope that this could help to create move momentum behind certain > proposals to get them accepted by the community and widely deployed. > > Ciao > Hannes > ______________________________**_________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/**listinfo/perpass<https://www.ietf.org/mailman/listinfo/perpass> > -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
