ASN.1 Parsing/Serialization

[ponast]

This is an extension suggestion for opening up a new application field with respect to ASN.1 parsing/serializing.

ASN.1 is a serialization notation extensively used within the Telecom industry and by many security protocols defined by the IETF, for instance certificates, TLS and OCSP. Even if ASN.1 is an old and complex format it will stay relevant for many years as it is deeply embedded in major telecom and security infrastructure. It is also well known that many current ASN.1 parser implementations are buggy due to poor ad-hoc implementations but also due to the general complexity of ASN.1 itself. Therefore many security issues arise from faulty parsing of protocols and certificates. A simple search for asn at the CVE database reveals some 2350 issues as of today including issues with OpenSSL and major TLS implementations. The systematic and thorough protocol processing of ASN.1 by the Comms framework would eliminate the majority of the issues and also make writing parsers and serializes for ASN.1 much easier.

The ability to serialize ASN.1 would open up new opportunities for the Comms framework within an area where it would also excel; security. If additionally a simple XSLT transformer is created, the Comms (ASN.1) XML notation could be made to closely resemble that of the original by using ASN.1 XML tags rather than Comms tags.

It turns out that ASN.1 can be supported elegantly by the Comms framework except for a single showstopper; the ASN.1 length field, see ITU-T X.690, section 8.1.3, for a description. Due to this issue Comms ASN.1 XML schemas cannot be designed without adding major complexity, thus rendering the schemas hard understand an use.

As the ASN.1 length field is similar to the varint field already present in Comms it is suggested that an ASN.1 varint field is added to the Comms framework to enable ASN.1 parsing/serializing. As a further improvement, a simple XSLT transformer can be written to allow for writing ASN.1 XML schemas with original ASN.1 type tags rather than Comms type tags. This would enable XML schema writing in an XML notation that closely resembles that of the original ASN.1 notation and thus simplify schema validation.

A more general alternative to the dedicated ASN.1 varint might be a new kind of integer; Calculation int. The calculation int would apply user defined callbacks to determine parameters like length and value from a fields raw data. This way the ASN.1 length field could be modeled without adding ASN.1 specific fields to Comms. It would also be a more generic feature that might be useful elsewhere too and to simplify future extensions. Unfortunately I cannot judge if the solution is feasible given the architecture of the framework.

Given the above suggestions I tried out some possible ASN.1 lookalike schema outlines. RFC 6960 OCSP responder shows one possible syntax for the ASN.1 schema defined in RFC6960 and written in a Comms ASN.1 friendly format. The schema closely resembles the original ASN.1 notation and can be transformed to actual Comms XML with only trivial XSLT post-processing. Equivalence between the original ANS.1 format in RFC 6960 and the Comms (ASN.1) XML thus is easily verifiable visually, and the output is high quality ASN.1 parsers/serializers.

[arobenko]

Hi @ponast,
I think is my initial (MVP) support of the ASN.1 encodings is ready.

• v5.0 of the COMMS Library provides an ability to defined complex length fields, such as one used by the ASN.1
• v5.0 of the CommsDSL Specification provides new properties making relevant ASN.1 definitions easier.
• v5.0 of the commsdsl code generators implement new features defined in the new version of the CommsDSL Specification.
• Version 2022-08-13 of the tutorial added extra info about the new features.
• There is new cc.asn1.commsdsl project containing common ASN.1 definitions that can be reused in other projects requiring ASN.1 encodings.
• There is also new cc.x509.commsdsl which defines X.509 certificate structure using the available ASN.1 definitions.

It's up to you now to start using it and report any issues you find. Any improvement suggestions are welcome.

[ponast]

Hello @arobenko,

I have checked the release and can confidently state that this not is a MVP as it looks much to solid for that. I'm grateful for all the enhancements and look forward to try them out in the coming months. If the ASN1 module lives up to the quality I have come to expect from the Champion echo system, this new ASN1 tool set will be a strong contender among ASN1 codecs in the C++ domain. I am at least not aware of any other systematically designed ASN1 codec in the open source space.

I would suggest that you try to get your tool posted on this ITU ASN1 tools page: https://www.itu.int/en/ITU-T/asn1/Pages/Tools.aspx