So, you will need a CA that are trusted by all parties involved, and one that is not tied to the Web PKI ecosystem.
One option is to build your own PKI with it’s own root certificate, and then tell all involved parties to import that into their root cert stores.
That’s a lot of work though. If you want to, I think you can buy “private-PKI-as-a-service” from companies like Digicert and Sectigo. And probably from AWS/Google/Azure too.
I don’t know the specifics of your environment but it might also be possible to do encryption and signature verification above the transport layer. I.e. sign (and possibly encrypt) the payload itself. Then you might not need mTLS for the connection itself.
Yeah, we've gone down the private CA PKI route, trouble is that you need to start managing your roots and your CA/RA properly, it needs to be auditable etc etc.
Cost of a Private CA on AWS is $400/month for a CA that issues certs more than 7 days in duration. That's for one signing CA. If you want PKI with a root, intermediates, and leaves, then the root has to issue intermediates every 7 days as well, or you have your root signing the leaves.
On top of that is the infrastructure of the RA, because if you want to automatically issue certs (eg to devices in the field), you need to implement ACME, but you can't necessarily use DNS methods for verification.
So you have to roll your own, from a Secure Element that contains a base key that gets diversified by the device's own ID, so it can sign a CSR or an internal DNS server that adds an TXT record for the dns-01 challenge.
Then you need the human processes of building the RA, authorizations, ceremonies, etc etc.
Good question. On their website they list 3550 Lenox Road, NE Atlanta, Georgia 30326 as their address. But no info about the company name, CEO or anything like that.
s6 (perhaps with s6-rc) is another interesting option. One could say it’s less opinionated than systemd. Or perhaps it’s more correct to say it has another set of opinions.
Alright that’s pretty bad. Have some questions though.
- For the bit.ly thing; as far as I understand Gaddafi could at least theoretically order the registrar to point somewhere else and then that somewhere else could get new keys from the automated CA, right? Or am I missing something? Maybe we do want some second layer process for extra security, but couldn’t you solve this by sticking extra certificates in the record? This can also replicate the corporate solution: “trust an extra MyCorp certificate as well as the actual one.”
- So… now that I know the details of DNSSEC beyond “signed encrypted DNS,” I’m not a fan. What stops us from phasing in (beyond, elas, politics and network effects) Actually Good Signed Encrypted DNS? Specifically;
- For backwards compat, can we separate the “signed” and “encrypted” part where you stick a signature on the record which signs the hash of the record minus the signature and any other signatures?
- And then, for encryption, can you just do DNS-over-TLS or something like that? Totally separate from the signing bit; the goal of signing is that you can trust the data, the goal of encryption is that people can’t see what you’re looking up.
- And let’s say we had this nice two-layer protocol. Why do we need proofs of nonexistence? Why not just treat it like https and, when adoption is good enough, default deny insecure HTTP? Seems like another mistake in DNSSEC to have this feature at all…
For a glimpse into the idealized mental model of an idealized future I’m grasping at here:
- An abstract identity is (waves at philosophy)
- A concrete identity is a set of cryptographic keys
- Two problems:
- How do I find out the identity associated with a name. Related subproblem: key rotation and friends.
- How do I reach the given identity, over a given network; here the Internet
Technically these can be separate services! DNS can do both at the same time so efficiency, but they’re orthogonal.
- You can have other naming systems. For example, a social network with E2E chat can be viewed as mapping names to identities-as-keys
- You can have other comms channels: see here again the chat, which is at a higher level than the Internet. But also SMS, Tailscale, idk… also, see different kinds of DNS records so one naming system (DNS) can handle multiple reachability kinds!
So, in short, if anyone bothered to read this brain dump, I believe a form for trustable (if you trust the source but not the nodes) hierarchical name => identity systems is a Good Idea so far, and I guess DNSSEC is not the way… but it still seems like CA is also not the way and it should really be part of DNS.
I know that many feel strongly that the web’s trust system should somehow move into DNS.
I think the first questions to ponder are: What is it that is wrong with the current WebPKI? (As it is in 2025, not as it was in 1999.) What would actually become better if we tried to move all of this into DNS?
Ponder this: Why do we place the “trust handling” in the application layer? (HTTP with TLS.) Why not in the IP layer?
- "I want to connect to IP X"
- What IP X is is defined by your ISP. You can probably have a trust model here (ISP X cannot reassign IPs from ISP Y) but people don't usually dial IPs like phone numbers, and if they are, then just get them to dial a public key (only 4x longer!) and you're
- done
- future proof if the IP changes
- Whereas DNS is about names.
- Part of that is name to IP, but many names can map to one IP and vice versa, and IPs change
- Really it's about names for agents, who have a key
- So DNS solves the problem of mapping human readable name => ephemeral agent ID
- How do I trust that it's the right agent though?
- I need cryptography! But it's exactly the same situation I want from DNS, except that here I only trust the root server.
One option is to build your own PKI with it’s own root certificate, and then tell all involved parties to import that into their root cert stores.
That’s a lot of work though. If you want to, I think you can buy “private-PKI-as-a-service” from companies like Digicert and Sectigo. And probably from AWS/Google/Azure too.
I don’t know the specifics of your environment but it might also be possible to do encryption and signature verification above the transport layer. I.e. sign (and possibly encrypt) the payload itself. Then you might not need mTLS for the connection itself.
reply