Subject: define string

From: Glenn McGrath <[email-masked]>
Date: Sat, 15 Feb 2003 01:52:55 +1100

Section 5.1 of draft-ietf-secsh-transport-15.txt describes the format of
the payload of binary packet used to negotiate the algorithms, namely

     byte      SSH_MSG_KEXINIT
     byte[16]  cookie (random bytes)
     string    kex_algorithms
     string    server_host_key_algorithms
     string    encryption_algorithms_client_to_server
     string    encryption_algorithms_server_to_client
     string    mac_algorithms_client_to_server
     string    mac_algorithms_server_to_client
     string    compression_algorithms_client_to_server
     string    compression_algorithms_server_to_client
     string    languages_client_to_server
     string    languages_server_to_client

I havent read this RFC before, nor have a played with the code of any
ssh software, when looking at these fields i just assumed string was a
sequence of printable characters terminated by a '\0'.

By trying to talk to openssh and lsh servers i worked out a string is

char string_length
char *string
char extra_terminators[3]

I understand why string_length is there, its can make it easier to
handle the string, but why are there three extra '\0' terminators ?

Irrespective of the reasoning i think the format of the string should be
documented somewhere, im sure im not the only person who has been caught
by this.

I thought maybe there was a RFC that defined standard types for all
RFC's, such as there is for standard terms (RECOMMENDS, SHOULD etc), i
searched but didnt find anything.

Thanks

Glenn

---

From: Simon Tatham <[email-masked]>
Date: Fri, 14 Feb 2003 15:00:40 +0000

Glenn McGrath  <[email-masked]> wrote:
> documented somewhere

It is. Look in draft-ietf-secsh-architecture-13.txt, which contains
general material which applies to more than one of the transport,
userauth and connect drafts:

string

      Arbitrary length binary string.  Strings are allowed to
      contain arbitrary binary data, including null characters and
      8-bit characters.  They are stored as a uint32 containing its
      length (number of bytes that follow) and zero (= empty string)
      or more bytes that are the value of the string.  Terminating
      null characters are not used.
		  
      Strings are also used to store text.  In that case, US-ASCII
      is used for internal names, and ISO-10646 UTF-8 for text that
      might be displayed to the user.  The terminating null
      character SHOULD NOT normally be stored in the string.

      For example, the US-ASCII string "testing" is represented as
      00 00 00 07 t e s t i n g.  The UTF8 mapping does not alter
      the encoding of US-ASCII characters.

In other words, your `three extra terminators' are actually part of
the 32-bit length field of the _next_ string.

Hope that helps,
Simon
-- 
Simon Tatham         "Thieves respect property; they only wish the property to
<[email-masked]>    be their own, that they may more properly respect it."