Please see RFC 1700, the section on data notation. The most significant bit in a byte /octet or word is always bit 0. A collection of bytes representing a set of bits should number from 0 or 0x80 hex as a mask for the first byte.
While 1700 was obsoleted by the protocol registries, I believe this data notation remains the standard approach for numbering. Best to ask the IANA about this rather than writing something that breaks things. They will be responsible for managing the profile registry for the flags. Later, Mike On Sun, Mar 17, 2024 at 13:53 David Benjamin <david...@chromium.org> wrote: > Did this ever get resolved? I noticed that there was a draft-13 cut, but > the issue Jonathan pointed out was still there. > > Looking at Section 2 again, it's actually even goofier than the original > email suggests. Section 2 first says: > > > The FlagExtensions field contains 8 flags in each octet. The length of > the extension is the minimal length that allows it to encode all of the > present flags. Within each octet, the bits are packed such that the first > bit is the least significant bit and the eighth bit is the most significant. > > This is LSB first. Then there's an example, which is also LSB first: > > > For example, if we want to encode only flag number zero, the > FlagExtension field will be 1 octet long, that is encoded as follows: > > > > 00000001 > > So that's all consistent. But then the last paragraph of section 2 says: > > > Note that this document does not define any particular bits for this > string. That is left to the protocol documents such as the ones in the > examples from the previous section. Such documents will have to define > which bit to set to show support, and the order of the bits within the bit > string shall be enumerated in network order: bit zero is the high-order bit > of the first octet as the flags field is transmitted. > > This says it's MSB first for some reason. But this is not only > inconsistent, but also redundant with the text at the start of section 2. > It seems to me we could simply delete the redundant text and move on: > > > Note that this document does not define any particular bits for this > string. That is left to the protocol documents such as the ones in the > examples from the previous section. Such documents will have to define > which bit to set to show support. > > David > > On Wed, Sep 27, 2023, 17:50 David Benjamin <david...@chromium.org> wrote: > >> Nice catch! I agree those don't match. I think bit zero should be the >> least-significant bit. That is, we should leave the examples as-is and then >> fix the specification text. >> >> Ordering bits MSB first doesn't make much sense. Unlike bytes, there is >> no inherent order to bits in memory, so the most natural order is the power >> of two represented by the bit. Put another way, everyone accesses bit N by >> ANDing with 1 << N and that's least-significant bits first. I can think of >> a couple systems (DER, GCM) that chose to order bits most-significant first >> and both have caused endless confusion and problems. (It's particularly bad >> for GCM which is actually representing a polynomial, but then messed up the >> order. Let's not repeat this blunder.) >> >> On Fri, Sep 15, 2023 at 1:37 PM Jonathan Hoyland < >> jonathan.hoyl...@gmail.com> wrote: >> >>> Hi TLSWG, >>> >>> I'm working on implementing the TLS Flags extension >>> <https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-12>, and >>> I just wanted to clarify a potential ambiguity in the spec. >>> >>> In Section 2 the spec says: >>> Such documents will have to define which bit to set to show support, and >>> the order of the bits within the bit string shall be enumerated in network >>> order: bit zero is the high-order bit of the first octet as the flags field >>> is transmitted. >>> >>> And also gives the example for encoding bit zero: >>> For example, if we want to encode only flag number zero, the >>> FlagExtension field will be 1 octet long, that is encoded as follows: >>> >>> 00000001 >>> >>> In which it seems that the low-order bit of the first octet represents zero. >>> >>> I have no preference either way, but when transmitted on the wire, should >>> flag 0 be transmitted as >>> >>> 0x01 or 0x80? >>> >>> Regards, >>> >>> Jonathan >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
