Hi guys,
first, thanks Felix for having fixed the tests I broke with the change I
did in the error message.
This morning I checked the reason why we have some failures in
protocol-kerberos. Stefan is right : some changes in the BitString class
are the reason for those breakage. Can we revert ? No : the BitString
class (and the Value.encode( BitString ) method ) are badly broken.
The BitString BER encoding requires that the number of unused bits are
present in the encoded value, something that is not correctly handled by
the original class. Typically, the order on which the bits are stored is
wrong in the previous BitString. BER encoding stipulate that the bits
are stored from left to right, bit 0 being the left most (this is purely
a convention).
So the value 48 (decimal) will be stored as 0000 1100 with the last two
0s being insignificant in BER.
One other thing is that the ending 0's can be omitted, as we can specify
the number of unused bits (which can be 0 or bits that don't count). For
instance, let's say we want to define 6 bits, and the value we have is 7
(0x07). This can be stored as : 0x03 0x02 0x02 0xE0 (0x03 = BitString
tag, 0x02 = length, number of bytes to encode the value, 0x02 = number
of unused bits, the last two, and 0xE0 = b'111000', which is 0x07 as the
bits are ordered from left to right).
or as : 0x03 0x03 0x05, 0xE0 (0x03 = BitString tag, 0x02 = length,
number of bytes to encode the value, 0x05 = number of unused bits, the
last five, as we have to insignificant bits, plus 3 bits set to 0, and
0xE = b'111', which is 0x07 as the bits are ordered from left to right)
In DER (used for Kerberos), the encoding is strict : if a BitString has
0s on the right, then they are not encoded. So if we have a field of
bits containing 32 bits, with only the bit 0 and 1 set, then the encoded
BitString will be :
0x03 0x02 0x06 0xC0
0x05 -> BitString tag
0x02 -> Number of bytes needed to encode the value
0x06 : 6 bits are unused in the last encoded byte
0xC0 : b'11', the current BitString value.
In BER, we could encode that in many ways :
0x03 0x02 0x06 0xC0 (as in DER)
or
0x03 0x02 0x00 0xC0 (no unused bits)
or
0x03 0x05 0x00 0xC0 0x00 0x00 0x00 (full 32 bits and no unused bits)
That's a bit insane :/
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
