Reputation: 2705
I'm trying to grasp the concepts of ASN.1 and the encoding scheme (say DER) and would like to have a sanity check.
What I got so far is that ASN.1 defines abstract data types (INTEGER, BOOLEAN, etc., some are more complicated), and it allows you to define data structures in an abstract way, such as:
World-Schema DEFINITIONS AUTOMATIC TAGS ::=
BEGIN
Rocket ::= SEQUENCE
{
range INTEGER, -- huge (see a special directive above)
name UTF8String (SIZE(1..16)),
message UTF8String DEFAULT "Hello World" ,
fuel ENUMERATED {solid, liquid, gas},
speed CHOICE
{
mph INTEGER,
kmph INTEGER
} OPTIONAL,
payload SEQUENCE OF UTF8String
}
END
This defines a structure of a "Rocket" by defining certain fields for it. DER as an encoding scheme come into play only when I want to encode an object, i.e., concrete values of this data structure. So basically I can somehow tell my computer: According to this ASN.1 module, serialize the following JSON file:
{
"range":340282366920938463463374607431768211455,
"name":"Falcon",
"fuel":"solid",
"speed":{"mph":18000},
"payload":["Car", "GPS"]
}
And it'll generate a stream of bits conforming to a certain standard, defined by the DER standard. (X.690 for the manner of sake). Now every receiver of this bit stream (that knows that it's a DER encoded data) will know to interpret this message in terms of ASN.1.
One thing I can't really explain to myself is: do we have to define an interface? I mean, once we have the language (ASN.1) which defines the data types (INTEGER, STRING, etc.) - one can assemble messages, encode them, and send them, and they can be understood. Why does defining an interface between us is important?
Please correct me if I'm getting it all the wrong way.
Upvotes: 1
Views: 1799
Reputation: 2539
One thing I can't really explain to myself is: do we have to define an interface? I mean, once we have the language (ASN.1) which defines the data types (INTEGER, STRING, etc.) - one can assemble messages, encode them, and send them, and they can be understood. Why does defining an interface between us is important?
Just about every encoding system out there can be used without defining modules. XDR? Check. NDR? Check. Protocol Buffers? Check. JSON? Check. And so on.
The value of having modules defined lies in code generation. If you can have codecs (encoders and decoders) generated by a tool (a compiler) or interpreted by a tool, then you don't have to write that code by hand.
Hand-written codecs are often riddled with security bugs (well, at least when written in C), and even ignoring those it's too easy to have interoperability bugs. But when you can have codecs generated by a tool, those problems go away.
As well, it's just really convenient to have less make-work code to write to get to the fun parts of your application!
Upvotes: 0
Reputation: 10008
ASN.1 is not a language, the acronym stands for Abstract Syntax Notation.
ASN.1 is a set of norms aiming at removing all ambiguity between 2 systems that want to talk to each other.
First, you describe what is going to be transfered (transfer syntax). In you example: a rocket that has a range, a name, etc ...
Then, you decide how things are going to be sent (encoding rules).
Because you show a Json value (which is human readable) you can think that the value explains itself.
But if you take binary encoding rules (which was the essence of ASN.1) you realize quickly that you absolutely need to know the transfer syntax (what you call interface) to be able to decode a value.
Some binary encoding rules (like BER, DER, CER) can give the impression you can work with them without knowing the specifications because they follow the Tag/Length/Value pattern ... if you know how to decode a tag and a length, you can do a bare minimum
But, when you need to work with packed encoding rules (PER) you are completely helpless without the specification ... and good tools.
Upvotes: 1