4 ms·

> Huh? That is what a PKI consists of.... How do you sign a key/value data set with a certificate from Verisign? Are there tools that can automatically follow

> Huh? That is what a PKI consists of.... How do you sign a key/value data set with a certificate from Verisign? Are there tools that can automatically follow this delegation? In DNSSEC once your zone is signed, you can upload an entire signed tree of subdomains. With current CA's, you get one certificate signed for xxxxxxx.com, and have to go back to Verisign for any subdomains (keys) you decide to add later. I can't add a signed value for __custom_protocol__._wellknown.me.com that uses the existing x509 infrastructure. If I add another server, I can't delegate to it. > DNSSEC was, from the outset, designed to support offline signing. Yes... that's what I said. The replacement should support it, too.

marcosdumay 11y ago
> How do you sign a key/value data set with a certificate from Verisign? If your domain root is signed by Verisign, you get your domain key signed through your register. The actual procedure varies with the register, from impossible to fully automated. DNS is exactly a key/value dataset. I just don't understand the point of your other questions: >Are there tools that can automatically follow this delegation? Just list the domain. You'll see all delegations there. > In DNSSEC once your zone is signed, you can upload an entire signed tree of subdomains. With current CA's, you get one certificate signed for xxxxxxx.com, and have to go back to Verisign for any subdomains (keys) you decide to add later. > I can't add a signed value for __custom_protocol__._wellknown.me.com that uses the existing x509 infrastructure. If I add another server, I can't delegate to it. Are you arguing that the specific certificates are better? Why?
- oconnore 11y ago
  > Just list the domain. You'll see all delegations there. > Are you arguing that the specific certificates are better? Why? We seem to be having a communication issue. From [1]: "Delegation problem: CAs cannot technically restrict subordinate CAs from issuing certificates outside a limited namespaces or attribute set; this feature of X.509 is not in use. Therefore a large number of CAs exist on the Internet, and classifying them and their policies is an insurmountable task. Delegation of authority within an organization cannot be handled at all, as in common business practice." With DNSSEC this is not a problem. Once I have a DS key pointing to my zone, I can delegate as much as I want. This allows a great deal of flexibility, as I've already mentioned. [1]: https://en.wikipedia.org/wiki/X.509#Problems_with_certificate_authorities https://en.wikipedia.org/wiki/X.509#Problems_with_certificat...
  - geofft 11y ago
    Ah, I think the delegation problem with the X.509 / HTTPS PKI is a (fairly massive) implementation facepalm, not anything inherent to a PKI itself. So I think that's why people were confused by your statement "DNSSEC got PKI wrong" -- that doesn't seem wrong, it seems like a good thing for a PKI to support this. Do you think that a DNSSEC replacement should match the X.509 PKI in this regard?
    - oconnore 11y ago
      Ah, that makes sense. Sorry for the confusion I created. I meant that DNSSEC PKI is wrong in the sense that it is hierarchical, and the root keys are centrally controlled by a biased party. A better PKI would probably look like Convergence [1], where trust is derived from a hybrid CA/"web of trust" system formed by a network of notaries. The delegation implemented in DNSSEC is a good thing. I didn't think about how that feature would quite reasonably be lumped in with "PKI". Oops. [1]: http://convergence.io/ http://convergence.io/
      - indolering 11y ago
        Marlinspike abandoned convergence a year after it was debuted. It's currently broken on most (all?) platforms. As covered in the article, Convergence-style triangulation of cryptographic information is application/protocol neutral. Indeed, a DNS-level implementation would be much more powerful than what can be accomplished with HTTPS.
        tptacek 11y ago
        He moved from Convergence to TACK, which is on hold during the rollout of HPKP, which is like 80% of the value proposition of TACK.
        cpach 11y ago
        What’s in the missing 20%?

marcosdumay 11y ago

> How do you sign a key/value data set with a certificate from Verisign? If your domain root is signed by Verisign, you get your domain key signed through your register. The actual procedure varies with the register, from impossible to fully automated. DNS is exactly a key/value dataset. I just don't understand the point of your other questions: >Are there tools that can automatically follow this delegation? Just list the domain. You'll see all delegations there. > In DNSSEC once your zone is signed, you can upload an entire signed tree of subdomains. With current CA's, you get one certificate signed for xxxxxxx.com, and have to go back to Verisign for any subdomains (keys) you decide to add later. > I can't add a signed value for __custom_protocol__._wellknown.me.com that uses the existing x509 infrastructure. If I add another server, I can't delegate to it. Are you arguing that the specific certificates are better? Why?

oconnore 11y ago
> Just list the domain. You'll see all delegations there. > Are you arguing that the specific certificates are better? Why? We seem to be having a communication issue. From [1]: "Delegation problem: CAs cannot technically restrict subordinate CAs from issuing certificates outside a limited namespaces or attribute set; this feature of X.509 is not in use. Therefore a large number of CAs exist on the Internet, and classifying them and their policies is an insurmountable task. Delegation of authority within an organization cannot be handled at all, as in common business practice." With DNSSEC this is not a problem. Once I have a DS key pointing to my zone, I can delegate as much as I want. This allows a great deal of flexibility, as I've already mentioned. [1]: https://en.wikipedia.org/wiki/X.509#Problems_with_certificate_authorities https://en.wikipedia.org/wiki/X.509#Problems_with_certificat...
- geofft 11y ago
  Ah, I think the delegation problem with the X.509 / HTTPS PKI is a (fairly massive) implementation facepalm, not anything inherent to a PKI itself. So I think that's why people were confused by your statement "DNSSEC got PKI wrong" -- that doesn't seem wrong, it seems like a good thing for a PKI to support this. Do you think that a DNSSEC replacement should match the X.509 PKI in this regard?
  - oconnore 11y ago
    Ah, that makes sense. Sorry for the confusion I created. I meant that DNSSEC PKI is wrong in the sense that it is hierarchical, and the root keys are centrally controlled by a biased party. A better PKI would probably look like Convergence [1], where trust is derived from a hybrid CA/"web of trust" system formed by a network of notaries. The delegation implemented in DNSSEC is a good thing. I didn't think about how that feature would quite reasonably be lumped in with "PKI". Oops. [1]: http://convergence.io/ http://convergence.io/
    - indolering 11y ago
      Marlinspike abandoned convergence a year after it was debuted. It's currently broken on most (all?) platforms. As covered in the article, Convergence-style triangulation of cryptographic information is application/protocol neutral. Indeed, a DNS-level implementation would be much more powerful than what can be accomplished with HTTPS.
      - tptacek 11y ago
        He moved from Convergence to TACK, which is on hold during the rollout of HPKP, which is like 80% of the value proposition of TACK.
        cpach 11y ago
        What’s in the missing 20%?