idnits 2.17.1 draft-ietf-secsh-publickeyfile-08.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 353. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 366. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (April 1, 2005) is 6965 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: 6 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Secure Shell Working Group J. Galbraith 2 Internet-Draft VanDyke Software 3 Expires: October 3, 2005 R. Thayer 4 The Tillerman Group 5 April 1, 2005 7 SSH Public Key File Format 8 draft-ietf-secsh-publickeyfile-08.txt 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 3, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document formally documents an existing public key file format 44 in use for exchanging public keys between different SSH 45 implementations. 47 Table of Contents 49 1. Conventions used in this document . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . . 5 52 3.1 Line Termination Characters . . . . . . . . . . . . . . . 5 53 3.2 Begin and End Markers . . . . . . . . . . . . . . . . . . 5 54 3.3 Key File Header . . . . . . . . . . . . . . . . . . . . . 5 55 3.3.1 Subject Header . . . . . . . . . . . . . . . . . . . . 6 56 3.3.2 Comment Header . . . . . . . . . . . . . . . . . . . . 6 57 3.3.3 New Headers . . . . . . . . . . . . . . . . . . . . . 6 58 3.4 Public Key File Body . . . . . . . . . . . . . . . . . . . 6 59 3.5 Differences with RFC1421 PEM formats . . . . . . . . . . . 7 60 3.6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Public Key Fingerprints . . . . . . . . . . . . . . . . . . . 9 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7.1 Normative References . . . . . . . . . . . . . . . . . . . 12 66 7.2 Informative References . . . . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 68 Intellectual Property and Copyright Statements . . . . . . . . 14 70 1. Conventions used in this document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 2. Introduction 78 In order to use public key authentication, public keys must be 79 exchanged between client and server. This document formally 80 describes an existing public key file format. 82 3. Key File Format 84 In order to implement public key authentication, SSH implementations 85 must share public key files between the client and the server in 86 order to interoperate. 88 A key file is a text file, containing a sequence of lines. Each line 89 in the file MUST NOT be longer than 72 bytes excluding line 90 termination characters. 92 3.1 Line Termination Characters 94 Implementations are REQUIRED to read files using any of the common 95 line termination sequence, , or . 97 Implementations may generate files using whichever of these line 98 termination conventions is most convenient. 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 120 case-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] 130 A line that is not a continuation line that has no ':' in it is the 131 first line of the base 64 encoded body (See Section 3.4.) 133 Compliant implementations MUST ignore unrecognized header fields. 134 Implementations SHOULD preserve unrecognized header fields when 135 manipulating the key file. 137 3.3.1 Subject Header 139 This field is used to store the login-name that the key was generated 140 under. For example: 142 Subject: user 144 3.3.2 Comment Header 146 The comment header contains a user specified comment. The comment 147 SHOULD be displayed when using the key. 149 It is suggested that this field default to user@hostname for the user 150 and machine used to generate the key. For example: 152 Comment: user@example.com 154 Currently, common practice is to quote the Header-value of the 155 Comment by prefixing and suffixing it with '"' characters, and some 156 existing implementations fail if these quotation marks are omitted 158 Compliant implementations MUST function correctly if the quotation 159 marks are omitted. 161 Implementations MAY include the quotation marks. If the first and 162 last characters of the Header-value are matching quotation marks, 163 implementations SHOULD remove them before using the value. 165 3.3.3 New Headers 167 New headers that are of the from "x-" are considered experimental, 168 and may be used without IETF consensus. 170 All other headers are reserved for use only by IETF consensus. 172 3.4 Public Key File Body 174 The body of a public key file consists of the public key blob as 175 described in [I-D.ietf-secsh-transport], section 4.6, "Public Key 176 Algorithms", encoded in base 64 as specified in [RFC2045], section 177 6.8, "Base64 Content-Transfer-Encoding". 179 As with all other lines, each line in the body MUST NOT be longer 180 than 72 characters excluding line termination characters. 182 3.5 Differences with RFC1421 PEM formats 184 Implemetors should take care to notice that while the format is 185 superficially similar to those specified by PEM [RFC1421] and OpenPGP 186 [RFC2440], it is not identical; most notably: 187 o The other specifications use different BEGIN/END delimeters (five 188 dashes, no space rather than four dashes and a space). 189 o There is no blank line before the start of the base64-encoded 190 contents. 191 o There is no CRC at the end of the base64-encoded block. 192 o Header continuation uses a backslash at the end of the continued 193 line rather then whitespace at the start of the next line. 195 3.6 Examples 197 The following are some example public key files that are compliant 198 (note that the examples all wrap before 72 lines to meet ietf 199 document requirements; however, they are still compliant.) 201 ---- BEGIN SSH2 PUBLIC KEY ---- 202 Comment: "1024-bit RSA, converted from OpenSSH by me@myhost" 203 x-command: /home/galb/bin/lock-in-guest.sh 204 AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb 205 YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 206 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= 207 ---- END SSH2 PUBLIC KEY ---- 209 ---- BEGIN SSH2 PUBLIC KEY ---- 210 Comment: This is my public key for use on \ 211 servers which I don't like. 212 AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET 213 W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH 214 YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c 215 vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf 216 J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA 217 vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB 218 AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS 219 n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 220 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV 221 ---- END SSH2 PUBLIC KEY ---- 223 ---- BEGIN SSH2 PUBLIC KEY ---- 224 Comment: DSA Public Key for use with MyIsp 225 AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET 226 W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH 227 YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c 228 vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf 229 J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA 230 vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB 231 AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS 232 n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 233 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV 234 ---- END SSH2 PUBLIC KEY ---- 236 ---- BEGIN SSH2 PUBLIC KEY ---- 237 Subject: galb 238 Comment: 1024-bit rsa, created by me@myhost Mon Jan 15 08:31:24 2001 239 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 240 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 241 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= 242 ---- END SSH2 PUBLIC KEY ---- 244 4. Public Key Fingerprints 246 The security of the SSH protocols relies on the verification of 247 public host keys. Since public keys tend to be very large, it is 248 difficult for a human to verify an entire host key. Even with a PKI 249 in place, it is useful to have a standard for exchanging short 250 fingerprints of public keys. 252 This section formally describes the method of generating public key 253 fingerprints that is in common use in the SSH community. 255 The fingerprint of a public key consists of the output of the MD5 256 message-digest algorithm [RFC1321]. The input to the algorithm is 257 the public key blob as described in [I-D.ietf-secsh-transport]. The 258 output of the algorithm is presented to the user as a sequence of 16 259 octets printed as hexadecimal with lowercase letters and separated by 260 colons. 262 For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87" 264 5. IANA Considerations 266 There are no IANA registries or other considerations associated with 267 this document. 269 6. Security Considerations 271 The file format described by this document provides no mechanism to 272 verify the integrity or otherwise detect tampering with the data 273 stored in such files. Given the potential of an adversarial 274 tampering with this data, system-specific measures (e.g. Access 275 Control Lists, UNIX permissions, other Discretionary and/or Mandatory 276 Access Controls) SHOULD be used to protect these files. Also, if the 277 contents of these files are transferred it SHOULD be done over a 278 trusted channel. 280 The header data allowed by this file format could contain an 281 unlimited range of information. While in many environments the 282 information conveyed by this header data may be considered innocuous 283 public information, it may constitute a channel through which 284 information about a user, a key or its use may be disclosed 285 intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main 286 St, Home Phone:..."). The presence and use of this header data 287 SHOULD be reviewed by sites that deploy this file format. 289 The public-key fingerprint method presented here relies on the MD5 290 hash, which is known to have certain weaknesses. The use of it here 291 is for historical purposes, and the particular use made of it depends 292 solely one it's 2nd-preimage resistance, not on it's 293 collision-resistance. 295 7. References 297 7.1 Normative References 299 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 300 April 1992. 302 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 303 Extensions (MIME) Part One: Format of Internet Message 304 Bodies", RFC 2045, November 1996. 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, March 1997. 309 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 310 10646", STD 63, RFC 3629, November 2003. 312 [I-D.ietf-secsh-transport] 313 Lonvick, C., "SSH Transport Layer Protocol", 314 Internet-Draft draft-ietf-secsh-transport-24, March 2005. 316 7.2 Informative References 318 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 319 Mail: Part I: Message Encryption and Authentication 320 Procedures", RFC 1421, February 1993. 322 [RFC2440] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, 323 "OpenPGP Message Format", RFC 2440, November 1998. 325 Authors' Addresses 327 Joseph Galbraith 328 VanDyke Software 329 4848 Tramway Ridge Blvd 330 Suite 101 331 Albuquerque, NM 87111 332 US 334 Phone: +1 505 332 5700 335 Email: galb-list@vandyke.com 336 Rodney Thayer 337 The Tillerman Group 338 370 Altair Way, PMB 321 339 Sunnyvale, CA 94086 341 Phone: +1 408 757 9693 342 Email: rodney@tillerman.to 344 Intellectual Property Statement 346 The IETF takes no position regarding the validity or scope of any 347 Intellectual Property Rights or other rights that might be claimed to 348 pertain to the implementation or use of the technology described in 349 this document or the extent to which any license under such rights 350 might or might not be available; nor does it represent that it has 351 made any independent effort to identify any such rights. Information 352 on the procedures with respect to rights in RFC documents can be 353 found in BCP 78 and BCP 79. 355 Copies of IPR disclosures made to the IETF Secretariat and any 356 assurances of licenses to be made available, or the result of an 357 attempt made to obtain a general license or permission for the use of 358 such proprietary rights by implementers or users of this 359 specification can be obtained from the IETF on-line IPR repository at 360 http://www.ietf.org/ipr. 362 The IETF invites any interested party to bring to its attention any 363 copyrights, patents or patent applications, or other proprietary 364 rights that may cover technology that may be required to implement 365 this standard. Please address the information to the IETF at 366 ietf-ipr@ietf.org. 368 Disclaimer of Validity 370 This document and the information contained herein are provided on an 371 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 372 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 373 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 374 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 375 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 378 Copyright Statement 380 Copyright (C) The Internet Society (2005). This document is subject 381 to the rights, licenses and restrictions contained in BCP 78, and 382 except as set forth therein, the authors retain all their rights. 384 Acknowledgment 386 Funding for the RFC Editor function is currently provided by the 387 Internet Society.