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