Redesign OID API for smaller code size

[gilles-peskine-arm]

The OID API (oid.h) and implementation (oid.c) are not good for code size for several reasons:

• OID lookup tables and conversion functions are included in the build regardless of whether they are actually needed (example). We guard individual strings by what they describe (e.g. an OID for SHA256 is only included if MBEDTLS_SHA256_C is defined), but we don't guard tables by how they're used (e.g. hash OIDs are included unconditionally, even if nothing consumes them, because it's a public API).
• Descriptive strings are includeed even though many applications don't care about them.
• The implementation uses lookup tables which are not very compact. The implementation uses functions which have some degree of inlining: there are separate functions for each parsing/formatting function and for each category.
• Numeric string conversion is included even though many applications don't care about it. Handled by https://github.com/Mbed-TLS/mbedtls/issues/9379.

The goal of this issue is to redesign the OID API and implementation with code size in mind, both to enable more compact code and to automatically include only what is needed. The general idea is:

• oid.h in TF-PSA-Crypto only exposes some generic lookup functions which are automatically enabled if some other part of the library needs them. If needed, X.509 will have additional conversion functions that crypto doesn't need.
• Each module will contain OID tables for what it needs. OID tables will be exposed as needed. OIDs consumed by crypto will be hosted by TF-PSA-Crypyo, and OIDs consumed only by X.509 will be in Mbed TLS's libmbedx509.

This is a design issue. The goal is a design specification. Once we have a design, there will be further tasks for implementation.

[davidhorstmann-arm]

This may be off-topic but it does relate to the design of the OID module. The way we currently define OIDs is something like:

#define MBEDTLS_OID_FOO "\x05\x05\x07"

Creating a null-terminated C string containing the bytes of the OID. Later, when we use it and need to set the OID's length field, we do:

oid.len = strlen(attr_descr->oid);

This is not ideal because OIDs are not guaranteed not to contain null bytes. In fact, we use one that has null bytes as test data for our conversion functions.

It would be better if we could find a way to define OIDs properly as arrays of arbitrary data with lengths.

[gilles-peskine-arm]

Later, when we use it and need to set the OID's length field, we do: (…)

That looks like a bug in X.509 code, please file it as a separate issue. It has nothing to do with the oid.h interface! It exposes OIDs through either MBEDTLS_OID_xxx string literals (for which you can use sizeof to get the length) or mbedtls_asn1_buf structures which contain a binary string and its length.