Re: New drafts

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi,

On Thu, 28 Oct 2004, der Mouse wrote:

> Good to see all the new drafts.

Sorry for the delay.  I'll pick up the pace.


>
> In architecture-17, I see new text
>
> 	It should be noted that these names resemble [RFC0822] email
> 	addresses.  This is purely coincidental and actually has
> 	nothing to do with [RFC0822].
>
> RFC 822 is long obsolete; shouldn't that refer to 2822?  (Similar
> remarks apply to assignednumbers-07 4.6.1.)

I was going from the IESG comments and the brief discussion we had on the
mailing list.  Does anyone disagree that we should be referencing RFC
2822?


>
> I also see
>
> 	(commonly known as the Rogaway attack
> 	[ROGAWAY],[DAI][BELLARE,KOHNO,NAMPREMPRE],) to work,
>
> s/,)/)/ surely?

I just put that in there to see who was reading the drafts.  ;)
..just kidding.  Good catch, I'll fix that.


>
> In assignednumbers-07, 4.2.3, what about reason codes from ffffffea
> through ffffffef?  Similar remarks apply to 4.3.3 and 4.4.3.

My apologies for that.  I was distracted by a side issue during the last
few weeks and hadn't realized that I had not completed my edits for that
issue.  The ranges are inconsistent throughout the documents and I will
correct that when the ID Editors start accepting new documents again.

Just to summarize the discussion, I am planning on the following:

=====
For SSH_MSG_CHANNEL_OPEN_FAILURE we will have

0x0000 0000 - 0xFDFF FFFF        IETF CONSENSUS
0xFE00 0000 - 0xFEFF FFFF        PRIVATE USE - channel-type specific
0xFF00 0000 - 0xFFFF FFFF        PRIVATE USE - (experimental stuff)

with accompanying notes about

- The range starting with 0xFE should be used when localized names are
used for opening a channel (e.g. SSH_MSG_CHANNEL_OPEN message with a
'channel type' of "secure-net-hearts%example.com@localhost").  Interoperability is
assumed by a "gentleman's agreement" that IF you accept the localized
channel open type THEN you will understand the failure 'reason code'
values associated with that localized name.  Also, the IANA assigned
'reason code' values are still valid even when opening a channel using a
localized name.

- No restrictions or suggestions for the range starting with 0xFF.  No
interoperability is expected for anything used here - it's for
experimentation.

=====
For SSH_MSG_DISCONNECT we will have

0x0000 0000 - 0xFDFF FFFF        IETF CONSENSUS
0xFE00 0000 - 0xFFFF FFFF        PRIVATE USE

=====
For SSH_MSG_CHANNEL_EXTENDED_DATA we will have

0x0000 0000 - 0xFDFF FFFF        IETF CONSENSUS
0xFE00 0000 - 0xFFFF FFFF        PRIVATE USE
=====



>
> userauth-22 contains (in the description of password authentication)
> more character set issues, similar to those raised by the recent
> discussion of filenames.

Was that the discussion with the subject line of "SFTP and unicode file
names..."?  I wasn't paying close attention to that.


> Built into this text is the assumption that a
> password is a sequence of characters; on most systems, it is actually a
> sequence of octets, with any conversion between them and characters
> left undefined.

Is that this paragraph:

   Note that the 'plaintext password' value is encoded in ISO-10646
   UTF-8.  It is up to the server how it interprets the password and
   validates it against the password database.  However, if the client
   reads the password in some other encoding (e.g., ISO 8859-1 - ISO
   Latin1), it MUST convert the password to ISO-10646 UTF-8 before
   transmitting, and the server MUST convert the password to the
   encoding used on that system for passwords.

If so, would anyone care to propose text as to how it can address this
issue?

Thanks,
Chris