Skip to content

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

@zhouxt1

Description

@zhouxt1

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/codecRelated to a new or existing ASN.1 codec.help wantedExtra attention is neededkind/bugSomething isn't working

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions