From owner-ietf-ediint@mail.imc.org Mon Oct 4 12:52:48 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22610 for ; Mon, 4 Oct 2004 12:52:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94Ggtk8057629; Mon, 4 Oct 2004 09:42:55 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i94GgtTF057628; Mon, 4 Oct 2004 09:42:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i94Ggs0J057595 for ; Mon, 4 Oct 2004 09:42:55 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 04 Oct 2004 12:42:52 -0400 id 003CC505.41617D8C.00003C59 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: ietf-ediint@imc.org Cc: "'Russ Housley'" Subject: FW: draft-ediint-certificate-exchange-00 Date: Mon, 4 Oct 2004 12:43:05 -0400 Message-ID: <7468147AEE316B41B3B55152959CE218129098@dul1wnexm05.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i94Ggt0J057622 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit WG members: Some follow-up on my own notes from a week or so ago. One of the security area directors also has questions about the ediint-certificate-exchange I-D. Would anyone care to respond to Russ' comment about PKIX overlap? -Scott- -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Wednesday, September 29, 2004 9:43 AM Subject: draft-ediint-certificate-exchange-00 The Abstract of this document says: "... EDIINT Certificate Exchange Messaging provides the format and means to effectively exchange certificates for use within trading partner relationships. ..." This seems to overlap with the charter of PKIX WG, and I do not think that an additional mechanism for certificate distribution is desirable. Can someone provide background that would make me fee comfortable about this work? Russ From owner-ietf-ediint@mail.imc.org Wed Oct 6 15:46:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28222 for ; Wed, 6 Oct 2004 15:46:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96JWmSY093390; Wed, 6 Oct 2004 12:32:48 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96JWmkD093389; Wed, 6 Oct 2004 12:32:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96JWlX3093382 for ; Wed, 6 Oct 2004 12:32:47 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26635; Wed, 6 Oct 2004 15:32:48 -0400 (EDT) Message-Id: <200410061932.PAA26635@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-ediint@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ediint-as2-17.txt Date: Wed, 06 Oct 2004 15:32:48 -0400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Electronic Data Interchange-Internet Integration Working Group of the IETF. Title : MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet Using HTTP Author(s) : D. Moberg, R. Drummond Filename : draft-ietf-ediint-as2-17.txt Pages : 42 Date : 2004-10-6 This document describes how to exchange structured business data securely using HTTP transfer for XML, Binary, Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, Electronic Data Interchange for Administration, Commerce and Transport) or other data describable in MIME used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements make use of multipart/signed replies to the original HTTP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-17.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ediint-as2-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ediint-as2-17.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-6151741.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ediint-as2-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ediint-as2-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-6151741.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ediint@mail.imc.org Wed Oct 6 17:52:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19930 for ; Wed, 6 Oct 2004 17:52:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96LcxH1004970; Wed, 6 Oct 2004 14:38:59 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i96Lcxnp004969; Wed, 6 Oct 2004 14:38:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i96LcxTm004963 for ; Wed, 6 Oct 2004 14:38:59 -0700 (PDT) (envelope-from apache@megatron.ietf.org) Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CFJHR-0001Lg-DE; Wed, 06 Oct 2004 17:25:01 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet Using HTTP' to Proposed Standard Reply-to: iesg@ietf.org CC: Message-Id: Date: Wed, 06 Oct 2004 17:25:01 -0400 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Electronic Data Interchange-Internet Integration WG to consider the following document: - 'MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet Using HTTP ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-10-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-17.txt From notice@computeradmin.org Thu Oct 7 06:56:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03350; Thu, 7 Oct 2004 06:56:20 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFW6G-00038T-I8; Thu, 07 Oct 2004 07:06:24 -0400 Received: from [210.123.198.1] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CFVwY-0007ep-DC; Thu, 07 Oct 2004 06:56:19 -0400 Received: from 8fl.sp1hr.com ([99.147.166.155]) by 65.246.255.50 id 3DsOexK9pU02; Thu, 07 Oct 2004 13:50:34 +0200 Message-ID: <70060-5-ib--0b2-e2$qp822f1@989only2> From: "Administrator" To: dcom@ietf.org Subject: ADV: Staff Annoucement Date: Thu, 07 Oct 04 13:50:34 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="F2AAAB_.35EB" X-Spam-Score: 27.9 (+++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --F2AAAB_.35EB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members and Staff You Must Respond By 5 P.M. Friday, October 8, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Nonprofit Members and Staff who respond to this message before 5 P.M., Friday, October 8, 2004 All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2005 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktops with the latest technology at an amazing price to all who call: 1-800-795-8466 by 5 P.M. Friday, October 8, 2004 The fast and powerful AT-3200 series Desktop features: * IBM Processor for amazing speed and performance * 128MB DDR RAM, -- Upgradeable to 1024 * 20 GB UDMA Hard Drive, -- Upgradeable to 80 GB * 52X CD-Rom Drive, -- Upgradeable to DVD/CDRW * Next Generation 2005 Technology * Premium video and sound -- For enhanced colors and graphics * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $499 ........................................ Your Cost $227 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-795-8466 by 5 P.M. Friday, October 8, 2004. and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. 6. Ask for Department C. Call Avtech Direct 1-800-795-8466 before 5 P.M. Friday, October 8, 2004 Visit our website at http://www.avtechdirectcomputers.com If you wish to unsubscribe from this list, please go to http://www.computeradvice.org/unsubscribelink.asp Avtech Direct 22647 Ventura Blvd. Suite 374 Woodland Hills, CA 91364 --F2AAAB_.35EB-- From owner-ietf-ediint@mail.imc.org Wed Oct 13 17:07:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08255 for ; Wed, 13 Oct 2004 17:06:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9DKrQwC038086; Wed, 13 Oct 2004 13:53:26 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9DKrQs5038085; Wed, 13 Oct 2004 13:53:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from s-utl01-dapop.stsn.com (s-utl01-dapop.stsn.com [63.241.218.135]) by above.proper.com (8.12.11/8.12.9) with SMTP id i9DKrNYR038075 for ; Wed, 13 Oct 2004 13:53:25 -0700 (PDT) (envelope-from kyle@drummondgroup.com) Received: from dapop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dapop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004101315534221499 for ; Wed, 13 Oct 2004 15:53:42 -0500 Received: from KYLEDGILAPTOP ([10.24.193.170]) by dapop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 13 Oct 2004 15:53:42 -0500 From: "Kyle Meadors" To: "'Scott Hollenbeck'" , Cc: "'Russ Housley'" Subject: RE: draft-ediint-certificate-exchange-00 Date: Wed, 13 Oct 2004 15:53:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <7468147AEE316B41B3B55152959CE218129098@dul1wnexm05.vcorp.ad.vrsn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSqMat2U3N0aDhJQj6C3Qmyfo3D3AHNOMcw Message-ID: X-OriginalArrivalTime: 13 Oct 2004 20:53:42.0914 (UTC) FILETIME=[B9704620:01C4B166] Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is from Dale Moberg, co-author of the CEM draft. In reply to: "Some follow-up on my own notes from a week or so ago. One of the security area directors also has questions about the ediint-certificate-exchange I-D. "Would anyone care to respond to Russ' comment about PKIX overlap? -Scott- "The Abstract of this document says: "... EDIINT Certificate Exchange Messaging provides the format and means to effectively exchange certificates for use within trading partner relationships. ..." "This seems to overlap with the charter of PKIX WG, and I do not think that an additional mechanism for certificate distribution is desirable. === Here is some context that should indicate how ediint-certificate-exchange differs from the PKIX CMP and related initiatives. === Here is my understanding of EDIINT conventions and requirements and its relation to CMP. This is from a developer's perspective but also from one who helped users formulate the draft in EDIINT about certificate exchange. While it is not mentioned in the initial draft, it probably should be recommended that applications support the use of CMP to interact with their CA/RA, at least to get certificates. Users said in effect that CMP was too complicated and was not how it was being done in practice-- they wanted to use EDIINT messages to send their new certificates directly to their trading partners. Leaving it to partners to check for expired certificates and try to find the new ones was not feasible. Unfortunately existing practice for peer to peer publication of updated certificates was variable, and frequently interoperability problems arose. As a matter of custom/convention, EDIINT applications mail/transfer their certificates to the corresponding application that then decide whether to trust the certificates that are received based on the local policy. Quite commonly, the certificates are self-signed, version 3 certificates, sometimes using a dual key model (key exchange and signing). So the message flow is peer to peer, with each side responsible for "pushing" its certificate to the other side. Obtaining certs/crls from a CA is not something that is expected or widely supported. I don't think this peer to peer message pattern is present in CMP although some of the message bodies might be adapted for this purpose. One very large retail user realized that it would need to reissue certificates to well over 10,000 trading partners and wanted a lightweight interoperable protocol to solve this problem. They wanted to send out the certificates at their discretion. I am uncertain that their CA/RA even supports CMP. The EAN.UCC Business Message Standards - Global Standards Management Process (GSMP)-- organized the requirements collection and draft preparation. They wanted XML requests and responses that simply asked the peer to begin trust of the enclosed certificate. It can be signed over using a CMS detached signature if trust is already in place, just as with ordinary EDIINT messages. Also, users wanted a provision for attaching, in the future, a profile that stated how they expected the EDIINT protocol to occur (that is, the specific features and capabilities that were to be used). So the requirements--simplicity, XML based messages, reuse of EDIINT message patterns, provision for extension to profiles--did not cleanly match CMP. The main difference to my mind is that CMP assumes a peer to RA/CA interaction. EDIINT assumes, more or less, that you are mailing/POSTing an attachment to a peer. It would be difficult, if not impossible, to prohibit this mechanism for sending certificates peer to peer. Attachments with certificates are something MIME allows, and MIME supporting transfer protocols, SMTP HTTP etc, allow distributing certificates in this manner. The draft only standardizes this practice so that it can become more interoperable by setting down an EDIINT "way" to send certificates to trading partners. Dale Moberg -----Original Message----- From: owner-ietf-ediint@mail.imc.org [mailto:owner-ietf-ediint@mail.imc.org] On Behalf Of Scott Hollenbeck Sent: Monday, October 04, 2004 11:43 AM To: ietf-ediint@imc.org Cc: 'Russ Housley' Subject: FW: draft-ediint-certificate-exchange-00 WG members: Some follow-up on my own notes from a week or so ago. One of the security area directors also has questions about the ediint-certificate-exchange I-D. Would anyone care to respond to Russ' comment about PKIX overlap? -Scott- -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com] Sent: Wednesday, September 29, 2004 9:43 AM Subject: draft-ediint-certificate-exchange-00 The Abstract of this document says: "... EDIINT Certificate Exchange Messaging provides the format and means to effectively exchange certificates for use within trading partner relationships. ..." This seems to overlap with the charter of PKIX WG, and I do not think that an additional mechanism for certificate distribution is desirable. Can someone provide background that would make me fee comfortable about this work? Russ --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.769 / Virus Database: 516 - Release Date: 9/24/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.775 / Virus Database: 522 - Release Date: 10/8/2004 From owner-ietf-ediint@mail.imc.org Tue Oct 19 15:25:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02436 for ; Tue, 19 Oct 2004 15:25:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JIu0WM020402; Tue, 19 Oct 2004 11:56:00 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JIu0Zd020401; Tue, 19 Oct 2004 11:56:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from atlrelay1.inovisinc.com (atlrelay1.inovisinc.com [206.113.209.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JItx1p020395 for ; Tue, 19 Oct 2004 11:55:59 -0700 (PDT) (envelope-from richard.bigelow@inovis.com) Received: from alfexfe1.itlogon.com (atlrelay1.itlogon.com [127.0.0.1]) by atlrelay1.inovisinc.com (8.11.6/8.11.6) with ESMTP id i9JIZRb19587 for ; Tue, 19 Oct 2004 14:35:27 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Certificate Exchange - Use Cases Date: Tue, 19 Oct 2004 14:58:07 -0400 Message-ID: Thread-Topic: Certificate Exchange - Use Cases Thread-Index: AcS2DZHhg3JUGuvDQ8CwKFJn8Z4Qow== From: "Richard Bigelow" To: "IETF EDIINT WG \(E-mail\)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9JIu01p020396 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Comment on draft-ediint-certificate-exchange-00.txt. I have 2 comments on section 4. 1. The beginning of section 4 says that it is "only illustrative". However, section 4 contains several uses of MUST and SHOULD, which are prescriptive words. These words should be in lower case, to indicate that they are not stating additional requirements, or different language should be used. 2. Section 4.2 does state some requirements that were not stated earlier in section 2 or 3. These requirements should be in section 2. The requirements in 4.2 on accepting signed messages should be modified. 1. In 4.1.1 Step 1, change In the case of an encryption certificate, the initiator MUST be immediately ready to receive documents encrypted with the new certificate. to In the case of an encryption certificate, the initiator is immediately ready to receive documents encrypted with the new certificate. Change the first paragraph of 4.1.2 to Receiver validates the EDIINTCertificateExchangeRequest message at the AS2 level and returns a correct MDN. If the message is a proper AS2 document, the receiver automatically accepts or rejects the new certificate(s) or requires manual intervention. If the certificate is automatically accepted or rejected, an EDIINTCertificateExchangeResponse is generated and returned to the initiator. Since the trading relationship could be hindered if action is not taken prior to the RespondByDate, manual intervention must be done before that date. When the manual intervention determines to accept or reject the new certificate, an EDIINTCertificateExchangeResponse is generated and returned to the initiator. Both automatic and manual EDIINTCertificateExchangeResponses are formatted according to Section 2. Message Processing and Section 3. XML Schema Description and sent according to EDIINT-AS2 protocol. A positive MDN received for the response message indicates successful transmission of the response message. 2. 4.2.1 says If the receiver supports this use case, they MUST accept this message regardless of the presence of a signature. and 4.2.2 says The initiator MUST accept this response, regardless of if it is signed. I interpret these requirements to mean that the receiver of a Request/Response message must accept a signed message, even if the receiver cannot validate the signing certificate. This requirement should be stated in section 2.3. In the first paragraph of section 2.3, after this sentence After obtaining the desired certificate, the initiator of the certificate exchange transmits the certificate in the CEM Request message. insert If the initiator does not possess the receiver's signature certificate, the initiator SHOULD NOT request a signed MDN. Change the first sentence of paragraph 3 of section 2.3 from Upon receipt of the CEM Request, the recipient trading partner processes the transport message as normal and returns the MDN. to Upon receipt of the CEM Request, the recipient trading partner processes the transport message as described below and returns the MDN. Add the following to the end of 2.3: If the initiator signs the CEM Request, the initiator SHOULD include the signing certificate in the signature. If the recipient partner receives a signed CEM Request, but the recipient does not possess a currently valid signing certificate for the initiator, then the recipient partner may ignore the signature without processing it in any way, return a positive MDN if one is requested, and go on to process the Request. However, it is RECOMMENDED that the recipient partner process the signature as much as possible, to detect possible corruption of the Request message, as follows. If the signing certificate is in the signature, or if the recipient possesses the signing certificate, the recipient SHOULD verify that the digest of the message equals the digest in the signature. If the signing certificate is issued by a CA Certificate that the recipient trusts, the recipient SHOULD verify that the issuer did issue the signing certificate. If either of these checks is done and! fails, the recipient MUST return a negative MDN. If the recipient does not trust the signing certificate because the signing certificate or one of its issuers has been revoked or has expired or is explicitly not trusted, the recipient SHOULD return a negative MDN. If the recipient already trusts the signing certificate or one of its issuers and all other tests pass, then the recipient MUST return a positive MDN. If the recipient has no basis to either trust or not trust the signing certificate, then the recipient MUST return a positive MDN. (This is contrary to the behavior for non-CEM messages, where the recipient returns a negative MDN if it cannot validate the trust of the signing certificate.) In this case, the recipient SHOULD require manual intervention to accept the certificates in the Request. The recipient returns a positive MDN even when it cannot validate trust of the signing certificate because this CEM Request may be the initial distribution of the signing certificate. The recipient might not yet possess any certificates of the initiator or have any means to validate the signing certificate. After the initial distribution, the initiator will normally sign the CEM Request with the existing signing certificate, which the recipient can validate. The burden for the initial distribution is placed on the recipient, as in section 4.2. The initiator can always send CEM Requests in the same way. The recipient might sign the Request's MDN or the Response, and the initiator may not yet possess any signing certificate of the recipient. (Note that the AS2 specification permits the recipient to sign the MDN even if the initiator did not request a signed MDN.) So the same requirements apply to the initiator when processing the MDN or Response message. Add to the end of 2.3, after the paragraph above: If the recipient signs the MDN for the CEM Request, the recipient SHOULD include the signing certificate in the signature. If the initiator receives a signed MDN for the CEM Request, but the initiator does not possess a currently valid signing certificate for the recipient, then the initiator may ignore the signature without processing it in any way, and accept the MDN. However, it is RECOMMENDED that the initiator process the signature as much as possible, to detect possible corruption of the MDN message, as follows. If the signing certificate is in the signature, or if the initiator possesses the signing certificate, the initiator SHOULD verify that the digest of the message equals the digest in the signature. If the signing certificate is issued by a CA Certificate that the initiator trusts, the initiator SHOULD verify that the issuer did issue the signing certificate. If either of these checks is done and fails, the initiator MUST reject the MDN. If the initiator ! does not trust the signing certificate because the signing certificate or one of its issuers has been revoked or has expired or is explicitly not trusted, the initiator SHOULD reject the MDN. The behavior when the initiator rejects the MDN is not defined. If the initiator already trusts the signing certificate or one of its issuers and all other tests pass, then the initiator MUST accept the MDN. If the initiator has no basis to either trust or not trust the signing certificate, then the initiator MUST accept the MDN. (This is contrary to the behavior for non-CEM messages, where the initiator rejects a MDN if it cannot validate the trust of the signing certificate.) If the recipient signs the CEM Response, the recipient SHOULD include the signing certificate in the signature. If the initiator receives a signed CEM Response, but the initiator does not possess a currently valid signing certificate for the recipient, then the initiator may ignore the signature without processing it in any way, return a positive MDN if one is requested, and go on to process the Response. However, it is RECOMMENDED that the initiator process the signature as much as possible, to detect possible corruption of the Response message, as follows. If the signing certificate is in the signature, or if the initiator possesses the signing certificate, the initiator SHOULD verify that the digest of the message equals the digest in the signature. If the signing certificate is issued by a CA Certificate that the initiator trusts, the initiator SHOULD verify that the issuer did issue the signing certificate. If either of these checks is done and fails, the initiato! r MUST return a negative MDN. If the initiator does not trust the signing certificate because the signing certificate or one of its issuers has been revoked or has expired or is explicitly not trusted, the initiator SHOULD return a negative MDN. If the initiator already trusts the signing certificate or one of its issuers and all other tests pass, then the initiator MUST return a positive MDN. If the initiator has no basis to either trust or not trust the signing certificate, then the initiator MUST return a positive MDN. (This is contrary to the behavior for non-CEM messages, where the initiator returns a negative MDN if it cannot validate the trust of the signing certificate.) Sections 4.2.1 and 4.2.2 should be modified as follows. MUST and SHOULD are replaced by other words, and the requirements for accepting signed messages are modified in accordance with the language above. 4.2.1. Step 1 Initiator creates an EDIINTCertificateExchangeRequest as described in Section 2.0 Message Format and Section 3.0 XML Schema. The initiator sends it according to EDIINT-AS2 protocol. Using a digital signature on the AS2 message is optional, as the receiver will not be able to verify until after accepting the signature certificate. The receiver accepts this message in accordance with section 2.3. Unless the initiator possesses the receiver's encryption certificate, encryption is not used. Unless the initiator possesses the receiver's signature certificate, the initiator does not request a signed MDN. If the MDN is not signed, there is no legal proof the receiver received the message. In addition, a positive MDN received during this step gives some indication of successful transmission of the message, but does not imply successful action on the certificate. In the case of an encryption certificate, the initiator must be immediately ready to receive documents encrypted with the new certificate. In the case of a signing certificate, the initiator can begin signing documents with the new certificate at the RespondByDate or upon receipt of an EDIINTCertificateExchangeResponse from the partner indicating they are ready. If an acceptance response is not received by the RespondByDate, the initiator may or may not begin signing with the new certificate, depending on the implementation's capabilities and the policies of the initiator. 4.2.2. Step 2 Receiver validates the EDIINTCertificateExchangeRequest message at the AS2 level and returns an MDN according to the EDIINT-AS2 protocol and section 2.3. If the message is a proper AS2 document, the receiver automatically accepts or rejects the new certificate(s), or requires manual intervention. Caution should be used in automatically accepting the certificate, as it may be impossible to verify the sender is authentic. If the certificate is automatically accepted or rejected, an EDIINTCertificateExchangeResponse is generated and returned to the initiator. Since the trading relationship could be hindered if action is not taken prior to the RespondByDate, manual intervention must be done before that date. When the manual intervention determines to accept or reject the certificate, an EDIINTCertificateExchangeResponse is generated and returned to the initiator. In both the automatic and manual case, the EDIINTCertificateExchangeResponses are formatted according to Section 2. Message Processing and Section 3. XML Schema Description and sent according to EDIINT-AS2 protocol. If the original CEM Request included the encryption certificate, or if the receiver has the initiator encryption certificate on file, it may be used to encrypt the AS2 message including the EDIINTCertificateExchangeResponse. Otherwise, it may be necessary to send this EDIINTCertificateExchangeResponse unencrypted. The message may be signed, but it is possible the initiator will have no way to verify the signature. The initiator accepts this response in accordance with section 2.3. A positive MDN received for the response message indicates successful transmission of the response message. From owner-ietf-ediint@mail.imc.org Tue Oct 19 15:40:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04095 for ; Tue, 19 Oct 2004 15:40:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JIQdST015564; Tue, 19 Oct 2004 11:26:39 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9JIQdZU015563; Tue, 19 Oct 2004 11:26:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from atlrelay1.inovisinc.com (atlrelay1.inovisinc.com [206.113.209.242]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9JIQbRT015525 for ; Tue, 19 Oct 2004 11:26:38 -0700 (PDT) (envelope-from richard.bigelow@inovis.com) Received: from alfexfe1.itlogon.com (atlrelay1.itlogon.com [127.0.0.1]) by atlrelay1.inovisinc.com (8.11.6/8.11.6) with ESMTP id i9JI66b15386 for ; Tue, 19 Oct 2004 14:06:06 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Certificate Exchange - Negative MDN Date: Tue, 19 Oct 2004 14:28:38 -0400 Message-ID: Thread-Topic: Certificate Exchange - Negative MDN Thread-Index: AcS2CXPnqPxFCT1hRvSsJ2X068ltug== From: "Richard Bigelow" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9JIQcRT015558 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Comment on draft-ediint-certificate-exchange-00.txt. Please clarify the behavior in the case of a negative MDN. After this paragraph of section 2.3 Upon receipt of the CEM Request, the recipient trading partner processes the transport message as normal and returns the MDN. The recipient MUST return the MDN before parsing and interpreting the CEM XML data. The returned MDN only provides information on the veracity of the transport message and not the acceptance of the certificate being exchanged. add this If the recipient rejects the Request message at the transport level, the recipient MUST return a negative MDN if an MDN is requested, and the recipient MUST NOT return a CEM Response. The recipient has rejected the Request at the transport level, and does not process the Request further. The initiator's behavior when receiving a negative MDN is not defined. The initiator MAY retransmit the Request, after taking some action to correct the transport problem, or it may take some other action. At the end of section 2.3, add If the initiator rejects the Response message at the transport level, the initiator MUST return a negative MDN if an MDN is requested. The initiator has rejected the Response at the transport level, and does not process the Response further. The recipient's behavior when receiving a negative MDN is not defined. The recipient MAY retransmit the Response, after taking some action to correct the transport problem. From owner-ietf-ediint@mail.imc.org Fri Oct 29 08:30:17 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24014 for ; Fri, 29 Oct 2004 08:30:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TC086q021595; Fri, 29 Oct 2004 05:00:08 -0700 (PDT) (envelope-from owner-ietf-ediint@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i9TC08ix021594; Fri, 29 Oct 2004 05:00:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f Received: from mail.verisignlabs.com (cliffie.verisignlabs.com [65.201.175.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i9TC03GC021580 for ; Fri, 29 Oct 2004 05:00:03 -0700 (PDT) (envelope-from sah@428cobrajet.net) Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Fri, 29 Oct 2004 07:59:52 -0400 id 0054026F.418230B8.000018AD From: "Scott Hollenbeck" To: "'Rik Drummond'" Cc: ietf-ediint@imc.org Subject: RE: ID Tracker State Update Notice: draft-ietf-ediint-as2 Date: Fri, 29 Oct 2004 08:00:17 -0400 Message-ID: <7468147AEE316B41B3B55152959CE218129154@dul1wnexm05.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <200410290249.i9T2msPH037466@drummondgroup.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i9TC03GC021586 Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit > what do I have to do?.... .anything? Hey thanks from all of > us for being an > AD.... Imagine how much work it is... rik Rik, You can find all of the IESG review comments in the public I-D tracker: https://datatracker.ietf.org/public/pidtracker.cgi I've included them here for completeness. All marked "Discuss" MUST be addressed; those marked "Comment" SHOULD be addressed. If you have any questions about any of them you should contact the appropriate AD with follow-up questions. Each will have to review and approve any updates to get the document to move forward. -Scott- ---------- Harald Alvestrand: Comment: [2004-10-28] Reviewed by John Loughney, Gen-ART His review: Formatting problems are so severe, I'd recommend a revision before considering this draft. The text is somewhat dense and hard to parse, so the formatting problems really make this impossible to read. I can try to re-read the draft for technical comments and will update this review if I find anything. In summary, I'd issue a discuss on this because of formatting - I doubt this passes the ID-Nits. John Major 1) What is AS2? This needs to be explained somewhere. Questions 1) The introduction discusses the relationship of this draft to other EDI RFCs. Does this document update / obsolete any of these RFCs? If so, it should mention it explicitly. Nits 1) Header & footer on page 1 should be removed. 2) Lots of editing problems - bullet lists should be reformatted, sections should be left justified, blank lines should be inserted after section titles, ToC should list page numbers, bulleted lists have formatting problems (page 6, for example). Steve Bellovin: Discuss: [2004-10-25] Nit: there are two sections numbered 1.1 Nit: in the second of those sections, there's text that speaks of MD5's small key size. MD5 is a hash algorithm and doesn't have keys. I believe what was meant is "short block size". If possible, I'd leave MD5 out; if you must leave it in, say that it SHOULD NOT be used except for compatibility, because of cryptographic weaknesses in MD5. 4.1: "AS" is never expanded There's no discussion of replay detection or prevention, nor of checking the message date to see if it's stale. I assume, from the text on reusing Message-IDs, that they could function as replay detectors; in that case, some notion of when a message is stale should be included, so that the list of previously-seen Message-IDs can be pruned. Ted Hardie: Discuss: [2004-10-25] I think the asynchronous MDNs text is confusing, and I think it could be cleared up fairly easily (at least I hope so!). First, my understanding is that an asynchronous MDN is essentially any MDN which can be later correlated to the original message. As the document notes, this means that the MDN must contain enough data to ensure that it uniquely identifies the original message. The document refers to RFC 3789 on MDNs, but it seems to want only the definition of message/disposition-notification from that; even in the case of SMTP-based asynchronous notifications, the document should look to RFC 3355? Are there other aspects of 3789 that are needed for this? If not, can the limitation be clarified? The diagram in 7.2 contains: Asynchronous AS2-MDN [C] ----( connect )----> [S] [C] -----( send )------> [S] [HTTP Request [AS2-Message]] [C] <---( receive )----- [S] [HTTP Response] [C]*<---( connect )----- [S] [C] <--- ( send )------- [S] [HTTP Request [AS2-MDN]] [C] ----( receive )----> [S] [HTTP Response] * Note: An AS2-MDN may be directed to a different host than that of the sender of the AS2 message and may utilize a different transfer protocol than that used to send the original AS2 message. The server initiates an HTTP connection to the client? I think this actually confuses "client/server" roles with "party1/party2" roles. If [S] is actually "party2", this makes sense, but [C]/"party1" must be an HTTP server, capable of handling the HTTP Request. An additional issue here is that the document doesn't seem to say whether the HTTP Request [AS2-MDN] is sent via a POST request or something else (e.g. PUT). I think POST, but this should be clarified. I'm also a bit concerned about how the mail-address in Disposition-notification-to is being treated. If it MUST be present and MUST be ignored, why not give it a specific address in .invalid or recommend addresses in .invalid for use here? Russ Housley: Discuss: [2004-10-27] I find the signed receipt discussion confusing. Sometimes, it seems that the signed receipt mechanism defined in RFC 2634 meets the needs of EDI and other times it appears that some EDI-specific content is needed. In my opinion, the cryptographic binding provided by the mechanism in RFC 2634 is highly desirable. Section 1.1 says: : : Non-repudiation of receipt (NRR) - NRR is a "legal event" that occurs : when the original sender of an signed EDI/EC interchange has verified : the signed receipt coming back from the receiver. NRR IS NOT a : functional or a technical message. : This is not sufficient. One must also match the values in the signed receipt against the retained copy of the original as is discussed in section 7.1. Pointing out that the returned MIC value inside the MDN must be the same as the digest of the original message early in the document would greatly help the reader. Section 2.3.1, 1st bullet, says: : : -The organization sending EDI/EC data signs and encrypts the data : using S/MIME. In addition, the message will request a signed : receipt to be returned to the sender of the message. : The sender must keep a copy of the original message or the message-id and digest value of the original message. The receipt validation cannot be performed without these values. Section 2.3.1, 3rd paragraph says: : : The above describes functionality which, if implemented, will : satisfy all security requirements and implement nonrepudiation : of receipt for the exchange. : Section 1.1 says a signedReceipt is a receipt signed with a digital signature. Then, section 7.4.3 says that a signed receipt does not have to include the Returned-content-MIC. Without the Returned-content-MIC NRR is unachievable. Section 2.3.2, 2nd paragraph, 2nd sentence says: : : NRR refers to a legal event which occurs only when the : original sender of an interchange has verified the signed : receipt coming back from recipient of the message. : This is not sufficient. I suggest: NRR refers to a legal event which occurs only when the original sender of an interchange has verified the signature on the signed receipt as coming from the recipient and the returned MIC value inside the MDN is the same as the digest of the original message. Section 2.4.2 says: : : If a signed receipt notification is requested however, a MIC value : is REQUIRED as part of the returned receipt, unless an error : condition occurs in which a MIC value cannot be returned. In error : cases, an unsigned receipt or MDN SHOULD be returned with the : correct "disposition modifier" error value. : And, Section 7.3.1 says: : : When a request for a signed receipt is made, but there is an error : in processing the contents of the message, a signed receipt MUST : still be returned. The request for a signed receipt SHALL still be : honored, though the transaction itself may not be valid. The reason : for why the contents could not be processed MUST be set in the : "disposition-field". : These seem contradictory. The first says that a MIC is not required if there is an error, but the second says that a signed receipt MUST be returned. Section 7.3.1 says: : : When a request for a signed receipt is made, the "Received-content- : MIC" MUST always be returned to the requester. : And, Section 7.4.3 says: : : This field [in reference to the Received-content-MIC] is set only : when the contents of the message are processed successfully. : These seem contradictory. The first says that a MIC always returned, but the second says that the MIC is only returned if the processing is successful. The Security Considerations needs to cover addition topics: - The NRR service supported by this document relies on the originator retaining a copy of either the original message or the MIC of the original message. - This document allows for the return of signed receipt that does not fulfill the NRR service, that is a signed receipt can be returned without the Returned-content-MIC. Comment: [2004-10-27] Please use include a hyphen in "non-repudiation" throughout the document. This is the accepted spelling when referring to the security service. In section 2.3.1, 3rd bullet: s/message,indicating/message, indicating/ In section 2.4.2, Permutation Summary, please add the following options, as the previous paragraphs indicate that if an error occurs an unsigned receipt can be returned: 1) Sender sends un-encrypted data, requests a signed receipt. Receiver sends back an unsigned receipt. 2) Sender sends encrypted data, requests a signed receipt. Receiver sends back an unsigned receipt. 3) Sender sends signed data, requests a signed receipt. Receiver sends back an unsigned receipt. 4) Sender sends encrypted and signed data, requests a signed receipt. Receiver sends back an unsigned receipt. In section 7.4.3: s/algorith/algorithm/ In section 7.6: s/varydepending/vary depending/ Please add a reference for S/MIME Version 3 Certificate Handling, it is referred to in Security Considerations. I would like for this to be a normative reference, with the following text appearing in the beginning of the Security Considerations: The following are the additional security considerations to those listed in [4] and [X]: The following certificate types MUST ... Where [X] refers to the S/MIME Version 3 Certificate Handling document. Allison Mankin: Comment: [2004-10-28] The IANA registrations are very terse - they should say into what registry they go.