3 ms·

EDI, PDF, and ACPI DSDT AML are provably worse "standards" as "standards" go. Forking implies a problem in one or more areas: - governance - usability (docum

EDI, PDF, and ACPI DSDT AML are provably worse "standards" as "standards" go. Forking implies a problem in one or more areas: - governance - usability (documentation and examples) - potentially NIH-syndrome protobufs, capnproto, flatbuffers, thrift, msgpack, erlang terms, BSON, java class files, and more exist to scratch itches that are not universally scratchable. You can't argue with the readability, portability, simplicity, or usability of JSON.. although you can argue with it's low density and parsing cost. What's missing generally in computer science, software engineering, and systems engineering is standardization down to a minimal, feature-complete subset of interchange formats, protocols, and APIs in the spirit of professionalizing and standardizing the industry with trusted conventions. The issue has been raised many times over the past 60 years, but at some point, there needs to be more than the rare bird of "professional engineering" licensure and too common and useless A+ certifications. I like DNSSEC and DANE because the combination adds another security layer to corroborate what PKI says. If browsers adopted it, it would be widely deployed to web-facing services. Like GPG, it has a UX problem and is a PITA to setup. (Sadly, a major DNSSEC multi browser extension effort shutdown.) I thought we were pro defense-in-depth rather than less security, so I don't understand the hate DNSSEC receives because it's not an alternative so much as a secondary trust-supporting mechanism. Disclaimer: I run PKI at home where every machine has 802.11x certs, every "intranet" has a cert from an intermediate cert, and every service like vSphere has its own subordinate signing cert. I keep meaning to migrate over to FreeIPA with Dogtag.

tptacek 4y ago
It effectively adds another CA to the set of CAs we already have, but this time without any of the transparency logs or browser leverage to control abuse. When operators screw up WebPKI certificates, people get certificate errors in their browser. When they screw up DNSSEC --- which everybody does --- their whole domain falls off the Internet. It doesn't solve any problems, and creates new ones. It's easy to understand the hate DNSSEC gets.
- cryptonector 4y ago
  Shall we reprise our arguments about this again for GP's benefit? Nothing about DNSSEC precludes the addition of CT, and it will eventually happen. DNSSEC w/ query name minimization means that any zone that wishes to MITM you has to potentially make the decision without first knowing what your target domain is, or even who you are (obviously this last depends on context), and the more indiscriminate they are in their MITM activities the more likely that they'll be caught. That's a big deal, and something WebPKI can't offer -- WebPKI only has CT to offer for mitigating the MITM power of CAs, and CT depends on people auditing the logs.
  - tptacek 4y ago
    Only any entity in the world that can effectively require the major TLDs to implement DNSPKI transparency. The browsers forced CT on the CAs, under threat of removing them from the root programs.
cryptonector 4y ago
> You can't argue with the readability, portability, simplicity, or usability of JSON. Hah, the joke's on you: ASN.1 has JER, which is the ASN.1 JSON Encoding Rules :) So you can specify JSON schemas in ASN.1 syntax, which means that you could transcode from any of the other ASN.1 encoding rules, which include: - BER/DER/CER (TLV encodings) - OER/PER (like XDR, but with one octet alignment) - XER (yes, the X is for XML -- XML Encoding Rules) - GSER (a pre-JSON JSON-like encoding rules for ASN.1 invented at IETF) - and other ERs that are proprietary - and any ER you care to create, which could just be bindings of other encoding schemes like Flat Buffers or anything else you like. I've been wanting an XDR-based encoding rules... Which goes to show that a lot of the encoding schemes you listed could just have been ASN.1 ERs from the get-go and: - benefited from existing ASN.1 modules - benefited from transcoding - benefited from existing ASN.1 compiler codebases But no, people had to reinvent the wheel all the way to the syntax and semantics without adding much of anything truly new. > I like DNSSEC and DANE because the combination adds another security layer to corroborate what PKI says. If browsers adopted it, it would be widely deployed to web-facing services. Like GPG, it has a UX problem and is a PITA to setup. (Sadly, a major DNSSEC multi browser extension effort shutdown.) I thought we were pro defense-in-depth rather than less security, so I don't understand the hate DNSSEC receives because it's not an alternative so much as a secondary trust-supporting mechanism. I agree with this, though I'm not sure what is the antecedent of "it" in "[l]ike GPG, it has a UX problem..." -- could be DNSSEC, but it could also be PKI! :)

tptacek 4y ago

It effectively adds another CA to the set of CAs we already have, but this time without any of the transparency logs or browser leverage to control abuse. When operators screw up WebPKI certificates, people get certificate errors in their browser. When they screw up DNSSEC --- which everybody does --- their whole domain falls off the Internet. It doesn't solve any problems, and creates new ones. It's easy to understand the hate DNSSEC gets.

cryptonector 4y ago
Shall we reprise our arguments about this again for GP's benefit? Nothing about DNSSEC precludes the addition of CT, and it will eventually happen. DNSSEC w/ query name minimization means that any zone that wishes to MITM you has to potentially make the decision without first knowing what your target domain is, or even who you are (obviously this last depends on context), and the more indiscriminate they are in their MITM activities the more likely that they'll be caught. That's a big deal, and something WebPKI can't offer -- WebPKI only has CT to offer for mitigating the MITM power of CAs, and CT depends on people auditing the logs.
- tptacek 4y ago
  Only any entity in the world that can effectively require the major TLDs to implement DNSPKI transparency. The browsers forced CT on the CAs, under threat of removing them from the root programs.

cryptonector 4y ago

> You can't argue with the readability, portability, simplicity, or usability of JSON. Hah, the joke's on you: ASN.1 has JER, which is the ASN.1 JSON Encoding Rules :) So you can specify JSON schemas in ASN.1 syntax, which means that you could transcode from any of the other ASN.1 encoding rules, which include: - BER/DER/CER (TLV encodings) - OER/PER (like XDR, but with one octet alignment) - XER (yes, the X is for XML -- XML Encoding Rules) - GSER (a pre-JSON JSON-like encoding rules for ASN.1 invented at IETF) - and other ERs that are proprietary - and any ER you care to create, which could just be bindings of other encoding schemes like Flat Buffers or anything else you like. I've been wanting an XDR-based encoding rules... Which goes to show that a lot of the encoding schemes you listed could just have been ASN.1 ERs from the get-go and: - benefited from existing ASN.1 modules - benefited from transcoding - benefited from existing ASN.1 compiler codebases But no, people had to reinvent the wheel all the way to the syntax and semantics without adding much of anything truly new. > I like DNSSEC and DANE because the combination adds another security layer to corroborate what PKI says. If browsers adopted it, it would be widely deployed to web-facing services. Like GPG, it has a UX problem and is a PITA to setup. (Sadly, a major DNSSEC multi browser extension effort shutdown.) I thought we were pro defense-in-depth rather than less security, so I don't understand the hate DNSSEC receives because it's not an alternative so much as a secondary trust-supporting mechanism. I agree with this, though I'm not sure what is the antecedent of "it" in "[l]ike GPG, it has a UX problem..." -- could be DNSSEC, but it could also be PKI! :)