[zeveb]

> Certificates are BS.

Pretty much. The whole business model never really made sense: the relying parties have no relationship with the certificate authorities, while the HTTPS servers are the customers of the CAs.

I think it would make a lot more sense for certificates to be issued by domain owners, esp. since the original idea of tying sites to real-world businesses (e.g. with Dun & Bradstreet numbers) has been reduced to just verifying domain-name ownership.

Edit: I think people misunderstand what I am saying here. What I mean is that I think that when one purchases a subdomain of domain, that domain should just issue a certificate — and that domain should only be allowed to issue certificates for its children. So e.g. if one purchases foo.com, then com issues a certificate for foo.com; if one purchases bar.net, then net issues a certificate for bar.net; if one purchases baz.ac.uk then ac.uk issued a certificate for baz.ac.uk. This is essentially what Let's Encrypt and ACME already do: com has the technical ability to reassign any of its subdomains at any time it wants to, and can get a certificate issued for any of them by reassigning & registering a certificate.

And while we're at it, maybe we could kill ASN.1 with fire?

Edit: if you downvoted for this, you have never tried to debug an ASN.1 BER file.

[microcolonel]

Then there's the whole issue of putting domain names/common names inside the certificates, but relying on external verification; rather than just having the DNS NICs directly sign for domains they have obvious authority over.

[arp242]

> I think it would make a lot more sense for certificates to be issued by domain owners, esp. since the original idea of tying sites to real-world businesses (e.g. with Dun & Bradstreet numbers) has been reduced to just verifying domain-name ownership.

The problem with that approach is that anyone can create a certificate for any domain; so if I go to "example.com" then it's kinda hard for me to detect if my connection is being MITM'd, especially if this is the first time I'm visiting example.com.

This is why ACME requires a verification that you actually control example.com (via http or dns).

I don't think the CA model is perfect by any means, but I don't think it's completely without value either.

[pbhjpbhj]

>The problem with that approach is that anyone can create a certificate for any domain; so if I go to "example.com" then it's kinda hard for me to detect if my connection is being MITM'd, especially if this is the first time I'm visiting example.com. //

I thought they meant the .tld registry would issue the certificate, so any registrar could sell you the domain+cert but it would have to come from the registry (ICANN say, for .com).

Can't the DNS data have a hash of the cert to avoid 3rd party certs (unless the 3rd party controls the domain registry entry, but then MitM is a [ahem] dead cert).

[ocdtrekkie]

DNS providers should be your HTTPS providers though. Presumably the certs your browser would have to "just know" would be for the root TLDs, so you could verify with them what DNS provider a given domain was entrusted to, and then query that DNS provider whether or not your domain's certificate was legitimate.

The idea that any CA can issue a valid cert for any domain is the heart of what's wrong with PKI.

[brohee]

The name constraint extension (https://tools.ietf.org/html/rfc5280#section-4.2.1.10) can help a lot with that, we chose to trust CA for all names but we could have had CAs for a way more limited set of domains.

Software support is far from universal sadly.

[zeveb]

> The problem with that approach is that anyone can create a certificate for any domain; so if I go to "example.com" then it's kinda hard for me to detect if my connection is being MITM'd, especially if this is the first time I'm visiting example.com.

You misunderstand what I mean: I advocate that the owner of .com be permitted to mint certificates for foo.com, bar.com, since right now the owner of .com and can point those subdomains to any host he wishes, and then generate a certificate using ACME (because he actually controls every subdomain of .com).

[arp242]

Oops, sorry; I misunderstood your comment. I thought that with "domain owners" you meant "the person who registered the domain" (i.e. self-signed certs).

Using DNS providers for certificates is an interesting idea; one I haven't heard before. I can't really think of any downsides of that at the moment.

[ocdtrekkie]

> original idea of tying sites to real-world businesses

Ironically, the only system PKI had to attempt this, Extended Validation, is opposed by the loudest voices in PKI today. Despite arguably being the only real benefit PKI potentially offered: Notarizing that a domain really belonged to a given real-world entity.

EV had flaws, but it should've been improved, not axed. Security detached from people-understandable real-world entities will never provide real security, because at the end of the day people still need to interact with the system.