Internet-Draft Kazu Yamamoto NAIST Expires in six months May, 1997 Multi-signature Extensions for PGP/MIME Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract PGP/MIME provides single signature service of PGP in the context of MIME, however, multiple signature service is desired for usability and flexibility. For this purpose, this memo defines "Multipart/PGP-Signature" used as the "protocol" parameter and the content type of the second part of "Multipart/Signed". Canonical MIME format used in PGP/MIME is reasonable but it is not enough for some kinds of MIME objects, particularly for ISO 2022 text. Thus, this memo extends the "micalg" parameter syntax as "pgp-+" so that can specify more specific canonicalization for signature calculation. Introduction "Multipart/Signed" defined in [SecMulti] provides a good framework to implement signature service in the context of MIME[MIME]. The first part of "Multipart/Signed" contains a MIME object to be protected by signature(s) and the second embeds the signature(s). Some protocols such as MOSS[MOSS] and S/MIME[S/MIME] define their signature service on "Multipart/Signed". PGP/MIME[PGP/MIME] also makes use of "Multipart/Signed" for PGP[PGP] signature service with detached signature. "Multipart/Signed" itself does not define the format of the second part but allows each protocol to do so. PGP/MIME specifies that the Yamamoto [Page 1] Internet-Draft Multi-signature for PGP/MIME May 1997 second part contains exactly one signature indicated by the "micalg" parameter where "pgp-md5" and "pgp-sha1" are reserved so far. The PGP program has used MD5[MD5] as the default hash function. So, it is reasonable for PGP/MIME to define that the second part contains one PGP signature identified by "pgp-md5". Resent cryptanalysis shows, however, that the strength of MD5 is suspicious. So, some users want to use another hash function such as SHA1[SHA1] which is believed strong enough. To maintain backward compatibilities, it is desired to deliver both the de-fact standard signature and new strong ones at the same time. This memo thus discusses how to embed multiple PGP signatures in the context of "Multipart/Signed". PGP/MIME defines canonical format for signature as 7bit-encoded MIME format. However, for some kinds of MIME objects more specific canonicalization is necessary. This memo also discusses how to support such specific canonicalization. The Multipart/PGP-Signature Content Type. "Multipart/Signed" objects which conforms this memo MUST have the "protocol" parameter whose value is "Multipart/PGP-Signature". The content type of their second part MUST be "Multipart/PGP-Signature". The content type of each part in "Multipart/PGP-Signature" MUST be "Application/PGP-Signature". The value of the "micalg" parameter of "Multipart/Signed" MUST be a comma separated list of tokens. Each token specifies signature type of regarding part of "Multipart/PGP-Signature". The number of the tokens MUST be greater than or equal to 2. The number of parts in "Multipart/PGP-Signature" MUST be equal to that of the tokens. Each "Application/PGP-Signature" part MUST have the "micalg" parameter whose value is the same as the regarding token. For instance, if the "micalg" parameter is '"pgp-md5","pgp-sha1"', the first part of "Multipart/PGP-Signature" contains a PGP signature with MD5. Its "micalg" parameter is "pgp-md5". And the second embeds a PGP signature with SHA1 whose "micalg" parameter is "pgp-sha1". The following shows the entire format of the example. Content-Type: Multipart/Signed; boundary="rfc1847"; protocol="Multipart/PGP-Signature"; micalg="pgp-md5","pgp-sha1" --rfc1847 Content-Type: text/plain; charset=us-ascii This is a text message to be signed. --rfc1847 Yamamoto [Page 2] Internet-Draft Multi-signature for PGP/MIME May 1997 Content-Type: Multipart/PGP-Signature; boundary="thismemo" --thismemo Content-Type: Application/PGP-Signature; micalg="pgp-md5" SIGNATURE WITH PGP/MD5 --thismemo Content-Type: Application/PGP-Signature; micalg="pgp-sha1" SIGNATURE WITH PGP/SHA1 --thismemo-- --rfc1847-- The Canonicalization Format Extension Section 2.1 of RFC1487 defines three steps to create a "Multipart/Signed" part. (1) An object to be signed is transformed into a MIME canonical form. It has an appropriate set of MIME headers. It is constrained to be in 7 bits if it is ever to be transferred via SMTP. All line delimiters must be . (2) The MIME canonical form is converted according to the value of the "protocol" parameter. (3) A "Multipart/Signed" part is created over the prepared object. Section 5 of RFC2015 does not specify any PGP/MIME specific transform for step (2) above. For some objects to be signed, typically ISO 2022 family text, more specific canonicalization than defined in step (1) is necessary. To support this kind of specific canonicalization, the "pgp-" syntax of the "micalg" parameter token is extended as follows: "pgp-+" Here "" indicates type of the specific canonicalization which may be defined in other RFCs. An example is found in [JMSG]. For this extension, plus ("+") symbol MUST NOT be used in "" nor "". This extension is allowed only if the "micalg" parameter is a comma separated list of tokens(i.e only if the value of the "protocol" parameter is "Multipart/PGP-Signature.). The canonicalization indicated by "" MUST be carried out as step (3.5) in Section 5 of RFC2015. Yamamoto [Page 3] Internet-Draft Multi-signature for PGP/MIME May 1997 Verification and Error Handling Each verification typically results in the followings: - Succeeded Hash value calculated over the first part of "Multipart/Signed" matched one in the signature. - Failure Hash value calculated over the first part of "Multipart/Signed" did not match one in the signature. - Unknown Did not verify since the value of the "micalg" is unknown. User agents which conforms this memo MUST tell users results of every signature verifications upon request. User agents MUST stop verification process if one or more of the following errors occur: - The number of parts in "Multipart/PGP-Signature" is not the same as that of tokens specified for the "micalg" parameter of "Multipart/Signed". - The content type of parts in "Multipart/PGP-Signature" is not "Application/PGP-Signature". - The content type "Application/PGP-Signature" does not have the "micalg" parameter. - The "micalg" parameter of "Application/PGP-Signature" is different from the regarding token. - The value of the "micalg" parameter of "Multipart/Signed" ends with comma. User agents MUST tells users failure of the verification process and MUST tell users, upon request, why the verification process stopped. IMPLEMENTATION NOTE The PGP signature format specified in [PGP] is categorized into "binary image" and "canonical text". If the "-t" option is specified and the PGP program guesses the object to be signed is text, the PGP program itself converts line delimiters of the object into . Then it calculates a signature over the converted object and specifies "canonical text" mark on the signature. Otherwise, the PGP program calculates a signature over the original object then specifies "binary image" mark on the signature. On verification, if the signature tells "canonical text", the PGP program first converts line delimiters of the target object into then verifies. Otherwise verification is carried out over the original object. RFC2015 does not limit type of PGP signatures, so both "binary Yamamoto [Page 4] Internet-Draft Multi-signature for PGP/MIME May 1997 image" and "canonical text" are valid. If a user agent itself converts line delimiters of an object to be signed into then calls the PGP program without the "-t" option, the signature is produced as "binary image" even if the object is a line-based text object. Please not that this signature is valid in the context of PGP/MIME and signature verification should success. If another user agent, particularly on UNIX whose line delimiter is , calls the PGP program without line delimiter conversion, the verification fails because the PGP program never converts line delimiters. So, to verify PGP signature, user agents MUST convert line delimiters of the first part to by itself. Discussion Items - The "micalg" parameter of "Application/PGP-Signature" is necessary? Security Considerations This entire memo is about security. Acknowledgements The author thank to Hidenori Ohta and Shigeya Suzuki for their feedback for early versions of this draft. References [SecMulti] J. Galvin, S. Murphy, S. Crocker, and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", August 1995. [MIME] N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC2045, December 1996. [MOSS] S. Crocker, N. Freed, J. Galvin and S. Murphy, "MIME Object Security Services", RFC1848 October 1995. 10/03/1995. [S/MIME] Steve Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade and Lisa Repka, "S/MIME Message Specification", Internet Draft, , May 1997 [PGP/MIME] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", RFC2015, October 1996. [PGP] D. Atkins, W. Stallings and P. Zimmermann, "PGP Message Yamamoto [Page 5] Internet-Draft Multi-signature for PGP/MIME May 1997 Exchange Formats", RFC1991, August 1996. [MD5] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [SHA1] "Secure Hash Standard", National Institute of Standards and Technology, U.S. Department Of Commerce, April 1995. [JMSG] Kazu Yamamoto, "Japanese Message Signing Procedure with Security Multipart", Internet Draft, , May 1997. Author's Address Kazuhiko YAMAMOTO Graduate School of Information Science Nara Institute of Science and Technology(NAIST) 8916-5 Takayama, Ikoma City 630-01 JAPAN Phone: +81-7437-2-5111 FAX: +81-7437-2-5329 EMail: Kazu@Mew.org Yamamoto [Page 6]