Support for Canonical UPER or more strict UPER decoder

[zhouxt1]

The pycrate UPER decoder currently accepts several forms of non-canonical encodings. While this provides flexibility, it prevents users from using the library to validate strict protocol compliance. This feature request proposes adding an option to enforce canonical rules.

The following are specific cases where the decoder is currently lenient:

Unconstrained INTEGER Encoding

• Rule: Per ITU-T X.691 (11.3.6), an unconstrained integer must be encoded using the minimum number of octets.
• Observed Behavior: The decoder accepts integers with redundant leading octets (e.g., 0x02 0x00 0xFF for the value 255, instead of the canonical 0x01 0xFF).

Explicit Encoding of DEFAULT Values

• Rule: Per X.691 (19.5), the encoding for a component with a DEFAULT value must be absent if its value is the default for a simple type.
• Observed Behavior: The decoder accepts messages where a simple type's default value is explicitly encoded rather than omitted.

Empty Extension Groups

• Rule: Per X.691 (19.9), if an extension bit is set to 1 in the bitmap, but all components within the corresponding extension group are absent, the encoding is non-canonical. The extension bit should have been 0.
• Observed Behavior: The decoder accepts a message where an extension bit is 1 but the extension group is effectively empty.

Other things include alternative encodings for length determinant or issue #36. These behaviors allows the parser to accept alternative encodings that are not valid. While it might not have an immediate impact, it is worth noting it.

---

Possible Solution

To address these issues, I suppose pycrate can add strict or canonical flag to the decoder functions, which allows for a more strict or lenient decoding, based on the choice of the user.

[mitshell]

Thanks for your interest in pycrate.
Currently, the encoder supports most of the PER canonical encoding rules. The decoder, on the other side, has always been implemented to maintain the best interoperability possible. There is currently no such decoder options, to enforce canonical rules and eventually raise in case some rules are not honored.
I have personally no need for such enforcement in the decoding stage. But I'll be happy to review any PR on this matter.