Skip to main content

The Secure Shell (SSH) Public Key File Format
RFC 4716

Revision differences

Document history

Date Rev. By Action
2018-12-20
13 (System)
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 …
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.')
2015-10-14
13 (System) Notify list changed from sommerfeld@sun.com to (None)
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Scott Hollenbeck
2012-08-22
13 (System) post-migration administrative database adjustment to the Yes position for Sam Hartman
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2012-08-22
13 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2006-11-16
13 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2006-11-16
13 Amy Vezza [Note]: 'RFC 4716' added by Amy Vezza
2006-11-14
13 (System) RFC published
2006-08-08
13 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2006-08-01
13 Amy Vezza IESG state changed to Approved-announcement sent
2006-08-01
13 Amy Vezza IESG has approved the document
2006-08-01
13 Amy Vezza Closed "Approve" ballot
2006-07-29
13 Sam Hartman State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Sam Hartman
2006-03-24
13 Sam Hartman State Changes to Approved-announcement to be sent::Point Raised - writeup needed from Approved-announcement to be sent by Sam Hartman
2006-03-24
13 Sam Hartman Status date has been changed to 2006-03-24 from
2006-03-24
13 Sam Hartman [Note]: 'Waiting for IANA confirmation.' added by Sam Hartman
2006-03-24
13 Sam Hartman State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Sam Hartman
2006-03-24
13 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to Yes from Discuss by Sam Hartman
2006-03-23
13 (System) New version available: draft-ietf-secsh-publickeyfile-13.txt
2006-03-03
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-03-03
12 (System) New version available: draft-ietf-secsh-publickeyfile-12.txt
2006-02-10
13 Sam Hartman State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Sam Hartman
2006-02-10
13 Sam Hartman [Ballot discuss]
IANA comments in tracker; new IANA section not clear.
2006-02-10
13 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to Discuss from Yes by Sam Hartman
2006-02-10
13 Michelle Cotton
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 …
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.
2006-01-30
13 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2006-01-26
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-01-26
11 (System) New version available: draft-ietf-secsh-publickeyfile-11.txt
2006-01-20
13 Sam Hartman State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Sam Hartman
2006-01-20
13 Sam Hartman The WG needs to submit a new draft.
2005-10-07
13 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Discuss by Scott Hollenbeck
2005-10-06
13 Russ Housley
[Ballot discuss]
Section 3.4 says:
  >
  > The body of a public key file consists of the public key blob as
  > …
[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.
2005-10-06
13 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-10-06
10 (System) New version available: draft-ietf-secsh-publickeyfile-10.txt
2005-09-30
13 (System) Removed from agenda for telechat - 2005-09-29
2005-09-29
13 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2005-09-29
13 Russ Housley
[Ballot discuss]
The introduction to this document is very lightweight.  Please expand
  it to provide some context.  At a minimum, this needs to say …
[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 ...
2005-09-29
13 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2005-09-29
13 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2005-09-29
13 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-09-29
13 Allison Mankin [Ballot comment]
Eyecatching typo:

  one it's 2nd-preimage resistance, not on it's collision-
  resistance.
2005-09-29
13 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-09-29
13 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Undefined by Bill Fenner
2005-09-29
13 Bill Fenner
[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 …
[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.
2005-09-29
13 Bill Fenner [Ballot Position Update] New position, Undefined, has been recorded for Bill Fenner by Bill Fenner
2005-09-28
13 Michelle Cotton IANA Comments:
As described in the IANA Considerations section, we understand this document to have NO IANA Actions.
2005-09-26
13 Ted Hardie
[Ballot discuss]
The document says:

  The fingerprint of a public key consists of the output of the MD5
  message-digest algorithm [RFC1321].  …
[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.
2005-09-26
13 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie
2005-09-26
13 Russ Housley
[Ballot discuss]
The introduction to this document is very lightweight.  Please expand
  it to provide some context.  At a minimum, this needs to say …
[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 ...
2005-09-26
13 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley
2005-09-26
13 Brian Carpenter
[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 …
[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.
2005-09-26
13 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-09-23
13 Scott Hollenbeck
[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 …
[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.
2005-09-23
13 Scott Hollenbeck [Ballot Position Update] New position, Discuss, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-09-20
13 Sam Hartman
  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this …
  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 " 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.
2005-09-20
13 Sam Hartman [Ballot Position Update] New position, Yes, has been recorded for Sam Hartman
2005-09-20
13 Sam Hartman Ballot has been issued by Sam Hartman
2005-09-20
13 Sam Hartman Created "Approve" ballot
2005-09-20
13 (System) Ballot writeup text was added
2005-09-20
13 (System) Last call text was added
2005-09-20
13 (System) Ballot approval text was added
2005-09-20
13 Sam Hartman Placed on agenda for telechat - 2005-09-29 by Sam Hartman
2005-09-20
13 Sam Hartman State Changes to IESG Evaluation from AD Evaluation by Sam Hartman
2005-09-19
13 Sam Hartman State Changes to AD Evaluation from Publication Requested by Sam Hartman
2005-08-23
13 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2005-08-22
09 (System) New version available: draft-ietf-secsh-publickeyfile-09.txt
2005-04-04
08 (System) New version available: draft-ietf-secsh-publickeyfile-08.txt
2005-03-23
07 (System) New version available: draft-ietf-secsh-publickeyfile-07.txt
2005-03-21
06 (System) New version available: draft-ietf-secsh-publickeyfile-06.txt
2004-04-06
05 (System) New version available: draft-ietf-secsh-publickeyfile-05.txt
2003-08-26
04 (System) New version available: draft-ietf-secsh-publickeyfile-04.txt
2002-10-17
03 (System) New version available: draft-ietf-secsh-publickeyfile-03.txt
2001-06-21
02 (System) New version available: draft-ietf-secsh-publickeyfile-02.txt
2001-03-05
01 (System) New version available: draft-ietf-secsh-publickeyfile-01.txt
2001-01-23
00 (System) New version available: draft-ietf-secsh-publickeyfile-00.txt