idnits 2.17.1 draft-ietf-secsh-publickeyfile-06.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 313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 303. ** 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 17, 2005) is 6978 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) == Unused Reference: 'RFC2026' is defined on line 246, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 18, 2005 R. Thayer 5 The Tillerman Group 6 March 17, 2005 8 SSH Public Key File Format 9 draft-ietf-secsh-publickeyfile-06.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 18, 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 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 64 Intellectual Property and Copyright Statements . . . . . . . . 11 66 1. Conventions used in this document 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 2. Introduction 74 In order to use public key authentication, public keys must be 75 exchanged between client and server. This document formally 76 describes the existing public key file format, with few exceptions. 78 Where this document departs from current practice, it also suggests a 79 mechanism for backwards compatibility. 81 3. Key File Format 83 SSH implementations must share public key files between the client 84 and the server in order to interoperate. 86 A key file is a text file, containing a sequence of lines. Each line 87 in the file MUST NOT be longer than 72 bytes. 89 3.1 Line termination Characters 91 In order to achieve the goal of being able to exchange public key 92 files between servers, implementations are REQUIRED to read files 93 using any of the common line termination sequence, , or 94 . 96 Implementations may generate files using which ever line termination 97 convention is most convenient 99 3.2 Begin and end markers 101 The first line of a conforming key file MUST be a begin marker, which 102 is the literal text: 104 ---- BEGIN SSH2 PUBLIC KEY ---- 106 The last line of a conforming key file MUST be a end marker, which is 107 the literal text: 109 ---- END SSH2 PUBLIC KEY ---- 111 3.3 Key File Header 113 The key file header section consists of multiple RFC822 - style 114 header fields. Each field is a line of the following format: 116 Header-tag ':' ' ' Header-value 118 The Header-tag MUST NOT be more than 64 bytes. The Header-value MUST 119 NOT be more than 1024 bytes. Each line in the header MUST NOT be 120 more than 72 bytes. 122 A line is continued if the last character in the line is a '\'. If 123 the last character of a line is a '\', then the logical contents of 124 the line is formed by removing the '\' and appending the contents of 125 the next line. 127 The Header-tag MUST be US-ASCII. The Header-value MUST be encoded in 128 UTF-8. [RFC2044] 129 A line that is not a continuation line that has no ':' in it is 130 assumed to be the first line of the base 64 encoded body (Section 8) 132 Compliant implementations MUST ignore unrecognized header fields. 133 Implementations SHOULD preserve unrecognized header fields when 134 manipulating the key file. 136 Existing implementations may not correctly handle unrecognized 137 fields. During a transition period, implementations SHOULD generate 138 key file headers that contain only a Subject field followed by a 139 Comment field. 141 3.3.1 Subject Header 143 This field currently is used to store the login-name that the key was 144 generated under. For example: 146 Subject: user 148 3.3.2 Comment Header 150 Contain a user specified comment which will be displayed when using 151 the key. 153 It is suggested that this field default to user@hostname for the user 154 and machine used to generate the key. For example: 156 Comment: user@mycompany.com 158 Currently, common practice is to quote the Header-value of the 159 Comment, and some existing implementations fail if these quotes are 160 omitted. 162 Compliant implementations MUST function correctly if the quotes are 163 omitted. 165 During an interim period implementations MAY include the quotes. If 166 the first and last characters of the Header-value are matching 167 quotes, implementations SHOULD remove them before using the value. 169 3.4 Public Key File Body 171 The body of a public key file consists of the public key blob as 172 described in the SSH transport draft [I-D.ietf-secsh-transport], 173 section 4.6, "Public Key Algorithms", encoded in base 64 as specified 174 in RFC-2045, section 6.8, "Base64 Content-Transfer-Encoding". 175 [RFC2045] 176 As with all other lines, each line in the body MUST NOT be longer 177 than 72 characters. 179 3.5 Examples 181 The following are some example public key files that are compliant: 183 ---- BEGIN SSH2 PUBLIC KEY ---- 184 Comment: "1024-bit RSA, converted from OpenSSH by galb@test1" 185 AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRb 186 YYFw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ 187 5TT4SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= 188 ---- END SSH2 PUBLIC KEY ---- 190 ---- BEGIN SSH2 PUBLIC KEY ---- 191 Comment: DSA Public Key for use with MyIsp 192 AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbET 193 W6ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdH 194 YI14Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5c 195 vwHWTZDPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGf 196 J0/RHd+NjB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAA 197 vioUPkmdMc0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACB 198 AN7CY+KKv1gHpRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HS 199 n24VYtYtsMu74qXviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5 200 sY29ouezv4Xz2PuMch5VGPP+CDqzCM4loWgV 201 ---- END SSH2 PUBLIC KEY ---- 203 ---- BEGIN SSH2 PUBLIC KEY ---- 204 Subject: galb 205 Comment: 1024-bit rsa, created by galb@shimi Mon Jan 15 08:31:24 2001 206 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt4 207 596k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4 208 soW6NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= 209 ---- END SSH2 PUBLIC KEY ---- 211 4. IANA Considerations 213 There are non IANA registries or other considerations associated with 214 this document. 216 5. Security Considerations 218 The file format described by this document provides no mechanism to 219 verify the integrity or otherwise detect tampering with the data 220 stored in such files. Given the potential of an adversarial 221 tampering with this data, system-specific measures (e.g. Access 222 Control Lists, UNIX permissions, other Discretionary and/or Mandatory 223 Access Controls) SHOULD be used to protect these files. Also, if the 224 contents of these files are transferred it SHOULD be done over a 225 trusted channel. 227 The header data allowed by this file format could contain an 228 unlimited range of information. While in many environments the 229 information conveyed by this header data may be considered innocuous 230 public information, it may constitute a channel through which 231 information about a user, a key or its use may be disclosed 232 intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main 233 St, Home Phone:..."). The presence and use of this header data 234 SHOULD be reviewed by sites that deploy this file format. 236 6. Normative References 238 [I-D.ietf-secsh-transport] 239 Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S. 240 Lehtinen, "SSH Protocol Transport Protocol", September 241 2002. 243 [RFC2044] Yergeau, F., "UTF-8, a Transformation Format of Unicode 244 and ISO 10646", October 1996. 246 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 247 3", October 1996. 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", March 1997. 252 [RFC2045] Freed and Borenstein, "Multipurpose Internet Mail 253 Extensions (MIME) Part One: Format of Internet Message 254 Bodies", November 1996. 256 Authors' Addresses 258 Joseph Galbraith 259 VanDyke Software 260 4848 Tramway Ridge Blvd 261 Suite 101 262 Albuquerque, NM 87111 263 US 265 Phone: +1 505 332 5700 266 Email: galb-list@vandyke.com 268 Rodney Thayer 269 The Tillerman Group 270 370 Altair Way, PMB 321 271 Sunnyvale, CA 94086 273 Phone: +1 408 757 9693 274 Email: rodney@tillerman.to 276 Trademark notice 278 "ssh" is a registered trademark in the United States and/or other 279 countries. 281 Intellectual Property Statement 283 The IETF takes no position regarding the validity or scope of any 284 Intellectual Property Rights or other rights that might be claimed to 285 pertain to the implementation or use of the technology described in 286 this document or the extent to which any license under such rights 287 might or might not be available; nor does it represent that it has 288 made any independent effort to identify any such rights. Information 289 on the procedures with respect to rights in RFC documents can be 290 found in BCP 78 and BCP 79. 292 Copies of IPR disclosures made to the IETF Secretariat and any 293 assurances of licenses to be made available, or the result of an 294 attempt made to obtain a general license or permission for the use of 295 such proprietary rights by implementers or users of this 296 specification can be obtained from the IETF on-line IPR repository at 297 http://www.ietf.org/ipr. 299 The IETF invites any interested party to bring to its attention any 300 copyrights, patents or patent applications, or other proprietary 301 rights that may cover technology that may be required to implement 302 this standard. Please address the information to the IETF at 303 ietf-ipr@ietf.org. 305 Disclaimer of Validity 307 This document and the information contained herein are provided on an 308 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 309 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 310 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 311 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 312 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 313 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 315 Copyright Statement 317 Copyright (C) The Internet Society (2005). This document is subject 318 to the rights, licenses and restrictions contained in BCP 78, and 319 except as set forth therein, the authors retain all their rights. 321 Acknowledgment 323 Funding for the RFC Editor function is currently provided by the 324 Internet Society.