The next major release of ASN1C will include updates for the 2021 revision of the ASN.1 standards. There are two noteworthy changes, discussed below.


X.697-2021 adds an encoder's option for BIT STRING and OCTET STRING types with a contents constraint. For example, if we have this type:

MyType ::= BIT STRING (CONTAINING SpecialType)

then a valid encoding for MyType takes this form:

{ "containing" : <JER for SpecialType> }

Previously, the contents constraint was irrelevant to the encoding, which would contain a hexadecimal representation of the BIT STRING or OCTET STRING, and not a JSON representation of the contained type.

ASN1C encoders will use the new encoder's option, and decoders will support both encoding options (the new and the old).

PER Padding for BIT STRING

X.691-2021 specifies that when encoding a BIT STRING in aligned PER, and the BIT STRING contains an ASN.1 encoding of some other type, the BIT STRING should be padded to a multiple of 8 bits.

By contrast, X.691-2015 did not have any requirement related to encoding a BIT STRING that contains an ASN.1 encoding of some other type.

X.691-2008 had the same requirement as 2021, but it also required the padding in the unaligned PER case, not just for aligned PER.

By default, ASN1C will now follow the 2021 rule (when a contents contstraint exists and -nocontaining was not used - the only time we can know the rule applies).

BUT I Don't Want The New Behavior?

You can choose which behavior you want. ASN1C will accept several new values for the -asnstd option, so you can choose your behavior by the specification year. The new values are:

  • x680-2021
  • x680-2015
  • x680-2008

(X.680 is the base specification for ASN.1.)