DISCUSS comments on publickeyfile-09

[Bill Sommerfeld <sommerfeld%orchard.arlington.ma.us@localhost>]

(these were sent directly to the list but got tripped up on an overly
exuberant regexp in the spam filter.  my apologes for the delay in
getting these out to the list).

Note that there are a few other non-DISCUSS comments in the datatracker
which at first glance look like reasonable things to pick up if we
respin the draft.

						- Bill


To: ietf-ssh%netbsd.org@localhost
Subject: [Scott Hollenbeck] DISCUSS:
draft-ietf-secsh-publickeyfile-09.txt
From: Sam Hartman <hartmans-ietf%mit.edu@localhost>
Date: Fri, 23 Sep 2005 14:11:49 -0400
Message-ID: <tsl1x3ffyca.fsf%cz.mit.edu@localhost>

--=-=-=


You know, the draft might actually even mean bytes in this instance.
I'm trying to imagine what I'd do if I took this file to tops-20.

I think it is either bytes or characters, octet seems clearly wrong.

--=-=-=

From: "Scott Hollenbeck" <sah%428cobrajet.net@localhost>
To: "'Internet Engineering Steering Group'" <iesg%ietf.org@localhost>
Date: Fri, 23 Sep 2005 09:21:31 -0400
Message-ID: <courier.43340161.000061E5%mail.verisignlabs.com@localhost>

Section 3, second paragraph, and elsewhere: "MUST NOT be longer than 72
bytes".  "bytes" is an imprecise term.  Do they really mean "8-bit ASCII
characters", octets, or are 9-bit bytes as implemented on older hardware
architectures also acceptable?

Section 3.4 uses the term "characters" to describe a line length
limitation.
Consistency would be good.

-Scott-

--=-=-=--


To: ietf-ssh%netbsd.org@localhost
Subject: [Russ Housley] DISCUSS: draft-ietf-secsh-publickeyfile-09
From: Sam Hartman <hartmans-ietf%mit.edu@localhost>
Date: Tue, 27 Sep 2005 00:29:44 -0400
Message-ID: <tslll1jm8uf.fsf%cz.mit.edu@localhost>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="

--=-=-=


Another discuss.



--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

Date: Mon, 26 Sep 2005 16:33:03 -0400
To: iesg%ietf.org@localhost
From: Russ Housley <housley%vigilsec.com@localhost>
Subject: DISCUSS: draft-ietf-secsh-publickeyfile-09

SSH Public Key File Format (Informational)

DISCUSS

   The introduction to this document is very lightweight.  Please expand
   it to provide some context.  At a minimum, this needs to say that the
   document is about the SSH protocol and the role of public keys.  It
   is also desirable to cover the trust model, explaining why these
   files are very important.

   The introduction should be expanded to discuss fingerprints and how
   they are used in SSH.

   Section 3.4 says:
   >
   > The body of a public key file consists of the public key blob as
   > described in [I-D.ietf-secsh-transport], section 4.6, ...
   >
   There is no section 4.6 in the referenced document.  I assume that
   this should be a reference to section 6.6.

   The examples in section 3.6 do not seem to match the key blob
   description in [I-D.ietf-secsh-transport], section 6.6, which says:
   >
   > The key type MUST always be explicitly known (from algorithm
   > negotiation or some other source).  It is not normally included in
   > the key blob.
   >
   But in this context, it is needed.  This document should make this
   clear with a MUST statement.  Note that it is included in each of
   the examples.  I base64 decoded them and checked.

   In section 3.6, please change "me@myhost" to "me%example.com@localhost".

   The last paragraph of the security considerations needs to be
   expanded to provide a bit of context.  MD5 has some known weakness,
   but they are not a problem in this situation because ...




--=-=-=--