Internet-Draft Kazu Yamamoto draft-kazu-jmsg-sign-00.txt NAIST Expires in six months June, 1996 Japanese Message Signing Procedure 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 ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo proposes a signing procedure for Japanese message. The procedure guarantees signature validity even 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, then duplicated into two objects. The first object is transformed into the signature form proposed in this memo and a detached digital signature is calculated over it. An entire digital signature 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, is used. Background 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 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 Yamamoto [Page 1] INTERNET-DRAFT Japanese Signature June 1996 to that of JIS X0208-1978 and vice versa. This causes a significant problem for digital signature service provided by MOSS[MOSS], PGP[PGP], 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. Since ISO-2022-JP does not define the rule of handling between multiple character sets, the verification of digital signature may fail. This memo proposes a signing procedure for Japanese message. The procedure guarantees signature validity even messages are processed through MTAs which carelessly transform character set encodings. Signing procedure for Japanese text This memo proposes 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 to be proposed 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 the transfer form, ISO-2022-JP. (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 . 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 \ Yamamoto [Page 2] INTERNET-DRAFT Japanese Signature June 1996 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. (7) An entire digital signature to be sent is created from the second transfer form object and the detached digital signature. 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 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, MUA implementors should clearly explain indistinguishability between different character sets to users in its document, and are encouraged to design MUAs to notify users at the signing process if messages contain such indistinguishable characters. Verifying procedure for Japanese text The verifying procedure to be proposed is as follows: (1) Received text to be verified is prepared. Yamamoto [Page 3] INTERNET-DRAFT Japanese Signature June 1996 (2) Japanese text and the signature is separated. 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. (3) The Japanese text is duplicated into two Japanese text objects. The first text object will be displayed to a user and the second one will be used for verification. (4) The second text object is converted into the signature form described in the signing procedure. (5) The signature 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. Encrypting and decrypting procedure The transfer form, ISO-2022-JP, provides a sufficient canonicalization for Japanese text. Line delimiters must be transformed into . Sign-AND-Encrypting procedure Some system (like PGP) provide sign-AND-encrypt services. The process of sign-AND-encrypt service seems atomic to users, though, it has internally a signing stage and an encrypting stage. The signing procedure proposed in this memo must be applied to the signing stage of sign-AND-encrypt service. Security Considerations The proposed signing procedure makes it possible to distinguish alteration by a third person and mapping of character set encoding by MTAs. Acknowledgements First and foremost, the author acknowledges Noriyuki SODA for his big contribution to develop the signing scheme. The author hereby thanks 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 Yamamoto [Page 4] INTERNET-DRAFT Japanese Signature June 1996 EMail: kazu@is.aist-nara.ac.jp 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. [PGP] P. Zimmermann, "The Official PGP User's Guide", MIT Press, 1995. [MOSS] S. Crocker, N. Freed, J. Galvin, and S. Murphy, "MIME Object Security Services", RFC1848, October 1995. Appendix A /* * 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 Yamamoto [Page 5] INTERNET-DRAFT Japanese Signature June 1996 # define EXIT_ERROR 1 #endif #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); Yamamoto [Page 6] INTERNET-DRAFT Japanese Signature June 1996 } else { esc_unknown(); if (state == SINGLE) { putchar(ESC); putchar(DOUBLE); putchar(c); state = DOUBLE; } } } else { esc_unknown(); putchar(ESC); putchar(c); /* Keep state. */ } } else putchar(c); } exit(EXIT_SUCCESS); } Yamamoto [Page 7]