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 |
2 Answers:
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 edited 26 Apr '12, 11:27 |
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 ♦ |
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.