@cjd ICANN can (and has) canceled TLDs and domains (on threat of canceling TLD) for political reasons. The shadowy "TLS cabal" selects CAs for inclusion in the "trusted" list for mainstream browsers. Any CA on the list can forge any cert whenever they want.
ICANN is ok for public websites - but if you want actual security, run your own TLD and CA. Like we did in the old days before ICANN.
We've been CLI (manual) signing certs, but I'm about to try this open source ACME server for private CAs/TLDs:
https://github.com/smallstep/certificates
@cjd Run your own ACME server for .pkt. Like the one I linked.
The BIG issue is that Normies only comprehend how to add fully trusted CAs to their browser (allowed to validate any domain). We need a normie friendly way to add a PKCS#11 policy that e.g. does *not* trust cabal CAs for .PKT and *only* trusts your CA for .PKT.
@cjd But then, the cabal CAs can still forge certs for the local stuff. Because the cabal CAs are trusted for *everything* - not just ICANN TLDs.
@customdesigned
Almost everything supports this. For example, I distribute a CA to all my equipment that's only valid for r000t.com and subdomains
@cjd
@cjd Not the biggest fan of golang - but at least it compiles fast, unlike Rust.
x := SomeStruct {
// hehe missing field here, lets just make it nil
}
Lead to so many blowups that it soured my opinion of the entire language. Not to mention most of my go experience was working on terrible code...
People register pkt.<whatever> and point it to our nameservers, then people who register domains on PKT blockchain get <their domain>.pkt.<every TLD>
So going after these is ... complicated.
But if LetsEncrypt just stops issuing certificates for political reasons then we lose SSL...