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
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 188.8.131.52. 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.
Although the encoding is correct, X.690 clause 184.108.40.206 says "the identifier octets shall comprise of a single octet..." so the encoder breaks that rule.
answered 26 Apr '12, 07:40