[HN Gopher] The specs behind the specs - a deep-dive on ASN.1
       ___________________________________________________________________
        
       The specs behind the specs - a deep-dive on ASN.1
        
       Author : torotime
       Score  : 20 points
       Date   : 2022-01-12 11:47 UTC (1 days ago)
        
 (HTM) web link (engineering.wgtwo.com)
 (TXT) w3m dump (engineering.wgtwo.com)
        
       | dingosity wrote:
       | Why are we even talking about ASN.1/DER/BER? We should, like the
       | ancient Egyptian priests who opposed Akhenaten, chisel it's name
       | from every public edifice. Referring to it not as "ASN.1, the
       | platform-independent abstract type system," but "the great
       | heresy, which shall not be named."
        
         | ggm wrote:
         | Hand in your X.509 certificate at the door. (There was a
         | proposal to do x509 as s-expressions. The road not taken...)
         | ANY DEFINED BY ANY -- all following comments
        
       | pphysch wrote:
       | > You might have heard of similar such abstract syntax notations
       | used for interface definitions such as Google Protocol Buffers,
       | or Facebook's Apache Thrift, but those languages have not been
       | managed by a standardization organization, so the owning
       | corporations could (in theory) make breaking changes or change
       | the license or even remove the language definitions overnight.
       | 
       | Is this really the main difference between ASN.1 and Google
       | protobufs, that one is managed by a private corporation and the
       | other by a standardization organization? Can they otherwise be
       | used "interchangably" in designing interfaces, a la two different
       | programming languages (with different syntax of course)?
        
         | jwalton wrote:
         | In terms of tooling, there's excellent tooling for ASN.1 for C
         | and C++ and maybe some other languages. There's excellent
         | tooling for protobufs for a handful of languages too, but
         | they're different sets, so in practice what languages you want
         | to use would likely come into play.
        
       | [deleted]
        
       | andrewmcwatters wrote:
       | What's so great about ASN.1 and it's encoding rules is that
       | anyone writing type-length-value serialization for networking
       | purposes, for example[1], is basically independently reinventing
       | ASN.1 because it's so fundamentally optimal.
       | 
       | It truly will make you wonder why Protobufs and others exist.
       | 
       | [1]: https://github.com/Planimeter/grid-
       | sdk/blob/master/engine/sh...
        
       | AceJohnny2 wrote:
       | Can the veterans of the 90s SSL Wars explain the issues with
       | ASN1/DER/BER? Looking it up today, it seems like a pretty smart
       | and extensive serialization system, and I have to wonder why new
       | systems like Google Protobufs chose to reinvent the wheel.
       | 
       | Conversely, how have modern systems avoided the pitfalls (if any)
       | of ASN1/DER/BER?
        
         | jwalton wrote:
         | When I first saw protobufs, I wondered exactly the same thing.
         | 
         | There's an "XER" if you want a human-readable XML encoding,
         | too.
        
         | carapace wrote:
         | Personally, I think that people just like to reinvent things. I
         | don't want to sound shitty (or have kentonv show up again to
         | scold me for it) but I get the feeling that, a lot of the time,
         | it's just that simple.
         | 
         | https://news.ycombinator.com/item?id=20725550
        
         | kevin_thibedeau wrote:
         | 10 different string encodings is one problem.
        
       ___________________________________________________________________
       (page generated 2022-01-13 23:00 UTC)