tasn1 0.0.2

Deimos-like binding to GNU Libtasn1, a library for Abstract Syntax Notation One (ASN.1) and Distinguished Encoding Rules (DER) manipulation.

To use this package, run the following command in your project's root directory:

Build Status


Twofold binding to GNU Libtasn1, a library for Abstract Syntax Notation One (ASN.1) and Distinguished Encoding Rules (DER) manipulation.

subPackage 'deimos': The "import-only" C header's declarations.
subPackage 'wrapper': 'deimos' + some 'D-friendly' stuff (overloaded functions and unittests).

Binds to Libtasn1 source code version 4.13, released 2018-01-16.


Example: cd examples && chmod +x CertificateExample.d && ./CertificateExample.d

Sadly the cited manual isn't as good as it should be for a quick start, thus some notes here:

Usage of libtasn1 is based on having the ASN1 module *.asn of the topic interested in (e.g. pkix.asn in examples), or constructing that first. Classes, parametrized types are not supported, but may be worked around by 'unrolling'.

Given any .asn, these 2 interesting questions are solved by libtasn1: Further given DER-endoded data 'ubyte[] der' which are known to be the encoding of "something defined in ASN1 module .asn": Which are the concrete field values of that "something"? And conversely, how does that "something" with assumed changed field values translate back to a new 'ubyte[] der'?

How does libtasn1 solve that, while not being an asn1 compiler? Well it constructs it's proprietary representation of ASN1 module *.asn; for brevity I'll call that IRdef (tree-like Intermediate Representation of definitions). IRdef may be produced either during each app invocation on the fly by function 'asn1parser2tree' or once in a preprocessing step by function 'asn1parser2array' followed in each app invocation by calling function 'asn1_array2tree'.

I didn't do benchmarks concerning thes 2 options (just using asn1parser2tree for now), but it's assumed that the other option which involves preprocessing will have performance benefits, at least it avoids asn file processing: Use libtasn1 utility 'asn1Parser' which internally employs function 'asn1parser2array' and generates a file based pre-IRdef, translate that from C to D to be imported later (containing const(asn1staticnode)[] array) and using function 'asn1array2tree'. That's what was done for the example CertificateExample.d. Function 'asn1parser2array' doesn't make sense in a D-binding and got excluded.

asn1_node is the data type of IRdef; the manual always refers to that as 'definitions' and that's exactly what IRdef is for: Only for describing the data stucture(s), their data types, optional or not etc.: It's NOT about concrete values.

The next (I call it IRconcrete) may be confusing, as it has type asn1_node too: It's called 'structure' throughout the manual and denotes something like IRdef or a specific section of IRdef filled with concrete values for the fields.

Keeping asn1node IRdef strictly separated in mind from asn1node IRconcrete is the key point in better understanding the manual.

In order to emphasize that, I changed parameter names in the wrapper binding where required for unambiguity.

The link between IRdef and IRconcrete is this: Create an empty/default IRconcrete from IRdef with function 'asn1createelement' and then optionally fill IRconcrete with values from a 'ubyte[] der' with function 'asn1derdecoding'. Now from IRconcrete values may be read by function asn1readvalue or written to by asn1writevalue. Writing DER-encoded data is as easy as calling 'function asn1dercoding' with an IRconcrete parameter and sufficiently sized preallocated memory for receiving DER-data.

  • Carsten Blüggel
Sub packages:
tasn1:deimos, tasn1:wrapper
0.0.7 2019-Jul-22
0.0.6 2019-Jun-27
0.0.5 2018-Jun-16
0.0.4 2018-Jun-15
0.0.3 2018-Jun-13
Show all 8 versions
Download Stats:
  • 0 downloads today

  • 0 downloads this week

  • 1 downloads this month

  • 12 downloads total

Short URL: