> That still requires trust stores to be distributed to the clients

There's no such thing as a "trust store" in practice. To be "trusted" you just need to demonstrate you have control over a DNS TXT record, and we don't need a special "store" or intermediary for that.

Certificate authorities are an artifact of a bygone time and an entirely different model of internet infrastructure.

▲

woodruffw 5 hours ago | parent [-]

The trust store refers to the collection of parties that ultimately verify the signed claim of your control over a domain, which might have taken the form of a DNS TXT challenge (or any other number of challenges). You still need it, because there would otherwise be a basic circularity when determining whether to trust a connection.

(Moving the PKI into DNS does not remove it, it just moves it around.)

▲

josephg 4 hours ago | parent [-]

> (Moving the PKI into DNS does not remove it, it just moves it around.)

Better in DNS though. You could have certs mirror the structure of DNS. Install a single root signing key for the top level DNS registry on client devices. Then you can query that to find out the signing keys for .com, .net, .au, etc. And continue from there.

One big problem with the CA system is that any CA - even the most incompetent - can sign certificates for any domain. If trust was moved to DNS, there would only be a single organisation that could forge certificates for any given domain. Using 7 as a private key? What a joke. The CAs aren't worthy of trust.

We already have to trust the domain name registrars anyway, since CAs query them to figure out if you own a domain before signing a certificate. In total, removing CAs would not only simplify the system. But it would allow scoped signatures. And we'd end up needing to trust far fewer actors to have a secure internet.

▲

itintheory 2 hours ago | parent | next [-]

> One big problem with the CA system is that any CA - even the most incompetent - can sign certificates for any domain.

Is this not what CAA records were intended to solve? It seems like in practice they're only used by CAs to decide if they can sign a cert for a given domain, but it seems like a client could use it to determine if a server cert was from the correct CA.

	▲	parasyte 13 minutes ago \| parent \| next [-]
		CAA records were never intended to be used by clients (Relying Parties), the RFC specifically prohibits them from using the CAA record to determine if the issuer was allowed to have issued the cert. I infer from the wording around there and elsewhere in the RFC that this is mostly because someone could switch issuers but still serve valid certs from the prior issuer, and there's no way an RP would have a historical record of which CAA values were in effect when to be able to determine if the issuance was valid or not.
	▲	Scott_Helme_ 27 minutes ago \| parent \| prev [-]
		CAA records are only checked by the CA at the point of issuance, not by the client later. If they did, there are problems to consider: 1. A domain would have to keep the CAA records for a CA in place to keep using the certificates from that CA, but that means continuing to authorise new issuance too. Right now, I can remove the `letsencrypt.org` value to stop them from issuing new certificates for me, but I can keep using any certificates I have until they expire. 2. The client would need to have support for this new DNS RR type. 3. The client would need a secure way to query DNS, which is not widespread.

▲

woodruffw 3 hours ago | parent | prev [-]

Why would I trust my domain registrar to maintain PKI? They don’t seem inherently better suited for it, and in various ways are more susceptible to meddling for e.g. ccTLDs.

I think the idea that CAs are uniquely incompetent is probably incorrect.