Till Maas wrote: > All CAs support verification via insecure protocols AFAIK because > usually the certificate is needed to secure the protocol. If you mean CAs who issue server certificates for use in HTTPS, and who serve the general public, then that's probably true, but then we're not talking about OpenPGP keys anymore. As an example of another kind of certification authority that doesn't rely on insecure protocols, I have a government-issued ID card that contains a chip with a certificate that I can use to prove my identity to some government agencies' websites. It can for example be used as a client certificate in HTTPS. To get this I had to be physically present and prove my identity with another valid ID document. (Unfortunately it's lacking in standardization and requires some unfree software components.) > What other option would they have? As regards server certificates for HTTPS, all the other options I can think of would use trust chains anchored in DNSsec in one way or another. Apparently Let's Encrypt performs DNSsec validation when using the DNS-01 challenge type. If the zone is signed, then an attacker can't get a fraudulent certificate by way of DNS poisoning: https://community.letsencrypt.org/t/dnssec-with-own-soa-and-acme2/80239 So then attackers will try the other challenge types. To prevent that, a new RFC specifies the validationmethods parameter for CAA records. Let's Encrypt has at least been testing support for this: https://www.rfc-editor.org/rfc/rfc8657 https://community.letsencrypt.org/t/acme-caa-validationmethods-support/63125 Björn Persson
Attachment:
pgpRkiAEB5BiL.pgp
Description: OpenPGP digital signatur
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
