Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

I jsut read over draft-ietf-secsh-publickeyfile-08.txt; herewith
comments.  Bare numbers flush left are section numbers.

3
   A key file is a text file, containing a sequence of lines.  Each line
   in the file MUST NOT be longer than 72 bytes excluding line
   termination characters.
3.1
   Implementations are REQUIRED to read files using any of the common
   line termination sequence, <CR>, <LF> or <CR><LF>.

I see problems here, both philosophical and practical.

A file containing a sequence of lines does not necessary have *any*
line termination sequence.  Across the OSes I've used, I've seen at
least three ways of storing a sequence of lines in a text file, only
one of which fits the termination-sequence model.  (One way is a
termination sequence; another way is a length attached to each line,
but returned by the interface not as in-band octets but rather as the
length of the record read; a third way is a record length attached to
the file, equal for all records in the file.)  Line termination
sequences make sense only for files that are conceptually sequences of
octets, rather than files that are conceptually sequences of lines
("records" is the usual word in filesystem docs I've seen).

If you want to provide a spec for encoding public keys as octet streams
containing sequences of lines delimited by line termination sequences,
that's fine, but that's (a) less useful (because it requires converting
between octet-stream representations and native representations for
filesystems that don't use line termination sequences) and (b) not what
publickeyfile-08 calls itself.

At various other places, I see wording such as "excluding line
termination characters" which I think needs an ", if any" attached.  Of
course, depending on how the line termination wording is resolved, this
may become a non-issue.

3.3
   The Header-tag MUST NOT be more than 64 bytes, and is
   case-insensitive.  The Header-value MUST NOT be more than 1024 bytes.
   Each line in the header MUST NOT be more than 72 bytes.

Since the Header-tag is explicitly declared case-insensitive, I'd
prefer to see the case-sensitivity of the Header-value mentioned, even
if only with wording like "...more than 1024 bytes, and, depending on
the Header-tag, may or may not be case-sensitive.".

3.3
   A line that is not a continuation line that has no ':' in it is the
   first line of the base 64 encoded body (See Section 3.4.)

s/base 64/base-64/ here?

3.3.1
No indication is given here what to do if the login name in question
does not exist or is not available.  Is the format unusable?  Should
Subject: be omitted?  Should whatever username is available be used?
Or something else?

3.3.2
   existing implementations fail if these quotation marks are omitted

There's an end-of-sentence . missing here.

3.3.2
   Implementations MAY include the quotation marks.  If the first and
   last characters of the Header-value are matching quotation marks,
   implementations SHOULD remove them before using the value.

"matching quotation marks" sounds as though there are other characters
than " that count as quotation marks.  I'd prefer to see this list
explicitly described, or else an indication that any character can
function as a quotation mark (or possibly any character except a
letter, or some such).

4
I'd like to see a specific public key quoted here together with its
fingerprint, for the same reason crypto specs include test vectors.

6
   intentionally or otherwise (e.g "Comment: Mary E.  Jones, 123 Main

s/E.  J/E. J/ surely?

6
   is for historical purposes, and the particular use made of it depends
   solely one it's 2nd-preimage resistance, not on it's

s/it's/its/g on the second of the quoted lines.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B