JHildebrand at jabber.com
Fri Jun 13 12:08:07 CDT 2003
Sorry. A couple more quick nits.
"note that any non-ASCII characters MUST be encoded as UTF-8" but should
also probabl say, "with all appropriate XML escaping" or something. And
perhaps an "obviously" on the front. :)
In Example 6, it should be easier to tell that this is a digest of 3EE948B0
+ Calli0pe (which I assume it is without doing the math).
SHOULD the server return the bad query on error? MAY it? I think it SHOULD
NOT, since the client already knows what it sent. (Example 8,9,10)
In security considerations:
"Client implementations SHOULD NOT implement the plaintext mechanism, MUST
NOT make it the default mechanism, and MUST warn the user that the plaintext
mechanism is insecure."
Unless the channel is encrypted (using SSL or TLS) and the server is
authenticated with a certificate that is signed by a trusted CA.
> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter at jabber.org]
> Sent: Thursday, June 12, 2003 10:29 PM
> To: council at jabber.org
> On Wed, Jun 11, 2003 at 02:20:56PM -0600, Joe Hildebrand wrote:
> > 78: -1.
> > - There needs to be a digest example
> > - This phrase is unclear after example 3:
> > "(note that any non-ASCII characters MUST be properly escaped)."
> > Escaped how? &x0000;? Shouldn't UTF-8 be good enough?
> > - When can error 409 happen? There probably needs to be some
> > narrative on example 6.
> > - Under security considerations, there needs to be a
> reference to the
> > upgrade attack. If the client speaks plaintext but the server
> > doesn't, a man-in-the-middle can trick the client into
> revealing the
> > plaintext password, so clients SHOULD NOT implement
> plaintext, in particular.
> Added. Please reload and review, then let me know if the
> changes address your concerns:
> Council mailing list
> Council at jabber.org
More information about the Council