Comment by wahern

This reminded me of ISO 7816-4 BER-TLV encodings, which uses the format defined in ISO/IEC 8825-1 (ASN.1 related spec). Length integer values of 0-127 are encoded in 1 byte. If the high bit is set, then the first 7 bits tell you the number of subsequent octets. So there's no offsetting involved, making it slightly less compact, but also dead simple.

EDIT: BUT, BER-TLV does permit overlong encodings. And I once found and reported a Yubikey 4 bug related to this. My source code comment for the workaround:

  -- The Yubikey 4 has an off-by-one bug which
  -- declares tag length of 255 (for the 0x53 outer
  -- tag of a certficate DO) when there are only 254
  -- bytes remaining in the reply. The reply is
  -- chained across two packets, but the off-by-one is
  -- probably related to the over-long encoded length
  -- (0x82 0x00 0xff instead of 0x81 0xff).
  --
  -- [snip packet captures]
  --
  -- Yubico's ykpiv_fetch_object function in ykpiv.c
  -- (confirmed 1.4.3-1.5.0) contains a read (memmove)
  -- overflow when the declared inner BER-TLV length
  -- (of the 0x53 tag) is longer than what was
  -- received over the wire. That makes Yubico's
  -- library oblivious to the issue. Relatedly, the
  -- set_length function has an off-by-one bug (length
  -- < 0xff instead of length <= 0xff) which produces
  -- an over-long encoded length. That doesn't by
  -- itself explain why the Yubikey 4 transmits a
  -- truncated logical reply unless the same code is
  -- being used.