idnits 2.17.1 draft-ietf-secsh-publickeyfile-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 2001) is 8442 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) -- No information found for draft-secsh-transport - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SSH-TRANS' ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Galbraith 2 INTERNET-DRAFT Van Dyke Technologies, Inc. 3 draft-ietf-secsh-publickeyfile-02 R. Thayer 4 Expires December 2001 The Tillerman Group 5 March 2001 7 SECSH Public Key File Format 9 STATUS OF THIS MEMO: 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of [RFC-2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document formally documents the existing public key file format 33 in use for exchanging public keys between different SECSH 34 implementations. 36 1. Conventions used in this document 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in [RFC-2119]. 42 2. Introduction 44 In order to use public key authentication, public keys must be 45 exchanged between client and server. This document formally 46 describes the existing public key file format, with few exceptions. 48 Where this document departs from current practice, it also suggests 49 a mechanism for backwards compatibility. 51 3. Key File Format 53 SECSH implementations must share public key files between the client 54 and the server in order interoperate. 56 A key file is a text file, containing a sequence of lines. Each line 57 in the file MUST NOT be longer than 72 bytes. 59 3.1 Line termination Characters 61 In order to achieve the goal of being able to exchange public key 62 files between servers, implementations are REQUIRED to read files 63 using any of the common line termination sequence, , or 64 . 66 Implementations may generate files using which ever line termination 67 convention is most convenient 69 4. Begin and end markers 71 The first line of a conforming key file MUST be a begin marker, 72 which is the literal text: 74 ---- BEGIN SSH2 PUBLIC KEY ---- 76 The last line of a conforming key file MUST be a end marker, which 77 is the literal text: 79 ---- END SSH2 PUBLIC KEY ---- 81 5. Key File Header 83 The key file header section consists of multiple RFC822 - style 84 header fields. Each field is a line of the following format: 86 Header-tag ':' ' ' Header-value 88 The Header-tag MUST NOT be more than 64 bytes. The Header-value 89 MUST NOT be more than 1024 bytes. Each line in the header MUST NOT 90 be more than 72 bytes. 92 A line is continued if the last character in the line is a '\'. If 93 the last character of a line is a '\', then the logical contents of 94 the line is formed by removing the '\' and appending the contents of 95 the next line. 97 The Header-tag MUST be US-ASCII. The Header-value MUST be encoded 98 in UTF-8 ([RFC-2044]). 100 A line that is not a continuation line that has no ':' in it is 101 assumed to be the first line of the base 64 encoded body (Section 8) 102 Compliant implementations MUST ignore unrecognized header fields. 103 Implementations SHOULD preserve unrecognized header fields when 104 manipulating the key file. 106 Existing implementations may not correctly handle unrecognized 107 fields. During a transition period, implementations SHOULD generate 108 key file headers that contain only a Subject field followed by a 109 Comment field. 111 6. Subject Header 113 This field currently is used to store the login-name that the key 114 was generated under. For example: 116 Subject: user 118 7. Comment Header 120 Contain a user specified comment which will be displayed when using 121 the key. 123 It is suggested that this field default to user@hostname for the 124 user and machine used to generate the key. For example: 126 Comment: user@mycompany.com 128 Currently, common practice is to quote the Header-value of the 129 Comment, and some existing implementations fail if these quotes are 130 omitted. 132 Compliant implementations MUST function correctly if the quotes are 133 omitted. 135 During an interim period implementations MAY include the quotes. If 136 the first and last characters of the Header-value are matching 137 quotes, implementations SHOULD remove them before using the value. 139 8. Public Key File Body 141 The body of a public key file consists of the public key blob as 142 described in [SSH-TRANS], section 4.6, "Public Key Algorithms", 143 encoded in base 64 as specified in [RFC-2045] section 6.8, "Base64 144 Content-Transfer-Encoding". 146 As with all other lines, each line in the body MUST NOT be longer 147 than 72 characters. 149 9. Examples 151 The following are some example public key files that are compliant: 153 ---- BEGIN SSH2 PUBLIC KEY ---- 154 Comment: "1024-bit RSA, converted from OpenSSH by galb@test1" 155 AAAAB3NzaC1yc2EAAAABIwAAAIEA1on8gxCGJJWSRT4uOrR13mUaUk0hRf4RzxSZ1zRbYY 156 Fw8pfGesIFoEuVth4HKyF8k1y4mRUnYHP1XNMNMJl1JcEArC2asV8sHf6zSPVffozZ5TT4 157 SfsUu/iKy9lUcCfXzwre4WWZSXXcPff+EHtWshahu3WzBdnGxm5Xoi89zcE= 158 ---- END SSH2 PUBLIC KEY ---- 160 ---- BEGIN SSH2 PUBLIC KEY ---- 161 Comment: DSA Public Key for use with MyIsp 162 AAAAB3NzaC1kc3MAAACBAPY8ZOHY2yFSJA6XYC9HRwNHxaehvx5wOJ0rzZdzoSOXxbETW6 163 ToHv8D1UJ/z+zHo9Fiko5XybZnDIaBDHtblQ+Yp7StxyltHnXF1YLfKD1G4T6JYrdHYI14 164 Om1eg9e4NnCRleaqoZPF3UGfZia6bXrGTQf3gJq2e7Yisk/gF+1VAAAAFQDb8D5cvwHWTZ 165 DPfX0D2s9Rd7NBvQAAAIEAlN92+Bb7D4KLYk3IwRbXblwXdkPggA4pfdtW9vGfJ0/RHd+N 166 jB4eo1D+0dix6tXwYGN7PKS5R/FXPNwxHPapcj9uL1Jn2AWQ2dsknf+i/FAAvioUPkmdMc 167 0zuWoSOEsSNhVDtX3WdvVcGcBq9cetzrtOKWOocJmJ80qadxTRHtUAAACBAN7CY+KKv1gH 168 pRzFwdQm7HK9bb1LAo2KwaoXnadFgeptNBQeSXG1vO+JsvphVMBJc9HSn24VYtYtsMu74q 169 XviYjziVucWKjjKEb11juqnF0GDlB3VVmxHLmxnAz643WK42Z7dLM5sY29ouezv4Xz2PuM 170 ch5VGPP+CDqzCM4loWgV 171 ---- END SSH2 PUBLIC KEY ---- 173 ---- BEGIN SSH2 PUBLIC KEY ---- 174 Subject: galb 175 Comment: 1024-bit rsa, created by galb@shimi Mon Jan 15 08:31:24 2001 176 AAAAB3NzaC1yc2EAAAABJQAAAIEAiPWx6WM4lhHNedGfBpPJNPpZ7yKu+dnn1SJejgt459 177 6k6YjzGGphH2TUxwKzxcKDKKezwkpfnxPkSMkuEspGRt/aZZ9wa++Oi7Qkr8prgHc4soW6 178 NUlfDzpvZK2H5E7eQaSeP3SAwGmQKUFHCddNaP0L+hM7zhFNzjFvpaMgJw0= 179 ---- END SSH2 PUBLIC KEY ---- 181 10. References 183 [SSH-TRANS] Ylonen, T., et al: "SSH Transport Layer Protocol", 184 Internet Draft, draft-secsh-transport-09.txt 186 [RFC-2044] Yergeau, F: "UTF-8, a Transformation Format of Unicode 187 and ISO 10646", October 1996. 189 [RFC-2026] S. Bradner: "The Internet Standards Process -- Revision 190 3", October 1996. 192 [RFC-2119] S. Bradner: "Key words for use in RFCs to Indicate 193 Requirement Levels", March 1997. 195 [RFC-2045] Freed & Borenstein: "Multipurpose Internet Mail 196 Extensions (MIME) Part One: Format of Internet Message Bodies", 197 November 1996. 199 11. Author's Address 201 Joseph Galbraith 202 Van Dyke Technologies, Inc. 203 4848 Tramway Ridge Rd. 204 Suite 101 205 Albuquerque, NM 87111 206 Email: galb@vandyke.com 207 Phone: +1 505 332 5700 209 Rodney Thayer 210 The Tillerman Group 211 370 Altair Way, PMB 321 212 Sunnyvale, CA 94086 213 Email: rodney@tillerman.to 214 Phone: +1 408 757 9693