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]. The input … [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 "<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. |
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 |