How should I interpret the ASN.1 BER standard for REALs?

2.1k views Asked by At

I have been reading

  • X.690 "Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)"

In particular, §8.5.6.4 (d), concerning a binary encoding of REAL values with a variable length mantissa and exponent, reads as follows:

"if bits 2 to 1 are 11, then the second contents octet encodes the number of octets, X say, (as an unsigned binary number) used to encode the value of the exponent, and the third up to the (X plus 3)th (inclusive) contents octets encode the value of the exponent as a two's complement binary numberthe value of X shall be at least one;  the first nine bits of the transmitted exponent shall not be all zeros or all ones."

This is inconsistent, as the octets from "the third up to the (X plus 3)[rd]" is actually X+1 octets.

Is anyone able to clarify this section?

I assume that it should read either

"...then the second contents octet encodes one less than the number of octets, X say,..."

or

"...the third up to the (X plus 2)nd (inclusive) contents octets..."

And, is the minimum value of X really 1, or is it 0 meaning 1 octet?

ADDENDUM: If anyone can provide me with some test data of variously BER-encoded values (octet strings with their meanings) that would be helpful.

What I have so far is

  • 09 00 = 0 (zero)
  • 09 01 40 = +INF (infinity)
  • 09 01 41 = -INF
  • 09 08 03 2b 31 2e 30 65 2b 30 = "+1.0e+0" = 1.0 (exact decimal)
  • 09 05 80 fe 55 55 55 = 1398101.25 (binary, 0x555555 * 2^-2)

An example I'm not sure of is:

  • ? 09 06 83 00 fc 00 00 01 = 0.0625 (binary, 0x000001 * 2^-4) ?

Also, there seems to be no encoding defined for NaN (not a number).

2

There are 2 answers

0
this.josh On BEST ANSWER

I think this is just a question of indexing.

Content Octet #1 contains some stuff (encoding type, sign bit, base, scale factor, and exponent format).

If the exponent format is '11' then the next octet (Content Octet #2) contains a number X which represents the number of octets used to encode the value of the exponent. The third Content Octet contains part of the exponent value. The last Content Octet is x+3.

CO1(stuff) CO2(x) CO3(exponent value) ... CO[x+3]

The minimum value for x is 1. If x=1 then CO[x+3] = CO4, meaning that the minimum number of Content Octets for exponent value is two. The shortest representation of this form is

CO1 CO2 CO3 CO4

That would mean that '09 00' is not a valid encoding of section 8.5.6. As is '09 01 04', and '09 01 41'.

The PLUS-INFINITY and MINUS-INFINITY are encoded via the rules of section 8.5.8 which is not compatible with the rules of section 8.5.6.

encoding zero by the rules of section 8.5.6 goes like this

CO1:8  =  1      (Content Octet #1 bit 8)
CO1:7  =  x =  0 (Content Octet #1 bit 7 is dont care, but I'll use 0 for positive)
CO1:65 = 00      (Content Octet #1 bits 6 and 5 is 00 for base two)
CO1:43 =  x = 01 (Content Octet #1 bits 4 and 3 is scaling factor, so we don't care but I'll make it 01 for a value of one)
CO1:21 = 11      (Content Octet #1 bits 2 and 1 is the exponent format and '11' is the format in question)

so Content Octet #1 = 1000 0111 is 0x87

Content Octet #2 = 0x01 (since the smallest value of X is 1)

Content Octet #3 = 0x00

Content Octet #4 = 0x01

Content Octets #3 and #4 give an exponent value of 1

(zero * one) ^ one = zero

0
dedlfix On

NaN is defined in 8.5.9 next to Infinity and would be 09 01 42

This

09 06 83 00 fc 00 00 01 = 0.0625 (binary, 0x000001 * 2^-4)

is according to 8.5.7.4 d) not valid, CO2 (the X) "shall at least be one". But I also get your result when I ignore these constraints.

Better: 09 03 80 fc 01 = 0.0625 (binary, 0x01 * 2^-4)