asn1: Allow Enum Like Object identifiers

[loewexy]

While working with the new asn1 implementation, i missed one specific feature that would make working with OIDs much simpler.

Currently there is just x509.ObjectIdentifier, which means i can build a sequence like the following:

@asn1.sequence
class Test:
  a: x509.ObjectIdentifier

However this has the disadvantage that for every object creation i have to build an object identifier from a string like so.

Test(a=x509.ObjectIdentifier('1.2.3.4'))

It is possible to create Constants for that or put them as Class Variables on a class however it would be much nicer from a type safety approach if we could have something like the following.

class Algorithm(OIDEnum):
  SHA_256 = '1.2.3.4'
  SHA_384 = '1.2.3.5'
  SHA_512 = '1.2.3.6'

@asn1.sequence
class Test:
  a: Algorithm

obj = Test(a=Algorithm.SHA_256)

obj.a is Algorithm.SHA_256

The Algorithm class should behave like a Enum with singleton members and stuff. This would make it explicitly clear that the field a has to be an OID that represents exactly one of the given options. Also the type checker could catch errors where invalid OIDs are provided. Also when we have parsed an object we can be sure that in the field a must be exactly one of the declared OIDs. So parsing should fail if an invalid OID is provided.

I really are not sure if making a separate OIDEnum is required or we could just use Enum and declare the values as x509.ObjectIdentifier, or automatically convert the string values of needed. Or a decorator instead of subclassing from OIDEnum would be better. But some sort of type safe integrated mapping of names to OIDs would be very helpful.

[alex]

It seems like maybe this generalizes to any enum: any enum whose values are ASN.1 types could plausibly be a) encoded as their value, b) decoded only when the bytes deserialize to one of the values.

I think we'd be interested in taking a look at this if someone put together an impelemtnation.

[loewexy]

Interesting Idea, i currently miss usecases for which this would help but certainly would not hurt. The only downside is that we would have to write:

class Algorithm(Enum):
  SHA_256 = x509.ObjectIdentifier('1.2.3.4')
  SHA_384 = x509.ObjectIdentifier('1.2.3.5')
  SHA_512 = x509.ObjectIdentifier('1.2.3.6')

Instead of

class Algorithm(OIDEnum):
  SHA_256 = '1.2.3.4'
  SHA_384 = '1.2.3.5'
  SHA_512 = '1.2.3.6'

However the added flexibility may be worth this downside. It could even simplify implementation.

My fear is that this must be implemented on the rust side, unfortunately I do not have any experience with rust.

[alex]

Pretty much any API we'll consider here will require you to construct OID objects.

[loewexy]

The specific OIDEnum could automatically convert the strings to OID objects when creating the singletons, but this is then very implicit. Not sure if i would still argue for my original idea. The generic solution seems superior and explicit.

[loewexy]

Okay I used Github Copilot to write a POC implementation of the Support for Arbitrary Enums and from a user perspective it also works as we discussed. However, since I do not have any knowledge in rust I am not able to evaluate the quality. But it seems it can be implemented with not too much effort.

[alex]

Triage with @reaperhulk: We'd be happy to take a PR for this. The API is probably something like:

@asn1.<something>
class MyEnum(enum.Enum):
  SHA_256 = x509.ObjectIdentifier('1.2.3.4')
  SHA_384 = x509.ObjectIdentifier('1.2.3.5')
  SHA_512 = x509.ObjectIdentifier('1.2.3.6')