Internet-Draft Kazu Yamamoto NAIST Expires in six months May, 1997 Japanese Message Signing Procedure with Security Multipart 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 This memo defines a signing procedure for Japanese message in the context of security multipart. The procedure guarantees signature validity even if messages are processed through message transfer agents which carelessly transform character set encodings. To sign Japanese message digitally, local forms such as EUC/Japanese, Shift-JIS, etc., are first converted into the transfer form, ISO-2022-JP with an appropriate set of MIME headers. Then it is duplicated into two objects. The first object is transformed into the signature form defined in this memo and a detached digital signature is calculated over it. A "Multipart/Signed" part is created with the second object and the detached digital signature. Japanese text is verified as the signature form instead of the transfer form. To encrypt Japanese message, the transfer form, ISO-2022-JP with an appropriate set of MIME headers, is used. Introduction ISO-2022-JP[ISO-2022-JP], the character set encoding to transfer Japanese message, can encode four character sets, ASCII[ASCII], JIS X0201-1976[JISX201], JIS X0208-1978, and JIS X0208-1983[JISX0208]. So, ISO-2022-JP maintains backward compatibility to JIS X0208-1978. Since ASCII and JIS X0208-1983 are interchangeable with JIS X0201-1976 and JIS X0208-1978 respectively, some message transfer Yamamoto [Page 1] Internet-Draft Japanese Signature within MIME May 1997 agents(MTA) and message user agents(MUA) carelessly convert escape sequence of ASCII to that of JIS X0201-1976 and vice versa. Likewise they carelessly transform escape sequence of JIS X0208-1983 to that of JIS X0208-1978 and vice versa. This causes a significant problem for digital signature service provided by MOSS[MOSS], PGP/MIME[PGP/MIME], etc., in Japanese environment. For example, a recipient may receive ISO-2022-JP text which contains different character sets(such as ASCII) from the original character sets(such as JIS X0201-1976) created by the originator because intermediate MTAs may map to different character encoding. So, the verification of digital signature may fail. This memo defines a signing procedure for Japanese message in the context of security multipart[SecMulti]. The procedure guarantees signature validity even messages are processed through MTAs which carelessly transform character set encodings. Signing Procedure for Japanese Text This memo defines an ISO-2022-JP signature form that uses only ASCII and JIS X0208-1983. This does not mean that JIS X0201-1976 and JIS X0208-1978 cannot be transferred as Japanese text. Rather, allowing all character sets of ISO-2022-JP, the form gets rid of ambiguity of ISO-2022-JP for signature service. The signing procedure for Japanese text is as follows: (1) Japanese text to be signed is prepared as a local form such as ISO-2022-JP, EUC/Japanese, Shift-JIS, etc. (2) The local form is converted to ISO-2022-JP. Then an appropriate set of MIME headers is prepended. This is called transfer form. An example of MIME header set is as follows: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Please note if the value of the content transfer encoding is which MTAs never converts, "base64" for instance, the procedure specified in this memo is not necessary. (3) The transfer form is duplicated into two objects. The first transfer form object will be used to calculate a digital signature and the second one will be sent. (4) The first transfer form object is converted to the signature form. That is, the escape sequences for JIS X0201-1976 ("(J") is transformed into that of ASCII ("(B"). Likewise, the escape sequences for JIS X0208-1978 ("$@") is converted to that of JIS X0208-1983 ("$B"). Line delimiters MUST be transformed into . Yamamoto [Page 2] Internet-Draft Japanese Signature within MIME May 1997 Example 1: $B ;3 K\ (B $@ OB I' (B This example MUST be converted into the following sequence. $B ;3 K\ (B $B OB I' (B Example 2: (J (B \ This example MUST be converted into the following sequence. (B \ (B \ (5) Redundant escape sequences to cause unnecessary character set switches are eliminated. Example 1 includes the escape sequences considered redundant, which are indicated by '^' symbols. $B ;3 K\ (B $B OB I' (B ^^^^^^^ ^^^^^^^ This example MUST be converted into the following sequence. $B ;3 K\ OB I' (B Example 2 also includes the escape sequences considered redundant, which are indicated by '^' symbols. (B \ (B \ ^^^^^^^ This example MUST be converted into the following sequence. (B \ \ Note that an example converter for the signature form is contained in Appendix A. (6) A detached digital signature is calculated over the signature form according to the "protocol" parameter. (7) A "Multipart/Signed" part to be sent is created from the second transfer form object and the detached digital signature according to the "protocol" parameter. Note that step (4) is an one-way, non-reversible procedure. So, duplication in step (3) is essential. In this signature method, different characters which are assigned to the same code in different character sets cannot be distinguished from each other. One of the examples is the characters assigned to code 0x5c (in hexadecimal), which is a backslash in US-ASCII and a Yamamoto [Page 3] Internet-Draft Japanese Signature within MIME May 1997 Yen (Japanese currency unit) in JIS X0201-1976. The similar cases can also be found between some codes in JIS X0208-1978 and JIS X0208-1983. So, multiple signature services are encouraged. That is, one signature is calculated over the transfer form object and the other is over the signature form object. If necessary, indication of this procedure is labeled as "iso-2022-jp" (case-insensitive). An example is given in Appendix B. Verifying Procedure for Japanese Text If a "Multipart/Signed" part contains signature(s) created by the procedure above, the following procedure is processed to verify the signature(s): (1) The first part of the "Multipart/Signed" part to be verified is extracted. This MUST be labeled as follows: Content-Type: text/plain; charset=iso-2022-jp (2) The part is duplicated into two objects. The first object will be displayed to a user and the second one will be used for verification. (3) The second object is converted the transfer form. This Japanese text may be a local form such as EUC/Japanese, Shift-JIS, etc., since a local MTA may have converted the transfer form to the local form. So, it MUST be converted into ISO-2022-JP if it is not. Line delimiters MUST be transformed into . (4) The second object is converted into the signature form described in the signing procedure. (5) The signature in the second part of "Multipart/Signed" is verified with the signature form. Even if intermediate MTAs map a character encoding to another, verification succeeds with this procedure since the originator and the receiver(s) deal with the identical, unambiguous signature form. In some cases of multiple signature services above, it is likely to happen that verification fails for the signature of the transfer form object but succeeds for that of the signature form object. In this case, MUAs should tell users that the former failure is probably because that intermediate MTA(s) converted character sets. Encrypting and Decrypting Procedure The transfer form, ISO-2022-JP with an appropriate set of MIME Yamamoto [Page 4] Internet-Draft Japanese Signature within MIME May 1997 headers, provides a sufficient canonicalization for Japanese text. Line delimiters MUST be transformed into . Sign-AND-Encrypting Procedure Some system (like PGP[PGP]) provide sign-AND-encrypt services. The procedure defined in this memo is not applicable to the sign-AND-encrypt services. If both signature service and encryption service is necessary, first create a "Multipart/Signed" part then produce a "Multipart/Encrypted" part with it as described in [SecMulti]. Security Considerations The signing procedure defined in this memo makes it possible to distinguish alteration by a third person and mapping of character set encoding by MTAs. Acknowledgements The author acknowledges Noriyuki Soda for his big contribution to develop the signing scheme. The author thanks to Japanese message working group for valuable comments and feedback. 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 References [ISO-2022-JP] J. Murai, M Crispin, and E. van der Poel, "Japanese Character Encoding for Internet Messages", RFC1468, June 1993. [ASCII] Coded Character Set--7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986. [JISX0201] Japanese Standards Association, "Code for Information Interchange", JIS X 0201-1976. [JISX0208] Japanese Standards Association, "Code of the Japanese graphic character set for information interchange", JIS X 0208-1978, -1983 and -1990. Yamamoto [Page 5] Internet-Draft Japanese Signature within MIME May 1997 [MOSS] S. Crocker, N. Freed, J. Galvin, and S. Murphy, "MIME Object Security Services", RFC1848, October 1995. [PGP/MIME] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", RFC2015, October 1996. [SecMulti] J. Galvin, S. Murphy, S. Crocker, and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", August 1995. [PGP] P. Zimmermann, "The Official PGP User's Guide", MIT Press, 1995. [MPM] Kazu Yamamoto, "Multi-signature Extensions for PGP/MIME", Internet Draft, , May 1997. Appendix A Here is an example code for canonicalization specified in this memo. /* * jaca.c :: JApanese message CAnonicalization filter * This program assumes that standard input is ISO-2022-JP. * * Copyright (C) 1996 Kazu Yamamoto, WIDE Project * * This software is distributed in the hope that it will be usefull, but * NO WARRANTY. * * Create: June 3, 1996 * Revised: * Version: 0.1 * Email: kazu@is.aist-nara.ac.jp */ #include #define ESC 27 #define SINGLE '(' #define ASC 'B' #define X201 'J' #define DOUBLE '$' #define X20878 '@' #define X20883 'B' #ifndef EXIT_SUCCESS # define EXIT_SUCCESS 0 #endif #ifndef EXIT_ERROR # define EXIT_ERROR 1 #endif Yamamoto [Page 6] Internet-Draft Japanese Signature within MIME May 1997 #define esc_error() fprintf(stderr,\ "Illegal escape sequence for ISO-2022-JP\n") #define esc_unknown() fprintf(stderr,\ "Unknown escape sequence for ISO-2022-JP\n") int state = SINGLE; main () { int c; while ((c = getchar()) != EOF) { if (c == ESC) { if ((c = getchar()) == EOF) { esc_error(); exit(EXIT_ERROR); } else if (c == SINGLE) { if ((c = getchar()) == EOF) { esc_error(); exit(EXIT_ERROR); } else if ((c == ASC) || (c == X201)) { if (((c = getchar()) != ESC) && (state == DOUBLE)) { putchar(ESC); putchar(SINGLE); putchar(ASC); state = SINGLE; } /* else {keep state.} */ ungetc(c, stdin); } else { esc_unknown(); if (state == DOUBLE) { putchar(ESC); putchar(SINGLE); putchar(c); state = SINGLE; } } } else if (c == DOUBLE) { if ((c = getchar()) == EOF) { esc_error(); exit(EXIT_ERROR); } else if ((c == X20878) || (c == X20883)) { if (((c = getchar()) != ESC) && (state == SINGLE)) { putchar(ESC); putchar(DOUBLE); putchar(X20883); state = DOUBLE; } /* else {keep state.} */ ungetc(c, stdin); } else { esc_unknown(); if (state == SINGLE) { Yamamoto [Page 7] Internet-Draft Japanese Signature within MIME May 1997 putchar(ESC); putchar(DOUBLE); putchar(c); state = DOUBLE; } } } else { esc_unknown(); putchar(ESC); putchar(c); /* Keep state. */ } } else putchar(c); } exit(EXIT_SUCCESS); } Appendix B Here is an example of a signature service applied the procotol described in [MPM]. Content-Type: Multipart/Signed; boundary="rfc1847"; protocol="Multipart/PGP-Signature"; micalg="pgp-md5","pgp-md5+iso-2022-jp" --rfc1847 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit This is a ISO-2022-JP text object to be signed. --rfc1847 Content-Type: Multipart/PGP-Signature; boundary="pgpmime" --pgpmime Content-Type: application/pgp-signature; micalg="pgp-md5" SIGNATURE WITH PGP OVER TRANSFER FORM --pgpmime Content-Type: application/pgp-signature; micalg="pgp-md5+iso-2022-jp" SIGNATURE WITH PGP OVER SIGNATURE FORM DEFINED IN THIS MEMO --pgpmime-- --rfc1847-- Yamamoto [Page 8]