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. >