idnits 2.17.1 draft-ietf-secsh-publickeyfile-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 372. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 22, 2005) is 6794 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1321 -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Secure Shell Working Group J. Galbraith 3 Internet-Draft VanDyke Software 4 Expires: February 23, 2006 R. Thayer 5 The Tillerman Group 6 August 22, 2005 8 SSH Public Key File Format 9 draft-ietf-secsh-publickeyfile-09.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 23, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document formally documents an existing public key file format 43 in use for exchanging public keys between different SSH 44 implementations. 46 Table of Contents 48 1. Conventions used in this document . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . . 5 51 3.1. Line Termination Characters . . . . . . . . . . . . . . . 5 52 3.2. Begin and End Markers . . . . . . . . . . . . . . . . . . 5 53 3.3. Key File Header . . . . . . . . . . . . . . . . . . . . . 5 54 3.3.1. Subject Header . . . . . . . . . . . . . . . . . . . . 6 55 3.3.2. Comment Header . . . . . . . . . . . . . . . . . . . . 6 56 3.3.3. New Headers . . . . . . . . . . . . . . . . . . . . . 6 57 3.4. Public Key File Body . . . . . . . . . . . . . . . . . . . 6 58 3.5. Differences with RFC1421 PEM formats . . . . . . . . . . . 7 59 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Public Key Fingerprints . . . . . . . . . . . . . . . . . . . 9 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Intellectual Property and Copyright Statements . . . . . . . . . . 14 69 1. Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 2. Introduction 77 In order to use public key authentication, public keys must be 78 exchanged between client and server. This document formally 79 describes an existing public key file format. 81 3. Key File Format 83 In order to implement public key authentication, SSH implementations 84 must share public key files between the client and the server in 85 order to interoperate. 87 A key file is a text file, containing a sequence of lines. Each line 88 in the file MUST NOT be longer than 72 bytes excluding line 89 termination characters. 91 3.1. Line Termination Characters 93 Implementations SHOULD generate public key files using their system's 94 local text file representation. 96 In the event that public key files are not transferred as text files, 97 implementations SHOULD be prepared to read files using any of the 98 common line termination sequence, , or . 100 3.2. Begin and End Markers 102 The first line of a conforming key file MUST be a begin marker, which 103 is the literal text: 105 ---- BEGIN SSH2 PUBLIC KEY ---- 107 The last line of a conforming key file MUST be an end marker, which 108 is the literal text: 110 ---- END SSH2 PUBLIC KEY ---- 112 3.3. Key File Header 114 The key file header section consists of multiple RFC822-style header 115 fields. Each field is a line of the following format: 117 Header-tag ':' ' ' Header-value 119 The Header-tag MUST NOT be more than 64 bytes, and is case- 120 insensitive. The Header-value MUST NOT be more than 1024 bytes. 121 Each line in the header MUST NOT be more than 72 bytes. 123 A line is continued if the last character in the line is a '\'. If 124 the last character of a line is a '\', then the logical contents of 125 the line is formed by removing the '\' and the line termination 126 characters, and appending the contents of the next line. 128 The Header-tag MUST be encoded in US-ASCII. The Header-value MUST be 129 encoded in UTF-8. [RFC3629] 131 A line that is not a continuation line that has no ':' in it is the 132 first line of the base 64 encoded body (See Section 3.4.) 134 Compliant implementations MUST ignore unrecognized header fields. 135 Implementations SHOULD preserve unrecognized header fields when 136 manipulating the key file. 138 3.3.1. Subject Header 140 This field is used to store the login-name that the key was generated 141 under. For example: 143 Subject: user 145 3.3.2. Comment Header 147 The comment header contains a user specified comment. The comment 148 SHOULD be displayed when using the key. 150 It is suggested that this field default to user@hostname for the user 151 and machine used to generate the key. For example: 153 Comment: user@example.com 155 Currently, common practice is to quote the Header-value of the 156 Comment by prefixing and suffixing it with '"' characters, and some 157 existing implementations fail if these quotation marks are omitted 159 Compliant implementations MUST function correctly if the quotation 160 marks are omitted. 162 Implementations MAY include the quotation marks. If the first and 163 last characters of the Header-value are matching quotation marks, 164 implementations SHOULD remove them before using the value. 166 3.3.3. New Headers 168 New headers that are of the from "x-" are considered experimental, 169 and may be used without IETF consensus. 171 All other headers are reserved for use only by IETF consensus. 173 3.4. Public Key File Body 175 The body of a public key file consists of the public key blob as 176 described in [I-D.ietf-secsh-transport], section 4.6, "Public Key 177 Algorithms", encoded in base 64 as specified in [RFC2045], section 178 6.8, "Base64 Content-Transfer-Encoding". 180 As with all other lines, each line in the body MUST NOT be longer 181 than 72 characters excluding line termination characters. 183 3.5. Differences with RFC1421 PEM formats 185 Implemetors should take care to notice that while the format is 186 superficially similar to those specified by PEM [RFC1421] and OpenPGP 187 [RFC2440], it is not identical; most notably: 189 o The other specifications use different BEGIN/END delimeters (five 190 dashes, no space rather than four dashes and a space). 192 o There is no blank line before the start of the base64-encoded 193 contents. 195 o There is no CRC at the end of the base64-encoded block. 197 o Header continuation uses a backslash at the end of the continued 198 line rather then whitespace at the start of the next line. 200 3.6. Examples 202 The following are some example public key files that are compliant 203 (note that the examples all wrap before 72 lines to meet ietf 204 document requirements; however, they are still compliant.) 206 ---- BEGIN SSH2 PUBLIC KEY ---- 207 Comment: "1024-bit RSA, converted from OpenSSH by me@myhost" 208 x-command: /home/galb/bin/lock-in-guest.sh 209 AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb 210 YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 211 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= 212 ---- END SSH2 PUBLIC KEY ---- 213 ---- BEGIN SSH2 PUBLIC KEY ---- 214 Comment: This is my public key for use on \ 215 servers which I don't like. 216 AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET 217 W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH 218 YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c 219 vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf 220 J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA 221 vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB 222 AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS 223 n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 224 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV 225 ---- END SSH2 PUBLIC KEY ---- 227 ---- BEGIN SSH2 PUBLIC KEY ---- 228 Comment: DSA Public Key for use with MyIsp 229 AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET 230 W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH 231 YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c 232 vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf 233 J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA 234 vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB 235 AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS 236 n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 237 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV 238 ---- END SSH2 PUBLIC KEY ---- 240 ---- BEGIN SSH2 PUBLIC KEY ---- 241 Subject: galb 242 Comment: 1024-bit rsa, created by me@myhost Mon Jan 15 08:31:24 2001 243 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 244 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 245 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= 246 ---- END SSH2 PUBLIC KEY ---- 248 4. Public Key Fingerprints 250 The security of the SSH protocols relies on the verification of 251 public host keys. Since public keys tend to be very large, it is 252 difficult for a human to verify an entire host key. Even with a PKI 253 in place, it is useful to have a standard for exchanging short 254 fingerprints of public keys. 256 This section formally describes the method of generating public key 257 fingerprints that is in common use in the SSH community. 259 The fingerprint of a public key consists of the output of the MD5 260 message-digest algorithm [RFC1321]. The input to the algorithm is 261 the public key blob as described in [I-D.ietf-secsh-transport]. The 262 output of the algorithm is presented to the user as a sequence of 16 263 octets printed as hexadecimal with lowercase letters and separated by 264 colons. 266 For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87" 268 5. IANA Considerations 270 There are no IANA registries or other considerations associated with 271 this document. 273 6. Security Considerations 275 The file format described by this document provides no mechanism to 276 verify the integrity or otherwise detect tampering with the data 277 stored in such files. Given the potential of an adversarial 278 tampering with this data, system-specific measures (e.g. Access 279 Control Lists, UNIX permissions, other Discretionary and/or Mandatory 280 Access Controls) SHOULD be used to protect these files. Also, if the 281 contents of these files are transferred it SHOULD be done over a 282 trusted channel. 284 The header data allowed by this file format could contain an 285 unlimited range of information. While in many environments the 286 information conveyed by this header data may be considered innocuous 287 public information, it may constitute a channel through which 288 information about a user, a key or its use may be disclosed 289 intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main St, 290 Home Phone:..."). The presence and use of this header data SHOULD be 291 reviewed by sites that deploy this file format. 293 The public-key fingerprint method presented here relies on the MD5 294 hash, which is known to have certain weaknesses. The use of it here 295 is for historical purposes, and the particular use made of it depends 296 solely one it's 2nd-preimage resistance, not on it's collision- 297 resistance. 299 7. References 301 7.1. Normative References 303 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 304 April 1992. 306 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 307 Extensions (MIME) Part One: Format of Internet Message 308 Bodies", RFC 2045, November 1996. 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 314 10646", STD 63, RFC 3629, November 2003. 316 [I-D.ietf-secsh-transport] 317 Lonvick, C., "SSH Transport Layer Protocol", 318 draft-ietf-secsh-transport-24 (work in progress), 319 March 2005. 321 7.2. Informative References 323 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 324 Mail: Part I: Message Encryption and Authentication 325 Procedures", RFC 1421, February 1993. 327 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 328 "OpenPGP Message Format", RFC 2440, November 1998. 330 Authors' Addresses 332 Joseph Galbraith 333 VanDyke Software 334 4848 Tramway Ridge Blvd 335 Suite 101 336 Albuquerque, NM 87111 337 US 339 Phone: +1 505 332 5700 340 Email: galb-list@vandyke.com 342 Rodney Thayer 343 The Tillerman Group 344 370 Altair Way, PMB 321 345 Sunnyvale, CA 94086 347 Phone: +1 408 757 9693 348 Email: rodney@tillerman.to 350 Intellectual Property Statement 352 The IETF takes no position regarding the validity or scope of any 353 Intellectual Property Rights or other rights that might be claimed to 354 pertain to the implementation or use of the technology described in 355 this document or the extent to which any license under such rights 356 might or might not be available; nor does it represent that it has 357 made any independent effort to identify any such rights. Information 358 on the procedures with respect to rights in RFC documents can be 359 found in BCP 78 and BCP 79. 361 Copies of IPR disclosures made to the IETF Secretariat and any 362 assurances of licenses to be made available, or the result of an 363 attempt made to obtain a general license or permission for the use of 364 such proprietary rights by implementers or users of this 365 specification can be obtained from the IETF on-line IPR repository at 366 http://www.ietf.org/ipr. 368 The IETF invites any interested party to bring to its attention any 369 copyrights, patents or patent applications, or other proprietary 370 rights that may cover technology that may be required to implement 371 this standard. Please address the information to the IETF at 372 ietf-ipr@ietf.org. 374 Disclaimer of Validity 376 This document and the information contained herein are provided on an 377 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 378 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 379 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 380 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 381 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 382 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 384 Copyright Statement 386 Copyright (C) The Internet Society (2005). This document is subject 387 to the rights, licenses and restrictions contained in BCP 78, and 388 except as set forth therein, the authors retain all their rights. 390 Acknowledgment 392 Funding for the RFC Editor function is currently provided by the 393 Internet Society.