3 ms·

I would replace OIDs with URNs. Textual identifiers are much nicer than OIDs in any APIs and in any UIs (if they must leak there, which often happens). This g

I would replace OIDs with URNs. Textual identifiers are much nicer than OIDs in any APIs and in any UIs (if they must leak there, which often happens). This goes for things like GSS-API as well. I do NOT like definite-length encoding. It's nice to have the full length of a PDU up front, but inside the PDU you want to use indefinite length encoding for everything as this greatly simplifies encoding. Tag-length-value (TLV) is an anti-optimization that was only ever a crutch. By the time the ITU-T worked on PER this was well understood. I feel that the use of TLV encoding rules held back [open source] compiler creation for ASN.1. Compare to XDR and rpcgen. XDR is a lot like a subset of ASN.1 with PER-/OER-like encoding that uses 4-octet alignment. XDR was long easier to use than ASN.1, but why? Mostly because a) it has C-like syntax and is fairly easy to build parsers for, and b) the encoding rules are very straightforward. Protocol buffers makes some of the same mistakes as DER... It's really difficult to reinvent wheels well. It really helps to not throw the baby out with the bathwater. Specifically, here, there's a lot functionality in ASN.1 the _syntax_ that would be very good to keep. As for encoding rules, XDR is dead simple, so I'd use that for almost anything. It's also good to know what's really missing. For my money, the most commonly missing feature is control over emitted types for the host language, and, specifically, lack of a way to emit private fields that are not to be encoded or decoded but which make it easy to keep state near relevant data. XDR is so simple that as long as you have a decent buffer abstraction and support routines for encoding/decoding scalar types, it's easy enough to do without a compiler. The most promising newish thing here is flatbuffers.

pas 7y ago
What's wrong with TLV? It helps getting rid of end-of terminators, no?
- cryptonector 7y ago
  For one, the tags aren't necessary -- you know what belongs at any point, and for OPTIONAL/DEFAULT elements all you need to know is whether they are present or absent (that's one bit, or a byte if you're not aiming to be more space efficient). Definite-lengths greatly complicate encoding. The easiest way to encode DER is "backwards", starting the end of a SEQUENCE and working your way backwards. That's a bit of a pain. Definite-lengths add lots of mostly-unnecessary redundancy. For constrained-range integers, the best thing to do is to encode them as whatever number of octets are needed to encode the constrained range. For structures (SEQUENCE) and arrays (SEQUENCE/SET OF) indefinite length encoding is much easier to encode. Decoding is easy because you just decode the fields -- a terminator shouldn't be needed (though I know BER uses terminators, but that's a design flaw in the BER family of encoding rules, not a complete necessity. Definite-length encodings or terminator encodings are mostly only needed for strings and extensibility holes (OCTET STRINGs, extensibility markers), but they can be the exception rather than the rule, and thus simplify things.

pas 7y ago

What's wrong with TLV? It helps getting rid of end-of terminators, no?

cryptonector 7y ago
For one, the tags aren't necessary -- you know what belongs at any point, and for OPTIONAL/DEFAULT elements all you need to know is whether they are present or absent (that's one bit, or a byte if you're not aiming to be more space efficient). Definite-lengths greatly complicate encoding. The easiest way to encode DER is "backwards", starting the end of a SEQUENCE and working your way backwards. That's a bit of a pain. Definite-lengths add lots of mostly-unnecessary redundancy. For constrained-range integers, the best thing to do is to encode them as whatever number of octets are needed to encode the constrained range. For structures (SEQUENCE) and arrays (SEQUENCE/SET OF) indefinite length encoding is much easier to encode. Decoding is easy because you just decode the fields -- a terminator shouldn't be needed (though I know BER uses terminators, but that's a design flaw in the BER family of encoding rules, not a complete necessity. Definite-length encodings or terminator encodings are mostly only needed for strings and extensibility holes (OCTET STRINGs, extensibility markers), but they can be the exception rather than the rule, and thus simplify things.