3 ms·

Names are not meanings but they describe a meaning. Webpki is framework used to verify public key ownership,specitically for TLS like you mentioned. What makes

Names are not meanings but they describe a meaning. Webpki is framework used to verify public key ownership,specitically for TLS like you mentioned. What makes webpki unique (and correct me if I am wrong) is how responsibilities are separated such that domain ownership is established by a 3rd party (like ISRG) as opposed to by the domain registrar. Logically speaking, the party transfering or registering domain ownership (for a fee) would also issue you a certificate at the time of transfer/registration. The different approaches to verify ownership would not be needed if the more sane approach was taken to begin with. As you know, DNS is a protocol sepatate from TLS or other protocols. As such, domain ownership/control validation should be contained within the domain name system (also, why dnssec,dane and other efforts are under way, but they don't address the root cause of the problem). For method 3.2.2.4.12 (and thanks for informing me about this), my comment was that it should be mandatory (not optional) for registrars to issue DV certs. While I appreciate the ISRG, there are cases where using letsencrypt is not practical ,that aside, one org controlling so much of the web goes against the very concept of having TLDs that are independent in purpose/function. It would be more architecturally sane if what the ISRG does now was instead done at least at the TLR level. (E.g.: .com's owners should issue certs that says site.com belongs to whoever has this cert) For the impractical corner cases: let's say I need to run a non-web service like SMTP and I can't spin up a web server to validate the domain. Or let's say I need non-TLS x509 such as ipsec.

tialaramex 7y ago
Let me start at the end: > let's say I need to run a non-web service like SMTP and I can't spin up a web server to validate the domain. You should use Let's Encrypt's implementation of 3.2.2.4.7 which is the dns-01 challenge as I already mentioned. Or use another vendor's own implementation of 3.2.2.4.7 or any of the half a dozen or so non-web methods listed. > Or let's say I need non-TLS x509 such as ipsec. The Web PKI can't help you. Leaf certificates in the Web PKI contain an EKU 1.3.6.1.5.5.7.3.1 which says their purpose is TLS server authentication. There is no global public PKI for IPsec. Feel free to try to make your own, but I expect it will be an expensive and thankless task. The central issue of a PKI is trust and domain name registrars are not on the whole very trustworthy. We're talking about the industry which invented Domain Front Running - the idea of waiting until a customer shows interest in a unique product (a domain name) and then buying it yourself so that they'll have to buy it from you at an inflated price. I sympathise with the desire to build a parallel PKI baked into the DNS system, but the Web PKI is not that system and there's no practical way to mutate it into that system. If you believe DANE is the only way forward you should go help people make DANE work better, not argue against the Web PKI. Issuing "a certificate" at time of domain registration greatly misses the point of Internet hierarchical naming by the way. While it would be technically possible for every domain to hold a single wildcard certificate and use flat naming (so news.america.ycombinator.com couldn't exist, it would need to be news-america.ycombinator.com) that's a terrible security choice. Necessarily where a service corresponds to one specific name the certificate and corresponding private key should be for that name only, and not a hierarchy of related names in order to mitigate risk.
- badrabbit 7y ago
  I think you misunderstood, I was not arguing against WEBPKI, I was advocating for a better ideal solution that does not exist. WEBPKI solves real problems well. I don't care for DANE either. To address your concern, clients will have TLD certs in their trust store. TLDs issue intermediate CA certs to registrars. When you get a domain, they issue a cert (not x509 neccesarily) that allows you to issue certificates like an intermediate but restricted to that domain and its subdomains. So news.america and news. Under ycombinator.com will have separate certs,signed by the owner of ycombiator.com which on turn has to have their CA cert signed by a registrar. This actually can improve security, because you can isolate your intermediate signig key from the rest of your services, and possibly have a dynamic process of issuing extremely short lived certs by your CA box to all of your services. Code signing certs,s/mime,client certs, eap-tls,etc... Can all be more easy to use. For example, if I could use eap-tls to connect to wifi at an airport or starbucks using a cert I issued myself under my domain (or under my work/school domain). Things that have been notoriously hard to adopt like TLS client certs could easier to use because anyone can have a client cert issued to them by any domain owner (likely the domain of their email provider for most) because any site can verify their client cert using this system and anyone with a domain can issue certs. This is the natural and most sensible way. As for trust, you already trust them with the power to transfer your domain. If someone compromises your registrar account, what stops them from taking over the domain,pointing it at their own servers and getting a new cert from ISRG? Imagine getting a government ID and to verify it's legitimacy,people have to contact 3rd party companies instead of the government, that makes no sense. Things are the way they are because public key crypto was not used widely when DNS and the internet became a thing.

tialaramex 7y ago

Let me start at the end: > let's say I need to run a non-web service like SMTP and I can't spin up a web server to validate the domain. You should use Let's Encrypt's implementation of 3.2.2.4.7 which is the dns-01 challenge as I already mentioned. Or use another vendor's own implementation of 3.2.2.4.7 or any of the half a dozen or so non-web methods listed. > Or let's say I need non-TLS x509 such as ipsec. The Web PKI can't help you. Leaf certificates in the Web PKI contain an EKU 1.3.6.1.5.5.7.3.1 which says their purpose is TLS server authentication. There is no global public PKI for IPsec. Feel free to try to make your own, but I expect it will be an expensive and thankless task. The central issue of a PKI is trust and domain name registrars are not on the whole very trustworthy. We're talking about the industry which invented Domain Front Running - the idea of waiting until a customer shows interest in a unique product (a domain name) and then buying it yourself so that they'll have to buy it from you at an inflated price. I sympathise with the desire to build a parallel PKI baked into the DNS system, but the Web PKI is not that system and there's no practical way to mutate it into that system. If you believe DANE is the only way forward you should go help people make DANE work better, not argue against the Web PKI. Issuing "a certificate" at time of domain registration greatly misses the point of Internet hierarchical naming by the way. While it would be technically possible for every domain to hold a single wildcard certificate and use flat naming (so news.america.ycombinator.com couldn't exist, it would need to be news-america.ycombinator.com) that's a terrible security choice. Necessarily where a service corresponds to one specific name the certificate and corresponding private key should be for that name only, and not a hierarchy of related names in order to mitigate risk.

badrabbit 7y ago
I think you misunderstood, I was not arguing against WEBPKI, I was advocating for a better ideal solution that does not exist. WEBPKI solves real problems well. I don't care for DANE either. To address your concern, clients will have TLD certs in their trust store. TLDs issue intermediate CA certs to registrars. When you get a domain, they issue a cert (not x509 neccesarily) that allows you to issue certificates like an intermediate but restricted to that domain and its subdomains. So news.america and news. Under ycombinator.com will have separate certs,signed by the owner of ycombiator.com which on turn has to have their CA cert signed by a registrar. This actually can improve security, because you can isolate your intermediate signig key from the rest of your services, and possibly have a dynamic process of issuing extremely short lived certs by your CA box to all of your services. Code signing certs,s/mime,client certs, eap-tls,etc... Can all be more easy to use. For example, if I could use eap-tls to connect to wifi at an airport or starbucks using a cert I issued myself under my domain (or under my work/school domain). Things that have been notoriously hard to adopt like TLS client certs could easier to use because anyone can have a client cert issued to them by any domain owner (likely the domain of their email provider for most) because any site can verify their client cert using this system and anyone with a domain can issue certs. This is the natural and most sensible way. As for trust, you already trust them with the power to transfer your domain. If someone compromises your registrar account, what stops them from taking over the domain,pointing it at their own servers and getting a new cert from ISRG? Imagine getting a government ID and to verify it's legitimacy,people have to contact 3rd party companies instead of the government, that makes no sense. Things are the way they are because public key crypto was not used widely when DNS and the internet became a thing.