[standards-jig] UPDATED: JEP-0078 (Non-SASL Authentication)

Jacek Konieczny jajcus at bnet.pl
Sat Jun 14 13:40:51 UTC 2003

On Fri, Jun 13, 2003 at 12:33:40PM -0500, Peter Saint-Andre wrote:
> On Fri, Jun 13, 2003 at 09:21:21AM +0200, Jacek Konieczny wrote:
> > Plain text passwords are regular CDATA in the XML stream, so it is
> > Unicode encoded in stream encoding (which may be UTF-8 or UTF-16). No
> > clarification is needed, and the sentence you wrote is wrong for UTF-16
> > encoded streams.
> True, it should just say you encode it according to the encoding of the
> stream (which could be UTF-8 or UTF-16).

No. It is just a string, so nothing extra should be said. We don't have
to say, that message body is encoded UTF-8 or UTF-16, we dont have to
say, that JID is encoded UTF-8, or UTF-16 (only that it is made of
Unicode characters) and we don't need to say, that the password is
encoded in UTF-8 or UTF-16.

> >    The value of the <digest/> element MUST be computed according to the following
> >    algorithm:
> > 
> >     1. Concatenate the Stream ID received from the server with the password.
> >     2. Hash the concatenated string according to the SHA1 algorithm.
> >     3. Ensure that the hash output is in hexidecimal format, not binary or base64.
> >     4. Convert the hash output to all lowercase characters.
> > 
> > This is a place where clarification is needed. Digest is computed from sequence of bytes,
> > so the encoding used should be known. Maybe point 1. should read:
> >     
> >     1. Concatenate the Stream ID received from the server with the password, both
> >        encoded as UTF-8.
> Same as above, could be UTF-8 or UTF-16.

No. The stream ID may come encoded UTF-8 or UTF-16 in the stream, but
the password may be stored by server or client in any encoding. It is
the concatenated string used for hash generation where always the same
encoding should be used. UTF-8 seems the best choice so it should be
specified in the specification.


More information about the Standards mailing list