Assuming that you can encrypt everything assumes that you have a trusted public key to encrypt with. This would be the case if the protocol relied on SSL/TLS for example and we assumed that the user already has a previously trusted public key (e.g. a browser root store) which may or may not be an assumption we want to make for a roaming user. Without these assumptions, you can really only put the password through a one-way function since you would be indexing based on the userid.
In any case, I agree with Darren that it's more of a UI issue.
Mike J.
> -----Original Message-----
> From: Mike DeGraw-Bertsch [mailto:mbertsch@xxxxxxxxxxx]
> Sent: Wednesday, January 03, 2001 1:02 PM
> To: Darren Moffat
> Cc: ietf-sacred@xxxxxxx
> Subject: Re: Two more thoughts about credentials download protocols
>
>
> Perhaps I misunderstand the problem, but... While I agree
> that this is
> mostly a user interface issue, not a protocol issue, shouldn't the
> username transmission be encrypted anyway? It's my
> understanding that the
> protocol should be authentication-type agnostic, and therefor
> whatever is
> being sent should be encrypted as a whole, irrespective of if it's a
> username, password, private key, or whatever.
>
> -Mike Bertsch
>
> On Wed, 3 Jan 2001, Darren Moffat wrote:
>
> >
> >
> > > I'd be interested in what others think about the requirement and
> > > especially other ideas for (possibly partly) solving the problem.
> >
> > My thoughts on this are that this is a user interface
> design problem and really
> > isn't
> > anything to do with the protocol. If an application on the
> client side sends
> > the users
> > password across in the "username" part of the protcol then
> it is because the UI
> > of
> > that client was unable to present information in a
> sufficiently clear maner to
> > the user
> > to get the correct data.
> >
> > Thats not to say it isn't an interesting problem, I just
> don't think it is one
> > that can
> > be solved at a protocol layer.
> >
> > --
> > Darren J Moffat
> >
>
>