Undeclared tags in the input to an ASN.1 BER decoder

Question

I have a specification for an ASN.1 syntax that I wish to modify by adding some fields. If I create an encoded string using BER with the new fields and then attempt to decode that string using a decoder that doesn't know about these additional fields, what should the result be? Will the decoding fail because there are fields that the decoder doesn't recognize? Will the decoder decode only the fields it can recognize and completely ignore ones it doesn't? Is this completely a decoder-implementation issue so either result is possible, depending upon on how the decoder is implemented?

Right now, I'm using an open source ASN.1 compiler/decoder and it seems to be failing entirely but I'm not sure if this is because of the implementation or because the ASN.1 rules dictate that kind of result?

Answer 1

This will all depend on the specification and the implementation. In short - there's no way to tell. and it's up to the implementation. Some specification for any given protocol/format utilizing asn.1 will explicitly state that unknown elements are to be ignored, in which case the decoding should not fail.

More common though, decoders will reject any input that does not strictly conform to the ASN.1 syntax it is supposed to be decoding.

Answer 2

It most certainly does not depend upon implementation. That is, if different implementations are handling it differently, one of them is doing it incorrectly. If you go to decode unknown fields using a decoder that doesn't expect unknown fields, the decoding should fail. It will not skip over unknown fields.

There is, however, a way to provide for additional fields even before they are known. It is to employ the extension marker ("..."). Let's say that we develop various versions of an ASN.1 specification. Let's call them V1, V2, V3, etc. V1 is the original specification, but we understand at the time we design V1 that it's likely we'll have to modify it at some point. To allow this, instead of something like

Z ::= SEQUENCE { a INTEGER,
                 b OCTET STRING,
                 c Message1
}

we would declare Z to be extensible like this

Z ::= SEQUENCE { a INTEGER,
                 b OCTET STRING,
                 c Message1,
                 ...
}

The extension marker says that, following c, there might be more fields which are as yet unknown. The decoder should treat messages containing such fields, as long as they follow c, as valid. The decoder would not be able to decode them since it doesn't know what they should be, but it knows that they are permissible.

Let's say that we update V1 to V2 by inserting two new fields somewhat like this

Z ::= SEQUENCE { a INTEGER,            -- V1
                 b OCTET STRING,       -- V1
                 c Message1,           -- V1
                 ...,
             [[  d PrintableString,    -- V2
                 e BOOLEAN          ]] -- V2
}

In this case, the V1 version can interoperate with the V2 version. The V1 encoder would not include d or e, while the V2 encoder would include them. From the decoder's viewpoint, the V1 decoder would accept (but not decode) d and e, while the V2 decoder would decode d and e if they are found. So a V1 decoder would accept both V1 and V2 encodings, ignoring d and e whenever they are found; a V2 decoder would also accept both V1 and V2 encodings, noting that a V1 encoding would not include d or e, but it remains valid.

We can continue this through additional versions, for example,

Z ::= SEQUENCE { a INTEGER,            -- V1
                 b OCTET STRING,       -- V1
                 c Message1,           -- V1
                 ...,
             [[  d PrintableString,    -- V2
                 e BOOLEAN         ]], -- V2
             [[  f PrintableString,    -- V3
                 g ExtensionMessage]]  -- V3
}

where V1, V2, and V3 can all interoperate.

Note, however, that since we are dealing with a SEQUENCE, the order must be preserved. You could not have e without d, nor g without d, e, and f.

The conclusion is therefore that if your type definition includes extension markers, you may add new fields, but if it does not, you may not.