riscv
Why ASN.1?
Is there some history behind why ASN.1 has been chosen? It just seems like a rather arbitrary and strange choice, given that ASN.1 has not been used in any similar capacity by platforms/firmware to describe features (e.g. on Arm, x86, etc)
Is the tooling sound? Do we have decent compilers, libraries? Is it easy enough to parse (single pass without consuming extra memory like Device Tree or complicated like ACPI AML?)? Do we have a good set of open source libraries that are embeddable?
Obviously the "human readable" nature of ASN.1 is a matter of taste, but I would imagine literally no one working on RISC-V systems (hardware or software) is familiar with it. So that's a steep climb already. Then consider that you're likely converting this to either straight Device Tree or Device Tree properties in ACPI. So... why not embrace Device Tree entirely for this purpose? It is lightweight, very flexible, trivial to parse, etc... and natively supported in OSes and firmware like u-boot, TianoCore UEFI, etc. The libraries are dual licensed and the spec is otherwise trivial even if you wanted to roll your own (and the tooling is super familiar to anyone).
Seconded. Picking ASN.1 over of one of the formats that we expect UD to be converted into deserves some explanation.
I didn't trace through the whole TG discussion but the genesis of the ASN.1 decision appears to be this message: https://lists.riscv.org/g/tech-config/topic/asn_1/81732549
A relevant thread recently popped up under https://lists.riscv.org/g/tech-config/topic/call_for_candidates/111912543. I'll quote it here:
"Ben Laurie" [email protected]:
Speaking as someone who has had to support ASN.1 parsing in the past, this seems like a terrible idea - it is very hard to get right and a common source of security problems.
"Tim Hutt" [email protected]
I second that. There are many vastly simpler and less error-prone options than ASN.1 today. CBOR is an obvious choice.
"Christian Herber" [email protected]
I believe i remarked that two years ago, but no one replied.
Different set of people 2 years ago, I think....
On Thu, Mar 27, 2025 at 12:27 AM Radim Krčmář @.***> wrote:
A relevant thread recently popped up under https://lists.riscv.org/g/tech-config/topic/call_for_candidates/111912543. I'll quote it here:
"Ben Laurie" @.***:
Speaking as someone who has had to support ASN.1 parsing in the past, this seems like a terrible idea - it is very hard to get right and a common source of security problems.
"Tim Hutt" @.***
I second that. There are many vastly simpler and less error-prone options than ASN.1 today. CBOR is an obvious choice.
"Christian Herber" @.***
I believe i remarked that two years ago, but no one replied.
— Reply to this email directly, view it on GitHub https://github.com/riscv/configuration-structure/issues/126#issuecomment-2756997021, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJUF5KMQEAZK2O5U2B32WOK3VAVCNFSM6AAAAABPZQ7M5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJWHE4TOMBSGE . You are receiving this because you are subscribed to this thread.Message ID: @.***> [image: radimkrcmar]radimkrcmar left a comment (riscv/configuration-structure#126) https://github.com/riscv/configuration-structure/issues/126#issuecomment-2756997021
A relevant thread recently popped up under https://lists.riscv.org/g/tech-config/topic/call_for_candidates/111912543. I'll quote it here:
"Ben Laurie" @.***:
Speaking as someone who has had to support ASN.1 parsing in the past, this seems like a terrible idea - it is very hard to get right and a common source of security problems.
"Tim Hutt" @.***
I second that. There are many vastly simpler and less error-prone options than ASN.1 today. CBOR is an obvious choice.
"Christian Herber" @.***
I believe i remarked that two years ago, but no one replied.
— Reply to this email directly, view it on GitHub https://github.com/riscv/configuration-structure/issues/126#issuecomment-2756997021, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJUF5KMQEAZK2O5U2B32WOK3VAVCNFSM6AAAAABPZQ7M5OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONJWHE4TOMBSGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
The history of this certainly goes back further than 2 years and probably is rooted in a discussion from 2021...
In my memory, the question posed by the (then) configuration-structure group was for a small, bit-accurate encoding that would also provide for tooling with schema support. The front-runner proposed by the group was a fork of protobuf (nanopb), which would have brought its own set of challenges. Back then, I had pointed out the x.69x standards to Tim as an industry-standard alternative to nanopb that provided both a specification language, an extensible schema, and various encodings (some very compact, such as uPER).
From what I can tell (from the repository and email history of the group), Tim et al. then proceeded to evaluate the technology and explore how compact the data representation obtained from different ways of describing the data structure could be. This was the state of the deliberations when Irma took over the group from Tim.
Given that ASN.1 is used in 4G, 5G, GlobalPlatform, SAE J2735, 802.11p, and many more: I wouldn't argue that it is a technology particularly prone to erroneous implementation (and I had my share of constructing and parsing DER-encoded messages for security-critical applications, involving HSMs and secure elements, in a previous life), although it certainly offers a learning curve due to the richness of the standards and how ASN.1 and the encoding rules layer on each other.
