idnits 2.17.1 draft-ietf-secsh-publickeyfile-07.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 323. ** 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 (March 22, 2005) is 6975 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) -- Obsolete informational reference (is this intentional?): RFC 1991 (Obsoleted by RFC 4880) Summary: 5 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: September 23, 2005 R. Thayer 5 The Tillerman Group 6 March 22, 2005 8 SSH Public Key File Format 9 draft-ietf-secsh-publickeyfile-07.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 23, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document formally documents the existing public key file format 45 in use for exchanging public keys between different SSH 46 implementations. 48 Table of Contents 50 1. Conventions used in this document . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Key File Format . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.1 Line termination Characters . . . . . . . . . . . . . . . 5 54 3.2 Begin and end markers . . . . . . . . . . . . . . . . . . 5 55 3.3 Key File Header . . . . . . . . . . . . . . . . . . . . . 5 56 3.3.1 Subject Header . . . . . . . . . . . . . . . . . . . . 6 57 3.3.2 Comment Header . . . . . . . . . . . . . . . . . . . . 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 6.1 Normative References . . . . . . . . . . . . . . . . . . . 10 65 6.2 Informative References . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 67 Intellectual Property and Copyright Statements . . . . . . . . 12 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 the existing public key file format, with few exceptions. 81 Where this document departs from current practice, it also suggests a 82 mechanism for backwards compatibility. 84 3. Key File Format 86 SSH implementations must share public key files between the client 87 and the server in order to interoperate. 89 A key file is a text file, containing a sequence of lines. Each line 90 in the file MUST NOT be longer than 72 bytes. 92 3.1 Line termination Characters 94 In order to achieve the goal of being able to exchange public key 95 files between servers, implementations are REQUIRED to read files 96 using any of the common line termination sequence, , or 97 . 99 Implementations may generate files using which ever line termination 100 convention is most convenient 102 3.2 Begin and end markers 104 The first line of a conforming key file MUST be a begin marker, which 105 is the literal text: 107 ---- BEGIN SSH2 PUBLIC KEY ---- 109 The last line of a conforming key file MUST be a end marker, which is 110 the literal text: 112 ---- END SSH2 PUBLIC KEY ---- 114 3.3 Key File Header 116 The key file header section consists of multiple RFC822 - style 117 header fields. Each field is a line of the following format: 119 Header-tag ':' ' ' Header-value 121 The Header-tag MUST NOT be more than 64 bytes. The Header-value MUST 122 NOT be more than 1024 bytes. Each line in the header MUST NOT be 123 more than 72 bytes. 125 A line is continued if the last character in the line is a '\'. If 126 the last character of a line is a '\', then the logical contents of 127 the line is formed by removing the '\' and appending the contents of 128 the next line. 130 The Header-tag MUST be US-ASCII. The Header-value MUST be encoded in 131 UTF-8. [RFC3629] 132 A line that is not a continuation line that has no ':' in it is 133 assumed to be the first line of the base 64 encoded body (Section 8) 135 Compliant implementations MUST ignore unrecognized header fields. 136 Implementations SHOULD preserve unrecognized header fields when 137 manipulating the key file. 139 Existing implementations may not correctly handle unrecognized 140 fields. During a transition period, implementations SHOULD generate 141 key file headers that contain only a Subject field followed by a 142 Comment field. 144 3.3.1 Subject Header 146 This field currently is used to store the login-name that the key was 147 generated under. For example: 149 Subject: user 151 3.3.2 Comment Header 153 Contain a user specified comment which will be displayed when using 154 the key. 156 It is suggested that this field default to user@hostname for the user 157 and machine used to generate the key. For example: 159 Comment: user@mycompany.com 161 Currently, common practice is to quote the Header-value of the 162 Comment, and some existing implementations fail if these quotes are 163 omitted. 165 Compliant implementations MUST function correctly if the quotes are 166 omitted. 168 During an interim period implementations MAY include the quotes. If 169 the first and last characters of the Header-value are matching 170 quotes, implementations SHOULD remove them before using the value. 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 the SSH transport draft [I-D.ietf-secsh-transport], 176 section 4.6, "Public Key Algorithms", encoded in base 64 as specified 177 in RFC-2045, section 6.8, "Base64 Content-Transfer-Encoding". 178 [RFC2045] 179 As with all other lines, each line in the body MUST NOT be longer 180 than 72 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 that specified by PEM [RFC1421] and PGP 186 [RFC1991], 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. 192 3.6 Examples 194 The following are some example public key files that are compliant: 196 ---- BEGIN SSH2 PUBLIC KEY ---- 197 Comment: "1024-bit RSA, converted from OpenSSH by galb@test1" 198 AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb 199 YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 200 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= 201 ---- END SSH2 PUBLIC KEY ---- 203 ---- BEGIN SSH2 PUBLIC KEY ---- 204 Comment: DSA Public Key for use with MyIsp 205 AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET 206 W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH 207 YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c 208 vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf 209 J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA 210 vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB 211 AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS 212 n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 213 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV 214 ---- END SSH2 PUBLIC KEY ---- 216 ---- BEGIN SSH2 PUBLIC KEY ---- 217 Subject: galb 218 Comment: 1024-bit rsa, created by galb@shimi Mon Jan 15 08:31:24 2001 219 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 220 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 221 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= 222 ---- END SSH2 PUBLIC KEY ---- 224 4. IANA Considerations 226 There are no IANA registries or other considerations associated with 227 this document. 229 5. Security Considerations 231 The file format described by this document provides no mechanism to 232 verify the integrity or otherwise detect tampering with the data 233 stored in such files. Given the potential of an adversarial 234 tampering with this data, system-specific measures (e.g. Access 235 Control Lists, UNIX permissions, other Discretionary and/or Mandatory 236 Access Controls) SHOULD be used to protect these files. Also, if the 237 contents of these files are transferred it SHOULD be done over a 238 trusted channel. 240 The header data allowed by this file format could contain an 241 unlimited range of information. While in many environments the 242 information conveyed by this header data may be considered innocuous 243 public information, it may constitute a channel through which 244 information about a user, a key or its use may be disclosed 245 intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main 246 St, Home Phone:..."). The presence and use of this header data 247 SHOULD be reviewed by sites that deploy this file format. 249 6. References 251 6.1 Normative References 253 [I-D.ietf-secsh-transport] 254 Lonvick, C., "SSH Transport Layer Protocol", 255 Internet-Draft draft-ietf-secsh-transport-24, March 2005. 257 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 258 10646", STD 63, RFC 3629, November 2003. 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 264 Extensions (MIME) Part One: Format of Internet Message 265 Bodies", RFC 2045, November 1996. 267 6.2 Informative References 269 [RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic 270 Mail: Part I: Message Encryption and Authentication 271 Procedures", RFC 1421, February 1993. 273 [RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message 274 Exchange Formats", RFC 1991, August 1996. 276 Authors' Addresses 278 Joseph Galbraith 279 VanDyke Software 280 4848 Tramway Ridge Blvd 281 Suite 101 282 Albuquerque, NM 87111 283 US 285 Phone: +1 505 332 5700 286 Email: galb-list@vandyke.com 288 Rodney Thayer 289 The Tillerman Group 290 370 Altair Way, PMB 321 291 Sunnyvale, CA 94086 293 Phone: +1 408 757 9693 294 Email: rodney@tillerman.to 296 Trademark notice 298 "ssh" is a registered trademark in the United States and/or other 299 countries. 301 Intellectual Property Statement 303 The IETF takes no position regarding the validity or scope of any 304 Intellectual Property Rights or other rights that might be claimed to 305 pertain to the implementation or use of the technology described in 306 this document or the extent to which any license under such rights 307 might or might not be available; nor does it represent that it has 308 made any independent effort to identify any such rights. Information 309 on the procedures with respect to rights in RFC documents can be 310 found in BCP 78 and BCP 79. 312 Copies of IPR disclosures made to the IETF Secretariat and any 313 assurances of licenses to be made available, or the result of an 314 attempt made to obtain a general license or permission for the use of 315 such proprietary rights by implementers or users of this 316 specification can be obtained from the IETF on-line IPR repository at 317 http://www.ietf.org/ipr. 319 The IETF invites any interested party to bring to its attention any 320 copyrights, patents or patent applications, or other proprietary 321 rights that may cover technology that may be required to implement 322 this standard. Please address the information to the IETF at 323 ietf-ipr@ietf.org. 325 Disclaimer of Validity 327 This document and the information contained herein are provided on an 328 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 329 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 330 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 331 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 332 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 333 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 335 Copyright Statement 337 Copyright (C) The Internet Society (2005). This document is subject 338 to the rights, licenses and restrictions contained in BCP 78, and 339 except as set forth therein, the authors retain all their rights. 341 Acknowledgment 343 Funding for the RFC Editor function is currently provided by the 344 Internet Society.