Secsh public key file format draft

A key file is a text file, containing a sequence of lines. Implementations may generate files using which ever line termination convention is most convenient 4. A line that is not a continuation line that has no ':' in it is assumed to be the first line of the base 64 encoded body Section 8 J. Existing implementations may not correctly handle unrecognized fields. Subject Header This field currently is used to store the login-name that the key was generated under. During a transition period, implementations SHOULD generate key file headers that contain only a subject field followed by a comment field.

Subject Header This field currently is used to store the login-name that the key was generated under. For example: Subject: user 7. Comment Header Contain a user specified comment which will be displayed when using the key. It is suggested that this field default to user hostname for the user and machine used to generate the key.

For example: Comment: user example. Compliant implementations MUST function correctly if the quotation marks are omitted. Implementations MAY include the quotation marks. If the first and last characters of the Header-value are matching quotation marks, implementations SHOULD remove them before using the value.

New Headers Headers with header-tags beginning with "x-" are considered experimental, and may be used without IETF consensus. All other headers are reserved for use only by IETF consensus. Examples The following are some example public key files that are compliant note that the examples all wrap before 72 bytes to meet ietf document requirements; however, they are still compliant. Since public keys tend to be very large, it is difficult for a human to verify an entire host key.

Even with a PKI in place, it is useful to have a standard for exchanging short fingerprints of public keys. This section formally describes the method of generating public key fingerprints that is in common use in the SSH community.

The fingerprint of a public key consists of the output of the MD5 message-digest algorithm [ RFC ]. The input to the algorithm is the public-key data as specified by [ RFC ]. This is the same data that is base64 encoded to form the body of the public-key file. 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. Existing implementations may not correctly handle unrecognized fields.

For example: Subject: user 3. It is suggested that this field default to user hostname for the user and machine used to generate the key. For example: Comment: user mycompany. Compliant implementations MUST function correctly if the quotes are omitted.

During an interim period implementations MAY include the quotes.