idnits 2.17.1 draft-kazu-pgpmime-multisig-00.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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. ** There are 39 instances of lines with control characters in the document. ** The abstract seems to contain references ([MOSS], [JMSG], [MIME], [SHA1], [PGP], [SecMulti], [MD5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 75: '...which conforms this memo MUST have the...' RFC 2119 keyword, line 77: '...heir second part MUST be "Multipart/PG...' RFC 2119 keyword, line 78: '...t in "Multipart/PGP-Signature" MUST be...' RFC 2119 keyword, line 81: '...ameter of "Multipart/Signed" MUST be a...' RFC 2119 keyword, line 84: '... tokens MUST be greater than or equ...' (9 more instances...) 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'SecMulti' ** Downref: Normative reference to an Historic RFC: RFC 1848 (ref. 'MOSS') ** Obsolete normative reference: RFC 1991 (ref. 'PGP') (Obsoleted by RFC 4880) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5') -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' -- Possible downref: Non-RFC (?) normative reference: ref. 'JMSG' Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Kazu Yamamoto 2 NAIST 3 Expires in six months May, 1997 5 Multi-signature Extensions for PGP/MIME 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other documents 17 at any time. It is inappropriate to use Internet- Drafts as 18 reference material or to cite them other than as ``work in 19 progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 23 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Abstract 29 PGP/MIME provides single signature service of PGP in the context of 30 MIME, however, multiple signature service is desired for usability 31 and flexibility. For this purpose, this memo defines 32 "Multipart/PGP-Signature" used as the "protocol" parameter and the 33 content type of the second part of "Multipart/Signed". 35 Canonical MIME format used in PGP/MIME is reasonable but it is not 36 enough for some kinds of MIME objects, particularly for ISO 2022 37 text. Thus, this memo extends the "micalg" parameter syntax as 38 "pgp-+" so that can 39 specify more specific canonicalization for signature calculation. 41 Introduction 43 "Multipart/Signed" defined in [SecMulti] provides a good framework 44 to implement signature service in the context of MIME[MIME]. The 45 first part of "Multipart/Signed" contains a MIME object to be 46 protected by signature(s) and the second embeds the 47 signature(s). Some protocols such as MOSS[MOSS] and S/MIME[S/MIME] 48 define their signature service on "Multipart/Signed". 49 PGP/MIME[PGP/MIME] also makes use of "Multipart/Signed" for PGP[PGP] 50 signature service with detached signature. 52 "Multipart/Signed" itself does not define the format of the second 53 part but allows each protocol to do so. PGP/MIME specifies that the 54 second part contains exactly one signature indicated by the "micalg" 55 parameter where "pgp-md5" and "pgp-sha1" are reserved so far. The 56 PGP program has used MD5[MD5] as the default hash function. So, it 57 is reasonable for PGP/MIME to define that the second part contains 58 one PGP signature identified by "pgp-md5". 60 Resent cryptanalysis shows, however, that the strength of MD5 is 61 suspicious. So, some users want to use another hash function such as 62 SHA1[SHA1] which is believed strong enough. To maintain backward 63 compatibilities, it is desired to deliver both the de-fact standard 64 signature and new strong ones at the same time. This memo thus 65 discusses how to embed multiple PGP signatures in the context of 66 "Multipart/Signed". 68 PGP/MIME defines canonical format for signature as 7bit-encoded MIME 69 format. However, for some kinds of MIME objects more specific 70 canonicalization is necessary. This memo also discusses how to 71 support such specific canonicalization. 73 The Multipart/PGP-Signature Content Type. 75 "Multipart/Signed" objects which conforms this memo MUST have the 76 "protocol" parameter whose value is "Multipart/PGP-Signature". The 77 content type of their second part MUST be "Multipart/PGP-Signature". 78 The content type of each part in "Multipart/PGP-Signature" MUST be 79 "Application/PGP-Signature". 81 The value of the "micalg" parameter of "Multipart/Signed" MUST be a 82 comma separated list of tokens. Each token specifies signature type 83 of regarding part of "Multipart/PGP-Signature". The number of the 84 tokens MUST be greater than or equal to 2. The number of parts in 85 "Multipart/PGP-Signature" MUST be equal to that of the tokens. Each 86 "Application/PGP-Signature" part MUST have the "micalg" parameter 87 whose value is the same as the regarding token. 89 For instance, if the "micalg" parameter is '"pgp-md5","pgp-sha1"', 90 the first part of "Multipart/PGP-Signature" contains a PGP signature 91 with MD5. Its "micalg" parameter is "pgp-md5". And the second embeds 92 a PGP signature with SHA1 whose "micalg" parameter is "pgp-sha1". 94 The following shows the entire format of the example. 96 Content-Type: Multipart/Signed; boundary="rfc1847"; 97 protocol="Multipart/PGP-Signature"; 98 micalg="pgp-md5","pgp-sha1" 100 --rfc1847 101 Content-Type: text/plain; charset=us-ascii 103 This is a text message to be signed. 105 --rfc1847 106 Content-Type: Multipart/PGP-Signature; boundary="thismemo" 108 --thismemo 109 Content-Type: Application/PGP-Signature; micalg="pgp-md5" 111 SIGNATURE WITH PGP/MD5 113 --thismemo 114 Content-Type: Application/PGP-Signature; micalg="pgp-sha1" 116 SIGNATURE WITH PGP/SHA1 118 --thismemo-- 120 --rfc1847-- 122 The Canonicalization Format Extension 124 Section 2.1 of RFC1487 defines three steps to create a 125 "Multipart/Signed" part. 127 (1) An object to be signed is transformed into a MIME canonical 128 form. It has an appropriate set of MIME headers. It is 129 constrained to be in 7 bits if it is ever to be transferred 130 via SMTP. All line delimiters must be . 132 (2) The MIME canonical form is converted according to the value 133 of the "protocol" parameter. 135 (3) A "Multipart/Signed" part is created over the prepared 136 object. 138 Section 5 of RFC2015 does not specify any PGP/MIME specific 139 transform for step (2) above. 141 For some objects to be signed, typically ISO 2022 family text, more 142 specific canonicalization than defined in step (1) is necessary. To 143 support this kind of specific canonicalization, the 144 "pgp-" syntax of the "micalg" parameter token is 145 extended as follows: 147 "pgp-+" 149 Here "" indicates type of the specific 150 canonicalization which may be defined in other RFCs. An example is 151 found in [JMSG]. For this extension, plus ("+") symbol MUST NOT be 152 used in "" nor "". This extension is 153 allowed only if the "micalg" parameter is a comma separated list of 154 tokens(i.e only if the value of the "protocol" parameter is 155 "Multipart/PGP-Signature.). 157 The canonicalization indicated by "" MUST be carried 158 out as step (3.5) in Section 5 of RFC2015. 160 Verification and Error Handling 162 Each verification typically results in the followings: 164 - Succeeded 165 Hash value calculated over the first part of 166 "Multipart/Signed" matched one in the signature. 167 - Failure 168 Hash value calculated over the first part of 169 "Multipart/Signed" did not match one in the signature. 170 - Unknown 171 Did not verify since the value of the "micalg" is 172 unknown. 174 User agents which conforms this memo MUST tell users results of 175 every signature verifications upon request. 177 User agents MUST stop verification process if one or more of the 178 following errors occur: 180 - The number of parts in "Multipart/PGP-Signature" is not the 181 same as that of tokens specified for the "micalg" parameter 182 of "Multipart/Signed". 183 - The content type of parts in "Multipart/PGP-Signature" is not 184 "Application/PGP-Signature". 185 - The content type "Application/PGP-Signature" does not have 186 the "micalg" parameter. 187 - The "micalg" parameter of "Application/PGP-Signature" is 188 different from the regarding token. 189 - The value of the "micalg" parameter of "Multipart/Signed" 190 ends with comma. 192 User agents MUST tells users failure of the verification process and 193 MUST tell users, upon request, why the verification process stopped. 195 IMPLEMENTATION NOTE 197 The PGP signature format specified in [PGP] is categorized into 198 "binary image" and "canonical text". If the "-t" option is 199 specified and the PGP program guesses the object to be signed is 200 text, the PGP program itself converts line delimiters of the 201 object into . Then it calculates a signature over the 202 converted object and specifies "canonical text" mark on the 203 signature. Otherwise, the PGP program calculates a signature 204 over the original object then specifies "binary image" mark on 205 the signature. 207 On verification, if the signature tells "canonical text", the 208 PGP program first converts line delimiters of the target object 209 into then verifies. Otherwise verification is carried 210 out over the original object. 212 RFC2015 does not limit type of PGP signatures, so both "binary 213 image" and "canonical text" are valid. 215 If a user agent itself converts line delimiters of an object to 216 be signed into then calls the PGP program without the 217 "-t" option, the signature is produced as "binary image" even if 218 the object is a line-based text object. Please not that this 219 signature is valid in the context of PGP/MIME and signature 220 verification should success. If another user agent, 221 particularly on UNIX whose line delimiter is , calls the PGP 222 program without line delimiter conversion, the verification 223 fails because the PGP program never converts line delimiters. 225 So, to verify PGP signature, user agents MUST convert line 226 delimiters of the first part to by itself. 228 Discussion Items 230 - The "micalg" parameter of "Application/PGP-Signature" is 231 necessary? 233 Security Considerations 235 This entire memo is about security. 237 Acknowledgements 239 The author thank to Hidenori Ohta and Shigeya Suzuki for their 240 feedback for early versions of this draft. 242 References 244 [SecMulti] J. Galvin, S. Murphy, S. Crocker, and N. Freed, "Security 245 Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", 246 August 1995. 248 [MIME] N. Freed and N. Borenstein, "Multipurpose Internet Mail 249 Extensions (MIME) Part One: Format of Internet Message Bodies", 250 RFC2045, December 1996. 252 [MOSS] S. Crocker, N. Freed, J. Galvin and S. Murphy, "MIME Object 253 Security Services", RFC1848 October 1995. 10/03/1995. 255 [S/MIME] Steve Dusse, Paul Hoffman, Blake Ramsdell, Laurence 256 Lundblade and Lisa Repka, "S/MIME Message Specification", 258 [PGP/MIME] M. Elkins, "MIME Security with Pretty Good Privacy 259 (PGP)", RFC2015, October 1996. 261 [PGP] D. Atkins, W. Stallings and P. Zimmermann, "PGP Message 262 Exchange Formats", RFC1991, August 1996. 264 [MD5] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 265 1992. 267 [SHA1] "Secure Hash Standard", National Institute of Standards and 268 Technology, U.S. Department Of Commerce, April 1995. 270 [JMSG] Kazu Yamamoto, "Japanese Message Signing Procedure with 271 Security Multipart", Internet Draft, 272 , May 1997. 274 Author's Address 276 Kazuhiko YAMAMOTO 277 Graduate School of Information Science 278 Nara Institute of Science and Technology(NAIST) 279 8916-5 Takayama, Ikoma City 630-01 JAPAN 281 Phone: +81-7437-2-5111 282 FAX: +81-7437-2-5329 283 EMail: Kazu@Mew.org