and vise versa) and are available for free from one of several ftp
archive servers. Use of these compression routines should be used
with care when one is employing an encryption technique such as PEM
or PGP.
5.8. Can the ISA 06 or 08 identify any entity other than the
'end' Trading Partners (i.e. a routing entity) ?
Yes, although the ISA06 and ISA08 elements are supposed to be used to
identify the sender and receiver of the interchange, the receiver of
the interchange could be a clearinghouse (as well as a VAN) that
processes the interchange and then forwards the data to the ultimate
recipient. In this case, you could put the receiver ID of the
clearinghouse into the ISA08. The clearinghouse would probably have
to determine the ultimate recipient of the message by looking inside
the transaction set (or perhaps by using the GS03). Alternatively,
you could put the receiver ID of the ultimate recipient into the
ISA08 and the clearinghouse would route the interchange based on the
ISA08 value (just as a VAN does).
5.9. Can we specify both the recipient's address and their VAN
address in the ISA ?
There was an X12 DM (data maintenance) request proposed to the X12
standards committee for a change to the ISA segment (X12 header
information) that would allow users to specify the recipient's VAN,
in addition to the recipient's ID. The intent was to provide a
hierarchical address in the ISA. The top level would be the VAN ID,
and the next level would be the recipient ID. To date, this DM has
not been approved.
5.10. Are there other options for routing EDI X12 messages ?
Yes, the GS02 and GS03 data elements can be used for a second level
of routing. The GS03 is the application receiver's code. Some EDI
users use the GS03 for routing a functional group to a particular
department or application within the receiver's corporation. For
example, you could use the ISA08 to identify the receiver as "Acme
Corporation" and use the GS03 to identify the receiving application
as the "Purchasing department (within Acme Corporation)". Many EDI
users simply put the same value in the ISA06 and the GS02, and put
the same value in the ISA08 and the GS03. Interestingly, there are
VANs that will broadcast a message. Other VANs will map the value of
the ISA08 into a distribution list VAN mailbox ids maintained by the
VAN. Thus, each recipient receives the exact same copy of the
interchange and the value of the ISA08 is not changed by the VAN.
6. US Federal Involvement
6.1. What is the commitment of the US Federal Government to EDI ?
In the Federal Information Processing Standard (FIPS) 161-1 for
Electronic Data Interchange[2], the US Government committed to using
EDI X12 and EDIFACT standards in the exchange of business information
with trading partners already using EDI. On October 26, 1993,
President Clinton signed an Executive memorandum requiring Federal
agencies to implement the use of electronic commerce in Federal
purchases as quickly as possible. As the initial step the
President's Management Council (PMC) Electronic Commerce Task Force
(ECTF), chaired by the Administrator, Office of Federal Procurement
Policy (OFPP), chartered the Federal Electronic Commerce Acquisition
Team (ECAT) memorandum. The PMC gave ECAT the task of defining the
architecture for the government-wide electronic commerce acquisition
system and identifying the executive departments or agencies
responsible for developing, implementing, operating, and maintaining
the Federal electronic system.
ECAT has become the Federal Electronic Commerce Program Management
Office (ECA-PMO). The National Institute or Science and Technology
(NIST) maintains an HTML home page for the ECA-PMO:
http://snad.ncsl.nist.gov/dartg/edi/fededi.html
6.2. What is the timetable for the Federal effort ?
To implement EC and to achieve his objectives for EC, the President
set forth the following four milestones:
1) By March 1994, define the architecture for the
government-wide EC acquisition system and identify
executive departments or agencies responsible for
developing, implementing, operating, and maintaining
the Federal electronic system. The ECAT identified
the architecture and recommend actions that each agency
should take. These documents are available via ftp at
ds.internic.net in the directory /pub/ecat.library.
ftp://ds.internic.net/pub/ecat.library/
2) By September 1994, establish an initial EC capability
to enable the Federal government and private suppliers
to exchange standardized requests for quotations (RFQs),
quotes, purchase orders, and notice of awards and begin
government-wide implementation.
3) By July 1995, implement a full-scale Federal EC system
that expands initial capabilities to include electronic
payments, document interchange, and supporting data bases.
4) By January 1997, complete government-wide implementation
of EC for appropriate Federal purchases, to the maximum
extent possible.
6.3. Will the US Government use the Internet to send EDI transactions ?
According to the ECAT, achieving the following objectives are
essential for a successful ubiquitous government EDI capability:
1) E-mail systems may be used as the transport medium for EDI
transactions.
2) FTP, FTAM, SMTP, X.400, or X.400 compatible substitutes
are the preferable transport methods for EDI.
3) EDI functionality must be supported such that the user can
choose between the Internet Protocol Suite (IPS) and Open
Systems Interconnection (OSI) protocol support.
4) Directory services will be provided through the X.500 model
as services become available.
5) Initial implementation of X.400 shall support the user agent
services defined in P2 and P22 protocols.
6) By 1996, the X.400 implementations shall contain the
services defined in the X.435 specification.
7) The Internet network may be used for EDI transactions when
it is capable of providing the essential reliability,
security, and privacy needed for business transactions.
6.4. I heard the US Government prohibited commercial use of the
Internet?
The Internet contains many Internet Service Providers (ISPs), each
with its own internal policies governing the conduct of its
customers. One of the largest ISPs is the National Science
Foundation. At one time, NSF adopted what is called the Acceptable
Use Policy of the National Science Foundation (NSF) was intended to
prevent commercial uses of the original NSF-sponsored Internet
telecommunications backbone. However, the growing number of
commercial providers and backbones now part of the Internet have made
this policy obsolescent. NSF is currently reducing its direct
support in favor of subsidies to universities and other NSF sponsored
organizations. Today the US Government is actively encouraging
commercial uses of the Internet.
6.5. The US Government is using both Internet and OSI E-mail
protocols. What should one consider when choosing which to use ?
For more than a decade, Federal policy has been to promote the Open
Systems Interconnection (OSI) telecommunications protocols developed
by international standards bodies. Despite this policy, Government
agencies, like the private sector, have invested far more in Internet
than OSI compliant products. Marshall T. Rose's "The Internet
Message"[3] compares the two alternative protocol suites and finds
clearly in favor of the IPS for messaging in general. For EDI
specifically, the advantages of the IPS are its simplicity, wide
availability, and security provided by Privacy Enhanced Mail (PEM,
see below). IPS lacks a number of desirable features and incurs
something of an efficiency penalty for binary transfers. On the
other hand, the OSI standard for messaging handling service (X.400)
promises a complete solution for EDI; the X.435 protocol includes
responsibility notifications, X.500 directory support, EDI-specific
addressing, message store support, message security, and other EDI-
specific services. Unfortunately, only a handful of X.435 products
have actually reached the market, their interoperability is not
assured, and their prices are substantially greater than for their
IPS counterparts. X.400 addressing tends to lock the customer into
the domain of the service provider, whereas SMTP/MIME addresses are
independent of the provider, permitting the customer to take his/her
business elsewhere relatively easily. The bottom line is that a lot
more organizations do EDI via the Internet than via OSI.
6.6. How is the US Government using VANs to distribute business
opportunities?
Presently, VANs make EDI request for quotation (RFQ) transactions
available to their subscribers (along with other services). For
example, a VAN client may ask that all RFQs for chairs be forwarded
immediately to them but the client is not interested in being
notified about RFQs for paper products. When a VAN sends an RFQ to a
specific client mailbox, the VAN modifies the "to address" to that of
the client. In this way, a vendor need only subscribe to a VAN that
is certified to receive and post the RFQs. The vendor then sees a
single source for all RFQs of interest, regardless of which buying
organization originated them. The screening and filtering process
performed by the VANs prevents the spread of electronic "junk" mail.
However, a trading partner could use an email filtering program to
filter and sort email, saving on VAN charges.
6.7. How would use of the Internet for Federal procurement change
this RFQ process?
Initially, very few changes may be apparent. New and existing VANs
will use the Internet to collect and disseminate EDI transactions;
trading partners may be totally unaware of the change in technology.
Prices may fall as VANs share telecommunications resources through
Internet Protocols rather than maintain their own costly proprietary
telecommunications services. Instead of competing with VANs, the
ubiquitous connectivity of the Internet offers VANs even greater
business opportunities. General purpose Internet Service Providers
(ISPs) do not typically offer EDI specific services, but they can
provide an alternative means to transfer EDI messages at a small
fraction of the cost of typical EDI VANs.
The impact of an organization's moving EDI onto the Internet,
independent of a VAN, is more difficult to assess. In the view of
some, the introduction of the Internet in the near term (1-5 years)
adds additional interfaces and complexity to the organization's
existing EDI environment. This may in the short term increase costs
and raise new costs. But a corporate commitment to an open systems
environment through the use of Internet Protocols offers the
potential for a greater interoperability, integration of application
systems, and therefore the promise of higher performance and lower
costs. Some organizations will be able to get to these benefits
others will pay for a set of largely incompatible services. The
return on investment largely depends on one's ability to consider EDI
on the Internet as a part of the organization's overall information
systems strategy and the organization's plans for a presence on the
Internet.
7. EDI Resources On The Internet
7.1. Are EDI Standards available on the Internet ?
The Data Interchange Standards Association (DISA) has a World Wide
Web server at "http://www.disa.org/" This Web server has
considerable information, including a list of new standards, a list
of all the X12 transaction sets, meeting minutes, calendar of events,
and lists of courses. Unfortunately, as of this date, the X12
standards are not available electronically. [soap ...] Hopefully
that will be added soon. [...soap]. DISA has also set up a gopher
server (gopher.disa.org) and an FTP server (ftp.disa.org).
The principle documents regarding ANSI ASC X12's planned alignment
with EDIFACT are available on the World Wide Web. The alignment plan
adopted by a mail ballot of X12 in December 1994/January 1995 is at
http:/www.disa.org/info/alinplan.html
The "floor motion" adopted at the X12 meeting in February 1995 is at:
http:/www.disa.org/meetings/alinmotn.html
The following mail lists and exploders support X12 and EDIFACT
standards development work.
------------------
X12G Mailing list:
------------------
This is a fully open exploder set up to support X12G.
To subscribe send an e-mail message to:
x12g-request@snad.ncsl.nist.gov
The text of the message should only contain the following:
subscribe x12g
After you subscribe, you can broadcast your messages to the
participants (who have subscribed) via the address
x12g@snad.ncsl.nist.gov.
---------------------
FED-REG Mailing list:
---------------------
This new exploder is concerned with the federal EDI Registry and
the implementation of IMPDEF within the registry, the EDI Viewers
and Editors, and the use of IMPDEF to upgrade EDI products. The
nature of this mailist calls for informal discussion focusing on
pragmatic issues.
To subscribe send an e-mail message to:
fed-reg-request@snad.ncsl.nist.gov
The text of the message should only contain the following:
subscribe fed-reg
Messages intended for the fed-reg list should be sent to:
fed-reg@snad.ncsl.nist.gov
-------------------------
X12C-IMPDEF Mailing list:
-------------------------
This exploder deals with formal discussion in the context of X12
regarding the evolution of IMPDEF. If would expect that
discussions in the context of the "fed-reg" exploder result in
formal DMRs submitted to "x12c-impdef" and X12C. Anyway, the
process will be defined and controlled by the appropriate X12C
authority.
To subscribe send an e-mail message to:
x12c-impdef-request@snad.ncsl.nist.gov
The text of the message should only contain the following:
subscribe x12c-impdef
Messages intended for the fed-reg list should be sent to:
x12c-impdef@snad.ncsl.nist.gov
See section 7.7 for additional EDI related mailing lists.
7.2. Are EDIFACT Standards available on the Internet ?
You can access the EDIFACT standards via GOPHER from the
International Telecommunications Union (gopher://info.itu.ch). Here
are the general directions in getting to the standards.
1. Launch the gopher client as gopher info.itu.ch
2. Select entry 11 (UN and international organizations)
3. Select entry 1 (UN EDITRANS, UN/EDIFACT (EDICORE))
4. Select entry 3 (UN-EDIFACT Standards Database (EDICORE))
5. Select entry 1, Publications.
If you want the actual standards, select 1, Drafts. You will get
D93A (which becomes the standard S94a)
D94A (which will be next year's standard).
If you want the UNTDED, select 2. If you want the UNTDID, select 3.
When you get to the lowest level directory in which ever path you
choose, press D (i.e. upper case D) to download. Choose the protocol
that suits and you are the proud owner of an EDIFACT Standards
Directory.
For electronic mail retrieval, send your message to itudoc@itu.ch
with no subject and the following message body:
START
GET ITU-1900
END
7.3. The EDI X12 standards are quite complex. How do we decide what
X12 transactions to implement and how ?
There are a number of generic implementation conventions (ICs) or
guidelines; most ICs are prepared on an industry-by-industry basis.
Be sure that both you and your current trading partners are working
from the same set. The Federal Electronic Commerce for Acquisition
Program Management Office has been promoting the 3040 version
throughout the government and the private sector. Older versions may
be used in accordance with the ASC X12 rules. Certain ICs are
published by the Data Interchange Standards Association (DISA);
contact DISA at the address above for information about ICs for your
applications. Certain ICs as well as the X12 standards may be
obtained through:
Washington Publishing Company
c/o EDI Support Services
P.O. Box 203
Chardon, OH 44024-0203
US Phone (800) 334-4912
Non-US Phone (216) 974-7650
Fax (216) 974-7655
7.4. What Implementation Conventions (ICs) are available over the
Internet ?
The US. Federal Implementation Guidelines for Electronic Commerce for
Acquisition are available for free via FTP at ds.internic.net. These
cover X12 transaction sets 810, 820, 824, 836, 838, 840, 843, 850,
855, 864, and 997. The path is pub/ecat.library/fed.ic/xxx where xxx
can be acrobat.pdf, postscript or ascii file formats.
ftp://ds.internic.net/pub/ecat.library/fed.ic/
The SPEEDE/ExPRESS Project, funded by the National Center for
Education Statistics of the U.S. Dept. of Ed., publishes an
Implementation Guide for X12 transaction sets 130, 131, 146, 147, and
997. The July 1994 versions (each in WordPerfect and in Postscript)
may be retrieved by anonymous FTP at admissions.carleton.ca. The
WordPerfect 5.1 files are found in /pub/wp_speede_2 while the
Postscript files are found in /pub/ps_guide_2.
ftp://admissions.carleton.ca/pub/wp_speede_2/
ftp://admissions.carleton.ca/pub/psguide_2/
Complete directions for retrieving these files can be found in the
AACRAO gopher at AACRAO-DEC.NCHE.EDU. Choose the SPEEDE/ ExPRESS
menu item, then Publications, and then select a version of the
Implementation Guide. Note that guidelines are sometimes referred to
by the release/version designation (currently 3040).
The Defense Information Systems Agency (DISA) Center for Standards is
the designated configuration manager for DoD Electronic
Commerce/Electronic Data Interchange (EC/EDI) standards. The DoD
EC/EDI Standards repository system, available via anonymous FTP from
ftp.sterling.com in the /edi/DoD-edi/ directory, contains DoD EDI ICs
separated into two categories, User and Test.
ftp://ftp.sterling.com/edi/DoD-edi/
Test conventions are identical to User, except that the condition
designator for all applicable transaction sets, data segments and
data elements used by that convention are designated as Mandatory for
test purposes. Implementation convention files, both user and test
versions, can be downloaded either individually or all together in
compressed self-extracting files. All the implementation files are
available, when decompressed, in both WordPerfect 5.1/5.2 (.WP) file
format and Standard Exchange Format (SEF) test files which are for
use with EDISIM software or any other EDI software that conforms with
the EDISIM .SEF file format.
The /DoD-edi/2003_User & _Test directories contain draft DoD
Implementation Conventions based on ANSI X12 Version 2 Release 3
(2003):
840 Request for Quotation
843 Response to Request for Quotation
850 Purchase Order
997 Functional Acknowledgement
The /DoD-edi/3010_User & _Test directories contain draft DoD
Implementation Conventions based on ANSI X12 Version 3 Release 1
(3010):
810 Invoice:
810 Commercial
810 Progress Payment
810 Public Voucher
840 Request for Quotation
843 Response to Request for Quotation
850 Purchase Order
997 Functional Acknowledgement
Additional 2003 and 3010 based conventions may be added in the near
future. 3010 based conventions will never progress to approved
status but will be used temporarily by various DoD agencies to
implement phase I of the DoD Electronic Commerce (EC)/Electronic Data
Interchange (EDI) in Contracting Report.
The /DoD-edi/3050_User directory contains draft DoD Implementation
Conventions based on ANSI X12 Version 3 Release 5 (3050):
840 Request for Quotation
843 Response to Request for Quotation
850 Purchase Order
855 Purchase Order Acknowledgement
860 Purchase Order Change Request - Buyer Initiated
865 Purchase Order Change Acknowledgement/Request - Seller
Initiated
Note that the ICs in the /DoD-edi/3050_USER directory were developed
as a means to express DOD requirements for an ANSI X12 3050 based
transaction set. They are not approved for implementation. They
have been submitted to the Federal IC configuration management
process for adoption throughout the federal government. Since they
are subject to Federal review and are based upon a standard not yet
released, changes can be anticipated. (See ECA PMO above)
7.5 How can a trading partner keep up with all these implementation
conventions (ICs) and revisions in X12 and EDIFACT?
The US government is trying to standardize electronic communications
internally and with it's 300,000 plus suppliers. This requires
standardization of the standards process and cross communication
between programs. The IMPDEF message and the NIST Federal IC
Registry will place electronic versions of all its ICs on the
Registry - both full federal ICs and individual agency ICs - so that
any trading partner can download and use them. In combination with
message data compliance checking as well, smaller firms should be
able to get into EDI and start benefitting both themselves and the
government.
7.6. Where can I get information on EDI translation software ?
Several commercial trade magazines publish periodic guides to EDI
translation software. Under commission by the US Government, the
Logistics Management Institute (LMI) of McLean, Va. published "A
Guide to EDI Translation Software, 1994 Edition." The guide
describes the features and characteristics of EDI software offered by
more than 60 vendors. Commercial organizations can get copies for
$20 each by sending a check made out to the Logistics Management
nstitute. Federal agencies may have up to five free copies by
sending requests to
Logistics Management Institute
Attn. Library
2000 Corporate Ridge
McLean, Virginia, 22102-7805
You can fax a typed request to the LMI library at (703) 917-7597 or
send a request to library@lmi.org. Requests for hard copies of the
Guide must include the requester's name, organization, address,
telephone number, and number of copies desired. All requests should
cite Report IR421RD1. If you have questions about the Guide, you can
contact the author, Harold Frohman, at (703) 917-7286 or send him an
Internet message at hfrohman@lmi.org. A somewhat older LMI report
(1992), but still quite relevant, is EDI Planning and Implementation
Guide (DL204RD1, August 1992).
7.7. How do I keep in touch with others pursuing EDI and Electronic
Commerce on the Internet ?
There are several EDI related mailing lists on (and off) the
Internet. Information on subscription follows below.
----------------------
IETF-EDI Mailing list:
----------------------
The IETF-EDI list has been established as a forum for discussing
methods of operating EDI transactions over the Internet, and for
discussing specifications which permit such operation. This list
is therefore focused on the technology of Internet usage of EDI,
rather than on more general aspects of EDI technology or use.
To subscribe, send an e-mail message to:
LISTSERV@BYU.EDU.
The text of the message should only contain the following:
sub ietf-edi <your-name>
Messages intended for the ietf-edi list should be sent to:
IETF-EDI@BYU.EDU.
-------------------
EDI-L Mailing list:
-------------------
The EDI-L list is target towards more general EDI discussions.
The edi-l mailing list is also gatewayed to the USENET newsgroup
bit.listserv.edi-l.
To subscribe, send an e-mail message to:
listserv@uccvma.ucop.edu
The text of the message should only contain the following:
subscribe edi-l <your-name>
Messages intended for the edi-l list should be sent to:
EDI-l@uccvma.ucop.edu
---------------------
EDI-NEW Mailing list:
---------------------
This list complements ietf-edi in the sense that it promotes
discussion of new approaches to edi and the extension of edi
beyond its traditional domains.
To subscribe, send an e-mail message to:
edi-new-request@tegsun.harvard.edu
The text of the message should only contain the following:
subscribe edi-new <your-name>
Messages intended for the edi-new list should be sent to:
edi-new@tegsun.harvard.edu
----------------------
SPEEDE-L Mailing list:
----------------------
The main purpose of this list is for discussions of Educational
EDI Standards.
To subscribe, send an e-mail message to:
listserv@vtvm1.cc.vt.edu
The text of the message should only contain the following:
SUBSCRIBE SPEEDE-L firstname lastname
Messages intended for the speede-l list should be sent to:
speede-l@vtvm1.cc.vt.edu
----------------------
OPEN-EDI Mailing list:
----------------------
The main purpose of this list is for UN/EDIFACT users to review
the work of JTC1/SC30.
To subscribe, send an e-mail message to:
majordomo@utu.premenos.com
The text of the message should only contain the following:
subscribe open-edi
Messages intended for the open-edi list should be sent to:
OPEN-EDI@utu.premenos.com
------------------
ECAT Mailing list:
------------------
The Federal Electronic Commerce for Acquisition Team (ECAT) has
established an open mail list for those interested in ECAT
activities.
Information sent to the forum address is automatically distributed
to all forum members. This forum is available 24 hours a day, 7
days a week. Currently, only ASCII text messages up to 250kb are
supported. For best results when sending messages to this forum,
each line should be limited 70 characters followed by a carriage
return. Also, your name and email address should be included in
the body of messages sent.
To subscribe, send an e-mail message to:
listserv@forums.fed.gov
The text of the message should only contain the following:
subscribe ecat firstname lastname
Messages intended for the ECAT list should be sent to:
ECAT@forums.fed.gov.
7.8. Can I get messages that have been previously posted to the EDI
mailing lists ?
Yes. Messages that have appeared on the ecat, edi-l, edi-new, fed-
reg, x12c-impdef and ietf-edi list are available via FTP from
ftp://ftp.sterling.com/edi/lists/
7.9. I have EDI related material I'd like to make available to the
Internet community. How do I do that ?
If you have an existing Internet connected site, you can make the
information available via FTP or WWW. If you do not wish to go to
the effort, send mail to Kent Landfield at
edi-archive@sterling.com
Sterling Software is making the archive publicly available to the
community. Anyone who wants to distribute EDI related documents may
contact Sterling to make your documents publicly available on
ftp.sterling.com. For example, the Department of Veterans Affairs
has posted numerous studies and training materials on EDI which are
available to the public at ftp.sterling.com/edi/va/.
7.10. Where are EDI Archives on the Internet ?
Some have been discussed previously while others have not. Here is a
very incomplete list of sites that archive EDI related material and
make that information publicly available.
o ftp://admissions.carleton.ca/pub/
o ftp://ds.internic.net/ietf/edi/
o ftp://ds.internic.net/pub/ecat.library/
o ftp://ftp.sterling.com/edi/
o ftp://ftp.swin.edu.au/pub/edi/
o ftp://prospero.isi.edu/pub/papers/security/
o ftp://turiel.cs.mu.oz.au/pub/edi/
o http://snad.ncsl.nist.gov/dartg/edi/fededi.html
o http://waltz.ncsl.nist.gov/ECIF/ecif.html
o http://www.disa.org/
o http://www.acq.osd.mil/ec/
o http://www.ietf.cnri.reston.va.us/
o http://www.premenos.com/standards/EDIStandards.html
8. Security Considerations
8.1. What security measures are needed to connect to the Internet ?
Internet security measures can be placed in two broad categories:
protecting your system from intruders and protecting the content and
integrity of your messages. With respect to the latter, EC/EDI
transactions of nominal value and sensitivity do not require special
security requirements. However, if the information has any sensitive
aspects, you will need to take measures discussed below. Competitors
might intercept your bids and undercut your proposal. Or they could
monitor your purchases and shipping notices to determine your firm's
production capacity. To ensure confidentiality of the message, your
e-mail system should offer some means of encrypting the message in a
manner only the intended recipient can read. Trading partners are
responsible for satisfying existing rules and regulations relating to
computer security and privacy. For example, bid data received by
government systems is subject to the appropriate controls. Trading
partner financial account data is likewise subject to disclosure
restrictions. To thwart those who might tamper with a message to
divert delivery by changing the "ship-to" address, digital signatures
can attest to the integrity of the message. Digital signatures can
also authenticate messages, preventing pranksters or rivals from
submitting false orders.
8.2. How do we go about protecting our system ?
The weakest link in most systems are people and passwords; your
current practices for managing both will apply to use of the
Internet. Steps you can take include:
o Obtain, study, implement, and enforce the NIST FIPS (112) on
passwords. Make the practice of safe computing a condition of
continued employment and let your staff know it.
o Conduct a risk assessment as described in Appendix M of the
Federal Electronic Commerce for Acquisition Team report
Streamlining Procurement Through Electronic Commerce. This
documents is available via ftp at ds.internic.net in the
directory /pub/ecat.library.
o Apply the recommendations from NIST Special Publication 800-9,
Good Security Practices for Electronic Commerce, Including
Electronic Data Interchange as appropriate.
o Establish necessary internal and external "Firewalls." See
John Wack and Lisa Carnahan, "Keeping Your Site Comfortably
Secure: An Introduction to Internet Firewalls," NIST Special
Publication 800-10, undated.
o Review RFC1281[4] Guidelines for the Secure Operation of
the Internet and RFC1244 Holbrook and Reynolds "Site Security
Handbook"
o Review Cheswick and Bellovin's "Firewalls and Internet
Security - Repelling the Wily Hacker," Addison-Wesley [5]
o Consider implementing active countermeasures in your firewalls.
See "There Be Dragons" by S. Bellovin, Proceedings of the Third
Usenix UNIX Security Symposium, September 1992[6]. You can
contact Bellovin at smb@ulysses.att.com.
8.3. Is there good publicly available software I can use?
These are several free, publicly available, security tools one can
obtain via ftp from one of many good archives. If your company uses
UNIX systems to connect to the Internet or has UNIX systems connected
to the Internet get and use the following tools:
1. The Purdue University COAST - Security Archive (Computer
Operations, Audit, and Security Tools, run by Gene Spafford)
is located at coast.cs.purdue.edu and mirrored in a few places,
including ftp.sterling.com.
2. COPS available from ftp.cert.org in /pub/tools
3. TIGER available from net.tamu.edu in pub/
These tools are a series of scripts and programs that will alert you
to many well-know problems and holes in UNIX systems and how to fix
them.
The Computer Emergency Response Team (CERT) at Carnegie Mellon
University can assist with computer break-ins as well as provide
notices of security activity on the Internet. The US Department of
Energy's Computer Incident Advisory Capability (CIAC), located at
Lawrence Livermore National Laboratory, can provide assistance at
ciac@llnl.gov or at 510-422-8193. CIAC offers software and documents
on their anonymous ftp server at ciac.llnl.gov. Both CERT and CIAC
are members of the Forum of Incident Response and Security Teams
(FIRST), a global organization to foster cooperation and coordination
among computer security teams worldwide.
8.4. How good are electronic or digital signatures ? Can they be used
in court ?
Properly used, these signature systems are better than existing paper
based authentication and forgery detection technology. You will find
a clear and concise description of how these signatures work in Gary
Ratterree's RIPEM Beginner's Guide; contact Ratterree at
grayr@cs.tamu.edu. Other references include:
ftp://ftp.tis.com/pub/PEM/ for Privacy Enhanced Mail
ftp://ftp.rsa.com/ for PEM
ftp net-dist.mit.edu:/pub/PGP for Pretty Good Privacy
(PGP)
An "infrastructure" for public keys is not required to use public key
encryption or digital signatures. In the absence of such an
infrastructure, the encryption protocol and the public keys would
need to be exchanged bilaterally, such as part of the trading partner
agreement. A public key infrastructure would provide a secure means
to obtain a public key without a need for a manual key exchange.
But digital techniques will become more convenient with the arrival
of additional infrastructure and support systems. The US government
is taking steps to ensure the admissibility in court of such systems.
We anticipate that the necessary regulatory and legal infrastructure
will be in place about the same time as the necessary directory and
certificate services and other supporting systems come on-line. We
expect to see expansion of several government pilot programs in the
later half of 1994. NIST recently published a report on the Public
Key Infrastructure (PKI) and related policy issues; for information
contact the NIST Computer Security Division at 301-975-2934.
8.5. Are there other US government standards publications I should
be aware of?
Yes. Here is a sample of those you will often hear mentioned.
1. Federal Information Processing Standard (FIPS) Publication
46-1, Data Encryption Standard, January 1988.
2. FIPS Publication 65, Guideline for Automated Data Processing
Risk Analysis, August 1979.
3. FIPS Publication 113, Computer Data Authentication, May 1985.
4. FIPS Publication 180, Secure Hash Standard - (SHS), May 1993.
5. FIPS Publication 186, Digital Signature Standard - (DSS),
May 1994.
6. NIST Special Publication 800-9, Good Security Practices for
Electronic Commerce Including Electronic Data Interchange,
December 1993.
The FIPS standards may be ordered from the
U.S. Department of Commerce
National Technical Information Service
Springfield, VA 22161.
9. References
[1] UN/EDIFACT (Electronic Data Interchange for Administration,
Commerce and Transport) Syntax Rules (ISO 9735), March 1993,
United Nations Economic Commission for Europe (UN/ECE), Working
Party for the Facilitation of International Trade Procedures
(WP.4)
[2] FIPS Publication 161-1, Electronic Data Interchange (EDI),
National Institute of Standards and Technology, April 1993.
[3] The Internet Message: Closing the book with electronic mail,
Marshal T. Rose., Prentice Hall, Englewood Cliffs, New Jersey,
1993.
[4] Pethia, R., Crocker, S., and B. Fraser, "Guidelines for the
Secure Operation of the Internet", RFC1281, Software
Engineering Institute, Trusted Information Systems, Inc.,
Software Engineering Institute, November 1991
[5] Firewalls and Internet Security - Repelling the Wily Hacker,
by Cheswick and Bellovin, Addison-Wesley, 1994,
ISBN 0-201-63357-4
[6] There Be Dragons, S. Bellovin, Proceedings of the Third
Usenix UNIX Security Symposium, Baltimore, Maryland, September
1992. USENIX Association, ISBN 1-880446-46-4
10. Credits
James A.(Artch) Griffin <artch@AGRIFFIN.CPCUG.ORG> is credited with
co-authorship as he prepared the ECAT FAQ which I used (or perhaps
abused) as the base document. Artch was judicious and patient as he
watched his original text being rewritten over and over.
Carl Hage contributed detailed explanations and clarifications of the
various Internet protocols and services and how EDI can employ them.
I would like to thank the following people for their comments and
specific contributions: Kent Landfield, Mike Bauer, Kit Lueder, Eric
Christ, Betsy Bainbridge, Bob Lyons, Kirby Spencer, Sally Hambridge,
Ed Levinson, Warren Smith, Steve Bass, Jerry Johnson, Randy
VandenBrink, John Pillay, Jim W.C. Smith, Mark Charles, Jean-
Philippe Favreau. I apologize if I omitted any one of the many folks
who responded to my many calls for comments.
I greatly appreciate Kent Landfield for his editorial assistance
during final preparation of this document. Sterling Software
graciously hosted the work in progress for ftp access and review,
saving many bits of Internet SMTP traffic.
Finally, I am grateful for the patient cooperation of the IETF
Working Group and the participants of the IETF-EDI and EDI-L lists.
It's a nice cyberplace to work!
WRH, Washington, DC.
11. Authors' Addresses
Walter Houser
Department of Veterans Affairs
810 Vermont Avenue
Washington DC, 20240
Phone: 202-786-9572
EMail: houser.walt@forum.va.gov
houser@cpcug.org
http://www.va.gov/
James A. (Artch) Griffin
President, Athena Associates
18924 High Point Drive
Gaithersburg, Maryland 20879
Phone: 301-972-2502
EMail: agriffin@cpcug.org
Carl Hage
C. Hage Associates
1180 Reed Ave #51
Sunnyvale, CA 94086