Received changes through RFC Editor sync (changed abstract to 'This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell (SSH) implementations.

In addition, this document defines a standard textual representation for SSH public key fingerprints. This memo provides information for the Internet community.')

IANA Follow-up Comments:
With the new version, IANA understands a new registry to be created.  The IANA Considerations section still needs more descriptive information for this new registry as well as registration procedure rules.

[Ballot discuss]
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.

[Ballot 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".

  Section 4 says:
  >
  > The fingerprint of a public key consists of the output of the MD5
  > message-digest algorithm [RFC1321].  The input to the algorithm is
  > the public key blob as described in [I-D.ietf-secsh-transport].
  >
  and, [I-D.ietf-secsh-transport], section 6.6, says:
  >
  > The key blobs in this protocol MAY contain certificates in
  > addition to keys.
  >
  [I-D.ietf-secsh-transport] also refers to certificate blobs as
  separate from key blobs.  I believe it would be valuable to clarify
  whether the input includes the certificate or public key format
  identifier, or just includes key/certificate data.

  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 ...

[Ballot comment]
It's not clear to the casual reader that understanding the referred section 6.6 of secsh-transport requires understanding section 5 of secsh-arch.  If someone is just trying to implement the public key format and starts with publickeyfile, they will just see the relatively opaque "string", "mpint", etc. and not understand what those translate to in the actual file format.

[Ballot discuss]
The document says:

  The fingerprint of a public key consists of the output of the MD5
  message-digest algorithm [RFC1321].  The input to the algorithm is
  the public key blob as described in [I-D.ietf-secsh-transport].  The
  output of the algorithm is presented to the user as a sequence of 16
  octets printed as hexadecimal with lowercase letters and separated by
  colons.

The referenced ID says in section 6.6:

The key blobs in this protocol MAY contain certificates in addition to keys.

The referenced ID also, however, refers to certificate blobs as separate from
key blobs.  I believe it would be valuable to clarify whether the input includes
the certificate or public key format identifier, or just includes key/certificate data.

[Ballot 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".
 
  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 ...

[Ballot comment]
Joel Halpern noted in his Gen-ART review:

...given that it identifies two header names, and calls for IETF consensus for creating more, if this were a PS it would seem to require an IANA registry.

[Ballot discuss]
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.

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

Yes; no concerns.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is strong consensus to publish.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes.

There is one marginal nit:  Strings of the general form "<verbed> by
me@myhost" appear in comments in two of the examples; if the IESG
believes that this should be changed to an example.com domain, please
issue an RFC editor note to this effect; the exact string used here is
not critical to the specification.

  1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

Yes; the one ID reference is to a document in the RFC Editor queue.