rasn icon indicating copy to clipboard operation
rasn copied to clipboard

Non-Canonical encoding for Sequence Extension Group in ASN.1 UPER

Open zhouxt1 opened this issue 2 months ago • 1 comments

Hi, In X.691 Section 19.9, it says

If all components values of the "ExtensionAdditionGroup" are missing then, 
the "ExtensionAdditionGroup" shall be encoded as a missing extension addition 
(i.e., the corresponding bit in the bit-field described in 19.7 shall be set to 0).

However, if we look at the following example. The ASN.1 message definition is

S1 ::= SEQUENCE {
  b1 BOOLEAN,
  ...,
  [[ b2 BOOLEAN OPTIONAL ]],
  [[ b3 BOOLEAN OPTIONAL ]]
}

We can craft a message of type S1. { b1: true, ext_group_b2: Some(S1ExtGroupB2 { b2: None }), ext_group_b3: Some(S1ExtGroupB3 { b3: Some(true) }) }

Now, according to the standard, since all the components are missing for the first extension group (here, it just means the one component b2 is missing), we should not encode it. The correct encoding should be C0 A0 38 00 in hex. [ 1 | 1 | 0000001 | 01 | 00000001 | 1 | 1 | 000000 ] in binary.

However, rasn will encode this value to C0 E0 20 00 38 00. The difference rasn will still set the extension bit to 1, and encode the first extension. The bit-level breakdown is as follows. You can see the first bit field is set to 11, indicating both extension groups are present. [ 1 | 1 | 0000001 | 11 | 00000001 | 0 | 0000000 | 00000001 | 1 | 1 | 000000 | 00000 ].

Could you take a look at this non-compliance? Thanks.

zhouxt1 avatar Oct 20 '25 18:10 zhouxt1

Thank you for your issue! I don't have time at the moment to investigate but I would be able to review a pull request.

XAMPPRocky avatar Oct 20 '25 22:10 XAMPPRocky