Finally. We're almost at parity for the template compiler.
Now we have a build option to use templating:
`./configure --enable-asn1-templating`
Tests fail if you build `rfc2459.asn1` with `--template`.
TBD: Figure out what differences remain between the two compilers, and
fix the templating compiler accordingly, adding tests along the
way.
Making IMPLICIT tags work in the templating compiler turned out to be a
simple fix: don't attempt to do anything clever about IMPLICIT tags in
the template generator in the compiler other than denoting them --
instead leave all the smarts about IMPLICIT tags to the interpreter.
This might be a very slight pessimization, but also a great
simplification.
The result is very elegant: when the interpreter finds an IMPLICIT
tag it then recurses to find the template for the body of the type
so-tagged, and evaluates that. Much more elegant than the code
generated by the non-template compiler, not least for not needing
any additional temporary memory allocation.
With this we finally have parity in basic testing of the template
compiler. Indeed, for IMPLICIT tags the template compiler and
interpreter might even be better because they support IMPLICIT tags
with BER lengths, whereas the non-template compiler doesn't (mostly
because `der_replace_tag()` needs to be changed to support it.
And, of course, the template compiler is simply superior in that it
produces smaller code and is *much* easier to work with because the
functions to interpret templates are small and simple. Which means we
can add more functions to deal with other encoding rules fairly
trivially. It should be possible to add all of these with very little
work, almost all of it localized to `lib/asn1/template.c`:
- PER Packed Encoding Rules [X.691]
- XER XML Encoding Rules [X.693]
- OER Octet Encoding Rules [X.696] (intended to replace PER)
- JER JSON Encoding Rules [X.697] (doubles as visual representation)
- GSER Generic String E.R.s [RFC3641] (a visual representation)
- XDR External Data Repr. [STD67][RFC4506]
(XDR is *not* an ASN.1 encoding rules specification, but it's a
*lot* like PER/OER but with 4-octet alignment, and is specified
for the syntax equivalent (XDR) of only a subset of ASN.1 syntax
and semantics.)
All we'd have to do is add variants of `_asn1_{length,encode,decode}()`
for each set of rules, then generate per-type stub functions that call
them (as we already do for DER).
We could then have an encoding rule transliteration program that takes a
`TypeName` and some representation of a value encoded by some encoding
rules, and outputs the same thing encoded by a different set of rules.
This would double as a pretty-printer and parser if we do add support
for JER and/or GSER. It would find the template for the given type
using `dlsym()` against some shared object (possibly `libasn1` itself).
Whereas generating source code for C (or whatever language) for
additional ERs requires much more work. Plus, templates are much
smaller, and the interpreter is tiny, which yields much smaller text and
much smaller CPU icache/dcache footprint, which yields better
performance in many cases.
As well, the template system should be much easier to port to other
languages. Though in the cases of, e.g., Rust, it would require use of
`unsafe` in the interpreter, so in fact the inverse might be true: that
it's easier to generate safe Rust code than to implement a template
interpreter in Rust. Similarly for Haskell, OCAML, etc. But wherever
the template interpreter is easy to implement, it's a huge win.
Note that implementing OER and PER using the templates as they are
currently would be a bit of a challenge, as the interpreter would have
to first do a pass of each SEQUENCE/SET to determine the size and
layout of the OER/PER sequence/set preamble by counting the number of
OPTIONAL/DEFAULT members, BOOLEAN members, and extensibility markers
with extensions present. We could always generate more entries to
encode precomputed preamble metadata. We would also need to add a
template entry type for extensibility markers, which currently we do
not.
This helped find a bug fixed in the preceding commit.
This also depends on the earlier fixes to IMPLICT tagging support, thus
implementing a test of that using a test vector from a standard.
In preparation for adding support for TPM attestations as an authentication
method in bx509d for a host trust bootstrap mechanism based on TPMs and their
endorsement keys and endorsement key certificates.
The plan is to add support to libhx509 and hxtool for PermanentIdentifier
(RFC4043) and HardwareModuleName (RFC4108) SANs, and then to add a query
parameter to bx509d for passing an attestation and a proof-of-possession
(either CMS or CSR), and add an authorizer plugin call for authorizing a device
manufacturer and serial number to hostname. Support for TPMs w/o endorsement
key certificates should also be possible based on a digest of the endorsement
key as the "serial number".
This commit adds functions for finding OIDs by symbolic name, meaning by
their symbolic names given in the ASN.1 modules that define them.
TBD:
- Resolve OIDs to names.
- Support a file in /etc for additional OID resolution.
- Add support for resolving OID arc names.
This will help us generate a directory of OIDs from all the ASN.1
modules in lib/asn1, which will then help us create an hx509 API for
resolving OIDs to/from friendly names, which ultimately will help us
make hxtool more user-friendly.
Modify the NTMakefile rules for tests so that a failed test does
not prevent subsequent tests from being executed.
Change-Id: I9595ad4a1527feae7c402241bf06ab21a0b76d4a
Add strtoll()/strtoull() to lib/roken
Add stdint.h to lib/roken (Windows only)
Add logic to detect whether to use lib/roken's stdint.h based on
Visual Studio version
Add include of stdint.h in generated ASN.1 code
Export missing symbols for 64-bit integers in lib/asn1
Export missing symbols for FAST
Add missing sources to kdc/NTMakefile
Fix issue in kuserok
Fix bsearch issues
Once DLLs and EXEs are built, they need to have their manifests
processed and signed. These steps are encapsulated in the EXEPREP and
DLLPREP Makefile macros. Use them instead of invoking each processing
macro individually.
In addition to building libasn1 as a DLL also add a build target
so that a list of exports can be generated and used to check with
the .def file whether any exports are being left out.
Be explicit about dependencies. A subsequent invocation of the NTMakefile
should correctly deduce dependencies for generated files instead of
assuming they are always out of date.
