Hi Conrad,
Thanks for the clarification. I somehow stumbled (or fumbled) onto this
conclusion independently as well, but now that I've got an expert
opinion from you, may I try to get this clarified a little more ?
Is the encoding mechanism able to handle integers that may not fit into
14-bit's (2 x 7-bit from 2 neighboring octets) ? In that case, what
would the encoding be like ?
For example, I need to encode an integer 'Z' in an arc, which is 16-bit
long...
( b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11 b12 b13 b14 b15 b16 )
2
Will it be encoded as:
01 b1 b2 b3 b4 b5 b6 b7
01 b8 b9 b10 b11 b12 b13 b14
00 b15 b16
??
If that's how it is, then does the text in X.690 look confusing (or not
leading to this conclusion) ?
Thanks & regards,
Banibrata Dutta
-----Original Message-----
From: Conrad Sigona [mailto:[EMAIL PROTECTED]
Sent: Monday, March 05, 2007 8:43 PM
To: Dutta, Banibrata (STSD)
Cc: [email protected]
Subject: Re: [Asn1] Confusion about OID BER encoding (again)
> About 10-11 months back I'd posted the question regarding BER encoding
> of OID's, and now I am back, since some doubts are.
>
> How do I decode the following octet string, using the explanation of
> the encoding rules as specified in X.690.
>
> 06 0c 2a 86 3a 00 89 61 33 01 00 01 00 01
>
> I'll write here, how far I manage to do it...
>
> Tag = 0x06
> Length = 0xc (12), count of folliowing value octets Value = { 2a =
> 1.2.
> 86 = 6.
> 3a = 58.
> 00 = 0.
> 89 = (10001001)2 ??? (I thought that the MSbit could be one, only for
> the terminal octet!!)
> 61 = (01100001)2 ? (.. so is this octet related to the previous one,
> the one above in this list ? if so, how ?)
> 33 = 51. ??
> 01 = 1. ??
> 00 = 0. ??
> 01 = 1. ??
> 00 = 0. ??
> 01 = 1. ??
> }
>
> I think this list doesn't permit HTML formatting, which is sad,
> because I'd colour coded the text to explain the issue in more clear
> terms. To me the problem is in the octet's with value 89 onwards...
> since it has the MSBit set. According to the explanation in X.690 &
> Olivier Dubuisson's books, the MSBit = 1, would occur only once ???
> (Or, that's what I understood).
The difficulty is that you are misinterpreting the octets with the high
order bit set. Please bear in mind that the nodes of an OID can be very
large numbers and so there needs to be a way to specify the length. One
could have, of course, designed it such that each node would be preceded
by a length field, but that's a lot of wasted bits.
Instead since the numbers tend to be small, the method chosen is one
where the high bit specifies whether (0) this is the last octet or (1)
more are coming. That is, only the least significant 7 bits of each
octet represent the value. The high bit, so to speak, specifies the
length. By way of example (you might find the breakouts easier to read
if you set this to some fixed font)
01 0xxx xxxx this is the final octet
x000 0001 value is 1
863A 1xxx xxxx xxxx xxxx another octet follows
xxxx xxxx 0xxx xxxx this is the final octet
x000 0110 x011 1010 these 14 bits specify the value (826)
If you squeeze out the x's and use hex representation, you'll have
00 0011 0011 1010 033A which is 826.
You can therefore, by examining the high-order bits, see that you have
the following nodes
2a 1.2
863a 826
00 0
8961 1249
33 51
01 1
00 0
01 1
00 0
01 1
=====================================================================
Conrad Sigona Voice Mail : 1-732-302-9669 x400
OSS Nokalva Fax : 1-614-388-4156
[EMAIL PROTECTED] My direct line : 1-315-845-1773
_______________________________________________
Asn1 mailing list
[email protected]
http://lists.asn1.org/mailman/listinfo/asn1
