| |
| ▲ | cryptonector 15 hours ago | parent | next [-] | | Would you rather they reinvent the wheel badly? Thjat's what ProtocolBuffers is: badly reinvented ASN.1/DER! PB is: - TLV (tag-length-value), like DER
- you have to explicitly list the
tags in the IDL as if it was ASN.1
in 1984 (but actually, worse,
because even back then tags were
not always required in ASN.1, only
for diambiguation)
- it's super similar to DER, yet not
not the same
- PB was created in part because ASN.1
had so little open source tooling,
but PB had none until they wrote it
so they could just have written the
ASN.1 tooling they'd wished they had
smh | | |
| ▲ | RainyDayTmrw 14 hours ago | parent | next [-] | | In complete fairnes to PBs, PBs have a heck of a lot less surface area than ASN.1. You could argue, why not use a subset of ASN.1, but it seems people have trouble agreeing which subset to use. | | |
| ▲ | cryptonector 2 hours ago | parent [-] | | I don't agree with that. PB is practically the same as DER. All the attack surface area lies in the codec, specifically in the decoder. |
| |
| ▲ | mort96 11 hours ago | parent | prev | next [-] | | Why wouldn't you want to explicitly number fields? Protocols evolve and get extended over time, making the numbering explicit ensures that there's no accidental backwards compat breakage from re-ordering fields. Implicit field numbers sounds like an excellent reason to not use ASN.1. This shilling for an over-engineered 80s encoding ecosystem that nobody uses is really putting me off. | | |
| ▲ | cryptonector 2 hours ago | parent [-] | | > Why wouldn't you want to explicitly number fields? Protocols evolve and get extended over time, making the numbering explicit ensures that there's no accidental backwards compat breakage from re-ordering fields. ASN.1 went through this whole evolution, and ended up developing extensive support for extensibility and "automatic tagging" so you don't have to manually tag. That happened because the tagging was a) annoying, b) led to inconsistent use, c) led to mistakes, d) was almost completely unnecessary in encoding rules that aren't tag-length-value, like PER and OER. The fact that you are not yet able to imagine that evolution, and that you are not cognizant with ASN.1's history proves the point that one should study what came before before reinventing the wheel [badly]. |
| |
| ▲ | flowerthoughts 15 hours ago | parent | prev [-] | | The one thing that grinds my gears about BER/CER/DER is that they managed to come up with two different varint encoding schemes for the tag and length. | | |
| ▲ | cryptonector 14 hours ago | parent [-] | | Meh. One rarely ever needs tags larger than 30, and even more seldom tags larger than twice that, say. | | |
| ▲ | flowerthoughts 6 hours ago | parent [-] | | Yeah, but if you're writing a parser for use by others, you have to implement both, even if it's "rarely" used. Or some intern somewhere will have a bad day after getting tasked with "just add this value here, it'll be an easy starter project." :) | | |
|
|
| |
| ▲ | Ekaros 12 hours ago | parent | prev | next [-] | | Understanding prior art and getting more comprehensive list of things that need to be considered is always good. Not doing it is like inventing new programming language after just learning one of them. | |
| ▲ | RainyDayTmrw 21 hours ago | parent | prev [-] | | What should people use today, given the choice, that isn't ASN.1? Edited to add: If they need something with a canonical byte representation, for example for hashing or MAC purposes? | | |
| ▲ | viraptor 18 hours ago | parent | next [-] | | How much of it do you need in that representation? Usually I see that need in either: x509 where you're already using der, or tiny fragments where a custom tag-length-value would cover almost every usage without having to touch asn. | | |
| ▲ | RainyDayTmrw 14 hours ago | parent [-] | | All I really need is serialization for structs. I'm trying to avoid inventing my own format, because it seems to be footgun-prone. |
| |
| ▲ | cryptonector 15 hours ago | parent | prev | next [-] | | First of all you should never need a canonical representation. If you think you do, you're almost certainly wrong. In particular you should not design protocols so that you have to re-encode things in order to validate signatures. So then you don't need DER or anything like it. Second, ASN.1 is fantastic. You should at least study it a bit before you pick something else. Third, pick something you have good tooling for. I don't care if it's ASN.1, XDR, DCE RPC / MSRPC, JSON, CBOR, etc. Just make sure you have good tooling. And don't pick XML unless you really need it to interop with things that are already using XML. EDIT: I generally don't care about downvotes, but in this case I do. Which part of the above was objectionable? Point 1, 2, or 3? My negativity as to XML for protocols? XML for docs is alright. | | | |
| ▲ | wglb 19 hours ago | parent | prev [-] | | Here are some issues: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=asn.1 |
|
|
