Re: New version of TLS + IMAP/POP/ACAP draft

On Mon, 23 Nov 1998, John Gardiner Myers wrote:
> Chris Newman wrote:
> > So the password itself is a sequence of non-zero octets, but if the
> > password is character-based, then it's UTF-8.  Do you still object to the
> > change?
> 
> Yes.  Who ever heard of a password that wasn't character-based?

If I only used one physically secure client machine and I used the "save
password to disk" option which is very common, then I'd want to use a
random key instead of a password.

> This change reduces interoperability by giving an excuse for clients to
> send and servers to only accept unlabeled national character sets in the
> password field.

What about the transition problem?  There are people out there with
passwords using various national character sets.  If the password is
fixed at UTF-8 only on the wire, then they're stuck.  If clients permit
arbitrary binary, then they can use the hex version (or a binary file
version) of their old password until they change it.  I'm also
uncomfortable putting any restrictions on password content that aren't
absolutely necessary -- the more keyspace the better.

We can discuss this further at the IETF.

		- Chris