4 ms·
The fundamental problem is with X.509... It uses a flat namespace so all CAs can issue a valid certificate for any domain on the internet. Much of the problem c
by gorset 16y ago
The fundamental problem is with X.509... It uses a flat namespace so all CAs can issue a valid certificate for any domain on the internet. Much of the problem could have been avoided if it was using a proper hierarchical structure, e.g. mirroring DNS, so only a .com CA could create a valid google.com certificate.
- caf 16y agoCompletely agreed. Note under such a system we wouldn't have even had to create separate CAs - it would have been natural for DNS registrars to take on this role, signing a certificate for your domain at the same time that they delegated your name server records. Certificate expiry dates could have been directly linked to domain registration expiry dates. Under such a system, you'd know that you were only at the mercy of the Chinese government when browsing .cn sites - which is neither unsurprising nor too much of a worry.
- tptacek 16y agoWhy do you trust DNS registrars more than you trust CAs?
- m0nastic 16y agoDanica Patrick isn't inherently trustworthy?
- gorset 16y agoYou are already trusting DNS more than CAs. The CN is set to your domain, not to mention that the authorization process for many CAs uses email, which depends on DNS. This is just another reason why it's so important to get technologies such as DNSSEC and DNSCurve working. As many have pointed out, it make sense to replace X.509 with DNSEC for exactly this reason, so you can verify the SSL certificate by simply doing a secure dns lookup.
- caf 16y agoIt is a logical conclusion that I trust the set (my DNS registrar) at least as much as I trust the set (my DNS registrar ∩ All CAs in the world). Not to mention that this would fix some of the incentive problems. DNS top-levels would effectively be competing on the strength of their certificate-issuing properties - if a particular TLD was known to have a more corruption-resistant registrar, then that TLD ought to become more sought-after by security-concious sites.
- tptacek 16y agoHTTPS doesn't depend on you trusting your DNS registrar!
- caf 16y agoThere is a transitive trust relationship, because the a CA will typically supply a certificate to anyone who can prove that they control the domain, and the DNS registrar has ultimate control of the domain.
- vog 16y ago> a CA will typically supply a certificate to anyone who can prove that they control the domain This is true, but it is also a problem that needs to be fixed. A CA should not only check whether you control the domain, but should also check your (real-world) identity, and in the case of a company, should also check other documents. Yes, most don't, or do it only ineffectually, but they should do it.
- qjz 16y agoAs always, trustworthy encryption boils down to identity assurance. Even in real-world personal interactions, identity assurance is subject to a leap of faith ("I believe this person is who they say they are based on the evidence they presented"). As such, is this problem even solvable? People rely on a much less stringent level of assurance to create secure connections on the Internet, because they want it handled within a single mouse click, and that expectation isn't going to change. At least with a certificate issued by the registrar, there's some logical reason to believe that it was issued to whoever purchased the domain (whoever that is), which is often enough to establish an encrypted connection at a level the user expects. Significant problems remain, however: 1) Most domain owners have no idea how to generate a key and CSR (the registrar shouldn't do it) and 2) a truly reliable system for certificate revocation must exist to handle domain transfers. These aren't new problems, they just don't go away by shifting to this "easier" approach.
- fanf2 16y agoThe IETF "DANE" working group is specifying a way to do this using DNSSEC.