A New ASN.1 API for Python

Original Article ↗ Hacker News Discussion ↗

Commercial vs Open Source ASN.1 Tooling

  • Several comments contrast OSS Nokalva’s commercial suite with open‑source tools (OpenSSL’s ASN.1, libtasn1, asn1c, Heimdal, etc.).
  • Commercial tools are valued for SLAs, timely bugfixes, robustness on huge specs (e.g., 3GPP), and full support for ASN.1 Value Notation and non‑crypto domains (telco, banking, biometrics).
  • Open source tools are seen as buggy or incomplete for complex specs and sometimes require patching; licenses of commercial compilers often block open‑source redistribution of generated code.
  • Others argue alternatives like Protobuf/FlatBuffers avoid ASN.1 entirely, which is why many choose them when they can.

Language Ecosystems and Specific Libraries

  • Erlang’s ASN.1 implementation is praised; Java users discuss now‑missing or archived tools and hunt for maintained compilers/libraries.
  • Java options (asn1bean, BeanIt, JAC ASN.1, older IBM tools) are mentioned, with mixed completeness and age.
  • JavaScript’s asn1js is cited as effective for browser‑based PKI.
  • Rust’s rasn library gets attention for broad codec support (BER/CER/DER/PER/APER/OER/COER/JER/XER), performance claims (especially OER), and an in‑progress compiler to generate Rust bindings from ASN.1.

Telecom, UPER, and 3GPP Challenges

  • UPER is described as significantly harder than DER and prevalent in telecom; commenters claim no open tool reliably handles 100% of real‑world UPER/3GPP specs.
  • Problems include massive, complex ASN.1 modules, tricky constraints, information object classes, and specs shipped as DOCX/PDF.
  • Commercial compilers are said to keep up with new 3GPP revisions faster than open tools, easing device and vendor interoperability.

ASN.1 vs Other Serialization Formats

  • Some urge new protocol designers to at least study ASN.1 instead of “reinventing” formats like Protobuf, which is characterized as a simpler, incompatible re‑take on TLV ideas.
  • Others push back, citing ASN.1’s perceived complexity and large “surface area” versus simpler IDLs.
  • Historical anecdotes describe why DER was chosen for PKI (determinism and canonical encoding) and compare ASN.1 to XDR, DCE/RPC, XML, JSON.

Canonical Encodings and Signing

  • One thread recounts signatures breaking after a MsgPack library change; switching to ASN.1 DER fixed this by providing canonical encodings.
  • Cryptography‑focused replies emphasize signing raw byte strings and treating encodings as untrusted; canonical formats like DER can be the chosen byte representation but are not strictly required if protocols are designed carefully.

Native Code vs Pure Python

  • Some miss “pure Python” libraries for portability and ease of installation; others argue modern wheels and tooling have reduced that pain.
  • There’s debate over Python’s pattern of pushing performance‑critical paths into native code (C, C++, Rust). Critics dislike needing multiple language skills; defenders say users don’t need to “master” the native language to benefit.
  • For cryptographic workloads, many see native code as unavoidable for speed and certification reasons.

Security, Parsers, and Specification Quality

  • Parser differential attacks on ASN.1 are noted as an under‑appreciated problem; a stronger, more consistent implementation is welcomed.
  • Discussion references ASN.1‑related CVEs, with the claim that most issues stem from poor implementations (e.g., OID handling, length calculations), not inherent flaws in ASN.1 itself.
  • Formal, machine‑readable specifications (ASN.1, extensibility markers, information object classes) are defended as reducing ambiguity and long‑term errors, at the cost of more sophisticated tooling.

Project Origins and Funding

  • The new Python ASN.1 work is funded via a Linux Foundation security initiative backed by major cloud vendors.
  • Commenters clarify the idea came from the Python cryptography ecosystem and was then pitched to the funding program, not imposed top‑down.
  • Some hope that, alongside this Rust‑backed approach, pure‑Python options will remain available for users who prioritize portability over performance.