From owner-ietf-ediint Thu Jan 2 17:56:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id RAA04757 for ietf-ediint-bks; Thu, 2 Jan 1997 17:56:20 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from ktnet.ktnet.co.kr (ktnet.ktnet.co.kr [203.248.73.1]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id RAA04753 for ; Thu, 2 Jan 1997 17:56:17 -0800 (PST) Received: from ktnet.co.kr.ktnet.co.kr ([203.242.136.114]) by ktnet.ktnet.co.kr (8.7.1H1/8.7.1) with SMTP id KAA10552 for ; Fri, 3 Jan 1997 10:54:51 +0900 (KST) Message-ID: <32CC671A.572C@ktnet.co.kr> Date: Fri, 03 Jan 1997 10:55:38 +0900 From: KANG SUNG WOOK Reply-To: swkang@ktnet.co.kr Organization: KTNET X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: ietf-ediint@imc.org Subject: request for subscription Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk subsribe From owner-ietf-ediint Thu Jan 2 17:57:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id RAA04773 for ietf-ediint-bks; Thu, 2 Jan 1997 17:57:51 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from ktnet.ktnet.co.kr (ktnet.ktnet.co.kr [203.248.73.1]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id RAA04769 for ; Thu, 2 Jan 1997 17:57:48 -0800 (PST) Received: from ktnet.co.kr.ktnet.co.kr ([203.242.136.114]) by ktnet.ktnet.co.kr (8.7.1H1/8.7.1) with SMTP id KAA10598 for ; Fri, 3 Jan 1997 10:56:22 +0900 (KST) Message-ID: <32CC6775.643@ktnet.co.kr> Date: Fri, 03 Jan 1997 10:57:09 +0900 From: KANG SUNG WOOK Reply-To: swkang@ktnet.co.kr Organization: KTNET X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: ietf-ediint@imc.org Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk set ietf-edi mail digest From owner-ietf-ediint Fri Jan 3 02:27:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id CAA09459 for ietf-ediint-bks; Fri, 3 Jan 1997 02:27:27 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12]) by mail.proper.com (8.8.4/8.7.3) with SMTP id CAA09455 for ; Fri, 3 Jan 1997 02:27:24 -0800 (PST) Received: from dal-tx2-59.ix.netcom.com (jwkckid1@dal-tx2-59.ix.netcom.com [207.94.120.187]) by dfw-ix12.ix.netcom.com (8.6.13/8.6.12) with SMTP id CAA22321 for ; Fri, 3 Jan 1997 02:26:39 -0800 Message-ID: <32CC8928.64A9@ix.netcom.com> Date: Fri, 03 Jan 1997 04:20:56 +0000 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.0Gold (Win16; I) MIME-Version: 1.0 To: ietf-ediint@imc.org Subject: Current EDi bit size restrictions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk All, Can any one give a clear difinitive answer to what the current ITAR or intrenational import/export restrictions are on Authentication Certs or other mechnisms? WHat are some good pointers that outline this. Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. Phone :972-447-1878 E-Mail jwkckid1@ix.netcom.com From owner-ietf-ediint Fri Jan 3 15:50:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id PAA18880 for ietf-ediint-bks; Fri, 3 Jan 1997 15:50:14 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from gatekeeper.premenos.com (mail.premenos.com [150.105.250.1]) by mail.proper.com (8.8.4/8.7.3) with SMTP id PAA18876 for ; Fri, 3 Jan 1997 15:50:11 -0800 (PST) Received: from karenr (karenr.premenos.com [150.105.100.205]) by gatekeeper.premenos.com (8.6.5/8.6.5) with SMTP id PAA14935; Fri, 3 Jan 1997 15:52:02 -0800 Message-ID: <32CD6FFE.7D9E@premenos.com> Date: Fri, 03 Jan 1997 15:45:50 -0500 From: Karen Rosenthal Reply-To: karenr@premenos.com Organization: Premenos X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: ietf-ediint@imc.org CC: smime-dev@rsa.com Subject: MDN Signed Body Part Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk In draft-ietf-ediint-as1-02.txt, the Content-Type of the second body part is specified as application/x-pkcs7-mime. Is this correct, or should application/x-pkcs7-signature be used? The 2/23/96 S/MIME Message Specification defines application/x-pkcs7-signature as the PKCS #7 detached signature. Regards, -- Name: Karen Rosenthal E-mail: karenr@premenos.com Phone: (510)688-2928 Fax: (510)602-2133 From owner-ietf-ediint Fri Jan 3 17:07:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id RAA19746 for ietf-ediint-bks; Fri, 3 Jan 1997 17:07:37 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.4/8.7.3) with SMTP id RAA19742 for ; Fri, 3 Jan 1997 17:07:34 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA21764 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Fri, 3 Jan 1997 17:06:56 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA24857; Fri, 3 Jan 97 15:51:16 PST Newsgroups: lists.ietf-ediint Path: carl From: carl@chage.com (Carl Hage) Subject: Re: Current EDi bit size restrictions Message-Id: <2q9r#rbn@chage.com> Date: Fri, 03 Jan 97 23:51:10 GMT Organization: C. Hage Associates, Sunnyvale, CA References: <32CC8928.64A9@ix.netcom.com> X-Newsreader: TIN [version 1.2 PL2] Apparently-To: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk Jeff Williams (jwkckid1@ix.netcom.com) wrote: : Can any one give a clear difinitive answer to what the current : ITAR or intrenational import/export restrictions are on Authentication : Certs or other mechnisms? WHat are some good pointers that outline : this. There is no restriction on bit length for digital signatures (authentication). As long as the US government can read your data, they don't care. As yet, they don't require the ability to forge your signature. This, of course requires separate keys for signatures and encryption, if you want exportable encryption algorithms, with secure signatures. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Sun Jan 5 02:19:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id CAA08290 for ietf-ediint-bks; Sun, 5 Jan 1997 02:19:05 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.4/8.7.3) with SMTP id CAA08286 for ; Sun, 5 Jan 1997 02:19:00 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA05377 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Sun, 5 Jan 1997 02:18:34 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA25376; Sat, 4 Jan 97 16:31:51 PST Date: Sat, 4 Jan 97 16:31:51 PST From: carl@chage.com (Carl Hage) Message-Id: <9701050031.AA25376@slick.chage.com> To: ietf-ediint@imc.org Subject: MDN Signed Body Part Sender: owner-ietf-ediint@imc.org Precedence: bulk Karen Rosenthal (karenr@premenos.com) wrote: : In draft-ietf-ediint-as1-02.txt, the Content-Type of the second body : part is specified as application/x-pkcs7-mime. Is this correct, or : should application/x-pkcs7-signature be used? The 2/23/96 S/MIME : Message Specification defines application/x-pkcs7-signature as the PKCS : #7 detached signature. This is an error in draft-ietf-ediint-as1-02.txt. There are two ways to sign data, either the embedded text form, where there is a single MIME type of application/x-pkcs7-mime, or the MIME multipart/signed, where the signature is separate from the text. In this case, the application/x-pkcs7-signature is the proper type. The first method has the original message encoded in binary form and requires PKCS software to decode. The second method works the same as the PGP/MIME except the PKCS7 signature algorithm is used instead of the PGP algorithm. Also, the original message is not encoded, and can be read separately from the authentication. In my opinion, the second form should be used, but apparently, the RSA toolkit doesn't make this easy. (???) -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Mon Jan 6 04:52:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id EAA19429 for ietf-ediint-bks; Mon, 6 Jan 1997 04:52:22 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id EAA19425 for ; Mon, 6 Jan 1997 04:52:19 -0800 (PST) Received: from drummond.onramp.net (ppp1-25.ftwotx.onramp.net [199.184.212.188]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id GAA02338; Mon, 6 Jan 1997 06:51:52 -0600 (CST) Message-ID: <32D0F562.E3F@onramp.net> Date: Mon, 06 Jan 1997 06:51:46 -0600 From: Rik Drummond Reply-To: drummond@onramp.net Organization: Drummond Group X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Carl Hage CC: ietf-ediint@imc.org Subject: Re: MDN Signed Body Part References: <9701050031.AA25376@slick.chage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Carl Hage wrote: > > Karen Rosenthal (karenr@premenos.com) wrote: > : In draft-ietf-ediint-as1-02.txt, the Content-Type of the second body > : part is specified as application/x-pkcs7-mime. Is this correct, or > : should application/x-pkcs7-signature be used? The 2/23/96 S/MIME > : Message Specification defines application/x-pkcs7-signature as the PKCS > : #7 detached signature. > > This is an error in draft-ietf-ediint-as1-02.txt. > > There are two ways to sign data, either the embedded text form, where > there is a single MIME type of application/x-pkcs7-mime, or the > MIME multipart/signed, where the signature is separate from the > text. In this case, the application/x-pkcs7-signature is the proper > type. > > The first method has the original message encoded in binary form and > requires PKCS software to decode. The second method works the same as > the PGP/MIME except the PKCS7 signature algorithm is used instead > of the PGP algorithm. Also, the original message is not encoded, and > can be read separately from the authentication. > > In my opinion, the second form should be used, but apparently, the RSA > toolkit doesn't make this easy. (???) > After the IETF meeting last month we will be doing the application/x-pkcs7-mime as the standard because it fits the Internet philosophy better than the other. As to the Commercenet test we are conducting on these standards, we will be using the other for the next several months because of how hard it is to do application/x-pkcs7-mime with the Smime toolkits.... later, rik From owner-ietf-ediint Mon Jan 6 09:30:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id JAA21648 for ietf-ediint-bks; Mon, 6 Jan 1997 09:30:12 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id JAA21644 for ; Mon, 6 Jan 1997 09:30:09 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA15014; Mon, 6 Jan 1997 09:28:29 -0800 Message-ID: <32D13545.3F8B@actracorp.com> Date: Mon, 06 Jan 1997 09:24:21 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: drummond@onramp.net CC: Carl Hage , ietf-ediint@imc.org Subject: Re: MDN Signed Body Part References: <9701050031.AA25376@slick.chage.com> <32D0F562.E3F@onramp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Rik, Just wanted to clarify: On sending the AS#1 will change to use the multipart/signed version of S/MIME instead of the signed-data version of S/MIME. This is as a result of the IETF wg in San Jose. The signed receipt has always been specified as using multipart/signed. Rik Drummond wrote: > > Carl Hage wrote: > > > > Karen Rosenthal (karenr@premenos.com) wrote: > > : In draft-ietf-ediint-as1-02.txt, the Content-Type of the second body > > : part is specified as application/x-pkcs7-mime. Is this correct, or > > : should application/x-pkcs7-signature be used? The 2/23/96 S/MIME > > : Message Specification defines application/x-pkcs7-signature as the PKCS > > : #7 detached signature. > > > > This is an error in draft-ietf-ediint-as1-02.txt. > > > > There are two ways to sign data, either the embedded text form, where > > there is a single MIME type of application/x-pkcs7-mime, or the > > MIME multipart/signed, where the signature is separate from the > > text. In this case, the application/x-pkcs7-signature is the proper > > type. > > > > The first method has the original message encoded in binary form and > > requires PKCS software to decode. The second method works the same as > > the PGP/MIME except the PKCS7 signature algorithm is used instead > > of the PGP algorithm. Also, the original message is not encoded, and > > can be read separately from the authentication. > > > > In my opinion, the second form should be used, but apparently, the RSA > > toolkit doesn't make this easy. (???) > > > After the IETF meeting last month we will be doing the > application/x-pkcs7-mime as the standard because it fits the Internet > philosophy better than the other. As to the Commercenet test we are > conducting on these standards, we will be using the other for the next > several months because of how hard it is to do application/x-pkcs7-mime > with the Smime toolkits.... later, rik From owner-ietf-ediint Mon Jan 6 09:20:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id JAA21541 for ietf-ediint-bks; Mon, 6 Jan 1997 09:20:15 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id JAA21537 for ; Mon, 6 Jan 1997 09:20:12 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA14717; Mon, 6 Jan 1997 09:18:32 -0800 Message-ID: <32D132F0.67E2@actracorp.com> Date: Mon, 06 Jan 1997 09:14:24 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Carl Hage CC: ietf-ediint@imc.org Subject: Re: MDN Signed Body Part References: <9701050031.AA25376@slick.chage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Carl and Karen, There is an error in draft-ietf-ediint-as1-02.txt and the signature part of the multipart/signed should indeed be application/x-pkcs-7-signature and not application/x-pkcs7-mime. This will be corrected. Note that on the signed receipt, multipart/signed will indeed be used and not S/MIME signed-data. This has always been the case. Carl Hage wrote: > > Karen Rosenthal (karenr@premenos.com) wrote: > : In draft-ietf-ediint-as1-02.txt, the Content-Type of the second body > : part is specified as application/x-pkcs7-mime. Is this correct, or > : should application/x-pkcs7-signature be used? The 2/23/96 S/MIME > : Message Specification defines application/x-pkcs7-signature as the PKCS > : #7 detached signature. > > This is an error in draft-ietf-ediint-as1-02.txt. > > There are two ways to sign data, either the embedded text form, where > there is a single MIME type of application/x-pkcs7-mime, or the > MIME multipart/signed, where the signature is separate from the > text. In this case, the application/x-pkcs7-signature is the proper > type. > > The first method has the original message encoded in binary form and > requires PKCS software to decode. The second method works the same as > the PGP/MIME except the PKCS7 signature algorithm is used instead > of the PGP algorithm. Also, the original message is not encoded, and > can be read separately from the authentication. > > In my opinion, the second form should be used, but apparently, the RSA > toolkit doesn't make this easy. (???) > -------------------------------------------------------------------------- > Carl Hage C. Hage Associates > Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 > Sunnyvale, CA 94086 From owner-ietf-ediint Mon Jan 6 10:06:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id KAA22117 for ietf-ediint-bks; Mon, 6 Jan 1997 10:06:48 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from gatekeeper.premenos.com (mail.premenos.com [150.105.250.1]) by mail.proper.com (8.8.4/8.7.3) with SMTP id KAA22113 for ; Mon, 6 Jan 1997 10:06:43 -0800 (PST) Received: from karenr (karenr.premenos.com [150.105.100.205]) by gatekeeper.premenos.com (8.6.5/8.6.5) with SMTP id KAA01440; Mon, 6 Jan 1997 10:07:37 -0800 Message-ID: <32D113BE.690@premenos.com> Date: Mon, 06 Jan 1997 10:01:18 -0500 From: Karen Rosenthal Reply-To: karenr@premenos.com Organization: Premenos X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: chucks@actracorp.com CC: ietf-ediint@imc.org Subject: Re: MDN Signed Body Part References: <9701050031.AA25376@slick.chage.com> <32D0F562.E3F@onramp.net> <32D13545.3F8B@actracorp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Two questions then. What is the rational for not supporting a receipt enveloped in S/MIME? We would like this option. Second, what is the working group's stance on supporting multipart/signed vs. S/MIME for data. Regards, Karen Chuck Shih wrote: > > Rik, > > Just wanted to clarify: > > On sending the AS#1 will change to use the multipart/signed version > of S/MIME instead of the signed-data version of S/MIME. This is as > a result of the IETF wg in San Jose. > > The signed receipt has always been specified as using multipart/signed. > > Rik Drummond wrote: > > > > Carl Hage wrote: > > > > > > Karen Rosenthal (karenr@premenos.com) wrote: > > > : In draft-ietf-ediint-as1-02.txt, the Content-Type of the second body > > > : part is specified as application/x-pkcs7-mime. Is this correct, or > > > : should application/x-pkcs7-signature be used? The 2/23/96 S/MIME > > > : Message Specification defines application/x-pkcs7-signature as the PKCS > > > : #7 detached signature. > > > > > > This is an error in draft-ietf-ediint-as1-02.txt. > > > > > > There are two ways to sign data, either the embedded text form, where > > > there is a single MIME type of application/x-pkcs7-mime, or the > > > MIME multipart/signed, where the signature is separate from the > > > text. In this case, the application/x-pkcs7-signature is the proper > > > type. > > > > > > The first method has the original message encoded in binary form and > > > requires PKCS software to decode. The second method works the same as > > > the PGP/MIME except the PKCS7 signature algorithm is used instead > > > of the PGP algorithm. Also, the original message is not encoded, and > > > can be read separately from the authentication. > > > > > > In my opinion, the second form should be used, but apparently, the RSA > > > toolkit doesn't make this easy. (???) > > > > > After the IETF meeting last month we will be doing the > > application/x-pkcs7-mime as the standard because it fits the Internet > > philosophy better than the other. As to the Commercenet test we are > > conducting on these standards, we will be using the other for the next > > several months because of how hard it is to do application/x-pkcs7-mime > > with the Smime toolkits.... later, rik -- Name: Karen Rosenthal E-mail: karenr@premenos.com Phone: (510)688-2928 Fax: (510)602-2133 From owner-ietf-ediint Mon Jan 6 11:11:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id LAA22802 for ietf-ediint-bks; Mon, 6 Jan 1997 11:11:39 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id LAA22797 for ; Mon, 6 Jan 1997 11:11:32 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA19740; Mon, 6 Jan 1997 11:09:52 -0800 Message-ID: <32D14D08.6DB8@actracorp.com> Date: Mon, 06 Jan 1997 11:05:44 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: karenr@premenos.com CC: ietf-ediint@imc.org Subject: Re: MDN Signed Body Part References: <9701050031.AA25376@slick.chage.com> <32D0F562.E3F@onramp.net> <32D13545.3F8B@actracorp.com> <32D113BE.690@premenos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Karen, At the last IETF wg in San Jose this topic was debated and it was my recollection that the following was decided: (If anyone has a different recollection please post on the discussion group.) 1). The IETF will not preclude the use of non Internet standards in its specifications, but it is preferred that if an Internet standard exists, then it should be used. The primary reason given for this: a). Changes to Internet standards are made in a public forum and can be debated before revisions are made. This is not always the case with proprietary standards. 2). Since the S/MIME standards allow the use of both the signed-data format as well as the Internet defined multipart/signed, the multipart/signed should be used since it satisfies the first criteria above as well as the S/MIME specifications. The signed-receipt has always been specified as being in multi-part signed format. An option to support a receipt enveloped in S/MIME format can be supported, if the members of the list thinks this is important. Other than your comments on supporting this option, nothing has been posted by others stating that this support is desirable. Karen Rosenthal wrote: > > Two questions then. What is the rational for not supporting a receipt > enveloped in S/MIME? We would like this option. Second, what is the > working group's stance on supporting multipart/signed vs. S/MIME for > data. > > Regards, > Karen > > Chuck Shih wrote: > > > > Rik, > > > > Just wanted to clarify: > > > > On sending the AS#1 will change to use the multipart/signed version > > of S/MIME instead of the signed-data version of S/MIME. This is as > > a result of the IETF wg in San Jose. > > > > The signed receipt has always been specified as using multipart/signed. > > > > Rik Drummond wrote: > > > > > > Carl Hage wrote: > > > > > > > > Karen Rosenthal (karenr@premenos.com) wrote: > > > > : In draft-ietf-ediint-as1-02.txt, the Content-Type of the second body > > > > : part is specified as application/x-pkcs7-mime. Is this correct, or > > > > : should application/x-pkcs7-signature be used? The 2/23/96 S/MIME > > > > : Message Specification defines application/x-pkcs7-signature as the PKCS > > > > : #7 detached signature. > > > > > > > > This is an error in draft-ietf-ediint-as1-02.txt. > > > > > > > > There are two ways to sign data, either the embedded text form, where > > > > there is a single MIME type of application/x-pkcs7-mime, or the > > > > MIME multipart/signed, where the signature is separate from the > > > > text. In this case, the application/x-pkcs7-signature is the proper > > > > type. > > > > > > > > The first method has the original message encoded in binary form and > > > > requires PKCS software to decode. The second method works the same as > > > > the PGP/MIME except the PKCS7 signature algorithm is used instead > > > > of the PGP algorithm. Also, the original message is not encoded, and > > > > can be read separately from the authentication. > > > > > > > > In my opinion, the second form should be used, but apparently, the RSA > > > > toolkit doesn't make this easy. (???) > > > > > > > After the IETF meeting last month we will be doing the > > > application/x-pkcs7-mime as the standard because it fits the Internet > > > philosophy better than the other. As to the Commercenet test we are > > > conducting on these standards, we will be using the other for the next > > > several months because of how hard it is to do application/x-pkcs7-mime > > > with the Smime toolkits.... later, rik > > -- > Name: Karen Rosenthal > E-mail: karenr@premenos.com > Phone: (510)688-2928 > Fax: (510)602-2133 From owner-ietf-ediint Mon Jan 6 14:42:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id OAA25234 for ietf-ediint-bks; Mon, 6 Jan 1997 14:42:22 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id OAA25230 for ; Mon, 6 Jan 1997 14:42:20 -0800 (PST) Received: from agathon.vip.best.com (agathon.vip.best.com [205.149.165.153]) by proxy1.ba.best.com (8.8.4/8.8.3) with SMTP id OAA10614 for ; Mon, 6 Jan 1997 14:36:52 -0800 (PST) Date: Mon, 6 Jan 1997 14:36:52 -0800 (PST) Message-Id: <199701062236.OAA10614@proxy1.ba.best.com> X-Sender: mjansson@best.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: Mats Jansson Subject: Hierarchy description of AS#1 Sender: owner-ietf-ediint@imc.org Precedence: bulk In the IETF meeting 12/9/96, Ray Poppino from Premenos had asked me to send out to the list the simplified "outline" of which RFC's are used in which example, within AS#1, the way I had it on a slide. Well, here it is - it may not be as clear in ascii as it was on the outliner page, but I hope it's useful to you. NOTE: Due to feedback in the meeting, the structure of the S/MIME signed examples will change to be more aligned with RFC 1847. I will re-submit this when it's complete. Mats J Example: No Encryption/No Signature RFC822 RFC1767 (Application/EDIxxxx) Example: No Encryption/S/MIME Signature RFC822 Draft(dusse) (Application/x-pkcs7-mime) RFC1767 (Application/EDIxxxx) S/MIME Signature Example: No Encryption/PGP/MIME Signature RFC822 RFC1847 (security multiparts) (Content-type: multipart/signed) RFC2015 (PGP/MIME) (protocol="application/pgp-signature") RFC1767 (Application/EDIxxxx) PGP/MIME Signature Example: S/MIME Encryption/No Signature RFC822 Draft(dusse) (Application/x-pkcs7-mime) RFC1767 (Application/EDIxxxx) (encrypted) Example: PGP/MIME Encryption/No Signature RFC822 RFC1847 (security multiparts) (Content-type: multipart/encrypted) RFC2015 (PGP/MIME) (protocol="application/pgp-encrypted") Version 1 RFC1767 (Application/EDIxxxx) (encrypted) Example: S/MIME Encryption and Signature RFC822 Draft(dusse) (Aplication/x-pkcs7-mime) RFC1767 (Application/EDIxxxx) (encrypted) S/MIME Signature (encrypted) Example: PGP/MIME Encryption and Signature RFC822 RFC1847 (security multiparts) (Content-type: multipart/encrypted) RFC2015 (PGP/MIME) (protocol="application/pgp-encrypted") Version 1 RFC1847 (security multiparts)(Content-type: multipart/signed) (encrypted) RFC2015 (PGP/MIME) (protocol="application/pgp-signature ") (encrypted) RFC1767 (Application/EDIxxxx) (encrypted) PGP/MIME Signature (encrypted) Example: Requesting receipt RFC822 mdn-request-header per Draft(fajman) Example: Signed Receipt with S/MIME RFC822 RFC1847 (multipart/signed) Draft(dusse) (protocol="application/x-pkcs7-mime") RFC1892 (signed) Text explanation (signed) message/disposition-notification (signed) message/rfc822 (signed) S/MIME Signature _____________________________________________________________ Mats Jansson, LiNK mjansson@agathon.com 2317 Broadway, Suite 330 Redwood City, CA 94063 v: +1-415-780-9039 http://www.agathon.com f: +1-415-780-9069 From owner-ietf-ediint Mon Jan 6 17:06:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id RAA26607 for ietf-ediint-bks; Mon, 6 Jan 1997 17:06:22 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id RAA26594 for ; Mon, 6 Jan 1997 17:06:15 -0800 (PST) Received: from agathon.vip.best.com (agathon.vip.best.com [205.149.165.153]) by proxy3.ba.best.com (8.8.4/8.8.3) with SMTP id RAA10869; Mon, 6 Jan 1997 17:03:06 -0800 (PST) Date: Mon, 6 Jan 1997 17:03:06 -0800 (PST) Message-Id: <199701070103.RAA10869@proxy3.ba.best.com> X-Sender: mjansson@best.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: chucks@actracorp.com, karenr@premenos.com From: Mats Jansson Subject: Re: MDN Signed Body Part Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk Chuck: What you describe below is exactly what I walked away with as well. Mats J. At 11:05 AM 1/6/97 -0800, Chuck Shih wrote: >Karen, > >At the last IETF wg in San Jose this topic was debated and it was my >recollection that the following was decided: (If anyone has a different >recollection please post on the discussion group.) > >1). The IETF will not preclude the use of non Internet standards > in its specifications, but it is preferred that if an Internet > standard exists, then it should be used. The primary reason > given for this: > > a). Changes to Internet standards are made in a public forum > and can be debated before revisions are made. This is not > always the case with proprietary standards. > > 2). Since the S/MIME standards allow the use of both the signed-data > format as well as the Internet defined multipart/signed, the > multipart/signed should be used since it satisfies the first > criteria above as well as the S/MIME specifications. > >The signed-receipt has always been specified as being in multi-part >signed format. An option to support a receipt enveloped in S/MIME format >can be supported, if the members of the list thinks this is important. >Other than your comments on supporting this option, nothing has been >posted by others stating that this support is desirable. > > >Karen Rosenthal wrote: >> >> Two questions then. What is the rational for not supporting a receipt >> enveloped in S/MIME? We would like this option. Second, what is the >> working group's stance on supporting multipart/signed vs. S/MIME for >> data. >> >> Regards, >> Karen >> >> Chuck Shih wrote: >> > >> > Rik, >> > >> > Just wanted to clarify: >> > >> > On sending the AS#1 will change to use the multipart/signed version >> > of S/MIME instead of the signed-data version of S/MIME. This is as >> > a result of the IETF wg in San Jose. >> > >> > The signed receipt has always been specified as using multipart/signed. >> > >> > Rik Drummond wrote: >> > > >> > > Carl Hage wrote: >> > > > >> > > > Karen Rosenthal (karenr@premenos.com) wrote: >> > > > : In draft-ietf-ediint-as1-02.txt, the Content-Type of the second body >> > > > : part is specified as application/x-pkcs7-mime. Is this correct, or >> > > > : should application/x-pkcs7-signature be used? The 2/23/96 S/MIME >> > > > : Message Specification defines application/x-pkcs7-signature as the PKCS >> > > > : #7 detached signature. >> > > > >> > > > This is an error in draft-ietf-ediint-as1-02.txt. >> > > > >> > > > There are two ways to sign data, either the embedded text form, where >> > > > there is a single MIME type of application/x-pkcs7-mime, or the >> > > > MIME multipart/signed, where the signature is separate from the >> > > > text. In this case, the application/x-pkcs7-signature is the proper >> > > > type. >> > > > >> > > > The first method has the original message encoded in binary form and >> > > > requires PKCS software to decode. The second method works the same as >> > > > the PGP/MIME except the PKCS7 signature algorithm is used instead >> > > > of the PGP algorithm. Also, the original message is not encoded, and >> > > > can be read separately from the authentication. >> > > > >> > > > In my opinion, the second form should be used, but apparently, the RSA >> > > > toolkit doesn't make this easy. (???) >> > > > >> > > After the IETF meeting last month we will be doing the >> > > application/x-pkcs7-mime as the standard because it fits the Internet >> > > philosophy better than the other. As to the Commercenet test we are >> > > conducting on these standards, we will be using the other for the next >> > > several months because of how hard it is to do application/x-pkcs7-mime >> > > with the Smime toolkits.... later, rik >> >> -- >> Name: Karen Rosenthal >> E-mail: karenr@premenos.com >> Phone: (510)688-2928 >> Fax: (510)602-2133 > > _____________________________________________________________ Mats Jansson, LiNK mjansson@agathon.com 2317 Broadway, Suite 330 Redwood City, CA 94063 v: +1-415-780-9039 http://www.agathon.com f: +1-415-780-9069 From owner-ietf-ediint Mon Jan 6 22:32:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id WAA29310 for ietf-ediint-bks; Mon, 6 Jan 1997 22:32:28 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from rmit.EDU.AU (root@B1.rmit.EDU.AU [131.170.1.1]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id WAA29305 for ; Mon, 6 Jan 1997 22:32:20 -0800 (PST) Received: from urgento.gse.rmit.EDU.AU (urgento.gse.rmit.EDU.AU [131.170.69.3]) by rmit.EDU.AU (8.7.5/8.7.3/ram2) with SMTP id RAA18847 for ; Tue, 7 Jan 1997 17:32:00 +1100 (EST) Received: by urgento.gse.rmit.EDU.AU (SMI-8.6/SMI-SVR4) id RAA26511; Tue, 7 Jan 1997 17:30:21 +1100 From: rsedc@urgento.gse.rmit.EDU.AU (David Chia) Message-Id: <199701070630.RAA26511@urgento.gse.rmit.EDU.AU> Subject: Re: MDN Signed Body Part To: ietf-ediint@imc.org Date: Tue, 7 Jan 1997 17:30:21 +1100 (EST) In-Reply-To: <199701070103.RAA10869@proxy3.ba.best.com> from "Mats Jansson" at Jan 6, 97 05:03:06 pm X-Mailer: ELM [version 2.4 PL25+3 PGP6+4] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk > Chuck: > > What you describe below is exactly what I walked away with as well. > > Mats J. > > At 11:05 AM 1/6/97 -0800, Chuck Shih wrote: > >Karen, > > > >At the last IETF wg in San Jose this topic was debated and it was my > >recollection that the following was decided: (If anyone has a different > >recollection please post on the discussion group.) > > > >1). The IETF will not preclude the use of non Internet standards > > in its specifications, but it is preferred that if an Internet > > standard exists, then it should be used. > > > >Karen Rosenthal wrote: > >> > >> Two questions then. What is the rational for not supporting a receipt > >> enveloped in S/MIME? We would like this option. Second, what is the > >> working group's stance on supporting multipart/signed vs. S/MIME for > >> data. The place for such proprietary standards is spelled out clearly in RFC 2026, especially against the RFCs in the 'standard track'. Request for Comments: 2026 The Internet Standards Process -- Revision 3 7.1.2 Incorporation of Other Specifications The IESG generally should not favor a particular proprietary specification over technically equivalent and competing specification(s) by making any incorporated vendor specification "required" or "recommended". Therefore 'generally' such proprietary standards can achieve is to be included as electvie specification, i.e. (c) Elective: Implementation of the referenced TS is optional within the domain of applicability of the AS; that is, the AS creates no explicit necessity to apply the TS. However, a particular vendor may decide to implement it, or a particular user may decide that it is a necessity in a specific environment. For example, the DECNET MIB could be seen as valuable in an environment where the DECNET protocol is used. The vendors have the option to make the specifications concerned to be open standards and proceed to push them into the 'internet standard track', not just informational RFCs. David Chia, RMIT University. From owner-ietf-ediint Tue Jan 7 15:02:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id PAA10209 for ietf-ediint-bks; Tue, 7 Jan 1997 15:02:26 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.4/8.7.3) with SMTP id PAA10205 for ; Tue, 7 Jan 1997 15:02:24 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA26078 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Tue, 7 Jan 1997 15:02:05 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA27347; Tue, 7 Jan 97 11:37:06 PST Date: Tue, 7 Jan 97 11:37:06 PST From: carl@chage.com (Carl Hage) Message-Id: <9701071937.AA27347@slick.chage.com> To: ietf-ediint@imc.org Subject: Re: MDN Signed Body Part References: <9701050031.AA25376@slick.chage.com> <32D0F562.E3F@onramp.net> <32D13545.3F8B@actracorp.com> Sender: owner-ietf-ediint@imc.org Precedence: bulk Chuck Shih (chucks@actracorp.com) wrote: : On sending the AS#1 will change to use the multipart/signed version : of S/MIME instead of the signed-data version of S/MIME. This is as : a result of the IETF wg in San Jose. Hmmm. This is the opposite of what Rik said. I agree with the result of the WG for the same reasons you already mentioned. Also, this allows software, e.g. to process an MDN, filter an RFQ, etc., to be separate from the authentication software. Though I don't have the RSA toolkit, I am skeptical that it is that difficult to implement (detached) application/x-pkcs7-signature. Can't you generate application/x-pkcs7-mime, then write a simple program to strip out the message and tweak the headers to get the application/x-pkcs7-signature? (Anyone without the RSA toolkit would need to do this anyway, just to _read_ the message.) ---- Mats, the MIME type is wrong here as well (probably need to check all "x-pkcs7-mime" cases): Example: Signed Receipt with S/MIME RFC822 RFC1847 (multipart/signed) Draft(dusse) (protocol="application/x-pkcs7-mime") -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Tue Jan 7 16:06:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id QAA10702 for ietf-ediint-bks; Tue, 7 Jan 1997 16:06:27 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id QAA10698 for ; Tue, 7 Jan 1997 16:06:23 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA679; Tue, 7 Jan 1997 16:04:43 -0800 Message-ID: <32D2E3A2.6D17@actracorp.com> Date: Tue, 07 Jan 1997 16:00:34 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Carl Hage CC: ietf-ediint@imc.org Subject: Re: MDN Signed Body Part References: <9701050031.AA25376@slick.chage.com> <32D0F562.E3F@onramp.net> <32D13545.3F8B@actracorp.com> <9701071937.AA27347@slick.chage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Carl Hage wrote: > > Chuck Shih (chucks@actracorp.com) wrote: > : On sending the AS#1 will change to use the multipart/signed version > : of S/MIME instead of the signed-data version of S/MIME. This is as > : a result of the IETF wg in San Jose. > > Hmmm. This is the opposite of what Rik said. I think I clarified what Rik said with a message I sent out in response to it. The change to using the multipart/signed was what was agreed to at the IETF wg. > > I agree with the result of the WG for the same reasons you already mentioned. > Also, this allows software, e.g. to process an MDN, filter an RFQ, etc., > to be separate from the authentication software. > > Though I don't have the RSA toolkit, I am skeptical that it is that > difficult to implement (detached) application/x-pkcs7-signature. Can't you > generate application/x-pkcs7-mime, then write a simple program to strip > out the message and tweak the headers to get the > application/x-pkcs7-signature? (Anyone without the RSA toolkit would need > to do this anyway, just to _read_ the message.) Difficult or hard this needs to be done for the signed receipt anyway, so the implementation will need to be done if signed receipts are to be implemented. > > ---- > > Mats, the MIME type is wrong here as well (probably need to check all > "x-pkcs7-mime" cases): > > Example: Signed Receipt with S/MIME > RFC822 > RFC1847 (multipart/signed) > Draft(dusse) (protocol="application/x-pkcs7-mime") > -------------------------------------------------------------------------- > Carl Hage C. Hage Associates > Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 > Sunnyvale, CA 94086 From owner-ietf-ediint Fri Jan 10 18:08:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id SAA29912 for ietf-ediint-bks; Fri, 10 Jan 1997 18:08:05 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id SAA29908 for ; Fri, 10 Jan 1997 18:08:00 -0800 (PST) X-Sender: phoffman@mail.proper.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Jan 1997 18:08:27 -0800 To: ietf-ediint@imc.org From: "Paul E. Hoffman" Subject: New Web page for this WG Sender: owner-ietf-ediint@imc.org Precedence: bulk Greetings again. I've redesigned the Web page associated with the Working Group to be more informative. Please take a look at and let me know if there is anything I should add or change. Thanks! --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-ediint Fri Jan 17 13:27:52 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id NAA09117 for ietf-ediint-bks; Fri, 17 Jan 1997 13:27:52 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id NAA09112 for ; Fri, 17 Jan 1997 13:27:34 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA5080; Fri, 17 Jan 1997 13:26:17 -0800 Message-ID: <32DFED79.3DDC@actracorp.com> Date: Fri, 17 Jan 1997 13:22:01 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ietf-ediint@imc.org CC: edipilot@commerce.net Subject: Requesting Signed Receipts Content-Type: multipart/mixed; boundary="------------4446203C73EA" Sender: owner-ietf-ediint@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------4446203C73EA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Below is a proposal using the new options supported by the 11/26 MDN draft on how signed receipts can be requested between trading partners. I have passed this by Roger Fajman, author of the MDN draft and his comment was "Looks reasonable to me." So I am posting the proposal to the list, and am looking for comments. I'd like to revise the section on "Requesting a Signed Receipt" in the AS#1 under section 5.2, incorporating the new options. Thanks. --------------4446203C73EA Content-Type: text/plain; charset=us-ascii; name="assend.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="assend.txt" 5.2 Requesting a Signed Receipt Message Disposition Notifications are requested as per the draft-ietf- receipt-mdn-01.txt. A request that the receiving user agent issue a message disposition notification is made by placing the following header into the message to be sent: mdn-request-header = "Disposition-notification-to" ":" mailaddress The mailaddress field is specified as an RFC 822 user@domain address, and is the return address for the message disposition notification. In addition to requesting a message disposition notification, a signed message disposition notification or what has been referred to as a signed-receipt, can be requested by placing the following in the message header following the "Disposition-notification-to" line: Disposition-notification-options = "Disposition-notification-options" ":" dispostion-notification-parameters Where disposition-notification-parameters = signature=R, requested; mic-alg=R, -; signature-alg=R, ; An example of a formatted options line would be as follows: Disposition-notification-options: signature=R, requested; mic-alg=R, rsa-sha1; signature-alg=R, rsa; The semantics of the above parameters are as follows: 1). The "R" is defined in the MDN draft and means the following: Parameters with the "R" associated with them cannot be ignored by a UA. If the UA does not understand what the parameter means, it cannot send back a message disposition notification in response to the request. The signature parameter must be understood by the UA in order for a MDN to be sent back - signed or unsigned. The signature parameter, if it is not understood, prevents the UA from sending the message disposition notification, and the mic-alg and the signature-alg parameters are then not processed. 2). The only valid value for the "signature" parameter is "requested", and is the mechanism by which the sender explicitly requests the MDN to be signed by the recipient. Any other value besides "requested" are invalid and the receiving UA sends back a message disposition notification with the disposition field set to "invalid parameter value" 3). The mic-alg and signature-alg parameters are the algorithms the sender is requesting be used with the signed-receipt. A receiving UA that does not support the algorithm values, sends back a message disposition notification (unsigned) with the disposition field set to "unsupported algorithm value". --------------4446203C73EA-- From owner-ietf-ediint Fri Jan 17 14:57:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id OAA10043 for ietf-ediint-bks; Fri, 17 Jan 1997 14:57:29 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from sdsosc.co.kr (dankun.sdsosc.co.kr [168.126.67.136]) by mail.proper.com (8.8.4/8.7.3) with SMTP id OAA10038 for ; Fri, 17 Jan 1997 14:57:24 -0800 (PST) Received: from hawk by sdsosc.co.kr (SMI-8.6/SMI-SVR4) id HAA11569; Sat, 18 Jan 1997 07:56:53 +0900 Message-ID: <32E003A8.CE9@sdsosc.co.kr> Date: Sat, 18 Jan 1997 07:56:40 +0900 From: yijaeho Organization: Samsung Data Systems X-Sender: yijaeho (Unverified) X-Mailer: Mozilla 4.0b1 (Win95; I) MIME-Version: 1.0 To: ietf-ediint@imc.org X-Priority: Normal Content-Type: multipart/alternative; boundary="----------2C81707262B61" Sender: owner-ietf-ediint@imc.org Precedence: bulk ------------2C81707262B61 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii subscribe ------------2C81707262B61 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
 subscribe 
------------2C81707262B61-- From owner-ietf-ediint Fri Jan 17 17:56:08 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id RAA12018 for ietf-ediint-bks; Fri, 17 Jan 1997 17:56:08 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from gatekeeper.premenos.com (mail.premenos.com [150.105.250.1]) by mail.proper.com (8.8.4/8.7.3) with SMTP id RAA12014 for ; Fri, 17 Jan 1997 17:56:05 -0800 (PST) Received: from localhost (smap@localhost) by gatekeeper.premenos.com (8.6.5/8.6.5) id RAA06240; Fri, 17 Jan 1997 17:58:41 -0800 Received: from karenr.premenos.com(150.105.100.205) by mail.premenos.com via smap (V1.3mjr) id sma006228; Fri Jan 17 17:57:46 1997 Message-ID: <32E0025D.68C2@premenos.com> Date: Fri, 17 Jan 1997 17:51:09 -0500 From: Karen Rosenthal Reply-To: karenr@premenos.com Organization: Premenos X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: chucks@actracorp.com CC: ietf-ediint@imc.org, edipilot@commerce.net Subject: Re: Requesting Signed Receipts References: <32DFED79.3DDC@actracorp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Chuck, The proposal using the new MDN options for requesting signed receipts look good. Just a few questions: 1. Aren't "signature=R, requested;" and "signature-alg=R, ;" redundant? I would think that we'd only need the latter. 2. Two new dispositions are being added here: invalid parameter value, and unsupported algorithm value. Along with decryption_failed, authentication_failed, and integrity_check_failed defined draft-ietf-ediint-as1-02.txt, none of these are mentioned in R. Fajman's draft. Will these dispositions eventially be included in the MDN draft, or are they specific to the EDIINT draft? Will a definitive list of IANA registered possibilities be listed in either draft? Are the added dispositions registered with the IANA, or do they need to be preceded with X-? 3. Ultimately, will the EDIINT proposals for a Signed MDN going to be integrated into R. Fajman's draft, or will they remain separately defined in the EDIINT draft? Thanks, Karen Chuck Shih wrote: > > Below is a proposal using the new options supported by the 11/26 MDN > draft on how signed receipts can be requested between trading partners. > I have passed this by Roger Fajman, author of the MDN draft and his > comment was "Looks reasonable to me." So I am posting the proposal to > the list, and am looking for comments. I'd like to revise the section on > "Requesting a Signed Receipt" in the AS#1 under section 5.2, > incorporating the new options. > > Thanks. > > --------------------------------------------------------------- > > 5.2 Requesting a Signed Receipt > > Message Disposition Notifications are requested as per the draft-ietf- > receipt-mdn-01.txt. A request that the receiving user agent issue a > message disposition notification is made by placing the following header > into the message to be sent: > > mdn-request-header = "Disposition-notification-to" ":" mailaddress > > The mailaddress field is specified as an RFC 822 user@domain address, and is > the return address for the message disposition notification. > > In addition to requesting a message disposition notification, a signed message > disposition notification or what has been referred to as a signed-receipt, can > be requested by placing the following in the message header following the > "Disposition-notification-to" line: > > Disposition-notification-options = "Disposition-notification-options" ":" > dispostion-notification-parameters > > Where disposition-notification-parameters = signature=R, requested; > mic-alg=R, -; signature-alg=R, ; > > An example of a formatted options line would be as follows: > > Disposition-notification-options: signature=R, requested; mic-alg=R, rsa-sha1; > signature-alg=R, rsa; > > The semantics of the above parameters are as follows: > > 1). The "R" is defined in the MDN draft and means the following: > > Parameters with the "R" associated with them cannot be ignored by a UA. If the > UA does not understand what the parameter means, it cannot send back a message > disposition notification in response to the request. The signature parameter > must be understood by the UA in order for a MDN to be sent back - signed or > unsigned. The signature parameter, if it is not understood, prevents the UA > from sending the message disposition notification, and the mic-alg and the > signature-alg parameters are then not processed. > > 2). The only valid value for the "signature" parameter is "requested", and is the > mechanism by which the sender explicitly requests the MDN to be signed by the > recipient. Any other value besides "requested" are invalid and the receiving UA sends > back a message disposition notification with the disposition field set to > "invalid parameter value" > > 3). The mic-alg and signature-alg parameters are the algorithms the sender is > requesting be used with the signed-receipt. A receiving UA that does not support the > algorithm values, sends back a message disposition notification (unsigned) > with the disposition field set to "unsupported algorithm value". > > -- Name: Karen Rosenthal E-mail: karenr@premenos.com Phone: (510)688-2928 Fax: (510)602-2133 From owner-ietf-ediint Fri Jan 17 18:39:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id SAA12421 for ietf-ediint-bks; Fri, 17 Jan 1997 18:39:20 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id SAA12417 for ; Fri, 17 Jan 1997 18:39:18 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA19734; Fri, 17 Jan 1997 18:38:02 -0800 Message-ID: <32E03689.5FD7@actracorp.com> Date: Fri, 17 Jan 1997 18:33:45 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: karenr@premenos.com CC: ietf-ediint@imc.org, edipilot@commerce.net Subject: Re: Requesting Signed Receipts References: <32DFED79.3DDC@actracorp.com> <32E0025D.68C2@premenos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Karen Rosenthal wrote: > > Chuck, > > The proposal using the new MDN options for requesting signed receipts > look good. Just a few questions: > > 1. Aren't "signature=R, requested;" and "signature-alg=R, algorithm symbol>;" redundant? I would think that we'd only need the > latter. > Yes at this point in time it is redundant. I put this in, so that at some point in time, if more than RSA is used as the signing algorithm, this can be specified. The signature parameter is intended to request a signature, while the signature algorithm is used to request what algorithm to use to do the signing. > 2. Two new dispositions are being added here: invalid parameter value, > and unsupported algorithm value. Along with decryption_failed, > authentication_failed, and integrity_check_failed defined > draft-ietf-ediint-as1-02.txt, none of these are mentioned in R. Fajman's > draft. Will these dispositions eventially be included in the MDN draft, > or are they specific to the EDIINT draft? Will a definitive list of > IANA registered possibilities be listed in either draft? Are the added > dispositions registered with the IANA, or do they need to be preceded > with X-? > The dispositions related to unknown parameters should be in the MDN spec, while the ones relating specifically to signed receipts should be in the ediint spec. Yes all of the dispositions will be registered with IANA. > 3. Ultimately, will the EDIINT proposals for a Signed MDN going to be > integrated into R. Fajman's draft, or will they remain separately > defined in the EDIINT draft? They will be seperately defined in the EDIINT draft. > > Thanks, > Karen > > Chuck Shih wrote: > > > > Below is a proposal using the new options supported by the 11/26 MDN > > draft on how signed receipts can be requested between trading partners. > > I have passed this by Roger Fajman, author of the MDN draft and his > > comment was "Looks reasonable to me." So I am posting the proposal to > > the list, and am looking for comments. I'd like to revise the section on > > "Requesting a Signed Receipt" in the AS#1 under section 5.2, > > incorporating the new options. > > > > Thanks. > > > > --------------------------------------------------------------- > > > > 5.2 Requesting a Signed Receipt > > > > Message Disposition Notifications are requested as per the draft-ietf- > > receipt-mdn-01.txt. A request that the receiving user agent issue a > > message disposition notification is made by placing the following header > > into the message to be sent: > > > > mdn-request-header = "Disposition-notification-to" ":" mailaddress > > > > The mailaddress field is specified as an RFC 822 user@domain address, and is > > the return address for the message disposition notification. > > > > In addition to requesting a message disposition notification, a signed message > > disposition notification or what has been referred to as a signed-receipt, can > > be requested by placing the following in the message header following the > > "Disposition-notification-to" line: > > > > Disposition-notification-options = "Disposition-notification-options" ":" > > dispostion-notification-parameters > > > > Where disposition-notification-parameters = signature=R, requested; > > mic-alg=R, -; signature-alg=R, ; > > > > An example of a formatted options line would be as follows: > > > > Disposition-notification-options: signature=R, requested; mic-alg=R, rsa-sha1; > > signature-alg=R, rsa; > > > > The semantics of the above parameters are as follows: > > > > 1). The "R" is defined in the MDN draft and means the following: > > > > Parameters with the "R" associated with them cannot be ignored by a UA. If the > > UA does not understand what the parameter means, it cannot send back a message > > disposition notification in response to the request. The signature parameter > > must be understood by the UA in order for a MDN to be sent back - signed or > > unsigned. The signature parameter, if it is not understood, prevents the UA > > from sending the message disposition notification, and the mic-alg and the > > signature-alg parameters are then not processed. > > > > 2). The only valid value for the "signature" parameter is "requested", and is the > > mechanism by which the sender explicitly requests the MDN to be signed by the > > recipient. Any other value besides "requested" are invalid and the receiving UA sends > > back a message disposition notification with the disposition field set to > > "invalid parameter value" > > > > 3). The mic-alg and signature-alg parameters are the algorithms the sender is > > requesting be used with the signed-receipt. A receiving UA that does not support the > > algorithm values, sends back a message disposition notification (unsigned) > > with the disposition field set to "unsupported algorithm value". > > > > > > -- > Name: Karen Rosenthal > E-mail: karenr@premenos.com > Phone: (510)688-2928 > Fax: (510)602-2133 From owner-ietf-ediint Sat Jan 18 14:42:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id OAA20952 for ietf-ediint-bks; Sat, 18 Jan 1997 14:42:41 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.4/8.7.3) with SMTP id OAA20948 for ; Sat, 18 Jan 1997 14:42:33 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA05889 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Sat, 18 Jan 1997 14:42:43 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA09987; Sat, 18 Jan 97 14:30:03 PST Date: Sat, 18 Jan 97 14:30:03 PST From: carl@chage.com (Carl Hage) Message-Id: <9701182230.AA09987@slick.chage.com> To: ietf-ediint@imc.org Subject: Requesting Signed Receipts Sender: owner-ietf-ediint@imc.org Precedence: bulk First, some comments on draft-ietf-receipt-mdn-02.txt (11/96): There are some significant problems with the MDN draft: - The "R" required, "O" optional assignment to parameters doesn't really fit. First, not returning an MDN is improper. The receipt of the MDN is critical, and at least an error response must be issued. The main "R" is that the MDN be returned. This is a major flaw for extensibility, since if a UA doesn't understand the option, the whole MDN breaks! The R/O doesn't really make sense. The UA generating the MDN should probably attempt to follow all request options, if possible. If not possible, the MDN should not fail, and the MDN returned would indicate (perhaps by lack of the requested option) inability to adhere to the parameter. Not understanding the R parameter, should probably do the opposite. Where a parameter indicated the MDN is optional or limited to certain conditions, an unknown parameter would cause the MDN to be generated always. - The requestor may be able to accept more than one value, e.g. for a signature, the requestor may be able to validate PGP and PKCS7/DSS signatures. The recipient may only have PGP. Thus the requestor would indicate it can authenticate PGP or PKCS7/DSS. If the requestor specified only PKCS7/DSS, and the recipient had only PGP, the recipient would still return an MDN, signed by PGP. - The disposition-value is still inadequate. A processedfail status should be added to indicate the message was autoprocessed, but this processing failed. Manual intervention might be required. For use with secure messaging, some response codes should be added to identify problems: undecodable - The contents of the message could not be decoded (or perhaps could not be decrypted). authenticatefail - The digital signature could not be authenticated. micfail - A message integrity check failed-- the message contents have probably been corrupted or truncated. (The MDN should return the calculated MIC (Content-MD5) on the message received to help identify problems.) - In some cases messaging might not succeed because a public key cannot be verified or is unavailable. A certificate or authenticated key may be needed and might need to be requested. Second, regarding Chuck's MDN request options: - The "signature=R, requested" is superflous. The presence of a signature-alg or mic-alg is sufficient for a signature request, and so is redundant. - The parameters for signature request should match the options in the RFC1847 "Content-Type: multipart/signed" header, namely protocol and micalg. The value of these parameters are defined by the RFCs defining the protocols, e.g. Disposition-notification-options: signature-protocol=O, application/pgp-signature; signature-micalg=O, pgp-md5 ('O' is used because 'R' is fatally flawed.) (I added the prefix signature-micalg, to distinguish the micalg from other possible MIC usage, e.g. a MIC of the original message contents.) A "signature=R, requested" is implicit with the existence of signature-protocol. - The signature-protocol parameter should supply the *list* of protocols which the requestor can decode, in order of preference. The recipient can then choose the reply signature based on it's supported protocols, e.g.: Disposition-notification-options: signature-protocol=O, application/pgp-signature, application/x-pkcs7-signature; signature-micalg=O, pgp-md5, rsa-md5 - If the "signature-micalg" parameter is omitted, then all values defined by the RFC corresponding to the signature-protocol are implied, e.g. all protocols supported by PGP, or by PKCS7. (The usual case is to omit the signature-micalg, since most packages support all algorithms defined in the protocol.) - The 'R, ' is meaningless and inappropriate. If the MDN rules are really followed, 'O' should be used to insure an MDN is returned. The 'R' should be deleted, in my opinion. - In case the signature-protocols requested do not include a supported protocol, the sender should still return a signed MDN in a protocol available. The recipient should not return an unsigned MDN unless no signature processing is available. (Even though a signature cannot be immediately authenticated, non-repudiation still applies and a signature is useful.) -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Sat Jan 18 16:28:08 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id QAA21853 for ietf-ediint-bks; Sat, 18 Jan 1997 16:28:08 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.4/8.7.3) with SMTP id QAA21849 for ; Sat, 18 Jan 1997 16:28:04 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA13694 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Sat, 18 Jan 1997 16:28:13 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA10071; Sat, 18 Jan 97 15:22:56 PST Date: Sat, 18 Jan 97 15:22:56 PST From: carl@chage.com (Carl Hage) Message-Id: <9701182322.AA10071@slick.chage.com> To: ietf-ediint@imc.org Subject: Re: Requesting Signed Receipts References: <32DFED79.3DDC@actracorp.com> <32E0025D.68C2@premenos.com> <32E03689.5FD7@actracorp.com> Organization: C. Hage Associates, Sunnyvale, CA Sender: owner-ietf-ediint@imc.org Precedence: bulk Oops, I see Karen said much of the same as I. Chuck Shih (chucks@actracorp.com) wrote: : Karen Rosenthal wrote: : > 1. Aren't "signature=R, requested;" and "signature-alg=R, algorithm symbol>;" redundant? : > : Yes at this point in time it is redundant. I put this in, so that at : some point in time, if more than RSA is used as the signing algorithm, : this can be specified. This doesn't make sense. A request for signature should always be followed by a list of _protocols_ supported. A request for signature with unspecified/arbitrary protocol is meaningless. Lack of compatibility, however, should not disable signing of receipts. The MSN *must* be returned or the overall reliable email system fails. : The dispositions related to unknown parameters should be in the MDN : spec, while the ones relating specifically to signed receipts should : be in the ediint spec. Yes all of the dispositions will be registered : with IANA. Sounds OK to put errors in decryption/authentication in ediint. The autoprocessed failed status and possibly an "undecodable" (say, because the application/mime-type is unknown, e.g. an HL7 type is sent to an X12/EDIFACT system) is probably general (not security related) and should be included in the Fajman draft. --- Note that the details of the original message MIC returned in the MDN still needs to be corrected/refined. The possibilities are: - Define multiple MIC "types" which define the scope of the content, e.g.: - RFC822 message content (a Content-MD5 header value) - the decrypted content MIC(s) (the result of decoding, which will typically start with a multipart\signed header) - the content used by original signatures (starting with Content-Type header) - the application data itself (without MIME header) (Note that to be general, other than for the RFC822 message content, a message could theoretically contain multiple encrypted contents, signed contents, or application data parts. Thus multiple MICs might be appropriate. The EDIINT protocol restricts the contents to a single EDI transactions, but other secure email applications might have other requirements and the MIC process should not be limited to the EDI usage of email.) - Return the _signature_ data (which is not a MIC, but contains a MIC) in the original message. (This could be useful for non-repudiation, if the sender has a co-signed ack with the original signature(s). Returning signatures could complicate email processing/filing and receipt tracking software by making it dependent on certain encryption protocols. Separating MDN handling and encryption is a major advantage, particularly with future extensibility of encryption protocols. - Use a MDN request option to request the type of original message MIC and/or signature to be included in the MDN. My suggestion is to define and include three MIC values: either: Content-MIC: , Decrypted-MIC: ,; ,; ... Application-MIC: ,; ,; ... or: Content-MD5: Decrypted-MD5: ; ; ... Application-MD5: ; ; ... The "Content-MIC" is a MIC (not a signature) over the body part (after the blank line following RFC822 headers) of a message. The "Decrypted-MIC" is a MIC over the result of decoding the "multipart/encrypted" MIME part(s) found within a message. The Application-MIC would be a MIC over the terminal (not multipart) MIME bodies found in a message, e.g. the X12/EDIFACT transaction (without MIME header) in an ediint message, attached files in a multipart, etc. The MD5 would be a simpler, easier to implement form, where the MIC algorithm was fixed. Allowing multiple MICs greatly complicates verification and tracking software, since different users/vendors might use different and incompatible MICs. In other words if an auditor of corp A scanned logs with MD5 MICs, but receipts from corp B used, SHA MICs, then the auditor could not correlate these values. The Content-MIC is most useful for general purpose reliable mailers and MDN processors to verify a message was exchanged correctly, independent of all other software processing. The Decrypted-MIC is most useful to correlate MDNs with logs of pre-encoded messages. Once encoded, a message cannot be decoded except by the recipient. The Application-MIC is most useful for correlating EDI interchange logs with an MDN, and to match attached files against an MDN. Updates to attached files sent by email could be readily detected. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Mon Jan 20 10:11:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id KAA10768 for ietf-ediint-bks; Mon, 20 Jan 1997 10:11:45 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from ns.atomic.net (root@ns.atomic.net [206.100.246.3]) by mail.proper.com (8.8.4/8.7.3) with SMTP id KAA10764 for ; Mon, 20 Jan 1997 10:11:41 -0800 (PST) Received: from carmac (pp36.atomic.net [206.100.246.236]) by ns.atomic.net (8.6.12/8.6.9) with ESMTP id NAA03141 for ; Mon, 20 Jan 1997 13:12:26 -0500 Message-Id: <199701201812.NAA03141@ns.atomic.net> From: "Chris Carmac" To: Subject: Please remove me from the EDI mailing list. Date: Mon, 20 Jan 1997 13:12:09 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk remove From owner-ietf-ediint Mon Jan 20 10:39:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id KAA10965 for ietf-ediint-bks; Mon, 20 Jan 1997 10:39:00 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from base (base.tax.state.ny.us [204.115.32.4]) by mail.proper.com (8.8.4/8.7.3) with SMTP id KAA10961 for ; Mon, 20 Jan 1997 10:38:57 -0800 (PST) From: Brian_Digman@tax.state.ny.us Received: from taohub01 by base (AIX 4.1/UCB 5.64/4.03) id AA09082; Mon, 20 Jan 1997 13:39:12 -0500 Received: by taohub01.tax.state.ny.us(Lotus SMTP MTA Release 1.0.1) id 85256425.0066B338 ; Mon, 20 Jan 1997 13:41:45 -0400 X-Lotus-Fromdomain: NYSTAX To: ietf-ediint@imc.org Message-Id: <8525641F:00626039.00@taohub01.tax.state.ny.us> Date: Mon, 20 Jan 1997 13:39:15 -0400 Subject: EDI/Internet filing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ediint@imc.org Precedence: bulk Brian Digman 01-20-97 01:39 PM I read an article in the December 1996 Network Computing magazine regarding transmitting EDI transactions across the Internet. The article was very informative and I would like additional information on this topic. Also, can you send me more information on the EDIINT working group (when they meet, etc ...). Thank You, BD From owner-ietf-ediint Mon Jan 20 13:49:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id NAA13038 for ietf-ediint-bks; Mon, 20 Jan 1997 13:49:23 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from dfw-ix9.ix.netcom.com (dfw-ix9.ix.netcom.com [206.214.98.9]) by mail.proper.com (8.8.4/8.7.3) with SMTP id NAA13034 for ; Mon, 20 Jan 1997 13:49:20 -0800 (PST) Received: from nyc-ny28-42.ix.netcom.com (nyc-ny28-42.ix.netcom.com [207.92.153.106]) by dfw-ix9.ix.netcom.com (8.6.13/8.6.12) with SMTP id NAA14080 for ; Mon, 20 Jan 1997 13:49:07 -0800 Received: by nyc-ny28-42.ix.netcom.com with Microsoft Mail id <01BC06F1.FFFA25C0@nyc-ny28-42.ix.netcom.com>; Mon, 20 Jan 1997 16:50:11 -0500 Message-ID: <01BC06F1.FFFA25C0@nyc-ny28-42.ix.netcom.com> From: saul harari To: "ietf-ediint@imc.org" Subject: please remove from edi mailing list Date: Mon, 20 Jan 1997 16:40:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk remove From owner-ietf-ediint Mon Jan 20 14:27:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id OAA13316 for ietf-ediint-bks; Mon, 20 Jan 1997 14:27:34 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from proxy.harbinger.net (gate.harbinger.net [204.4.60.250]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id OAA13309 for ; Mon, 20 Jan 1997 14:27:30 -0800 (PST) Received: by proxy.harbinger.net; id RAA01586; Mon, 20 Jan 1997 17:26:49 -0500 (EST) Received: from hendrix.harbinger.net(199.99.178.182) by gate.harbinger.net via smap (3.2) id xma001577; Mon, 20 Jan 97 17:26:44 -0500 Received: from gduvall.harbinger.net ([207.16.69.37]) by hendrix.harbinger.com (post.office MTA v1.9.1 ID# 0-11810) with SMTP id AAA198 for ; Mon, 20 Jan 1997 17:19:41 -0500 Received: by gduvall.harbinger.net with Microsoft Mail id <01BC06F7.9528D060@gduvall.harbinger.net>; Mon, 20 Jan 1997 17:30:08 -0500 Message-ID: <01BC06F7.9528D060@gduvall.harbinger.net> From: gduvall@harbinger.net (Garland Duvall) To: "ietf-ediint@imc.org" Subject: remove Date: Mon, 20 Jan 1997 17:30:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk remove From owner-ietf-ediint Tue Jan 21 04:50:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id EAA23014 for ietf-ediint-bks; Tue, 21 Jan 1997 04:50:20 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from docws001.shl.com (docws001.shl.com [159.249.56.252]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id EAA23010 for ; Tue, 21 Jan 1997 04:50:17 -0800 (PST) Received: from dalmsdoc01.shl.com (dalmsdoc01.shl.com [159.249.142.247]) by docws001.shl.com (8.7.3/8.7.3) with SMTP id GAA30930 for ; Tue, 21 Jan 1997 06:48:42 -0600 Received: by dalmsdoc01.shl.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC0767.E2D5A750@dalmsdoc01.shl.com>; Tue, 21 Jan 1997 06:54:02 -0600 Message-ID: From: CHILDERS Dale To: "ietf-ediint@imc.org" Subject: remove Date: Tue, 21 Jan 1997 06:47:00 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ietf-ediint@imc.org Precedence: bulk remove From owner-ietf-ediint Tue Jan 21 05:34:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id FAA23454 for ietf-ediint-bks; Tue, 21 Jan 1997 05:34:21 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from jcpenney.com (atlas.jcpenney.com [146.235.0.69]) by mail.proper.com (8.8.4/8.7.3) with SMTP id FAA23443 for ; Tue, 21 Jan 1997 05:34:17 -0800 (PST) From: WLANE@jcpenney.com Received: from osiris.jcpenney.com by jcpenney.com (SMI-8.6/SMI-SVR4) id HAA29014; Tue, 21 Jan 1997 07:34:26 -0600 Received: from wlane_1.jcpenney.com ([10.32.105.232]) by osiris.jcpenney.com (5.0/SMI-SVR4) id AA19735; Tue, 21 Jan 1997 07:34:04 -0600 Date: Tue, 21 Jan 1997 07:34:04 -0600 Message-Id: <9701211334.AA19735@osiris.jcpenney.com> To: ietf-ediint@imc.org Subject: remove Content-Type: text/plain Content-Description: remove Sender: owner-ietf-ediint@imc.org Precedence: bulk remove <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> William L. Lane, Manager, Electronic Commerce - Information Systems 6501 Legacy Drive, Plano, TX 75024-3698, Bldg E2-088, MS 5209 Office 972.431.7632, EFAX 972.531.7632, PFAX 972.431.7861 Internet Email ID=wlane@jcpenney.com From owner-ietf-ediint Tue Jan 21 08:44:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id IAA25184 for ietf-ediint-bks; Tue, 21 Jan 1997 08:44:49 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from wotan.compaq.com (root@wotan.compaq.com [207.18.199.254]) by mail.proper.com (8.8.4/8.7.3) with SMTP id IAA25180 for ; Tue, 21 Jan 1997 08:44:45 -0800 (PST) Received: from mail.compaq.com(really [207.18.199.36]) by wotan.compaq.com via sendmail with smtp id for ; Tue, 21 Jan 97 10:45:05 -0600 (CST) (/\##/\ Smail3.1.30.16 #30.2 built 25-may-96) Received: from bangate.compaq.com(really [131.168.114.234]) by mail.compaq.com via sendmail with smtp id for ; Tue, 21 Jan 97 10:41:37 -0600 (CST) (/\##/\ Smail3.1.30.16 #30.2 built 25-may-96) Received: by bangate.compaq.com; Tue, 21 Jan 97 10:41:32 -0600 Date: Tue, 21 Jan 97 10:39:11 CST Message-ID: X-Priority: 3 (Normal) To: From: "bob blaesing" Subject: remove from distribution list Sender: owner-ietf-ediint@imc.org Precedence: bulk remove If you have any questions, please contact me. Bob Blaesing, EDI Program Manager Compaq North America MS580204 20555 SH 249 Houston, Texas 77070-2698 Tel: 713-518-6906 Fax: 713-518-6223 Pager 1-800-781-0445 EMAIL BBlaesing@Netgate.Compaq.com From owner-ietf-ediint Tue Jan 21 11:53:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id LAA26609 for ietf-ediint-bks; Tue, 21 Jan 1997 11:53:42 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from gatekeeper.premenos.com (mail.premenos.com [150.105.250.1]) by mail.proper.com (8.8.4/8.7.3) with SMTP id LAA26605 for ; Tue, 21 Jan 1997 11:53:39 -0800 (PST) Received: from localhost (smap@localhost) by gatekeeper.premenos.com (8.6.5/8.6.5) id LAA08466; Tue, 21 Jan 1997 11:55:23 -0800 Received: from karenr.premenos.com(150.105.100.205) by mail.premenos.com via smap (V1.3mjr) id sma008439; Tue Jan 21 11:55:02 1997 Message-ID: <32E4F34E.A48@premenos.com> Date: Tue, 21 Jan 1997 11:48:14 -0500 From: Karen Rosenthal Reply-To: karenr@premenos.com Organization: Premenos X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: Carl Hage CC: ietf-ediint@imc.org Subject: Re: Requesting Signed Receipts References: <9701182230.AA09987@slick.chage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Chuck, Carl: My suggestion after reading both of your responses: Disposition-notification-options=signature=R/0, sigalg1, sigalg2 ...; mic=R/0, micalg1, micalg2 ...; Signature Logic: a. Whether or not signature is required, an MDN should be returned (if supported by the receiving application). b. Following the requirement status, is a list (of one or more, prioritized left to right) of acceptable signature algorithms. c. The recipient tries to sign the MDN with the leftmost algorithm. d. If the recipient cannot sign the MDN (doesn't support any of the algorithms), the MDN is returned unsigned. e. If d, if the signature was 'R'equired, disposition 'Unsupported Signature Algorithm' is returned. f. If d, and the signature was 'O'ptional, disposition 'autoprocessed' or another appropriate status is returned. Same logic for micalg, except 'Unsupported MIC Algorithm' would be returned in case e. -- Name: Karen Rosenthal E-mail: karenr@premenos.com Phone: (510)688-2928 Fax: (510)602-2133 From owner-ietf-ediint Wed Jan 22 04:33:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id EAA04135 for ietf-ediint-bks; Wed, 22 Jan 1997 04:33:05 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id EAA04131 for ; Wed, 22 Jan 1997 04:33:02 -0800 (PST) Received: from drummond.onramp.net (ppp1-08.ftwotx.onramp.net [199.184.212.171]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id GAA06736; Wed, 22 Jan 1997 06:33:22 -0600 (CST) Message-ID: <32E51494.4E1@onramp.net> Date: Tue, 21 Jan 1997 13:10:12 -0600 From: Rik Drummond X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Chris Carmac CC: ietf-ediint@imc.org Subject: Re: Please remove me from the EDI mailing list. References: <199701201812.NAA03141@ns.atomic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Chris Carmac wrote: > > remove to: ietf-ediint-request@imc.org unsubscribe From owner-ietf-ediint Wed Jan 22 05:22:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id FAA04416 for ietf-ediint-bks; Wed, 22 Jan 1997 05:22:11 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from wfscorp.com ([199.0.49.12]) by mail.proper.com (8.8.4/8.7.3) with SMTP id FAA04412 for ; Wed, 22 Jan 1997 05:22:08 -0800 (PST) Received: from Connect2 Message Router by wfscorp.com via Connect2-SMTP 4.20A; Wed, 22 Jan 1997 08:22:25 -0500 Message-ID: <7A5CD83001032B00@wfscorp.com> Date: Wed, 22 Jan 1997 08:19:00 -0500 From: Chuck Salerno Organization: World Fuel Services To: ietf-ediint@imc.org Subject: Remove MIME-Version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-disposition: inline Content-transfer-encoding: 7bit X-Mailer: Connect2-SMTP 4.20A MHS/SMF to SMTP Gateway Sender: owner-ietf-ediint@imc.org Precedence: bulk REMOVE From owner-ietf-ediint Wed Jan 22 06:42:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id GAA05075 for ietf-ediint-bks; Wed, 22 Jan 1997 06:42:37 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from ns.stercomm.com (ns.stercomm.com [199.3.19.2]) by mail.proper.com (8.8.4/8.7.3) with SMTP id GAA05071 for ; Wed, 22 Jan 1997 06:42:34 -0800 (PST) Received: ns.stercomm.com id AA05302; Wed, 22 Jan 1997 09:37:44 -0500 Mime-Version: 1.0 Date: Wed, 22 Jan 1997 09:37:00 -0500 Message-Id: <000179C2.1733@stercomm.com> From: "Jim_Hoyt/Sterling_Commerce@STERLING_COMMERCE"@stercomm.com Subject: How to unsubscribe from the ediint mailing list To: ietf-ediint@imc.org Content-Type: text/plain; charset=US-ASCII; name="How to unsubscribe from the ediint mailing list" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="How to unsubscribe from the ediint mailing list" Sender: owner-ietf-ediint@imc.org Precedence: bulk To remove yourself from the mailing list send a message to ietf-ediint-request@imc.org with the single word unsubscribe in the body of the message. Don't send the message to ieft-ediint@imc.org. Thank you From owner-ietf-ediint Wed Jan 22 10:10:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id KAA07142 for ietf-ediint-bks; Wed, 22 Jan 1997 10:10:28 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id KAA07138 for ; Wed, 22 Jan 1997 10:10:25 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA13190; Wed, 22 Jan 1997 10:09:22 -0800 Message-ID: <32E656C3.468A@actracorp.com> Date: Wed, 22 Jan 1997 10:04:51 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: karenr@premenos.com CC: Carl Hage , ietf-ediint@imc.org Subject: Re: Requesting Signed Receipts References: <9701182230.AA09987@slick.chage.com> <32E4F34E.A48@premenos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Karen, I like your suggestion. Carl do you have any thoughts? Karen Rosenthal wrote: > > Chuck, Carl: > > My suggestion after reading both of your responses: > > Disposition-notification-options=signature=R/0, sigalg1, sigalg2 > ...; mic=R/0, micalg1, micalg2 ...; > > Signature Logic: > > a. Whether or not signature is required, an MDN should be returned (if > supported by the receiving application). > b. Following the requirement status, is a list (of one or more, > prioritized left to right) of acceptable signature algorithms. > c. The recipient tries to sign the MDN with the leftmost algorithm. > d. If the recipient cannot sign the MDN (doesn't support any of the > algorithms), the MDN is returned unsigned. > e. If d, if the signature was 'R'equired, disposition 'Unsupported > Signature Algorithm' is returned. > f. If d, and the signature was 'O'ptional, disposition 'autoprocessed' > or another appropriate status is returned. > > Same logic for micalg, except 'Unsupported MIC Algorithm' would be > returned in case e. > > -- > Name: Karen Rosenthal > E-mail: karenr@premenos.com > Phone: (510)688-2928 > Fax: (510)602-2133 From owner-ietf-ediint Wed Jan 22 12:02:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id MAA08024 for ietf-ediint-bks; Wed, 22 Jan 1997 12:02:29 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from noteslab.neptunesoftware.com ([205.230.202.199]) by mail.proper.com (8.8.4/8.7.3) with SMTP id MAA08019 for ; Wed, 22 Jan 1997 12:02:24 -0800 (PST) Received: by noteslab.neptunesoftware.com(Lotus SMTP MTA v1.05 (274.9 11-27-1996)) id 85256427.006E12A2 ; Wed, 22 Jan 1997 15:02:17 -0400 X-Lotus-FromDomain: NEPTUNE SOFTWARE @ NEPSOFTEX From: "Raymond R Hood" To: ietf-ediint@imc.org Message-ID: <85256427.006DE2F7.00@noteslab.neptunesoftware.com> Date: Wed, 22 Jan 1997 15:00:50 -0400 Subject: remove Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=LkdWFZkeOkrkxqd0wJPuQ0WCQjXKIvzV8lRRmzOe0j6JgEm2OtMxobE1" Sender: owner-ietf-ediint@imc.org Precedence: bulk --0__=LkdWFZkeOkrkxqd0wJPuQ0WCQjXKIvzV8lRRmzOe0j6JgEm2OtMxobE1 Content-type: text/plain; charset=US-ASCII Raymond R Hood @ NEPTUNE SOFTWARE 01/22/97 03:00 PM (Embedded image moved to file: PIC14161.PCX) Gentlemen: I am being BCC'd on every remove request to your account. Why? Ray Hood ---------------------- Forwarded by Raymond R Hood/Neptune Software on 01/22/97 03:57 PM --------------------------- (Embedded image moved WLANE @ jcpenney.com to file: 01/21/97 08:34 AM PIC06173.PCX) To: ietf-ediint @ imc.org cc: (bcc: Raymond R Hood/Neptune Software) Subject: remove remove <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> William L. Lane, Manager, Electronic Commerce - Information Systems 6501 Legacy Drive, Plano, TX 75024-3698, Bldg E2-088, MS 5209 Office 972.431.7632, EFAX 972.531.7632, PFAX 972.431.7861 Internet Email ID=wlane@jcpenney.com --0__=LkdWFZkeOkrkxqd0wJPuQ0WCQjXKIvzV8lRRmzOe0j6JgEm2OtMxobE1 Content-type: application/octet-stream; name="PIC14161.PCX" Content-transfer-encoding: x-uuencode begin 644 PIC14161.PCX M"@4!"`````#"`0\````````````````````````````````````````````` M```````````````````````````!PP$!```````````````````````````` M```````````````````````````````````````````````````/_P?_!_\' M_P?_!_\'Y0?2!\0'QP_$#\(/#_\+_0L/PPL/PPL/PPL/PPL/PPL/PPL/PPL/ MPPL/PPL/PPL/PPL/PPL/PPL/PPL/PPL/PPL/PPL/PPL/PPL/PPL/"P\+#\,+ M#PL/"P\+#PL/"P\+#PL/"P\+#PL/"\,/"P\+#PO##PO##PO##PO##PO##PO# M#PO##PO##PO##PO##PO##PO##PO##PO##PO##PO##PO##PO##PO##PO##PO_ M#^$/T0_(#\0/P@\/#^4+#\<+#\,+#\,+#\,+#\,+#\,+#PL/"P\+#PL/"P\+ M#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/ M"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+ M#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/ M"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+ M#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/ M"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+ M#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"P\+#PL/"\,/"\,/"\,/"\,/ M"\$P8'QQ("$0/# M`@,"PA(&$@8'!@P&$`(0`L(&!\,3#,83PP?*$PS&$\,3PA/#$\(,!]\3#!+" M!\42`@,1Q`(2!\(2!@<&#`80!A`&$`8,!\,,!\D3PP?'$PS&$\,3PA/#$PP/ MP@S?$P82!\(2!\(2`A$"`P(#$@<2!P8'!@P&$`80Q@S##\('Q1/#!\D3!PS& M$\,3PA/#$PS##\0,W!/"!A(&PQ(&`A$"`P('!@<&R`S)#Q,'S1,'PPP'QQ/# M$\(3PQ,'#,8/QPP'U!,&$@82!A++#,X/PPP3#,<3P@?$#`?)$\03PA,3Q!,' MP@S+#]L,TP_&#`?#$PS#$P?$#`?+$\83PQ,3QA,'Q`SM#\@,!@?($\0,!\X3 MQQ/#$\(3RA,'QPS;#\L,$`4,!<(,P@8'U1/*$\43PQ,3T1,'VPP&$`80!A`" M!0P%#`4,!@P'!@?6$\L3Q1/#$Q/N$P8,!A`&$`(&#`8,PP8'UQ/+$\83PQ,3 M\!/*!@?8$\P3QA/#$Q/U$]L3S1/'$\,3PA/U$]L3S1/'$\,3PA,,````@``` M`(``@(````"`@`"``("`P,#`P-S`ILKP__OPH*"D@("`_P```/\`__\```#_ M_P#_`/______````@````(``@(````"`@`"``("`P,#`P-S`ILKP__OPH*"D M@("`_P```/\`__\```#__P#_`/______````@````(``@(````"`@`"``("` MP,#`P-S`ILKP__OPH*"D@("`_P```/\`__\```#__P#_`/______````@``` M`(``@(````"`@`"``("`P,#`P-S`ILKP__OPH*"D@("`_P```/\`__\```#_ M_P#_`/______````@````(``@(````"`@`"``("`P,#`P-S`ILKP__OPH*"D M@("`_P```/\`__\```#__P#_`/______````@````(``@(````"`@`"``("` MP,#`P-S`ILKP__OPH*"D@("`_P```/\`__\```#__P#_`/______````@``` M`(``@(````"`@`"``("`P,#`P-S`ILKP__OPH*"D@("`_P```/\`__\```#_ M_P#_`/______````@````(``@(````"`@`"``("`P,#`P-S`ILKP__OPH*"D M@("`_P```/\`__\```#__P#_`/______````@````(``@(````"`@`"``("` MP,#`P-S`ILKP__OPH*"D@("`_P```/\`__\```#__P#_`/______````@``` M`(``@(````"`@`"``("`P,#`P-S`ILKP__OPH*"D@("`_P```/\`__\```#_ M_P#_`/______````@````(``@(````"`@`"``("`P,#`P-S`ILKP__OPH*"D M@("`_P```/\`__\```#__P#_`/______````@````(``@(````"`@`"``("` MP,#`P-S`ILKP__OPH*"D@("`_P```/\`__\```#__P#_`/______````@``` J`(``@(````"`@`"`__OPH*"D@("`_P```/\`__\```#__P#_`/______ ` end --0__=LkdWFZkeOkrkxqd0wJPuQ0WCQjXKIvzV8lRRmzOe0j6JgEm2OtMxobE1-- From owner-ietf-ediint Wed Jan 22 23:03:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id XAA12995 for ietf-ediint-bks; Wed, 22 Jan 1997 23:03:16 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from gate.itr.ing.nl (ns.ingbank.nl [193.67.152.189]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id XAA12991 for ; Wed, 22 Jan 1997 23:03:12 -0800 (PST) Received: (from root@localhost) by gate.itr.ing.nl (8.7.1/8.6.12) id HAA18323 for ; Thu, 23 Jan 1997 07:57:05 +0100 (MET) Received: from webmaster.ing.nl(172.16.2.3) by gate_le0.itr.ing.nl via smap (V1.3) id sma018315; Thu Jan 23 07:56:38 1997 Received: by itr.ing.nl (8.6.9/SMI-4.1) id HAA11365; Thu, 23 Jan 1997 07:59:57 +0100 From: jbron@itr.ing.nl (Jan Bron) Message-Id: <199701230659.HAA11365@itr.ing.nl> Subject: remove To: ietf-ediint@imc.org Date: Thu, 23 Jan 1997 07:59:57 +0100 (MET) X-Mailer: ELM [version 2.4 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk remove From owner-ietf-ediint Thu Jan 23 08:51:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id IAA18415 for ietf-ediint-bks; Thu, 23 Jan 1997 08:51:34 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from edidev.tymnet.com (bashful.tymnet.com [131.146.56.23]) by mail.proper.com (8.8.4/8.7.3) with SMTP id IAA18411 for ; Thu, 23 Jan 1997 08:51:32 -0800 (PST) Received: by edidev.tymnet.com (1.37.109.4/16.2) id AA29619; Thu, 23 Jan 97 08:51:20 -0800 From: "Pat Ducaud" Message-Id: <9701230851.ZM29617@bashful.tymnet.com> Date: Thu, 23 Jan 1997 08:51:20 -0800 X-Mailer: Z-Mail (3.2.1 10apr95) To: "ietf-ediint@imc.org" Subject: Please, Remove Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ediint@imc.org Precedence: bulk Please, remove. From owner-ietf-ediint Thu Jan 23 13:18:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id NAA20484 for ietf-ediint-bks; Thu, 23 Jan 1997 13:18:38 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.4/8.7.3) with SMTP id NAA20480 for ; Thu, 23 Jan 1997 13:18:34 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA01171 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Thu, 23 Jan 1997 13:19:01 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA14310; Thu, 23 Jan 97 11:20:17 PST Date: Thu, 23 Jan 97 11:20:17 PST From: carl@chage.com (Carl Hage) Message-Id: <9701231920.AA14310@slick.chage.com> To: ietf-ediint@imc.org Subject: Re: Requesting Signed Receipts References: <9701182230.AA09987@slick.chage.com> <32E4F34E.A48@premenos.com> Organization: C. Hage Associates, Sunnyvale, CA Sender: owner-ietf-ediint@imc.org Precedence: bulk Karen Rosenthal (karenr@premenos.com) wrote: : Chuck, Carl: : My suggestion after reading both of your responses: : Disposition-notification-options=signature=R/0, sigalg1, sigalg2 : ...; mic=R/0, micalg1, micalg2 ...; The term 'sigalg' needs to be defined. As I mentioned, I think a good definition is the MIME type used in the multipart/signed part with the signature data. This is called 'protocol' not algorithm in the MIME RFC. The receiving software will decode based on the MIME type, not the algorithm, and two protocols with the same algorithm may be incompatible. : Signature Logic: : a. Whether or not signature is required, an MDN should be returned (if : supported by the receiving application). Yes, the MDN RFC should be changed to indicate this. For EDI, and MDN should be returned even if not explicitly requested. Also, the MDN should be signed. : b. Following the requirement status, is a list (of one or more, : prioritized left to right) of acceptable signature algorithms. : c. The recipient tries to sign the MDN with the leftmost algorithm. Yes, the sigalg (protocol) should be ordered by preference. : d. If the recipient cannot sign the MDN (doesn't support any of the : algorithms), the MDN is returned unsigned. I disagree. The MDN should be signed using multipart/signed of whatever protocol is supported. Even if the recipient cannot decode, non-repudiation applies. (This is the usual case with handwritten signatures which are typically authenticated after the fact.) [In no case would the MDN not be returned, other than failed delivery attempt in which case a DSN should be returned.] : e. If d, if the signature was 'R'equired, disposition 'Unsupported : Signature Algorithm' is returned. Where would this be returned? I'm not sure it's a good idea to cancel the transaction because the receipt couldn't be signed. A separate status from the overall disposition may be appropriate. : f. If d, and the signature was 'O'ptional, disposition 'autoprocessed' : or another appropriate status is returned. The R/O is meaningless in this context. I don't think the receipt signature process should affect the MDN status or receipt generation. : Same logic for micalg, except 'Unsupported MIC Algorithm' would be : returned in case e. Yes. However, the algorithm would match the leftmost sigalg, then leftmost micalg, and choose the first match. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Fri Jan 24 09:27:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id JAA28245 for ietf-ediint-bks; Fri, 24 Jan 1997 09:27:37 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id JAA28240 for ; Fri, 24 Jan 1997 09:27:34 -0800 (PST) Received: from drummond.onramp.net (ppp2-23.ftwotx.onramp.net [199.184.212.122]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id LAA10549; Fri, 24 Jan 1997 11:28:01 -0600 (CST) Message-ID: <32E655B8.3D0C@onramp.net> Date: Wed, 22 Jan 1997 12:00:24 -0600 From: Rik Drummond X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Chuck Salerno CC: ietf-ediint@imc.org Subject: Re: Remove References: <7A5CD83001032B00@wfscorp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Chuck Salerno wrote: > > REMOVE send a message to ietf-ediint-request@imc.org with unsubscribe in the message body....later..rik From owner-ietf-ediint Fri Jan 24 22:03:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id WAA03550 for ietf-ediint-bks; Fri, 24 Jan 1997 22:03:50 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id WAA03546 for ; Fri, 24 Jan 1997 22:03:47 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA10079; Fri, 24 Jan 1997 22:02:55 -0800 Message-ID: <32E9A0FF.2E33@actracorp.com> Date: Fri, 24 Jan 1997 21:58:23 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Carl Hage CC: ietf-ediint@imc.org Subject: Re: Requesting Signed Receipts References: <9701182230.AA09987@slick.chage.com> <32E4F34E.A48@premenos.com> <9701231920.AA14310@slick.chage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Carl Hage wrote: > > Karen Rosenthal (karenr@premenos.com) wrote: > : Chuck, Carl: > > : My suggestion after reading both of your responses: > > : Disposition-notification-options=signature=R/0, sigalg1, sigalg2 > : ...; mic=R/0, micalg1, micalg2 ...; > > The term 'sigalg' needs to be defined. As I mentioned, I think a good > definition is the MIME type used in the multipart/signed part with the > signature data. This is called 'protocol' not algorithm in the MIME RFC. Carl can you specify the syntax per the multipart/signed using the protocol designation. I think we are close on the syntax here. > The receiving software will decode based on the MIME type, not the > algorithm, and two protocols with the same algorithm may be incompatible. > > : Signature Logic: > > : a. Whether or not signature is required, an MDN should be returned (if > : supported by the receiving application). > > Yes, the MDN RFC should be changed to indicate this. All right I agree on this point. > > For EDI, and MDN should be returned even if not explicitly requested. > Also, the MDN should be signed. I disagree here. I don't think there should be implicit sendings of MDNs. If you need an MDN or a signed receipt you should request one. > > : b. Following the requirement status, is a list (of one or more, > : prioritized left to right) of acceptable signature algorithms. > : c. The recipient tries to sign the MDN with the leftmost algorithm. > > Yes, the sigalg (protocol) should be ordered by preference. > > : d. If the recipient cannot sign the MDN (doesn't support any of the > : algorithms), the MDN is returned unsigned. > > I disagree. The MDN should be signed using multipart/signed of whatever > protocol is supported. Even if the recipient cannot decode, non-repudiation > applies. (This is the usual case with handwritten signatures which are > typically authenticated after the fact.) OK, but if the UA really can't sign then an unsigned MDN is returned. > > [In no case would the MDN not be returned, other than failed delivery > attempt in which case a DSN should be returned.] > > : e. If d, if the signature was 'R'equired, disposition 'Unsupported > : Signature Algorithm' is returned. > > Where would this be returned? I'm not sure it's a good idea to cancel the > transaction because the receipt couldn't be signed. A separate status > from the overall disposition may be appropriate. > > : f. If d, and the signature was 'O'ptional, disposition 'autoprocessed' > : or another appropriate status is returned. > > The R/O is meaningless in this context. I don't think the receipt > signature process should affect the MDN status or receipt generation. The O designation would be used since an MDN is always expected to be sent back., > > : Same logic for micalg, except 'Unsupported MIC Algorithm' would be > : returned in case e. > > Yes. However, the algorithm would match the leftmost sigalg, then > leftmost micalg, and choose the first match. > -------------------------------------------------------------------------- > Carl Hage C. Hage Associates > Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 > Sunnyvale, CA 94086 From owner-ietf-ediint Sun Jan 26 21:57:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id VAA18910 for ietf-ediint-bks; Sun, 26 Jan 1997 21:57:45 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from uu5.psi.com (uu5.psi.com [38.145.226.3]) by mail.proper.com (8.8.4/8.7.3) with SMTP id VAA18906 for ; Sun, 26 Jan 1997 21:57:41 -0800 (PST) Received: from uu1190.UUCP by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA24089 for ietf-ediint@imc.org; Mon, 27 Jan 97 00:58:21 -0500 Received: from smtpgate.washpost.com by uucpgate.washpost.com id ab07017; 25 Jan 97 12:35 EST Received: by smtpgate.washpost.com with Microsoft Mail id <32EA6F4F@smtpgate.washpost.com>; Sat, 25 Jan 97 12:38:39 PST From: "Pailen, Loyce" To: ietf-ediint , owner-ietf-ediint Subject: RE: remove Date: Sat, 25 Jan 97 12:38:00 PST Message-Id: <32EA6F4F@smtpgate.washpost.com> X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-ediint@imc.org Precedence: bulk very good question. ---------- From: owner-ietf-ediint[SMTP:owner-ietf-ediint@imc.org] Sent: Wednesday, January 22, 1997 3:00 PM To: ietf-ediint Subject: remove <><> --0__=LkdWFZkeOkrkxqd0wJPuQ0WCQjXKIvzV8lRRmzOe0j6JgEm2OtMxobE1 Content-type: text/plain; charset=US-ASCII Raymond R Hood @ NEPTUNE SOFTWARE 01/22/97 03:00 PM (Embedded image moved to file: PIC14161.PCX) Gentlemen: I am being BCC'd on every remove request to your account. Why? Ray Hood ---------------------- Forwarded by Raymond R Hood/Neptune Software on 01/22/97 03:57 PM --------------------------- (Embedded image moved WLANE @ jcpenney.com to file: 01/21/97 08:34 AM PIC06173.PCX) To: ietf-ediint @ imc.org cc: (bcc: Raymond R Hood/Neptune Software) Subject: remove remove <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> William L. Lane, Manager, Electronic Commerce - Information Systems 6501 Legacy Drive, Plano, TX 75024-3698, Bldg E2-088, MS 5209 Office 972.431.7632, EFAX 972.531.7632, PFAX 972.431.7861 Internet Email ID=wlane@jcpenney.com --0__=LkdWFZkeOkrkxqd0wJPuQ0WCQjXKIvzV8lRRmzOe0j6JgEm2OtMxobE1 Content-type: application/octet-stream; name="PIC14161.PCX" Content-transfer-encoding: x-uuencode -------------------------------------------------------------------------- ---- This uuencoded part of the message containing the file PIC14161.PCX has been decoded and converted into an attachment. -------------------------------------------------------------------------- ---- --0__=LkdWFZkeOkrkxqd0wJPuQ0WCQjXKIvzV8lRRmzOe0j6JgEm2OtMxobE1 Content-type: application/octet-stream; name="PIC06173.PCX" Content-transfer-encoding: x-uuencode -------------------------------------------------------------------------- ---- This uuencoded part of the message containing the file PIC06173.PCX has been decoded and converted into an attachment. -------------------------------------------------------------------------- ---- --0__=LkdWFZkeOkrkxqd0wJPuQ0WCQjXKIvzV8lRRmzOe0j6JgEm2OtMxobE1-- From owner-ietf-ediint Wed Jan 29 05:14:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id FAA17287 for ietf-ediint-bks; Wed, 29 Jan 1997 05:14:16 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from zafu.bbn.com (ZAFU.BBN.COM [128.89.0.25]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id FAA17282 for ; Wed, 29 Jan 1997 05:14:13 -0800 (PST) Received: from KessFam (GKESSLER-REMOTE.BBN.COM [128.33.229.167]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id IAA03269; Wed, 29 Jan 1997 08:14:58 -0500 (EST) Message-ID: <32EF4D6C.4227@bbn.com> Date: Wed, 29 Jan 1997 08:15:24 -0500 From: Gary Kessler Reply-To: gkessler@bbn.com Organization: BBN X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: Rik Drummond CC: ietf-ediint@imc.org, edipilot@lists.Commerce.Net Subject: Re: EDIINT FYI: [Fwd: Final Final CommerceNet EDI press release] References: <32EF4887.74E9@onramp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Hi everyone. Congratulations! Although I was on the sidelines on this, it was a pleasure watching everyone working together so well. Later! /kessler Gary Kessler BBN gkessler@bbn.com +1 802-879-3375 From owner-ietf-ediint Wed Jan 29 05:01:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id FAA17181 for ietf-ediint-bks; Wed, 29 Jan 1997 05:01:29 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-ediint@imc.imc.org using -f Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id FAA17177 for ; Wed, 29 Jan 1997 05:01:26 -0800 (PST) Received: from drummond.onramp.net (ppp1-16.ftwotx.onramp.net [199.184.212.179]) by mailhost.onramp.net (8.8.5/8.6.5) with SMTP id HAA28903; Wed, 29 Jan 1997 07:02:09 -0600 (CST) Message-ID: <32EF4887.74E9@onramp.net> Date: Wed, 29 Jan 1997 06:54:31 -0600 From: Rik Drummond X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ietf-ediint@imc.org, edipilot@lists.commerce.net Subject: EDIINT FYI: [Fwd: Final Final CommerceNet EDI press release] Content-Type: multipart/mixed; boundary="------------4D575CB46143" Sender: owner-ietf-ediint@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------4D575CB46143 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is a press release, about those vendors who are implementing our EDI over Internet IETF Drafts to show secure, interoperable EDI over Internet is doable. Later...Rik --------------4D575CB46143 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from boa.commerce.net (root@boa.commerce.net [205.180.68.10]) by mailhost.onramp.net (8.8.5/8.6.5) with ESMTP id RAA03388 for ; Mon, 27 Jan 1997 17:23:15 -0600 (CST) Received: from Stacey1.commerce.net (pal22.commerce.net [205.180.68.121]) by boa.commerce.net (8.7.5/8.7.3) with SMTP id PAA19167 for ; Mon, 27 Jan 1997 15:25:12 -0800 Message-Id: <3.0.32.19970127152151.006f5fdc@pop.commerce.net> X-Sender: stacey@pop.commerce.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 27 Jan 1997 15:21:52 -0800 To: drummond@onramp.net From: Stacey Subject: Final Final CommerceNet EDI press release Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" HI Rik, Here is the press release that will go out tomorrow. /stacey >Return-Path: Calisa@aol.com >From: Calisa@aol.com >Date: Mon, 27 Jan 1997 17:55:46 -0500 (EST) >To: stacey@commerce.net >Subject: Final Final CommerceNet EDI press release > >Contact: >Stacey Bressler >CommerceNet >Tel: 415-858-1930, x232 >Email: stacey@commerce.net > > >CommerceNet Sponsors EDI Over Internet Initiative; Digitally-Signed >EDI Data is Exchanged Successfully for the First Time >--VeriSign Provides Digital Authentication for Open EDI Transactions-- > >SAN FRANCISCO, CA, January 27, 1997 -- CommerceNet, the premier industry >association for Internet commerce, today announced the successful results of >its ongoing initiative to demonstrate and promote the interoperable exchange >of EDI (Electronic Data Interchange) data over the Internet. The announcement >was made at the RSA Data Security Conference in San Francisco. > >During the week of January 20, five participating EDI vendors in the >initiative exchanged digitally-signed data, marking the first time that such >an event has occurred. Those organizations are Actra Business Systems (a >Netscape/GEIS company), AT&T, Digital Equipment Corporation, Premenos and >Sterling Commerce. > >VeriSign, Inc. is providing third-party digital authentication services for >many test participants through its Get-rEDI Digital ID Center (sm), a >Web-based enrollment site. Authentication, in the form of VeriSign Digital >IDs (sm), verifies the identity of parties in an electronic transaction and >ensures the integrity of messages. > >The complete list of initiative participants includes: Actra Business >Systems, Atlas Products International, AT&T, CyberPath, DanNet, Digital >Equipment Corporation, EDS, Harbinger, Premenos, Sterling Commerce and U.S. >Department of Defense. > >Jay M. Tenenbaum, CommerceNet founder and chairman, said, "CommerceNet is >pleased to sponsor the first-ever demonstration of interoperable and secure >EDI on the Internet. As today's news proves, the initiative takes us beyond >theorizing to actual implementation. Migrating successful technologies such >as EDI to more cost-effective solutions is a win-win strategy." > >--more-- >CommerceNet, Page 2 > >Stratton Sclavos, president and CEO of VeriSign, Inc., added, "EDI systems >have traditionally been expensive and closed. By spearheading the effort to >demonstrate open EDI across a public network, CommerceNet is helping to >accelerate the adoption of EDI. We are excited to be a part of this >groundbreaking initiative." > >The Benefits of Interoperability >"The Internet's ease of use and accessibility will help expand the benefits >of electronic commerce to a broader trading community," said Charles >Stambaugh, vice president of marketing for Sterling Commerce's Commerce >Service Group. "As a leading value-added services and software provider, >Sterling Commerce is pleased to participate in this exciting pilot project." > >"A lack of choice of EDI software vendors has been the major inhibitor of >Internet-based EDI to date. Once the interoperability initiative ends, users >will have a choice of EDI software vendors, regardless of the vendor selected >by their trading partners," said Lincoln Yarbrough, product manager, Actra >Business Systems and CommerceNet pilot team leader. > >Wayne Toye, EDI marketing manager at Digital Equipment Corporation, added, >"We are excited by the business benefits this initiative provides for >companies wanting to exchange secure EDI transactions over the Internet. We >look forward to our continuing participation in the ongoing CommerceNet >demonstration and testing." > >"AT&T is committed to making it safe and easy for businesses to conduct >electronic commerce over the Internet. Participation in this program helps >keep us at the forefront of technological innovation to help our customers >grow their businesses," said AT&T's Jim Daniell, electronic messaging and new >business development vice president. > >"Premenos is a strong advocate of open standards and adheres to them in >developing its electronic commerce products," said Steve Botts, director of >Templar product management for Premenos. "It's gratifying to see others >following and adopting the methodology and standards implemented in Templar >to secure EDI on the Internet." > >About EDI >EDI is a fast and dependable way to exchange business documents using >computer-to-computer communication between different companies. Early EDI >systems were proprietary and expensive, establishing barriers to entry and to >the open exchange of documents. EDI has historically been used to improve >only discrete processes such as automating the accounts payable function or >the funds transfer process. Internet technologies enable a new paradigm for >EDI. Increased interoperability will make EDI easier and less expensive to >implement. The new focus for EDI, using the Internet for electronic commerce, >is bridging the external and internal business processes which will enable >companies to improve their productivity beyond what has > > --more-- >CommerceNet, Page 3 > >been possible previously. Companies can now enter orders and purchases; do >accounts payable; transfer funds; and link seamlessly to suppliers, >distributors, customers, banks and transportation carriers. An open, >interactive EDI allows completion of the entire business transaction >point-to-point. > >Background on the Initiative >The CommerceNet initiative consists of three phases of testing: >* During Phase I, participants successfully demonstrated the exchange of EDI >documents over SMTP (Simple Mail Transport Protocol) using MIME >(Multi-purpose Internet Mail Extensions). The participating companies >completed this phase at the end of 1996. >* Phase II, now underway, covers security with signature and encryption. This >includes adding S/MIME (Secure/ Multi-purpose Internet Mail Extensions) >encryption and integrity technology (see www.rsa.com). PGP is optional, but >no vendors have selected PGP yet. Phase II will also include the use of >certificates, both self-issued and from VeriSign. >* In Phase III, the participating companies will test receipt requests and >signed and unsigned receipts. > >For technical information related to the initiative, please contact project >lead Rik Drummond, The Drummond Group, Tel: 817-294-7339. Email: >drummond@onramp.net. > >CommerceNet >CommerceNet is the premier industry association for promoting and building >electronic commerce solutions on the Internet. Launched in April 1994 in >Silicon Valley, CA, its membership has grown to over 200 companies and >organizations worldwide. They include the leading banks, telecommunications >companies, VANs, ISPs, online services, and software and services companies, >as well as major end-users, who together are transforming the net into a >global electronic marketplace. CommerceNet can be contacted at Tel: >415-858-1930; Fax: 415-858-1936; URL: http://www.commerce.net. (CN1A) > ># # # > > > > > > --------------4D575CB46143-- From owner-ietf-ediint Fri Jan 31 06:15:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA25864 for ietf-ediint-bks; Fri, 31 Jan 1997 06:15:27 -0800 (PST) Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id GAA25860 for ; Fri, 31 Jan 1997 06:15:24 -0800 (PST) Received: from email.demon.co.uk ([158.152.123.83]) by relay-6.mail.demon.net id aa625507; 31 Jan 97 12:34 GMT Message-ID: Date: Fri, 31 Jan 1997 10:15:44 +0000 To: ietf-ediint@imc.org From: Terry Dosdale Subject: UN/EDIFACT SJWG comments on EDIINT documents MIME-Version: 1.0 X-Mailer: Turnpike Version 3.02 Sender: owner-ietf-ediint@imc.org Precedence: bulk Dear Rik I am writing to you on behalf of the UN/EDIFACT Security Joint Working Group (SJWG), of which I am co-chair. The group has looked at the output of the EDIINT group, which I understand you lead, and would like to make some comments. Firstly, however, I thought you might like a little background information on the SJWG and its activities. SJWG ---- The SJWG was formed in its original incarnation back in 1989. It is an international group, with representatives from all the active UN/EDIFACT regions (though pan-America has not provided a representative for some time). Its role is to produce methods of securing EDIFACT transactions, by providing the means to transport security information within EDIFACT, based on existing security techniques. The group typically meets four times per year, and also has other roles such as awareness, liaison with other relevant groups, and monitoring other activities which may affect the standards (for example X.509 certificates). I should also mention that the UN/EDIFACT Finance and Security groups are currently working together to produce an internationally agreed UN/EDIFACT subset both of the payment messages and security, for use between banks and customers EDIFACT security standards -------------------------- The SJWG has produced a number of standards documents for EDIFACT security. It is intended that these will all be part of version 4 of the EDIFACT syntax, ISO 9735. There are 5 parts which relate to security: Part 5: Security rules for batch EDI (authenticity, integrity and non- repudiation of origin) Part 6: Secure authentication and acknowledgement message (message type - AUTACK) Part 7: Security rules for batch EDI (confidentiality) Part 9: Security key and certificate management message (message type - KEYMAN) Part 10: Security rules for interactive EDI Of these, Parts 5, 6 are going into the fast-track process (under the aegis of TC154) right now and Part 9 should follow in March. Parts 7 and 10 are expected to follow later this year. If you wish, I can send you the most recent versions of these parts. The earlier draft security standards (WP.4 document R.1026) have been available for users of version 3 of the syntax since March 1994, and have been successfully implemented by users throughout the world. Comments on EDIINT work ----------------------- The SJWG foresees that many EDI companies, especially VANS, are now searching for ways to do EDI on the Internet and at the same time to protect their business. Some EDI companies are also using Internet security mechanisms to safeguard their transactions. As we understand the situation, the EDIINT group is concentrating particularly on security with MIME, and two documents have been prepared, neither of which is an RFC. The first document (EDIINT01.TXT) seems to focus on the requirements for inter operable Internet EDI. The second document (EDIINT02.TXT) appears to concentrate on the actual implementation standards using MIME. The SJWG would like to suggest that this work could benefit from being put in a wider context, whether in the first document, or in a broader scoping document. This could include not only other Internet mechanisms, such as PGP, PEM etc, but also a slightly more in depth discussion of EDI security standards (X12 and EDIFACT), possibly including the relative pros and cons. Internet users need to be aware of what's available in EDI, and the business requirements it can meet, including (multiple) signing of individual messages (may be relevant to section 3.8 of the first EDIINT document), and transparency across multiple networks - for example originating on the Internet and ending up on an X.400 network. The SJWG would also like to clarify the position regarding the roles of the various parts of the EDIFACT syntax: The primary security mechanism is the use of security headers and trailers as described in Part 5 of the standard (or the older R.1026 Add.2). These provide all security services except non-repudiation of receipt, although confidentiality does require two extra segments as defined in Part 7. The AUTACK message, as defined in Part 6, was originally designed to be a secure acknowledgement message, providing non-repudiation of receipt. It turned out that it could also meet a particular business requirement in some countries, where EDIFACT data is sent at one time, then the next day the signatures which authorise the transactions are transmitted. Though this has also been used in some cases as an interim solution for securing whole interchanges (which was not available using security headers and trailers in version 3 of the syntax), it is not seen as the strategic direction for the standard. This may help clear up some slight confusion identifying EDIFACT security with AUTACK in the two EDIINT documents. The CONTRL message, defined in Part 4, is not itself a security message. Its primary uses are to report syntax errors and provide some type of (unsecured) acknowledgement of receipt. This information may be useful for section 4.1 of the first EDIINT document. I have also proposed that individual SJWG members wishing to make detailed comments on the documents should do so directly, the format meeting that specified in your documents. Please feel free to distribute this note to members of your group. I look forward to hearing from you in the near future. Kind regards Terry Dosdale Dr Terence Dosdale CEng FBCS Chartered Information Systems Practitioner ----------------------------------------------------------------------- Axiom Services Limited - for - Electronic Commerce/Security 3 Holt Park Rise http://www.email.demon.co.uk LEEDS Tel +44 (0)113 230 1910 LS16 7QZ Fax +44 (0)113 230 1910 UK Email axiom@email.demon.co.uk ----------------------------------------------------------------------- From owner-ietf-ediint Mon Feb 3 01:55:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA17586 for ietf-ediint-bks; Mon, 3 Feb 1997 01:55:02 -0800 (PST) Received: from relay-7.mail.demon.net (relay-7.mail.demon.net [194.217.242.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id BAA17578 for ; Mon, 3 Feb 1997 01:54:59 -0800 (PST) Received: from email.demon.co.uk ([158.152.123.83]) by relay-5.mail.demon.net id ab518823; 3 Feb 97 9:33 GMT Message-ID: Date: Mon, 3 Feb 1997 09:30:36 +0000 To: ietf-ediint@imc.org From: Terry Dosdale Subject: UN/EDIFACT SJWG comments on EDIINT documents MIME-Version: 1.0 X-Mailer: Turnpike Version 3.02 Sender: owner-ietf-ediint@imc.org Precedence: bulk Dear Rik Further to my previous email, I wanted to explain that most SJWG members (including myself) have not subscribed to the EDIINT list. It would therefore be most helpful if, after discussing the document with your group, you could make a formal reply to me. I will then distribute it to the SJWG members. I apologise if this seems rather formal, but we already belong to several EDIFACT lists, and I am sure you will understand the amount of mail which this can generate! Kind regards Terry Dosdale Dr Terence Dosdale CEng FBCS Chartered Information Systems Practitioner ----------------------------------------------------------------------- Axiom Services Limited - for - Electronic Commerce/Security 3 Holt Park Rise http://www.email.demon.co.uk LEEDS Tel +44 (0)113 230 1910 LS16 7QZ Fax +44 (0)113 230 1910 UK Email axiom@email.demon.co.uk ----------------------------------------------------------------------- From owner-ietf-ediint Mon Feb 3 04:23:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id EAA21490 for ietf-ediint-bks; Mon, 3 Feb 1997 04:23:19 -0800 (PST) Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by mail.proper.com (8.8.5/8.7.3) with SMTP id EAA21480 for ; Mon, 3 Feb 1997 04:23:15 -0800 (PST) Received: from email.demon.co.uk ([158.152.123.83]) by relay-10.mail.demon.net id aa1023580; 3 Feb 97 12:22 GMT Message-ID: Date: Mon, 3 Feb 1997 11:55:00 +0000 To: ietf-ediint@imc.org From: Terry Dosdale Subject: UN/EDIFACT SJWG MIME-Version: 1.0 X-Mailer: Turnpike Version 3.02 Sender: owner-ietf-ediint@imc.org Precedence: bulk I have had several enquiries (from Joe, Wayne and James) as to whether the SJWG has any newsgroup or list server. We try to be as open as possible, but we're not an Internet group, so the group has a closed list for its day to day business, like correcting documents, which would be boring to other people. However, the idea of having an open list in parallel has been mooted in the past, and I am quite keen on this, so I will contact the appropriate organisation to see if this is possible. You can also participate actively through your regional UN/EDIFACT body (PAEB) - I assume you're all based in the US? I suggest you contact Jim Sykes (uslevp8s@ibmmail.com). You may get the formal documents from Axiom Services' Web page (below). Either look at the EC/EDI/Security link to get the last version published by the UN, or the Security Joint Working Group link to find the most recent versions (to be published by the UN in March, with different cover pages). Kind regards Terry Dosdale Dr Terence Dosdale CEng FBCS Chartered Information Systems Practitioner ----------------------------------------------------------------------- Axiom Services Limited - for - Electronic Commerce/EDI/Security 3 Holt Park Rise http://www.email.demon.co.uk LEEDS Tel +44 (0)113 230 1910 LS16 7QZ Fax +44 (0)113 230 1910 UK Email axiom@email.demon.co.uk ----------------------------------------------------------------------- From owner-ietf-ediint Mon Feb 3 16:05:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA29842 for ietf-ediint-bks; Mon, 3 Feb 1997 16:05:26 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA29836 for ; Mon, 3 Feb 1997 16:05:23 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA26369; Mon, 3 Feb 1997 16:05:03 -0800 Message-ID: <32F67C18.7B8F@actracorp.com> Date: Mon, 03 Feb 1997 16:00:24 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Carl Hage CC: ietf-ediint@imc.org, edipilot@commerce.net Subject: Re: Requesting Signed Receipts References: <9701182230.AA09987@slick.chage.com> <32E4F34E.A48@premenos.com> <9701231920.AA14310@slick.chage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Carl, I will update the MDN portion of AS#1 with some of your and Karen's suggestions on requesting and processing MDNs. More specifically I will: 1). Incorporate a signature-protocol parameter with values equal to the MIME defined types of application/x-pkcs7-signature and application/pgp-signature. This parameter will specify which format the requestor would like the returned signed MDN to be in. This parameter will be used for completeness, and an explicit signature-algorithm parameter will still be specified, because within each security format, the choices for algorithms is not or will not be fixed. I don't think it is a good idea to make assumptions on what the supported algorithms are from the security format. 2). Incorporate a signature-algorithm parameter that is a list of signature algorithms that the requestor would like the recipient to use in signing the MIC. The list of signature algorithms are processed from left to right by the recipient. 3). Incorporate a signature-micalg parameter that is a list of MIC algorithms that the requestor would like the recipient to use in calculating the MIC on the MDN. The list of signature-micalgs are processed from left to right by the recipient. All the parameters specified above will have the O designation so that an MDN can always be returned to the requestor. Unrecognized parameters or parameter values will have a new disposition, "unrecognized parameter or parameter value" that will be defined in the MDN specification. The dispositions that are specific to the signed receipt will be specified in the AS#1 and registerd with IANA. At this point in time, this is the list of dispostion extended values defined by the AS#1: 1). Unsupported signature algorithm - occurs when none of the list of signature algorithms requested are supported by the recipient. 2). Unsupported signature MIC algorithm - occurs when none of the list of MIC algorithms requested are supported by the recipient. 3). decryption failed 2). authentication failed 3). integrity check failed The consensus seems to be that MDNs should be returned in all cases. At times they may not always be signed, even though a signature is requested, because of processing failures as specified above. I'm not sure I agree with Carl's suggestion that an MDN be signed by a recipient with an algorithm not supported by the requestor. Non-repudiation does not apply, because the requestor cannot verify the signature of the recipient in the above case. I also want to keep all parameters explicit, in the sense that if a signature-micalg is not specified, then this is an error - unsupported signature algorithm or a new disposition if the list prefers - rather than have the recipient default in using what might be supported by the particular "protocol", i.e. pkcs7 or pgp. I'll incorporate these changes and re-send the MDN section of AS#1 by Wednesday of this week if no furthur comments come my way. Carl Hage wrote: > > Karen Rosenthal (karenr@premenos.com) wrote: > : Chuck, Carl: > > : My suggestion after reading both of your responses: > > : Disposition-notification-options=signature=R/0, sigalg1, sigalg2 > : ...; mic=R/0, micalg1, micalg2 ...; > > The term 'sigalg' needs to be defined. As I mentioned, I think a good > definition is the MIME type used in the multipart/signed part with the > signature data. This is called 'protocol' not algorithm in the MIME RFC. > The receiving software will decode based on the MIME type, not the > algorithm, and two protocols with the same algorithm may be incompatible. > > : Signature Logic: > > : a. Whether or not signature is required, an MDN should be returned (if > : supported by the receiving application). > > Yes, the MDN RFC should be changed to indicate this. > > For EDI, and MDN should be returned even if not explicitly requested. > Also, the MDN should be signed. > > : b. Following the requirement status, is a list (of one or more, > : prioritized left to right) of acceptable signature algorithms. > : c. The recipient tries to sign the MDN with the leftmost algorithm. > > Yes, the sigalg (protocol) should be ordered by preference. > > : d. If the recipient cannot sign the MDN (doesn't support any of the > : algorithms), the MDN is returned unsigned. > > I disagree. The MDN should be signed using multipart/signed of whatever > protocol is supported. Even if the recipient cannot decode, non-repudiation > applies. (This is the usual case with handwritten signatures which are > typically authenticated after the fact.) > > [In no case would the MDN not be returned, other than failed delivery > attempt in which case a DSN should be returned.] > > : e. If d, if the signature was 'R'equired, disposition 'Unsupported > : Signature Algorithm' is returned. > > Where would this be returned? I'm not sure it's a good idea to cancel the > transaction because the receipt couldn't be signed. A separate status > from the overall disposition may be appropriate. > > : f. If d, and the signature was 'O'ptional, disposition 'autoprocessed' > : or another appropriate status is returned. > > The R/O is meaningless in this context. I don't think the receipt > signature process should affect the MDN status or receipt generation. > > : Same logic for micalg, except 'Unsupported MIC Algorithm' would be > : returned in case e. > > Yes. However, the algorithm would match the leftmost sigalg, then > leftmost micalg, and choose the first match. > -------------------------------------------------------------------------- > Carl Hage C. Hage Associates > Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 > Sunnyvale, CA 94086 From owner-ietf-ediint Mon Feb 3 17:13:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA00778 for ietf-ediint-bks; Mon, 3 Feb 1997 17:13:04 -0800 (PST) Received: from gatekeeper.premenos.com (mail.premenos.com [150.105.250.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA00774 for ; Mon, 3 Feb 1997 17:13:00 -0800 (PST) Received: from localhost (smap@localhost) by gatekeeper.premenos.com (8.6.5/8.6.5) id RAA25014; Mon, 3 Feb 1997 17:15:19 -0800 Received: from karenr.premenos.com(150.105.100.205) by mail.premenos.com via smap (V1.3mjr) id sma025006; Mon Feb 3 17:15:07 1997 Message-ID: <32F661C6.1EA9@premenos.com> Date: Mon, 03 Feb 1997 17:08:07 -0500 From: Karen Rosenthal Reply-To: karenr@premenos.com Organization: Premenos X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: chucks@actracorp.com CC: Carl Hage , ietf-ediint@imc.org, edipilot@commerce.net Subject: Re: Requesting Signed Receipts References: <9701182230.AA09987@slick.chage.com> <32E4F34E.A48@premenos.com> <9701231920.AA14310@slick.chage.com> <32F67C18.7B8F@actracorp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Chuck Shih wrote: > > All the parameters specified above will have the O designation so that > an MDN can always be returned to the requestor. Unrecognized parameters > or parameter values will have a new disposition, "unrecognized parameter > or parameter value" that will be defined in the MDN specification. > > The dispositions that are specific to the signed receipt will be > specified in the AS#1 and registerd with IANA. At this point in time, > this is the list of dispostion extended values defined by the AS#1: > > 1). Unsupported signature algorithm - occurs when none of the list of > signature algorithms requested are supported by the recipient. > > 2). Unsupported signature MIC algorithm - occurs when none of the list > of MIC algorithms requested are supported by the recipient. > > 3). decryption failed > > 2). authentication failed > > 3). integrity check failed > I liked Carl's comment in his previous email that perhaps the MDN request errors should be separated from the actual receipt disposition. I think the originator will want to know if decryption, authentication or integrity failed, regardless of whether their request was syntactically correct or the signature or micalg preferences are supported by the recipient. Non-repudiation shouldn't hold unless the MDN is successfully signed & the micalg is returned and reverified, but the additional info is still valuable. > I'm not sure I agree with Carl's suggestion that an MDN be signed by a > recipient with an algorithm not supported by the requestor. > Non-repudiation does not apply, because the requestor cannot verify the > signature of the recipient in the above case. > Agreed. If none of the requested signing algorithms are supported, it makes no sense to sign the MDN. What about if the signing algorithm is supported, but none of the hashing algorithms are? Do we just leave out the MIC, but sign anyways? -- Name: Karen Rosenthal E-mail: karenr@premenos.com Phone: (510)688-2928 Fax: (510)602-2133 From owner-ietf-ediint Tue Feb 4 02:10:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id CAA05402 for ietf-ediint-bks; Tue, 4 Feb 1997 02:10:59 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id CAA05398 for ; Tue, 4 Feb 1997 02:10:55 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA01139 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Tue, 4 Feb 1997 02:12:05 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA05497; Mon, 3 Feb 97 19:53:10 PST Date: Mon, 3 Feb 97 19:53:10 PST From: carl@chage.com (Carl Hage) Message-Id: <9702040353.AA05497@slick.chage.com> To: ietf-ediint@imc.org Subject: Re: Requesting Signed Receipts Sender: owner-ietf-ediint@imc.org Precedence: bulk >From chucks@actracorp.com Mon Feb 3 17:56:10 1997 > >suggestions on requesting and processing MDNs. More specifically I will: > >1). Incorporate a signature-protocol parameter with values equal to the >MIME defined types of application/x-pkcs7-signature and >application/pgp-signature. This parameter will specify which format the >requestor would like the returned signed MDN to be in. This parameter >will be used for completeness, and an explicit signature-algorithm >parameter will still be specified, because within each security format, >the choices for algorithms is not or will not be fixed. I don't think it >is a good idea to make assumptions on what the supported algorithms are >from the security format. OK. Probably, 'x-pkcs7-signature' and 'pgp-signature' are appropriate since 'application' is assumed. New types can be added implicitly with new MIME definitions. Typically, the algorithms are defined by software packages that support the protocols. For example, the sigalg and micalg used by PGP does not vary for any existing PGP implementation. Likewise, I think all S/MIME software supports identical sets of sigalgs and micalgs. Not all versions of PGP and S/MIME are compatible. This is not just an algorithm issue, it's a protocol issue. There might be different MIME types for different versions, but lack of version presents a problem. This could be inferred from sigalgs, but not necesarily. I agree that there could be a need to identify algorithms, but not currently with PGP and S/MIME. It might be worth noting the semantics if the signature-protocol is specified but a signature-algorithm and mic-alg is not specified. The signature-protocol should be a list. >2). Incorporate a signature-algorithm parameter that is a list ... >3). Incorporate a signature-micalg parameter that is a list of MIC ... OK. How are the values defined, and how are they updated? >The dispositions that are specific to the signed receipt will be >specified in the AS#1 and registerd with IANA. At this point in time, >this is the list of dispostion extended values defined by the AS#1: > >1). Unsupported signature algorithm - occurs when none of the list of >signature algorithms requested are supported by the recipient. >2). Unsupported signature MIC algorithm - occurs when none of the list >of MIC algorithms requested are supported by the recipient. This is not a _message_ disposition-- this is specifically related to the MDN. >3). decryption failed > >2). authentication failed > >3). integrity check failed These are message disposition's, assuming the decryption/authentication/ integrity failure causes the message to be ignored. >The consensus seems to be that MDNs should be returned in all cases. At >times they may not always be signed, even though a signature is >requested, because of processing failures as specified above. As above, signing of a receipt is independent of the processing of a message. Failure to support a receipt signature should not "delete" the message or it's disposition. >I'm not sure I agree with Carl's suggestion that an MDN be signed by a >recipient with an algorithm not supported by the requestor. >Non-repudiation does not apply, because the requestor cannot verify the >signature of the recipient in the above case. The spec should probably not require nor prohibit signing. Here's my rationale for always signing an MDN, even if it can be _immediately_ authenticated: What happens when you get a uuencode/base64/stuffit, etc. file that you can't decode? You usually download a decoder. Likewise, people will probably install signature authentication software if they can't decode a signature. Usually the sigalgs are defined by the signer not the recipient and are tied to the type of public key. Non-repudiation applies since the signature can be authenticated after-the-fact. If you can't decode, you can't authenticate (immediately) but the signer can't deny signing the document since it can be proven (in court or whatever) at some later time. One question to be addressed is-- should the inability to return a signed receipt in the desired format cancel a transaction? I think no should be the answer. If the transaction is processed, then the receipt should still be signed so that it can be authenticated at least some point in time. Otherwise, the receipt cannot _ever_ be authenticated. If the unsupported MDN sigalg is required to cause the complete message to be rejected, then that should be explicity stated. Even in this case, the MDN should be signed (in some protocol) so the reader of the MDN can at some point distinguish the MDN from a bogus MDN. An unsigned MDN can be fraudulent, whereas a signed MDN can be verified later even if software is not immediately available. The most important requirement is not to prohibit returning a signed receipt. The receipt should always be signed with multipart/signed, and so the body should be readable even if there is a problem decoding the signature. You can't have a signature without a MIC-- they are inseparable. So you can't sign without a MIC. >I also want to keep all parameters explicit, in the sense that if a >signature-micalg is not specified, then this is an error - unsupported >signature algorithm or a new disposition if the list prefers - rather >than have the recipient default in using what might be supported by the >particular "protocol", i.e. pkcs7 or pgp. That means you need to maintain the definitions of these. I see a problem in that people might not use the correct values. Other than misinterpretation of the values, eliminating a default doesn't hurt other than being verbose. -------------------------------------------------------------------------- The supported algorithms are not likely to be a problem. However, versions of the encryption and signature protocol may be a problem. If one can encrypt, then it's likely they can authenticate a receipt. You have either PGP, PKCS, FORTEZZA/DSN, etc., which defines encryption as well as signatures, including the protocols. Though it is unlikely there will be a problem with mismatched sigalgs, it's important that the EDI RFC does not specify an inappropriate action should this occur, e.g. cancelling the MDN or transaction (if it's not supposed to), or processing a message with a receipt that can never be authenticated. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Fri Feb 7 09:18:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA24203 for ietf-ediint-bks; Fri, 7 Feb 1997 09:18:34 -0800 (PST) Received: from gatekeeper.premenos.com (mail.premenos.com [150.105.250.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA24199 for ; Fri, 7 Feb 1997 09:18:30 -0800 (PST) Received: from localhost (smap@localhost) by gatekeeper.premenos.com (8.6.5/8.6.5) id JAA24769; Fri, 7 Feb 1997 09:21:58 -0800 Received: from karenr.premenos.com(150.105.100.205) by mail.premenos.com via smap (V1.3mjr) id sma024765; Fri Feb 7 09:21:07 1997 Message-ID: <32FB38A0.324@premenos.com> Date: Fri, 07 Feb 1997 09:13:52 -0500 From: Karen Rosenthal Reply-To: karenr@premenos.com Organization: Premenos X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: edipilot@commerce.net CC: ietf-ediint@imc.org Subject: Use of multipart/encrypted with S/MIME Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk I am looking for some clarification on the (intended?) use of the multipart/encrypted Content-Type with S/MIME. It is my understanding from the edipilot conference call this past Wednesday, that rather than supporting directed adherence to the S/MIME v2 specification (using application/x-pkcs7-mime body parts), the ediint working group is suggesting adherence to RFC1847 (Security Multiparts for MIME - Multipart/Signed and Multipart/Encrypted). (If I am mistaken here, please let me know!) The usage of multipart/signed is well detailed in the S/MIME v2 specification, but use of multipart/encrypted is not mentioned, nor is it accounted for in design. So for a vendor that supports S/MIME, but not PGP or MOSS, what should be used for the multipart/encrypted protocol, and what will the MIME message look like? Regards, -- Name: Karen Rosenthal E-mail: karenr@premenos.com Phone: (510)688-2928 Fax: (510)602-2133 From owner-ietf-ediint Fri Feb 7 10:22:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA26111 for ietf-ediint-bks; Fri, 7 Feb 1997 10:22:14 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA26106 for ; Fri, 7 Feb 1997 10:22:11 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA12459; Fri, 7 Feb 1997 10:22:04 -0800 Message-ID: <32FB71B3.4C78@actracorp.com> Date: Fri, 07 Feb 1997 10:17:23 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: karenr@premenos.com CC: edipilot@commerce.net, ietf-ediint@imc.org Subject: Re: Use of multipart/encrypted with S/MIME References: <32FB38A0.324@premenos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Karen, The AS#1 is not recommending use of multipart/encrypted when using S/MIME. The S/MIME enveloped data format will still be used. The multipart/signed however will be recommended (per the wg meeting in SJ), instead of the PKCS signed data format. Both are supported by S/MIME, but multipart/signed is also specified as an Internet RFC. Does this clarify the confusion? Karen Rosenthal wrote: > > +----------------------------------------------------------------------+ > This message was addressed to: edipilot@lists.commerce.net > +----------------------------------------------------------------------+ > > I am looking for some clarification on the (intended?) use of the > multipart/encrypted Content-Type with S/MIME. > > It is my understanding from the edipilot conference call this past > Wednesday, that rather than supporting directed adherence to the S/MIME > v2 specification (using application/x-pkcs7-mime body parts), the ediint > working group is suggesting adherence to RFC1847 (Security Multiparts > for MIME - Multipart/Signed and Multipart/Encrypted). (If I am mistaken > here, please let me know!) > > The usage of multipart/signed is well detailed in the S/MIME v2 > specification, but use of multipart/encrypted is not mentioned, nor is > it accounted for in design. So for a vendor that supports S/MIME, but > not PGP or MOSS, what should be used for the multipart/encrypted > protocol, and what will the MIME message look like? > > Regards, > -- > Name: Karen Rosenthal > E-mail: karenr@premenos.com > Phone: (510)688-2928 > Fax: (510)602-2133 > ------------------------------------------------------------------------- > This message was sent by a majordomo-based automatic list manager. > Subscriptions to and archives of this list are available to CommerceNet > members, partners, and invited guests. For further information send a > mail message to 'edipilot-request@lists.commerce.net' with 'help' > (no quotations) contained in the body of your message. From owner-ietf-ediint Fri Feb 7 10:43:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA26725 for ietf-ediint-bks; Fri, 7 Feb 1997 10:43:04 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA26721 for ; Fri, 7 Feb 1997 10:43:01 -0800 (PST) Received: from drummond.onramp.net (ppp1-16.ftwotx.onramp.net [199.184.212.179]) by mailhost.onramp.net (8.8.5/8.6.5) with SMTP id MAA13543; Fri, 7 Feb 1997 12:44:12 -0600 (CST) Message-ID: <32FB77EF.D65@onramp.net> Date: Fri, 07 Feb 1997 12:43:59 -0600 From: Rik Drummond Reply-To: drummond@onramp.net Organization: Drummond Group X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: karenr@premenos.com CC: edipilot@commerce.net, ietf-ediint@imc.org Subject: Re: Use of multipart/encrypted with S/MIME References: <32FB38A0.324@premenos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk We will be using the standard pkcs-7/encrypted form from smime.....whoever we will be using as the smime spec say the multipart signed as our many structure for signature....by doing this the receipent can read a signed message if they do not have smime.....hope that helps.... Karen Rosenthal wrote: > > +----------------------------------------------------------------------+ > This message was addressed to: edipilot@lists.commerce.net > +----------------------------------------------------------------------+ > > I am looking for some clarification on the (intended?) use of the > multipart/encrypted Content-Type with S/MIME. > > It is my understanding from the edipilot conference call this past > Wednesday, that rather than supporting directed adherence to the S/MIME > v2 specification (using application/x-pkcs7-mime body parts), the ediint > working group is suggesting adherence to RFC1847 (Security Multiparts > for MIME - Multipart/Signed and Multipart/Encrypted). (If I am mistaken > here, please let me know!) > > The usage of multipart/signed is well detailed in the S/MIME v2 > specification, but use of multipart/encrypted is not mentioned, nor is > it accounted for in design. So for a vendor that supports S/MIME, but > not PGP or MOSS, what should be used for the multipart/encrypted > protocol, and what will the MIME message look like? > > Regards, > -- > Name: Karen Rosenthal > E-mail: karenr@premenos.com > Phone: (510)688-2928 > Fax: (510)602-2133 > ------------------------------------------------------------------------- > This message was sent by a majordomo-based automatic list manager. > Subscriptions to and archives of this list are available to CommerceNet > members, partners, and invited guests. For further information send a > mail message to 'edipilot-request@lists.commerce.net' with 'help' > (no quotations) contained in the body of your message. From owner-ietf-ediint Fri Feb 7 11:49:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA28530 for ietf-ediint-bks; Fri, 7 Feb 1997 11:49:29 -0800 (PST) Received: from gatekeeper.premenos.com (mail.premenos.com [150.105.250.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA28526 for ; Fri, 7 Feb 1997 11:49:26 -0800 (PST) Received: from localhost (smap@localhost) by gatekeeper.premenos.com (8.6.5/8.6.5) id LAA29909; Fri, 7 Feb 1997 11:46:12 -0800 Received: from karenr.premenos.com(150.105.100.205) by mail.premenos.com via smap (V1.3mjr) id sma029886; Fri Feb 7 11:45:15 1997 Message-ID: <32FB5A67.5264@premenos.com> Date: Fri, 07 Feb 1997 11:37:59 -0500 From: Karen Rosenthal Reply-To: karenr@premenos.com Organization: Premenos X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: chucks@actracorp.com, drummand@onramp.net CC: edipilot@commerce.net, ietf-ediint@imc.org Subject: Re: Use of multipart/encrypted with S/MIME Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Chuck & Rik, Thanks for your quick responses. For clarification: . Signed only goes out as multipart/signed, protocol=application/x-pkcs7-signature. . Encrypted only goes out as application/x-pkcs7-mime, EnvelopedData. Question: Does Signed & Encrypted go out as multipart/signed within application/x-pkcs7-mime, EnvelopedData, or as application/x-pkcs7-mime, SignedData within application/x-pkcs7-mime, EnvelopedData? The former doesn't make sense. If the latter, then I don't understand the issue discussed Wednesday on edipilot test 8 (during which I obviously misunderstood that only multipart/signed within multipart/encrypted would be accepted)? Thanks, Karen Chuck wrote: > Karen, > > The AS#1 is not recommending use of multipart/encrypted when using > S/MIME. The S/MIME enveloped data format will still be used. The > multipart/signed however will be recommended (per the wg meeting in > SJ), > instead of the PKCS signed data format. Both are supported by S/MIME, > but multipart/signed is also specified as an Internet RFC. > > Does this clarify the confusion? > Rik wrote: > We will be using the standard pkcs-7/encrypted form from > smime.....whoever we will be using as the smime spec say the multipart > signed as our many structure for signature....by doing this the > receipent can read a signed message if they do not have smime.....hope > that helps.... -- Name: Karen Rosenthal E-mail: karenr@premenos.com Phone: (510)688-2928 Fax: (510)602-2133 From owner-ietf-ediint Fri Feb 7 12:24:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA29425 for ietf-ediint-bks; Fri, 7 Feb 1997 12:24:49 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA29420 for ; Fri, 7 Feb 1997 12:24:46 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA18145; Fri, 7 Feb 1997 12:24:40 -0800 Message-ID: <32FB8E6F.1A3A@actracorp.com> Date: Fri, 07 Feb 1997 12:19:59 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: karenr@premenos.com CC: drummand@onramp.net, edipilot@commerce.net, ietf-ediint@imc.org Subject: Re: Use of multipart/encrypted with S/MIME References: <32FB5A67.5264@premenos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Karen, Since I wasn't on the conference call, why doesn't the multipart/signed within EnvelopedData make sense? Karen Rosenthal wrote: > > Chuck & Rik, > > Thanks for your quick responses. For clarification: > > . Signed only goes out as multipart/signed, > protocol=application/x-pkcs7-signature. > . Encrypted only goes out as application/x-pkcs7-mime, EnvelopedData. > > Question: Does Signed & Encrypted go out as multipart/signed within > application/x-pkcs7-mime, EnvelopedData, or as application/x-pkcs7-mime, > SignedData within application/x-pkcs7-mime, EnvelopedData? The former > doesn't make sense. If the latter, then I don't understand the issue > discussed Wednesday on edipilot test 8 (during which I obviously > misunderstood that only multipart/signed within multipart/encrypted > would be accepted)? > > Thanks, > Karen > > Chuck wrote: > > Karen, > > > > The AS#1 is not recommending use of multipart/encrypted when using > > S/MIME. The S/MIME enveloped data format will still be used. The > > multipart/signed however will be recommended (per the wg meeting in > SJ), > > instead of the PKCS signed data format. Both are supported by S/MIME, > > but multipart/signed is also specified as an Internet RFC. > > > > Does this clarify the confusion? > > > > Rik wrote: > > We will be using the standard pkcs-7/encrypted form from > > smime.....whoever we will be using as the smime spec say the multipart > > signed as our many structure for signature....by doing this the > > receipent can read a signed message if they do not have smime.....hope > > that helps.... > > -- > Name: Karen Rosenthal > E-mail: karenr@premenos.com > Phone: (510)688-2928 > Fax: (510)602-2133 From owner-ietf-ediint Fri Feb 7 13:02:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA02967 for ietf-ediint-bks; Fri, 7 Feb 1997 13:02:21 -0800 (PST) Received: from ns.stercomm.com (ns.stercomm.com [199.3.19.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA02933 for ; Fri, 7 Feb 1997 13:02:15 -0800 (PST) Received: ns.stercomm.com id AA17557; Fri, 7 Feb 1997 15:56:08 -0500 Mime-Version: 1.0 Date: Fri, 7 Feb 1997 15:57:19 -0500 Message-Id: <00021CBE.1733@stercomm.com> From: Dale_Moberg@stercomm.com Subject: Re[2]: Use of multipart/encrypted with S/MIME To: chucks@actracorp.com, drummand@onramp.net, Karen Rosenthal Cc: edipilot@commerce.net, ietf-ediint@imc.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ediint@imc.org Precedence: bulk Hi Karen, Karen R. writes: >Thanks for your quick responses. For clarification: >. Signed only goes out as multipart/signed, >protocol=application/x-pkcs7-signature. >. Encrypted only goes out as application/x-pkcs7-mime, EnvelopedData. That is what I understood from Wed. > Question: Does Signed & Encrypted go out as multipart/signed within >application/x-pkcs7-mime, EnvelopedData, > or as application/x-pkcs7-mime, > SignedData within application/x-pkcs7-mime, EnvelopedData? > The former doesn't make sense. This structure is what I understood Rik to be saying was agreed upon at the December conference. So for an EDIFACT transaction, the transaction would be made into a MIME body part with headers: Content-Type: application/edifact Content-Transfer-Encoding: binary Content-Disposition: attachment; filename="UNA000.edi" The detatched signature (a pkcs # 7 detached signature) would be in the second body part with headers Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: binary Content-Disposition: attachment; filename="UNA000.pk7" The signature would have been computed on the entire first body part, headers included with the transfer-encoding indicated (that is an identity transfer encoding...) These two parts are wrapped up as a multipart/signed, with headers: Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="rsa-md5"; boundary="yourgobbleygookhere" Content-transfer-encoding: binary Content-Disposition: attachment; filename="multi.tmp" Then this whole structure is processed into a pkcs7 enveloped, with headers: Content-type: application/x-pkcs7-mime Content-transfer-encoding: base64 Content-Dispostion: whatever These operations seem clear. I take it that it doesn't make sense to you because the removal of the edi data into a file does not really do much to help make the data readable to a user (not that EDI data is very readable to users anyway). That was the rationale for splitting the signature off from the thing signed in the multipart/signed in the first place. Is that your point? Or is there something technically nonsensical in this? I guess the reason for making the inner signed structure a Mime multipart is for uniformity of pattern in packaging-- so that the PGP and S/MIME structures are handled symmetrically. Possibly others can expand on what the rationale for these procedures are; my remarks are only conjectural and extrapolated. Rik or Chuck? The latter option that you mention is what we were doing initially in the pilot. >If the latter, then I don't understand the issue >discussed Wednesday on edipilot test 8 (during which I obviously >misunderstood that only multipart/signed within multipart/encrypted >would be accepted)? From owner-ietf-ediint Fri Feb 7 13:45:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA05289 for ietf-ediint-bks; Fri, 7 Feb 1997 13:45:19 -0800 (PST) Received: from gatekeeper.premenos.com (mail.premenos.com [150.105.250.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA05285 for ; Fri, 7 Feb 1997 13:45:16 -0800 (PST) Received: from localhost (smap@localhost) by gatekeeper.premenos.com (8.6.5/8.6.5) id NAA04142; Fri, 7 Feb 1997 13:48:04 -0800 Received: from karenr.premenos.com(150.105.100.205) by mail.premenos.com via smap (V1.3mjr) id sma004124; Fri Feb 7 13:47:29 1997 Message-ID: <32FB770D.2F20@premenos.com> Date: Fri, 07 Feb 1997 13:40:13 -0500 From: Karen Rosenthal Reply-To: karenr@premenos.com Organization: Premenos X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: Dale_Moberg@stercomm.com CC: edipilot@commerce.net, ietf-ediint@imc.org Subject: Re: Use of multipart/encrypted with S/MIME References: <00021CBE.1733@stercomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Thanks for the details, Dale. Dale_Moberg@stercomm.com wrote: > That is what I understood from Wed. > > Then this whole structure [multipart/signed] is processed into a pkcs7 enveloped, with headers: > Content-type: application/x-pkcs7-mime > Content-transfer-encoding: base64 > Content-Dispostion: whatever > > These operations seem clear. I take it that it doesn't make sense to you > because the removal of the edi data into a file does not really do much to help > make the data readable to a user (not that EDI data is very readable to users > anyway). > That was the rationale for splitting the signature off from the thing signed > in the multipart/signed in the first place. > Is that your point? Or is there something technically nonsensical in this? > I guess the reason for making the inner signed structure a Mime multipart is for > uniformity of pattern in packaging-- so that the PGP and S/MIME structures are > handled symmetrically. But PGP and S/MIME structure aren't handled symmetrically. The PGP outer envelope is multipart/encryted. My understanding of the benefit of using multipart/signed rather than application/x-pkcs7-mime, SignedData, is so non-S/MIME compliant recipients can still receive, parse, and read the sent data, even if they can't understand the signature. The nonsensical part to me is that if you receive an outer envelope of application/x-pkcs7-mime, EnvelopedData, if you can't parse pkcs7, you won't be able to get at the inner envelope anyways, so why not just use SignedData? > > > The latter option that you mention is what we were doing initially in > the pilot. > It was suggested during the last pilot meeting, that whatever the final requirement is, is what should be done for the pilot. Thanks, -- Name: Karen Rosenthal E-mail: karenr@premenos.com Phone: (510)688-2928 Fax: (510)602-2133 From owner-ietf-ediint Fri Feb 7 15:31:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA07215 for ietf-ediint-bks; Fri, 7 Feb 1997 15:31:17 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA07209 for ; Fri, 7 Feb 1997 15:31:14 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA26806; Fri, 7 Feb 1997 15:31:02 -0800 Message-ID: <32FBBA1D.7E8F@actracorp.com> Date: Fri, 07 Feb 1997 15:26:21 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: karenr@premenos.com CC: Dale_Moberg@stercomm.com, edipilot@commerce.net, ietf-ediint@imc.org Subject: Re: Use of multipart/encrypted with S/MIME References: <00021CBE.1733@stercomm.com> <32FB770D.2F20@premenos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Karen and Dale, The rationale for multipart/signed versus PKCS signed data is that the multipart/signed format is supported by both Internet as well as S/MIME standards. The signed data is only a S/MIME standard. Changes to multipart/signed can be better discussed and controlled by the Internet community. Changes to signed data are controlled primarily by RSA. It was felt that when given a choice such as we have above, that Internet standards should use other Internet standards when possible. Karen Rosenthal wrote: > > +----------------------------------------------------------------------+ > This message was addressed to: edipilot@lists.commerce.net > +----------------------------------------------------------------------+ > > Thanks for the details, Dale. > > Dale_Moberg@stercomm.com wrote: > > > That is what I understood from Wed. > > > > Then this whole structure [multipart/signed] is processed into a pkcs7 enveloped, with headers: > > Content-type: application/x-pkcs7-mime > > Content-transfer-encoding: base64 > > Content-Dispostion: whatever > > > > These operations seem clear. I take it that it doesn't make sense to you > > because the removal of the edi data into a file does not really do much to help > > make the data readable to a user (not that EDI data is very readable to users > > anyway). > > That was the rationale for splitting the signature off from the thing signed > > in the multipart/signed in the first place. > > Is that your point? Or is there something technically nonsensical in this? > > I guess the reason for making the inner signed structure a Mime multipart is for > > uniformity of pattern in packaging-- so that the PGP and S/MIME structures are > > handled symmetrically. > > But PGP and S/MIME structure aren't handled symmetrically. The PGP > outer envelope is multipart/encryted. > > My understanding of the benefit of using multipart/signed rather than > application/x-pkcs7-mime, SignedData, is so non-S/MIME compliant > recipients can still receive, parse, and read the sent data, even if > they can't understand the signature. The nonsensical part to me is that > if you receive an outer envelope of application/x-pkcs7-mime, > EnvelopedData, if you can't parse pkcs7, you won't be able to get at the > inner envelope anyways, so why not just use SignedData? > > > > > > > The latter option that you mention is what we were doing initially in > > the pilot. > > > > It was suggested during the last pilot meeting, that whatever the final > requirement is, is what should be done for the pilot. > > Thanks, > -- > Name: Karen Rosenthal > E-mail: karenr@premenos.com > Phone: (510)688-2928 > Fax: (510)602-2133 > ------------------------------------------------------------------------- > This message was sent by a majordomo-based automatic list manager. > Subscriptions to and archives of this list are available to CommerceNet > members, partners, and invited guests. For further information send a > mail message to 'edipilot-request@lists.commerce.net' with 'help' > (no quotations) contained in the body of your message. From owner-ietf-ediint Sat Feb 8 06:55:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA16254 for ietf-ediint-bks; Sat, 8 Feb 1997 06:55:39 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA16250 for ; Sat, 8 Feb 1997 06:55:36 -0800 (PST) Received: from drummond.onramp.net (ppp1-13.ftwotx.onramp.net [199.184.212.176]) by mailhost.onramp.net (8.8.5/8.6.5) with SMTP id IAA08954; Sat, 8 Feb 1997 08:56:58 -0600 (CST) Message-ID: <32FC942D.2303@onramp.net> Date: Sat, 08 Feb 1997 08:56:45 -0600 From: Rik Drummond Reply-To: drummond@onramp.net Organization: Drummond Group X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: chucks@actracorp.com CC: karenr@premenos.com, Dale_Moberg@stercomm.com, edipilot@commerce.net, ietf-ediint@imc.org Subject: Re: Use of multipart/encrypted with S/MIME References: <00021CBE.1733@stercomm.com> <32FB770D.2F20@premenos.com> <32FBBA1D.7E8F@actracorp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Part of the proplem in this areas is that we don't have the final drafts out yet....chuck is working on it. chuck it will be out in the next few days... Do you have a date yet? Rik From owner-ietf-ediint Sat Feb 8 06:53:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA16234 for ietf-ediint-bks; Sat, 8 Feb 1997 06:53:55 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA16230 for ; Sat, 8 Feb 1997 06:53:52 -0800 (PST) Received: from drummond.onramp.net (ppp1-13.ftwotx.onramp.net [199.184.212.176]) by mailhost.onramp.net (8.8.5/8.6.5) with SMTP id IAA08728; Sat, 8 Feb 1997 08:55:11 -0600 (CST) Message-ID: <32FC93C3.4972@onramp.net> Date: Sat, 08 Feb 1997 08:54:59 -0600 From: Rik Drummond Reply-To: drummond@onramp.net Organization: Drummond Group X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: chucks@actracorp.com CC: karenr@premenos.com, Dale_Moberg@stercomm.com, edipilot@commerce.net, ietf-ediint@imc.org Subject: Re: Use of multipart/encrypted with S/MIME References: <00021CBE.1733@stercomm.com> <32FB770D.2F20@premenos.com> <32FBBA1D.7E8F@actracorp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk We were told by the Internet experts... that the s/mime signed does not fit "the internet philosophy" we had to do it multipart signed. We have said this for the last two months many times.... If we wish to get an RFC we must do multipart/signed..... so discussion on this fuitless.... we are doing multipart/signed...unless you all don't wish to have an internet draft. later....rik Chuck Shih wrote: > > +----------------------------------------------------------------------+ > This message was addressed to: edipilot@lists.commerce.net > +----------------------------------------------------------------------+ > > Karen and Dale, > > The rationale for multipart/signed versus PKCS signed data is that the > multipart/signed format is supported by both Internet as well as S/MIME > standards. The signed data is only a S/MIME standard. > > Changes to multipart/signed can be better discussed and controlled by > the Internet community. Changes to signed data are controlled primarily > by RSA. It was felt that when given a choice such as we have above, that > Internet standards should use other Internet standards when possible. > > Karen Rosenthal wrote: > > > > +----------------------------------------------------------------------+ > > This message was addressed to: edipilot@lists.commerce.net > > +----------------------------------------------------------------------+ > > > > Thanks for the details, Dale. > > > > Dale_Moberg@stercomm.com wrote: > > > > > That is what I understood from Wed. > > > > > > Then this whole structure [multipart/signed] is processed into a pkcs7 enveloped, with headers: > > > Content-type: application/x-pkcs7-mime > > > Content-transfer-encoding: base64 > > > Content-Dispostion: whatever > > > > > > These operations seem clear. I take it that it doesn't make sense to you > > > because the removal of the edi data into a file does not really do much to help > > > make the data readable to a user (not that EDI data is very readable to users > > > anyway). > > > That was the rationale for splitting the signature off from the thing signed > > > in the multipart/signed in the first place. > > > Is that your point? Or is there something technically nonsensical in this? > > > I guess the reason for making the inner signed structure a Mime multipart is for > > > uniformity of pattern in packaging-- so that the PGP and S/MIME structures are > > > handled symmetrically. > > > > But PGP and S/MIME structure aren't handled symmetrically. The PGP > > outer envelope is multipart/encryted. > > > > My understanding of the benefit of using multipart/signed rather than > > application/x-pkcs7-mime, SignedData, is so non-S/MIME compliant > > recipients can still receive, parse, and read the sent data, even if > > they can't understand the signature. The nonsensical part to me is that > > if you receive an outer envelope of application/x-pkcs7-mime, > > EnvelopedData, if you can't parse pkcs7, you won't be able to get at the > > inner envelope anyways, so why not just use SignedData? > > > > > > > > > > > The latter option that you mention is what we were doing initially in > > > the pilot. > > > > > > > It was suggested during the last pilot meeting, that whatever the final > > requirement is, is what should be done for the pilot. > > > > Thanks, > > -- > > Name: Karen Rosenthal > > E-mail: karenr@premenos.com > > Phone: (510)688-2928 > > Fax: (510)602-2133 > > ------------------------------------------------------------------------- > > This message was sent by a majordomo-based automatic list manager. > > Subscriptions to and archives of this list are available to CommerceNet > > members, partners, and invited guests. For further information send a > > mail message to 'edipilot-request@lists.commerce.net' with 'help' > > (no quotations) contained in the body of your message. > ------------------------------------------------------------------------- > This message was sent by a majordomo-based automatic list manager. > Subscriptions to and archives of this list are available to CommerceNet > members, partners, and invited guests. For further information send a > mail message to 'edipilot-request@lists.commerce.net' with 'help' > (no quotations) contained in the body of your message. From owner-ietf-ediint Mon Feb 10 02:06:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id CAA01841 for ietf-ediint-bks; Mon, 10 Feb 1997 02:06:04 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id CAA01837 for ; Mon, 10 Feb 1997 02:05:57 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA15626 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Mon, 10 Feb 1997 02:07:29 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA10871; Sun, 9 Feb 97 14:13:26 PST Date: Sun, 9 Feb 97 14:13:26 PST From: carl@chage.com (Carl Hage) Message-Id: <9702092213.AA10871@slick.chage.com> To: ietf-ediint@imc.org Subject: Re: Use of multipart/encrypted with S/MIME References: <00021CBE.1733@stercomm.com> <32FB770D.2F20@premenos.com> Organization: C. Hage Associates, Sunnyvale, CA Sender: owner-ietf-ediint@imc.org Precedence: bulk Karen Rosenthal (karenr@premenos.com) wrote: : My understanding of the benefit of using multipart/signed rather than : application/x-pkcs7-mime, SignedData, is so non-S/MIME compliant : recipients can still receive, parse, and read the sent data, even if : they can't understand the signature. The nonsensical part to me is that : if you receive an outer envelope of application/x-pkcs7-mime, : EnvelopedData, if you can't parse pkcs7, you won't be able to get at the : inner envelope anyways, so why not just use SignedData? Instead of 'receive, parse, and read the sent data' it is so recipients, or more specifically software packages used by recipients, can 'parse, and read the sent (signed) data'. The whole process of sending/receiving and processing of data should not be a bundled package. You could apply the same logic to SignedAndEnvelopedData (signed and encrypted bundle), i.e. why not merge encryption and signing into one? There are a few issues on reasons. The messaging process should be highly modular and layered, so different software subsystems can work together and information can be processed in many ways other than some original model. The layered signature/encryption permits the encryption/decryption (for privacy) to be separated or made optional from the other parts of the process. The incoming MTA might (should) decrypt and log the message with signature attached. The same protocols are useful for messages not encrypted. The decrypted message can then be processed by many software packages, e.g. an MDN tracking subsystem, which may be something other than the "Premenos Internet EDI system" for example. What is "Not the Internet way" is the concept that attaching a signature to a piece of data causes the data to be garbled within a binary data structure. This binds specialized software decoding to the ability to maintain signatures associated with exchanged data. In other words, one should be able to pass around signed data and have it processed by many different applications which don't authenticate, but without losing the ability to authenticate that data at some point. There is also an issue of placing the burden on the creator or the user of data. Since we expect many readers/users/uses of data, the burden should be placed on the writer to encode in a maximally usable form. If stripping the data is considered "hard", e.g. all the gripes about such a mandate, then this is all the more reason why the multipart/signed is important. The burden should be placed on the 1 signer/encryptor software package creating data rather than all other packages that might want to use it. Creating a standard where only the 1 package may use signed data is not "the Internet way". If the recipient has to strip the signed data from the PKCS binary data, why can't the sender do this? The answer, "because the RSA toolkit doesn't have that subroutine", is not good. An Internet RFC shouldn't be corrupted because of defects in a particular version of a proprietary software product. Anyway, that's why I agree with the IETF honchos. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Mon Feb 10 17:40:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA20419 for ietf-ediint-bks; Mon, 10 Feb 1997 17:40:13 -0800 (PST) Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA20414 for ; Mon, 10 Feb 1997 17:40:10 -0800 (PST) Received: from agathon.vip.best.com (agathon.vip.best.com [205.149.165.153]) by proxy3.ba.best.com (8.8.5/8.8.3) with SMTP id RAA11968; Mon, 10 Feb 1997 17:34:30 -0800 (PST) Date: Mon, 10 Feb 1997 17:34:30 -0800 (PST) Message-Id: <199702110134.RAA11968@proxy3.ba.best.com> X-Sender: mjansson@best.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: edipilot@commerce.net, ietf-ediint@imc.org From: Mats Jansson Subject: Structures for MIME EDI Sender: owner-ietf-ediint@imc.org Precedence: bulk Since there has been so much discussion regarding this, I thought it might be helpful to send out the "high level" applicability the way it is stated in the version of AS#1 that has not yet been published. Keep in mind that this has not been reviewed yet, so if anything does not make sense based on your experiences, please let me or Chuck know. The below does not in- clude MDN/receipts. Mats J. 4.2 Structure of an EDI MIME message - PGP/MIME 4.2.1 No encryption, no signature -RFC822/1521 -RFC1767 (Application/EDIxxxx) 4.2.2 No encryption, signature -RFC822/1521 -RFC1847 (Multipart/signed) -RFC2015 (application/pgp-signature) -RFC1767 (Application/EDIxxxx) -PGP/MIME Signature 4.2.3 Encryption, no signature -RFC822/1521 -RFC1847 (Multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version 1" -RFC1767 (Application/EDIxxxx) (encrypted) 4.2.4 Encryption, signature -RFC822/1521 -RFC1847 (Multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version 1" -RFC1847 (Multipart/signed) (encrypted) -RFC2015 (application/pgp-signed) (encrypted) -RFC1767 (application/EDIxxxx) (encrypted) -PGP/MIME Signature (encrypted) 4.3 Structure of an EDI MIME message - S/MIME 4.3.1 No encryption, no signature -RFC822/1521 -RFC1767 (Application/EDIxxxx) 4.3.2 No encryption, signature -RFC822/1521 -RFC1847 (Multipart/signed) -Draft (dusse) (application/x-pkcs7-mime) -RFC1767 (Application/EDIxxxx) -S/MIME Signature 4.3.3 Encryption, no signature -RFC822/1521 -Draft (dusse) (application/x-pkcs7-mime) -RFC1767 (Application/EDIxxxx) (encrypted) 4.3.4 Encryption, signature -RFC822/1521 -Draft (dusse) (application/x-pkcs7-mime) -RFC1847 (Multipart/signed) (encrypted -Draft (dusse) (application/x-pkcs7-mime) (encrypted) -RFC1767 (application/EDIxxxx) (encrypted) -S/MIME Signature (encrypted) _____________________________________________________________ Mats Jansson, LiNK mjansson@agathon.com 2317 Broadway, Suite 330 Redwood City, CA 94063 v: +1-415-780-9039 http://www.agathon.com f: +1-415-780-9069 From owner-ietf-ediint Tue Feb 11 12:38:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA09108 for ietf-ediint-bks; Tue, 11 Feb 1997 12:38:31 -0800 (PST) Received: from cbgw2.lucent.com (cbgw2.lucent.com [192.20.239.134]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA09104 for ; Tue, 11 Feb 1997 12:38:25 -0800 (PST) To: "'ietf-ediint@imc.org'" Received: from nj0319exch001p.wins.lucent.com by cbig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id PAA27420; Tue, 11 Feb 1997 15:38:42 -0500 Received: by nj0319exch001p.wins.lucent.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC1831.D6C26720@nj0319exch001p.wins.lucent.com>; Tue, 11 Feb 1997 15:39:59 -0500 Message-ID: From: "Woodman, Wesley (Wes)" Original-To: "'ietf-ediint@imc.org'" <'ietf-ediint@imc.org'> Subject: EDI via Internet Date: Tue, 11 Feb 1997 15:39:57 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Recently I read the Network Computing article in Dec. 1, 96 issue on EDI Over the Internet. In this article there were not any references to any of the vendors. Can you either supply a list of vendors and/or web sites that have information on EDI Over Internect or Electronic Commerce. We are currently planning an implementation of Electronic Commerce on outbound invoices and inbound remittance advices over the Internet. We are currently gathering information on both Sterling Commerce and Harbinger Express vendors. Are there any other quality vendors that we should be soliciting information? Is the BBN product a potential fit? I noticed it conforms to the MSP Encryption Scheme. Thanks for any help in this area. Wes Woodman wwoodman@lucent.com From owner-ietf-ediint Tue Feb 11 13:53:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA10252 for ietf-ediint-bks; Tue, 11 Feb 1997 13:53:50 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA10248 for ; Tue, 11 Feb 1997 13:53:46 -0800 (PST) Received: from drummond.onramp.net (ppp1-36.ftwotx.onramp.net [199.184.212.199]) by mailhost.onramp.net (8.8.5/8.6.5) with SMTP id PAA02503; Tue, 11 Feb 1997 15:55:16 -0600 (CST) Message-ID: <3300EAB6.148B@onramp.net> Date: Tue, 11 Feb 1997 15:55:02 -0600 From: Rik Drummond Reply-To: drummond@onramp.net Organization: Drummond Group X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: "Woodman, Wesley (Wes)" CC: ietf-ediint@imc.org Subject: Re: EDI via Internet References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Please see below for company names that are testing the proposed standards..if you need more info, please let me know...later...rik harbinger, premenos, att, actra, eds, dec, sterling commerce, dod, dannet (finland), atlas product (england) and cyberpath Woodman, Wesley (Wes) wrote: > > Recently I read the Network Computing article in Dec. 1, 96 issue on EDI > Over the Internet. In this article there were not any references to any > of the vendors. > Can you either supply a list of vendors and/or web sites that have > information on EDI Over Internect or Electronic Commerce. We are > currently planning an implementation of Electronic Commerce on outbound > invoices and inbound remittance advices over the Internet. > > We are currently gathering information on both Sterling Commerce and > Harbinger Express vendors. Are there any other quality vendors that we > should be soliciting information? Is the BBN product a potential fit? > I noticed it conforms to the MSP Encryption Scheme. > > Thanks for any help in this area. > > Wes Woodman > wwoodman@lucent.com From owner-ietf-ediint Tue Feb 11 15:05:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA11199 for ietf-ediint-bks; Tue, 11 Feb 1997 15:05:05 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA11194 for ; Tue, 11 Feb 1997 15:05:01 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA26195 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Tue, 11 Feb 1997 15:02:42 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA00442; Tue, 11 Feb 97 12:13:21 PST Date: Tue, 11 Feb 97 12:13:21 PST From: carl@chage.com (Carl Hage) Message-Id: <9702112013.AA00442@slick.chage.com> To: ietf-ediint@imc.org Subject: Re: Structures for MIME EDI References: <199702110134.RAA11968@proxy3.ba.best.com> Organization: C. Hage Associates, Sunnyvale, CA Sender: owner-ietf-ediint@imc.org Precedence: bulk Mats Jansson (mjansson@agathon.com) wrote: : Since there has been so much discussion regarding this, I thought it might : be helpful to send out the "high level" applicability the way it is stated : in the version of AS#1 that has not yet been published. Keep in mind that : this has not been reviewed yet, so if anything does not make sense based : on your experiences, please let me or Chuck know. The below does not in- : clude MDN/receipts. Looks good, with the correct, in my opinion, protocols. The MDN is identical, except the RFC1767 application/edixxxx is replaced with the MDN RFC/draft, which is a multipart instead of application MIME type. I don't think you need to duplicate the examples for MDN. The secured message structure applies to other MIME types besides application/edixxxx, which includes MDNs or any other MIME type, by substituting any MIME labelled content for the EDI data. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Tue Feb 11 17:46:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA12881 for ietf-ediint-bks; Tue, 11 Feb 1997 17:46:11 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA12877 for ; Tue, 11 Feb 1997 17:46:08 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA25410; Tue, 11 Feb 1997 17:45:44 -0800 Message-ID: <33011FAD.6E82@actracorp.com> Date: Tue, 11 Feb 1997 17:41:01 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: edipilot@commerce.net, ietf-ediint@imc.org Subject: Revision of Signed Receipts Content-Type: multipart/mixed; boundary="------------26AD2E58208" Sender: owner-ietf-ediint@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------26AD2E58208 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached is the latest revision for requesting and processing signed receipts. This revision takes into account the new disposition options supported by the latest MDN draft. I have also tried to make the MDN processing as simple as possible, and have elected to have only one parameter that explicitly requests a signed receipt and the format the signed receipt should be returned in. At some point, additional parameters can be added requesting a specific MIC or signature algorithm be used with the signed receipt. At present, these algorithms can be agreed to in the trading relationship. Please review the section on signed receipts, so I can incorporate any comments into the final revision of the AS#1. Thanks. --------------26AD2E58208 Content-Type: text/plain; charset=us-ascii; name="as10211.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="as10211.txt" INTERNET DRAFT Mats Jansson, LiNK draft-ietf-ediint-as1-03.txt Chuck Shih, Actra Nancy Turaj, Mitre Corp. Rik Drummond, Drummond Group 10 January, 1997 MIME-based Secure EDI 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 document describes how to securely exchange EDI documents using MIME and public key cryptography. Feedback Instructions: If you want to provide feedback on this draft, follow these guidelines: -Send feedback via e-mail to mjansson@agathon.com, with "AS#1" in the Subject field. -Be specific as to what section you are referring to, preferably quoting the portion that needs modification, after which you state your comments. -If you are recommending some text to be replaced with your suggested text, again, quote the section to be replaced, and be clear on the section in question. -If you are questioning fundamental methods, bring the issue to the ediint list for discussion. To enter/follow the discussion, you need to subscribe at ietf-ediint@imc.org. Table of Contents 1. Introduction 2. Overview 2.1 Purpose of a security guideline for MIME EDI 2.2 Definitions 2.2.1 Terms 2.2.2 The secure transmission loop 2.2.3 Definition of receipts 2.3 Assumptions 2.3.1 EDI process assumptions 2.3.2 Flexibility assumptions 3. Referenced RFCs and their contribution 3.1 RFC 821 SMTP [7] 3.2 RFC 822 Text Message Format [3] 3.3 RFC 1521 MIME [1] 3.4 RFC 1847 MIME Security Multiparts [6] 3.5 RFC 1892 Multipart/report [9] 3.6 RFC 1767 EDI Content [2] 3.7 RFC 2015 PGP/MIME [4] 3.8 Internet draft (fajman): Message Disposition Notification [5] 3.9 Internet draft (dusse): - S/MIME Specification [8] 4. Structure of an EDI MIME message - Applicability 4.1 Introduction 4.2 Structure of an EDI MIME message - PGP/MIME 4.2.1 No encryption, no signature 4.2.2 No encryption, signature 4.2.3 Encryption, no signature 4.2.4 Encryption, signature 4.3 Structure of an EDI MIME message - S/MIME 4.3.1 No encryption, no signature 4.3.2 No encryption, signature 4.3.3 Encryption, no signature 4.3.4 Encryption, signature 5. Receipts 5.1 Introduction 5.2 Requesting a signed receipt 5.3 Message Disposition Notification Format 5.4 Message Disposition Notification Processing 5.4.1 Large File Processing 5.4.2 Example 6. Public key certificate handling 6.1 Near term approach 6.2 Long term approach 7. Authors' Addresses 8. References 1. Introduction The authors would like to extend special thanks to Carl Hage for providing the team with valuable, and very thorough feedback. Without participants like Carl, these efforts become hard to complete in a way useful to the users of the technology. Previous work on Internet EDI focused on specifying MIME content types for EDI data ([2] RFC 1767). This Applicability Statement expands on RFC 1767 to specify use of a comprehensive set of data security features, specifically data privacy, data integrity/authenticity, non-repudiation of origin and non- repudiation of receipt. This draft recognizes contemporary RFCs and Internet drafts and is attempting to "re-invent" as little as possible. With an enhancements in the area of "receipts", as described below (3.1.8), secure Internet MIME based EDI can be accomplished by using and complying with the following RFCs and drafts: -RFC 821 SMTP -RFC 822 Text Message Formats -RFC 1521 MIME -RFC 1767 EDI Content Type -RFC 1847 Security Multiparts for MIME -RFC 1892 Multipart/Report -Internet draft: Message Disposition Notification (fajman) -RFC 2015 MIME/PGP (elkins) -Internet draft: S/MIME Specification (dusse) Our intent here is to define clearly and precisely how these are pieced together and what is required by user agents to be compliant with this Applicability Statement. 2. Overview 2.1 Purpose of a security guideline for MIME EDI The purpose of these specifications is to ensure interoperability between EDI user agents, invoking some or all of the commonly expected security features. This standard is also NOT limited to strict EDI use, but applies to any electronic commerce application where business data needs to be exchanged over the Internet in a secure manner. 2.2 Definitions 2.2.1. Terms EDI Electronic Data Interchange EC Electronic Commerce Receipt The functional message that is sent from a receiver to a sender to acknowledge receipt of an EDI/EC interchange Signed Receipt Same as above, but with a digital signature Message Disposition The way by which a receipt or a signed Notification (MDN) receipt is accomplished within Internet Messaging. Non-repudiation of NRR is a "legal event" that occurs when the Receipt (NRR) original sender of an EDI/EC interchange has verified the signed receipt coming back from the receiver. NRR IS NOT a functional or a technical message. PGP/MIME Digital envelope security based on the Pretty Good Privacy (PGP) standard (Zimmerman), integrated with MIME Security Multiparts [6]. S/MIME A protocol for adding cryptographic signature and/or encryption services to Internet MIME messages. 2.2.2 The secure transmission loop The functional requirements document, [9] "Requirements for Inter- operable Internet EDI" (can be found at www.ietf.org),provides extensive information on EDI security and the user/business related processes surrounding the need for and use of EDI security. In this document, it is assumed that the reader is familiar with the requirements document. This document's focus is on the formats and protocols for exchanging EDI content that has had security applied to it using the Internet's messaging transport. The "secure transmission loop" for EDI involves one organization sending a signed and encrypted EDI interchange to another organization, requesting a "signed receipt", followed later by the receiving organization sending this "signed receipt" back to the sending organization. In other words, the following transpires: -The organization sending EDI/EC data encrypts the data and provides a digital signature, using either PGP/MIME or S/MIME. In addition, they request a "signed receipt". -The receiving organization decrypts the message and verifies the signature, resulting in verified integrity of the data and authenticity of the sender. -The receiving organization then sends a "signed receipt" in the form of a signature over the hash from the previous step. The above describes functionality which if implemented, would satisfy all security requirements. This specification, however, leaves full flexibility for users to decide the degree to which they want to deploy those features with their EDI trading partners. 2.2.3 Definition of receipts The term used for both the functional activity and message for acknowledging receipt of an EDI/EC interchange is "receipt", or "signed receipt". The first term is used if the acknowledgment is for an interchange resulting in a receipt which is NOT signed. The second term is used if the acknowledgment is for an interchange resulting in a receipt which IS signed. The rule is: If a receipt is requested, explicitly specifying that the receipt should be signed, then the receipt indeed has to be returned with a signature. If signature is not explicitly requested, all bets are off. This is consistent with Fajman's MDN draft. A term often used in combination with receipts is "Non-repudiation of Receipt (NRR). NRR refers to a legal event which occurs only when the original sender of an interchange has verified the sender and content of a "signed receipt". Note that NRR is not possible without signatures. 2.3 Assumptions 2.3.1 EDI process assumptions -Encrypted object is an EDI Interchange This specification assumes that a typical EDI interchange is the lowest level object that will be subject to security features. In ANSI X12, this means anything between, and including segments ISA and IEA. In EDIFACT, this means anything between, and including, segments UNA/UNB and UNZ. In other words, the EDI interchanges including envelope segments remain intact and unreadable during secure transport. -EDI envelope headers are encrypted Congruent with the above statement, EDI envelope headers are NOT visible in the MIME package. In order to optimize VAN-to- Internet routing, work may need to be done in the future to define ways to pull out some of the envelope information to make them visible, however, this specification does not go into any detail on that. -X12.58 and UN/EDIFACT security considerations The most common EDI standards, ANSI X12 and EDIFACT, have defined internal provisions for security. X12.58 is the security mechanism for ANSI X12 and AUTACK provides security for EDIFACT. This specification DOES NOT dictate use or non-use of these security standards. They are both fully compatible, though possibly redundant, with this specification. 2.3.2 Flexibility assumptions -Encrypted or un-encrypted data This specification allows for EDI message exchange where the EDI data is either un-protected or protected by means of encryption. -Signed or un-signed data This specification allows for EDI message exchange with or without digital signature of the original EDI transmission. -Use of receipt or not This specification allows for EDI message transmission with or without a request for receipt notification. If a signed receipt notification is requested, however, a signature is required as part the returned receipt. -Formatting choices This specification defines use of two methods for formatting EDI contents that have security applied to it: -PGP/MIME -S/MIME This specification relies on the guidelines set forth in the RFC 2015, as reflected in [4] MIME Security with Pretty Good Privacy (PGP), and Internet draft [8] S/MIME Specification from RSA Security, Inc. (dusse) Compliance with this specification dictates that AT LEAST one of these methods is supported. -Hash function, message digest choices When signature is used, unless specified otherwise by the chosen method (PGP/MIME or S/MIME), the SHA1 checksum hash function is recommended. In summary, the following eight permutations are possible, in any given trading relationship: (1) Sender sends un-encrypted data, does NOT request a receipt. (2) Sender sends unencrypted data, requests a receipt. Receiver sends back a receipt. (3) Sender sends encrypted data, does NOT request a receipt. (4) Sender sends encrypted data, requests a receipt. Receiver sends back a receipt. (5) Sender sends signed data, does NOT request a signed receipt. (6) Sender sends signed data, requests a signed receipt. Receiver sends back a signed receipt. (7) Sender sends encrypted and signed data, does NOT request a signed receipt. (8) Sender sends encrypted and signed data, requests a signed receipt. Receiver sends back a signed receipt. NOTE: Users can choose any of the eight possibilities, but only example (8) offers the whole suite of security features described in the "Secure transmission loop" above. NOTE: A request for receipt that is signed, MUST result in a signed receipt. A request for receipt without signature MUST result in an un-signed receipt. 3. Referenced RFCs and their contribution 3.1 RFC 821 SMTP [7] This is the core mail transfer standard that all MTAs need to adhere to. 3.2 RFC 822 Text Message Format [3] Defines message header fields and the parts making up a message. 3.3 RFC 1521 MIME [1] This is the basic MIME standard, upon which all MIME related RFCs build, including this one. Key contributions include definition of "content type" and sub-type "multipart", in addition to encoding guidelines, which establish 7-bit US-ASCII as the lowest common denominator used. 3.4 RFC 1847 MIME Security Multiparts [6] This document defines security multiparts for MIME: multipart/encrypted and multipart/signed. 3.5 RFC 1892 Multipart/report [10] This RFC defines the use of Multipart/report content type, something that the MDN draft (fajman) relies on for the receipt functionality. 3.6 RFC 1767 EDI Content [2] This RFC defines the use of content type "application" for ANSI X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and mutually defined EDI (application/EDI-Consent). 3.7 RFC 2015 PGP/MIME [4] This RFC defines the use of content types "multipart/encrypted", "multipart/signed", "application/pgp encrypted" and "application/pgp-signature" for defining MIME PGP content. 3.8 Internet draft (fajman): Message Disposition Notification [5] This Internet draft defines how a message disposition notification (MDN) is requested, and the structure of the MDN. NOTE: This is the only specification we were not able to take "as is". Extension field-names beginning with "X-" will not be defined as a standard field. MDN field names not beginning with "X- " need to be registered with the Internet Assigned Numbers Authority (IANA) and described in an RFC. The X-Received-MIC field described in this document will be registered with IANA. 3.9 Internet draft (dusse): S/MIME Message Specification [8] This specification describes how MIME shall carry PKCS7 signature and envelope information. 4. Structure of an EDI MIME message - Applicability 4.1 Introduction The below structures are described hierarchically in terms of which RFC's are applied to form the specific structure. For details of how to code in compliance with all RFC's involved, turn directly to the RFC's referenced. The "requirements document" has several examples described in an Appendix for those interested. Also, these structures describe the initial transmission only. Receipts, and requests for receipts are handled in section 5. 4.2 Structure of an EDI MIME message - PGP/MIME 4.2.1 No encryption, no signature -RFC822/1521 -RFC1767 (Application/EDIxxxx) 4.2.2 No encryption, signature -RFC822/1521 -RFC1847 (Multipart/signed) -RFC2015 (application/pgp-signature) -RFC1767 (Application/EDIxxxx) -PGP/MIME Signature 4.2.3 Encryption, no signature -RFC822/1521 -RFC1847 (Multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version 1" -RFC1767 (Application/EDIxxxx) (encrypted) 4.2.4 Encryption, signature -RFC822/1521 -RFC1847 (Multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version 1" -RFC1847 (Multipart/signed) (encrypted -RFC2015 (application/pgp-signed) (encrypted) -RFC1767 (application/EDIxxxx) (encrypted) -PGP/MIME Signature (encrypted) 4.3 Structure of an EDI MIME message - S/MIME 4.3.1 No encryption, no signature -RFC822/1521 -FC1767 (Application/EDIxxxx) 4.3.2 No encryption, signature -RFC822/1521 -RFC1847 (Multipart/signed) -Draft (dusse) (application/x-pkcs7-mime) -RFC1767 (Application/EDIxxxx) -S/MIME Signature 4.3.3 Encryption, no signature -RFC822/1521 -Draft (dusse) (application/x-pkcs7-mime) -RFC1767 (Application/EDIxxxx) (encrypted) 4.3.4 Encryption, signature -RFC822/1521 -Draft (dusse) (application/x-pkcs7-mime) -RFC1847 (Multipart/signed) (encrypted -Draft (dusse) (application/x-pkcs7-mime) (encrypted) -RFC1767 (application/EDIxxxx) (encrypted) -S/MIME Signature (encrypted) 5. Receipts 5.1 Introduction In order to provide a non-repudiation of receipt (NRR) or signed receipt, a message disposition notification (MDN) as specified by draft- ietf-receipt-mdn-02.txt is to be implemented by a receiving trading partner's UA (User Agent). The message disposition notification is then digitally signed and returned to the sending trading partner as part of a multipart/signed content. The required support for signed receipts when doing EDI Internet is as follows: 1). Create a multipart/report; report-type= disposition-notification. 2). Calculate the MIC on the message disposition notification. 3). Digitally sign the MIC. 4). Create a multipart/signed content with the message disposition notification as the first body part, and the signed MIC calculated on the message disposition notification as the second body part. 5). Return the signed receipt to the sending trading partner. The MDN is used to notify a sending trading partner that sent a signed, or signed and encrypted EDI Interchange that: 1). The receiving trading partner acknowledges receipt of the sent EDI Interchange. 2). The receiving trading partner has authenticated the sender of the EDI Interchange. 3). The receiving trading partner has verified the integrity of the received EDI Interchange. Regardless of whether the EDI Interchange was sent in S/MIME or PGP/MIME format, the receiving trading partner's UA must provide the following basic processing: 1). If the sent EDI Interchange is encrypted, then the encrypted symmetric key and initialization vector (if applicable) is decrypted using the receiver's private key. 2). The decrypted symmetric encryption key is then used to decrypt the EDI Interchange. 3). The receiving trading partner authenticates signatures in a message using the sender's public key. The authentication algorithm performs the following: a). The message integrity check (MIC or Message Digest) contained within the signature is decrypted using the sender's public key. b). A MIC on the signed contents (the MIME header and encoded EDI object, as per RFC1767) in the message received is calculated using the same one-way hash function that the sending trading partner used. c). The MIC extracted from the signature is compared with the MIC calculated using the same one-way hash function that the sending trading partner used. 4). The receiving trading partner formats the MDN and sets the calculated MIC into the MDN extension field. 5). The receiving trading partner creates a multipart/signed MIME message according to RFC 1847. 6). The MDN is the first part of the multipart/signed message, and the digital signature is created over this MDN, including its MIME headers. 7). The second part of the multipart/signed message contains the digital signature. The "protocol" option specified in the multipart/signed is as follows: S/MIME: protocol = "application/pkcs-7-signature" PGP/MIME: protocol = "application/pgp-signature" The EDI Interchange and the RFC 1767 MIME EDI content header, can actually be part of a multi-part MIME content-type. When the EDI Interchange is part of a multi-part MIME content-type, the MIC is calculated across the entire multi-part content, including the MIME headers. The multi-part MIME content that contains the EDI Interchange is then enveloped in either PKCS#7 or PGP format. The signed MDN, when received by the sender of the EDI Interchange can then be used by the sender: 1). As an acknowledgment that the EDI Interchange sent, was delivered and acknowledged by the receiving trading partner. The receiver does this by returning the original message id of the sent message in the signed MDN. 2). As an acknowledgment that the integrity of the EDI Interchange was verified by the receiving trading partner. The receiver does this by returning the calculated MIC of the received EDI Interchange (and 1767 MIME headers) in the X-Received-MIC field of the signed MDN. 3). As an acknowledgment that the receiving trading partner has authenticated the sender of the EDI Interchange. 4). As a non-repudiation of receipt when the signed MIC calculated over the MDN, is successfully decrypted by the sender with the receiver's public key. 5.2 Requesting a signed receipt Message Disposition Notifications are requested as per draft-ietf- receipt-mdn-02.txt, "An Extensible Message Format for Message Disposition Notification". A request that the receiving user agent issue a message disposition notification is made by placing the following header into the message to be sent: mdn-request-header = "Disposition-notification-to" ":" mail-address The mail-address field is specified as an RFC 822 user@domain address, and is the return address for the message disposition notification. In addition to requesting a message disposition notification, a message disposition notification that is digitally signed, or what has been referred to as a signed-receipt, can be requested by placing the following in the message header following the "Disposition-notification-to" line: Disposition-notification-options = "Disposition-notification-options" ":" dispostion-notification-parameters Where disposition-notification-parameters = signed-receipt-protocol=O, ; The currently supported values for are "x-pkcs7-signature", for the S/MIME detached signature format, or "pgp-signature", for the pgp signature format. An example of a formatted options line would be as follows: Disposition-notification-options: signed-receipt-protocol=O, x-pkcs7-signature; The semantics of the "signed-receipt-protocol" parameter is as follows: 1). The "signed-receipt-protocol" parameter is used to request a signed receipt from the recipient trading partner. The "signed-receipt-protocol" parameter also specifies the format in which the signed receipt should be returned to the requestor. The MIC algorithm and signature algorithm used in formulating the signed receipt are agreed to in the trading partner relationship. The actual algorithms used in the signed receipt are always returned as part of the signed receipt. 2). The "importance" attribute of "O" is defined in the MDN draft and has the following meaning: Parameters with an importance of "O" permit a UA that does not understand the "signed-receipt-protocol" parameter to still generate a MDN in response to a request for a MDN. A UA that does not understand the "signed-receipt-protocol" parameter, will obviously not return a signed receipt. The importance of "O" is used for the signed receipt parameters because it is desirable that an MDN be returned to the requesting trading partner even if the recipient could not sign it. The returned MDN will contain information on the dispostion of the message as well as why the MDN could not be signed. See the dispostion and extension fields in section 5.3 for more information. Within an EDI trading relationship, if a signed-receipt is expected and is not returned, then the validity of the transaction is up to the trading partners to resolve. In general, if a signed-receipt is required in the trading relationship and is not received, the transaction will likely not be considered valid. 3). The receiving UA should first parse the message header to see if a request for a signed receipt has been made. The receiving UA should then check to insure that it can support the requested format before proceeding to process the contents of the message. If the requested format cannot be supported, then a MDN is returned with the "X-signed-receipt-disposition" field set to "unsupported-format". Since the message contents have not been processed when an "unsupported-format" is detected, the message "disposition-field" should be set to "notprocessed". 4). When a request for a signed receipt is made, but there is an error in processing the contents of the message, then a signed receipt should still be returned. The non-repudiation of receipt should still be honored, though the transaction itself is not valid. The reason for why the contents could not be processed should still be set in the "dispostion-field". 5.3 Message Disposition Notification Format The format of a message disposition notification is as specified in draft-ietf-receipt-mdn-02.txt. For use in EDI over the Internet the following format will be used: - content-type - per RFC1892 and the ietf-receipt-mdn specification - reporting-ua-field - per ietf-receipt-mdn specification - mdn-gateway-field - per ietf-receipt-mdn specification - original-recipient-field - per ietf-receipt-mdn specification - final-recipient-field - per ietf-receipt-mdn specification - original-message-id-field - per ietf-receipt-mdn specification - disposition-field - for EDI use: "notprocessed" - The received content(s) was not processed. "autoprocessed" - The received content(s) was successfully processed. "decryption-failed" - The receiver could not decrypt the contents. "authentication-failed" - The receiver could not authenticate the sender. "integrity-check-failed" - The receiver could not verify content integrity. - extension field - the following extension fields will be added in order to support signed-receipts for RFC 1767 MIME content types and multi-part MIME content types that include RFC 1767 MIME content types. The "X-Received-MIC" extension field is set when the integrity of the received message is verified. The MIC or message integrity check, is defined as a result of a one-way hash function applied to the received RFC 1767 MIME content, or a multi-part MIME content containing RFC 1767 MIME content. The MIC is applied to the MIME headers as well as the content. This field is set only when the contents of the message are processed successfully. This field is used in conjunction with the receiver's signature on the MDN, in order for the sender to verify non-repudiation of receipt. - extension field = "X-" "received-MIC" ":" MIC The "X-signed-receipt-disposition" extension field is set when a request for a signed receipt is made by the sender, but cannot be returned by the receiver. - extension field = "X-" "signed-receipt-disposition": signed-receipt-disposition where signed-receipt-disposition is: "unsupported-format" - A request for a signed receipt cannot be returned because the requested format is not supported. "unexpected-error" - A catch-all for errors that prevent a signed receipt from being returned when it has been requested. 5.4 Message Disposition Notification Processing 5.4.1 Large File Processing Large EDI Interchanges sent via SMTP can be automatically fragmented by some message transfer agents. A subtype of message, "partial", is defined in RFC 1521 to allow large objects to be=20 delivered as separate pieces of mail and to be automatically reassembled by the receiving user agent. Using message, "partial", can help alleviate fragmentation of large messages by different message transfer agents, but does not completely eliminate the problem. It is still possible that a piece of a partial message, upon re-assembly, may prove to contain a partial message as well. This is allowed by the Internet standards, and it is the responsibility of the user agent to re-assemble the fragmented pieces. It is recommended that the size of the EDI Interchange sent via SMTP be configurable so that if fragmentation does occur, then message, "partial" can be used to send the large EDI Interchange in smaller pieces. RFC 1521 defines the use of Content-Type: message/partial. Support of the message/partial content type for use in Internet EDI is optional. The receiving UA is required to re-assemble the original message before sending the message disposition notification to the original sender of the message. A message disposition notification is used to specify the disposition of the entire message that was sent, and should not be returned by a processing UA until the entire message is received, even if the received message requires re-assembling. In general, EDI content compresses well, since there is repetitive data in most EDI Interchanges. Instead of implementing the message/partial, compression of the EDI Interchange can be done after the signature is applied to the EDI Interchange, and before encryption. When no signature applied, then compression is applied before the encryption. Compression is an alternative solution to implementing Content-Type: message/partial when sending large EDI Interchanges on the Internet. Applying compression before encryption strengthens cryptographic security since repetitious strings are reduced. This sequence is consistent with the PGP sequence as well. 5.4.2 Example The following is an example of a signed receipt returned by a UA after processing a MIME EDI content type that was signed. This example follows the S/MIME application/x-pkcs-7-signature format. NOTE: This example is provided as an illustration only, and is not considered part of the protocol specification. If an example conflicts with the protocol definitions specified above or in the other referenced RFCs, the example is wrong. To: Subject: From: Date: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="separator"; micalg=rsa-sha1; protocol="application/x-pkcs7-signature" --separator &Content-Type: multipart/report; report-type=disposition & notification; boundary = "xxxxx" & &--xxxxx & The message sent to Edi Recipient & has been received, the EDI Interchange was succesfully & decrypted and its integrity was verified. In addition, the & sender of the message, Edi Sender & was authenticated as the originator of the message. There is & no guarantee however that the EDI Interchange was & syntactically correct, or was received by the EDI & application. & &--xxxxx & Content-Type: message/disposition-notification & & Reporting-UA: good-edi-internet-ua.edicorp.com (ediua 1.0) & Original-Recipient: rfc822; Edi_Recipient@edicorp.com & Final-Recipient: rfc822; Edi_Recipient@edicorp.com & Original-Message-ID: <17759920005.12345@edicorp.com> & Disposition: autoprocessed & X-Received-MIC: Q2hlY2sgSW50XwdyaXRIQ=85=85 & &--xxxxx & Content-Type: message/rfc822 & &--xxxxx-- --separator Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: base64 @ContentType = SignedData @version = Version @digestAlgorithms = DigestAlgorithmIdentifiers @signerInfos = SignerInfo --separator-- Notes: -The lines preceeded with "&" is what the signature is calculated over. -The text preceeded by "@" indicates PKCS#7 defined fields and types. (For details on how to prepare the multipart/signed with protocol = "application/x-pkcs7-signature" see the "S/MIME Message Specification, PKCS Security Services for MIME" documentation.) As specified by RFC 1892, returning the original message is not necessary. This is an optional body part. It is recommended that the received headers be placed in the third body part, as it can be helpful in tracking problems. 6. Public key certificate handling 6.1 Near term approach In the near term, the exchange of public keys and certificaition of these keys must be handled as part of the process of establishing a trading partnership. The UA and/or EDI application interface must maintain a database of public keys used for encryption or signatures, in addition to the mapping between EDI trading partner ID and RFC822 email address. The procedures for establishing a trading partnership and configuring the secure EDI messaging system might vary among trading partners and software packages. For systems which make use of X.509 certificates, it is recommended that trading partners self-certify each other if an agreed upon certification authority is not used. It is highly recommended that when trading partners are using S/MIME, that they also exchange public key certificates using the recommendations specified in the S/MIME Implementation Guide Version 2. The message formats and S/MIME conformance requirements for certificate exchange are specified in this document. This applicability statement does NOT require the use of a certification authority. 6.2 Long term approach In the long term, additional Internet-EDI standards may be developed to simplify the process of establishing a trading partnership, including the third party authentication of trading partners, as well as attributes of the trading relationship. 7. Authors' Addresses Mats Jansson mjansson@agathon.com LiNK 2317 Broadway, Suite 330 Redwood City, CA 94063 USA Chuck Shih chucks@actracorp.com Actra Corp. 610 East Caribbean Drive Sunnyvale, CA 94089 USA Nancy Turaj nturaj@.mitre.org MITRE Corporation Mailstop: W657 1820 Dolley Madison Blvd. McLean, VA 22102-3481 USA Rik Drummond drummond@onramp.com The Drummond Group 5008 Bentwood Ct. Ft. Worth, TX 76132 USA 8. References [1] N. Borenstein, N.Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 23, 1993. [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 2, 1995. [3] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 13, 1982. [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 2015, Sept. 1996. [5] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", draft-ietf-receipt-mdn-01.txt, May 13, 1996. [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct. 3, 1995 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1, 1982. [8] S. Dusse, "S/MIME Message Specification; PKCS Security Services for MIME", Internet draft: draft-dusse-mime-msg-spec 00.txt [9] C. Shih, "Requirements for Inter-operable Internet EDI", July 1996. [10] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 15, 1996. --------------26AD2E58208-- From owner-ietf-ediint Wed Feb 12 10:57:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA26296 for ietf-ediint-bks; Wed, 12 Feb 1997 10:57:36 -0800 (PST) Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA26292 for ; Wed, 12 Feb 1997 10:57:34 -0800 (PST) Received: from agathon.vip.best.com (agathon.vip.best.com [205.149.165.153]) by proxy1.ba.best.com (8.8.5/8.8.3) with SMTP id KAA18881; Wed, 12 Feb 1997 10:49:23 -0800 (PST) Date: Wed, 12 Feb 1997 10:49:23 -0800 (PST) Message-Id: <199702121849.KAA18881@proxy1.ba.best.com> X-Sender: mjansson@best.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: edipilot@commerce.net, ietf-ediint@imc.org From: Mats Jansson Subject: MIME EDI Structures - next take Cc: karenr@premenos.com, chucks@actracorp.com Sender: owner-ietf-ediint@imc.org Precedence: bulk Karen: Thanks for the suggestions - I agree it makes more sense. Attached here are the structures described the way you suggested. Mats 4.2 Structure of an EDI MIME message - PGP/MIME 4.2.1 No encryption, no signature -RFC822/1521 -RFC1767 (Application/EDIxxxx) 4.2.2 No encryption, signature -RFC822/1521 -RFC1847 (Multipart/signed) -RFC1767 (Application/EDIxxxx) -RFC2015 (Application/pgp-signature) 4.2.3 Encryption, no signature -RFC822/1521 -RFC1847 (Multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version 1" -RFC1767 (Application/EDIxxxx) (encrypted) 4.2.4 Encryption, signature -RFC822/1521 -RFC1847 (Multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version 1" -RFC1847 (Multipart/signed) (encrypted) -RFC1767 (application/EDIxxxx) (encrypted) -RFC2015 (Application/pgp-signature) (encrypted) 4.3 Structure of an EDI MIME message - S/MIME 4.3.1 No encryption, no signature -RFC822/1521 -RFC1767 (Application/EDIxxxx) 4.3.2 No encryption, signature -RFC822/1521 -RFC1847 (Multipart/signed) -RFC1767 (Application/EDIxxxx) -Draft (dusse) (Application/x-pkcs7-signature) 4.3.3 Encryption, no signature -RFC822/1521 -Draft (dusse) (application/x-pkcs7-mime) -RFC1767 (Application/EDIxxxx) (encrypted) 4.3.4 Encryption, signature -RFC822/1521 -Draft (dusse) (application/x-pkcs7-mime) -RFC1847 (Multipart/signed) (encrypted -RFC1767 (application/EDIxxxx) (encrypted) -Draft (dusse) (Application/x-pkcs7-signature) _____________________________________________________________ Mats Jansson, LiNK mjansson@agathon.com 2317 Broadway, Suite 330 Redwood City, CA 94063 v: +1-415-780-9039 http://www.agathon.com f: +1-415-780-9069 From owner-ietf-ediint Wed Feb 12 12:19:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA28733 for ietf-ediint-bks; Wed, 12 Feb 1997 12:19:29 -0800 (PST) Received: from gatekeeper.premenos.com (mail.premenos.com [150.105.250.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA28728 for ; Wed, 12 Feb 1997 12:19:26 -0800 (PST) Received: from localhost (smap@localhost) by gatekeeper.premenos.com (8.6.5/8.6.5) id MAA03333; Wed, 12 Feb 1997 12:23:23 -0800 Received: from karenr.premenos.com(150.105.100.205) by mail.premenos.com via smap (V1.3mjr) id sma003322; Wed Feb 12 12:22:27 1997 Message-ID: <3301FBB2.48E6@premenos.com> Date: Wed, 12 Feb 1997 12:19:47 -0500 From: Karen Rosenthal Reply-To: karenr@premenos.com Organization: Premenos X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: edipilot@commerce.net, ietf-ediint@imc.org Subject: MIME-based Secure EDI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Regarding the new revision of the MIME-based Secure EDI draft: Thumbs up to the new draft, with the exception of one section that I think should be revised: >5.2 >3). The receiving UA should first parse the message header to see if a request for a > signed receipt has been made. The receiving UA should then check to insure that > it can support the requested format before proceeding to process the contents of > the message. If the requested format cannot be supported, then a MDN is returned > with the "X-signed-receipt-disposition" field set to "unsupported-format". > > Since the message contents have not been processed when an "unsupported-format" > is detected, the message "disposition-field" should be set to "notprocessed". The draft shouldn't dictate whether or not the recipient should process the message, if the signature requested for the receipt cannot be supported. This should be the choice of the recipient. 5.2 item 2 already specifies that if a signed-receipt is expected but not returned, the validity of the transaction will likely be invalid. Regards, -- Name: Karen Rosenthal E-mail: karenr@premenos.com Phone: (510)688-2928 Fax: (510)602-2133 From owner-ietf-ediint Wed Feb 12 13:50:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA29845 for ietf-ediint-bks; Wed, 12 Feb 1997 13:50:12 -0800 (PST) Received: from na3.dow.com (na3.dow.com [198.17.33.4]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA29837 for ; Wed, 12 Feb 1997 13:50:08 -0800 (PST) From: tjeffers@dow.com Received: by na3.dow.com id AA25794 (InterLock SMTP Gateway 3.0 for ietf-ediint@imc.org); Wed, 12 Feb 1997 16:51:49 -0500 Message-Id: <199702122151.AA25794@na3.dow.com> Received: by na3.dow.com (Internal Mail Agent-1); Wed, 12 Feb 1997 16:51:49 -0500 To: Subject: Is the goal really "EDI" over the internet? Date: Wed, 12 Feb 1997 16:51:55 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ietf-ediint@imc.org Precedence: bulk It appears from reviewing the discussion archives and the draft document that EDI standards and practices are completely ignored, and in some cases specifically excluded from consideration, when trying to decide the best method for implementation or how to proceed. What you are proposing is really secure internet transmission of data regardless of format (proprietary, EDI, etc..). Should the charter of the working group be changed since EDI is really not a consideration? Regards, Todd Jeffers From owner-ietf-ediint Wed Feb 12 14:41:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA00709 for ietf-ediint-bks; Wed, 12 Feb 1997 14:41:04 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA00704 for ; Wed, 12 Feb 1997 14:40:56 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA29715 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Wed, 12 Feb 1997 14:42:38 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA01422; Wed, 12 Feb 97 14:37:31 PST Date: Wed, 12 Feb 97 14:37:31 PST From: carl@chage.com (Carl Hage) Message-Id: <9702122237.AA01422@slick.chage.com> To: ietf-ediint@imc.org Subject: Revision of Signed Receipts Sender: owner-ietf-ediint@imc.org Precedence: bulk The new draft looks pretty good. Typo: 4.3.1 No encryption, no signature -FC1767 (Application/EDIxxxx) I still don't like the usage of X-Received-MIC, or even the name: - extension field - the following extension fields will be added in order to support signed-receipts for RFC 1767 MIME content types and multi-part MIME content types that include RFC 1767 MIME content types. ...The MIC or message integrity check, is defined as a result of a one-way hash function applied to the received RFC 1767 MIME content, or a multi-part MIME content containing RFC 1767 MIME content. The MIC is applied to the MIME headers as well as the content. The problems I have are: - A MIC cannot be supplied on unsigned data If the content doesn't have a signature, then a MIC can't be included in the MDN, but it should be. This is a flaw, since this RFC says data doesn't need to be signed, but then there is no definition for a MIC needed for non-repudiation. - The MIC doesn't include all the data within the email message-- only part of the message is included in the non-repudiation. This isn't that big a deal in the context of the single EDI content, but causes more problems for general secure email. The signature isn't included in the receipt MIC. The receipt thus doesn't acknowledge a specific signature. It would be best to supply a MIC over the decrypted content, which includes the signature(s), or whatever content was sent. For example, "X-Decrypted-MIC" would supply the MIC of the complete content (usually starting with headers of multipart/signed) after decrypting. This is a separate MIC from the signed data. An "X-Received-MIC" could be defined as the content, or decrypted content. A MIC of the encrypted content isn't desirable since only the recipient can decode to authenticate. - The MIC cannot be interpreted without additional information The MIC doesn't include the algorithm, so an MDN and a log of pre-signed messages can't be correlated. The MIC should include the algorithm in addition to the value. - The attribute name is misleading The X-Received-MIC is not the content received, but the MIC of the signed data. Using "X-Signature-MIC" or "X-Signed-MIC" is more specific. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Wed Feb 12 15:16:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA01219 for ietf-ediint-bks; Wed, 12 Feb 1997 15:16:34 -0800 (PST) Received: from gatekeeper.premenos.com (mail.premenos.com [150.105.250.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA01214 for ; Wed, 12 Feb 1997 15:16:31 -0800 (PST) Received: from localhost (smap@localhost) by gatekeeper.premenos.com (8.6.5/8.6.5) id PAA07823; Wed, 12 Feb 1997 15:20:51 -0800 Received: from om.premenos.com(150.105.100.49) by mail.premenos.com via smap (V1.3mjr) id sma007812; Wed Feb 12 15:19:56 1997 Received: from fortune.premenos.com by premenos.com. (5.x/SMI-SVR4) id AA08718; Wed, 12 Feb 1997 14:57:14 -0800 Date: Wed, 12 Feb 97 14:38:25 From: Steve Botts Subject: RE: Is the goal really "EDI" over the internet? To: ietf-ediint@imc.org, tjeffers@dow.com X-Priority: 3 (Normal) X-Mailer: Chameleon 5.0, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ediint@imc.org Precedence: bulk --- On Wed, 12 Feb 1997 16:51:55 -0500 tjeffers@dow.com wrote: >It appears from reviewing the discussion archives and the draft document >that EDI standards and practices are completely ignored, and in some >cases specifically excluded from consideration, when trying to decide >the best method for implementation or how to proceed. What you are >proposing is really secure internet transmission of data regardless of >format (proprietary, EDI, etc..). Should the charter of the working >group be changed since EDI is really not a consideration? > Todd, I disagree with your observations. Particularly since Premenos has had our Templar product, which bears a striking resemblance, to the IETF draft on the market for nearly two years. No one would argue that we're not an EDI company or that we're interested in promoting anything but standards in the implementation of our products. The same may be said of the other participants. We're all EDI savvy. The charter of the WG has been to recommend and demonstrate a means to securely send EDI over the Internet, using existing standards where they may be applied. We have also sought to make our recommendation open so that the same mechanisms and processes could be used for other data types. Let's face it, we have enough single purpose, closed systems that are not interoperable. All of the participants in the creation of the draft and the interoperability testing have my highest compliments and are to be commended for their cooperation in this effort, despite the fact that we compete in the marketplace for the same customers. -Steve -------------------------------------------------------------------- Steve Botts +1 510 602 2000 Premenos Corp fax +1 510 602 2133 1000 Burnett Avenue steveb@premenos.com Concord, CA 94520 http://www.premenos.com -------------------------------------------------------------------- From owner-ietf-ediint Wed Feb 12 15:35:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA01411 for ietf-ediint-bks; Wed, 12 Feb 1997 15:35:16 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA01407 for ; Wed, 12 Feb 1997 15:35:14 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA04637 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Wed, 12 Feb 1997 15:36:54 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA01521; Wed, 12 Feb 97 15:14:30 PST Date: Wed, 12 Feb 97 15:14:30 PST From: carl@chage.com (Carl Hage) Message-Id: <9702122314.AA01521@slick.chage.com> To: ietf-ediint@imc.org Subject: Is the goal really "EDI" over the internet? References: <199702122151.AA25794@na3.dow.com> Organization: C. Hage Associates, Sunnyvale, CA Sender: owner-ietf-ediint@imc.org Precedence: bulk The goal is "EDI" over the internet, but it would be stupid to define messaging protocols that wouldn't apply to other message content, but with similar security/reliability needs. tjeffers@dow.com wrote: : ... What you are : proposing is really secure internet transmission of data regardless of : format (proprietary, EDI, etc..). Should the charter of the working : group be changed since EDI is really not a consideration? Personally, I think splitting the RFC would be appropriate. There should be a secure/reliable email transaction process, independent of the content of data exchange, e.g. application/EDIxxxx or whatever. However, there are a few EDI specific parts, e.g. using RFC1767 to wrap X12/EDIFACT data, and the protocol of bundling one interchange into one RFC822 message. Most of the RFC could be independent of terms like "EDI", with a paragraph at the end for EDI specific definitions. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Wed Feb 12 18:51:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA03415 for ietf-ediint-bks; Wed, 12 Feb 1997 18:51:05 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA03411 for ; Wed, 12 Feb 1997 18:51:03 -0800 (PST) Received: from lincoln.actracorp.com ([205.217.242.76]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA19010 for ; Wed, 12 Feb 1997 18:51:15 -0800 Message-ID: <33027F0F.7F07@actracorp.com> Date: Wed, 12 Feb 1997 18:40:15 -0800 From: lincoln@actracorp.com (Lincoln Yarbrough) Reply-To: lincoln@actracorp.com Organization: Actra Business Systems X-Mailer: Mozilla 3.0GoldC (Win95; U) MIME-Version: 1.0 To: ietf-ediint@imc.org Subject: Re: MIME-based Secure EDI Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk I also think the draft looks good. Let's try it. -Lincoln -- Lincoln Yarbrough Email: lincoln@actracorp.com Actra Business Systems Tel#: 1.408.542.3261 610 Caribbean Drive Fax#: 1.408.542.3210 Sunnyvale, CA 94089 Visit: http://home.actracorp.com From owner-ietf-ediint Thu Feb 13 12:19:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA28159 for ietf-ediint-bks; Thu, 13 Feb 1997 12:19:29 -0800 (PST) Received: from proxy1.ba.best.com (root@proxy1.ba.best.com [206.184.139.12]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA28155 for ; Thu, 13 Feb 1997 12:19:26 -0800 (PST) Received: from agathon.vip.best.com (agathon.vip.best.com [205.149.165.153]) by proxy1.ba.best.com (8.8.5/8.8.3) with SMTP id MAA07314; Thu, 13 Feb 1997 12:15:24 -0800 (PST) Date: Thu, 13 Feb 1997 12:15:24 -0800 (PST) Message-Id: <199702132015.MAA07314@proxy1.ba.best.com> X-Sender: mjansson@best.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: tjeffers@dow.com, From: Mats Jansson Subject: Re: Is the goal really "EDI" over the internet? Sender: owner-ietf-ediint@imc.org Precedence: bulk Dear Todd: What you bring up has been brought up several times by new entrants to the list, and the answers have always been the same: The goals are for the EDI community to be able to adopt internet as an alternative to VAN/direct connect, in the easiest way possible, while making sure that all required security services are supported. Thus, -by treating the EDI data as "any old EC object", the standard becomes usable for a wide variety of EDI/EC applications -by not requiring any changes within the EDI data object, there is a very clear line between what the new encryption softwares do, and what the EDI translator softwares do. For many organizations, the transition simply involves replacing their communication script with the EC encryption app. -by not pre-empting, or being in conflict with X12.58 and EDIFACT security standards, we are not making things unnecessarily complicated, for organi- zations that use it, though some of the security services may be redundant. So, in closing - we have never been able to pin-point any reasons why making the standard more targetted to EDI (what does it mean?) would be of any benefit to anyone except consultants and others making a living off things being more complicated than they need to. If you have come up with any such reasons, the list, I'm sure, would love to hear about it. Mats J. Co-editor AS#1 At 04:51 PM 2/12/97 -0500, tjeffers@dow.com wrote: >It appears from reviewing the discussion archives and the draft document >that EDI standards and practices are completely ignored, and in some >cases specifically excluded from consideration, when trying to decide >the best method for implementation or how to proceed. What you are >proposing is really secure internet transmission of data regardless of >format (proprietary, EDI, etc..). Should the charter of the working >group be changed since EDI is really not a consideration? > >Regards, >Todd Jeffers > > _____________________________________________________________ Mats Jansson, LiNK mjansson@agathon.com 2317 Broadway, Suite 330 Redwood City, CA 94063 v: +1-415-780-9039 http://www.agathon.com f: +1-415-780-9069 From owner-ietf-ediint Thu Feb 13 12:36:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA29906 for ietf-ediint-bks; Thu, 13 Feb 1997 12:36:43 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA29899 for ; Thu, 13 Feb 1997 12:36:39 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA24030; Thu, 13 Feb 1997 12:36:50 -0800 Message-ID: <33037A45.3AE7@actracorp.com> Date: Thu, 13 Feb 1997 12:32:05 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: karenr@premenos.com CC: edipilot@commerce.net, ietf-ediint@imc.org Subject: Re: MIME-based Secure EDI References: <3301FBB2.48E6@premenos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Karen, I will remove this section. Karen Rosenthal wrote: > > +----------------------------------------------------------------------+ > This message was addressed to: edipilot@lists.commerce.net > +----------------------------------------------------------------------+ > > Regarding the new revision of the MIME-based Secure EDI draft: > > Thumbs up to the new draft, with the exception of one section that I > think should be revised: > > >5.2 > >3). The receiving UA should first parse the message header to see if a request for a > > signed receipt has been made. The receiving UA should then check to insure that > > it can support the requested format before proceeding to process the contents of > > the message. If the requested format cannot be supported, then a MDN is returned > > with the "X-signed-receipt-disposition" field set to "unsupported-format". > > > > Since the message contents have not been processed when an "unsupported-format" > > is detected, the message "disposition-field" should be set to "notprocessed". > > The draft shouldn't dictate whether or not the recipient should process > the message, if the signature requested for the receipt cannot be > supported. This should be the choice of the recipient. 5.2 item 2 > already specifies that if a signed-receipt is expected but not returned, > the validity of the transaction will likely be invalid. > > Regards, > -- > Name: Karen Rosenthal > E-mail: karenr@premenos.com > Phone: (510)688-2928 > Fax: (510)602-2133 > ------------------------------------------------------------------------- > This message was sent by a majordomo-based automatic list manager. > Subscriptions to and archives of this list are available to CommerceNet > members, partners, and invited guests. For further information send a > mail message to 'edipilot-request@lists.commerce.net' with 'help' > (no quotations) contained in the body of your message. From owner-ietf-ediint Thu Feb 13 23:52:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA11109 for ietf-ediint-bks; Thu, 13 Feb 1997 23:52:46 -0800 (PST) Received: from aun.uninett.no (aun.uninett.no [129.241.1.99]) by mail.proper.com (8.8.5/8.7.3) with SMTP id XAA11101 for ; Thu, 13 Feb 1997 23:52:42 -0800 (PST) Received: from dale.uninett.no (actually dale.htalvestrand.priv.no) by aun.uninett.no with SMTP (PP); Fri, 14 Feb 1997 08:53:58 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id IAA22043; Fri, 14 Feb 1997 08:53:49 +0100 From: Harald.T.Alvestrand@uninett.no To: carl@chage.com (Carl Hage) cc: ietf-ediint@imc.org Subject: Re: Is the goal really "EDI" over the internet? In-reply-to: Your message of "Wed, 12 Feb 1997 15:14:30 PST." <9702122314.AA01521@slick.chage.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22039.855906828.1@dale.uninett.no> Date: Fri, 14 Feb 1997 08:53:48 +0100 Message-ID: <22041.855906828@dale.uninett.no> Sender: owner-ietf-ediint@imc.org Precedence: bulk This group is chartered to give recommendations for EDI over the Internet; it cannot specify security protocols per se. I think the documents as they seem to be shaping up now do this; if they are also able to serve as an introducer to securing message transfer over the Internet, that's an added benefit, but not a purpose of the group. Harald A From owner-ietf-ediint Fri Feb 14 05:14:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id FAA01070 for ietf-ediint-bks; Fri, 14 Feb 1997 05:14:59 -0800 (PST) Received: from na3.dow.com (na3.dow.com [198.17.33.4]) by mail.proper.com (8.8.5/8.7.3) with SMTP id FAA01066 for ; Fri, 14 Feb 1997 05:14:55 -0800 (PST) From: tjeffers@dow.com Received: by na3.dow.com id AA06077 (InterLock SMTP Gateway 3.0 for ietf-ediint@imc.org); Fri, 14 Feb 1997 08:16:42 -0500 Message-Id: <199702141316.AA06077@na3.dow.com> Received: by na3.dow.com (Internal Mail Agent-1); Fri, 14 Feb 1997 08:16:42 -0500 To: , Subject: RE: Is the goal really "EDI" over the internet? Date: Fri, 14 Feb 1997 08:17:01 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ietf-ediint@imc.org Precedence: bulk I like this idea a lot. The effort to make this an open extensible environment should not be limited to EDI. But when implementing it for secure EDI, there should be some specific considerations. Regards, Todd Jeffers >---------- >From: carl@chage.com[SMTP:carl@chage.com] >Sent: Wednesday, February 12, 1997 6:14 PM >To: ietf-ediint@imc.org >Subject: Is the goal really "EDI" over the internet? > >The goal is "EDI" over the internet, but it would be stupid to define >messaging protocols that wouldn't apply to other message content, but with >similar security/reliability needs. > >tjeffers@dow.com wrote: >: ... What you are >: proposing is really secure internet transmission of data regardless of >: format (proprietary, EDI, etc..). Should the charter of the working >: group be changed since EDI is really not a consideration? > >Personally, I think splitting the RFC would be appropriate. There should >be a secure/reliable email transaction process, independent of the >content of data exchange, e.g. application/EDIxxxx or whatever. > >However, there are a few EDI specific parts, e.g. using RFC1767 to >wrap X12/EDIFACT data, and the protocol of bundling one interchange >into one RFC822 message. > >Most of the RFC could be independent of terms like "EDI", with a >paragraph at the end for EDI specific definitions. >-------------------------------------------------------------------------- >Carl Hage C. Hage Associates > Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 > Sunnyvale, CA 94086 > > From owner-ietf-ediint Fri Feb 14 08:47:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA03737 for ietf-ediint-bks; Fri, 14 Feb 1997 08:47:40 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA03733 for ; Fri, 14 Feb 1997 08:47:33 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA4036; Fri, 14 Feb 1997 08:47:51 -0800 Message-ID: <33049619.1C9B@actracorp.com> Date: Fri, 14 Feb 1997 08:43:05 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Carl Hage CC: ietf-ediint@imc.org Subject: Re: Revision of Signed Receipts References: <9702122237.AA01422@slick.chage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Carl Hage wrote: > > The new draft looks pretty good. > > Typo: > 4.3.1 No encryption, no signature > -FC1767 (Application/EDIxxxx) > > I still don't like the usage of X-Received-MIC, or even the name: > > - extension field - the following extension fields will be added in > order to support signed-receipts for RFC 1767 MIME content > types and multi-part MIME content types that include RFC > 1767 MIME content types. > > ...The MIC or message integrity check, is > defined as a result of a one-way hash function applied to the received > RFC 1767 MIME content, or a multi-part MIME content containing RFC 1767 > MIME content. The MIC is applied to the MIME headers as well as the > content. > > The problems I have are: > > - A MIC cannot be supplied on unsigned data > > If the content doesn't have a signature, then a MIC can't be included > in the MDN, but it should be. This is a flaw, since this RFC > says data doesn't need to be signed, but then there is no > definition for a MIC needed for non-repudiation. The Calculated MIC on the received contents can be returned in this field even if the original message is not signed. In this case there would not be non-repudiation of origin, but there would be non-repudiation of receipt. > > - The MIC doesn't include all the data within the email message-- > only part of the message is included in the non-repudiation. > This isn't that big a deal in the context of the single EDI content, > but causes more problems for general secure email. > Yes, only the content of the message is included in the non-repudiation. But this should be sufficient. > The signature isn't included in the receipt MIC. The receipt > thus doesn't acknowledge a specific signature. > Why does the receipt need to acknowledge a specific signature? The receiver would have had to verify the signature in order to process the MIC. > It would be best to supply a MIC over the decrypted content, which > includes the signature(s), or whatever content was sent. For > example, "X-Decrypted-MIC" would supply the MIC of the complete > content (usually starting with headers of multipart/signed) > after decrypting. This is a separate MIC from the signed data. > An "X-Received-MIC" could be defined as the content, or decrypted > content. > > A MIC of the encrypted content isn't desirable since only the > recipient can decode to authenticate. The MIC calculated by the receiver is on the decrypted content. Decryption occurs first, then signature verification, and then message integrity check, i.e. calculating a MIC on the received contents and comparing it to the MIC that was sent. I'm not following this. > > - The MIC cannot be interpreted without additional information > > The MIC doesn't include the algorithm, so an MDN and a log of > pre-signed messages can't be correlated. The MIC should include > the algorithm in addition to the value. I can add this parameter to the extension field. > > - The attribute name is misleading > > The X-Received-MIC is not the content received, but the MIC of the > signed data. Using "X-Signature-MIC" or "X-Signed-MIC" is more > specific. I'll change the attribute name to "X-Received-Content-MIC", which would also take care of the case where the original message was not signed, but a signed-receipt is still requested. > -------------------------------------------------------------------------- > Carl Hage C. Hage Associates > Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 > Sunnyvale, CA 94086 From owner-ietf-ediint Fri Feb 14 09:45:34 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA05330 for ietf-ediint-bks; Fri, 14 Feb 1997 09:45:34 -0800 (PST) Received: from ns.stercomm.com (ns.stercomm.com [199.3.19.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA05308 for ; Fri, 14 Feb 1997 09:45:30 -0800 (PST) Received: ns.stercomm.com id AA13366; Fri, 14 Feb 1997 12:41:51 -0500 Mime-Version: 1.0 Date: Fri, 14 Feb 1997 12:45:17 -0500 Message-Id: <00024D76.1733@stercomm.com> From: Dale_Moberg@stercomm.com Subject: Revision of Signed Receipts To: chucks@actracorp.com (Chuck Shih) Cc: ietf-ediint@imc.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ediint@imc.org Precedence: bulk Comments on ietf-ediint-as1 draft : 1. I agree that section 5.2.3 should be removed so that the behavior of downstream EDI processing can be left configurable by the user and in accordance with detailed trading policies and agreements. 2. I think that in section 5.3 the need for the X-Received-MIC extension field is overkill. The integrity check has already been done by the receiver when the authentication was done. It is not a real part of the signing of the receipt by the receiving partner. It is not needed to correlate the receipt with the original message because the original-message-id-field already does that. The information conveyed is not really diagnostic of a problem with the transport. It is not needed for gatewaying to other message transport systems, as far as I can tell. Since it could be altered by a malicious mail relay, it could create confusion about the success of the transmission if the sending site actually tried to check the value in its records, assuming such information is kept (and if not, what would be the point of returning it). Nevertheless, if an application wanted to send back this information,the information could easily be incorporated within the RFC 1894 structure within the optional returned message field. (The hash value is a "part" of the original message, although buried.) Or it could be made a part of the human readable report. I guess I don't see what real work the return of this value is thought to play. I would prefer to see explicit additional disposition-values such as "authentication-verified" or "integrity-verified" instead of sending back this value. 3. The semantics of the disposition values needs some clarification. First, can more than one disposition value be returned or are these values intended to be mutually exclusive? (Can there be a list following the header or multiple headers starting "Disposition:" ?) It is conceivable that trading partners would agree to autoprocess purchase orders even if authentication failed, for example. Authentication might fail because a certificate issuer validity period expired, and while awaiting a reissue, the partners might decide to continue processsing. Software might even offer users a configurable option to ignore authentication to allow trading to continue during a period of merely technical or administrative difficulty. In that case, a MDN should say "autoprocessed" and "authentication-failed". Also, the explanation of "autoprocessed" in the ietf-ediint draft differs from the explanation in the fajman draft. The fajman draft says only that the user agent successfully submitted the content for some further processing. The ietf-ediint draft is less cautious and says that the contents were successfully processed (by the downstream applications?). I think the ietf-ediint language for autoprocessed should be aligned with the fajman draft with no implication about the success of subsequent processing. The downstream processing of EDI already has mechanisms for acknowledging EDI processing if the trading partners agree to use them. Some other things I noticed while rereading this document: 4. Section 5.4.1 suggests using compression but mentions no applicable standards for using it. What standards within the MIME RFCs would specify an interoperable approach? 5. The References should be updated to reflect the new MIME RFCs 2045 to 2049. One thing I noticed in these new RFCs is that the CRLF before a boundary marker is considered part of the boundary marker. So when using a binary content-transfer-encodings within multipart/signed structures within the signed-then-enveloped EDI, it appears that a CRLF is to be appended to the binary stream and then the boundary marker appended (?). In general, because any string can possibly occur within a binary part (especially if compressed), it will be hard to guarantee that a boundary will work unless the binary is screened against the boundary before packaging. I think that the content-transfer-encoding field for a binary identity transfer encoding should have a mandatory parameter of the length of the binary field or else some other encoding should be used. Of course, you can always just hope that your marker is nowhere in the 20 MB file most of the time :-). Bye, Dale Moberg From owner-ietf-ediint Fri Feb 14 10:16:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA09157 for ietf-ediint-bks; Fri, 14 Feb 1997 10:16:10 -0800 (PST) Received: from interlock.gartner.com (interlock.gartner.com [198.81.204.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id KAA09145 for ; Fri, 14 Feb 1997 10:16:06 -0800 (PST) Received: by interlock.gartner.com id AA14119 (InterLock SMTP Gateway 3.0 for ietf-ediint@imc.org); Fri, 14 Feb 1997 13:17:49 -0500 Message-Id: <199702141817.AA14119@interlock.gartner.com> Date: 14 Feb 1997 13:11:02 -0500 From: "Victor Wheatman" Subject: NoCal EDI/EC Meeting To: ietf-ediint@imc.org X-Mailer: Mail*Link SMTP/QM 3.0.0 Sender: owner-ietf-ediint@imc.org Precedence: bulk Reply to: NoCal EDI/EC Meeting Northern California EDI/EC Users Group Meeting March 26th 8:30 AM Gartner Group World Events Center 251 River Oaks Parkway San Jose, California 95134 Topics: o Electronic Commerce and the Law (Ben Wright) o Secure Electronic Commerce and the Role of Certification Authorities (Victor S. Wheatman) Electronic Commerce and the Law A critical goal of electronic commerce is to create evidence of transactions so they can later be authenticated in court. Mr. Wright will consider alternative strategies for legally authenticating transactions, including the new Utah Digital Signature Act and biometric signing methods. He will also describe techniques for making reliable electronic archives and for achieving trust over the Internet. Benjamin Wright is the author of The Law of Electronic Commerce: EDI, E-mail and Internet, a comprehensive book on the legality of electronic contracts, published by Little, Brown and Company. He is also editor of EDI Forum, a quarterly journal covering technology, business, legal and security issues in electronic commerce. A graduate of Georgetown University Law School, Mr. Wright is an independent attorney practicing electronic commercial law in Dallas, Texas. E-mail: Ben_Wright@compuserve.com; URL: http://infohaus.com/access/by-seller/Benjamin_Wright Secure Electronic Commerce and the Role of Certification Authorities This presentation examines the appropriate use of the Internet for "official correspondence" and the methodologies now available to insure safe messaging. The talk looks at the emerging role of Certification Authorities in providing a public key infrastructure, with a market segmentation of the major players. The issues facing users, and the Certification Authorities themselves, in market education, liability and other areas, are examined. The presentation concludes by describing the EC and security standards in which enterprises will need to invest over the next two to five years. Victor S. Wheatman, Vice President - Information Security Strategies, Gartner Group, Inc. Mr. Wheatman joined Gartner Group in 1989, specializing in analysis of Electronic Commerce markets. He is president of the Northern California EDI/EC Users Group. Earlier in his career Mr. Wheatman worked as a public broadcasting manager and award winning radio journalist. Mr. Wheatman holds a M.S. in Communications from Boston University, a B.A. in Journalism from Fairleigh Dickinson University, a Telecommunications Management Certificate from Golden Gate University, and he attended the Executive Management Program at Harvard University. From owner-ietf-ediint Fri Feb 14 14:07:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA00300 for ietf-ediint-bks; Fri, 14 Feb 1997 14:07:54 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA00284 for ; Fri, 14 Feb 1997 14:07:48 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA29033 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Fri, 14 Feb 1997 14:09:36 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA01019; Fri, 14 Feb 97 14:02:00 PST Date: Fri, 14 Feb 97 14:02:00 PST From: carl@chage.com (Carl Hage) Message-Id: <9702142202.AA01019@slick.chage.com> To: ietf-ediint@imc.org Subject: Re: Revision of Signed Receipts References: <9702122237.AA01422@slick.chage.com> <33049619.1C9B@actracorp.com> Organization: C. Hage Associates, Sunnyvale, CA Sender: owner-ietf-ediint@imc.org Precedence: bulk Chuck Shih (chucks@actracorp.com) wrote: : Carl Hage wrote: : > : Why does the receipt need to acknowledge a specific signature? The : receiver would have had to verify the signature in order to process the : MIC. Basically, to provide non-repudiation of receipt on the complete set of data received, including who signed the data. In the case of a dispute, the recipient could present the signature which could only have been created by the sender. However, this doesn't allow other verifications, e.g. auditors to verify who signed outgoing messages. Returning a MIC (co-signing) all data is also more general and extends to more sophisticated future applications, e.g. a transaction is validated when multiple signatures are presented, or cases where the message contains a multipart with attachments, etc. : > The X-Received-MIC is not the content received, but the MIC of the : > signed data. Using "X-Signature-MIC" or "X-Signed-MIC" is more : > specific. : I'll change the attribute name to "X-Received-Content-MIC", which would : also take care of the case where the original message was not signed, : but a signed-receipt is still requested. I wish I could think of a better name than, "Content", which typically refers to the top level data following the RFC822 headers. It would be nice to have a clear rule on how to compute a MIC which applied to an MDN of any email message, i.e. define the Received-MIC for all cases, not just the EDI case of always one signed RFC1767 data part. Returning the outer content, or outermost decrypted content would apply to all messages. I suppose one could "punt" and allow MICs of any content, and where MIME content is wrapped, a MIC could be computed and matched against the Received-MIC. In other words, in the general case, multiple MICs could be returned, or one of a number of possible MICs could be returned. There could also be a MDN request option to indicate where the MIC is calculated. -------------------------------------------------------------------------- Dale_Moberg@stercomm.com wrote: : : 1. I agree that section 5.2.3 should be removed so that the behavior : of downstream EDI processing can be left configurable by the user and : in accordance with detailed trading policies and agreements. The MDN disposition would indicate if the message was accepted or canceled, allowing either case. A separate header indicates a problem with the MDN signature format request. Note, that the case is where the sender's transaction has been authenticated and a valid request has been made. The only problem is that the recipient cannot sign the MDN in the requested format. Since a valid request has been made, there isn't really a need to abort the transaction. Rather than suspending trading, a receipt could be generated, signed (by whatever) and returned. It would be up to the sender to install the appropriate software, accept (temporarily) unauthenticated receipts, or suspend trading. Say I file a tax return with the IRS, and I ask for a PGP signture. However, say the IRS insists on using clipper chips to sign thier receipts. Instead of cancelling a valid filing, I would get a receipt with the IRS determined signature algorithm. I could then either install clipper software/hardware, or accept the receipt I get. I would want the receipt signed in some verifyable format, rather then return no signature. Since a multipart/signed is used, I can read the receipt OK even if I can't authenticate. : 2. I think that in section 5.3 the need for the X-Received-MIC : extension field is overkill. The integrity check has already been done : by the receiver when the authentication was done. The X-Received-MIC is necessary for non-repudiation of receipt. Otherwise, there is no guarantee that the recipient received a particular message. The message ID doesn't indicate content-- only the MIC does. The X-Received-MIC has nothing to do with diagnosing transport problems-- it's only for nonrepudiation, i.e. cryptographically secure binding of the receipt with the "content" of a particular message. : 3. The semantics of the disposition values needs some clarification. : First, can more than one disposition value be returned or are these : values intended to be mutually exclusive? That would require alteration of the MDN RFC-- a different group. I think allowing a list makes sense. : 4. Section 5.4.1 suggests using compression but mentions no : applicable standards for using it. What standards within the : MIME RFCs would specify an interoperable approach? PGP compresses within the encryption algorithm. The proper way to add encryption in my opinion, would be to borrow the Content-Encoding header from HTTP, which allows a compression algorithm to be added without tampering with the Content-Type, or wrapping Content-Type. Too bad this wasn't added in the MIME revision. : 5. The References should be updated to reflect the new MIME RFCs : 2045 to 2049. One thing I noticed in these new RFCs is that the CRLF : before a boundary marker is considered part of the boundary marker. This was there before too, if you read the fine print. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Sun Feb 16 13:45:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA24209 for ietf-ediint-bks; Sun, 16 Feb 1997 13:45:47 -0800 (PST) Received: from okau.ok.br.np.els-gms.att.net (okau.ok.br.np.els-gms.att.net [199.191.128.73]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA24205 for ; Sun, 16 Feb 1997 13:45:44 -0800 (PST) Date: Sun, 16 Feb 1997 12:34:41 +0000 From: intech2@attmail.com (David Paraiso, Jr.) Received: from intech2 by attmail; Sun Feb 16 21:47:01 GMT 1997 Subject: EDI/EC Courses at the University of New Mexico-Albuquerque To: ietf-ediint@imc.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Sender: owner-ietf-ediint@imc.org Precedence: bulk The following intensive EDI and Electronic Commerce (EC) courses will be conducted at the University of New Mexico-Albuquerque between March 24-29. These same courses are scheduled at the U.S. International University-San Diego between February 24-March 1, and are also offered and and conducted by the same faculty at UC-Berkeley, UC-Irvine, and UCLA. Please contact us for specifics and refer to course descriptions, pre-requisites and enrollment procedures below. thanks, Melody intech2@attmail.com ****************************************************************************** 1. ELECTRONIC DATA INTERCHANGE(EDI) IMPLEMENTATION (16 hours) UNMA - Course Number: B5864B; $550; 3/24-3/25 Monday and Tuesday 2. IMPLEMENTING FINANCIAL EDI/EC APPLICATIONS (16 hours) UNMA - Course Number: B5859B; $550; 3/26-3/27 (Wednesday and Thursday) 3. AUDITING EDI/EC IMPLEMENTATIONS (8 hours) UNMA - Course Number: C5861C; $350; 3/28 (Friday) 4. MANAGING EDI/EC PROJECTS (8 hours) UNMA - Course Number: C5862C; $350; 3/29 (Saturday) 5. ADVANCED EDI/EC ARCHITECTURE (16 hours) - to be announced. 6. IMPLEMENTING HEALTHCARE EDI/EC APPLICATIONS (16 hours) - to be announced. ADVANCED REGISTRATION IS REQUIRED. To register, please list the course number(s), campus location and mail a check payable to Integrated Technologies, P.O. Box 3465, Santa Fe Springs, CA 90670. Alternatively, please call (310) 771-6112; or, FAX: (818) 918-6115 or (818) 918-8145; or E-mail: intech2@attmail.com. Classes at the University of New Mexico-Albuquerque will be held at Room G, Conference Center, 1634 University Blvd., NE, Albuquerque, NM 87131. Classes at U.S. International University-San Diego will be conducted at Green Hall, 10455 Pomerado Road, San Diego, CA 92131. Classes are conducted from 9AM-5PM. For a list of hotels and airports, or directions, or course schedule at UC-Berkeley, UC-Irvine and UCLA, please call (310) 771-6112, or send a message to FAX: (818) 918-8145, or E-Mail: intech2@attmail.com. ***************************************************************************** IMPLEMENTING ELECTRONIC DATA INTERCHANGE (EDI) - 16 hours According to a recent Electronic Data Interchange Association estimate, close to 60,000 companies worldwide have moved numerous applications from paper-based technology to electronics-based EDI technology. In retail, distribution, electronics, automotive, pharmaceutical, apparel, transportation, and other industries, EDI has become the way to do business or to take your business elsewhere. This applications-oriented workshop is structured to assist MIS, accounts payable, accounts receivable, warehouse, transportation, and finance departments in the successful planning and implementation of EDI with trading partners. Using case studies to illustrate applications such as order entry, billing, bar code, shipment, and EFT, the course utilizes the following ANSI X12 transaction sets: 810, 820, 824, 832, 846, 850, 855, 856, 860, 865, 869, 870, 997, etc. Topics include: EDI envelopes, segments, elements, and data dictionary; translators, mappers, and interfaces; communications software; value added network and value added bank; CCD+/CTP/CTX formats; banks, federal and state agencies; industry associations, publications, and events; trading partner legal documents; audit procedures; operational contingencies; EDI administration and coordination; hub and spoke implementation; trends and implications of EDI; economics of EDI; and barriers to EDI justification and implementation. COMPANION COURSES: Implementing Financial EDI/EC Applications or Advanced EDI/EC Architecture or Managing EDI/EC Projects. PRE-REQUISITE COURSES: None. ADVANCED EDI/EC ARCHITECTURE - 16 hours This workshop is a presentation of design and implementation techniques utilized in large-scale EDI and electronic commerce (EC) projects in banking, retail, automotive, petroleum, utilities, distribution, aerospace, and other industries. From a business process re-engineering perspective, several EDI/EC applications are discussed, including electronic funds transfer (EFT), evaluated receipt settlement (ERS), vendor management inventory, automatic replenishment, and JIT. This workshop is intended for corporate planners, ClOs, AP/AR managers, business process engineering teams, project managers, information processing managers, auditors, systems integration and technical teams, EDI administrators, EDI coordinators, and customer service managers. Business, technical, and operational parameters are discussed in implementing the following: bar codes; X.400/X.435/X.500; security; batch, event-driven and interactive EDI/EC; building and operating your own VAN; electronic document acknowledgment and reconciliation; concurrent ANSI X12 and EDIFACT; audit and controls; managing legacy systems; EDI/EC, EDI over Internet; and other emerging technologies; disaster recovery and other contingencies; and archival requirements. COMPANION COURSES: Implementing EDI or Managing EDI/EC Projects. PRE-REQUISITE COURSES: Implementing EDI or equivalent experience. IMPLEMENTING FINANCIAL EDI/EC APPLICATIONS - 16 hours According to a recent UC study, 3 years ago, 8 out of 10 new EDI/EC projects were initiated by purchasing departments. However, during the recent 2 years, 8 out 10 new EDI/EC projects have been initiated by AP, AR, treasury and cash management departments. Based on lessons learned from several large-scale and successful financial EDI/EC implementations, the course is structured to assist treasury, finance, AP, AR and purchasing departments in the successful justification, planning, development, pilot run, full production rollout, and ongoing support of financial EDI/EC projects. Although the course is focused on the financial component of an implementation, there will be substantial discussion on the following subjects: EDI/ACH/EFT services (820, 823, 824, 831, 828, 829, CDX+, CTX, SWIFT and other formats) from Bank of America, Citibank, Chase Manhattan, Union Bank, First Chicago, NationsBank and Sterling Commerce; Consolidated invoices (110, 210, 811, 835, 837, 864 and 980) from Federal Express, UPS, Airborne Express, Rodeway, Pacific Bell, Southwestern Bell, BellSouth, AT&T, and health care institutions; Logistic data (856, 861 and 315) from transportation and freight forwarding companies; Integration with AP/AR, logistics, inventory management and purchasing applications; FEDI over Internet; and, re-engineering implications of Financial EDI/EC implementation. COMPANION COURSES: Implementing EDI or Managing EDI/EC Projects. PRE-REQUISITE COURSES: Implementing EDI or equivalent experience. MANAGING EDI/EC PROJECTS - 8 hours As more business applications make the transition from paper-based to electronic based media, the task of planning, managing, and supporting these projects becomes increasingly complex. This workshop examines and presents project management techniques utilized by companies with successful EDI/EC programs. The workshop is intended for corporate planners, CFOs, ClOs, controllers, AP/AR managers, business process engineering teams, project managers, information processing managers, auditors, systems integration and technical teams, EDI administrators, and EDI coordinators. Guidelines for the following are discussed: budget; schedule; job descriptions; education and training, legal agreement; evaluation and selection of EDI translator, VAN, security tools; selection of banks for EFT applications; identifying EDI applications; documentation; trading partner questionnaire; QA/QC; audit and controls; facilitating EDI implementation; achieving critical mass; outsourcing; integration with legacy systems; managing various tiers of EDI/EC trading partners; managing EDI/EC and other emerging technologies; ANSI X12 and EDIFACT; disaster recovery and other contingencies; and archival requirements. COMPANION COURSES: Implementing EDI or Implementing Financial EDI/EC Applications or Advanced EDI/EC Architecture. PRE-REQUISITE COURSES: Implementing EDI or Implementing Financial EDI/EC Applications or equivalent experience. AUDITING EDI/EC IMPLEMENTATIONS - 8 Hours Most EDI/EC projects are reactive implementations. Consequently, it is the industry norm to stumble into implementations that have been put together by "cut and paste" methodology. It is amazing that "mission critical applications" of major industries and companies increasingly depend on systems that were put together in a haphazard fashion. Moreover, despite EDI being more than 20 years old and therefore more matured than other emerging electronic commerce technologies, most EDI/EC implementations are only standardized at the intercompany data interchange level but revert back to paper-based and proprietary methodology at the intracompany level. With these factors in mind, most EDI/EC implementation have components that maybe classified into four major categories: process improvement opportunities; status quo; ticking timebombs; and, failures. This course is structured to identify, classify and recommend steps in evaluating and managing these components from the following perspectives: methodology, control, security, legal, disaster recovery, and business integration. COMPANION COURSES: Implementing EDI and Managing EDI/EC Projects and Advanced EDI/EC Architecture. PRE-REQUISITE COURSES: Implementing EDI or Managing EDI/EC Projects or Advanced EDI/EC Architecture or equivalent experience. ********************************************************************* PRIMARY INSTRUCTOR: David Paraiso, Jr. Director of Systems Integration -Integrated Technologies Instructor EDI/EC Courses - UC-Berkeley, UC-Irvine, UCLA, U.S. International University-san Diego, University of New Mexico, Electronic Commerce Research Centers (ECRCs), etc. HOTLINE: (800) 949-9278 INTERNET: DAVIDPARAISO@ATTMAIL.COM From owner-ietf-ediint Mon Feb 17 05:11:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id FAA03054 for ietf-ediint-bks; Mon, 17 Feb 1997 05:11:47 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id FAA03050 for ; Mon, 17 Feb 1997 05:11:44 -0800 (PST) Received: from drummond.onramp.net (r37p6.onramp.net [206.50.173.6]) by mailhost.onramp.net (8.8.5/8.6.5) with SMTP id HAA09332; Mon, 17 Feb 1997 07:13:39 -0600 (CST) Message-ID: <33085976.DAA@onramp.net> Date: Mon, 17 Feb 1997 07:13:26 -0600 From: Rik Drummond Reply-To: drummond@onramp.net Organization: Drummond Group X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: tjeffers@dow.com, ietf-ediint@imc.org Subject: Re: Is the goal really "EDI" over the internet? References: <199702132015.MAA07314@proxy1.ba.best.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Our focus resulted from detailed requirement gathering last Feb. on the needs of accomplishing EDI over Internet. These requirements just happen to be applicable to much more than just EDI. Many of our discussions revolve around how to do EDI over Internet... and after much discussion, often are found to be applicable to both EDI and generic messaging issues. If we did not have the EDI focus, we would not be ensuring that EDI's special issues are being address. I think it is gratifying that EDI and messaging have so much in common in the area of requirements. Later, Rik EDIINT WG Chair Mats Jansson wrote: > > Dear Todd: > > What you bring up has been brought up several times by new entrants to > the list, and the answers have always been the same: > > The goals are for the EDI community to be able to adopt internet as > an alternative to VAN/direct connect, in the easiest way possible, while > making sure that all required security services are supported. Thus, > > -by treating the EDI data as "any old EC object", the standard becomes > usable for a wide variety of EDI/EC applications > > -by not requiring any changes within the EDI data object, there is a very > clear line between what the new encryption softwares do, and what the EDI > translator softwares do. For many organizations, the transition simply > involves replacing their communication script with the EC encryption app. > > -by not pre-empting, or being in conflict with X12.58 and EDIFACT security > standards, we are not making things unnecessarily complicated, for organi- > zations that use it, though some of the security services may be redundant. > > So, in closing - we have never been able to pin-point any reasons why > making the standard more targetted to EDI (what does it mean?) would be of > any benefit to anyone except consultants and others making a living off > things being more complicated than they need to. If you have come up with > any such reasons, the list, I'm sure, would love to hear about it. > > Mats J. > Co-editor AS#1 > > At 04:51 PM 2/12/97 -0500, tjeffers@dow.com wrote: > >It appears from reviewing the discussion archives and the draft document > >that EDI standards and practices are completely ignored, and in some > >cases specifically excluded from consideration, when trying to decide > >the best method for implementation or how to proceed. What you are > >proposing is really secure internet transmission of data regardless of > >format (proprietary, EDI, etc..). Should the charter of the working > >group be changed since EDI is really not a consideration? > > > >Regards, > >Todd Jeffers > > > > > _____________________________________________________________ > Mats Jansson, LiNK mjansson@agathon.com > 2317 Broadway, Suite 330 > Redwood City, CA 94063 v: +1-415-780-9039 > http://www.agathon.com f: +1-415-780-9069 From owner-ietf-ediint Tue Feb 18 07:20:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA06724 for ietf-ediint-bks; Tue, 18 Feb 1997 07:20:59 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA06720 for ; Tue, 18 Feb 1997 07:20:56 -0800 (PST) Received: from drummond.onramp.net (r37p6.onramp.net [206.50.173.6]) by mailhost.onramp.net (8.8.5/8.6.5) with SMTP id JAA24668; Tue, 18 Feb 1997 09:22:56 -0600 (CST) Message-ID: <3309C7AE.72C7@onramp.net> Date: Tue, 18 Feb 1997 09:15:58 -0600 From: Rik Drummond X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: edipilot@lists.commerce.net CC: ietf-ediint@imc.org Subject: EDIINT / CNET Commercenet Conference call Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Don't forget to attend our normal commercenet conference call on wedness day at 1:00 pm est. We will be discussion the as#2 draft among other things. Conference Call number: 800 390 5048 How is the testing with verisign progressing? See you there....later rik Agenda Testing group 1: - Status of phase 2 testing - estimated start of phase 3 - Status of Verisign testing Testing group 2: - Estimated start of phase 2 testing - participant confirmation for Test group 2. All participants: - review the final as#2 draft on the ietf-ediint@imc.org list for implemenation issues - Decide which subset to test during phase 3 - marketing plan discussion. From owner-ietf-ediint Tue Feb 18 15:46:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA15290 for ietf-ediint-bks; Tue, 18 Feb 1997 15:46:19 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA15281 for ; Tue, 18 Feb 1997 15:46:01 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA28011; Tue, 18 Feb 1997 15:46:32 -0800 Message-ID: <330A3E22.3BD4@actracorp.com> Date: Tue, 18 Feb 1997 15:41:22 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Dale_Moberg@stercomm.com CC: ietf-ediint@imc.org Subject: Re: Revision of Signed Receipts References: <00024D76.1733@stercomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Dale_Moberg@stercomm.com wrote: > > > > Comments on ietf-ediint-as1 draft : > > 1. I agree that section 5.2.3 should be removed so that the behavior > of downstream EDI processing can be left configurable by the user and > in accordance with detailed trading policies and agreements. > See my previous note to Karen R. This section will be removed. > 2. I think that in section 5.3 the need for the X-Received-MIC > extension field is overkill. The integrity check has already been done > by the receiver when the authentication was done. > It is not a real part of the signing of the receipt by the receiving > partner. It is not needed to correlate the receipt with the original > message because the original-message-id-field already does that. The > information conveyed is not really diagnostic of a problem with the > transport. It is not needed for gatewaying to other message transport > systems, as far as I can tell. Since it could be altered by a > malicious mail relay, it could create confusion about the success of > the transmission if the sending site actually tried to check the value > in its records, assuming such information is kept (and if not, what > would be the point of returning it). Nevertheless, if an application > wanted to send back this information,the information could easily be > incorporated within the RFC 1894 structure within the optional > returned message field. (The hash value is a "part" of the original > message, although buried.) Or it could be made a part of the human > readable report. I guess I don't see what real work the return of this > value is thought to play. I would prefer to see explicit additional > disposition-values such as "authentication-verified" or > "integrity-verified" instead of sending back this value. > The "X-Received-MIC" is needed for non-repudiation purposes. The sender using this field knows what the receiver received. Since this is signed by the receiver, non-repudiation of receipt is achieved. I do agree with you however in that this field does not necessarily need to be an extension field in the MDN. For purposes of EDI we could send it in the third part of the MDN. I feel that specifying a field for this makes it more explicit than returning it in the third part of the MDN. Additional disposition fields can be defined by this working group and I will add any that people think they need. > 3. The semantics of the disposition values needs some clarification. > First, can more than one disposition value be returned or are these > values intended to be mutually exclusive? (Can there be a list > following the header or multiple headers starting "Disposition:" ?) > It is conceivable that trading partners would agree to autoprocess > purchase orders even if authentication failed, for example. > Authentication might fail because a certificate issuer validity > period expired, and while awaiting a reissue, the partners might > decide to continue processsing. Software might even offer users a > configurable option to ignore authentication to allow trading to > continue during a period of merely technical or administrative > difficulty. In that case, a MDN should say "autoprocessed" and > "authentication-failed". I don't see any reason why there can't be a list of dispostion fields, whoever I think it would be simpler to define additional disposition values that encompass such things as autoprocessed and authentication-failed. > Also, the explanation of "autoprocessed" in > the ietf-ediint draft differs from the explanation in the fajman > draft. The fajman draft says only that the user agent successfully > submitted the content for some further processing. The ietf-ediint > draft is less cautious and says that the contents were successfully > processed (by the downstream applications?). I think the ietf-ediint > language for autoprocessed should be aligned with the fajman draft > with no implication about the success of subsequent processing. I will re-word so it is in line with the MDN spcification. >The downstream processing of EDI already has mechanisms for acknowledging > EDI processing if the trading partners agree to use them. > > Some other things I noticed while rereading this document: > > 4. Section 5.4.1 suggests using compression but mentions no > applicable standards for using it. What standards within the > MIME RFCs would specify an interoperable approach? > > 5. The References should be updated to reflect the new MIME RFCs > 2045 to 2049. One thing I noticed in these new RFCs is that the CRLF > before a boundary marker is considered part of the boundary marker. So > when using a binary content-transfer-encodings within multipart/signed > structures within the signed-then-enveloped EDI, it appears that > a CRLF is to be appended to the binary stream and then the boundary > marker appended (?). In general, because any string can possibly occur > within a binary part (especially if compressed), it will be hard to > guarantee that a boundary will work unless the binary is screened > against the boundary before packaging. I think that the > content-transfer-encoding field for a binary identity transfer > encoding should have a mandatory parameter of the length of the binary > field or else some other encoding should be used. Of course, you can > always just hope that your marker is nowhere in the 20 MB file most of > the time :-). I need to look into these RFCs a bit more. As far as compression is concerned, AS#1 recommends the use of compression over using the message partial. It is not recommending any particular compression algorithm, but does recommend the sequence of when compression should be done. Should the workgroup and the AS#1 require use of any particular compression algorithm? > > Bye, > > Dale Moberg From owner-ietf-ediint Wed Feb 19 11:33:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA01323 for ietf-ediint-bks; Wed, 19 Feb 1997 11:33:13 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA01319 for ; Wed, 19 Feb 1997 11:33:10 -0800 (PST) Received: from drummond.onramp.net (r37p3.onramp.net [206.50.173.3]) by mailhost.onramp.net (8.8.5/8.6.5) with SMTP id NAA11675; Wed, 19 Feb 1997 13:35:10 -0600 (CST) Message-ID: <330B546C.7B23@onramp.net> Date: Wed, 19 Feb 1997 13:28:44 -0600 From: Rik Drummond X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: edipilot@lists.commerce.net CC: ietf-ediint@imc.org Subject: CNET Minutes for 19 Feb 97 Conf. Call Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk - Rik and Chuck will check to see how to chose the boundary string around binary data with ietf protocol experts. - Rik will redo the test plan for phase three to reflect the new changes to the as#2 document - Next week we will discuss the test-cases derived from the as#2 document - Next week will discuss how to start phase 1 for test-group-2 - Harbinger, Atlas and DoD (test-group-2) should be ready to start phase 1 in two weeks from last Monday - Test-group-1 will finish phase 2 testing with multipart/signed starting in two weeks - Test-group-1 will start phase 3 testing March 11, 1997 Next conference call: 26 Feb 97, 1:00 pm est. Number is 800 390 5048 Great Job! Enjoy it every time ..... Later ... Rik Test-group-1 Status (Testing of EDIINT AS#2 Document Recommendations) Date: 19th February 1997 Participants: 1. Tony Hansen, AT&T 2. Jun Ding, Actra 3. Ruben Iversen, Dannet (withdrew 5'th February from test-group-1) 4. Graham Helliar, Digital 5. Pedro Chiang, Premenos 6. Dale Moberg, Sterling Tests are: key : A --- B , not done A <-- B , successfully done from B to A A |-- B , unsuccessful or unacknowledged receipt from B to A A <-> B , successfully done both ways A X-- B , test abandoned due to A's withdrawl from test. A - Exchange certificates and ackowledge validity 1 |-| 2 1 |-| 4 1 |-> 5 1 |-> 6 2 <-> 4 2 <-> 5 2 <-> 6 4 <-> 5 4 <-> 6 5 <-> 6 5 - SMTP(MIME(RFC1767(PO), 5 MB WP File)) 1 --- 2 1 --- 4 1 --- 5 1 --- 6 2 <-> 4 2 --- 5 2 <-> 6 4 <-> 5 4 <-> 6 5 <-> 6 6 - Signed (pkcs) 1 --- 2 1 --- 4 1 --- 5 1 --- 6 2 <-> 4 2 <-> 5 2 <-> 6 4 <-> 5 4 <-> 6 5 <-> 6 7 - Enveloped 1 --- 2 1 --- 4 1 --> 5 1 --- 6 2 <-> 4 2 <-> 5 2 <-> 6 4 <-> 5 4 <-> 6 5 <-> 6 8 - Signed then Enveloped (multipart)= 1 --- 2 1 --- 4 1 --- 5 1 --- 6 2 --- 4 2 --- 5 2 --- 6 4 --- 5 4 --- 6 5 --- 6 From owner-ietf-ediint Thu Feb 20 06:51:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA13281 for ietf-ediint-bks; Thu, 20 Feb 1997 06:51:24 -0800 (PST) Received: from ns.stercomm.com (ns.stercomm.com [199.3.19.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id GAA13277 for ; Thu, 20 Feb 1997 06:51:21 -0800 (PST) Received: ns.stercomm.com id AA00437; Thu, 20 Feb 1997 09:47:16 -0500 Mime-Version: 1.0 Date: Thu, 20 Feb 1997 09:52:38 -0500 Message-Id: <000273AE.1733@stercomm.com> From: Dale_Moberg@stercomm.com Subject: *** CNET Revision of Signed Receipts on binary issue To: chucks@actracorp.com (Chuck Shih), drummond@onramp.net, ietf-ediint@imc.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ediint@imc.org Precedence: bulk Hi Chuck and Rik, This is just to clarify a proposal that could help in implementing the EDI-INT RFC. In section 6.2, RFC 2045, there is discussion about how the binary Content-Transfer-Encoding is not really valid in Internet mail. Of course, this ignores the s/mime literature and the good point that when data is encrypted, it would be an efficiency win to avoid an "inner transfer encoding". I just want to make certain that this efficiency win does not become an interoperability pitfall and introduce other inefficiencies. When we sign and then encrypt, we will first generate a multipart/signed. That means a Mime boundary element will need to be defined to delimit the mime parts. In principle, mixing binary data with delimiters that are themselves octet strings is not so hot as software engineering. The more orthodox approach is to use a length & data approach to this problem. It will also be a big win because block reads/writes can be used to handle the I/O of the EDI data, and there will be no need to process the EDI line by line (there are not necessarily lines in binary, and not usually if the data is edifact) or to process it by a substring search algorithm to check that the boundary string is absent. My suggestion then is that we have something like: Content-Type: application/edifact; octets=NNNN Content-Transfer-Encoding: binary Content-Disposition: attachment Now if you want a different parameter name than "octets," fine. While putting the parameter after the content-transfer-encoding make sense, it conflicts with the stated grammer in 2045 (see BNF for encoding; but possibly an "ietf-token" could be defined to handle this case, however.) So to avoid a conflict with the 2045 grammar, it might be better to mandate having the parameter octets=NNNN after the Content-type field "application/edi*". I support requiring using the content-transfer-encoding binary only if some additional requirement for length is required. The boundary will still have to be there, and an attempt should be made to check that it is at the end of the block and signal an error if it is not. But a matching delimiter might happen to occur previously. This will not bother any User Agent unless it already has the capability of unpacking an S/MIME envelope. Possibly the S/MIME draft dusse group should be consulted or perhaps just the people who put out the S/MIME interoperability guideline to see if they want to suggest a solution to this problem since they seem to be suggesting using "binary". My point is that the headers for this multipart, if we are going to require binary, need to have a length parameter, and it should be mandatory for EDI use. (I think a length parameter should be available anywhere binarygets used, if it ever gets used, but I don't want to get into that brawl.) The only conflict I see is that by not checking for the dash-boundary in the data stream we almost somewhere would eventually clash with a remark in Appendix A, RFC 2046 which says that the dash-boundary should not occur anywhere in the body part (see the BNF for body-part). But this would only be for a mime-part that is enveloped; maybe that will be ok. An alternative to all this would be to analyze the character sets in edifact or X12 data and try to find some string never in that data (like one can do for quoted printable and base64). But if compression gets used, and I think we should plan to make this possible, then the same problem will come back for transferring the compressed data as binary. From owner-ietf-ediint Thu Feb 20 13:48:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA17900 for ietf-ediint-bks; Thu, 20 Feb 1997 13:48:04 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA17896 for ; Thu, 20 Feb 1997 13:48:00 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA04846 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Thu, 20 Feb 1997 13:41:11 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA05856; Thu, 20 Feb 97 13:18:29 PST Date: Thu, 20 Feb 97 13:18:29 PST From: carl@chage.com (Carl Hage) Message-Id: <9702202118.AA05856@slick.chage.com> To: ietf-ediint@imc.org Subject: Re: *** CNET Revision of Signed Receipts on binary issue References: <000273AE.1733@stercomm.com> Organization: C. Hage Associates, Sunnyvale, CA Sender: owner-ietf-ediint@imc.org Precedence: bulk Dale_Moberg@stercomm.com wrote: : In section 6.2, RFC 2045, there is discussion about how the binary : Content-Transfer-Encoding is not really valid in Internet mail. That means you aren't supposed to send binary data after the RFC822 headers. Binary is still valid as a MIME type, which is used to wrap data to be signed and later encoded. The data is later base64 encoded after encryption. : My suggestion then is that we have something like: : : Content-Type: application/edifact; octets=NNNN : Content-Transfer-Encoding: binary : Content-Disposition: attachment Sorry, but life is imperfect and we have to live with less than ideal in the world of standards. The MIME RFCs cannot be changed, unless there is no possible way to meet a requirement. (The current MIME does not define a means to define a compression protocol, for example, other than the MIME headers used in HTTP.) BTW, there is a "Content-Length:" header, which means the same as octets, used in some places. Though a length might be more convienient for binary data, the MIME spec cannot be changed just for convienience. There are two approaches: 1. Generate a random number where the probability of failure is negligible over the life of the universe. (Be careful of infinite improbability drives, though.) In other words, the probability of a boundary marker failure is << other failures which are expected. 2. Scan the binary file for a conflict, e.g. while computing the MIC. The efficiency gain of block I/O is negligible, compared to the processing required for encryption and signing, or even all the other overhead in transmission. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Sun Feb 23 02:36:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id CAA17585 for ietf-ediint-bks; Sun, 23 Feb 1997 02:36:15 -0800 (PST) Received: from dv.kp.dlr.de (dv.kp.dlr.de [129.247.97.1]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id CAA17581 for ; Sun, 23 Feb 1997 02:36:10 -0800 (PST) Received: from sunco.co.kp.dlr.de (sunco.co.kp.dlr.de [129.247.110.5]) by dv.kp.dlr.de (8.8.5/8.8.5) with SMTP id LAA38388 for ; Sun, 23 Feb 1997 11:38:26 +0100 Received: from crazy ([194.175.71.38]) by sunco.co.kp.dlr.de (4.1/SMI-4.1) id AA12975; Sun, 23 Feb 97 11:22:32 +0100 Message-Id: <3.0.1.32.19970223114158.0081dd20@sunco.co.kp.dlr.de> X-Sender: andy@sunco.co.kp.dlr.de X-Mailer: Windows Eudora Light Version 3.0.1 beta 7 (32) Date: Sun, 23 Feb 1997 11:41:58 +0100 To: ietf-ediint@imc.org From: "Andy Pieniazek ( Bonn / DE )" Subject: EC Conference in Bonn, April 7-9 1997 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ediint@imc.org Precedence: bulk Dear Ladies and Gentlemen, I apologise in advance for possible multiple posting of this message, but I would like to draw your attention to the upcoming event that is organised by the European Commission on behalf of the European G7 partners. The first Annual Conference of the G7 Project "A Global Marketplace for SMEs"will be held in Bonn, Germany on April 7th - 9th 1997. The sponsors include the German Ministry of Economics, City of Bonn and The State of Nordrhein-Westphalen, IBM, German Telekom, Thomnet/France, ECOM/Japan, Hewlett-Packard, Oracle, Lotus and SNI/Siemens/Nixdorf. The conference aims to raise the interest of SMEs in the fast growing market of electronic commerce and stimulate the debate in the industry and policy-making on electronic commerce. A series of major announcements, political as well as business related, are already projected for the event ( 'Electronic Commerce Europe' initiative). The conference will consist of the series of plenary sessions, workshops and discussion fora and will be enhanced by the exhibition related to the subject. It is planned that the exhibition will be opened to general public on all days. Additional events both related to the conference ( Research Meets Practise) and spouse programmes are being planned as well. The conference will be attended by international audience ( 400-500 ) from Europe, USA, Canada and Japan and other countries, including decision makers from both state and international organisations ( including Mr. Rexroth, German Minister for Economic Affairs, Mr. Monti, European Commissioner ) and major players from the commercial/industrial sector. The organisers expect that the conference will become an important step toward improving the participation of the SMEs in global trade and the information’s society. For more information contact the organising company: Ms Sandra Herms Project manager D3 Group GmbH Oxfordstr. 2 53111 Bonn, Germany Tel: +49-228-9853888 Fax: +49-228-9853889 Email: g7@empirica.de http://www.g7ec.de The organisers will be also very happy to talk to all Electronic Commerce partners not only from G7 members countries about attending the conference, possible participation in exhibition ( success stories, best practice ), delivering a seminar but also about attractive sponsorship opportunities.We would also appreciate if you passed these message around and possibly place some reference on your web site. With best wishes D3, Group GmbH Andy Pieniazek Director From owner-ietf-ediint Mon Feb 24 12:13:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA04266 for ietf-ediint-bks; Mon, 24 Feb 1997 12:13:40 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA04262 for ; Mon, 24 Feb 1997 12:13:37 -0800 (PST) Received: from drummond.onramp.net (r37p23.onramp.net [206.50.173.23]) by mailhost.onramp.net (8.8.5/8.6.5) with SMTP id OAA12946 for ; Mon, 24 Feb 1997 14:16:03 -0600 (CST) Message-ID: <3311F6F6.10B1@onramp.net> Date: Mon, 24 Feb 1997 14:15:50 -0600 From: Rik Drummond Reply-To: drummond@onramp.net Organization: Drummond Group X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ietf-ediint@imc.org Subject: EDIINT - A Quick Status Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Chuck and Mats are working hard on the modifications to the AS#1 and AS#2. They must be complete in the next couple of weeks, so that they can be presented at the next IETF meeting in April. Since, the last version, almost, all of the work has been on the MDN (signed receipt) with rearrangement of content of between AS#1 and AS#2 as specified in our last IETF meeting. I think we are getting close!!! Later, Rik From owner-ietf-ediint Mon Feb 24 11:15:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA03451 for ietf-ediint-bks; Mon, 24 Feb 1997 11:15:02 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA03443 for ; Mon, 24 Feb 1997 11:14:54 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA12533; Mon, 24 Feb 1997 11:15:46 -0800 Message-ID: <3311E7A7.7704@actracorp.com> Date: Mon, 24 Feb 1997 11:10:31 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ietf-ediint@imc.org, edipilot@commerce.net Subject: Revision of MDN Section of AS#1 Content-Type: multipart/mixed; boundary="------------476D2328774C" Sender: owner-ietf-ediint@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------476D2328774C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have attached a revision of the MDN section of AS#1 to reflect the following: 1). Deleted section 5.2.3 on how to process the EDI transactions down stream when a signed-receipt can not be honored. 2). Defined a new disposition qualifier field that allows trading partners to furthur qualify the disposition-field value. 3). Update the autoprocessed dispostion-field value to reflec the definition in the MDN specification. 4). Added the explicit order in which compression should be done when it is used with this specification. 5). Changed the name of the extension field from "X-received-MIC" to "X-received-content-MIC". (If anyone can think of a better name please post ASAP.) Did I miss anything? Please review the changes and send me contents as soon as possible. I am trying to get a version of the AS#1 that we can post within the next 2 weeks. Thanks. --------------476D2328774C Content-Type: text/plain; charset=us-ascii; name="assend.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="assend.txt" INTERNET DRAFT Mats Jansson, LiNK draft-ietf-ediint-as1-03.txt Chuck Shih, Actra Nancy Turaj, Mitre Corp. Rik Drummond, Drummond Group 10 January, 1997 MIME-based Secure EDI 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 document describes how to securely exchange EDI documents using MIME and public key cryptography. Feedback Instructions: If you want to provide feedback on this draft, follow these guidelines: -Send feedback via e-mail to mjansson@agathon.com, with "AS#1" in the Subject field. -Be specific as to what section you are referring to, preferably quoting the portion that needs modification, after which you state your comments. -If you are recommending some text to be replaced with your suggested text, again, quote the section to be replaced, and be clear on the section in question. -If you are questioning fundamental methods, bring the issue to the ediint list for discussion. To enter/follow the discussion, you need to subscribe at ietf-ediint@imc.org. Table of Contents 1. Introduction 2. Overview 2.1 Purpose of a security guideline for MIME EDI 2.2 Definitions 2.2.1 Terms 2.2.2 The secure transmission loop 2.2.3 Definition of receipts 2.3 Assumptions 2.3.1 EDI process assumptions 2.3.2 Flexibility assumptions 3. Referenced RFCs and their contribution 3.1 RFC 821 SMTP [7] 3.2 RFC 822 Text Message Format [3] 3.3 RFC 1521 MIME [1] 3.4 RFC 1847 MIME Security Multiparts [6] 3.5 RFC 1892 Multipart/report [9] 3.6 RFC 1767 EDI Content [2] 3.7 RFC 2015 PGP/MIME [4] 3.8 Internet draft (fajman): Message Disposition Notification [5] 3.9 Internet draft (dusse): - S/MIME Specification [8] 4. Structure of an EDI MIME message - Applicability 4.1 Introduction 4.2 Structure of an EDI MIME message - PGP/MIME 4.2.1 No encryption, no signature 4.2.2 No encryption, signature 4.2.3 Encryption, no signature 4.2.4 Encryption, signature 4.3 Structure of an EDI MIME message - S/MIME 4.3.1 No encryption, no signature 4.3.2 No encryption, signature 4.3.3 Encryption, no signature 4.3.4 Encryption, signature 5. Receipts 5.1 Introduction 5.2 Requesting a signed receipt 5.3 Message Disposition Notification Format 5.4 Message Disposition Notification Processing 5.4.1 Large File Processing 5.4.2 Example 6. Public key certificate handling 6.1 Near term approach 6.2 Long term approach 7. Authors' Addresses 8. References 1. Introduction The authors would like to extend special thanks to Carl Hage for providing the team with valuable, and very thorough feedback. Without participants like Carl, these efforts become hard to complete in a way useful to the users of the technology. Previous work on Internet EDI focused on specifying MIME content types for EDI data ([2] RFC 1767). This Applicability Statement expands on RFC 1767 to specify use of a comprehensive set of data security features, specifically data privacy, data integrity/authenticity, non-repudiation of origin and non- repudiation of receipt. This draft recognizes contemporary RFCs and Internet drafts and is attempting to "re-invent" as little as possible. With an enhancements in the area of "receipts", as described below (3.1.8), secure Internet MIME based EDI can be accomplished by using and complying with the following RFCs and drafts: -RFC 821 SMTP -RFC 822 Text Message Formats -RFC 1521 MIME -RFC 1767 EDI Content Type -RFC 1847 Security Multiparts for MIME -RFC 1892 Multipart/Report -Internet draft: Message Disposition Notification (fajman) -RFC 2015 MIME/PGP (elkins) -Internet draft: S/MIME Specification (dusse) Our intent here is to define clearly and precisely how these are pieced together and what is required by user agents to be compliant with this Applicability Statement. 2. Overview 2.1 Purpose of a security guideline for MIME EDI The purpose of these specifications is to ensure interoperability between EDI user agents, invoking some or all of the commonly expected security features. This standard is also NOT limited to strict EDI use, but applies to any electronic commerce application where business data needs to be exchanged over the Internet in a secure manner. 2.2 Definitions 2.2.1. Terms EDI Electronic Data Interchange EC Electronic Commerce Receipt The functional message that is sent from a receiver to a sender to acknowledge receipt of an EDI/EC interchange Signed Receipt Same as above, but with a digital signature Message Disposition The way by which a receipt or a signed Notification (MDN) receipt is accomplished within Internet Messaging. Non-repudiation of NRR is a "legal event" that occurs when the Receipt (NRR) original sender of an EDI/EC interchange has verified the signed receipt coming back from the receiver. NRR IS NOT a functional or a technical message. PGP/MIME Digital envelope security based on the Pretty Good Privacy (PGP) standard (Zimmerman), integrated with MIME Security Multiparts [6]. S/MIME A protocol for adding cryptographic signature and/or encryption services to Internet MIME messages. 2.2.2 The secure transmission loop The functional requirements document, [9] "Requirements for Inter- operable Internet EDI" (can be found at www.ietf.org),provides extensive information on EDI security and the user/business related processes surrounding the need for and use of EDI security. In this document, it is assumed that the reader is familiar with the requirements document. This document's focus is on the formats and protocols for exchanging EDI content that has had security applied to it using the Internet's messaging transport. The "secure transmission loop" for EDI involves one organization sending a signed and encrypted EDI interchange to another organization, requesting a "signed receipt", followed later by the receiving organization sending this "signed receipt" back to the sending organization. In other words, the following transpires: -The organization sending EDI/EC data encrypts the data and provides a digital signature, using either PGP/MIME or S/MIME. In addition, they request a "signed receipt". -The receiving organization decrypts the message and verifies the signature, resulting in verified integrity of the data and authenticity of the sender. -The receiving organization then sends a "signed receipt" in the form of a signature over the hash from the previous step. The above describes functionality which if implemented, would satisfy all security requirements. This specification, however, leaves full flexibility for users to decide the degree to which they want to deploy those features with their EDI trading partners. 2.2.3 Definition of receipts The term used for both the functional activity and message for acknowledging receipt of an EDI/EC interchange is "receipt", or "signed receipt". The first term is used if the acknowledgment is for an interchange resulting in a receipt which is NOT signed. The second term is used if the acknowledgment is for an interchange resulting in a receipt which IS signed. The rule is: If a receipt is requested, explicitly specifying that the receipt should be signed, then the receipt indeed has to be returned with a signature. If signature is not explicitly requested, all bets are off. This is consistent with Fajman's MDN draft. A term often used in combination with receipts is "Non-repudiation of Receipt (NRR). NRR refers to a legal event which occurs only when the original sender of an interchange has verified the sender and content of a "signed receipt". Note that NRR is not possible without signatures. 2.3 Assumptions 2.3.1 EDI process assumptions -Encrypted object is an EDI Interchange This specification assumes that a typical EDI interchange is the lowest level object that will be subject to security features. In ANSI X12, this means anything between, and including segments ISA and IEA. In EDIFACT, this means anything between, and including, segments UNA/UNB and UNZ. In other words, the EDI interchanges including envelope segments remain intact and unreadable during secure transport. -EDI envelope headers are encrypted Congruent with the above statement, EDI envelope headers are NOT visible in the MIME package. In order to optimize VAN-to- Internet routing, work may need to be done in the future to define ways to pull out some of the envelope information to make them visible, however, this specification does not go into any detail on that. -X12.58 and UN/EDIFACT security considerations The most common EDI standards, ANSI X12 and EDIFACT, have defined internal provisions for security. X12.58 is the security mechanism for ANSI X12 and AUTACK provides security for EDIFACT. This specification DOES NOT dictate use or non-use of these security standards. They are both fully compatible, though possibly redundant, with this specification. 2.3.2 Flexibility assumptions -Encrypted or un-encrypted data This specification allows for EDI message exchange where the EDI data is either un-protected or protected by means of encryption. -Signed or un-signed data This specification allows for EDI message exchange with or without digital signature of the original EDI transmission. -Use of receipt or not This specification allows for EDI message transmission with or without a request for receipt notification. If a signed receipt notification is requested, however, a signature is required as part the returned receipt. -Formatting choices This specification defines use of two methods for formatting EDI contents that have security applied to it: -PGP/MIME -S/MIME This specification relies on the guidelines set forth in the RFC 2015, as reflected in [4] MIME Security with Pretty Good Privacy (PGP), and Internet draft [8] S/MIME Specification from RSA Security, Inc. (dusse) Compliance with this specification dictates that AT LEAST one of these methods is supported. -Hash function, message digest choices When signature is used, unless specified otherwise by the chosen method (PGP/MIME or S/MIME), the SHA1 checksum hash function is recommended. In summary, the following eight permutations are possible, in any given trading relationship: (1) Sender sends un-encrypted data, does NOT request a receipt. (2) Sender sends unencrypted data, requests a receipt. Receiver sends back a receipt. (3) Sender sends encrypted data, does NOT request a receipt. (4) Sender sends encrypted data, requests a receipt. Receiver sends back a receipt. (5) Sender sends signed data, does NOT request a signed receipt. (6) Sender sends signed data, requests a signed receipt. Receiver sends back a signed receipt. (7) Sender sends encrypted and signed data, does NOT request a signed receipt. (8) Sender sends encrypted and signed data, requests a signed receipt. Receiver sends back a signed receipt. NOTE: Users can choose any of the eight possibilities, but only example (8) offers the whole suite of security features described in the "Secure transmission loop" above. NOTE: A request for receipt that is signed, MUST result in a signed receipt. A request for receipt without signature MUST result in an un-signed receipt. 3. Referenced RFCs and their contribution 3.1 RFC 821 SMTP [7] This is the core mail transfer standard that all MTAs need to adhere to. 3.2 RFC 822 Text Message Format [3] Defines message header fields and the parts making up a message. 3.3 RFC 1521 MIME [1] This is the basic MIME standard, upon which all MIME related RFCs build, including this one. Key contributions include definition of "content type" and sub-type "multipart", in addition to encoding guidelines, which establish 7-bit US-ASCII as the lowest common denominator used. 3.4 RFC 1847 MIME Security Multiparts [6] This document defines security multiparts for MIME: multipart/encrypted and multipart/signed. 3.5 RFC 1892 Multipart/report [10] This RFC defines the use of Multipart/report content type, something that the MDN draft (fajman) relies on for the receipt functionality. 3.6 RFC 1767 EDI Content [2] This RFC defines the use of content type "application" for ANSI X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and mutually defined EDI (application/EDI-Consent). 3.7 RFC 2015 PGP/MIME [4] This RFC defines the use of content types "multipart/encrypted", "multipart/signed", "application/pgp encrypted" and "application/pgp-signature" for defining MIME PGP content. 3.8 Internet draft (fajman): Message Disposition Notification [5] This Internet draft defines how a message disposition notification (MDN) is requested, and the structure of the MDN. NOTE: This is the only specification we were not able to take "as is". Extension field-names beginning with "X-" will not be defined as a standard field. MDN field names not beginning with "X- " need to be registered with the Internet Assigned Numbers Authority (IANA) and described in an RFC. The X-Received-MIC field described in this document will be registered with IANA. 3.9 Internet draft (dusse): S/MIME Message Specification [8] This specification describes how MIME shall carry PKCS7 signature and envelope information. 4. Structure of an EDI MIME message - Applicability 4.1 Introduction The below structures are described hierarchically in terms of which RFC's are applied to form the specific structure. For details of how to code in compliance with all RFC's involved, turn directly to the RFC's referenced. The "requirements document" has several examples described in an Appendix for those interested. Also, these structures describe the initial transmission only. Receipts, and requests for receipts are handled in section 5. 4.2 Structure of an EDI MIME message - PGP/MIME 4.2.1 No encryption, no signature -RFC822/1521 -RFC1767 (Application/EDIxxxx) 4.2.2 No encryption, signature -RFC822/1521 -RFC1847 (Multipart/signed) -RFC2015 (application/pgp-signature) -RFC1767 (Application/EDIxxxx) -PGP/MIME Signature 4.2.3 Encryption, no signature -RFC822/1521 -RFC1847 (Multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version 1" -RFC1767 (Application/EDIxxxx) (encrypted) 4.2.4 Encryption, signature -RFC822/1521 -RFC1847 (Multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version 1" -RFC1847 (Multipart/signed) (encrypted -RFC2015 (application/pgp-signed) (encrypted) -RFC1767 (application/EDIxxxx) (encrypted) -PGP/MIME Signature (encrypted) 4.3 Structure of an EDI MIME message - S/MIME 4.3.1 No encryption, no signature -RFC822/1521 -FC1767 (Application/EDIxxxx) 4.3.2 No encryption, signature -RFC822/1521 -RFC1847 (Multipart/signed) -Draft (dusse) (application/x-pkcs7-mime) -RFC1767 (Application/EDIxxxx) -S/MIME Signature 4.3.3 Encryption, no signature -RFC822/1521 -Draft (dusse) (application/x-pkcs7-mime) -RFC1767 (Application/EDIxxxx) (encrypted) 4.3.4 Encryption, signature -RFC822/1521 -Draft (dusse) (application/x-pkcs7-mime) -RFC1847 (Multipart/signed) (encrypted -Draft (dusse) (application/x-pkcs7-mime) (encrypted) -RFC1767 (application/EDIxxxx) (encrypted) -S/MIME Signature (encrypted) 5. Receipts 5.1 Introduction In order to provide a non-repudiation of receipt (NRR) or signed receipt, a message disposition notification (MDN) as specified by draft- ietf-receipt-mdn-02.txt is to be implemented by a receiving trading partner's UA (User Agent). The message disposition notification is then digitally signed and returned to the sending trading partner as part of a multipart/signed content. The required support for signed receipts when doing Internet EDI is as follows: 1). Create a multipart/report; report-type = disposition-notification. 2). Calculate the MIC on the message disposition notification. 3). Digitally sign the MIC. 4). Create a multipart/signed content with the message disposition notification as the first body part, and the signed MIC calculated on the message disposition notification as the second body part. 5). Return the signed receipt to the sending trading partner. The signed receipt is used to notify a sending trading partner that requested the signed receipt that: 1). The receiving trading partner acknowledges receipt of the sent EDI Interchange. 2). If the sent message was signed, then the receiving trading has authenticated the sender of the EDI Interchange. 3). If the sent message was signed, then the receiving trading partner has verified the integrity of the received EDI Interchange. Regardless of whether the EDI Interchange was sent in S/MIME or PGP/MIME format, the receiving trading partner's UA must provide the following basic processing: 1). If the sent EDI Interchange is encrypted, then the encrypted symmetric key and initialization vector (if applicable) is decrypted using the receiver's private key. 2). The decrypted symmetric encryption key is then used to decrypt the EDI Interchange. 3). The receiving trading partner authenticates signatures in a message using the sender's public key. The authentication algorithm performs the following: a). The message integrity check (MIC or Message Digest), is decrypted using the the sender's public key. b). A MIC on the signed contents (the MIME header and encoded EDI object, as per RFC1767) in the message received is calculated using the same one-way hash function that the sending trading partner used. c). The MIC extracted from the signature is compared with the MIC calculated using the same one-way hash function that the sending trading partner used. 4). The receiving trading partner formats the MDN and sets the calculated MIC into the "X-received-content-MIC" extension field. 5). The receiving trading partner creates a multipart/signed MIME message according to RFC 1847. 6). The MDN is the first part of the multipart/signed message, and the digital signature is created over this MDN, including its MIME headers. 7). The second part of the multipart/signed message contains the digital signature. The "protocol" option specified in the multipart/signed is as follows: S/MIME: protocol = "application/pkcs-7-signature" PGP/MIME: protocol = "application/pgp-signature" 8). The signature information is formatted according to S/MIME or PGP/MIME specifications. The EDI Interchange and the RFC 1767 MIME EDI content header, can actually be part of a multi-part MIME content-type. When the EDI Interchange is part of a multi-part MIME content-type, the MIC is calculated across the entire multi-part content, including the MIME headers. The multi-part MIME content that contains the EDI Interchange is then enveloped in either S/MIME or PGP/MIME format. The signed MDN, when received by the sender of the EDI Interchange can then be used by the sender: 1). As an acknowledgment that the EDI Interchange sent, was delivered and acknowledged by the receiving trading partner. The receiver does this by returning the original message id of the sent message in the signed MDN. 2). As an acknowledgment that the integrity of the EDI Interchange was verified by the receiving trading partner. The receiver does this by returning the calculated MIC of the received EDI Interchange (and 1767 MIME headers) in the "X-received-content-MIC" field of the signed MDN. 3). As an acknowledgment that the receiving trading partner has authenticated the sender of the EDI Interchange. 4). As a non-repudiation of receipt when the signed MIC calculated over the MDN, is successfully decrypted by the sender with the receiving trading partner's public key. 5.2 Requesting a signed receipt Message Disposition Notifications are requested as per draft-ietf- receipt-mdn-02.txt, "An Extensible Message Format for Message Disposition Notification". A request that the receiving user agent issue a message disposition notification is made by placing the following header into the message to be sent: mdn-request-header = "Disposition-notification-to" ":" mail-address The mail-address field is specified as an RFC 822 user@domain address, and is the return address for the message disposition notification. In addition to requesting a message disposition notification, a message disposition notification that is digitally signed, or what has been referred to as a signed receipt, can be requested by placing the following in the message header following the "Disposition-notification-to" line: Disposition-notification-options = "Disposition-notification-options" ":" dispostion-notification-parameters Where disposition-notification-parameters = signed-receipt-protocol=O, ; The currently supported values for are "x-pkcs7-signature", for the S/MIME detached signature format, or "pgp-signature", for the pgp signature format. An example of a formatted options line would be as follows: Disposition-notification-options: signed-receipt-protocol=O, x-pkcs7-signature; The semantics of the "signed-receipt-protocol" parameter is as follows: 1). The "signed-receipt-protocol" parameter is used to request a signed receipt from the recipient trading partner. The "signed-receipt-protocol" parameter also specifies the format in which the signed receipt should be returned to the requestor. The MIC algorithm and signature algorithm used in formulating the signed receipt are agreed to in the trading partner relationship. The actual algorithms used in the signed receipt are always returned as part of the signed receipt. 2). The "importance" attribute of "O" is defined in the MDN draft and has the following meaning: Parameters with an importance of "O" permit a UA that does not understand the "signed-receipt-protocol" parameter to still generate a MDN in response to a request for a MDN. A UA that does not understand the "signed-receipt-protocol" parameter, will obviously not return a signed receipt. The importance of "O" is used for the signed receipt parameters because it is desirable that an MDN be returned to the requesting trading partner even if the recipient could not sign it. The returned MDN will contain information on the dispostion of the message as well as why the MDN could not be signed. See the dispostion and extension fields in section 5.3 for more information. Within an EDI trading relationship, if a signed-receipt is expected and is not returned, then the validity of the transaction is up to the trading partners to resolve. In general, if a signed-receipt is required in the trading relationship and is not received, the transaction will likely not be considered valid. 3). When a request for a signed receipt is made, but there is an error in processing the contents of the message, a signed receipt should still be returned. The non-repudiation of receipt should still be honored, though the transaction itself is not valid. The reason for why the contents could not be processed should still be set in the "disposition-field". 4). A new extension field that furthur qualifies the "disposition-field" is | defined by this specification. The field "X-disposition-qualifier-field" | is used to convey additional error or status information on the value | specified in the "disposition-field". | Situations arise in EDI where even if a trading partner cannot be | authenticated correctly, the trading partners still agree | to continue processing the EDI transactions. Transaction reconciliation | is done between the trading partners at a later time. The | "X-disposition-qualifier-field" allows for qualifying an "authentication-failed" | disposition value with a "X-disposition-qualifier-field" of "autoprocessed" for | instance. This use of a dispostion qualifier value would convey in the above | example, that even though authentication failed, the receiving trading | partner still processed the received EDI transactions. | 5.3 Message Disposition Notification Format The format of a message disposition notification is as specified in draft-ietf-receipt-mdn-02.txt. For use in EDI over the Internet the following format will be used: - content-type - per RFC1892 and the ietf-receipt-mdn specification - reporting-ua-field - per ietf-receipt-mdn specification - mdn-gateway-field - per ietf-receipt-mdn specification - original-recipient-field - per ietf-receipt-mdn specification - final-recipient-field - per ietf-receipt-mdn specification - original-message-id-field - per ietf-receipt-mdn specification - disposition-field - for EDI use: "notprocessed" - The received content(s) was not processed. "autoprocessed" - The message has been processed automatically | in some manner (e.g., printed, faxed, forwarded, gatewayed) | in response to some user request made in advance, without | being displayed to the user. The user may or may not see | the message later. "decryption-failed" - The receiver could not decrypt the contents. "authentication-failed" - The receiver could not authenticate the sender. "integrity-check-failed" - The receiver could not verify content integrity. - extension field - the following extension fields will be added in order to support signed-receipts for RFC 1767 MIME content types and multi-part MIME content types that include RFC 1767 MIME content types. The "X-disposition-qualifier-field" is used to furthur qualify the value | in the "disposition-field". The value of the "X-disposition-qualifier-field" | is a trading partner mutally agreed to value. The semantics of the qualifying | value upon the "dispostion-field" value is up to the trading partners to | define and interpret. | - extension field = "X-" "disposition-qualifier-field" ":" value | The "X-received-content-MIC" extension field is set when the integrity of the received message is verified. The MIC or message integrity check, is defined as a result of a one-way hash function applied to the received RFC 1767 MIME content, or a multi-part MIME content containing RFC 1767 MIME content. The MIC is applied to the MIME headers as well as the content. This field is set only when the contents of the message are processed successfully. This field is used in conjunction with the receiver's signature on the MDN, in order for the sender to verify non-repudiation of receipt. - extension field = "X-" "received-content-MIC" ":" MIC The "X-signed-receipt-disposition" extension field is set when a request for a signed receipt is made by the sender, but cannot be returned by the receiver. - extension field = "X-" "signed-receipt-disposition": signed-receipt-disposition where signed-receipt-disposition is: "unsupported-format" - A request for a signed receipt cannot be returned because the requested format is not supported. "unexpected-error" - A catch-all for errors that prevent a signed receipt from being returned when it has been requested. 5.4 Message Disposition Notification Processing 5.4.1 Large File Processing Large EDI Interchanges sent via SMTP can be automatically fragmented by some message transfer agents. A subtype of message, "partial", is defined in RFC 1521 to allow large objects to be delivered as separate pieces of mail and to be automatically reassembled by the receiving user agent. Using message, "partial", can help alleviate fragmentation of large messages by different message transfer agents, but does not completely eliminate the problem. It is still possible that a piece of a partial message, upon re-assembly, may prove to contain a partial message as well. This is allowed by the Internet standards, and it is the responsibility of the user agent to re-assemble the fragmented pieces. It is recommended that the size of the EDI Interchange sent via SMTP be configurable so that if fragmentation does occur, then message, "partial" can be used to send the large EDI Interchange in smaller pieces. RFC 1521 defines the use of Content-Type: message/partial. Support of the message/partial content type for use in Internet EDI is optional. The receiving UA is required to re-assemble the original message before sending the message disposition notification to the original sender of the message. A message disposition notification is used to specify the disposition of the entire message that was sent, and should not be returned by a processing UA until the entire message is received, even if the received message requires re-assembling. In general, EDI content compresses well, since there is repetitive data in most EDI Interchanges. Instead of implementing the message/partial, compression of the EDI Interchange can be done after the signature is applied to the EDI Interchange, and before encryption. When no signature is applied, then compression is applied before the encryption. Compression is an alternative solution to implementing Content-Type: message/partial when sending large EDI Interchanges on the Internet. Applying compression before encryption strengthens cryptographic | security since repetitious strings are reduced. This sequence of | signature, compression, then encryption or compression then encryption, | is consistent with the order in which PGP implementations handle compression. | 5.4.2 Example The following is an example of a signed receipt returned by a UA after processing a MIME EDI content type that was signed. This example follows the S/MIME application/x-pkcs-7-signature format. NOTE: This example is provided as an illustration only, and is not considered part of the protocol specification. If an example conflicts with the protocol definitions specified above or in the other referenced RFCs, the example is wrong. To: Subject: From: Date: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="separator"; micalg=rsa-sha1; protocol="application/x-pkcs7-signature" --separator &Content-Type: multipart/report; report-type=disposition & notification; boundary = "xxxxx" & &--xxxxx & The message sent to Edi Recipient & has been received, the EDI Interchange was succesfully & decrypted and its integrity was verified. In addition, the & sender of the message, Edi Sender & was authenticated as the originator of the message. There is & no guarantee however that the EDI Interchange was & syntactically correct, or was received by the EDI & application. & &--xxxxx & Content-Type: message/disposition-notification & & Reporting-UA: good-edi-internet-ua.edicorp.com (ediua 1.0) & Original-Recipient: rfc822; Edi_Recipient@edicorp.com & Final-Recipient: rfc822; Edi_Recipient@edicorp.com & Original-Message-ID: <17759920005.12345@edicorp.com> & Disposition: autoprocessed & X-Received-MIC: Q2hlY2sgSW50XwdyaXRIQ=85=85 & &--xxxxx & Content-Type: message/rfc822 & &--xxxxx-- --separator Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: base64 @ContentType = SignedData @version = Version @digestAlgorithms = DigestAlgorithmIdentifiers @signerInfos = SignerInfo --separator-- Notes: -The lines preceeded with "&" is what the signature is calculated over. -The text preceeded by "@" indicates PKCS#7 defined fields and types. (For details on how to prepare the multipart/signed with protocol = "application/x-pkcs7-signature" see the "S/MIME Message Specification, PKCS Security Services for MIME" documentation.) As specified by RFC 1892, returning the original message is not necessary. This is an optional body part. It is recommended that the received headers be placed in the third body part, as it can be helpful in tracking problems. 6. Public key certificate handling 6.1 Near term approach In the near term, the exchange of public keys and certificaition of these keys must be handled as part of the process of establishing a trading partnership. The UA and/or EDI application interface must maintain a database of public keys used for encryption or signatures, in addition to the mapping between EDI trading partner ID and RFC822 email address. The procedures for establishing a trading partnership and configuring the secure EDI messaging system might vary among trading partners and software packages. For systems which make use of X.509 certificates, it is recommended that trading partners self-certify each other if an agreed upon certification authority is not used. It is highly recommended that when trading partners are using S/MIME, that they also exchange public key certificates using the recommendations specified in the S/MIME Implementation Guide Version 2. The message formats and S/MIME conformance requirements for certificate exchange are specified in this document. This applicability statement does NOT require the use of a certification authority. 6.2 Long term approach In the long term, additional Internet-EDI standards may be developed to simplify the process of establishing a trading partnership, including the third party authentication of trading partners, as well as attributes of the trading relationship. 7. Authors' Addresses Mats Jansson mjansson@agathon.com LiNK 2317 Broadway, Suite 330 Redwood City, CA 94063 USA Chuck Shih chucks@actracorp.com Actra Corp. 610 East Caribbean Drive Sunnyvale, CA 94089 USA Nancy Turaj nturaj@.mitre.org MITRE Corporation Mailstop: W657 1820 Dolley Madison Blvd. McLean, VA 22102-3481 USA Rik Drummond drummond@onramp.com The Drummond Group 5008 Bentwood Ct. Ft. Worth, TX 76132 USA 8. References [1] N. Borenstein, N.Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 23, 1993. [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 2, 1995. [3] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 13, 1982. [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 2015, Sept. 1996. [5] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", draft-ietf-receipt-mdn-01.txt, May 13, 1996. [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct. 3, 1995 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1, 1982. [8] S. Dusse, "S/MIME Message Specification; PKCS Security Services for MIME", Internet draft: draft-dusse-mime-msg-spec 00.txt [9] C. Shih, "Requirements for Inter-operable Internet EDI", July 1996. [10] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 15, 1996. --------------476D2328774C-- From owner-ietf-ediint Thu Feb 27 11:26:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA25796 for ietf-ediint-bks; Thu, 27 Feb 1997 11:26:29 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA25792 for ; Thu, 27 Feb 1997 11:26:26 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA9635; Thu, 27 Feb 1997 11:27:23 -0800 Message-ID: <3315DEE1.5ADD@actracorp.com> Date: Thu, 27 Feb 1997 11:22:09 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ietf-ediint@imc.org, edipilot@commerce.net Subject: Re: Revision of Signed Receipts References: <9702122237.AA01422@slick.chage.com> <33049619.1C9B@actracorp.com> <9702142202.AA01019@slick.chage.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Carl Hage wrote in response to Dale Moberg: > > : 4. Section 5.4.1 suggests using compression but mentions no > : applicable standards for using it. What standards within the > : MIME RFCs would specify an interoperable approach? > > PGP compresses within the encryption algorithm. The proper way to add > encryption in my opinion, would be to borrow the Content-Encoding header > from HTTP, which allows a compression algorithm to be added without > tampering with the Content-Type, or wrapping Content-Type. Too bad this > wasn't added in the MIME revision. After some investigation here is what I propose to put into the AS#1, concerning recommendations on compression: 1). That compression be considered an alternative to implementing message/partial for large EDI files. This is already in the AS#1. 2). The sequence of when to apply the compression - no different from what PGP already does today. This is already in the AS#1. 3). RFC 2045 allows the definition of additional MIME header fields that "furthur describes the content of a message". The recommended use to describe that the EDI data has been compressed should be what is used by RFC2068 (HTTP/1.1) to describe this same exact thing: Content-Encoding = gzip or compress Both gzip and compress are registered with IANA and gzip is described in RFC 1952. Compress is the encoding format produced by the UNIX compress command. > > : 5. The References should be updated to reflect the new MIME RFCs This has been done and will appear in the next refresh of the document. From owner-ietf-ediint Thu Feb 27 22:37:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA01802 for ietf-ediint-bks; Thu, 27 Feb 1997 22:37:35 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id WAA01798 for ; Thu, 27 Feb 1997 22:37:27 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA7394; Thu, 27 Feb 1997 22:38:29 -0800 Message-ID: <33167C2A.2F56@actracorp.com> Date: Thu, 27 Feb 1997 22:33:14 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: jding@actracorp.com CC: pedro@premenos.com, edipilot@commerce.net, ietf-ediint@imc.org Subject: Re: [Fwd: Multipart/Signed] References: <331627CC.7CA9@actracorp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Jun and Pedro, RFC1847 doesn't really discuss how to handle the situation you discuss below, but RFC2015 which defines PGP/MIME and uses the multipart/signed does discuss this situation. Look at section 5 under PGP signed data and the section that begins "Upon receipt of a signed message, an application MUST:" (1) Convert line endings to the canonical sequence before the signature can be verified. This is necessary since the local MTA may have converted to a local end of line convention. It seems that both of our mailers (Netscape and I think Pedro's yours is Eudora?) convert the \r\n to \n. I have sent a note to Jim Galvin to get his read on this, but I think that the PGP/MIME folks have encountered this problem and prescribed the solution. I will also put this into the appendix of the requirements document where we give examples and notes to implementors. Jun Ding wrote: > > Message from Pedro. > > --------------------------------------------------------------- > > Subject: Multipart/Signed > Date: Thu, 27 Feb 1997 15:08:01 -0800 > From: "Pedro Chiang" > To: "Jun Ding" > > Jun, > In regards to Multipart/Signed, after reading RFC 1847 and I quote > > "The entire contents of the multipart/signed must be treated as opaque > while it is transit from an originator to a recipient. Intermediate MTAs > must > not alter the content of a M/S in any way..." > > Since mailers do change "\r\n" we are in trouble. Have you talked to > Chuck about the \r\n -> \n problem? > > Let me know if you have any news. > > ---Pedro Chiang > From owner-ietf-ediint Fri Feb 28 09:19:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA09405 for ietf-ediint-bks; Fri, 28 Feb 1997 09:19:50 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA09399 for ; Fri, 28 Feb 1997 09:19:31 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA24200; Fri, 28 Feb 1997 09:20:16 -0800 Message-ID: <33171294.4048@actracorp.com> Date: Fri, 28 Feb 1997 09:15:00 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: edipilot@commerce.net, ietf-ediint@imc.org Subject: [Fwd: Re: Help! Processing] Content-Type: multipart/mixed; boundary="------------F2285D6616" Sender: owner-ietf-ediint@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------F2285D6616 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is the response from Jim Galvin on line delimiter processing using multipart/signed. RFC1848 Section 2.1.1 addresses this issue in detail. --------------F2285D6616 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from maleman.mcom.com ([198.93.92.3]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA20040 for ; Fri, 28 Feb 1997 07:10:34 -0800 Received: from xwing.netscape.com (xwing.mcom.com [205.218.156.54]) by maleman.mcom.com (8.6.9/8.6.9) with ESMTP id HAA12830 for ; Fri, 28 Feb 1997 07:10:22 -0800 Received: from drawbridge.east.commerce.net (firewall-user@drawbridge.east.commerce.net [207.123.157.2]) by xwing.netscape.com (8.7.6/8.7.3) with SMTP id HAA06552 for ; Fri, 28 Feb 1997 07:11:39 -0800 (PST) Received: by drawbridge.east.commerce.net; id KAA20791; Fri, 28 Feb 1997 10:00:00 -0500 Received: from jim.east.commerce.net(10.0.0.5) by drawbridge.east.commerce.net via smap (3.2) id xma020786; Fri, 28 Feb 97 09:59:57 -0500 X-Sender: galvin@inside.east.commerce.net Message-Id: In-Reply-To: <331678D4.5866@actracorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Feb 1997 10:09:43 -0500 To: chucks@actracorp.com From: "James M. Galvin" Subject: Re: Help! Processing At 1:19 AM -0500 2/28/97, Chuck Shih wrote: >In the elkins draft on PGP/MIME it does state that on receiving a signed >message to convert line endings to the canonical form with >before the signature can be verified. Is this the common way to handle >this problem? Exactly right. The fact is SMTP engines routinely convert line delimiters to match local conventions. Therefore, 822/MIME level processors need to address this issue. RFC1847 explicitly did not address this because we wanted to make sure it could be used in 8bit environments, should they ever become popular, notwithstanding the fact that they do exist in some "regional" areas. However, I've decided at this point that 1847 should at least call attention to this detail because it's become a common problem. If you look at the MOSS specification (RFC1848), we give this issue due consideration. If I were to point you at one place that makes good reading it would be Section 2.1.1. Enjoy, Jim ---------------------------------------------------------------------------- James M. Galvin galvin@commerce.net CommerceNet +1 410.203.2707 3209-A Corporate Court FAX +1 410.203.2709 Ellicott City, MD 21042 http://www.commerce.net/ http://www.eff.org/blueribbon http://www.eff.org/goldkey --------------F2285D6616-- From owner-ietf-ediint Fri Feb 28 14:18:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA13462 for ietf-ediint-bks; Fri, 28 Feb 1997 14:18:18 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA13457 for ; Fri, 28 Feb 1997 14:18:14 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA01779 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Fri, 28 Feb 1997 14:20:51 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA11179; Fri, 28 Feb 97 13:05:11 PST Date: Fri, 28 Feb 97 13:05:11 PST From: carl@chage.com (Carl Hage) Message-Id: <9702282105.AA11179@slick.chage.com> To: ietf-ediint@imc.org Subject: Revision of MDN Section of AS#1 Sender: owner-ietf-ediint@imc.org Precedence: bulk ---- The details in the MDN section are greatly improved. I still think the returned MIC should be over a higher/outer level content, but the latest AS#1 will work successfully and the spec is now precisely defined, except for one part: There should be another section defining the MIC when there is no signature, e.g. add section 3.d) which specifies how the MIC is calculated for unsigned messages. For encrypted, unsigned messages, the MIC to be returned in the MDN is calculated on the content which would have been signed, e.g. the MIME header and content results of decryption. In the case of unsigned, unencrypted messages, the MIC should be calculated over the message body without MIME Content-Type-Encoding (or Content-Encoding), or any other RFC822 header. For this case, the MIME headers are mixed with the RFC822 headers (which are sometimes altered or reordered by MTAs), so unlike the encrypted or signed data content, the EDI message alone is used for the MIC calculation. ---- - disposition-field - for EDI use: "notprocessed" - The received content(s) was not processed. This definition is too vague. What happens when there is a failure in the application/edi-x12, processing script, e.g. the MTA/UA authenticates, forks a program to pipe the EDI message, but something goes wrong and the fork/pipe/app fails? Perhaps this is "notprocessed"? What other conditions are "notprocessed"? There should probably be a distinction between ignoring/rejecting a message and an error condition. --- The "X-disposition-qualifier-field" is used to furthur qualify the value in the "disposition-field". The value of the "X-disposition-qualifier-field" is a trading partner mutally agreed to value. The semantics of the qualifying value upon the "dispostion-field" value is up to the trading partners to define and interpret. I don't like the idea of defining undefined headers. This is contrary to the purpose of standards. Aren't there some obvious values that can be defined now and implemented by the vendors? I would rather see nothing than "up to the trading partners". This is a source of interoperability problems. Realistically, it's probably not up to trading partners-- it's probably a function of the software vendors, hence should be standardized. A list of values might be better. Not all conditions can be defined with a single word. Allowing multiple words provides a means to convey semantics for more than one function. --- It would be useful to include a paragraph which indicates that the textual first part of the MDN should be used to include a more detailed explaination of the error conditions reported by the disposition headers. The disposition headers allow software to detect error conditions, and the textual part allows a person responing to a failure to diagnose the problem in detail. --- "unsupported-format" - A request for a signed receipt cannot be returned because the requested format is not supported. How about changing s/returned/processed/. The receipt can (and should) still be "returned", even though the format request cannot be honored. It would be useful to indicate that MDN receipts can be signed, even though "Disposition-notification-options:" are not present or cannot be complied with. I noticed in the intro: If signature is not explicitly requested, all bets are off. This is consistent with Fajman's MDN draft. It would be better to reword this slightly, e.g. If signature is not explicitly requested or the format is not supported, all bets are off. An MDN should be returned, but may be with or without a signature. Software processing MDNs must be able to extract the report from within a multipart/signed even though signatures are not processed or explicitly requested. It might also be useful to include a comment in the section on MDN processing/disposition rather than just in the intro. My concern is that people will misread this and think that if a signature is not requested or there is an unknown option, then "the MDN _must not_ be signed", rather than the correct interpretation, "all bets are off". --- It might be useful to include a statement on the third part of the MDN, which could be omitted, could include the RFC822 headers, or could contain a copy of the received message. The content provided could be at the descretion of the recipient, or could be agreed upon by the trading partners. Including RFC822 headers only could be useful for tracking email forwarding performance. I suggest you modify the example MDN at: & Content-Type: message/rfc822 to either show a set of sample RFC822 headers with "Received:" headers (demonstrating why headers would be included), and/or put an explainatory paragraph. The example should probably not be a header with blank content. --- The proposed additions for optional compression sounds good. The currnet AS#1 section 5.4.1 has a problem because it says compression can be done, but doesn't specify the protocol. Either add the headers (best) or delete the references to compression. Compression should not be permitted without a standardized protocol/format. It would also be worth mentioning, that if PGP encryption is used, then compressing the message content is superflous since the encryption format already includes compression. Compression (indicated by Content-Encoding) would be useful for unencrypted messages such as RFQs, catalogs, etc. broadcast to multiple recipients, or for S/MIME encrypted messages. --- P.S. Thanks for the acknowledgment. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Sat Mar 1 23:30:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA00615 for ietf-ediint-bks; Sat, 1 Mar 1997 23:30:03 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA00608 for ; Sat, 1 Mar 1997 23:29:59 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA29219; Sat, 1 Mar 1997 23:31:40 -0800 Message-ID: <33192B9E.3430@actracorp.com> Date: Sat, 01 Mar 1997 23:26:22 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ietf-ediint@imc.org, edipilot@commerce.net Subject: Re: Revision of MDN Section of AS#1 References: <9702282105.AA11179@slick.chage.com> Content-Type: multipart/mixed; boundary="------------B3272210C1" Sender: owner-ietf-ediint@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------B3272210C1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It is Saturday night, and yes, here I am working away at "yet another" revision of the AS#!!. This time I have incorporated the comments of Carl Hage, see below. Attached is an AS#1 with some (most) of Carl's comments incorporated. I think (hope) this stuff is getting close, and I hope (will) to post it next week to the IETF web site. Carl Hage wrote: > > ---- > There should be another section defining the MIC when there is no > signature, e.g. add section 3.d) which specifies how the MIC is calculated > for unsigned messages. This has been added under a new subsection 5.2.1, with essentially your wording. > ---- > - disposition-field - for EDI use: > "notprocessed" - The received content(s) was not processed. > > This definition is too vague. > .... There should probably be a distinction > between ignoring/rejecting a message and an error condition. > --- I kept the notprocessed and added an error value, and made the distinction between ignored/rejected and processing errors. This is to be found in Section 5.3. > I don't like the idea of defining undefined headers. This is contrary to the > purpose of standards. Aren't there some obvious values that can be defined > now and implemented by the vendors? > > A list of values might be better. Not all conditions can be defined with > a single word. Allowing multiple words provides a means to convey semantics > for more than one function. The only value that has been brought up in the discussion is Dale's, and that would be autoprocessed. The list feels that a qualifier field on the dispostion field is preferable to allowing a list of disposition fields, primarily because it is easier to process. The semantics of a list of disposition values can become fairly complex. > --- > It would be useful to include a paragraph which indicates that the textual > first part of the MDN should be used to include a more detailed explaination > of the error conditions reported by the disposition headers. The disposition > headers allow software to detect error conditions, and the textual part > allows a person responing to a failure to diagnose the problem in detail. Added to the end of section 5.4, the signed receipt example. > --- > "unsupported-format" - A request for a signed receipt cannot be > returned because the requested format is not > supported. > > How about changing s/returned/processed/. The receipt can (and should) > still be "returned", even though the format request cannot be honored. > > It would be useful to indicate that MDN receipts can be signed, even > though "Disposition-notification-options:" are not present or cannot > be complied with. I noticed in the intro: > > If signature is not explicitly requested, all bets are off. This > is consistent with Fajman's MDN draft. > > It would be better to reword this slightly, e.g. > If signature is not explicitly requested or the format is not > supported, all bets are off. An MDN should be returned, but may be > with or without a signature. Software processing MDNs must be able to > extract the report from within a multipart/signed even though > signatures are not processed or explicitly requested. I have re-worded both 2.2.3 and added 5.2.1 to clarify how to handle the situation when a signature is not explicitly requested. I disagree with you on this point, and the list should comment. My opinion is that if a signature is not explicitly requested, or parameters are not recognized, that an unsigned MDN should be returned. Although the Fajman spec states that all bets are off, I think that within Internet EDI an unsigned MDN should always be returned in these situations. I also believe that only when a signature request is explicitly made, and that the format can be supported by the recipient, then and only then should a signed-receipt be returned. I also don't think we should require a UA to extract the report from a multipart/signed if it does not process outgoing signatures or request incoming signed receipt. > > It might also be useful to include a comment in the section on MDN > processing/disposition rather than just in the intro. My concern is > that people will misread this and think that if a signature is not > requested or there is an unknown option, then "the MDN _must not_ be > signed", rather than the correct interpretation, "all bets are off". > --- This is done in 5.2.1, though not as you propose. > It might be useful to include a statement on the third part of the > MDN, which could be omitted, could include the RFC822 headers, or > could contain a copy of the received message. The content provided > could be at the descretion of the recipient, or could be agreed upon > by the trading partners. Including RFC822 headers only could be useful > for tracking email forwarding performance. This is already in the spec at the end of the signed receipt example. > > I suggest you modify the example MDN at: > & Content-Type: message/rfc822 > > to either show a set of sample RFC822 headers with "Received:" headers > (demonstrating why headers would be included), and/or put an explainatory > paragraph. The example should probably not be a header with blank content. Done. > --- > The proposed additions for optional compression sounds good. The currnet > AS#1 section 5.4.1 has a problem because it says compression can be > done, but doesn't specify the protocol. Either add the headers (best) > or delete the references to compression. Compression should not be permitted > without a standardized protocol/format. I have added additional recommendations on compression. More specifically, recommendations to use the HTTP/1.1 defined Content-Encoding header and values. > > It would also be worth mentioning, that if PGP encryption is used, then > compressing the message content is superflous since the encryption format > already includes compression. Compression (indicated by Content-Encoding) > would be useful for unencrypted messages such as RFQs, catalogs, etc. > broadcast to multiple recipients, or for S/MIME encrypted messages. > --- Have added. > P.S. Thanks for the acknowledgment. Thanks for the comments and thorough review. > -------------------------------------------------------------------------- > Carl Hage C. Hage Associates > Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 > Sunnyvale, CA 94086 --------------B3272210C1 Content-Type: text/plain; charset=us-ascii; name="assend.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="assend.txt" INTERNET DRAFT Mats Jansson, LiNK draft-ietf-ediint-as1-04.txt Chuck Shih, Actra Rik Drummond, Drummond Group 24 February, 1997 MIME-based Secure EDI 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 document describes how to securely exchange EDI documents using MIME and public key cryptography. Feedback Instructions: If you want to provide feedback on this draft, follow these guidelines: -Send feedback via e-mail to the ietf-ediint list for discussion, with "AS#1" in the Subject field. To enter/follow the discussion, you need to subscribe at ietf-ediint@imc.org. -Be specific as to what section you are referring to, preferably quoting the portion that needs modification, after which you state your comments. -If you are recommending some text to be replaced with your suggested text, again, quote the section to be replaced, and be clear on the section in question. Table of Contents 1. Introduction 2. Overview 2.1 Purpose of a security guideline for MIME EDI 2.2 Definitions 2.2.1 Terms 2.2.2 The secure transmission loop 2.2.3 Definition of receipts 2.3 Assumptions 2.3.1 EDI process assumptions 2.3.2 Flexibility assumptions 3. Referenced RFCs and their contribution 3.1 RFC 821 SMTP [7] 3.2 RFC 822 Text Message Format [3] 3.3 RFC 1847 MIME Security Multiparts [6] 3.4 RFC 1892 Multipart/report [9] 3.5 RFC 1767 EDI Content [2] 3.6 RFC 2015 PGP/MIME [4] 3.7 RFC 2045,2046, and 2049 MIME [1] 3.8 Internet draft (fajman): Message Disposition Notification [5] 3.9 Internet draft (dusse): - S/MIME Specification [8] 4. Structure of an EDI MIME message - Applicability 4.1 Introduction 4.2 Structure of an EDI MIME message - PGP/MIME 4.2.1 No encryption, no signature 4.2.2 No encryption, signature 4.2.3 Encryption, no signature 4.2.4 Encryption, signature 4.3 Structure of an EDI MIME message - S/MIME 4.3.1 No encryption, no signature 4.3.2 No encryption, signature 4.3.3 Encryption, no signature 4.3.4 Encryption, signature 5. Receipts 5.1 Introduction 5.2 Requesting a signed receipt 5.2.1 Additional signed receipt considerations 5.3 Message Disposition Notification Format 5.3.1 Message Disposition Notification Extension Fields 5.4 Message Disposition Notification Processing 5.4.1 Large File Processing 5.4.2 Example 6. Public key certificate handling 6.1 Near term approach 6.2 Long term approach 7. Authors' Addresses 8. References 1. Introduction The authors would like to extend special thanks to Carl Hage for providing the team with valuable, and very thorough feedback. Without participants like Carl, these efforts become hard to complete in a way useful to the users of the technology. The authors would also like to thank Nancy Turaj for her help in editing portions of this document. Previous work on Internet EDI focused on specifying MIME content types for EDI data ([2] RFC 1767). This Applicability Statement expands on RFC 1767 to specify use of a comprehensive set of data security features, specifically data privacy, data integrity/authenticity, non-repudiation of origin and non- repudiation of receipt. This draft recognizes contemporary RFCs and Internet drafts and is attempting to "re-invent" as little as possible. With an enhancement in the area of "receipts", as described below (3.1.8), secure Internet MIME based EDI can be accomplished by using and complying with the following RFCs and drafts: -RFC 821 SMTP -RFC 822 Text Message Formats -RFC 1767 EDI Content Type -RFC 1847 Security Multiparts for MIME -RFC 1892 Multipart/Report -RFC 2015 MIME/PGP (elkins) -RFC 2045 to 2049 MIME RFCs -Internet draft: Message Disposition Notification (fajman) -Internet draft: S/MIME Specification (dusse) Our intent here is to define clearly and precisely how these are used together, and what is required by user agents to be compliant with this Applicability Statement. 2. Overview 2.1 Purpose of a security guideline for MIME EDI The purpose of these specifications is to ensure interoperability between EDI user agents, invoking some or all of the commonly expected security features. This standard is also NOT limited to strict EDI use, but applies to any electronic commerce application where business data needs to be exchanged over the Internet in a secure manner. 2.2 Definitions 2.2.1. Terms EDI Electronic Data Interchange EC Electronic Commerce Receipt The functional message that is sent from a receiver to a sender to acknowledge receipt of an EDI/EC interchange Signed Receipt Same as above, but with a digital signature Message Disposition The way by which a receipt or a signed Notification (MDN) receipt is accomplished within Internet Messaging. Non-repudiation of NRR is a "legal event" that occurs when the Receipt (NRR) original sender of an EDI/EC interchange has verified the signed receipt coming back from the receiver. NRR IS NOT a functional or a technical message. PGP/MIME Digital envelope security based on the Pretty Good Privacy (PGP) standard (Zimmerman), integrated with MIME Security Multiparts [6]. S/MIME A format and protocol for adding cryptographic signature and/or encryption services to Internet MIME messages. 2.2.2 The secure transmission loop The functional requirements document, [9] "Requirements for Inter- operable Internet EDI" (can be found at www.ietf.org),provides extensive information on EDI security and the user/business related processes surrounding the need for and use of EDI security. In this document, it is assumed that the reader is familiar with the requirements document. This document's focus is on the formats and protocols for exchanging EDI content that has had security applied to it using the Internet's messaging transport. The "secure transmission loop" for EDI involves one organization sending a signed and encrypted EDI interchange to another organization, requesting a "signed receipt", followed later by the receiving organization sending this "signed receipt" back to the sending organization. In other words, the following transpires: -The organization sending EDI/EC data encrypts the data and provides a digital signature, using either PGP/MIME or S/MIME. In addition, they request a "signed receipt". -The receiving organization decrypts the message and verifies the signature, resulting in verified integrity of the data and authenticity of the sender. -The receiving organization then sends a "signed receipt" in the form of a signature over the hash from the previous step. The above describes functionality which if implemented, would satisfy all security requirements. This specification, however, leaves full flexibility for users to decide the degree to which they want to deploy those features with their EDI trading partners. 2.2.3 Definition of receipts The term used for both the functional activity and message for acknowledging receipt of an EDI/EC interchange is "receipt", or "signed receipt". The first term is used if the acknowledgment is for an interchange resulting in a receipt which is NOT signed. The second term is used if the acknowledgment is for an interchange resulting in a receipt which IS signed. The "rule" is: If a receipt | is requested, explicitly specifying that the receipt be | signed, then the receipt indeed has to be returned with a signature. | If a receipt is requested, explicitly specifying that the receipt | be signed, but the recipient cannot support the requested | signature format, then an unsigned receipt or MDN should be returned. | If a signature is not explicitly requested, or if the signed receipt | request parameter is not recognized by the UA, all bets are off. This is | consistent with the MDN draft. | A term often used in combination with receipts is "Non-repudiation of Receipt (NRR). NRR refers to a legal event which occurs only when the original sender of an interchange has verified the sender and content of a "signed receipt". Note that NRR is not possible without signatures. 2.3 Assumptions 2.3.1 EDI process assumptions -Encrypted object is an EDI Interchange This specification assumes that a typical EDI interchange is the lowest level object that will be subject to security features. In ANSI X12, this means anything between, and including segments ISA and IEA. In EDIFACT, this means anything between, and including, segments UNA/UNB and UNZ. In other words, the EDI interchanges including envelope segments remain intact and unreadable during secure transport. -EDI envelope headers are encrypted Congruent with the above statement, EDI envelope headers are NOT visible in the MIME package. In order to optimize VAN-to- Internet routing, work may need to be done in the future to define ways to pull out some of the envelope information to make them visible, however, this specification does not go into any detail on that. -X12.58 and UN/EDIFACT security considerations The most common EDI standards, ANSI X12 and EDIFACT, have defined internal provisions for security. X12.58 is the security mechanism for ANSI X12 and AUTACK provides security for EDIFACT. This specification DOES NOT dictate use or non-use of these security standards. They are both fully compatible, though possibly redundant, with this specification. 2.3.2 Flexibility assumptions -Encrypted or un-encrypted data This specification allows for EDI message exchange where the EDI data is either un-protected or protected by means of encryption. -Signed or un-signed data This specification allows for EDI message exchange with or without digital signature of the original EDI transmission. -Use of receipt or not This specification allows for EDI message transmission with or without a request for receipt notification. If a signed receipt notification is requested, however, a signature is required as part of the returned receipt, unless an error condition occurs in which a signed-receipt cannot be returned. In these cases an un-signed receipt or MDN should be returned with the correct "signed-receipt-disposition" value. -Formatting choices This specification defines use of two methods for formatting EDI contents that have security applied to it: -PGP/MIME -S/MIME This specification relies on the guidelines set forth in the RFC 2015, as reflected in [4] MIME Security with Pretty Good Privacy (PGP), and Internet draft [8] S/MIME Specification from RSA Security, Inc. (dusse) Compliance with this specification dictates that AT LEAST one of these methods is supported. -Hash function, message digest choices When signature is used, unless specified otherwise by the chosen method (PGP/MIME or S/MIME), the SHA1 checksum hash function is recommended. In summary, the following eight permutations are possible in any given trading relationship: (1) Sender sends un-encrypted data, does NOT request a receipt. (2) Sender sends un-encrypted data, requests a receipt. Receiver sends back a receipt. (3) Sender sends encrypted data, does NOT request a receipt. (4) Sender sends encrypted data, requests a receipt. Receiver sends back a receipt. (5) Sender sends signed data, does NOT request a signed or un-signed receipt. (6) Sender sends signed data, requests a signed or un-signed receipt. Receiver sends back a signed or un-signed receipt. (7) Sender sends encrypted and signed data, does NOT request a signed or un-signed receipt. (8) Sender sends encrypted and signed data, requests a signed or un-signed receipt. Receiver sends back a signed or un-signed receipt. NOTE: Users can choose any of the eight possibilities, but only example (8), when a signed receipt is requested, offers the whole suite of security features described in the "Secure transmission loop" above. 3. Referenced RFCs and their contribution 3.1 RFC 821 SMTP [7] This is the core mail transfer standard that all MTAs need to adhere to. 3.2 RFC 822 Text Message Format [3] Defines message header fields and the parts making up a message. 3.3 RFC 1847 MIME Security Multiparts [6] This document defines security multiparts for MIME: multipart/encrypted and multipart/signed. 3.4 RFC 1892 Multipart/report [10] This RFC defines the use of Multipart/report content type, something that the MDN draft (fajman) relies on for the receipt functionality. 3.5 RFC 1767 EDI Content [2] This RFC defines the use of content type "application" for ANSI X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and mutually defined EDI (application/EDI-Consent). 3.6 RFC 2015 PGP/MIME [4] This RFC defines the use of content types "multipart/encrypted", "multipart/signed", "application/pgp encrypted" and "application/pgp-signature" for defining MIME PGP content. 3.7 RFC 2045, 2046, and 2049 MIME [1] These are the basic MIME standards, upon which all MIME related RFCs build, including this one. Key contributions include definition of "content type" and sub-type "multipart", in addition to encoding guidelines, which establish 7-bit US-ASCII as the lowest common denominator used. 3.8 Internet draft (fajman): Message Disposition Notification [5] This Internet draft defines how a message disposition notification (MDN) is requested, and the structure of the MDN. NOTE: This is the only specification we were not able to take "as is". Extension field-names beginning with "X-" will not be defined as a standard field. MDN field names not beginning with "X- " need to be registered with the Internet Assigned Numbers Authority (IANA) and described in an RFC. The "X-" extension fields described in this document will be registered with IANA. 3.9 Internet draft (dusse): S/MIME Message Specification [8] This specification describes how MIME shall carry PKCS7 signature and envelope information. 4. Structure of an EDI MIME message - Applicability 4.1 Introduction The structures below are described hierarchically in terms of which RFC's are applied to form the specific structure. For details of how to code in compliance with all RFC's involved, turn directly to the RFC's referenced. The "requirements document" has several examples described in an Appendix for those interested. Also, these structures describe the initial transmission only. Receipts, and requests for receipts are handled in section 5. 4.2 Structure of an EDI MIME message - PGP/MIME 4.2.1 No encryption, no signature -RFC822/1521 -RFC1767 (application/EDIxxxx) 4.2.2 No encryption, signature -RFC822/1521 -RFC1847 (multipart/signed) -RFC1767 (application/EDIxxxx) -RFC2015 (application/pgp-signature) 4.2.3 Encryption, no signature -RFC822/1521 -RFC1847 (multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version 1" -RFC1767 (application/EDIxxxx) (encrypted) 4.2.4 Encryption, signature -RFC822/1521 -RFC1847 (multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version 1" -RFC1847 (multipart/signed) (encrypted) -RFC1767 (application/EDIxxxx) (encrypted) 4.3 Structure of an EDI MIME message - S/MIME 4.3.1 No encryption, no signature -RFC822/1521 -RFC1767 (application/EDIxxxx) 4.3.2 No encryption, signature -RFC822/1521 -RFC1847 (multipart/signed) -RFC1767 (application/EDIxxxx) -Draft (dusse) (application/x-pkcs7-signature) 4.3.3 Encryption, no signature -RFC822/1521 -Draft (dusse) (application/x-pkcs7-mime) -RFC1767 (application/EDIxxxx) (encrypted) 4.3.4 Encryption, signature -RFC822/1521 -Draft (dusse) (application/x-pkcs7-mime) -RFC1847 (multipart/signed) (encrypted) -RFC1767 (application/EDIxxxx) (encrypted) -Draft (dusse) (application/x-pkcs7-signature) (encrypted) 5. Receipts 5.1 Introduction In order to support non-repudiation of receipt (NRR), a signed receipt, based on digitally signing a message disposition notification, is to be implemented by a receiving trading partner's UA (User Agent). The message disposition notification, specified by draft-ietf-receipt-mdn-02.txt is digitally signed by a receiving trading partner and returned to the sending trading partner as part of a multipart/signed MIME message. The required support for signed receipts when doing Internet EDI is as follows: 1). Create a multipart/report; report-type = disposition-notification. 2). Calculate the MIC on the message disposition notification. 3). Digitally sign the MIC. 4). Create a multipart/signed content with the message disposition notification as the first body part, and the signed MIC calculated on the message disposition notification as the second body part. 5). Return the signed receipt to the sending trading partner. The signed receipt is used to notify a sending trading partner that requested the signed receipt that: 1). The receiving trading partner acknowledges receipt of the sent EDI Interchange. 2). If the sent message was signed, then the receiving trading partner has authenticated the sender of the EDI Interchange. 3). If the sent message was signed, then the receiving trading partner has verified the integrity of the received EDI Interchange. Regardless of whether the EDI Interchange was sent in S/MIME or PGP/MIME format, the receiving trading partner's UA must provide the following basic processing: 1). If the sent EDI Interchange is encrypted, then the encrypted symmetric key and initialization vector (if applicable) is decrypted using the receiver's private key. 2). The decrypted symmetric encryption key is then used to decrypt the EDI Interchange. 3). The receiving trading partner authenticates signatures in a message using the sender's public key. The authentication algorithm performs the following: a). The message integrity check (MIC or Message Digest), is decrypted using the sender's public key. b). A MIC on the signed contents (the MIME header and encoded EDI object, as per RFC 1767) in the message received is calculated using the same one-way hash function that the sending trading partner used. c). The MIC extracted from the signature is compared with the MIC calculated using the same one-way hash function that the sending trading partner used. 4). The receiving trading partner formats the MDN and sets the calculated MIC into the "X-Received-content-MIC" extension field. 5). The receiving trading partner creates a multipart/signed MIME message according to RFC 1847. 6). The MDN is the first part of the multipart/signed message, and the digital signature is created over this MDN, including its MIME headers. 7). The second part of the multipart/signed message contains the digital signature. The "protocol" option specified in the second part of the multipart/signed is as follows: S/MIME: protocol = "application/pkcs-7-signature" PGP/MIME: protocol = "application/pgp-signature" 8). The signature information is formatted according to S/MIME or PGP/MIME specifications. The EDI Interchange and the RFC 1767 MIME EDI content header, can actually be part of a multi-part MIME content-type. When the EDI Interchange is part of a multi-part MIME content-type, the MIC is calculated across the entire multi-part content, including the MIME headers. The multi-part MIME content that contains the EDI Interchange is then enveloped in either S/MIME or PGP/MIME format. The signed MDN, when received by the sender of the EDI Interchange can then be used by the sender: 1). As an acknowledgment that the EDI Interchange sent, was delivered and acknowledged by the receiving trading partner. The receiver does this by returning the original message id of the sent message in the MDN portion of the signed receipt. 2). As an acknowledgment that the integrity of the EDI Interchange was verified by the receiving trading partner. The receiver does this by returning the calculated MIC of the received EDI Interchange (and 1767 MIME headers) in the "X-Received-content-MIC" field of the signed MDN. 3). As an acknowledgment that the receiving trading partner has authenticated the sender of the EDI Interchange. 4). As a non-repudiation of receipt when the signed MIC calculated over the MDN, is successfully decrypted by the sender with the receiving trading partner's public key. 5.2 Requesting a signed receipt Message Disposition Notifications are requested as per draft-ietf- receipt-mdn-02.txt, "An Extensible Message Format for Message Disposition Notification". A request that the receiving user agent issue a message disposition notification is made by placing the following header into the message to be sent: mdn-request-header = "Disposition-notification-to" ":" mail-address The mail-address field is specified as an RFC 822 user@domain address, and is the return address for the message disposition notification. In addition to requesting a message disposition notification, a message disposition notification that is digitally signed, or what has been referred to as a signed receipt, can be requested by placing the following in the message header following the "Disposition-notification-to" line: Disposition-notification-options = "Disposition-notification-options" ":" disposition-notification-parameters Where disposition-notification-parameters = signed-receipt-protocol=O, ; The currently supported values for are "x-pkcs7-signature", for the S/MIME detached signature format, or "pgp-signature", for the pgp signature format. An example of a formatted options line would be as follows: Disposition-notification-options: signed-receipt-protocol=O, x-pkcs7-signature; The semantics of the "signed-receipt-protocol" parameter is as follows: 1). The "signed-receipt-protocol" parameter is used to request a signed receipt from the recipient trading partner. The "signed-receipt-protocol" parameter also specifies the format in which the signed receipt should be returned to the requester. The MIC algorithm and signature algorithm used in formulating the signed receipt are agreed to in the trading partner relationship. The actual algorithms used in the signed receipt are always returned as part of the signed receipt. 2). The "importance" attribute of "O" is defined in the MDN draft and has the following meaning: Parameters with an importance of "O" permit a UA that does not understand the "signed-receipt-protocol" parameter to still generate a MDN in response to a request for a MDN. A UA that does not understand the "signed-receipt-protocol" parameter, will obviously not return a signed receipt. The importance of "O" is used for the signed receipt parameters because it is desirable that an MDN be returned to the requesting trading partner even if the recipient could not sign it. The returned MDN will contain information on the disposition of the message as well as why the MDN could not be signed. See the disposition and extension fields in section 5.3 for more information. Within an EDI trading relationship, if a signed-receipt is expected and is not returned, then the validity of the transaction is up to the trading partners to resolve. In general, if a signed-receipt is required in the trading relationship and is not received, the transaction will likely not be considered valid. 5.2.1 Additional Signed Receipt Considerations The "rules" stated in Section 2.2.3 for signed receipts are as follows: | 1). When a receipt is requested, explicitly specifying that the receipt | be signed, then the receipt indeed has to be returned with a signature. 2). When a receipt is requested, explicitly specifying that the receipt | be signed, but the recipient cannot support the requested signature format, then an unsigned receipt or MDN should be returned. | 3). If a signature is not explicitly requested, or if the signed receipt | request parameter is not recognized by the UA, then all bets are off. | This is consistent with the MDN specification. NOTE: For Internet EDI, it is recommended that when a signature is not | explicitly requested, or if parameters are not recognized, that the UA | send back the MDN unsigned. When a request for a signed receipt is made, but there is an error in processing the contents of the message, a signed receipt should still be returned. The request for a signed receipt should still be honored, though the transaction itself may not be valid. The reason for why the contents could not be processed should still be set in the "disposition-field". When a request for a signed receipt is made, and the message contents themselves | are not signed, then the calculation of the "X-Received-MIC" should be as follows: | - For encrypted, unsigned messages, the MIC to be returned is calculated on the | decrypted RFC 1767 MIME header and content, or multipart MIME header and content. | - For unsigned, unencrypted messages, the MIC should be calculated over the message | body without the MIME Content-Type, or MIME Content-Transfer-Encoding, or any | other RFC 822 headers, since these are sometimes altered or reordered by MTAs. | A new extension field that further qualifies the "disposition-field" is defined by this specification. The field "X-Disposition-qualifier-field" is used to convey additional error or status information on the value specified in the "disposition-field". Situations arise in EDI where even if a trading partner cannot be authenticated correctly, the trading partners still agree to continue processing the EDI transactions. Transaction reconciliation is done between the trading partners at a later time. The "X-Disposition-qualifier-field" allows for qualifying an "authentication-failed" disposition value with a "X-Disposition-qualifier-field" of "autoprocessed" for instance. This use of a disposition qualifier value would convey in the above example, that even though authentication failed, the receiving trading partner still processed the received EDI transactions. 5.3 Message Disposition Notification Format The format of a message disposition notification is as specified in draft-ietf-receipt-mdn-02.txt. For use in Internet EDI the following format will be used: - content-type - per RFC 1892 and the ietf-receipt-mdn specification - reporting-ua-field - per ietf-receipt-mdn specification - mdn-gateway-field - per ietf-receipt-mdn specification - original-recipient-field - per ietf-receipt-mdn specification - final-recipient-field - per ietf-receipt-mdn specification - original-message-id-field - per ietf-receipt-mdn specification - disposition-field - for EDI use: "notprocessed" - The received content(s) was not processed. "autoprocessed" - The message has been processed automatically in some manner (e.g., printed, faxed, forwarded, gatewayed) in response to some user request made in advance, without being displayed to the user. The user may or may not see the message later. "decryption-failed" - The receiver could not decrypt the contents. "authentication-failed" - The receiver could not authenticate the sender. "integrity-check-failed" - The receiver could not verify content integrity. "unexpected-processing-error" - A catch-all for additional processing errors. | Note: The "notprocessed" disposition value should be used when the message content is | being rejected or ignored, for instance if it is determined that a signed receipt | cannot be returned so the UA chooses not to process the message content itself. The | "unexpected-processing-error" should be used when an actual error is encountered | when processing the message content. 5.3.1 Message Disposition Notification Extension Fields The following "extension fields" will be added in order to support signed receipts for RFC 1767 MIME content types and multi-part MIME content types that include the RFC 1767 MIME content types. The "extension fields" defined below follow the "dispostion-field" in the MDN. The "X-Disposition-qualifier-field" is used to further qualify the value | in the "disposition-field". The value of the "X-Disposition-qualifier-field" | have defined values, but can also be used by implementations to support mutually | agreed to values. | - extension field = "X-" "Disposition-qualifier-field" ":" value | where the defined value is: | "autoprocessed" - The message has been processed automatically | in some manner (e.g., printed, faxed, forwarded, gatewayed) | in response to some user request made in advance, without | being displayed to the user. The user may or may not see | the message later. The "X-Received-content-MIC" extension field is set when the integrity of the received message is verified. The MIC or message integrity check, is defined as a result of a one-way hash function applied to the received RFC 1767 MIME content, or a multi-part MIME content containing RFC 1767 MIME content. The MIC is applied to the MIME headers as well as the content. This field is set only when the contents of the message are processed successfully. This field is used in conjunction with the receiver's signature on the MDN in order for "non-repudiation of receipt" to occur on the sender's side. - extension field = "X-" "Received-content-MIC" ":" MIC The "X-Signed-receipt-disposition" extension field is set when a request for a signed receipt is made by the sender, but cannot be returned by the receiver. - extension field = "X-" "Signed-receipt-disposition": signed-receipt-disposition where signed-receipt-disposition is: "unsupported-format" - A request for a signed receipt cannot be returned because the requested format is not supported. "unexpected-error" - A catch-all for errors that prevent a signed receipt from being returned when it has been requested. 5.4 Message Disposition Notification Processing 5.4.1 Large File Processing Large EDI Interchanges sent via SMTP can be automatically fragmented by some message transfer agents. A subtype of message, "partial", is defined in RFC 1521 to allow large objects to be delivered as separate pieces of mail and to be automatically reassembled by the receiving user agent. Using message, "partial", can help alleviate fragmentation of large messages by different message transfer agents, but does not completely eliminate the problem. It is still possible that a piece of a partial message, upon re-assembly, may prove to contain a partial message as well. This is allowed by the Internet standards, and it is the responsibility of the user agent to re-assemble the fragmented pieces. It is recommended that the size of the EDI Interchange sent via SMTP be configurable so that if fragmentation does occur, then message, "partial" can be used to send the large EDI Interchange in smaller pieces. RFC 2045 [1] defines the use of Content-Type: message/partial. Support of the message/partial content type for use in Internet EDI is optional. The receiving UA is required to re-assemble the original message before sending the message disposition notification to the original sender of the message. A message disposition notification is used to specify the disposition of the entire message that was sent, and should not be returned by a processing UA until the entire message is received, even if the received message requires re-assembling. In general, EDI content compresses well, since there is repetitive data in most EDI Interchanges. Instead of implementing the message/partial, compression of the EDI Interchange can be done after the signature is applied to the EDI Interchange, and before encryption. When no signature is applied, then compression is applied before the encryption. Compression is an alternative solution to implementing Content-Type: message/partial when sending large EDI Interchanges on the Internet. Applying compression before encryption strengthens cryptographic security since repetitious strings are reduced. This sequence of signature, compression, then encryption, or compression then encryption, is consistent with the order in which PGP implementations handle compression. Note: Compression is done automatically when using PGP. | The MIME standards [1], do not define a way in which to convey | that a message has been compressed. However, RFC 2045 [1] does allow the definition | of additional MIME header fields to further describe the content of a message. | RFC 2068 [11], the HTTP/1.1 specification does define a Content-Encoding field that | is primarily used to convey compression information: | Content-Encoding = "Content-Encoding" ":" content-coding | where content-coding can take on the values of "gzip" or "compress". | The gzip compression standard is furthur described in RFC 1952 [12], and compress | is the standard UNIX file compression program. Both "gzip" and "compress" are | registered with IANA. | Trading partners can adopt the use of the Content-Encoding header if they need to | compress their EDI data and convey the compression type to their trading partners. | 5.4.2 Example The following is an example of a signed receipt returned by a UA after successfully processing a MIME EDI content type. The sending trading partner has requested a return signed receipt. This example follows the S/MIME application/x-pkcs-7-signature format. NOTE: This example is provided as an illustration only, and is not considered part of the protocol specification. If an example conflicts with the protocol definitions specified above or in the other referenced RFCs, the example is wrong. To: Subject: From: Date: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="separator"; micalg=rsa-sha1; protocol="application/x-pkcs7-signature" --separator &Content-Type: multipart/report; report-type=disposition & notification; boundary = "xxxxx" & &--xxxxx & The message sent to Edi Recipient & has been received, the EDI Interchange was successfully & decrypted and its integrity was verified. In addition, the & sender of the message, Edi Sender & was authenticated as the originator of the message. There is & no guarantee however that the EDI Interchange was & syntactically correct, or was received by the EDI & application. & &--xxxxx & Content-Type: message/disposition-notification & & Reporting-UA: good-edi-internet-ua.edicorp.com (ediua 1.0) & Original-Recipient: rfc822; Edi_Recipient@edicorp.com & Final-Recipient: rfc822; Edi_Recipient@edicorp.com & Original-Message-ID: <17759920005.12345@edicorp.com> & Disposition: autoprocessed & X-Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ & &--xxxxx & To: & Subject: & . & . & &--xxxxx-- --separator Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: base64 @ContentType = SignedData @version = Version @digestAlgorithms = DigestAlgorithmIdentifiers @signerInfos = SignerInfo --separator-- Notes: -The lines preceded with "&" is what the signature is calculated over. -The text preceded by "@" indicates PKCS#7 defined fields and types. (For details on how to prepare the multipart/signed with protocol = "application/x-pkcs7-signature" see the "S/MIME Message Specification, PKCS Security Services for MIME" documentation.) Note: As specified by RFC 1892 [10], returning the original or portions of the original message in the third body part of the multipart/report is not required. This is an optional body part. It is recommended that the received headers from the original message be placed in the third body part, as it can be helpful in tracking problems. Also note that the textual first body part of the multipart/report can be used | to include a more detailed explanation of the error conditions reported by the | disposition headers. The first body part of the multipart/report when used in | this way, allows a person to better diagnose a problem in detail. | 6. Public key certificate handling 6.1 Near term approach In the near term, the exchange of public keys and certification of these keys must be handled as part of the process of establishing a trading partnership. The UA and/or EDI application interface must maintain a database of public keys used for encryption or signatures, in addition to the mapping between EDI trading partner ID and RFC 822 [3] email address. The procedures for establishing a trading partnership and configuring the secure EDI messaging system might vary among trading partners and software packages. For systems which make use of X.509 certificates, it is recommended that trading partners self-certify each other if an agreed upon certification authority is not used. It is highly recommended that when trading partners are using S/MIME, that they also exchange public key certificates using the recommendations specified in the S/MIME Implementation Guide Version 2. The message formats and S/MIME conformance requirements for certificate exchange are specified in this document. This applicability statement does NOT require the use of a certification authority. 6.2 Long term approach In the long term, additional Internet-EDI standards may be developed to simplify the process of establishing a trading partnership, including the third party authentication of trading partners, as well as attributes of the trading relationship. 7. Authors' Addresses Mats Jansson mjansson@agathon.com LiNK 2317 Broadway, Suite 330 Redwood City, CA 94063 USA Chuck Shih chucks@actracorp.com Actra Corp. 610 East Caribbean Drive Sunnyvale, CA 94089 USA Rik Drummond drummond@onramp.com The Drummond Group 5008 Bentwood Ct. Ft. Worth, TX 76132 USA 8. References [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 02, 1996. N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 02, 1996. N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049 , December 02, 1996. [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 2, 1995. [3] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 13, 1982. [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 2015, Sept. 1996. [5] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", draft-ietf-receipt-mdn-01.txt, May 13, 1996. [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct. 3, 1995 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1, 1982. [8] S. Dusse, "S/MIME Message Specification; PKCS Security Services for MIME", Internet draft: draft-dusse-mime-msg-spec 00.txt [9] C. Shih, "Requirements for Inter-operable Internet EDI", July 1996. [10] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 15, 1996. [11] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [12] L. Deutsch, "GZIP File Format Specification Version 4.3", RFC 1952, May 23, 1996. --------------B3272210C1-- From owner-ietf-ediint Sun Mar 2 16:10:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA09020 for ietf-ediint-bks; Sun, 2 Mar 1997 16:10:17 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA09016 for ; Sun, 2 Mar 1997 16:10:14 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA28867 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Sun, 2 Mar 1997 16:13:02 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA12836; Sun, 2 Mar 97 16:11:14 PST Date: Sun, 2 Mar 97 16:11:14 PST From: carl@chage.com (Carl Hage) Message-Id: <9703030011.AA12836@slick.chage.com> To: ietf-ediint@imc.org Subject: Revision of MDN Section of AS#1 Sender: owner-ietf-ediint@imc.org Precedence: bulk Oops, I forgot to ask in the prior message: What is the advantage of not signing an MDN? (Please explain you rationale of why it should be unsigned in the case of format difficulties.) I can only think of: - Software won't be confused by an unsupported format - The CPU time to generate a signature would be wasted - The receipt would be ugly-- cluttered with a weird looking sig - Don't ask, don't tell, don't do anything you weren't asked to In the first case, it would be wrong to implement software that would be confused. Since a sig was requested, presumably the sig multipart can be unwrapped. The more complex issue is when a sig is not requested but returned signed. I think the multipart form addresses this as best possible, and is generally upwards compatible with current non sig-aware email software. The second case is the perogative of the signer. The third case seems doesn't seem as important as the ability to verify a sig once software is installed (e.g. Windows-01 scheduled to come out in 4 years). The fourth case is a philosophy in life. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Sun Mar 2 15:59:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA08912 for ietf-ediint-bks; Sun, 2 Mar 1997 15:59:01 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA08908 for ; Sun, 2 Mar 1997 15:58:58 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA28309 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Sun, 2 Mar 1997 16:01:47 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA12651; Sun, 2 Mar 97 15:55:56 PST Date: Sun, 2 Mar 97 15:55:56 PST From: carl@chage.com (Carl Hage) Message-Id: <9703022355.AA12651@slick.chage.com> To: ietf-ediint@imc.org Subject: Re: Revision of MDN Section of AS#1 Sender: owner-ietf-ediint@imc.org Precedence: bulk The latest version is looking good-- very close to complete. >From chucks@actracorp.com (Chuck Shih): >I have re-worded both 2.2.3 and added 5.2.1 to clarify how to handle the >situation when a signature is not explicitly requested. I disagree with >you on this point, and the list should comment. My opinion is that if a >signature is not explicitly requested, or parameters are not recognized, >that an unsigned MDN should be returned. Although the Fajman spec states >that all bets are off, I think that within Internet EDI an unsigned MDN >should always be returned in these situations. Let me explain my rationale. Consider the paper analogy. Suppose you get a form that requires the signature of your parents. You might not be able to comply, e.g. you might return the form signed by the director of an orphanage, but you wouldn't return the form unsigned. Likewise, the "signature" might be a rubber stamp, or whatever is actually appropriate. If the UPS driver delivers a package and gives it to a neighbor, the neighbor's signature is returned instead of an unsigned receipt. In essence, a request for signed receipt means you want (for both verification and non-repudiation) a receipt, certified that the message was received by a unique signature. If the format requested cannot be complied with, then a certified receipt can still be returned with a unique signature. Non-repudiation still applies as long as a unique signature is attached. The signature could still be verified after the fact. If a signature were always returned as a policy (whether requested or not), then any false unsigned receipt is implicitly repudiated. On the other hand, if unsigned "official" messages are returned automatically, then this complicates auditing and repudiation issues. The MIME multipart/signed format allows a signature to be trivially stripped and ignored if that is unimportant or undecodable. Thus it is easy to ignore a signature present, but hard to get back a signature that was omitted. Normally, should this condition occur (e.g. probably something outside the traditional EDI with complex TP agreements) the resolution would probably be that one or the other parties would install compatible software. This is more likely to be software to validate a signature, rather than generate a signature, since one's signature is determined by hardware and public keys selected by the signer. If we assume a site installs software to authenticate the signatures generated by thier TP, then previously unverifyable signed messages can then be authenticated without have to have the messages reissued or regenerated. Thus, the rule that says returning a signed receipt is not allowed doesn't make sense to me. The rule should be that all email systems should be able to read (not necessarily verify) any message or receipt signed in a multipart/signed form, rather than saying signatures are prohibited in certain cases. In other words, the use of a signature should be the perogative of the signer, while the acceptance or validation of a signature is up to the reader. By wording the spec so it says that signatures are possible in cases where the requested format cannot be processed, then it means that software won't die in cases where part 2 of a multipart/signed isn't a particular application type. It's a bad idea to build software that relies on a signature not being present. -------------------------------------------------------------------------- - For unsigned, unencrypted messages, the MIC should be calculated over the message | body without the MIME Content-Type, or MIME Content-Transfer-Encoding, or any | other RFC 822 headers, since these are sometimes altered or reordered by MTAs. How about a slightly more clear: - For unsigned, unencrypted messages, the MIC should be calculated over the message body prior to Content-Transfer-Encoding or Content-Encoding, and without the MIME or any other RFC 822 headers, since these are sometimes altered or reordered by MTAs. When MIME headers are included, the MIC is calculated over contents after Content-Transfer-Encoding, whereas without MIME headers, the "content" refers to the data prior to MIME processing. In other words, the Content-Encoding compression, base64/quoted Content-Transfer-Encoding, and the addition of MIME headers are considered a single transformation, and the MIC scope applies either before or after this transformation. --- Note: Compression is done automatically when using PGP. should be Note: Compression is done automatically when using PGP encryption. (doesn't apply to unencrypted messages, e.g. a catalog posted to an elist) --- &Content-Type: multipart/report; report-type=disposition & notification; boundary = "xxxxx" & &--xxxxx & The message sent to Edi Recipient ... &--xxxxx & To: Oops!! Parts 1 and 3 of multipart/report need MIME headers, e.g. plain text for the top part, and message/rfc822 for the third, in this case. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Mon Mar 3 11:16:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA22063 for ietf-ediint-bks; Mon, 3 Mar 1997 11:16:00 -0800 (PST) Received: from gatekeeper.premenos.com (mail.premenos.com [150.105.250.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA22058 for ; Mon, 3 Mar 1997 11:15:57 -0800 (PST) Received: from localhost (smap@localhost) by gatekeeper.premenos.com (8.6.5/8.6.5) id LAA29424; Mon, 3 Mar 1997 11:21:51 -0800 Received: from karenr.premenos.com(150.105.100.205) by mail.premenos.com via smap (V1.3mjr) id sma029406; Mon Mar 3 11:21:23 1997 Message-ID: <331AF9A4.5D35@premenos.com> Date: Mon, 03 Mar 1997 11:17:40 -0500 From: Karen Rosenthal Reply-To: karenr@premenos.com Organization: Premenos X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: chucks@actracorp.com CC: ietf-ediint@imc.org, edipilot@commerce.net Subject: Re: Revision of MDN Section of AS#1 References: <9702282105.AA11179@slick.chage.com> <33192B9E.3430@actracorp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Chuck Shih wrote: > > Carl Hage wrote: > > > > I don't like the idea of defining undefined headers. This is contrary to the > > purpose of standards. Aren't there some obvious values that can be defined > > now and implemented by the vendors? > > > > A list of values might be better. Not all conditions can be defined with > > a single word. Allowing multiple words provides a means to convey semantics > > for more than one function. > > The only value that has been brought up in the discussion is Dale's, and > that would be autoprocessed. The list feels that a qualifier field on > the dispostion field is preferable to allowing a list of disposition > fields, primarily because it is easier to process. The semantics of a > list of disposition values can become fairly complex. I think the concept of the X-Disposition-Qualifier-Field has mutated since our phone edipilot phone discussion. My understanding of the implementation this field was to be used only as a 'text elaboration' of the disposition field. I understand Carl's reaction to using an unstandardized field in this manner, but it during discussion it did seem to adequately address the business issue brought up by Dale. My understanding of its usage was solely for human readable 'text' only - not for a program's decision making. An application could stuff this field into a DB / storage field for human review. In our phone discussion, it was agreed that we'd add another disposition (i.e. autoprocessed-with-warning), and allow the warning description to be put in the X-Disposition-Qualifier-Field. Then, an application could decide how it was to handle autoprocessed-with-warning(s). Additionally, all dispositions could be elaborated on, i.e. 'notprocessed' with an X-Disposition-Qualifier-Field of 'rejected'. But regardless of the entry in the X-Disposition-Qualifier-Field, an application's decision making would be based SOLELY on the disposition field. I have a real concern with the draft's example of putting 'autoprocessed' into the X-Disposition-Qualifier-Field along with a disposition of 'authentication-failed', for example. Now we're taking an unstandardized field (X-Disposition-Qualifier-Field), and giving it a weight (autoprocessed) that should be programmically addressed. If we're going to give the X-Disposition-Qualifier-Field programmable weight, we need to standardize it. > I have re-worded both 2.2.3 and added 5.2.1 to clarify how to handle the > situation when a signature is not explicitly requested. I disagree with > you on this point, and the list should comment. My opinion is that if a > signature is not explicitly requested, or parameters are not recognized, > that an unsigned MDN should be returned. Although the Fajman spec states > that all bets are off, I think that within Internet EDI an unsigned MDN > should always be returned in these situations. > > I also believe that only when a signature request is explicitly made, > and that the format can be supported by the recipient, then and only > then should a signed-receipt be returned. > > I also don't think we should require a UA to extract the report from a > multipart/signed if it does not process outgoing signatures or request > incoming signed receipt. > I think 'all bets are off' is as far as we should go. There is no reason why the EDI draft should prohibit a business that wants to sign all of its receipts, from doing so. If a UA cannot extract the report from multipart/signed, then it's not compliant with MIME-based Secure EDI. Regards, -- Name: Karen Rosenthal E-mail: karenr@premenos.com Phone: (510)688-2928 Fax: (510)602-2133 From owner-ietf-ediint Mon Mar 3 11:19:28 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA22129 for ietf-ediint-bks; Mon, 3 Mar 1997 11:19:28 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA22117 for ; Mon, 3 Mar 1997 11:19:25 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA16361 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Mon, 3 Mar 1997 11:22:10 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA13362; Mon, 3 Mar 97 11:16:11 PST Date: Mon, 3 Mar 97 11:16:11 PST From: carl@chage.com (Carl Hage) Message-Id: <9703031916.AA13362@slick.chage.com> To: ietf-ediint@imc.org Subject: MIC definition has problems Sender: owner-ietf-ediint@imc.org Precedence: bulk One more thing I noticed. The definition: - extension field = "X-" "Received-content-MIC" ":" MIC is ambiguous and incomplete. The definition "a one-way hash function" doesn't specify which one-way has function, nor how the value is encoded, e.g. hex or base64. ---------------- Background Info: ---------------- PGP uses MD5, PKCS7 and MOSS mention MD2 and MD5. Somewhere I've seen SHA. IANA doesn't seem to have anything useful, and the micalgid assignments don't seem like they are being updated. MOSS (RFC1848) defines: ::= "MIC-Info:" "," "," CRLF where the misleading name "MIC-Info" really means "digital signature". In the MIME multipart/signed (RFC1847), there is also a micalgid: Content-Type: multipart/signed; protocol="TYPE/STYPE"; micalg="MICALG"; boundary="Signed Boundary" parameter := "micalg" "=" value The Message Integrity Check (MIC) is the name given to the quantity computed over the body part with a message digest or hash function, in support of the digital signature service. Valid value tokens are defined by the specification for the value of the protocol parameter. The value may be a comma (",") separated list of tokens, indicating the use of multiple MIC algorithms. As a result, the comma (",") character is explicitly excluded from the list of characters that may be included in a token used as a value of the micalg parameter. ----------- Solutions: ------------ Perhaps what you mean by MIC is the hex coded value computed using the same micalg used in the original multipart/signed, for the case where a signature is present. If no signature is present, I suggest this RFC specify that the "rsa-md5" micalg is recommended. (MD5 is the common algorithm for PGP and S/MIME, and is used in other RFCs.) In order to interpret the MIC value, the algorithm must be fixed or specified as a parameter. It's a bad idea to require a third piece of data (the original signature) to be accessed in order to provide meaning to the value. Since RFC1847 allows comma separated micalgs, one possibility is: - extension field = "X-" "Received-content-MIC" ":" = "," = the result of the one way hash function, coded as hexadecimal digits. = the micalg value defined in RFC1847, an IANA registered MIC algorithm ID token, or a comma separated list of tokens. Alternatively a "parameter=value; parameter=value;" form could be used. Example: X-Received-content-MIC: f4e260bc0f96adf609caad45517dcd9d, rsa-md5 -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Mon Mar 3 12:29:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA23284 for ietf-ediint-bks; Mon, 3 Mar 1997 12:29:39 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA23280 for ; Mon, 3 Mar 1997 12:29:36 -0800 (PST) Received: from drummond.onramp.net (r37p7.onramp.net [206.50.173.7]) by mailhost.onramp.net (8.8.5/8.6.5) with SMTP id OAA14322; Mon, 3 Mar 1997 14:32:22 -0600 (CST) Message-ID: <331B3437.4010@onramp.net> Date: Mon, 03 Mar 1997 14:27:35 -0600 From: Rik Drummond X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: karenr@premenos.com CC: chucks@actracorp.com, ietf-ediint@imc.org, edipilot@commerce.net Subject: Re: Revision of MDN Section of AS#1 References: <9702282105.AA11179@slick.chage.com> <33192B9E.3430@actracorp.com> <331AF9A4.5D35@premenos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Karen Wrote: >I think the concept of the X-Disposition-Qualifier-Field has mutated >since our phone edipilot phone discussion. My understanding of the >implementation this field was to be used only as a 'text elaboration' of >the disposition field. I understand Carl's reaction to using an >unstandardized field in this manner, but it during discussion it did >seem to adequately address the business issue brought up by Dale. My >understanding of its usage was solely for human readable 'text' only - >not for a program's decision making. An application could stuff this >field into a DB / storage field for human review. Karen has a good memory.... We agreed that it was only for text elaboration, at least over the short term because error codes which have real debug meaning only get defined in the second generation after we find all the error conditions.. not in the first generation. The field is for trading partner debug conditions and is not for machine readable stuff... later...rik From owner-ietf-ediint Mon Mar 3 14:14:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA24915 for ietf-ediint-bks; Mon, 3 Mar 1997 14:14:31 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA24910 for ; Mon, 3 Mar 1997 14:14:27 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA695; Mon, 3 Mar 1997 14:16:12 -0800 Message-ID: <331B4C6E.58D6@actracorp.com> Date: Mon, 03 Mar 1997 14:10:54 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: karenr@premenos.com, carl@chage.com CC: ietf-ediint@imc.org, edipilot@commerce.net Subject: Re: Revision of MDN Section of AS#1 References: <9702282105.AA11179@slick.chage.com> <33192B9E.3430@actracorp.com> <331AF9A4.5D35@premenos.com> Content-Type: multipart/mixed; boundary="------------44057037798C" Sender: owner-ietf-ediint@imc.org Precedence: bulk This is a multi-part message in MIME format. --------------44057037798C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Karen and Carl, Newest revision. I have: a). Allowed the sending of signed receipts when the signed receipts are not explicitly requested, or as a matter of policy, wherein signed receipts are always returned as a business practice. This is in 2.2.3 and 5.2.1. There seems to be some general consensus on this point. Hopefully others weigh in with their opinions. b). The "diposition-qualifier-field" has been refined to specify its original intent, although I do define a "none" value. c). The "X-Received-content-MIC" has been updated to allow the return of the MIC algorithm used, and clarified with recommendations on what MIC algorithm to use if the original message was not signed. d). Miscellaneous updates: put content-type of message/rfc822 nad text/plain in the example. Please review and send comments. I would like to freeze the draft tomorrow and get it posted, so more people may be inclined to look it over. Thanks for all the comments however. > > +----------------------------------------------------------------------+ > This message was addressed to: edipilot@lists.commerce.net > +----------------------------------------------------------------------+ > > Chuck Shih wrote: > > > > Carl Hage wrote: > > > > > > I don't like the idea of defining undefined headers. This is contrary to the > > > purpose of standards. Aren't there some obvious values that can be defined > > > now and implemented by the vendors? > > > > > > A list of values might be better. Not all conditions can be defined with > > > a single word. Allowing multiple words provides a means to convey semantics > > > for more than one function. > > > > The only value that has been brought up in the discussion is Dale's, and > > that would be autoprocessed. The list feels that a qualifier field on > > the dispostion field is preferable to allowing a list of disposition > > fields, primarily because it is easier to process. The semantics of a > > list of disposition values can become fairly complex. > > I think the concept of the X-Disposition-Qualifier-Field has mutated > since our phone edipilot phone discussion. My understanding of the > implementation this field was to be used only as a 'text elaboration' of > the disposition field. I understand Carl's reaction to using an > unstandardized field in this manner, but it during discussion it did > seem to adequately address the business issue brought up by Dale. My > understanding of its usage was solely for human readable 'text' only - > not for a program's decision making. An application could stuff this > field into a DB / storage field for human review. In our phone > discussion, it was agreed that we'd add another disposition (i.e. > autoprocessed-with-warning), and allow the warning description to be put > in the X-Disposition-Qualifier-Field. Then, an application could decide > how it was to handle autoprocessed-with-warning(s). Additionally, all > dispositions could be elaborated on, i.e. 'notprocessed' with an > X-Disposition-Qualifier-Field of 'rejected'. But regardless of the > entry in the X-Disposition-Qualifier-Field, an application's decision > making would be based SOLELY on the disposition field. > > I have a real concern with the draft's example of putting > 'autoprocessed' into the X-Disposition-Qualifier-Field along with a > disposition of 'authentication-failed', for example. Now we're taking > an unstandardized field (X-Disposition-Qualifier-Field), and giving it a > weight (autoprocessed) that should be programmically addressed. If > we're going to give the X-Disposition-Qualifier-Field programmable > weight, we need to standardize it. > > > I have re-worded both 2.2.3 and added 5.2.1 to clarify how to handle the > > situation when a signature is not explicitly requested. I disagree with > > you on this point, and the list should comment. My opinion is that if a > > signature is not explicitly requested, or parameters are not recognized, > > that an unsigned MDN should be returned. Although the Fajman spec states > > that all bets are off, I think that within Internet EDI an unsigned MDN > > should always be returned in these situations. > > > > I also believe that only when a signature request is explicitly made, > > and that the format can be supported by the recipient, then and only > > then should a signed-receipt be returned. > > > > I also don't think we should require a UA to extract the report from a > > multipart/signed if it does not process outgoing signatures or request > > incoming signed receipt. > > > > I think 'all bets are off' is as far as we should go. There is no > reason why the EDI draft should prohibit a business that wants to sign > all of its receipts, from doing so. If a UA cannot extract the report > from multipart/signed, then it's not compliant with MIME-based Secure > EDI. > > Regards, > -- > Name: Karen Rosenthal > E-mail: karenr@premenos.com > Phone: (510)688-2928 > Fax: (510)602-2133 > ------------------------------------------------------------------------- > This message was sent by a majordomo-based automatic list manager. > Subscriptions to and archives of this list are available to CommerceNet > members, partners, and invited guests. For further information send a > mail message to 'edipilot-request@lists.commerce.net' with 'help' > (no quotations) contained in the body of your message. --------------44057037798C Content-Type: text/plain; charset=us-ascii; name="assend.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="assend.txt" INTERNET DRAFT Mats Jansson, LiNK draft-ietf-ediint-as1-04.txt Chuck Shih, Actra Rik Drummond, Drummond Group 24 February, 1997 MIME-based Secure EDI 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 document describes how to securely exchange EDI documents using MIME and public key cryptography. Feedback Instructions: If you want to provide feedback on this draft, follow these guidelines: -Send feedback via e-mail to the ietf-ediint list for discussion, with "AS#1" in the Subject field. To enter/follow the discussion, you need to subscribe at ietf-ediint@imc.org. -Be specific as to what section you are referring to, preferably quoting the portion that needs modification, after which you state your comments. -If you are recommending some text to be replaced with your suggested text, again, quote the section to be replaced, and be clear on the section in question. Table of Contents 1. Introduction 2. Overview 2.1 Purpose of a security guideline for MIME EDI 2.2 Definitions 2.2.1 Terms 2.2.2 The secure transmission loop 2.2.3 Definition of receipts 2.3 Assumptions 2.3.1 EDI process assumptions 2.3.2 Flexibility assumptions 3. Referenced RFCs and their contribution 3.1 RFC 821 SMTP [7] 3.2 RFC 822 Text Message Format [3] 3.3 RFC 1847 MIME Security Multiparts [6] 3.4 RFC 1892 Multipart/report [9] 3.5 RFC 1767 EDI Content [2] 3.6 RFC 2015 PGP/MIME [4] 3.7 RFC 2045,2046, and 2049 MIME [1] 3.8 Internet draft (fajman): Message Disposition Notification [5] 3.9 Internet draft (dusse): - S/MIME Specification [8] 4. Structure of an EDI MIME message - Applicability 4.1 Introduction 4.2 Structure of an EDI MIME message - PGP/MIME 4.2.1 No encryption, no signature 4.2.2 No encryption, signature 4.2.3 Encryption, no signature 4.2.4 Encryption, signature 4.3 Structure of an EDI MIME message - S/MIME 4.3.1 No encryption, no signature 4.3.2 No encryption, signature 4.3.3 Encryption, no signature 4.3.4 Encryption, signature 5. Receipts 5.1 Introduction 5.2 Requesting a signed receipt 5.2.1 Additional signed receipt considerations 5.3 Message Disposition Notification Format 5.3.1 Message Disposition Notification Extension Fields 5.4 Message Disposition Notification Processing 5.4.1 Large File Processing 5.4.2 Example 6. Public key certificate handling 6.1 Near term approach 6.2 Long term approach 7. Authors' Addresses 8. References 1. Introduction The authors would like to extend special thanks to Carl Hage for providing the team with valuable, and very thorough feedback. Without participants like Carl, these efforts become hard to complete in a way useful to the users of the technology. The authors would also like to thank Nancy Turaj for her help in editing portions of this document. Previous work on Internet EDI focused on specifying MIME content types for EDI data ([2] RFC 1767). This Applicability Statement expands on RFC 1767 to specify use of a comprehensive set of data security features, specifically data privacy, data integrity/authenticity, non-repudiation of origin and non- repudiation of receipt. This draft recognizes contemporary RFCs and Internet drafts and is attempting to "re-invent" as little as possible. With an enhancement in the area of "receipts", as described below (3.1.8), secure Internet MIME based EDI can be accomplished by using and complying with the following RFCs and drafts: -RFC 821 SMTP -RFC 822 Text Message Formats -RFC 1767 EDI Content Type -RFC 1847 Security Multiparts for MIME -RFC 1892 Multipart/Report -RFC 2015 MIME/PGP (elkins) -RFC 2045 to 2049 MIME RFCs -Internet draft: Message Disposition Notification (fajman) -Internet draft: S/MIME Specification (dusse) Our intent here is to define clearly and precisely how these are used together, and what is required by user agents to be compliant with this Applicability Statement. 2. Overview 2.1 Purpose of a security guideline for MIME EDI The purpose of these specifications is to ensure interoperability between EDI user agents, invoking some or all of the commonly expected security features. This standard is also NOT limited to strict EDI use, but applies to any electronic commerce application where business data needs to be exchanged over the Internet in a secure manner. 2.2 Definitions 2.2.1. Terms EDI Electronic Data Interchange EC Electronic Commerce Receipt The functional message that is sent from a receiver to a sender to acknowledge receipt of an EDI/EC interchange Signed Receipt Same as above, but with a digital signature Message Disposition The way by which a receipt or a signed Notification (MDN) receipt is accomplished within Internet Messaging. Non-repudiation of NRR is a "legal event" that occurs when the Receipt (NRR) original sender of an EDI/EC interchange has verified the signed receipt coming back from the receiver. NRR IS NOT a functional or a technical message. PGP/MIME Digital envelope security based on the Pretty Good Privacy (PGP) standard (Zimmerman), integrated with MIME Security Multiparts [6]. S/MIME A format and protocol for adding cryptographic signature and/or encryption services to Internet MIME messages. 2.2.2 The secure transmission loop The functional requirements document, [9] "Requirements for Inter- operable Internet EDI" (can be found at www.ietf.org),provides extensive information on EDI security and the user/business related processes surrounding the need for and use of EDI security. In this document, it is assumed that the reader is familiar with the requirements document. This document's focus is on the formats and protocols for exchanging EDI content that has had security applied to it using the Internet's messaging transport. The "secure transmission loop" for EDI involves one organization sending a signed and encrypted EDI interchange to another organization, requesting a "signed receipt", followed later by the receiving organization sending this "signed receipt" back to the sending organization. In other words, the following transpires: -The organization sending EDI/EC data encrypts the data and provides a digital signature, using either PGP/MIME or S/MIME. In addition, they request a "signed receipt". -The receiving organization decrypts the message and verifies the signature, resulting in verified integrity of the data and authenticity of the sender. -The receiving organization then sends a "signed receipt" in the form of a signature over the hash from the previous step. The above describes functionality which if implemented, would satisfy all security requirements. This specification, however, leaves full flexibility for users to decide the degree to which they want to deploy those features with their EDI trading partners. 2.2.3 Definition of receipts The term used for both the functional activity and message for acknowledging receipt of an EDI/EC interchange is "receipt", or "signed receipt". The first term is used if the acknowledgment is for an interchange resulting in a receipt which is NOT signed. The second term is used if the acknowledgment is for an interchange resulting in a receipt which IS signed. The "rule" is: If a receipt | is requested, explicitly specifying that the receipt be | signed, then the receipt indeed has to be returned with a signature. | If a receipt is requested, explicitly specifying that the receipt | be signed, but the recipient cannot support the requested | signature format, then a receipt, either signed or unsigned should be returned. | If a signature is not explicitly requested, or if the signed receipt | request parameter is not recognized by the UA, all bets are off. This is | consistent with the MDN draft. | A term often used in combination with receipts is "Non-repudiation of Receipt (NRR). NRR refers to a legal event which occurs only when the original sender of an interchange has verified the sender and content of a "signed receipt". Note that NRR is not possible without signatures. 2.3 Assumptions 2.3.1 EDI process assumptions -Encrypted object is an EDI Interchange This specification assumes that a typical EDI interchange is the lowest level object that will be subject to security features. In ANSI X12, this means anything between, and including segments ISA and IEA. In EDIFACT, this means anything between, and including, segments UNA/UNB and UNZ. In other words, the EDI interchanges including envelope segments remain intact and unreadable during secure transport. -EDI envelope headers are encrypted Congruent with the above statement, EDI envelope headers are NOT visible in the MIME package. In order to optimize VAN-to- Internet routing, work may need to be done in the future to define ways to pull out some of the envelope information to make them visible, however, this specification does not go into any detail on that. -X12.58 and UN/EDIFACT security considerations The most common EDI standards, ANSI X12 and EDIFACT, have defined internal provisions for security. X12.58 is the security mechanism for ANSI X12 and AUTACK provides security for EDIFACT. This specification DOES NOT dictate use or non-use of these security standards. They are both fully compatible, though possibly redundant, with this specification. 2.3.2 Flexibility assumptions -Encrypted or un-encrypted data This specification allows for EDI message exchange where the EDI data is either un-protected or protected by means of encryption. -Signed or un-signed data This specification allows for EDI message exchange with or without digital signature of the original EDI transmission. -Use of receipt or not This specification allows for EDI message transmission with or without a request for receipt notification. If a signed receipt notification is requested, however, a signature is required as part of the returned receipt, unless an error condition occurs in which a signed-receipt cannot be returned. In these cases an un-signed receipt or MDN should be returned with the correct "signed-receipt-disposition" value. -Formatting choices This specification defines use of two methods for formatting EDI contents that have security applied to it: -PGP/MIME -S/MIME This specification relies on the guidelines set forth in the RFC 2015, as reflected in [4] MIME Security with Pretty Good Privacy (PGP), and Internet draft [8] S/MIME Specification from RSA Security, Inc. (dusse) Compliance with this specification dictates that AT LEAST one of these methods is supported. -Hash function, message digest choices When signature is used, unless specified otherwise by the chosen method (PGP/MIME or S/MIME), the SHA1 checksum hash function is recommended. In summary, the following eight permutations are possible in any given trading relationship: (1) Sender sends un-encrypted data, does NOT request a receipt. (2) Sender sends un-encrypted data, requests a receipt. Receiver sends back a receipt. (3) Sender sends encrypted data, does NOT request a receipt. (4) Sender sends encrypted data, requests a receipt. Receiver sends back a receipt. (5) Sender sends signed data, does NOT request a signed or un-signed receipt. (6) Sender sends signed data, requests a signed or un-signed receipt. Receiver sends back a signed or un-signed receipt. (7) Sender sends encrypted and signed data, does NOT request a signed or un-signed receipt. (8) Sender sends encrypted and signed data, requests a signed or un-signed receipt. Receiver sends back a signed or un-signed receipt. NOTE: Users can choose any of the eight possibilities, but only example (8), when a signed receipt is requested, offers the whole suite of security features described in the "Secure transmission loop" above. 3. Referenced RFCs and their contribution 3.1 RFC 821 SMTP [7] This is the core mail transfer standard that all MTAs need to adhere to. 3.2 RFC 822 Text Message Format [3] Defines message header fields and the parts making up a message. 3.3 RFC 1847 MIME Security Multiparts [6] This document defines security multiparts for MIME: multipart/encrypted and multipart/signed. 3.4 RFC 1892 Multipart/report [10] This RFC defines the use of Multipart/report content type, something that the MDN draft (fajman) relies on for the receipt functionality. 3.5 RFC 1767 EDI Content [2] This RFC defines the use of content type "application" for ANSI X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and mutually defined EDI (application/EDI-Consent). 3.6 RFC 2015 PGP/MIME [4] This RFC defines the use of content types "multipart/encrypted", "multipart/signed", "application/pgp encrypted" and "application/pgp-signature" for defining MIME PGP content. 3.7 RFC 2045, 2046, and 2049 MIME [1] These are the basic MIME standards, upon which all MIME related RFCs build, including this one. Key contributions include definition of "content type" and sub-type "multipart", in addition to encoding guidelines, which establish 7-bit US-ASCII as the lowest common denominator used. 3.8 Internet draft (fajman): Message Disposition Notification [5] This Internet draft defines how a message disposition notification (MDN) is requested, and the structure of the MDN. NOTE: This is the only specification we were not able to take "as is". Extension field-names beginning with "X-" will not be defined as a standard field. MDN field names not beginning with "X- " need to be registered with the Internet Assigned Numbers Authority (IANA) and described in an RFC. The "X-" extension fields described in this document will be registered with IANA. 3.9 Internet draft (dusse): S/MIME Message Specification [8] This specification describes how MIME shall carry PKCS7 signature and envelope information. 4. Structure of an EDI MIME message - Applicability 4.1 Introduction The structures below are described hierarchically in terms of which RFC's are applied to form the specific structure. For details of how to code in compliance with all RFC's involved, turn directly to the RFC's referenced. The "requirements document" has several examples described in an Appendix for those interested. Also, these structures describe the initial transmission only. Receipts, and requests for receipts are handled in section 5. 4.2 Structure of an EDI MIME message - PGP/MIME 4.2.1 No encryption, no signature -RFC822/1521 -RFC1767 (application/EDIxxxx) 4.2.2 No encryption, signature -RFC822/1521 -RFC1847 (multipart/signed) -RFC1767 (application/EDIxxxx) -RFC2015 (application/pgp-signature) 4.2.3 Encryption, no signature -RFC822/1521 -RFC1847 (multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version 1" -RFC1767 (application/EDIxxxx) (encrypted) 4.2.4 Encryption, signature -RFC822/1521 -RFC1847 (multipart/encrypted) -RFC2015 (application/pgp-encrypted) -"Version 1" -RFC1847 (multipart/signed) (encrypted) -RFC1767 (application/EDIxxxx) (encrypted) 4.3 Structure of an EDI MIME message - S/MIME 4.3.1 No encryption, no signature -RFC822/1521 -RFC1767 (application/EDIxxxx) 4.3.2 No encryption, signature -RFC822/1521 -RFC1847 (multipart/signed) -RFC1767 (application/EDIxxxx) -Draft (dusse) (application/x-pkcs7-signature) 4.3.3 Encryption, no signature -RFC822/1521 -Draft (dusse) (application/x-pkcs7-mime) -RFC1767 (application/EDIxxxx) (encrypted) 4.3.4 Encryption, signature -RFC822/1521 -Draft (dusse) (application/x-pkcs7-mime) -RFC1847 (multipart/signed) (encrypted) -RFC1767 (application/EDIxxxx) (encrypted) -Draft (dusse) (application/x-pkcs7-signature) (encrypted) 5. Receipts 5.1 Introduction In order to support non-repudiation of receipt (NRR), a signed receipt, based on digitally signing a message disposition notification, is to be implemented by a receiving trading partner's UA (User Agent). The message disposition notification, specified by draft-ietf-receipt-mdn-02.txt is digitally signed by a receiving trading partner and returned to the sending trading partner as part of a multipart/signed MIME message. The required support for signed receipts when doing Internet EDI is as follows: 1). Create a multipart/report; report-type = disposition-notification. 2). Calculate the MIC on the message disposition notification. 3). Digitally sign the MIC. 4). Create a multipart/signed content with the message disposition notification as the first body part, and the signed MIC calculated on the message disposition notification as the second body part. 5). Return the signed receipt to the sending trading partner. The signed receipt is used to notify a sending trading partner that requested the signed receipt that: 1). The receiving trading partner acknowledges receipt of the sent EDI Interchange. 2). If the sent message was signed, then the receiving trading partner has authenticated the sender of the EDI Interchange. 3). If the sent message was signed, then the receiving trading partner has verified the integrity of the received EDI Interchange. Regardless of whether the EDI Interchange was sent in S/MIME or PGP/MIME format, the receiving trading partner's UA must provide the following basic processing: 1). If the sent EDI Interchange is encrypted, then the encrypted symmetric key and initialization vector (if applicable) is decrypted using the receiver's private key. 2). The decrypted symmetric encryption key is then used to decrypt the EDI Interchange. 3). The receiving trading partner authenticates signatures in a message using the sender's public key. The authentication algorithm performs the following: a). The message integrity check (MIC or Message Digest), is decrypted using the sender's public key. b). A MIC on the signed contents (the MIME header and encoded EDI object, as per RFC 1767) in the message received is calculated using the same one-way hash function that the sending trading partner used. c). The MIC extracted from the signature is compared with the MIC calculated using the same one-way hash function that the sending trading partner used. 4). The receiving trading partner formats the MDN and sets the calculated MIC into the "X-Received-content-MIC" extension field. 5). The receiving trading partner creates a multipart/signed MIME message according to RFC 1847. 6). The MDN is the first part of the multipart/signed message, and the digital signature is created over this MDN, including its MIME headers. 7). The second part of the multipart/signed message contains the digital signature. The "protocol" option specified in the second part of the multipart/signed is as follows: S/MIME: protocol = "application/pkcs-7-signature" PGP/MIME: protocol = "application/pgp-signature" 8). The signature information is formatted according to S/MIME or PGP/MIME specifications. The EDI Interchange and the RFC 1767 MIME EDI content header, can actually be part of a multi-part MIME content-type. When the EDI Interchange is part of a multi-part MIME content-type, the MIC is calculated across the entire multi-part content, including the MIME headers. The multi-part MIME content that contains the EDI Interchange is then enveloped in either S/MIME or PGP/MIME format. The signed MDN, when received by the sender of the EDI Interchange can then be used by the sender: 1). As an acknowledgment that the EDI Interchange sent, was delivered and acknowledged by the receiving trading partner. The receiver does this by returning the original message id of the sent message in the MDN portion of the signed receipt. 2). As an acknowledgment that the integrity of the EDI Interchange was verified by the receiving trading partner. The receiver does this by returning the calculated MIC of the received EDI Interchange (and 1767 MIME headers) in the "X-Received-content-MIC" field of the signed MDN. 3). As an acknowledgment that the receiving trading partner has authenticated the sender of the EDI Interchange. 4). As a non-repudiation of receipt when the signed MIC calculated over the MDN, is successfully decrypted by the sender with the receiving trading partner's public key. 5.2 Requesting a signed receipt Message Disposition Notifications are requested as per draft-ietf- receipt-mdn-02.txt, "An Extensible Message Format for Message Disposition Notification". A request that the receiving user agent issue a message disposition notification is made by placing the following header into the message to be sent: mdn-request-header = "Disposition-notification-to" ":" mail-address The mail-address field is specified as an RFC 822 user@domain address, and is the return address for the message disposition notification. In addition to requesting a message disposition notification, a message disposition notification that is digitally signed, or what has been referred to as a signed receipt, can be requested by placing the following in the message header following the "Disposition-notification-to" line: Disposition-notification-options = "Disposition-notification-options" ":" disposition-notification-parameters Where disposition-notification-parameters = signed-receipt-protocol=O, ; The currently supported values for are "x-pkcs7-signature", for the S/MIME detached signature format, or "pgp-signature", for the pgp signature format. An example of a formatted options line would be as follows: Disposition-notification-options: signed-receipt-protocol=O, x-pkcs7-signature; The semantics of the "signed-receipt-protocol" parameter is as follows: 1). The "signed-receipt-protocol" parameter is used to request a signed receipt from the recipient trading partner. The "signed-receipt-protocol" parameter also specifies the format in which the signed receipt should be returned to the requester. The MIC algorithm and signature algorithm used in formulating the signed receipt are agreed to in the trading partner relationship. The actual algorithms used in the signed receipt are always returned as part of the signed receipt. 2). The "importance" attribute of "O" is defined in the MDN draft and has the following meaning: Parameters with an importance of "O" permit a UA that does not understand the "signed-receipt-protocol" parameter to still generate a MDN in response to a request for a MDN. A UA that does not understand the "signed-receipt-protocol" parameter, will obviously not return a signed receipt. The importance of "O" is used for the signed receipt parameters because it is desirable that an MDN be returned to the requesting trading partner even if the recipient could not sign it. The returned MDN will contain information on the disposition of the message as well as why the MDN could not be signed. See the disposition and extension fields in section 5.3 for more information. Within an EDI trading relationship, if a signed-receipt is expected and is not returned, then the validity of the transaction is up to the trading partners to resolve. In general, if a signed-receipt is required in the trading relationship and is not received, the transaction will likely not be considered valid. 5.2.1 Additional Signed Receipt Considerations The "rules" stated in Section 2.2.3 for signed receipts are as follows: | 1). When a receipt is requested, explicitly specifying that the receipt | be signed, then the receipt indeed has to be returned with a signature. | 2). When a receipt is requested, explicitly specifying that the receipt | be signed, but the recipient cannot support the requested | signature format, then either a signed or unsigned receipt should be | returned. 3). When a signature is not explicitly requested, or if the signed receipt | request parameter is not recognized by the UA, then all bets are off. | In this situation, no receipt, an unsigned receipt, or a signed receipt | may be returned by the recipient. | NOTE: For Internet EDI, it is recommended that when a signature is not | explicitly requested, or if parameters are not recognized, that the UA | send back at a minimum, an unsigned receipt. If a signed receipt however | was always returned as a policy, whether requested or not, then any false | unsigned receipts can be repudiated. | When a request for a signed receipt is made, but there is an error in processing the contents of the message, a signed receipt should still be returned. The request for a signed receipt should still be honored, though the transaction itself may not be valid. The reason for why the contents could not be processed should still be set in the "disposition-field". When a request for a signed receipt is made, then the calculation of the | "X-Received-content-MIC" should be as follows: | - For any signed messages, the MIC to be returned is calculated on the RFC 1767 | MIME header and content, or multipart MIME header and content. | - For encrypted, unsigned messages, the MIC to be returned is calculated on the | decrypted RFC 1767 MIME header and content, or multipart MIME header and content. | - For unsigned, unencrypted messages, the MIC should be calculated over the message | body prior to Content-Transfer-Encoding or Content-Encoding, and without the MIME | or any other RFC 822 headers, since these are sometimes altered or reordered by | MTAs. A new extension field that further qualifies the "disposition-field" is defined by this specification. The field "X-Disposition-qualifier-field" is used to convey additional error or status information on the value specified in the "disposition-field". Situations arise in EDI where even if a trading partner cannot be authenticated correctly, the trading partners still agree to continue processing the EDI transactions. Transaction reconciliation is done between the trading partners at a later time. The "X-Disposition-qualifier-field" allows for qualifying an "autoprocessed-with-warning" disposition value with a "X-Disposition-qualifier-field" of "authentication-failed" for instance. This use of a disposition qualifier value would convey in the above example, that even though authentication failed, the receiving trading partner still processed the received EDI transactions. 5.3 Message Disposition Notification Format The format of a message disposition notification is as specified in draft-ietf-receipt-mdn-02.txt. For use in Internet EDI the following format will be used: - content-type - per RFC 1892 and the ietf-receipt-mdn specification - reporting-ua-field - per ietf-receipt-mdn specification - mdn-gateway-field - per ietf-receipt-mdn specification - original-recipient-field - per ietf-receipt-mdn specification - final-recipient-field - per ietf-receipt-mdn specification - original-message-id-field - per ietf-receipt-mdn specification - disposition-field - for EDI use: "notprocessed" - The received content(s) was not processed. "autoprocessed" - The message has been processed automatically in some manner (e.g., printed, faxed, forwarded, gatewayed) in response to some user request made in advance, without being displayed to the user. The user may or may not see the message later. "autoprocessed-with-warning" - The message has been processed automatically | in some manner (e.g., printed, faxed, forwarded, | gatewayed) in response to some user request made | in advance, without being displayed to the user. | The user may or may not see the message later. | Additionally, the "disposition-qualifier-field" | may be set with a warning description. | "decryption-failed" - The receiver could not decrypt the contents. "authentication-failed" - The receiver could not authenticate the sender. "integrity-check-failed" - The receiver could not verify content integrity. "unexpected-processing-error" - A catch-all for additional processing errors. Note: The "notprocessed" disposition value should be used when the message content is being rejected or ignored, for instance if it is determined that a signed receipt cannot be returned so the UA chooses not to process the message content itself. The "unexpected-processing-error" should be used when an actual error is encountered when processing the message content. 5.3.1 Message Disposition Notification Extension Fields The following "extension fields" will be added in order to support signed receipts for RFC 1767 MIME content types and multi-part MIME content types that include the RFC 1767 MIME content types. The "extension fields" defined below follow the "disposition-field" in the MDN. The "X-Disposition-qualifier-field" is used to further qualify the value | in the "disposition-field". The value of the "X-Disposition-qualifier-field" | can be used to further describe the "autoprocessed-with-warning" disposition | value, or as further elaboration of any other "disposition-field". This field is | optional, and its only defined value is "none". | - extension field = "X-" "Disposition-qualifier-field" ":" value | where the defined value is: | "none" - The "disposition-field" is not qualified any further. | | The "X-Received-content-MIC" extension field is set when the integrity of the | received message is verified. The MIC is the hex coded quantity computed over | a "body part" with a message digest or hash function. For details of "what" | the "X-Received-content-MIC" should be calculated over, see Section 5.2.1. | The algorithm used to calculate the "X-Received-content-MIC" value should be | the same as the "micalg" value received in the multipart/signed. When no signature| is received, then it is recommended that the SHA1 algorithm be used to calculate | the "X-Received-content-MIC" value. | This field is set only when the contents of the message are processed | successfully. This field is used in conjunction with the recipient's signature | on the MDN in order for "non-repudiation of receipt" to occur on the sender's | side. - extension field = "X-" "Received-content-MIC" ":" MIC | where: | = "," | = the result of the one way hash function, coded | as hexadecimal digits. < micalg> = the micalg value defined in RFC1847, an IANA registered | MIC algorithm ID token. The "X-Signed-receipt-disposition" extension field is set when a request for a signed receipt is made by the sender, but cannot be returned by the receiver. - extension field = "X-" "Signed-receipt-disposition": signed-receipt-disposition where signed-receipt-disposition is: "unsupported-format" - A request for a signed receipt cannot be returned because the requested format is not supported. "unexpected-error" - A catch-all for errors that prevent a signed receipt from being returned when it has been requested. 5.4 Message Disposition Notification Processing 5.4.1 Large File Processing Large EDI Interchanges sent via SMTP can be automatically fragmented by some message transfer agents. A subtype of message, "partial", is defined in RFC 1521 to allow large objects to be delivered as separate pieces of mail and to be automatically reassembled by the receiving user agent. Using message, "partial", can help alleviate fragmentation of large messages by different message transfer agents, but does not completely eliminate the problem. It is still possible that a piece of a partial message, upon re-assembly, may prove to contain a partial message as well. This is allowed by the Internet standards, and it is the responsibility of the user agent to re-assemble the fragmented pieces. It is recommended that the size of the EDI Interchange sent via SMTP be configurable so that if fragmentation does occur, then message, "partial" can be used to send the large EDI Interchange in smaller pieces. RFC 2045 [1] defines the use of Content-Type: message/partial. Support of the message/partial content type for use in Internet EDI is optional. The receiving UA is required to re-assemble the original message before sending the message disposition notification to the original sender of the message. A message disposition notification is used to specify the disposition of the entire message that was sent, and should not be returned by a processing UA until the entire message is received, even if the received message requires re-assembling. In general, EDI content compresses well, since there is repetitive data in most EDI Interchanges. Instead of implementing the message/partial, compression of the EDI Interchange can be done after the signature is applied to the EDI Interchange, and before encryption. When no signature is applied, then compression is applied before the encryption. Compression is an alternative solution to implementing Content-Type: message/partial when sending large EDI Interchanges on the Internet. Applying compression before encryption strengthens cryptographic security since repetitious strings are reduced. This sequence of signature, compression, then encryption, or compression then encryption, is consistent with the order in which PGP implementations handle compression. Note: Compression is done automatically when using PGP encryption. | The MIME standards [1], do not define a way in which to convey that a message has been compressed. However, RFC 2045 [1] does allow the definition of additional MIME header fields to further describe the content of a message. RFC 2068 [11], the HTTP/1.1 specification does define a Content-Encoding field that is primarily used to convey compression information: Content-Encoding = "Content-Encoding" ":" content-coding where content-coding can take on the values of "gzip" or "compress". The gzip compression standard is furthur described in RFC 1952 [12], and compress is the standard UNIX file compression program. Both "gzip" and "compress" are registered with IANA. Trading partners can adopt the use of the Content-Encoding header if they need to compress their EDI data and convey the compression type to their trading partners. 5.4.2 Example The following is an example of a signed receipt returned by a UA after successfully processing a MIME EDI content type. The sending trading partner has requested a return signed receipt. This example follows the S/MIME application/x-pkcs-7-signature format. NOTE: This example is provided as an illustration only, and is not considered part of the protocol specification. If an example conflicts with the protocol definitions specified above or in the other referenced RFCs, the example is wrong. To: Subject: From: Date: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="separator"; micalg=rsa-sha1; protocol="application/x-pkcs7-signature" --separator &Content-Type: multipart/report; report-type=disposition & notification; boundary = "xxxxx" & &--xxxxx &Content-Type: text/plain & &The message sent to Edi Recipient &has been received, the EDI Interchange was successfully &decrypted and its integrity was verified. In addition, the &sender of the message, Edi Sender &was authenticated as the originator of the message. There is &no guarantee however that the EDI Interchange was &syntactically correct, or was received by the EDI &application. & &--xxxxx &Content-Type: message/disposition-notification & &Reporting-UA: good-edi-internet-ua.edicorp.com (ediua 1.0) &Original-Recipient: rfc822; Edi_Recipient@edicorp.com &Final-Recipient: rfc822; Edi_Recipient@edicorp.com &Original-Message-ID: <17759920005.12345@edicorp.com> &Disposition: autoprocessed &X-Disposition-qualifier-field: none &X-Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ & &--xxxxx &Content-Type: message/rfc822 & &To: &Subject: & & [additional header fields goes here] & &--xxxxx-- --separator Content-Type: application/x-pkcs7-signature Content-Transfer-Encoding: base64 @ContentType = SignedData @version = Version @digestAlgorithms = DigestAlgorithmIdentifiers @signerInfos = SignerInfo --separator-- Notes: -The lines preceded with "&" is what the signature is calculated over. -The text preceded by "@" indicates PKCS#7 defined fields and types. (For details on how to prepare the multipart/signed with protocol = "application/x-pkcs7-signature" see the "S/MIME Message Specification, PKCS Security Services for MIME" documentation.) Note: As specified by RFC 1892 [10], returning the original or portions of the original message in the third body part of the multipart/report is not required. This is an optional body part. It is recommended that the received headers from the original message be placed in the third body part, as it can be helpful in tracking problems. Also note that the textual first body part of the multipart/report can be used to include a more detailed explanation of the error conditions reported by the disposition headers. The first body part of the multipart/report when used in this way, allows a person to better diagnose a problem in detail. 6. Public key certificate handling 6.1 Near term approach In the near term, the exchange of public keys and certification of these keys must be handled as part of the process of establishing a trading partnership. The UA and/or EDI application interface must maintain a database of public keys used for encryption or signatures, in addition to the mapping between EDI trading partner ID and RFC 822 [3] email address. The procedures for establishing a trading partnership and configuring the secure EDI messaging system might vary among trading partners and software packages. For systems which make use of X.509 certificates, it is recommended that trading partners self-certify each other if an agreed upon certification authority is not used. It is highly recommended that when trading partners are using S/MIME, that they also exchange public key certificates using the recommendations specified in the S/MIME Implementation Guide Version 2. The message formats and S/MIME conformance requirements for certificate exchange are specified in this document. This applicability statement does NOT require the use of a certification authority. 6.2 Long term approach In the long term, additional Internet-EDI standards may be developed to simplify the process of establishing a trading partnership, including the third party authentication of trading partners, as well as attributes of the trading relationship. 7. Authors' Addresses Mats Jansson mjansson@agathon.com LiNK 2317 Broadway, Suite 330 Redwood City, CA 94063 USA Chuck Shih chucks@actracorp.com Actra Corp. 610 East Caribbean Drive Sunnyvale, CA 94089 USA Rik Drummond drummond@onramp.com The Drummond Group 5008 Bentwood Ct. Ft. Worth, TX 76132 USA 8. References [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 02, 1996. N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 02, 1996. N. Borenstein, N.Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049 , December 02, 1996. [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 2, 1995. [3] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 13, 1982. [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 2015, Sept. 1996. [5] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", draft-ietf-receipt-mdn-01.txt, May 13, 1996. [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Oct. 3, 1995 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1, 1982. [8] S. Dusse, "S/MIME Message Specification; PKCS Security Services for MIME", Internet draft: draft-dusse-mime-msg-spec 00.txt [9] C. Shih, "Requirements for Inter-operable Internet EDI", July 1996. [10] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 15, 1996. [11] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [12] L. Deutsch, "GZIP File Format Specification Version 4.3", RFC 1952, May 23, 1996. --------------44057037798C-- From owner-ietf-ediint Mon Mar 3 17:16:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA27177 for ietf-ediint-bks; Mon, 3 Mar 1997 17:16:23 -0800 (PST) Received: from yog.actracorp.com (h-205-217-242-6.netscape.com [205.217.242.6]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA27173 for ; Mon, 3 Mar 1997 17:16:20 -0800 (PST) Received: from cshih.actracorp.com ([205.217.242.69]) by yog.actracorp.com (Netscape Mail Server v2.02) with SMTP id AAA9342; Mon, 3 Mar 1997 17:17:36 -0800 Message-ID: <331B76F2.1A9B@actracorp.com> Date: Mon, 03 Mar 1997 17:12:18 -0800 From: chucks@actracorp.com (Chuck Shih) Reply-To: chucks@actracorp.com Organization: actra X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: ietf-ediint@imc.org, edipilot@commerce.net Subject: MIC Calculation and Multipart Boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk I am posting this in hopes that the implementers of multipart/signed all either use the following to calculate and verify the MICs when using multipart/signed, or tell the list how they are doing it, so we can confirm that we are calculating the MIC over the same thing: 1). Take the EDI content and transfer encode it using base64, for EDI data, this does the required canonicalization. 2). Formulate the MIME headers and embody the EDI content within the MIME headers. 3). Calculate the MIC over the MIME headers and the EDI content. 4). Send the message to the recipient. The recipient then does the following: 1). Canonicalize the base64 encoded content by converting all line delimiters to . 2). Scan for the multipart boundary and back-up either one or two bytes (to account for the , , or line delimiter that always precedes the boundary), to the end of the content. 3). Calculate the MIC on the MIME headers and the content arrived at by backing up the 1 to 2 bytes from the beginning of the first boundary hypen. An alternative to doing the above would be to canonicalize the line delimiter preceding the boundary, and always back up two bytes to find the end of the contents. From owner-ietf-ediint Tue Mar 4 07:08:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA05628 for ietf-ediint-bks; Tue, 4 Mar 1997 07:08:19 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA05624 for ; Tue, 4 Mar 1997 07:08:17 -0800 (PST) Received: from drummond.onramp.net (r37p10.onramp.net [206.50.173.10]) by mailhost.onramp.net (8.8.5/8.6.5) with SMTP id JAA18621 for ; Tue, 4 Mar 1997 09:11:12 -0600 (CST) Message-ID: <331C3B80.1094@onramp.net> Date: Tue, 04 Mar 1997 09:10:56 -0600 From: Rik Drummond Reply-To: drummond@onramp.net Organization: Drummond Group X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ietf-ediint@imc.org Subject: EDIINT - comments on AS#1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ediint@imc.org Precedence: bulk Please make the following changes to the as#1 draft as below. the sections 4.2.2, 4.3.2 and 4.3.4 are confussing in the current version. Later....rik 4.2.2 No encryption, signature -RFC822/1521 -RFC1847 (multipart/signed) -RFC2015 (application/pgp-signature) -RFC1767 (application/EDIxxxx) 4.3.2 No encryption, signature -RFC822/1521 -RFC1847 (multipart/signed) -Draft (dusse) (application/x-pkcs7-signature) -RFC1767 (application/EDIxxxx) 4.3.4 Encryption, signature -RFC822/1521 -Draft (dusse) (applicat