WG Chair Nits & start of WG Last Call: draft-ietf-secsh-publickeyfile-06.txt

[Bill Sommerfeld <sommerfeld%sun.com@localhost>]

On Mon, 2005-03-21 at 15:34, Internet-Drafts%ietf.org@localhost wrote:
> 	Title		: SSH Public Key File Format
> 	Author(s)	: J. Galbraith, R. Thayer
> 	Filename	: draft-ietf-secsh-publickeyfile-06.txt
> 	Pages		: 11
> 	Date		: 2005-3-21

I am starting an official WG Last Call on this document, for publication
as an Informational RFC.  This last call period expires on April 4th,
2005.

During this Last Call period, comments supporting publication are
appropriate, as are comments suggesting changes to the spec. 

This Last Call assumes that the following nits will be corrected in a
new revision submitted in the near future:

1) The draft references:

   [RFC2044]  Yergeau, F., "UTF-8, a Transformation Format of Unicode
              and ISO 10646", October 1996.

which was obsoleted by RFC2279, which was in turn obsoleted by RFC3629. 

2) as discussed on the WG list about a year ago, this format is (alas)
subtly different from the formats documented in rfc1113 and rfc1421 in
two ways:

  a) the BEGIN/END markers start/end with four dashes and a space rather
than five dashes.
since the center part of the markers are also different from other
PEM-type delimeters.

  b) no blank line between comment/header section and the start of the
base64-encoded key.

As there is running code using these formats I don't think it's
worthwhile to spec a migration path to 1421-style delimeters, but since
implementors may want to reuse existing PEM-format code here, we should
explicitly mention the deltas from RFC1421 and cite 1421 as an
informative reference.

Proposed edits:

 1) replace references to RFC2044 with references to RFC3629.

 2) insert a new subsection of section 3 titled "Differences with
RFC1421 PEM formats" containing the following text or equivalent:

Implemetors should take care to notice that while the format is
superficially similar to that specified by PEM [RFC1421] and PGP
[RFC1991], it is not identical; most notably:
 1) The other specifications use different BEGIN/END delimeters (five
dashes, no space rather than four dashes and a space).
 2) there is no blank line before the start of the base64-encoded
contents.

(end proposed edits)

							- Bill