On 07/07/15 15:57, Russ Housley wrote: > I want to make people on this list aware of this draft that was posted > yesterday. > > Stephen Farrell suggested that this list might be a good place to discuss it.
https://tools.ietf.org/html/draft-housley-web-pki-problems-00 Some comments: 3.1: See: https://wiki.mozilla.org/CA:RevocationPlan 3.2/3.3: See HPKP, CAA and CT. 3.4: Bug Apple :-) 3.5: See Let's Encrypt, DigiCert Express Install, SSLMate etc. etc. 3.6: The entire point of Trustwave is that browsers could _not_ ordinarily detect the MITM. But anyway: it has been suggested that MITM certs should be required to have a special marking which browsers can detect, but this solution, when investigated, has a number of problems. Ideas welcome. 3.7: 1024-bit: See https://bugzilla.mozilla.org/show_bug.cgi?id=1156844 for roots, CAB Forum policy for intermediates and EE certs. SHA1: See Microsoft and Google policy and CAB Forum policy. MD5 is already dead. RC4 is being worked on: see https://bugzilla.mozilla.org/show_bug.cgi?id=1138101 . 4.1: With regard to the Mozilla root program, I refute the first suggestion here. See http://www.mozilla.org/projects/security/certs/policy/ and many other places. 4.2: The actions we took in the CNNIC case were specifically designed to be generalisable to a CA otherwise considered "too big to fail". 4.3: Given the existence of the above-mentioned services and APIs, this seems like a Simple Matter of Programming to me. :-) 5.1.1: Browsers don't use such extensions because CRLs suck. 5.1.2: Indeed. Please put polite pressure on the Apache project and/or Linux distributions to allow OCSP stapling to be enabled by default. 5.2.1: See https://www.imperialviolet.org/2015/01/17/notdane.html . 5.2.2: CAA is fine. 6.1: The CAB Forum is a lot more open, inclusive and transparent than it once was, in part due to Mozilla pressure. For example, voting is no longer secret, and nor are the mailing lists. Third parties can now take part (although not vote) in working groups. Organizations can become associate members. And while this is not full openness and transparency, mozilla.dev.security.policy is always open to hear input from the Internet community on what Mozilla should be doing or advocating. The chances of browser makers handing over the right of decisions about who to trust to a 3rd party body are vanishingly small. Gerv _______________________________________________ wpkops mailing list wpkops@ietf.org https://www.ietf.org/mailman/listinfo/wpkops
