To Home page
What is a protocol? Protocols wind up being defined by implementations, which people attempt, not very successfully, to reverse engineer. By trial and error they get their client to work with the existing server, and their server to work wit the existing client, and so an ill defined protocol becomes over time even worse defined.
To address this problem, we have ASN.1, ASN.1 PER, and ASN.1 DER
ASN.1 is a language for describing data.
It is also a compiler for generating C code to process the data described. Some people complain that DER is too complex for anyone to get right.
If you attempt to hand generate code for processing packets described by ASN.1, you will probably get it wrong and your head will explode. Hence ASN.1 is much cursed and condemned.
Don't do that. Don't hand write code to generate or interpret ASN.1 data packets. You are unlikely to succeed, and your code will have mystery bugs.
ASN.1 PER is ASN.1 data description complied to produce efficiently compressed data packets that conform to a description in ASN.1, and efficiently decompresses them.
ASN.1 DER that data description that generates data packets with a description of what the data packet means, so that if two programs sign the same ASN.1 DER data, they agree not only on the data, but on the meaning of that data, and if one program means the same thing as the other program, the signatures will come out the same.
Use it. ASN.1, used right, is what is needed to rigorously define a protocol so that a client written by one person will work with a server written by another.
There is much loud cursing about the fact that the data on the wire is humanly incomprehensible, and that the code that converts it into program data structures is humanly incomprehensible. No one should be looking at machine generated code, because machine generated code is notoriously incomprehensible. The question then is, does the compiler work, and is the compiler usable.
If a program reads DER or BER data, the result is apt to be disastrous. BER and DER can express an arbitrary data structure - and thus can crash the program receiving the data, probably causing it to execute transmitted data as code.
You can't depend on a DER or BER bit string being able to map back into any well-defined ASN.1 object that the program was designed to deal with.
Incoming data should be parsed as the expected and bounded size data
structure, thus we need something that can generate parsing code from a
description of the data at compile time. We need compile time
descriptions of the data, not run time descriptions, because the program
that uses the incoming data will unavoidably rely on compile time
description of the data.
PER, however cannot receive unexpected data structures, because the expected data structure is specified at compile time, not run time. Malicious or faulty data will generate an error, not a crash.
Thus all data should be received as PER or by a format with the properties of PER.
These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License