Re-work OID handling

[sjaeckel]

Follow-up of OID handling of #309

[karel-m]

FYI: During my work on a support for encrypted pkcs8 ecc keys the OID stuff became even more complicated see https://github.com/libtom/libtomcrypt/blob/pr/ecc-asn1-part/src/pk/ecc/ecc_import_pkcs8.c

[sjaeckel]

I know that the current way the API is built up works pretty well, but there is one basic thing I don't like and that's the usage of unsigned long to represent an OID arc which would basically result in different en-/decoding capabilities of the implementation depending on the architecture if the code wouldn't trim it all down to 32bits...
This leads to the following questions:

Should we keep the basic type of the OID array as unsigned long or change it to ulong32 or ulong64 (and kill the trimming)?

Or do we even want 100% ASN.1 standard compatibility? Then we'd have to work with mp_int to represent an arc... where one implementation would then be to only work with strings/const char* on the API and use mp_int on the insides... or do we really have to convert OID's into their numerical representation? Why can't we even work with strings on the inside and do the conversion when doing the ASN.1 en/decoding on the fly via the math provider?

When reading http://oid-info.com/faq.htm#size-limitations I'd say it'd be sufficient to change the basic type to ulong64 and optionally provide something like der_encode_object_identifier_64() etc.
The biggest problem then being the break of user-code when processing flexi-decoded OID's ...

[Edit]: I've just received an answer from the oid-info.com admins:

The longest OID described in the OID repository is 34-arcs long but it is not clear whether it is a fake as it is strangely constructed (see https://docs.bmc.com/docs/display/Configipedia/List+of+discoverable+printers).

The highest arcs (in term of integer values) are Universally Unique IDentifiers (UUIDs) used as subsequent arcs of OID {joint-iso-itu-t(2) uuid(25)}.

I'll just leave this here...

[karel-m]

The more I fiddle with OID stuff the more I think that our API (public functions, public structs) shoudl use string representation e.g. "1.2345.67.8.9.10". I see the API breakage of flexi-decoded OID's but I still consider using strings more appropriate.

[sjaeckel]

Perfect, then I'll work in that direction!

Regarding the API breakage we could leave the old enum element LTC_ASN1_OBJECT_IDENTIFIER in there but don't use it anymore on output, but still process it on input? And then simply add a new LTC_ASN1_OID_STRING?
Or we replace the first by the latter?
It'd come together with a major ABI bump, so I tend to replace, but don't use the old name.

[karel-m]

I would:

• keep LTC_ASN1_OBJECT_IDENTIFIER (we use it quite a lot even in libtomcrypt itself)
• introduce LTC_ASN1_OID_STRING
• switch flexi-decode implementation to LTC_ASN1_OID_STRING

[sjaeckel]

I would:

• keep LTC_ASN1_OBJECT_IDENTIFIER (we use it quite a lot even in libtomcrypt itself)
• introduce LTC_ASN1_OID_STRING
• switch flexi-decode implementation to LTC_ASN1_OID_STRING

sounds good!

I'm thinking about defaulting to only decode to LTC_ASN1_OID_STRING and if s/o requests a LTC_ASN1_OBJECT_IDENTIFIER to convert.
The advantage would be:

• we are relying on one implementation of the decoding
• that implementation/conversion will then finally detect&report potential overflows of subidentifiers

I've also pushed a starting point to the branch rework/oid that removes oid_st. Should I already open a PR for that?

[karel-m]

Yes, I am for opening a new PR so that we see what Travis-CI thinks about the changes.

Ad: only decode to LTC_ASN1_OID_STRING 👍