This is our old Q&A Site. Please post any new questions and answers at


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:


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

accept rate: 0%

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 Note that some tools (such as the one from OSS Nokalva - 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.

permanent link

answered 26 Apr '12, 11:23

Paul's gravatar image

accept rate: 33%

edited 26 Apr '12, 11:27

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

permanent link

answered 26 Apr '12, 07:40

Jaap's gravatar image

Jaap ♦
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
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 26 Apr '12, 02:38

question was seen: 3,588 times

last updated: 27 Apr '12, 04:13

p​o​w​e​r​e​d by O​S​Q​A