From owner-ietf-ediint@mail.imc.org Thu Sep 2 16:35:29 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 QAA06596
for ; Thu, 2 Sep 2004 16:35:28 -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 i82KEu77024503;
Thu, 2 Sep 2004 13:14:56 -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 i82KEuDF024502;
Thu, 2 Sep 2004 13:14:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f
Received: from drummondgroup.com (drummondgroup.com [161.58.166.198])
by above.proper.com (8.12.11/8.12.9) with ESMTP id i82KEtuc024487
for ; Thu, 2 Sep 2004 13:14:55 -0700 (PDT)
(envelope-from rvd2@drummondgroup.com)
Received: from DGIServer1 (68.189.209.147.sbi.ftwrth.tx.charter.com [68.189.209.147] (may be forged))
by drummondgroup.com (8.12.11/8.12.11) with ESMTP id i82KEl1T053432
for ; Thu, 2 Sep 2004 14:14:51 -0600 (MDT)
Message-Id: <200409022014.i82KEl1T053432@drummondgroup.com>
From: "Rik Drummond"
To:
Subject: I just submitted, I hope, the final draft of the AS2 document to the draft section on the IETF site.
Date: Thu, 2 Sep 2004 15:14:47 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
Thread-Index: AcSRKX5nBoYEhlg6Sv63gx7vPGBDig==
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 7bit
Next step final call... If you all approve.... rik
From nv33134@yahoo.com Thu Sep 2 18:35:22 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 SAA19358;
Thu, 2 Sep 2004 18:35:21 -0400 (EDT)
Date: Thu, 2 Sep 2004 18:35:21 -0400 (EDT)
Message-Id: <200409022235.SAA19358@ietf.org>
Received: from [200.247.6.3] (helo=ietf.org)
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1C30DO-00072x-5x; Thu, 02 Sep 2004 18:37:59 -0400
From: "Brasil 2004 / Informe Exclusivo"
To: MapaAtualizado2004@local.cnri.reston.va.us
Subject: Mapa atualizado da "esquerda católica"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
MIME-Version: 1.0
Content-Type: text/html
X-Spam-Score: 10.0 (++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
InfoGratuitaProximosLancamentos - LinkToFreeAutomaticTranslator (Castellano, English, Français, Deutsche, Português, etc.)
Brasil 2004: reportagem desenha mapa atualizado da "esquerda católica"
* A "esquerda católica", sua influência visível na esfera sociopolítica, e seu poder subterrâneo através de redes capilares e "vasos comunicantes" no Brasil de hoje, é apresentada num livro-reportagem inédito de 56 páginas, de fácil leitura e ampla documentação.
* "Pastoral da Terra e MST incendeiam o País" é ao mesmo tempo um mapa atualizado e um instrumento informativo indispensável para quem deseja conhecer os possíveis rumos sociopolíticos do Brasil de amanhã.
* O autor, o advogado e pesquisador Gregorio Vivanco Lopes, com mais de 30 anos de especialização no tema das comunidades eclesiais de base e da teologia da libertação, mostra a real dimensão da Pastoral da Terra e do MST, duas pontas de um mesmo e gigantesco iceberg que a mídia nem sempre revela e que a opinião pública ignora.
* A força e o talão de Aquiles da "esquerda católica" descritas num informe objetivo, documentado e sereno que todo brasileiro deve ler, ainda que para discordar e debater de maneira invariavelmente respeitosa, em prol da paz social no Brasil.
* O autor do livreto "Pastoral da Terra e MST incendeiam o País" exerce o legítimo direito de informar, e favorece também o direito de cada brasileiro de ser informado, condições ambas indispensáveis para uma autêntica democracia.
* Solicite gratuitamente, por e-mail, o Índice e a Introdução contendo um resumo da reportagem e a capa da edição impressa:
IntroCapaGratuitas
* Envie seu voto eletrônico e, se possível, sua valiosa opinião a respeito do tema abordado, e receberá informação gratuita sobre próximos lançamentos:
-
Lopes:Concordo
-
Lopes:EmTermos
-
Lopes:Discordo
* Para enviar mensagem ou tomar contato com o autor, clique em:
Lopes:MinhaMensagem (ou ligue para 11-38223241 / 11-38281102
* Caso deseje adquirir a versão impressa (R$ 10,00 correio incluído), clique no link: DesejoAdquirirLivro (receberá as instruções do distribuidor, de exclusiva responsabilidade deste).
* Caso deseje receber, por e-mail, o e-Book com o texto completo da reportagem (R$ 1,99), clique no link:
DesejoAdquirirEBook
* Para ser retirado de nosso Address Book, por favor, clique em:
RetirarImediatamente
From admin@computeradmin.org Fri Sep 3 19:57:29 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 TAA25165
for ; Fri, 3 Sep 2004 19:57:29 -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 1C3Nyc-00049z-9n
for ediint-archive@ietf.org; Fri, 03 Sep 2004 20:00:18 -0400
Received: from h0010b572dbb6.ne.client2.attbi.com ([24.218.72.219])
by mx2.foretec.com with smtp (Exim 4.24)
id 1C3Nvp-00075u-Uq
for ediint-archive@ietf.org; Fri, 03 Sep 2004 19:57:27 -0400
Received: from 1c5.t80azrm.net [83.16.86.54] by h0010b572dbb6.ne.client2.attbi.com with ESMTP id 7E9F88C462D; Sat, 04 Sep 2004 03:00:31 +0200
Message-ID: <2b25$64t0rkk7qt$ja$3$4j-4@prfho>
From: "Administrator"
To: dcom@ietf.org
Subject: Attention All Nonprofit Organizations: Members and Staff
Date: Sat, 04 Sep 04 03:00:31 GMT
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook, Build 10.0.2616
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="1A_0A_F0.6_.7540F_.__9B"
X-Spam-Score: 16.4 (++++++++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
This is a multi-part message in MIME format.
--1A_0A_F0.6_.7540F_.__9B
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Attention All Nonprofit Organizations: Members and Staff
You Must Respond By 5 P.M. Tuesday, September 7, 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., Tuesday, September 7, 2004.
All desktop 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 2004
next generation technology, making these the best performing
computers money can buy.
Avtech Direct is offering these feature rich, top performing
Desktop Computers with the latest Intel technology at an amazing price
to all who call:
1-800-884-9510 by 5 P.M. Tuesday, September 7, 2004
The fast and powerful AT-2400 series Desktop features:
* Intel 2.0Ghz 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
* 1.44 Floppy disk drive
* Next Generation Technology
* ATI Premium video and sound
* 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 $699 ........................................ Your Cost $297
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-884-9510 by 5 P.M. Tuesday, September 7, 2004
and we will hold the desktops you request on will call.
4. You are not obligated in any way.
5. 100% Satisfaction Guaranteed.
Call Avtech Direct
1-800-884-9510 before 5 P.M. Tuesday, September 7, 2004
Visit our website at http://www.avtechdirectcomputers.com
If you wish to unsubscribe from this list, please go to:
http://www.computeradvice.org/unsubscribe.asp
Avtech Direct
22647 Ventura Blvd., Suite 374
Woodland Hills, CA 91364
--1A_0A_F0.6_.7540F_.__9B--
From owner-ietf-ediint@mail.imc.org Tue Sep 7 12:28:13 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 MAA05507
for ; Tue, 7 Sep 2004 12:28:13 -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 i87GFaPx043354;
Tue, 7 Sep 2004 09:15:36 -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 i87GFalD043353;
Tue, 7 Sep 2004 09:15:36 -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 i87GFZF8043346
for ; Tue, 7 Sep 2004 09:15:35 -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 MAA04556;
Tue, 7 Sep 2004 12:15:35 -0400 (EDT)
Message-Id: <200409071615.MAA04556@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-16.txt
Date: Tue, 07 Sep 2004 12:15:34 -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 AS2
Author(s) : D. Moberg, R. Drummond
Filename : draft-ietf-ediint-as2-16.txt
Pages : 84
Date : 2004-9-3
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-16.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-16.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-16.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-9-7124405.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ediint-as2-16.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ediint-as2-16.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2004-9-7124405.I-D@ietf.org>
--OtherAccess--
--NextPart--
From owner-ietf-ediint@mail.imc.org Fri Sep 24 19:17: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 TAA00918
for ; Fri, 24 Sep 2004 19:17: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 i8ON4mZf031650;
Fri, 24 Sep 2004 16:04: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 i8ON4mNT031649;
Fri, 24 Sep 2004 16:04:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f
Received: from drummondgroup.com (drummondgroup.com [161.58.166.198])
by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ON4lf8031643
for ; Fri, 24 Sep 2004 16:04:47 -0700 (PDT)
(envelope-from kyle@drummondgroup.com)
Received: from KYLEDGILAPTOP (pcp517486pcs.nash01.tn.comcast.net [68.53.139.87])
by drummondgroup.com (8.12.11/8.12.11) with ESMTP id i8ON4lQC089962
for ; Fri, 24 Sep 2004 17:04:47 -0600 (MDT)
Message-Id: <200409242304.i8ON4lQC089962@drummondgroup.com>
From: "Kyle Meadors"
To:
Subject: need for certificate exchange standard
Date: Fri, 24 Sep 2004 18:04:45 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_3897_01C4A260.F9CE8D40"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcSiiuE3xSQ/u6xZSuyIXZFD8ilO8Q==
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
This is a multi-part message in MIME format.
------=_NextPart_000_3897_01C4A260.F9CE8D40
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
EDIINT,
=20
Part of the EDIINT WG charter is the intention to produce secure
transactions of EDI over the Internet. Within AS1, AS2 and AS3, this
security has been realized through encryption which relies on trusted
digital certificates. The AS1, AS2 and AS3 standards all contain =
sections
discussing certificate handling and each have this statement=85
=20
=93In the long term, additional Internet-EDI standards may be developed =
to
simplify the process of establishing a trading partnership, including =
the
third party authentication of trading partners, as well as attributes of =
the
trading relationship.=94
=20
I will soon be submitting a RFC standards track Internet draft dealing =
with
certificate exchange within EDIINT. This standard was first proposed by =
the
ecGIF subcommittee within the UCC. Through ecGIF, several AS2 vendors =
and
implementers contributed to its development. It is being brought to =
EDIINT
for discussion and consideration as an Internet draft. There is a great
interest among supply-chains for an effective means of exchanging
certificates within a trading partner relationship.
=20
I look forward to your comments and suggestions on this initiative.=20
=20
Kyle Meadors
Program Manager
Drummond Group Inc.
615.384.5006
=20
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/2004
=20
------=_NextPart_000_3897_01C4A260.F9CE8D40
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
EDIINT,
Part of the EDIINT WG charter is the intention to =
produce
secure transactions of EDI over the Internet. Within AS1, AS2 and AS3, =
this
security has been realized through encryption which relies on trusted =
digital
certificates. The AS1, AS2 and AS3 standards all contain sections =
discussing
certificate handling and each have this =
statement…
“In the long term, additional Internet-EDI =
standards
may be developed to simplify the process of establishing a trading =
partnership,
including the third party authentication of trading partners, as well as
attributes of the trading =
relationship.”
I will soon be submitting a RFC standards track =
Internet draft
dealing with certificate exchange within EDIINT. This standard was first
proposed by the ecGIF subcommittee within the UCC. Through ecGIF, =
several AS2
vendors and implementers contributed to its development. It is being =
brought to
EDIINT for discussion and consideration as an Internet draft. There is a =
great
interest among supply-chains for an effective means of exchanging =
certificates
within a trading partner relationship.
I look forward to your comments and suggestions on =
this
initiative.
Kyle Meadors
Program Manager
Drummond Group Inc.
615.384.5006
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/2004
------=_NextPart_000_3897_01C4A260.F9CE8D40--
From owner-ietf-ediint@mail.imc.org Fri Sep 24 19:23: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 TAA01296
for ; Fri, 24 Sep 2004 19:23: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 i8ONDr00032200;
Fri, 24 Sep 2004 16:13:53 -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 i8ONDr32032199;
Fri, 24 Sep 2004 16:13:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-ediint@mail.imc.org using -f
Received: from drummondgroup.com (drummondgroup.com [161.58.166.198])
by above.proper.com (8.12.11/8.12.9) with ESMTP id i8ONDpWd032186
for ; Fri, 24 Sep 2004 16:13:52 -0700 (PDT)
(envelope-from kyle@drummondgroup.com)
Received: from KYLEDGILAPTOP (pcp517486pcs.nash01.tn.comcast.net [68.53.139.87])
by drummondgroup.com (8.12.11/8.12.11) with ESMTP id i8ONDr5L092728
for ; Fri, 24 Sep 2004 17:13:54 -0600 (MDT)
Message-Id: <200409242313.i8ONDr5L092728@drummondgroup.com>
From: "Kyle Meadors"
To:
Subject: draft-ediint-certificate-exchange-00.txt
Date: Fri, 24 Sep 2004 18:13:52 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcSijCcXCM1RuyTJQkeP+/fq1RLT8g==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i8ONDqWd032193
Sender: owner-ietf-ediint@mail.imc.org
Precedence: bulk
List-Archive:
List-ID:
List-Unsubscribe:
Content-Transfer-Encoding: 8bit
Draft CEM for EDIINT September 2004
EDIINT Working Group
Internet Draft K. Meadors
Document: draft-ietf-ediint-certificate- Drummond Group Inc.
exchange-00.txt D. Moberg
Expires: March 2005 Cyclone Commerce
September 2004
Certificate Exchange Messaging for EDIINT
Draft-ediint-certificate-exchange-00.doc
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Any questions, comments, and reports of defects or ambiguities in
this specification may be sent to the mailing list for the EDIINT
working group of the IETF, using the address .
Requests to subscribe to the mailing list should be addressed to
.
Copyright Notice
Copyright (c) The Internet Society (2004). All rights reserved.
Abstract
The EDIINT AS1, AS2 and AS3 message formats do not currently contain
any neutral provisions for transporting and exchanging trading
partner profiles or digital certificates. EDIINT Certificate Exchange
Messaging provides the format and means to effectively exchange
certificates for use within trading partner relationships. The
Meadors, Moberg Expires - March 2005 [Page 1]
Draft CEM for EDIINT September 2004
messaging consists of two types of messages, Request and Response,
which allow trading partners to communicate certificates, their
intended usage and their acceptance through XML. Certificates can be
specified for use in digital signatures, data encryption or SSL/TLS
over HTTP (HTTPS).
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Feedback Instructions
NOTE TO RFC EDITOR: This section should be removed by the RFC editor
prior to publication.
If you want to provide feedback on this draft, follow these
guidelines:
-Send feedback via e-mail to the ietf-ediint list for discussion,
with "Certificate Exchange" in the Subject field. To enter or follow
the discussion, you need to subscribe to ietf-ediint@imc.org.
-Be specific as to what section you are referring to, preferably
quoting the portion that needs modification, after which you state
your comments.
-If you are recommending some text to be replaced with your suggested
text, again, quote the section to be replaced, and be clear on the
section in question.
Table of Contents
1. Introduction...................................................3
1.1 Overview...................................................3
1.2 Terminology and Key Word Convention........................3
1.3 Certificate Lifecycle......................................5
2. Message Processing.............................................5
2.1 Message Structure..........................................5
2.2 Version Header.............................................6
2.3 Messaging Exchange.........................................6
2.4 Certificate Implementation.................................7
3. XML Schema Description.........................................8
3.1 EDIINTCertificateExchangeRequest element...................9
3.2 EDIINTCertificateExchangeResponse element.................12
4. Use Case Scenarios............................................14
Meadors, Moberg Expires - March 2005 [Page 2]
Draft CEM for EDIINT September 2004
4.1 Maintenance Configuration Processing......................14
4.2 Initial Configuration Processing..........................15
5. Profile Exchange Messaging....................................17
6. Security Considerations.......................................18
7. IANA Considerations...........................................18
8. References....................................................19
9. Acknowledgments...............................................19
Author's Addresses...............................................20
Appendix.........................................................20
1. Introduction
1.1 Overview
The growth and acceptance of EDIINT protocols, AS1, AS2 and AS3, in
numerous supply-chains was due in part to the security feature which
was provided. The security is not possible without the digital
certificates which enable it. To maintain the level of security
necessary to transmit business documentation, existing certificates
must occasionally be replaced and exchanged with newer ones. The
exchanging of digital certificates is unavoidable given how
certificates can expire or become compromised. Complicating this is
supply-chains which cannot afford to shutdown their business
transactions while trading partners laboriously upload new
certificates. Certificate exchange must be accomplished in a reliable
and seamless format so as not to affect ongoing business
transactions.
This document describes how EDIINT products may exchange public-key
certificates. Since EDIINT is built upon the security provided by
public-private key pairs, it is vital that implementers are able to
update their trading partners with new certificates as their old
certificates expire, become outdated or insecure. EDIINT Certificate
Exchange Messaging (CEM) described here utilizes XML data to exchange
the certificate and provide information on its intended usage and
acceptance within the trading partner relationship. There are two
types of CEM messages, the CEM Request which presents the new
certificate to be introduced into the trading partner relationship
and the CEM Response which is the recipient’s response to the CEM
Request. CE messages can be exchanged through AS1 [AS1], AS2 [AS2] or
AS3 [AS3] message transports. However, it is possible to leverage CE
messaging through other transport standards besides EDIINT.
1.2 Terminology and Key Word Convention
[RFC2818] provides a glossary of Internet security terms, and several
of their definitions are listed here verbatim. However, some
Meadors, Moberg Expires - March 2005 [Page 3]
Draft CEM for EDIINT September 2004
definitions required for this document were undefined by [RFC2818] or
rewritten to better explain their specific use within CEM.
Certificate – A digital certificate contains the owner’s (End
Entity’s) name, the issuer’s name, a serial number, expiration date,
and a copy of the owner’s Public Key. The Public Key is used for
Encrypting messages and Verifying Signatures (verifying a signature
is also called Authentication).
Certificate Revocation List (CRL) – A data structure that enumerates
digital certificates that have been invalidated by their issuer prior
to when they were scheduled to expire. [RFC2828]
Certification Authority (CA) – An entity that issues digital
certificates (especially X.509 certificates) and vouches for the
binding between the data items in a certificate. [RFC2828]
CA Certificate - A certificate issued by a trusted certification
authority. CA certificates are not used to encrypt data but to sign
other certificates. CA certificates are signed by themselves, but are
not considered self-signed certificates for the purpose of this
document.
Certification Hierarchy - In this structure, one CA is the top CA,
the highest level of the hierarchy. The top CA may issue public-key
certificates to one or more additional CAs that form the second
highest level. Each of these CAs may issue certificates to more CAs
at the third highest level, and so on. The CAs at the second-lowest
of the hierarchy issue certificates only to non-CA entities, called
"end entities" that form the lowest level. Thus, all certification
paths begin at the top CA and descend through zero or more levels of
other CAs. All certificate users base path validations on the top
CA's public key. [RFC2828]
CEM Request –The EDIINT Certificate Exchange Messaging (CEM) Request
is one of two possible CEM messages. It presents a certificate to be
introduced into the trading partner relationship along with relevant
information on how it is to be implemented.
CEM Response –The EDIINT Certificate Exchange Messaging (CEM)
Response is one of two possible CEM messages. It is the response to
the CEM Request indicating whether or not the end entity certificate
present in the CEM Request was accepted.
End Entity – A system entity that is the subject of a public-key
certificate and that is using, or is permitted and able to use, the
matching private key only for a purpose or purposes other than
signing a digital certificate; i.e., an entity that is not a CA.
[RFC2828]
Meadors, Moberg Expires - March 2005 [Page 4]
Draft CEM for EDIINT September 2004
End Entity Certificate - A certificate which is used to encrypt data
or authenticate a signature. (The private key associated with the
certificate is used to decrypt data or sign data). The certificate
may be self-signed or issued by a trusted certificate.
Intermediary Certificate - A certificate issued by a CA certificate
which itself issues another certificate (either intermediary or end
entity). Intermediary certificates are not used to encrypt data but
to sign other certificates.
Public Key - The publicly-disclosable component of a pair of
cryptographic keys used for asymmetric cryptography. [RFC2828]
Public Key Certificate - A digital certificate that binds a system
entity's identity to a public key value, and possibly to additional
data items. [RFC2828]
Self-signed Certificate - A certificate which is issued by itself
(both issuer and subject are the same) and is an End Entity
certificate.
1.3 Certificate Lifecycle
A certificate has five states.
1. Pending - Upon receiving a certificate from a trading partner, the
certificate is marked as Pending until a decision can be made to
trust it or if its validity period has not yet begun.
2. Rejected – If a Pending certificate is not trusted, it is
considered Rejected.
3. Accepted - Once a Pending certificate has been trusted, it is
considered Accepted. An Accepted certificate may be used in
secure transactions.
4. Expired – A certificate which is no longer valid because its
expiration date has passed. Expired certificates SHOULD be kept
in a certificate storehouse for decrypting and validating past
transactions.
5. Revoked – A certificate which has been explicitly revoked by its
owner or the certificate authority.
2. Message Processing
2.1 Message Structure
CEM messages use the underlying EDIINT transport, such as AS2, to
communicate information on the certificate, its intended use and its
acceptance. The information is XML data which is identified through
Meadors, Moberg Expires - March 2005 [Page 5]
Draft CEM for EDIINT September 2004
the MIME content-type of application/ediint-cert-exchange+xml. The
simple format for CEM messages is as follows:
Various EDIINT headers
Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="--BOUNDARY"
----BOUNDARY
Content-Type: application/ediint-cert-exchange+xml
[CEM XML data]
----BOUNDARY
Content-Type: application/pkcs7-signature
[Digital Signature]
----BOUNDARY--
Both the CEM Request and CEM Response message SHOULD be signed. If it
is desired to enable automatic exchange based on a previous trust
relationship, then both the CEM Request and CEM Response message MUST
be signed. Also, CEM messages SHOULD request a MDN and SHOULD request
a signed MDN. Extra security such as applying data encryption is
OPTIONAL. The MDN can be either synchronous or asynchronous. The MDN
response verifies the transport delivery but is not equivalent to the
CEM Response message. All necessary headers MUST be applied to the
message per the underlying transport standard.
2.2 Version Header
Before a CEM Request message is generated, the initiator MUST
determine if the recipient can accept the CEM Request message. For
both AS2 and AS3, the version header value of 1.2 or greater (e.g.
1.3) indicates the implementation can both initiate and receive CEM
message exchanges. AS2 and AS3 implementers of CEM MUST utilize the
proper version header in all of their messages, both CEM messages and
normal document transport messages. Since there is no AS1 version
header, trading partners using AS1 MUST decide within the trading
partner agreement whether to utilize CEM.
For CEM Request messages of initial trading partner configurations,
the initiator MUST decide within the trading partner agreement if the
recipient can accept the CEM Request.
2.3 Messaging Exchange
Meadors, Moberg Expires - March 2005 [Page 6]
Draft CEM for EDIINT September 2004
After obtaining the desired certificate, the initiator of the
certificate exchange transmits the certificate in the CEM Request
message. Multiple certificates may be included with the XML of the
CEM Request. If the end-entity certificate is not self-signed, then
the CA certificate and any other certificates needed to create the
chain of trust for the end-entity certificate are included in the XML
payload. Multiple end-entity certificates may also be present.
Information on how the certificate is to be used, or certificate
usage, is also found in the XML data. A certificate can be used for a
single function, like digital signatures, or used for multiple
functions, such as both digital signatures and data encryption. If a
certificate is intended for multiple usages, such as for both digital
signatures and data encryption, the certificate MUST be listed only
once in a CEM Request message and its multiple usage listed through
the CertUsage element.
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.
The new certificate is considered to be in the Pending state for the
recipient who MUST decide whether to accept the certificate as
trustworthy. This decision is arbitrary and left to each individual
trading partner. Upon accepting the certificate, it is to be
considered an Accepted certificate within the trading partner
relationship. If the certificate is not accepted, it is considered
Rejected. The recipient MUST respond with a CEM Response message
indicating its acceptance or rejection of the certificate. If
multiple certificates were included within the CEM Request, the
recipient MAY generate individual CEM Response messages for each
certificate or the recipient MAY consolidate responses for multiple
certificates in one or more CEM Response messages. The recipient MUST
NOT generate more than one CEM Response for a given certificate.
Based on the CEM Response message, the initiator determines if the
exchanged certificate may be used in future trading with the
recipient partner.
2.4 Certificate Implementation
When a certificate is intended for use in data encryption or TLS/SSL
server authentication, the initiator MUST consider the certificate to
be Accepted and be prepared for its trading partner to begin using
the certificate upon generating the CEM Request message. After a
recipient generates a positive CEM Response message for a
certificate, the recipient MUST immediately begin using the
Meadors, Moberg Expires - March 2005 [Page 7]
Draft CEM for EDIINT September 2004
certificate in trading with the initiator of the request. The
recipient MAY apply encryption to the CEM Response message using the
new Accepted certificate or MAY apply encryption to the CEM Response
message using the previously Accepted encryption certificate.
When a certificate is intended for use in digital signatures or
TLS/SSL client authentication, the initiator MUST NOT use the
certificate until the recipient trading partner generates a CEM
Response accepting the certificate or the start of the respond by
date, which is listed in the RespondByDate XML element. The initiator
MAY use the certificate after the respond by date, regardless of
whether the partner has accepted it or not. The certificate used for
the digital signature of the CEM Request message MUST be the one
which is currently Accepted within the trading partner relationship.
Since implementers of EDIINT often use the same certificate with
multiple trading partners, implementers of CEM MUST be able to keep
both the old and new certificates as Accepted. If the initiator has
generated a CEM Request and exchanged a new encryption certificate to
multiple trading partners, it MUST be able to accept encrypted data
which uses either the older, existing encryption certificate or the
newly exchanged encryption certificate. Likewise, a recipient of a
CEM Request MUST be able to authenticate digital signatures using
either the new or old certificates, since the initiator may not be
able to switch certificates until all trading partners accept the new
certificate. Similar provisions MUST be made for certificates
intended for TLS/SSL server and client authentication. Revoking a
certificate MUST be done outside of CEM.
If a CEM Request message contains a certificate which is currently
Accepted and has the identical usage for the certificate that has
been Accepted, the recipient MUST NOT reject the duplicate
certificate but MUST respond with a CEM Response message indicating
the certificate has been accepted. For example, if Certificate A is
currently Accepted as the encryption certificate for Implementation
X, any CEM Request message containing Certificate A with the usage as
the encryption only MUST be accepted by an existing trading partner.
This situation may be necessary for an implementation intending to
verify its current trading partner certificate.
If two trading partners utilize multiple EDIINT protocols for
trading, such as AS2 for a primary transport and AS1 as the backup
transport, it is dependent upon implementation and trading partner
agreement how CEM messages are sent and which transports the
exchanged certificates affect.
3. XML Schema Description
Meadors, Moberg Expires - March 2005 [Page 8]
Draft CEM for EDIINT September 2004
The CEM schema has two top-level elements,
EDIINTCertificateExchangeRequest and
EDIINTCertificateExchangeResponse. The
EDIINTCertificateExchangeRequest element is present only in the CEM
Request message, and the EDIINTCertificateExchangeResponse is present
only in the CEM Response message. All other elements nest directly or
indirectly from these. Please refer to the appendix for the actual
schema document.
3.1 EDIINTCertificateExchangeRequest element
EDIINTCertificateExchangeRequest contains two elements,
TradingPartnerInfo, which can only appear once and TrustRequest,
which may be present multiple times. TrustRequest contains
information on a certificate and its intended usage.
TradingPartnerInfo exists to provide information on the publication
of the CEM Request message since processing of the XML data may occur
apart from the handling of the accompanying transport message, for
example the AS2 request.
TradingPartnerInfo identifies the entity that created the CEM message
through the nested Name element. Both the optional qualifier
attribute and the element value of Name are left open to the
implementer, but some suggested choices are to list the EDI
identification or the transport trading partner relationship, for
example the qualifier of “AS2” and the value of the AS2 system
identifier (AS2-From value). MessageOriginated is included in
TradingPartnerInfo to identify the time and date the message was
created. The MessageOriginated date and time values MUST follow XML
standard dateTime type syntax and be listed to at least the nearest
second and expressed in local time with UTC offset.
Meadors, Moberg Expires - March 2005 [Page 9]
Draft CEM for EDIINT September 2004
The TrustRequest element contains the EndEntity, TrustChain,
CertUsage, RespondByDate and ResponseURL elements. The required
EndEntity element is found only once in a TrustRequest element and
contains the end entity certificate being exchanged. TrustChain
contains any certificates necessary to complete the chain of trust
for the end entity certificate. For example, if the end entity
certificate being exchanged is self-signed then there would not be a
TrustChain element. However, if the end entity certificate is issued
by an intermediary certificate which is issued by a root CA
certificate, both the intermediary certificate and the CA certificate
would be placed in the same X509Data element within the same
TrustChain element.
EndEntity contains the nested elements of CertificateIdentifier and
X509Data, and TrustChain only contains X509Data. Both
CertificateIdentifier and X509Data come from the XML Signature schema
namespace [XML-DSIG].
Meadors, Moberg Expires - March 2005 [Page 10]
Draft CEM for EDIINT September 2004
CertificateIdentifier contains the string element X509IssuerName and
the integer element X509SerialNumber. X509SerialNumber is the
assigned serial number of the end entity certificate as it is listed.
X509IssuerName contains the issuer name information of the end-entity
certificate, such as common name, organization, etc. This information
can be described in any format, but it is RECOMMENDED to list each
issuer attribute abbreviation [X.520] [PROFILE] followed by the equal
sign (i.e. “=”), then separating each attribute listing by a single
semi-colon (e.g. CN=The Common Name;O=Organization;…). Refer to the
appendix and the sample CEM Request message for an example of the
X509IssuerName.
X509Data element contains the digital certificate. For both the
EndEntity and TrustChain elements, the choice for displaying the
certificate MUST be the X509Certificate element within X509Data. The
certificate MUST be encoded in base64.
Meadors, Moberg Expires - March 2005 [Page 11]
Draft CEM for EDIINT September 2004
CertUsage is an unbounded element which contains enumerated values on
how the exchanged certificate is to be used. There are enumerated
values for SMIME digital signatures (digitalSignature), SMIME data
encryption (keyEncipherment), the server certificate used in TLS
transport encryption (tlsServer) and the client certificate used in
TLS transport encryption (tlsClient). While the element is unbounded,
CertUsage only has a potential number of four occurrences due to the
limit of the enumerated values.
RespondByDate is a required element of the XML standard dateTime type
expressed in local time with UTC offset, which provides information
on when the certificate should be trusted, inserted into the trading
partner relationship and responded to by a CEM Response message. If
the certificate can not be trusted or inserted into the trading
partner relationship, the CEM Response message should still be
returned by the date indicated.
ResponseURL is an optional element which indicates where the CEM
Response message should be sent. This value takes precedence over the
existing inbound URL of the current trading partner relationship. If
the element is absent, the CEM Response message is returned according
to the URL stipulated in the trading partner relationship. The
Response MUST use the same transport protocol (AS1, AS2, or AS3) as
the Request. The Response URL MUST use this protocol.
3.2 EDIINTCertificateExchangeResponse element
EDIINTCertificateExchangeResponse contains the two elements
TradingPartnerInfo and TrustResponse. TradingPartnerInfo, which is
also found in EDIINTCertificateExchangeRequest, describes the trading
partner generating this response message. TrustResponse provides
information on the acceptance of a previously sent end entity
certificate. There can be multiple TrustResponse elements within an
EDIINTCertificateExchangeResponse.
Meadors, Moberg Expires - March 2005 [Page 12]
Draft CEM for EDIINT September 2004
A TrustResponse element identifies a certificate which has been
previously exchanged within the trading partner relationship through
a CEM Request and now has been either accepted or rejected by the
partner. The CertificateReference element is of the same type as the
CertificateIdentifier element. A CertificateReference element in a
CEM Response MUST be identical to its CertificateIdentifier
counterpart in the associated CEM Request since they identify the
same certificate in question.
The required element CertStatus has the enumerated values of
“Accepted” or “Rejected”. “Accepted” indicates the certificate was
trusted by the trading partner and is now ready for use within the
trading partner relationship, and “Rejected” indicates the
certificate is not trusted by the trading partner nor can it be
currently used with the trading partner relationship. If the value of
“Rejected” is chosen, the optional string element ReasonForRejection
may be included. If present, ReasonForRejection should contain a
brief description of why the certificate was not accepted. Since the
value for this element is not enumerated but open, it MUST be
interpreted through human means.
Meadors, Moberg Expires - March 2005 [Page 13]
Draft CEM for EDIINT September 2004
4. Use Case Scenarios
These scenarios illustrate how the request and response messages
described in Section 2 and 3 can be used to exchange certificates.
The requirements of this standard are in Section 2 and 3; this
section is only illustrative.
4.1 Maintenance Configuration Processing
This use case assumes an established relationship with currently
working certificates. Examples of this use case include, but are not
limited to a certificate with an expiration date approaching. If the
current certificate is used to sign the Certificate Exchange
messages, this signature can be used to establish a level of trust in
the transaction. For this example, the AS2 transport protocol is
used.
4.1.1. Step 1
Initiator creates an EDIINTCertificateExchangeRequest as described in
Section 2. Message Processing and Section 3. XML Schema Description
and sends it according to EDIINT-AS2 protocol. A positive MDN
received during this step indicates 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 acceptance of the certificate. 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.1.2. Step 2
Receiver validates the EDIINTCertificateExchangeRequest message at
the AS2 level and returns a correct MDN. If the message is a proper
AS2 document, the receiver MUST automatically accept or reject the
new certificate(s) or require manual intervention. If the certificate
is automatically accepted or rejected, an
EDIINTCertificateExchangeResponse MUST be 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 MUST be generated and returned to
the initiator. Both automatic and manual
Meadors, Moberg Expires - March 2005 [Page 14]
Draft CEM for EDIINT September 2004
EDIINTCertificateExchangeResponses MUST be 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.
After the receiver accepts the new certificate and returns an
acceptance response, the receiver encrypts all messages to the
initiator with the new encryption certificate. The receiver
continues to accept messages from the initiator that are signed with
the old signing certificate, and also accepts messages signed with
the new signing certificate. The initiator may start signing with
the new certificate when it receives the acceptance response, or when
it receives acceptance responses from all its partners, or after the
RespondByDate, or when the old signing certificate expires.
4.1.3. Step 3
After the exchange is complete, some cleanup may be desirable,
including retiring or archiving the old certificates. This step is
considered an implementation detail that is left purely to the
vendors and users.
4.2 Initial Configuration Processing
This use case assumes all necessary elements of an EDIINT
relationship exist outside of the certificates, including an
understanding of the partner’s ability to support a CEM.
Establishing these elements may be accomplished via an automated
exchange, a manual process, or any other method desirable. No
methods of exchanging the additional information are described in
this specification. Examples of this use case include, but are not
limited to the first exchange of a certificate, or recovery from an
expired or compromised certificate. This case assumes no signing
certificate has been established, precluding a signature being used
to establish a level of trust. Therefore, extra precautions may be
appropriate in this use case. There are additional use cases
possible where some certificates are already established. It is not
practical to cover every case here, but this case and the maintenance
case should give sufficient guidance.
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. If the
receiver supports this use case, they MUST accept this message
Meadors, Moberg Expires - March 2005 [Page 15]
Draft CEM for EDIINT September 2004
regardless of the presence of a signature. Unless the initiator
possesses the receiver’s encryption certificate, encryption MUST NOT
be used. Unless the initiator possesses the receiver’s signature
certificate, they SHOULD 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. If the message is a proper AS2 document, the receiver MUST
automatically accept or reject the new certificate(s), or require
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 MUST be 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 MUST be generated and returned to
the initiator.
In both the automatic and manual case, the
EDIINTCertificateExchangeResponses MUST be formatted according to
Section 2. Message Processing and Section 3. XML Schema Description
and sent according to EDIINT-AS2 protocol. If the original CEM
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 MUST accept this response, regardless
of if it is signed. A positive MDN received for the response message
indicates successful transmission of the response message.
Meadors, Moberg Expires - March 2005 [Page 16]
Draft CEM for EDIINT September 2004
After the receiver accepts the certificate and returns an acceptance
response, the receiver may encrypt messages to the initiator with the
encryption certificate. The receiver begins to accept messages from
the initiator that are signed with the signing certificate. The
initiator may start signing with the certificate when it receives the
acceptance response, or when it receives acceptance responses from
all its partners, or after the RespondByDate.
4.2.3. Step 3
After the exchange is complete, additional certificates may need to
be exchanged before a complete trading relationship can be
successful. This step is considered an implementation detail that
is left purely to the vendors and users.
5. Profile Exchange Messaging
CEM provides the means to exchange certificates among trading
partners. However, other profile information, such as URLs and
preferred security settings, is needed to create a trading partner
relationship. A future standard is needed to describe profile
descriptions and how they will be exchanged. The format for this
profile attachment is not defined in this specification but is
planned for a future document. It will build upon the existing CEM
protocol with profile information stored with XML data. Both
certificate and profile description information will be placed into a
multipart/related [RFC2387] body part entity. A possible format for a
profile description message is as follows:
Various EDIINT headers
Disposition-Notification-To: http://10.1.1.1:80/exchange/as2_company
Disposition-Notification-Options: signed-receipt-protocol=optional,
pkcs7-signature; signed-receipt-micalg=optional, sha1
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature"; boundary="--BOUNDARY1"
----BOUNDARY1
Content-Type: multipart/related;
start=”";
type=”application/ediint-cert-exchange+xml”;
boundary="--BOUNDARY2"
----BOUNDARY2
Content-Type: application/ediint-cert-exchange+xml
Content-ID:
[CEM XML data]
----BOUNDARY2
Meadors, Moberg Expires - March 2005 [Page 17]
Draft CEM for EDIINT September 2004
[Profile information attachment]
----BOUNDARY2--
----BOUNDARY1
Content-Type: application/pkcs7-signature
[Digital Signature]
----BOUNDARY1--
6. Security Considerations
Certificate exchange is safe for transmitting. However, implementers
SHOULD verify the received certificate to determine if it is truly
from the stated originator through out-of-band means for the initial
use case of 4.2 or whenever the request is not signed.
7. IANA Considerations
MIME Media type name: Application
MIME subtype name: EDIINT-cert-exchange+xml
Required parameters: None
Optional parameters: This parameter has identical semantics to the
charset parameter of the “application/xml” media type as specified
in [RFC3023].
Encoding considerations: Identical to those of "application/xml" as
described in [RFC3023], section 3.2.
Security considerations: See section 6.
Interoperability Considerations: See section 2.2
Published specification: This document.
Applications which use this media type: EDIINT applications, such as
AS1, AS2 and AS3 implementations.
Additional Information: None
Intended Usage: Common
Author/Change controller: See Author’s section of this document.
Meadors, Moberg Expires - March 2005 [Page 18]
Draft CEM for EDIINT September 2004
8. References
[AS1] RFC3335 “MIME-based Secure Peer-to-Peer Business Data
Interchange over the Internet using SMTP”, T. Harding, R.
Drummond, C. Shih, 2002.
[AS2] draft-ietf-ediint-as2-15.txt “MIME-based Secure Peer-to-Peer
Business Data Interchange over the Internet using HTTP”, D.
Moberg, R. Drummond, 2004.
[AS3] draft-ietf-ediint-as3-02.txt “MIME-based Secure Peer-to-Peer
Business Data Interchange over the Internet using FTP”, T.
Harding, R. Scott, 2003.
[RFC2119] RFC2119 “Key Words for Use in RFC's to Indicate Requirement
Levels”, S.Bradner, March 1997.
[RFC2246] RFC2246 "The TLS Protocol", Dierks, T. and C. Allen,
January 1999.
[RFC2387] RFC2387 "The MIME Multipart/Related Content-type", E.
Levinson, August 1998.
[RFC2818] RFC2818 "HTTP over TLS", Rescorla, E., May 2000.
[RFC2828] RFC2828 “Internet Security Glossary”, R. Shirley, May 2000.
[RFC3023] RFC3023 “XML Media Types”, M. Murata, January 2001.
[S/MIME] RFC2633 “S/MIME Version 3 Message Specification”,
B.Ramsdell, June 1999.
[XML-DSIG] RFC3275 “XML-Signature Syntax and Processing”, D.
Eastlake, March 2002.
[X.520] ITU-T Recommendation X.520: Information Technology – Open
Systems Interconnection - The Directory: Selected Attribute
Types, 1993.
[PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and CRL Profile",
RFC 3280, April 2002.
9. Acknowledgments
The authors wish to extend gratitude to the ecGIF sub-committee
within the EAN.UCC organization from which this effort began. Of
special note is John Duker who chaired the sub-committee and provided
valuable editing, Richard Bigelow who greatly assisted development of
Meadors, Moberg Expires - March 2005 [Page 19]
Draft CEM for EDIINT September 2004
the ideas presented, John Koehring with his insights on
implementation and James Zwyer for his contribution to the use case
scenarios.
Author's Addresses
Kyle Meadors
Drummond Group Inc.
4700 Bryant Irvin Court, Suite 303
Fort Worth, TX 76107 USA
Email: kyle@drummondgroup.com
Dale Moberg
Cyclone Commerce
8388 E. Hartford Drive, Suite 100
Scottsdale, AZ 85255 USA
Email: dmoberg@cyclonecommerce.com
Appendix
A.1 EDIINT Certificate Exchange XML Schema
Meadors, Moberg Expires - March 2005 [Page 20]
Draft CEM for EDIINT September 2004
Meadors, Moberg Expires - March 2005 [Page 21]
Draft CEM for EDIINT September 2004
A.2 Example of EDIINT Certificate Exchange Request XML
Somewhere.com
2005-05-17T07:21:00-03:00
digitalSignature
2005-05-20T07:21:00-03:00
http://somewhere.com/someplace
CN=EDIINT WG; O=IETF; OU=EDIINT;
L=New York; S=New York; C=US
123454321
Meadors, Moberg Expires - March 2005 [Page 22]
Draft CEM for EDIINT September 2004
MIICXTCCA..
MIICPzCCA...
MIICSTCCA...
keyEncipherment
2005-05-20T07:21:00-03:00
http://foo.com/path
CN=EDIINT WG; O=IETF; OU=EDIINT;
L=New York; S=New York; C=US
987654321
MIICXTCCA..
MIICPzCCA...
MIICSTCCA...
A.3 Example of EDIINT Certificate Exchange Response XML
Rejected
Meadors, Moberg Expires - March 2005 [Page 23]
Draft CEM for EDIINT September 2004
Invalid KeyUsage
extension
CN=EDIINT WG; O=IETF; OU=EDIINT;
L=New York; S=New York; C=US
123454321
Accepted
CN=US;O=Somewhere.com
987654321
Meadors, Moberg Expires - March 2005 [Page 24]
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 9/17/2004
From micheal1935@voila.fr Mon Sep 27 12:07:20 2004
Received: from mwinf4006.voila.fr (smtp1.voila.fr [193.252.22.174])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10063
for ; Mon, 27 Sep 2004 12:07:19 -0400 (EDT)
From: micheal1935@voila.fr
Received: from me-wanadoo.net (localhost [127.0.0.1])
by mwinf4006.voila.fr (SMTP Server) with SMTP
id 66F0418000B9; Mon, 27 Sep 2004 18:06:48 +0200 (CEST)
Received: from wwinf4001 (wwinf4001 [172.22.157.28])
by mwinf4006.voila.fr (SMTP Server) with ESMTP
id 5CD9818000AF; Mon, 27 Sep 2004 18:06:48 +0200 (CEST)
Message-ID: <9001186.1096301208198.JavaMail.www@wwinf4001>
Reply-To: micheal1935@voila.fr
Subject: URGENT RESPONSE
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_92047_11927362.1096301208194"
X-Originating-IP: [213.181.81.58]
Date: Mon, 27 Sep 2004 18:06:48 +0200 (CEST)
To: undisclosed-recipients: ;
------=_Part_92047_11927362.1096301208194
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
NICON ASSOCIATES
45/46 NICON HOUSE Ste 4
LAGOS,NIGERIA.
From the desk of:MICHEAL SMITH(ATTORNEY)
HEAD OF CHAMBER
Our Ref:........Your Ref:........Date:.....
ATTENTION:
Dear Sir,
URGENT BUSINESS REQUEST
I am a lawyer resident and practicing in LAGOS,
NIGERIA and I am using this correspondence to urgently seek and
request
your assistance and cooperation in a sensitive but highly beneficial
financial arrangement.Important clients of mine whose details I
cannot
release at this point has implored me to contact a reliable and
trustworthy
partner overseas to urgently receive and handle funds totaling THIRTY
MILLION US DOLLARS (US$30.M) in CASH presently lodged in a
security/finance outfit in LONDON (UK). Due to my client's inability
to travel out of the country presently and the fact that we continue
to accumulate huge debts daily as long as this consignment remains in
the security company we need a friend and partner to proceed as soon
as possible and retrieve this money on behalf of my clients and handle
it as duly instructed.
We intend to share this amount as follows: 65% for I
and my clients, 30% for you and 5% for any
contingencies. We expect this deal to be completed
within 14 (fourteen) working days, and all our
transaction shall be in accordance with the laws and
procedures on international remittance of fund.
Thank you in anticipation of your cooperation and hoping
to hear from you soon.
Yours' sincerely,
MICHEAL SMITH(ATTORNEY)
HEAD OF CHAMBER
------------------------------------------
Faites un voeu et puis Voila ! www.voila.fr
------=_Part_92047_11927362.1096301208194
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
NICON ASSOCIATES
45/46 NICON HOUSE Ste 4
LAGOS,NIGERIA.
From the d=
esk of:MICHEAL SMITH(ATTORNEY)
HEAD OF CHAMBER
Our Ref:........Your =
Ref:........Date:.....
ATTENTION:
Dear Sir,
&n=
bsp;  =
; URGENT BUSINESS REQUEST
I am a lawyer resident=
and practicing in LAGOS,
NIGERIA and I am using this correspondence to=
urgently seek and
request
your assistance and cooperation in a sen=
sitive but highly beneficial
financial arrangement.Important clients of=
mine whose details I
cannot
release at this point has implored me =
to contact a reliable and
trustworthy
partner overseas to urgently =
receive and handle funds totaling THIRTY
MILLION US DOLLARS (US$30.M) i=
n CASH presently lodged in a
security/finance outfit in LONDON (UK). Du=
e to my client's inability
to travel out of the country presently and t=
he fact that we continue
to accumulate huge debts daily as long as this=
consignment remains in
the security company we need a friend and partn=
er to proceed as soon
as possible and retrieve this money on behalf of =
my clients and handle
it as duly instructed.
We intend to share thi=
s amount as follows: 65% for I
and my clients, 30% for you and 5% for an=
y
contingencies. We expect this deal to be completed
within 14 (fourt=
een) working days, and all our
transaction shall be in accordance with t=
he laws and
procedures on international remittance of fund.
Thank you=
in anticipation of your cooperation and hoping
to hear from you soon.Yours' sincerely,
MICHEAL SMITH(ATTORNEY)
HEAD OF CHAMBER
----=
--------------------------------------
Faites un voeu et puis Voila =
! www.voila.fr
------=_Part_92047_11927362.1096301208194--
From annoucement@computeradmin.org Thu Sep 30 13:27:29 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 NAA12195
for ; Thu, 30 Sep 2004 13:27:28 -0400 (EDT)
Received: from [221.10.145.8] (helo=MAIL-SERVER)
by ietf-mx.ietf.org with smtp (Exim 4.33)
id 1CD4qZ-0005rb-PW
for ediint-archive@ietf.org; Thu, 30 Sep 2004 13:36:06 -0400
Received: from [226.121.43.36]
by MAIL-SERVER SMTP id w3axUMw6P6xS6O;
Thu, 30 Sep 2004 19:25:57 +0100
Message-ID:
From: "Admin"
To: com@ietf.org
Subject: ADV: Announcement To All Staff
Date: Thu, 30 Sep 04 19:25:57 GMT
X-Priority: 1
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="BF.635CA4E_"
X-Spam-Score: 36.7 (++++++++++++++++++++++++++++++++++++)
X-Spam-Flag: YES
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
This is a multi-part message in MIME format.
--BF.635CA4E_
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Attention All Nonprofit Organizations: Members, Staff and Associates:
You Must Respond By 5 P.M. Friday, October 1, 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 1, 2004.
All desktop 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 2004
next generation technology, making these the best performing
computers money can buy.
Avtech Direct is offering these feature rich, top performing
Desktop Computers with the latest Intel technology at an amazing price
to all who call:
1-800-884-9510 by 5 P.M. Friday, October 1, 2004
The fast and powerful AT-2400 series Desktop features:
* Intel 2.0Ghz 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
* 1.44 Floppy disk drive
* Next Generation Technology
* ATI Premium video and sound
* 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 $699 ........................................ Your Cost $297
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-884-9510 by 5 P.M. Friday, October 1, 2004
and we will hold the desktops you request on will call.
4. You are not obligated in any way.
5. 100% Satisfaction Guaranteed.
Call Avtech Direct 1-800-884-9510 before 5 P.M. Friday, October 1, 2004
Visit our website at http://www.avtechdirectcomputers.com
If you wish to unsubscribe from this list, please go to:
http://www.computeradvice.org/unsubscribe.asp
Avtech Direct
22647 Ventura Blvd., Suite 374
Woodland Hills, CA 91364
--BF.635CA4E_--