And dnssec-validator.cx for a Firefox/chrome plugin that you can see in action against fedoraproject.org that already deploys this Sent from my iPhone > On Jul 3, 2015, at 10:43, Petr Spacek <pspacek@xxxxxxxxxx> wrote: > >> On 2.7.2015 17:56, Michael Catanzaro wrote: >>> On Thu, 2015-07-02 at 16:38 +0200, Reindl Harald wrote: >>> this type of attitude? >>> >>> everybody who reads IT news over the past years about CA's issued >>> certificates even for Google knows that a CA signed certificate does >>> not >>> prove anything - the real problem is wehn this happens for Google >>> somebody takes notice and the press writes about it >>> >>> if the same happens for your domain nobody will recognize it >> >> The situation is going to be getting a lot better in the near future, >> though. We're getting to the point where we can start enforcing >> Google's certificate transparency: if your certificate isn't on the >> public audit list, we can simply reject it. That allows individual web >> sites to get an immediate heads-up whenever any fraudulent certificate >> is issued for their site. (And researchers will be looking after the >> most important sites, of course.) That's not going to fix TLS in >> itself, because most sites probably don't care, but if the site does >> care, it will be impossible to issue a browser-trusted certificate for >> the site without that site knowing. (At least, that's my understanding >> of the technology; I haven't researched it thoroughly.) >> >> You're right that OCSP is worthless. GNOME applications don't currently >> perform any certificate revocation; I'm not willing to implement OCSP >> unless Firefox is willing to enforce it, and they aren't. We should >> implement OneCRL, which solves the revocation problem for intermediate >> certificates, but there doesn't seem to be any reasonable solution for >> individual sites yet. OCSP must-staple seems promising. >> >> Of course, we can't have any of these nice features in GNOME unless >> somebody wants to pay for their implementation. (If so, get in touch >> please.) > > For the record, and all this can be solved by DNSSEC + DANE. See RFC 6698. > > -- > Petr Spacek @ Red Hat > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
