This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

ASN.1 Tag Encoding Problem

1

Hello,

I have an application that uses ASN.1 ber to encode its data to transmit. One particular field encodes an OCTET STRING, and uses an implicit application tag. The hex bytes are these:

5F 01 04 .. .. .. ..

Where 0x5F01 is the tag and 0x04 the length. This encodes the APPLICATION type, with a tag number of 1. However, an APPLICATION type with tag number of 1 should (AFAIK) encodes as 0x41. I.e. this data file is encoding the tag number 1 in a high-tag-number form I thought was reserved for tag numbers of >30.

Is this a violation of ASN.1 standard?

I'm trying to write the ASN.1 syntax to describe this data, and so far have this:

version [APPLICATION 1] IMPLICIT OCTET STRING SIZE(4)

but this will always produce 0x41 as the tag. I need 0x5F01. Is there any modifier I can use to force high-tag-number form? Unfortunately, I have no control over the file data format.

Thanks for any help

Regards Rob Smith

asked 26 Apr '12, 02:38

salukibob's gravatar image

salukibob
21114
accept rate: 0%


2 Answers:

1

The tag 5F01 is [APPLICATION 1] but should be encoded in one octet instead of 2 since the value is between zero and 30 (inclusive) as indicated in X.690 clause 8.1.2.2. Note that some tools (such as the one from OSS Nokalva - www.oss.com) have a runtime flag for relaxing the strict rule checking thus allowing you to decode messages with tags like this that deviate slightly from the specified rules.

If you are able to have the encoder that generated those encodings corrected, that would be ideal, but if not, you could consider an ASN.1 tool such as the one from OSS Nokalva that is able to handle this kind of deviation from the strict ASN.1 rules.

answered 26 Apr '12, 11:23

Paul's gravatar image

Paul
723
accept rate: 33%

edited 26 Apr '12, 11:27

1

Although the encoding is correct, X.690 clause 8.1.2.2 says "the identifier octets shall comprise of a single octet..." so the encoder breaks that rule.

answered 26 Apr '12, 07:40

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

I did suspect that the encoder was breaking the rules slightly. Unfortunately I have no control over its output.

Luckily the decoder I am using accepts it, so must not enforce the X.690 rules quite so strictly. I do however need to re-encode data back into this format, so I was hoping that the basic ASN.1 syntax would have a modifier to allow this. Nevermind. Looks like an ugly hack will be necessary!

Thanks for your comments.

(27 Apr '12, 03:53) salukibob