CA2181597A1

CA2181597A1 - Method and system for providing secure edi over an open net work

Info

Publication number: CA2181597A1
Application number: CA002181597A
Authority: CA
Inventors: Emmanuel K. Pasetes, Jr.; Lew Jenkins
Original assignee: Emmanuel K. Pasetes, Jr.; Premenos Corp.; Lew Jenkins
Current assignee: Premenos Corp
Priority date: 1995-07-19
Filing date: 1996-07-18
Publication date: 1997-01-20
Also published as: GB9614931D0; NL1003644C2; US5812669A; GB2303525A; IT1283473B1; JPH09162860A; NL1003644A1; ITMI961519A1; ITMI961519A0; AU6058696A; DE19629192A1; FR2737067A1

Abstract

A method and system for selectively interconnecting a plurality of computers (112,114) over an open public network (120,102,122), such as the INTERNET, provides a private secure computer exchange of EDI interchange communications between a sender computer (112) and a recipient computer (114), each of which has an associated public key and an associated private key, such as in an RSA type cryptographic communication system (100).
The associated EDI acknowledgement message, such as the AUTACK, is used to provide secure authentication and non-repudiation of both origin and receipt of the secure private EDI interchange communications transmitted over the open public network (120,102,122) with the AUTACK transmitted from the sender computer (112) being digitally signed with the sender's private key, and with the reply AUTACK transmitted from the recipient computer (114) being digitally signed with the recipient's private key. The respective digitally signed AUTACKs are decrypted after receipt by using the public key associated with the private key used to provide the digital signature. The transmitted AUTACK from the sender computer (112) includes an MD5 for the entire EDI interchange as well as an MD5 of the AUTACK, with the AUTACK, thus, being used to provide the digital signature. The reply AUTACK from the recipient computer (114) includes an MD5 of the reply AUTACK. The ability to conduct business over the network (120,102,122) is controlled by private trading partner agreement communications which provide key certification.

Description

-218~597 BACKGROUND QF THE INV~TI~N
Field Qf the Inven~ion The present invention relates to methods and systems for providing secure EDI over an open system network, such as the INTEP~NET, and particularly to an improved method and system for providing a secure EDI mailer over an open network which employs an RSA type public/private key encryption scheme in order to deliver secure authentication, and non-repudiation of both origin and receipt.
Public/private key secure communication systems over an open network are well known, such as described in United States Patent Nos. 4,578,531; 4,471,164; 5,268,962; 5rl42r577i 4,893,338; 5,222,140; 5,261,002; 5,073,934; 5,303,303; 5,297,208;
5,369,705; 5,351,293; 5,375,169; 5,224,166; 5,253,294; and 5,237,611. The RSA public/private key encryption scheme, is a well-known public key system for providing secure messageS over .
an open network, such as the lN'l'~;~N~'l', and is described in various issued United States patents, such as United Sates Patent Nos. 4,405,829; 4,424,414; 4,200,770; 4,218,582; 5,073,935; and 4,723,284, the contents of which are incorporated by reference herein. In addition, the concept of non-repudiation of origin is known, such as described in United States Patent Nos. 5,226,709;
and 5,367,573; as well as such systems in which digital signatures are employed in public/private key systems, such a8 described in United States Patent Nos. 5,311,591; 5,214,702;
5,337,360; 4,868,877; 5,001,752; 5,005,200; 5,136,643; 5,018,196;
4,885,777- 4,267,782; 5,351,302; 5,208,858; 5,299,263; 5,142,578;
4,987,593; 4,991,210; 5,339,361; 5,373,558; 4,625,076; and the Entrust system marketed by Northern Telecom. Furthermore, various other secure transmis6ion systems have been developed over the years in an attempt to try to provide secure business communications over public or private networks, such as described =~
in United States Patent Nos. 5,369,702; 4,876,716; 5,199,074;
4,823,388; 5,268,962; 5,022,080; 5,136,646; and 5,204,961. Also, the use of electronïc data or document interchange or EDI to transmit business communications from peer to peer is known in the art, such as described, by way of example, in United States Patent No. 5, 202, 977 owned by the assignee herein, or in previously mentioned United States Patent No. 5,337,360.
However, applicants are not aware of any successful prior art . ~
attempts to use the lN'l'~ N~;'l', or any other widely accessible open network, such as telephone lines or any TCP/IP systemj in which a secure public key/private key system, such as RSA, has been successfully combined with EDI to provide authentication and non-repudiation of both origin and receipt in a secure peer-to-peer =
private transaction which can occur at any time over the open network without requiring password management, while also providing verification of message integrity. Such a system eliminates the need for private valve-added networks and other third party private networks as well as ensuring the commercial feasibili~y of a private peer-to-peer business transaction over a widely available open network using EDI. The certainty of non-repudiation and authentication eliminates the ability of either party to deny that the transaction was approved and eliminates doubt as to the contents of the EDI document giving rise to the transaction. The ability of the method and system of the present invention to provide a secure EDI mailer in combination with an RSA type public/private key system overcomes the disadvantages of the prior art.
SUMMARY OF THE INVENTION
The method and system of the present invention comprises using the AUTACK or EDI acknowledgement message as a _ document to provide the digital signature in a public/private key system in which the AUTACK is signed by an encrypted hash code 2~81~97 from the EDI interchange communication which has been encrypted with the sender' s private key, such as in an RSA type public/private key 9ystem, and is an improvement on such systems.
Because the AUTACK or functional acknowledgement is sealed with the private key of the sender of the functional acknowledgement, the recipient of the original message, when the original sender decrypts the reply AUTACK message with the recipient ' s public key, he is assured that the intended recipient actually sent the reply AUTACK or acknowledgement and of the integrity of the receipt due to the correct hash code being detected.
The EDI AUTACK message, such as the EDIFACT AUTACK
message, a generic international standard of EDI for administration, commerce and trade, is preferably used to deliver the desired secure authentication, non-repudiation of origin or receipt, and acknowledgement or denial of acknowledgement for one or more EDI envelopes, such as the X.12 or EDIFACT envelopes, by way of example. In the presently preferred method and system of the present invention, in the process of authentication and non-repudiation of origin, the sender computes a desired hush or message digest from the EDI, such as the MD5 for the entire interchange communication, and inserts the value in the AUTACK
message. The sender then preferably computes the MD5 (message digest version 5) of the AUTACK message and digitally signs the AUTACK by encrypting the computed MD5 with the sender' s private ` 21815~7 --key, and inserts this value in the AUTACK message~ Thus, the AUTACK, or EDI acknowledgement message, is preferably used to provide the signature . The recipient, af ter receipt of the message, then decrypts the EDI interchange communication, if it is encrypted, and computer the MD5 of the received EDI
interchange communication. If non-repudiation of origin is desired, the recipient then decrypts the AUTACK message with the sender' public key. The value obtained by this decryption in this example is the MD5 of the AUTACK message. The MDS of the AUTACK message is then computed and compared with the decrypted value . ~ f both values are e~ual, the integrity of the AUTACK is verif ied and non-repudiation of origin is established . The MD5 of the EDI interchange communication is then compared with the MD5 of the EDI interchange which had been inserted in the AUTACK
and if the two are e~lual, then the integrity of the EDI
interchange is verified, and non-repudiation of origin is established .
In order to then establish non-repudiation of receipt, after verifying the integrity and authenticity of the EDI
interchange communication received in the manner described above, a new or reply AUTACK is created by populating all segments and elements as appropriate, the computed MD5 is digitally signed with the receiver' s private key, the digitally signed MD5 is inserted into the reply AUTACK, appropriate segments of the reply .

AUTACK are populated, and the prepared reply AUTACK is transmitted to the sender. The original sender, upor~ receiving this reply AUTACK, then verifies the digital 6ignature from the recipient of his original message by decrypting it with the receiver' s public key. The value obtained by this decryption is the MD5 of the received reply AUTACK. The original sender, who has received the reply AUTACK from the recipient of his message, then computes the MD5 of the received reply AUTACK and if the computed MD5 is equal to the decrypted MD5, the integrity of the AUTACK is preserved and non-repudiation of origin of the AUTACK
is establ ished. Moreover, if the MD5 contained in the particular segment of the AUTACK received where it has been inserted by the sender is equal to the MD5 of the EDI interchange previously transmitted and the acknowledgement is positive, which can be inferred by testing the security code in the AUTACK message, then the following are implicit to establish non-repudiation of receipt: the EDI interchange communication in question is known to both sender and receiver because the MD5 of the EDI
interchange communication and the interchange number are =~
contained in the AUTACK message and have been duly recognized, the integrity and authenticity of the EDI interchange communication upon receipt hae been verif ied, and the receiver does not deny having received the EDI interchange communication in question.

` ~ 2181~97 ~
The ability to trade or conduct business on a peer-to-peer basis over an open public network, such as the INTERNET, without the need for . password management may be controlled, to the extent de5ired, by the trading participants through the use of trading partner agreements to provide key exchange certification, or by reliance on a certificate authority which issues and verifies public/private key paths. Thus, private and secure transactions, subject to authentication and non-repudiation of both oriyin and receipt, along with verificationof message integrity, using EDI, may be conducted oYer an open communication network.
BRIEF DESCRIPTIO~ OF TF~F I~RAWIN(~S . . -FIG. 1 is a functional flow diagram of the presently preferred method and system of the present invention for providing secure EDI over an open network, such as the INTERNET, in order to provide, integrity, authentication, non-repudiation of origin and recipient, and confidentiality using EDI;
FIG. 2 is a functional flow diagram of the portion of the method and system of FIG. 1 which provides authentication and non-repudiation of origin using the EDIP~CT AUTACK message;
FIG. 3 is a functional flow diagram, similar to FIG. 2, of the portiop of the method and system of FIG. 1 which provides on-repudiation of recipient us ng ~he ~DI~AC~ A~ CK mes~ie .
.FIG. 4 is a functional flow diagram of the receipt of secure mail over the INTEKNET in accordance with the presently preferred method and system of the present invention;
FIG. 5 is a functional flow diagram, similar to FIG. 4, of the sending of secure mail over the lN'L'~KN~:'l' in accordance with the presently preferred method and system of the present invent ion;
FIG . 6 is a functional f low diagram, similar to FIG . 4, of trading partner management in accordance with the presently preferred method and system of the present invention;
FIG. 7 is a functional flow diagram, similar to FIG. 4, of audit log management in accordance with the presently preferred method and system of the present invention;
FIG. 8 is a functional flow diagram, similar to FIG. 4, of tracking management in accordance with the presently preferred method and system of the present invention;
FIG. 9 is a functional flow diagram, similar to fig. 4, of job monitoring in accordance with the presently preferred .:
method and system of the present invention;
FIG. 10 is a functional diagram of the organization of the system employed in carrying out the presently preferred method of the present invention;
FIGS. 11-13 comprise a functional flow diagram, similar to FIG. 4, of the overall presently preferred method and system ~3 -2~8i~97 1~
of FIGS~ 1-10, with FIG. 11 illustrating certificate verification, FIG. 12 illustrating TPA processing, and FIG. 13 illustrating public key/private key processing;
PIG. 14 is a diagrammatic illustration of a typical .=
computer screen display in accordance with the presently preferred method and system of the present invention, illustrating the various functional options to be controlled by the users to en9ure secure mail over the INTERNET in accordance ~=
with the presently preferred method and system of the present invention .
FIGS. 15-21 are diagrammatic illustrations, similar to FIG. 14, of typical computer screen displays in accordance with the TRADING PARTNERS PROFII,E option in the screen display of FIG.

1~;
FIGS. 22-28 are diagrammatic illustrations, similar to FIG. 14, of typical c~mputer screen displays in accordance with the TRADING PARTNER AGREEMENTS option in the screen display of FIG. 14, with FIG. 28 illustrating the OUTBOUND RETRANSMISSION
screen display for sending secure E-mail in accordance with the presently preferred method and system of the present invention;
FIGS~ 29-33 are diagrammatic illustrations, similar to FIG. 14, of typical computer screen displays in accordance with the KEY ~NAGEMENT option in the screen display of FIG. 14; and _ 9 _ 218~597 ~
FIGS. 34-41 are diagrammatic illustrations, similar to FIG. 14, of typical computer screen displays in accoraance with the TRACKING option in the screen display of FIG. 14, with FIGS.
3S-38 illustrating tracking interchanges and FIGS. 39-41 illustrating tracking an audit log.
DETAILED DESCRIPTION OF THE PREFER~?~n ~ BODIMENT
Referring now to the drawings in detail, and initially to FIG. 1, a functional flow diagram of the presently preferred system 100 of the present invention for providing secure EDI over a conventional open network, such as the commercially available INTERNET 102, is shown. The preferred method and system of the present invention is implemented in a system which i9 provided under the trademark TEMPLAR owned by the assignee herein. As will be explained in greater detail hereinafter, with reference to FIGS. 2-41, the presently preferred method and system of the present invention provides integrity, authentication, non-repudiation of both origin and receipt, and confidentiality using EDI. This is preferably accomplished by using the AUTACK or EDI
(Electronic Data Interchange) acknowledgement message as a document to provide a digital signature in a public/private key system, which is preferably one employing the conventional RSA
public/private key encryption scheme, such as the encryption scheme described in United States Patent Nos.4,405,828;
4,424,414; 4,200,770; and 4,218,582, the contents of which are 218~5~7 ~
incorporated by reference herein in their entirety. As will be described in greater Getail hereinafter, the AUTACK is preferably sealed or signed with a digital signature which is preferably created by encrypting the MD5 ~message digest version 5) of the AUTACK with the originator of the AUTACK' s private key, such as the private key of the sender in the preferred process of authentication and non-repudiation of origin illustrated in FIG.
2, or with the private key of the recipient in the preferred process of non-repudiation of receipt illustrated in FIG. 3. The digital signature is then preferably inserted into a predetermined position in the AUTACK and transmitted to the other party to the transaction. Because the AUTACK is sealed with the private key of the se~.der of the AUTACK, when the receiver of that AUTACK decrypts the AUTACK with the public key of the sender of that AUTACK, he is assured that the intended recipient of his message actually sent that AUTACK, as well as being assured of the integrity of the receipt due to the correct hash code being detected in the manner to be described hereinaf ter . In accordance with the present invention, the encrypted secret key used to encrypt the message, as well as the message ityself, are contained in the PKCS message.
The MD5 is a .conventional value which can be obtained in an EDI message by conventionally hashing a quantity, such as an EDI interchange. There is a very low probability that the MD5 21~1597 .
of any two different documents will be the same and, accordingly, the MD5 is preferably used to establish the integrity of EDI
interchanges in accordance with the presently preferred method of the present invention.
As is well known by users of EDI, an AUTACK message is an ~lN/EDIFACT standard for authentication and acknowledgement. In accordance with the presently preferred method and system of the present invention, the AUTACK preferably consists of the USH or security header, USB, USX to identify the message, USY to hold security information on the referred message, USR, and a few other conventional segments normally found in an AUTACK.
Preferably, information such as response type, scope of security application, and security function are coded in the USH segment.
By way of example, the second element of the USH segment may preferably contain the value 2, or some other designated value, if the AUTACK were to serve as a document verifying non-repudiation of origin with, for example, the fifth field having the value 2, or some other designated value, if an acknowledgement were required~ The USX segment preferably contains the interchange number of the EDI interchange in question, thereby linking the referred message to the AUTACK, and the USR segment preferably is a security result holder and contains the digitally signed MD5 of the AUTACK in accordance with the present invention.

. ~
A~ further 6hown and preferred in Fig. 1, assuming only a two party business transaction between two parties who have entered into a trading partner agreement, each of the parties has a conventional computer workstation 104, 106, such as a RS/6000, HP/9000 and a SOLARIS; a conventional EDI
translator 108, 110; a conventional integrated software/hardware server 112, 114 which has been programmed to operate in accordance with the preferred method and system of the present invention, and which includes conventional 10 computer di6play terminals 116, 118, capable of operating in a Microsoft WINDOWS or UNIX X-WINDOWS type environment, for displaying me6sages and choices in accordance with the preferred method of the present invention as well as messages and documents transmitted via EDI over the INTERNET network 102 in carrying out the method of the present invention, with the servers 112, 114 being capable of providing the desired authentication, integrity, non-repudiation of origin and receipt, and confidentiality in accordance with the present invention . As shown and pref erred, the servers 112, 114 20 conventionally communicate over the open network, such as the INTERNET 102, through a heterogeneous mail environment 120, 122, such as one employing SMPT/MIME, X400/X435, LOTUS
NOTES/cc:MAIL, and/or MICROSOFT MAIL/EXCHANGE. The server 112, 114 are preferably conventional computers, which have been //

` 2181597 ' ` ~
conventionally programmed in C++, to carry out the presently preferred method of the present invention, and are preferably targeted to run- on on one of the following UNIX platforms: AIX, HPUX, SUN OS, or SOLARIS.
Enumerated below in TABLE A are the various scripts which may be readily used by a programmer of ordinary skill in the art to create the nece$sary programming in C++, which is an object oriented programming language, to run on the servers 112, 114 to carry out the presently preferred method of the present invention. As will be noted, the various scripts relate to sending an EDI document, re- sending an EDI document, receiving a valid EDI document, receiving an acknowledgement AUTACK, receiving a trading partner' s new public key, distributiny your new public key to related trading partners, activating the certificate management main menu, creating your own private/public key pair, changing a certif icate (your own public/private key pair), removing your own private/public key pair, copying your own public key to disk file, printing your own public key certificate, saving your own private/public key to disk file, restoring your own private/public key from disk file to replace the existing private/public key, restoring your own private/public key from disk file to a new key, activating the trading partner public key management main menu, adding a trading partner public key, changing the trading trading partner public 2 ~ 8 ~ 597 ~
key, removing the trading partner public key, copying the trading partner public key from disk file to replace the existing trading partner public key, copying the trading partner public key from disk f ile to a new key . activating the trading partner agreement management main menu, adding trading partner agreement, changing the trading partner agreement, removing the trading partner : =
agreement, copying the trading partner agreement to disk file, copying the trading partner agreement from disk file, MIME
packaging (conventional MIME mailer), MIME unpackaging, PKCS
packaging (conventional PKCS~, PKCS unpackaging, working with the tracking record, monitoring server jobs, receiving an invalid ED
document with an integrity problem, receiving an AUTACK with an integrity problem, receiving unsupported mail, receiving an EDI
interchange without AUTACK while non-repudiation of origin is expected, and receiving an unexpected AUTACK.
TABLE A

, 2',8~597 , Scripts Send an EDI ~ocument Ini~ialor Action ParticiDant EDI transla~or Reouest lo scnd nn EDI bjllch aQen~
~-- h~-n~ir7tinn Qgent Gcl sendcr ;md rccciYcr ID EDI inl~rchangc enYeloD
ar~ent Crc~lc a tr;~cl;ine rccord traci;inR record a.. ~h n~irn~inn aRent Crca~c an evenl bcRin lR cn~rY audit IOR
7~h~n~ir~tinn agcnt Rcquest di6est alcul;ltion method and tr3ding Lrading p~rtn~r prlnner s des~ina~ion rlddrcss source addrcss. agreemen~
me~hod of non-rcpudi~ion of rcceipl (i~RR) non-rcpudi~ion of origin (Ni~0) rr~nr i n~ y and tr~llst r ~u~hen~ic~tion aecnt ~et i-en~irlc~ion diRcs~ EDI in~erchan~e EDI in~erchanec c~ i-cn~itica~ion dieest m~hod conh~ur~ion EDI in~erchanee _;]lcu ~e diRes~ of ~hc EDI in~rchanRe diccs~ caicul;~or 7l~lh~nlir7linn agent ./~nfy thc conLrol number and iri~n~ r7~inn dicest Iraci;ing list is uniouc 7.. ~h n~ir7~inr aeent Crc~ AUTACK AUTACK
AUTACK Ge~ ~he priYcte i;ey ID Ni~ NR0 inlcgri~y trading par~ner rneci; diQestme~hod ere~men~
A --A- ~ e~ ~h~ priV;IIe l~ey eY dire~orY
A - A_ ct illleen~ dieest .DI in~erchnnee A A . _;~lculale o- n dicest - ieest calculalor A --.A ~ ienlhediRcslofthcAU~rAcK SAF
a--~ l~nlirn~inr aeent re~e AUTACK enYeloD NB enveloD
n~ n~ir7~inn ceent ncrYpt ~he EDI in~erch:mrJc i~CS
71~t~.~nlir7~inn a~ent Combine Ihe EDI inlcrch;~nge and AUrACK inlo ~iilEpaci;ager one i~iiviE encoded m~il body (multiple M ii~E
p;~r~ials a--~h n~ir7~inn aeent Send Ihe encoded in~erch;ince ~o ~r;~dine par~ner selldm;lil 7.. ~h~n~ir7~inn agent Updi~e ~he tr~ci;ing record wi~h send d~e and tr~cl;ing record time loa~ion of ~he mail body sender and receiver lD i~R0 rJnd in~ei ri~y dii~s~ priva~e l;~y ID public i~ v ID i~ ir ~ior die~st ~ulh nlir~inn :IRcnt CrcD~ a mail scnt lR cl~trY audit IOR
au~h~ntica~ion a_~nt Rcturn a succcss re~urn code and tr~ci;ing record ~ ~.n~irn~inn agent ID ~o EDi ~r3nsl;~0r 218~597 ~e-Send an EDI doctlment Ini~iator Aclion P~rticipant re-transmit monilor Reouest Ihe~h,u .. ~ . st~us traCI~inR record re-transmit monitor Request re-transmit action trading partner attreemen~
re- ran -nit monilor : .equcst to re-scnd Ihe EDI in~erchan,ee ~ ul, astentaRent ,equ~st ~he loc;l~ion of ~he mrlil body trackin~ record aRent end ~he encoded in~erch~n~e tû tradinR partner sendmail n agent Jpda(e Ihe tracldng record v/ith re-send date and trrcking record time ~"h~ r-~inn~enl _~c3m~ enl o,~n~ lo,~

. . .

2 1 8 ~ ~97 ~
Receive a valid ~DI docL~ment Ini 3~0r Ac~ion . i~iciD3n~
?~t Y~E D3C.~3tter Inform m3ii 3mv31 i~E DiC.;at'er ~", l~.nr1r-~ir~n 3t'en~ Cre3~e 3 mnil rec-ived suec-st`ullY loe ~n[rY lUUit IOQ
,." ,~ .,~" ;,~,- ngen~ V3iid3~e the receiYed m3il coll~nined 3n tD~ tD[ in~erchnnge in~erch3nee ~J,. ,. r,.~.. 3aent Cre3~e n unciii~e record ~rnci~inst fecord 3t'enc Get 5~nder ~ld r~ceiY~r t3 ~3[ in~rchnng~
env~lOD
"",ng~n~ Gettr~ding?3rrnerngreementwjthsend~r~nd tradinspnrrn~r rec~iver iD 3ereem~nt .... h. 1~ .. 3g~nt G~t ~he dig-st ot the interch3ng~ ~snd signed AtlTACC
die~s~. -nd disest c31cul3~ion merhod AU ~'ACt Get Lh~ public i;~y tD uading pnrtn~r t~re-ment AtiT,~C.i iet ~he Dublic i;~Y o ` ~he tf3din-~ D3nner ;eY direcwrY
~eY direc;orJ .e~d Ihe 13~CSt efftAC Y~ DUbliC i~CY ~Y direc~orY
At~TAC.t CC YDt ~hC sitned - Q~S~ Sf~fr , jr;~ A 3Q~nt IICUlY~c ditlest ot ~ 3[ interch311tte ~r interch3nae eent ~omDlre~hcc31cu13teddigest of th~E31 AU-~ACt interch^nee wi~h ~he dig~st in ~he AlJT~C:t verify ~he diaest of L~LC p3rti3i AU LAC{ s3me ^s ~he d- C.-~D e" sit~n d dittest ill ~he AtJ I .~C~
lll,hr ~ni~-~ir n 3eerl~ Ge~ irSr~il r-~ir~n - ittest -Dl in~erc~nult/e 3~ in~er~-nst~ G~ iA~'lnf ~-lir~n ' it~es~ me~hod c3ntiaur~ion E3t in~erc.~nnee ~31culY~e -i~!~s o ~h~ E~ erc.~s3nt!~ dit~estc~lcJln~or ", ." 3gen~ V~rify ~he c3n~rol number md ir~r ~rifi~-rif n digcs~ 3-Ychng iist is uni3ue rh~r;f^~lf n Ir~ent C.~ e 3n _:~1 in~erch3~1 ge rec~ived succ s,usiy :udit log loa en~rY
~g~nt Get ~he non-r~?udi3~ion ot rereipt ~lag u3ding pnrtner If ~re~ncn~
Julhentlc~lon -aent Cre3~e 3n 3c' ~owledY~ AUTAc-.C. cor~rol numbet AuTAC.t .~uTAc~c G~t ~he pnv3~e iiey ID tr3ding p3rtn~r ,3sree.~nent A~ T,AC.t iet ~h~ Drv3~ i;eY ~Y direc~orY
Ai TAC~ ian ~he diYes~ aSAf-r if n na~nt r~3~C 3n Ai TA ~C send r~3ues~ loa en~rv 3udi~ loa n~ if n3yent -n~L~e3nAuT~A-xiy~li~Ee~lcodedn:3ilbody ~YfL~Eonc.Lnaer ~u~ len~ c~~on 3aent ~nd Ihe :rtc3de- A~'AC.rt ~o rr~ydinY D3nner s~ndm3il ~u~ lent c3~ion Jgent Jpd~ he ~QCi; I~g record wi~h Ai~TACAt send rr3c.iing .~ecord d3~ Jnd ~im~. Ioc-~io~l ot ~he m3ii body, sender Jnd re~:ver ID. diaes~ _ Ju~hen(ic3tion 3aent Cre3~e 3n ~[JTfAcK sel~ ~oe ell~rY JUdi~ loa JuLhen~ic3~ioll J,en~ Get inbourld roulillg po~ p-ocessing Jc~ioll ;rding p3nner :are~ment ~ ull 3c~e~ wrj~e Ei~[ d~3 ~o sDeci~ied lile or direc~orY ~"~h~ri~rinn ~eent 3u~hen~c3~10n 3~'en~ E~ccu~e pos~-"roccssi-l~ comm311d (e.~ Yoi;e ~ a~nt EDi ~r:nSl~nr1 2~815q7 .
~eceive an acknowledgementAUTACK t' Ini ia~or Action P -ticiDnnt h~Epac aeer InfonnmnilLtrrivnl h vEDnc;neer .,.,arent GctlistofhilhEbodypilrts M'~EDacaster reent Vniidnte tho receiYed mnil con~rined nn AUTACK A~ TACK nterch~nre .. 1. 1;.~l~",agent GetsenderrndreceierID A~TACK nterchange enyelope rh~n~ir~innagent GctNRRf1ng publicl:eyII) Tradingpanner neerement ~,.(~.. /;.. li.. ,. atent Verify lhe sender s sir!nnture BSAFE
." ngent Gc~ in~rchnl~ge conurol number nnd illLegra~y AUTACK
dir~est Rll~h~n~ir~inn agent Updnte ~L~--o .. ~d~ received d;lte nnd time of the uacl:ing record sent inlerchnnee -F~eceive a tr~ding partner's new public key rni iator Acuon PnrliciDnn~
hiI~E Dac orer Infonm mnil arrivnl hlllUE Dnci~neer n~ir~ rn 3~en~ Ge~ lis~ Or hllhi~ bodY Dnns Mlh[E DncL a~er .. aeent Valida~e Ihe received mri~ conlnined r cenihc~(e cerihcn~e ,-n,ir~r nn 2gen~ Get dis~inguish narne qunliher tnd ID of ~he ceniilcn~e tradine Danner ;. ", a~^nL Ge~ e-mQil ~ddress of ceruficn~e managemen~ s~ff ~y dine ~orv DUbliC keY
~"~-,nrr~onneen~ VerifY~hesienn~ure 3S.~-r ~", l.-n, r~- nn ae-n~ oe cenihc~e ~rrivol audi~ loe , aeen~ re~t~e n rrncl:ine record wilh ~vPe ce.tihc~e uacl~lne record a~ n~ r~ nn rleen~ nform the user the arriv~l of the cenihc tte ~I~lh~n~ inn aeen~
User ~enfy wj~h trnding p;Lnner ~hn~ ~he cenirlcn~e is User correc~
User Sclec~ ~o upd~te the cenihcate from the rl~ci;ing User record ~ Get the cenihcDte . trnc~ ne record Add the cenirlcnte with new serini number l;eY d neCtOrY
Ch3nee the e~Pired d;~e of previous certihcn~e l;ev dnec~orY
Loecenihcn~euPdn~e nudi~ oe ~ Chnnge the st ttus of ~he tr~cl~ing record to ~racl;ing record uPdnted ' ` 218~97 _ Distribute new own public key to related trading partners - i~irllor ~c~ion ~rlicirJan~
ser nYo~c cenir a~e mr~nrJ~emenl bul~on Jser 1 el 3 list of l~ey pQir ~e~ ID y direc~ory ispl3y Ihe list r l;ey p r on screen se~ clectlllecertirc~telo- slribule ser ser nvol:e Ihe distr bution unc~ion ser I Ge~ ~ lis~ of ~r~ ing prlr~ner using IhDt cerliricrlle Ir~ding panner ~ercemen~
Ul Get Ihe c-m~il rlddress of Ihe Ir~dille p;lrtner Ir~dine D:lrtner Ul Displ~y Ihc lisl of r~ding p2rlner Dnd e-mr~il Ul ~ddress ser Sclecl or de-selecl tr dine p~nner scr ser Ch~nee ~hee-m il a-dress ser ser ~dd 2 new e-m~ dress ser er nvol;e Ihe dis~ri -ul on r~rc~ess ser reale Ihe cenir c~e (X.509 or PKCS?) ;ey direclory ncodc Ihe CCrliC~le in MIME rormDI vllME p~cl;aeer end ~hc MIME encode cenirlcrllc sendm3i~
_- _re~le r~ l;ev se~l loe elllrv ~udil loe ZO

2i81597 .
._ Activate certificate managemen~ main menu niliator . ~c~ion nrliciDant Jser lYol;ecertificllemanaeementbu(~on Jser Jl e~ a lis~ of ~:~Y pair - liey ID ey direc~orY
Jl isDlay ~he list of l;ey pa ir on screen Jl Create o wn private/public key pair The Dser needs ~o logon rmd activa~e certirc~e mana~emen~ main menu before ge~ ~o ~his funcLion.
_Ini~io~or Ac~ion P~r~iciD~n~
User Invoi:e creale ~ey p~ir bu~oll User Ul Displ~y a screen ~o accep~ )~ey ID erfecLive da~e Ul i"~ ;~h~ name and e-mail address User Key in ~he l~ey ID erfec~ive da~e llame and e.m~il User ~dress Jl rea~e l;ey D~ir i:eY direc~ory ey ~ ~ rec~ory . e~ lenQ~h of ~he l~eY conrir urrl~ion ~ey ~ nec~ory e~ ~ey Qenera~io~l seed seed -enerrl~or ;ey ~ rec~ory enera~e priv~e Dlld pub1ic l~ey pair BSA E
;eY - n c~orv nsure ~he public l;eY does no~ exis~ I;ey - irec~ory da~ab~se ;ey .rec~orv e~ in~ernal encrYD~ion l~eY con r~ura~ion ;eY -. reC~orY .ncryp~ ~he priY~e ~eY !3SAF
;eY - rec~ory Assit~n l ~o lhe serinl numbcr k~v direc~orY
~ev - rec~orY Wri~e ~he ~ev D3ir d~labase ;eY ~ n c~orv Re~urn ~he l;ey pair i;eY dire~orv Jl Upd~e l~ey lis~ Ul Change certificate (own private,~public key palr) rhe user needs ~o logon a~d ac~iYa~e CerlirCale ma~lagem~n~ main mel~u berore ge~ ~o ~his funcLion.
~ iator Acliol~ ar~iciDa~
Jser Selec~ a l:eY pair ror challee Jser Jser InYol;e chQnQe cerlirjca~e bu~on Jser Jl Display a scree~ ~o chall. e er~ec~ive d~e. Ilame Jser ~ld e-m~il zddress Jser _hanee rields Jser Jser lYo~e ~he crea~e ~lew ~ ey bullon Jser Jl .e-Qenera~e ~hc l:ey pa r ;ey direc~orY
;eY - ncc~ory /-.sSiQn llew serial ~lum ler ~ey dinec~ory ;cY - rec~ory ~ c~ l:CY Qe~Cr~ioll see- seed e~nera~or ;cy ~ nec~ory c~ Ie~e~h of l:e~ conr -ura~ion ;cy ~ rcc~ory encr3~c privale nl~d pU~llic ~ey pair BSA~E
c rcc~ory .~lsure ~he public l:CY docs no~ exis~ ~ev - irec~orv d:l~basc .cY- nec~ory c~i~lIcrnalencrvplionl:cv -~nr-ur~lion :cy c rcclorY .~lcnp~ Ihe priv~le l:eY SA E
;ey - reclory ~rile Ihc ~Icw ~cy r-~ir ;cv - ircc~ory dalab~sc ;cy ~ rcClory I c~ur~ c l:eY r~ir ;cv ~ircclory Jl Ur~lalc l;cy lis~ IT =~-218~597 . . ~
~emove own private/public l~ey pair ~he user needs lo logon and activrl~e cenifca~e mrmagement main menu before ge~ lo ~his function.
nitiator Ac~ion aniciprlnt Jser Seloct a l;ey pair ~or nemoval Jser Jser rnvol;e remove l~ey poir bu~lon Jser Jr Check whe~her tho l~ey pair is used in any trading ~rading p3rtner prlrtnu aereement - ereement Jr Displrly Ihe confirmalion messa~e Jr Jser 'onr~rm lo removo Ihe l~ey pair Jser Jl emoYe Ihe l~ey pair iey dlrec~ory ~ey direc~ory e~c~ivale ~he l:ey pnir ;ey direc~ory da~abrlse rl vlar~ Ihe ~ey pair as dcac~iva~ed on screen Jl .

`` 2181~q7 Copy own public key to disk file The u5~r needs ~o logon ru~d ac~iYale certifica~c m tn tzcmcnt maill merlu before zc~ lo ~his runcdon.
~niliator Ac~ion . ;tr~iciP2n Jser Selecta l;ey Jser Jser InYokc ~he copY ~o dist~ func~ion Jser n Displny a sc~een to prompt rOr ~he oulput file n lrlme ser ~ey in ~he fle n;~me Jser ~ispl3~' a revlacement confirma~ion screcn n cr elect~ooYerYri~e~heexistingfle Jser utput ~he certilic tte ill X.509 rormat ~o disl~ flc .cy direclorY
- isplay a complc~io~l mess~r!e Jl edisplay ~hc list ~T
Print own pub/ic key certificate The user needs lo logon rlnd ac~iYa!e ccnif catc m~tn~zcmenl m tin mcnu beror~ ze~ lo Ihis fanction.
ni~ia~or ~c~ion arliciDant Jser elec~ a l~ey Jser Jscr nYo~e ~he print cerliric~e runc~ion Jser ~T c~ ~he human rc;~dable rormtl~ed certirica~e ~cv dire_torY
;ey direclorv orma~ the rli~ ol~ishr d namc. public l~cy iey dineclory erfecliYe da~e rcferc~lce (l~ey ID) scrial number.
sizn~ture alzorithm cenific~te signoture YerSion issue~ rnd e-m~it oddrcss Ul Output thc certiricate IO Ihe svstcm dcrau~t prillter Ul Ul RedisDlaY l:le list m Save own private/public key to disk file The user necds ~o lozoll ~Id ac~iva~e cenif~c t~e m tnaZemenl main menu bcrore get ~o this runc~ion.
nitia~or Actioll tlrtici Jser Sclec~ a ~eY Jser Jscr Invol;e the saYe lo disl; rullClion Jser JT Display ~ SCrccll ~o promp~ for ~hc output rile n lame scr ~cy in ~he rite ll~mc Jser l ~isplaY a rcplaccmcllt conf rmatioll scrcen Jl scr clcc~ ~o ovcrv ritc Ihe C~is~ rile Jscr T Outpu~ the l;c I .lir - distillzuished llt mc privatc ;e~ directorY
pul~lic l;cy crrcctivc d:ltc. rcrcrcnce (l~cy ~D) scrirInumbcr di~cstulzori~hm ditcsl.vcrsio issucr a~ld c-m~ ddrcss ~o rilc In Display n com~tctir)ll mcss~rc t~t tn t~c~tisplay t~lclist 23 2~8~97 `~ ~
Restore own priva~e/public key from disk fi~e ~o replace the existing Th~ uscr needs lo logon and ~ctiv31c cc:lific31e m3n3gcmcll~ m2in mcnu bcrore gct ~o ~his runction.
itialor ~clion rliCipant ser ele_l a i;ey . ser ser nvo ;c Ihe rcslore from disl; runction . ser ~isp aY a screcn lo promp~ ror Ihc inpu~ rle n3me scr 'eY n lhe rlc l~3me ser ~isp ay a repl3ccmenl conrumalion 3nd save Ihe l iiev p3ir scncen User Sclcc~ (o ovcr~vnle Ihe cx isling iicy 3nd iicy in Ihe Uscr 53VC rlle 113mc Ui Cre31e a loe cn~ry 3udil loe Ul Oulpul Ihe cxis~ing iicy p tir ~ in~ h,~d 113mC, iicy dircclory pnvale, public ~ey, erfcc~ive d3~e, rercrc~lce (liey ID), serial numbcr, digcsl al~ori(hm, diQcst, ~crsiol~. issu2r Dnd e-m3il 3ddrcss (o (hc s3vc file f[ ,eDI3c~ (h: liey p3ir - iicv direc(ory ;cy dircc(ory~ .e3d in (he iicy inrorm3(ion from ~hc r(lc i ev dircc(ory ;ey direc(orv Dd3(e (he ~ey inform3(ion . ~ 313b3se n ispl3v a c~mDlelioll mess3r~e ~i r~ edisDI~Y Ihc list n ..
Restore ou~n private~public key f~om dlsk file to a new key rhe uscr needs (o logon and 3ctiv3(e ce.~ifc3(c m3nngcmelll m3ill mcllu betore gel (o (his rullction.
Ini(i3(0r Aclion P~r(iciD3n Uscr ~llvoiic !hc reslOrC from disi; rullc(ioll Uscr Ul Dispi3y a s~rccn (o promp( ror (hc licy ID 3l1d Ui npu( rlle llamc Jser :ev ill Ihc iieY ID alld file n3me User ;cy c reclorv c3d in Ihc ~ey illform31ioll from (hc filc iiey direc(orY
;cy - rcc(ory 31cul31e ~he ccrtirc31c diQest diaesl c31cui31or cy - reclory Ycrirv Ihc diQest m~lch iicv dircclory cvt rec(orv Wri(elheiicvillrorm31ion dal3b3sc ~i Add Ihc iicv Dair (o (hc lis( Ul i Redispl3Y (hc lis( Ui `` 2~81597 , _ Activate ~radlng parfner public key management main menu ni~inlor Aclion rr~iCiDant Jser rnYol;e er:ldin~ D~r(ner l;ey bu~lon Jser n Gel a lis~ of ~r3dinr p~r(ner pub~ie i:ey ;ey direc~ory Jl Displ:ly Ihe lis~ of trading pQr ner publie l~eys on Jl sereen Add tradingpartnerpu~lic key The us needs lo lo~on ~nd ~etivo(e (r~dill~ p~ er public ceniriC~(e manrgemcn( m:hn mcnu berore ge~
lo (his func(ion.
i(ir,(or t~e(ion rliCiP:mt ser nvo~:e lhe add ~r~dinQ p~nner pub ie l~ey bu(lon ser 1 ~isD~ay rdd ~r3dille prlnner puhlie ;ey screen 1 ser eleet lo ~dd (he ~ey from a dis~: fi e ser r ~isplay ~ sereen ror i:eyinQ in (he ile nrme ser :ey in Ihe file n~me ser ~ead hl ~he e-m~il oddr~ss effeetive d~le publie public l~ey hle ey. phone number slreel ~ddress ur ~ispl~v Ihe publie l;eY ur User ~eY in Ihe tr3dine Derlner comp~ny name User Ul ~isDlay (he new Dublic l;ev in Ihe lisl on screen Ul Change ~radfngpar~nerpublic key The user ne-ds lo logon and rlc~iv~e Ir~ding p~r~ner public cerlific~e m~naeemenl m~in menu before ge o ~his func~ion.
ni(i~or ~c~ion ar(iciD~n~
ser ele ( a Dub ic l:~Y rOr ch~tlQe Jser ser nvo e (he clnllQe public keY bu(~on Jser 1 3e( (le publ c l;eY illrormr~oin ev dineclorv -isp Dy rrod nQ p3rll~er public ~ey on screen Jl cr _h~nQe Ihe crrcclive dnle ;n~d Duhlic l;ev Jser JpdDle Ihe pu~lic l;ev ;ey direclorY
Add Ihe new puhlie l:ev wilh I~CW serirll llumber ~ev direclorY .
- Displav Ihe new nublie ~ev ill Ihe lisl oll serecll Jl . _ 218i597 .
Remove tradingp~rtnerpublickey The user necds to logon Dnd rlctiYnlc IrDding pDnner public c~nifcDle mDnDgcmcnl mDin mcnu bc~ore get to Ihis ~unc~ion.
itiator 4c~ion Dr~iciprnt 5 cle t a public kcy ~or rcmoYal ~ser cr lVo e ~he r~moYe public key ba~on Jser et le public key i n~ormD(oin y din c~ory - isp ~y r,dd tr~din~ par~ner public key screen isp Dy Ihe conhrmrllion scrcen s ont rm Ihe removDI ser T eDc ;YJIC ~he public key ;ey dincc~orY
I .emove ~he public key ~rom ~he lis~ on screen n Copy ~radlng partnerpublic key from disk file to replace the existing The user needs ~o logon Dnd rlcliY~c ccnihc~e mDnDgemen~ mDin menu bcfore gc~ ~o ~his function.
Assume lhc file is in X.50 formD~. -iD~or 4c~ion r~iCiDrln~
scr elc_~ a Dublic l~ey ser ser nYo~e ~hc rcs~ore from dis~ funclion ser ~jSD ~Y a screen ~o promD~ for ~he inDu~ rlle n3me ~
ser ~ey n Ihc file nDme scr _l ~isp Dy a rcplDcemcn~ conrumD~ion rnd SDve ~he kcY Pr,ir scncen User Selcc~ ~o ovcr~yri~e ~he e~is~ing l~ey Dlld key in ~he User SDVe rle nDme Ul C-e~ea lo~cn~rY ~udi~ loe Ul Ou~pu~ ~he e~ls~ing l;ey - dis~inguished nrlme ~cy dineclory public l~ey erfec~ive dD~e rcference (kcy ID) seriDI number digesl rllgorilhm digest version suer and e-m:lil rlddress lo Ihe snve rlle ~1 .eplDce ~he l;eY l:eY din c~orY
;ey direc~orY eDd in ~he l:CY illform:llloll from ~hc rle I eY direc~ory ~eY direc~orY ndD~c ~hc kcY il~formD~io~ h~sc n isplny rl comùlc~ioll mcssnr!e n ~ci~ol~v~hcli~
~6 .
Capy ~rad~ng partrler pub~lc key from disk file fo a new k~y The uscr needs lo logon rLnd ncliY~Ic ceniric~le ~ m~in menu bcrore ~el lo Ihis function.
Assume Ihc rilc is in X.50, rorm~t.
Iniliator Ac~ion Pr-~icipnn~
Us~r InYolcc ~he reslorc rrom dislc func~ion User ur Dis,013y a screen lo prompt rOr Ihc ~ey ID and Ul ~put filc nzmc Jser :ey in ~hc t~cy ID and r~lc namc User ccy ~ rcclory .crld in ~he Iccy intormrl~ion from Ihc rile l;cy direclory ;cy ~ reclory ~ al- ulr,lc ~hc cerliricrl~e diecsl diF~csl calculalor ;cy ~ rcclory er fy Ihe di~esl m~ch ~ cy dineclory cY reclory Wr c~hc~eYinFormn~ion -~l~b~sc Jl Ad- ~hc ~cy lo Ihc list Jl Jl Re;.spl~y Ih~ lis~ Jl 2i8',597 , Ac~iYate trading partne~ ag~eement management main menLI
~niLiolor Ac~ion Porlicipan( User InYo1ie ~rodin2 ponner Dereemenl bullon User Ul Ciel o lis~ of trodinf, prlrlner ogreemenl ~roding p3nner oereemenl lisl UI Disploy ~he list of (roding p~nner o~reemen~ on Ul screen Add trading partner agreement l`he user needs ~o logon ond oc~iYo~e Irodill~ pQr~ller mon3gcm~nt mnin menu before ~et lo Ihis function.
Initio~or Ac~ion Por~iciDon~
User Invoiie ~he ~dd ~rodine ponner altrecmen~ bu~on Uscr Ul Disploy ~roding prrtner ogrcemen~ screc~l lo occepl Ul locoi ~r~ding por~ncr ond ccnircr~e ID: rcmo(e ~ridine Dorlner olld cenircole ID
User ~ InYoiie odd new locol Irodin ~ ponner User Ul DisplaY an add ~r3dille Donl~cr screen Ul Uscr ~ey in nome c011~3Cl colltocle-moil oddrcss User Dhone. fn;~. address~ full n~me. commcnt :I VerifY ~he ~rodine p~nner docs nol exis~ ~rodil~e Danner lis~
l ~dd he ~rodino ponner r~dine Dar~nerlis ~jSD OY ~he locol ~rodil~e ponncr on scrce~ l ser CeY n envcloD Iype. sepero~ors. ouolircr ol~d ID scr ser nvo ;e rdd new remo~e ~rodine ponner scr l ~jSD OY ~n odd ~r~di~e pon~cr screcn l _scr Cey n nome. coll~ocl. con~cl e-moil oddress _ser Dhone f~x t ddress. full n~me. comment _ I Verify ~he ~rodill& portncr docs no~ exis~ ~rodine D~rlner lis~
l ~dd ~he ~radinf pon~l'er radine p~tnner lis~
~isp aY ~he remo~e trodinlt pr~nner on screell l ser llvo ic ~hc illboulld rou~ e bu~on ser l ~isp oY inboulld rou~ine inrorma~ion screell l _ ser ~ey n illboulld i~lformo~ion -slolus; securi~y - _ scr NR0 I'IRR. ùlld collridelllioi: rlle ~o rcccivc EDI
d~lo: comm~lld ~o rull orlcr rcccivine I Vcrify illboul~d rouli~e il~rormo~ion ~bound rou~ine Add illhound rou~ llboul~d rouline ~scr l~lvoiic ~he ou~houlld rou~illc bu~on Jscr Displ~vou~bou~ld rou~ c i~lrormo~ion scrcc~l Jl _scr Kcy in Ir~nspr~r~ rorm31io~1 - MIME rcccivcr olld Jscr scl~dcr c-moii oddrcss. m~ximum mcss~gc si7,e, c~l~roc~cr scl scr Kcy ill sccurily - NR0. NRR. collridcl~ Uscr icr KCY i~l rc ~r~llsmissio~ crvol o~d nc~in~l Uscr _` VCrirY OU~hO~IIII~ K)l~illC illrorm~iorl ou~l~ol~l~d rou~inc A~ld oull)ou~ld rouli~lc ou~hound rou~inc Rc-displ~y ~llc ~r:ldillg p~r~llcr o~rccmcll~ m:~i~l Ul ~c rccn 2~8~597 ~ Sclcc~ lo S~tYc Ihe Irndine p~trlncr ncrccme~ Uscr ¦ Ul Add Ihe ~rnding pcnnc~ nsrcement trnding pnnner ~erc~men~ lisl Change trading partner agreement The uscr needs lo logon nnd nc~iYalc Irnding prlrtn~r m;tnngcmenl mnin menu berore ge~ lo Lhis function~
Inilialor Ac~ion Pnrticipant User Selec~ trndine prlnncr aereemcnt for chanee User Us~r InYol;c the chnnge ~rnding pnnner agrcemen~ User bullon UT Gel the sclec~ed trnding pitrtncr ngrccment trnding pnnncr - aerecmenl list Ul Ge~ inrormnlion - locnl and remole trnding trnding pnnner pnnncr~ inbound rnd cu~bound inrormnlion acreemen un Displ~y trnding pitrtner ngrc~menl informnlion on un screen nnd do nol ~llow ~o chnnge ~hc local nnd remo~e ~ntdine p~rlner User Rc~ues~ ~rJ chitnge Ihe loc~l Ir~ding pnnner User nronmnlion 1 e~ in~orma~ion nbou~ ~he locnl ~r2dine pt~nner Irndine Danner l isplty ~hc ~rndine ponner informn~ion on screen Ul ser h~nre e-m3il 3ddress of Ihe ~rndinQ Dtnner User I pd~tle Ihe ~rndi~le pnr~ller ~r;tdinr pnr~ncr isDlaY ~he ~rndinQ Dnnner nQreemcn~ scr~en tn ~r elec~ lo chnne~ rCmole Ihe IrndinQ Dnnner un - ~ inror nr~ior abou~ ~he remo~e ~radine pnnner rndinr D~tnner . sDl~Y I le ~rt- illQ pnnner inform~ion on scrcen n : splnY ~ te ~rn- inQ pDnncr ~ ~reemen~ scrcen Jl scr _ lnnQe ~ le nd - ress of Ihe ~rtdine Dnr~ner Jser l tpdn~e ~he ~r~ ine pnr~ncr ~radinQ Danner l isplny ~he IrDdinQ pitnlle- aQrecmen~ screen un _scr Cht~lce ~he i~bou~d n~ld ou~bou~ld rou~ing User inform~ion User Sclec~ ~o upd3~e ~he ~rndinQ pcrlner aercemcn~ Uscr ~n Upd~e Ihe ~rDdillQ pitr~ner QQreCmen~ ~rndi~lQ D2rtner lis~

.

2181~97 .
Remove trading partner agreement The user needs to logon and aC~ivalC unding prlrtller m:~nngemelll main mcnu bcro-~ gcl lo ~his runclion.
Ini~ia~or Ac~ion r~niciD~nt User Selec~ a ~rndin Q pQrtner agreemen~ ror remova~ Usa uS rnvol~e ~he remoYe trnding panner agreement Us ou~on ur Gel the selcc~ed trading partner agreement trading panner 2Qreem~n~ lis~
ur Ge~ inrormnlion - loc tl Dnd remole trading pQnn~r trnding panner nRrecm~nt ur Display trnding pnnner agr~ement inrorma~ion on ur screen ur Disolny ~he conrirmntion screen Ul User Conrirm removal User ur Remove trnding pDnner agr~ement trading p~nner nQreement ~ist ur Remov~ Ihe ~Qreement rrom Ih~ lis~ on scrcen ur ur RadisDlaY Ihe new list on scneen ur Copy trading partner agreement to disk file The user needs to logon and acliYrlle ~radil~g p~r~ner ngreemcn~ m~ mel~u bcfore 6c~ lo ;his funclion.
nilialor Aclion arlicio~n Jser Selccl a IradinQ D~rtner DQreemenl Jser Jser InYoi:e Ihe CODY 10 disl; funclion Jscr Jl Displny a screen lo prompl for Ihe oulpul rile ~1 lnme ser CeY in Ihe rle n~me Uscr ~isplaY a reDl~cemen~ conrrmalion scrcen Ul ser elecl ~o oYerwri~e ~he c~islinQ rle User l ~)utpu~ Ihc Ir~dil~g prrlllcr ngreemell~ lo file as a Iradillg p~nne~
n:" r,le aQrcem~nl ur Di.~plnY n comDlelioll mess~ne ur Ul RcdisplnY Ihe lisl Ul . ,~
Copy trading partner agreement from ~isk file The user needs lo logon nnd nctiv~le trnding p~nner ngreemcm m~in menu bcrorc g~t lo ~his runction ia~or 4cti n - rticip2nt ser lVO e lhe copy from disk func~ion ser isp nY a scneen lo promp~ ror the input rile name l ser ~ey n thefile n~me ser isp 2y a replncemcnt conrirm~tion screen ser eiect to ovcr vrite thc cxisting trnding partner ser aereernent Ul Replnce the trnding p mner agreeement trnd ing panne-nereement tr~ding panner Re~d in the tr~ding p~nner agreemen~ inrormnlion trnding panner aereement rrom ~he rile nereement trnding partner Updnle ~he tr~dine p~nn ngreemen~ inrormntion d~lnbase a ereemenl Ul Disp~ny n comp~ct ion mcss~ee Ul Ul Redisplny ~he lis~ Ul ` ~ ~
MIME packaging Initia~or Ac~ion P3rlicipant ;v . agent Cre3~e a MIME Objec~ wilh EDI in~erchrlnge MiME paciiager AUTACK trndinQ D3rtner 3QrCCment MIME paciirleer Get Sender's and ReceiYer's Qu31ifier rnd ID EDI in~erchanee MiME p3ciiager Ge~ From and To e-mjlil 3ddrcss m3ximum ~rading partner M~ME pani~l size 3Qrcemen~
MIME pacl ager Get trrlding pjmner securi~y - encryp~ion me~hod ~r3ding panner (e.g. DE'i or RC4) tr3ding partner public iiey ID 3gr~emen~
~o~fid."li~ na2 Mli~',E p3cli3Qer EnYelopc EDI in~erch3nee in PKCS enveiope PKCS enveloDer MiME pacii3ger Cre3~e EDI body pjm ~or ~he PKCS-r d EDI MiME body p3n inlerchnnQe MiME p3clr~2er Cre3~e AUTACK i ody p tn MIME bodY p3rt MIME prcii3ger Crc~e MIME hejlder - From 3nd To e-m~il MIME header ilddress MIME p3cl~3ger Cre3te MlME-p.. ni~ls from MIME ~lc3dcr nnd i ilME mcss3ge bodv p3ns MiME Drc~i3Qer Relum the MIME mcss3r~e lo 3u~hell~icr~ioll 3Qe~ MIME D3cii3eer MIME unpackaging Ini~i (or .~c~ion Parli Dan~
1' - ail CrerleMlMED3nial illsl3t~ce .~v-.D3clirQer v~v .Drc:3Qer LOQ D3nial 3rriv31 . 3u-il ~e v v- D3c;aQer ~ssembleD3ni31s M ~ D3cli3Qer ~'v .paC;~Qer oQrllD3ni:11sreccivcd -il o Y- v' paC~ZQer Jnv.r3PPKCS-ed bodY D~n , ~ de-enveloDcr v v pac a2er nfomm 3u~hen~ic3~ion zeen~ m3il 3rriY31 v s/lr Drcii3eer r~ .n~in~ r!n ar!en~ C~ From alld To e-m3il 3ddress v vi . p3ciia2er MlviEpaci3gcr I c~TPsecuri~y ~r3~ingp3nner -- lent au~ len~ C21 on 3een~ e~ lis~ of body p3r~s v v r messa2e a~ nl rn~ n~ 3een~ e~ AUTACK hodY p;lrl v v r. meSS3Qe n~ n~ on 32en~ et EDI ill~erchD~lQe v- v . meSS3Qe ~llcn~ on ~ n~ w~ h D~hc~ Dlocc ~e ~u lc: ic~ ~n 218~597 PKCS packaging r i3~0r Ac~ion nr~iciDnnt ~r ~E pncl~acer Crenle n PKCS-ed EDI in~erchnnce KCS pncicaeer . S pacl;ac~r Ge~ scnder s nnd receiver s ounliiler nnd ID .DI in~erchnricer ~t S pachger Ge~ ~rading pnr~ner s public l;ey ID nnd encryp~ion ~3ding pnnner nc~hod (e.g. DES or RC4) ~reement ~~_ pnc ;a2er e~ ~rndin2 n er s puhlic i:eY ; -~ direc~orY
pnc;ncer e~ r3ndom ~ _ I;ey :) S encrYp~or . _ pnc;neer .ncryp~ ~he . interchnn2e S encrYP1Or ~ . pac;acer Jlcryp~ ~he ~ Irey AFE
.r prlc ~ger ~rcnle Lhe P ~( -cd MIME body p~ wilh Ihe v ~E body pnrt encrYD~ed DES l:ey nnd EDI inlerch~nne PKCS pncl~neer ~eturn ~he PKCS-ed EDI inlcrchnnee PKCS p~cl~n.2er PKCS unpackaging Ini~in~or Aclion PnrliciDnn~
MIME pnclrnr~er UnwrrD n PKCS-ed bodY pnn PKCS p~c~n2er PKCS pncl~ger Gel Ir~ding pnrlner s public i:cy ID ~r~ding pnnner r r rcemen~
PKCS DaCl~arer Ge~ Iradil~r D~rtner S pub~ic l;e~ ~ev direclorY
PKCS prlc) nger Mrllch ~he ccr~i~cn~e in ~he envelope ~o ~hc Ir~ding p~r~ne; s public rtirlca in ~h~ I;ev dir~c~orY
: ~ Dac ~acer e~ ~he YCS-~d EDI inlcrch~n2er :CS-ed bodv pnrt DaC :~2er ecrYp~ ~ le DES ~eY AFE
DDc _2er ecrYD~ I le enc~D~cd EDI il~crchnncc S encr D~Or C ~ b~ --Di i~lc c~nc~ Ml~ S ~c~e ~ C5 D~cl:~n 2l8~597 Work with tracking record Inilialor Action Parlicio3nt User InYol:e worl; Wilh tr3c):ine record ~unc~ion User U~ Promp~ ~or seleclion cri~eri3 - d3~c r3ngo, Ul ~"d~ tracl~iltg recordID s~3~us da~a ~ype inl~rch3nge control numbcr (d3~a ~yr~e sensi~ive Dnd only apply ~o EDI d~Q) User ICey in crileriD e.&. d3~e r3nge User Ul Ge~ D I jS~ Or tr3cl;ing rccords which 3re wilhi~l ~he ~r~cldng rccord -peci ried d~e r3n Qe r~cl;inQ record uerY d3~b3se d313b3se 1 isp ay a lis~ of ~r3cl;in& records Ul ser nYo c view de~nil or 3n EDI bD~ch Uscr .1 e~-cl3il ~r3cl;ine record I j5P ny Ihe ùel3il of Ihe EDI bolch Ui ser ~vo ;e ~he rclr3nsmi~ion of 3n inlerch3nee User ~l elr3nsmil Ihe inlerch3nce Ihen~ic3tion 3rcen~
_ l edisDI3Y Ihe dc~3il ser _lose ser .edispiaY ~he lis~ or tr3cldllQ record ser = elec~ ~o retr3nsmi~ 3n EDI b3~ch scr .err3nsmi~ of Ihe b3~ch ~ ;. aeen~
l edisDI3y Ihe lis~ of ~r3cl;inrc rccord Ul ser ~ ~eDroccss 3n ou~bound b:~ch User _l eproccss 3n ou~bound b3(ch (st~n ~rom ~ h~/.li,n~irn agen~
-cQinllin e~
1: .edisDI3y ~he lisl of Ir3ci;inQ record Ul scr eorocess3n illbou~d b31ch User eDrocess rn i~lbou~7d b3~ch ~sl3r~ rrom bcr i"ni~ e~ aQcn 1 edisPI3Y Ihc lisl of Ir3cl;inQ record Ul ser onlinUc rrom 13sl 3clion User l onlinue IQSI 3clion ~1. ... ~il .~1; - . arent rll~h~n~ir~lir~n3eent e~sl31us Iracl;inQrecord ~U~ iv~ acenl _o~l~inue proccss 3ccordi~1Q lo Ihe s131us ~.,1~.. ~; I;v. ~cn Ul cdispl~Y Ihe lis~ of Ir3cl;ill~ record Ul Uscr .epeal 13s~ 3c~io~1 Or 3 succcss inhou~ld b3~ch i.c. Uscr (r~11sl3~e Ul .CPC~ IQSI 3clio~1 3u~hcnlic31ion aeen nl~hrnlir~irll 3~cn~ e~s~lus ~r:~ckine record - ~hcn~ic3~ion 3QCo~ cpc3~ sl ~CIiO~ llhrn~irn~irn ~I!Cn I cdispl~v Ihc lis~ or Ir3cl;i~1r rccord Ul -cr clcc~ ~o pri~ll 3 aroup or Ir3cl~ine rccord Uscr - cl Ir3C~:ine rccord summw i~lrorrn3~io~1 Ir3cl;ine rccord orm~ Ihc rcport Ul ri~ c rcpor~ pri~l~cr cdisrl~Y ~llc lis~ or ~r3c~inr rccord Ul scr clc3sc3 llol~l EDI b~ch Uscr _h~nrc ~hc s~ s or Ihc Ir~c~i~lr~ rccord ~o rclc3sc ~r.lcl;inr rccord 2~8~597 rocess ~heEDI batch ~u~henlic~ion ~eCn l edisplry Ihe lis~ of ~rrcl~inr record Ul scr cle_t ~o disDI3Y Ihe conlcnl of a receivcd mnil Uscr _T ct ~ lc mrlil conlen~ tr~cl;inr rccord racl;inr record et ~le mail con~en~ . r lil file _ Jl isD ry ~he meil Jser _losc ser n .edisPl~y ~he list of tr~cl~inr record Monitor server jobs Ini~ir~lor Aclion P~rlicip~n~
Uscr l~vol;c wor); Wilh mo~ orservcr jobs fullc~ion Uscr Ul Ge~ serYer jobs ill~orm~ion or)er~ing sys~cm on Ihe scrver Ul D jSDI~Y Ihe scrver job name s~alus Ul User Sclec~ ~o refresh ~he s~us Uscr Ul Ge~ server jobs i~rormr~ion oper~linS sysl~m on ~he crYcr n ~isDlry ~hc scrver iob 1~3me s~lus Jl Jscr cl~ ~o s~:m a scrvcr job e.r. rcuardian Jser n the server iob ob conrleur~ion ob ullfj5u- GIiUII tar~ Ihc job ooer~tinS sys~m on ~hc server Ul Ge~serYerjobsinformr~ion operl~in s~s~emorl~he scrver 1)1 Di~ v Ih- ~o~ b no~

2~875q7 ~ecefve an fnvi31f~ EDI doclJmen~ witf7 integ~ity prab~em Assume ~hrl~ the beginning of thc scrip~ is sDme es ~hc Receive a VDlid EDI Docum~n~. Afle- v~rif~ing the diges~ of ~he p.~rtial AuTAcK sDme ;~s ~hc decryp~ed signed digest in ~he AUTACK, ~he h~ nlir1~irn Agen~ finds ou~ ~h~ Ihe diges~ in ~hc AUTACT does no~ m;l~ch Ihe diges~ Or ~he EDr in~erchrlnge.
Ini~iator Aclion P~rticipan~
.. ".. ,i, .~i"" agcn~ Crea~c Dn in~erchnnge in~egri~y error log wi~h audi~ log following informa~ion: digest in AUTACK, diges~
of ~hc EDI in~enchrmge, AUTACK control numbcr, inlerchrlge con~rol numbcr, trading panner nDmc, tr;tcl;ine record ID.
hPn~ir~ion agcn~ Upd~c ~hc status of ~he tr;lcl;ing record to trac~ing record in~erchanQc in~e~ri~y error h~n~ira~inn agen~ Ge~ local e-mail addrcss ~nading partncr a reemen~
~",h,n,irDlinn agen~ Fommal an in~cchrmge in~egrity error e-mnil wilh I ~ agent foltowing infonmalion: lime st~mp, di6es~ in AIITACK, diges~ of ~he EDI inlerch mge, AUTACK control numbcr, inlerchage conurol number. Iradin~t prlr~ner name~ ~racl;in~ record tD.
h~n~ir1~inn aQent Send ~he e-mail sendmail ~u~h~n~ir~irn aeent Get EDI inlenchrmQe cre~ion da~e and ~ime ED~ in~erchanQeh.~n~ir~inn agent FormDt a nega~ive AUTACK - Ihe digesl in Ihe AUTACK
neceived A~TACK
a~h~n~irn~ion D~ent ~reDle Dn AUTACK i~llerchDnQe AUTAC~ inlerchanQe aulhenticDlion DQenl Encode Ihe nel!DliYe AUTACK in MIME rormDI MIME Dac~aDcr hl~n~ir1~irn age~ll Scnd Ihe cncodcd llcga~ive AUTACK ~o trDding sendmail pDr~ller hrnlir~inn Dgent Updale ~he s(~us of Ihe ~ract;ing rccord lo ~rDci6ng record inlerchDnge inlegrily error wilh neg~live AUTACK sen~
hrn~ir~ir~n aeen~ Loe Ihe neQDlive AUTACK scn event . audit loe Re~ve an A LI~A CK with in~egrify problem Assume th3~ Ihe beginning of the script is s3me rls the Recei~e D Valid EDI Document. Thc h~nlirr~tinn Agen~ finds out Ihal Ihe digest of the p3rtial AUTACK is nol same as Ihe decrypted signcd digest in the AUTACK
Initialor Action P;lrlicipant ?~'h~n~ir~ion agent . Crea~e an AUTACK in~egriiy error log wilh audil log rollowing inform3tion: signed digest ot Ihe partial AUTACK in AUTACK, decrypled signed digest of the partial AUTAC~C in AUTACK. ca~cul31ed digest of Ihe partinl AUTACK, AUTACK control numbcr, trading p3riner name, trading panner's public key, ~racking record ID.
n~h~n~irr.~irn agenL UpdaleIhes~31usofthetracl;ingrecordlo tr3cl:ingrecord AUTACK in~e,~ri~y error ~lh~n~ir~in-l agent Get loc31 e-mnil nddress Ir3ding p3nner acreement ;",- agent Form3~ 3n AUTACK in~egri~y error e-m3il wi(h ~ ' ' agent following informa tio~ ime sl3mp, signed di6est of Ihe p3ni31 AUTACK in AUTACK, decrypled signed digesl of (he p3ni31 AUTACK in AUTACK, calcal31ed diges~ of Ihe psrtiai AUTACK, AUTACK con~rol numoer, trading p3nner n3me, tradil1g p3nner's public key, ~rackinE record ID.
accn~ Selld ~he e-m3il sendmail Receive unsLlpported mail Assume tha~ ~he beginning of Ihe scripl is same 3s ~he Receive a Valid EDI Documen~. The lh~nlir~inn Agen~ rlnds out ~hat ~he mail is not an EDI documen~, no~ a~t AUTACK, and not a certifica~e.
Ini~ia~or ~clion Par~iciDan~
"~h~n~ir~irn aecn~ ump ~he ansuppor~cd mail lo a hle dumD rlle - ump hle el ~he dump file dir~ory conhcura~ion - ump file ellera~e an ullique dump hle name dumD hle - - ump filc u~pu~ ~hc unsupported mail to the dump rile dump hle r--~hrn~ irn 3gcAt Crcale a rcccived u~lsur~poncd mail error log wilh audit log followillg illrormation: scllder alld receiver e-mail address, subjecl, e-mail mess3ge ID, dump hlc name.
?.. ~h- nlir-l~irn agc-.~ Update thc s~a~us or ~he ~r3cki~lg rccord ~o rcccivcd ~raci;ing record unsuppor~cd mail 53vC ~hc dump filc namc t ~ n agclll Gc~ localc-m3il Dddrcss ~radillg partncr acrccmen rnti~r~i~n ngcnl ForTnat a rcccivcd u~lsuppor~cd mail cnror c-m;~il o~hr~-ir~irn a,cen wi~h rollowil~g il~form3~ioll: sclldcr a~ld rcccivcr c-m3il nddrcss. sul~jcc~, c-mail mcss3gc ID, dun~p hIc n3mc.
.lu~l~rn~ io~ acC~I Sclld t ~c c-mjlil scndm3il 2~81597 ,~.
Rece;ve an EDI ;nte~ch~nge w;thout AUTACI< while non-rep~diat;on of orlgin ~s expected Assume ~hat Ihe beginning ot the scripl is s:lme rls Ihe Receive a VDlid EDI Documet~l. 'rhe hrn~ir~ion Agent finds out thi~t Ihere is no AUTACK in Ihe mDil.
Ini~iator ~.ction Pilrticipant ,.11.~ ~;. .1;.,l~ apent ump the EDI inlerchonpe lo a file dumD flle ump f Ie et ~he dump fiie directory 1, ~liu"
- ump r le enerate an unique dump file name dump file ump f le U~DU~ ~he EDI in~erchrlnpe ~o the dump hle dump file R~l~h~n~ r~l jon agent re~te ;m AUTACK no~ reeeived error log wi~h zudit log following inrormation: ~ime s~rlmp, in~erchi~ge con~rol number, trDding pilrtner nilme, tracldng record ID. dump file nilme.
h~n~ inn Dgent UpdDle ~he slalus of Ihe ~r~cldng rord ~o ~cl:ing record AUTACK no~ rcceived. srlve Ihe dump file name l~h,on~ inn ngen~ Ge~ local e-milil Dddress tr~ding pDr~ner rl~r~ment l~h~n~ inn rlgen~ Form~ n AUTACK l~o~ received error e-mr~ llh,-ni~n~inn r.~en~
wilh rollowing informD~ion: ~ime s~nmp, in~erchr~ge con(rol number, ~r;lding pilrtner nome, ~rilcl~ins record ID, dump rlle name.
~nn ~c~ I Sen~ m~ en~m~l ` 2181~7 ~-Re~ve an unexpecfedAUTACK
Assume Ihat the beginning of the scrip~ is Same as Ihe Receive Q Vrllid EDI Document. The h~n~ina~in~ Agent finds out ~hrt there is rln AUTACK in ~he mail but Ihe ~radillg partner agreement spccifes no non repudiation of origin.
Initialor ~ ction Pnrticipan~
a~enl ump Ihe EDI inlcrchrl~te lo a hle dump file - ump fle et the dump file dircc~ory ~tiu"
- ump file enerale an ur iqu dump f le n3me - ump e ~umpfile ulpu~heED lolledumpfle ~ump e iv~ atten~ ump ~he AU AC C in~erchanee lo a file ~ ump e -umrJfle etlhedump Icdreclory Collrrurrlion - ump f le encrale an un que dump rile n~me dump fle -umpfle utputtheA~rACK~olhedumpfle dumpfile agen~ ~re~e rn unexpcclcd AUTACK error log wi~h audil log followil~g il~rormalion: ~ime slamp inlerchage control number Iradillg partncr n2me tracl:ing record 1~. dump fle names nlllh~n~ imn azenl Updale ~hc Status of thc trac~ing rord to tr~cl:ing record ullexpected AUTACK. sa-~c the dump rlle n3mcs Rll~h~n~irnli~n agent Get loCrll c-mail address trad~ panner at!reement nu~h~nlirRli~n agent Format an unexpecled AUTACK error e-mail wi~h aulhel~ication agen~
following inrormation: lime st;tmp intcrcha~e control numbcr Irrding part~cr n~me ~racldng rccord ID. dump r~le l~ames , atlenl Send the e-mail scl~dmail 2~8~597 FIGS. 14-41 illustrate the various screen displays, in a conventional WINDOWS, type environment, that are capable of being preferably provided on the typical computer screens 116, 118 associated with the servers 112, 114 in carrying out the :
above method under control of the program which is based on the scripts of TABLE A~ In this regard, FIG. 14 illustrates the overall screen display which is presented to the parties on the network who are eligible to participate in peer to peer, computer to computer, business EDI transactions through the INTERNET. As shown by way of example in FIG. 14, the user may be presented, by way of example, with the choice to select windows for TRADING
PARTNER PROFILES, TRADING PARTNER AGREEMENTS, KEY MANAGEMENT, and TRACKING in the conventional WINDOWS environment which is preferably employed.
FIGS. 15-21 illustrate various computer screen displays which the user may be presented with af ter selecting the TRADING
PARTNERS PROFILES window in the screen display of FIG. 14. FIG.
15 represents a scenario of three possible trading partners identified as CISCO, SEARS, and ME, where ME represents the user himself. FIG. 16 illustrates a possible dialog box for creating the trading partner profile directly on the computer screen 116, 118. Similarly, FIG. 17 illustrates a possible dialog box for creating contact information for the trading partner directly on the computer screen 116, 118. FIG. 18 illustrates a possible dialog box for creating EDI qualifier information directly on the computer screen 116, 118. FIG. 19 illustrates a possible dialog box for trading partner bound keys which are displayed and may be changed directly on the computer screen 116, 118, with two options for BIND and UNBIND being shown. FIG. 20 illustrates the computer screen display 116, 118 when the sIND KEYS option has been selected in the display of FIG. 19 in order to bind a particular key to a par~icular trading partner. FIG. 21 illustrates the computer screen display 116, 118 for KEY ADDENDUM
for, by way of example, displaying a formatted certificate which may be bound to the trading partner along with the key.
FIGS. 22-28 illustrate various computer screen displays which the user may be presented with after selecting the TRADING
PARTNER AGREEMENTS window in the screen display of FIG. 14. FIG.
22 represents a scenario of the same three trading partners as identified in FIG. 15. FIG. 23 illustrates a dialog box for creating, in the above example, a trading partner agreement between the user ME, which is the local ID, and SEARS, which is the remote ID, directly on the computer screen 116, 118. FIG. Z4 illustrates a dialog box for creating the inbound routing instructions for the trading partner agreement directly on the computer screen 116, 118. Similarly, FIGS. 25-27 illustrate various dialog boxes for creating the outbound routing instructions for the trading partner agreement directly on the 2181~97 . ~
computer screen 116, 118. FIG. 28 illustrates a dialog box for selecting the outbound retransmission directly on the computer screen 116, 118.
FIGS. 29-33 illustrate various computer screen displays which the user may be presented with af ter selecting the KEY
MANAGEMENT window in the screen display of FIG. 14. FIG. 29 again represents a scenario of the same three trading partners as presented in FIG. 15. FIG. 3~) illustrates a possible dialog box ~-associated with the local key ID, FIG. 31 illustrates a possible dialog box associated with the remote key ID, FIG. 32 illustrates a possible dialog box associated with key details, and FIG. 33 illustrates a possible dialog box associated with export oi~ the public key to another ~ile.
FIGS. 34-41 illustrate various computer screen displays which the user may be presented with a~ter selecting the TRACKING
window in the screen display of FIG. 14. F~G. 34 illustrates a screen display on the computer screen 115, 118 in which two EDI
messages have been sent, one between SEARS and CISCO, and one between ME and THEM, by way o~ example. FIG. 35 illustrates a -~
possible display on the computer screen 116, 118 of the interchanges between the trading partners and shows the non-repudiation o~ receipt AUTACK, illustrating the AUTACK status on the computer screen 116, 118 in accordance with the present invention. FIG. 36 illustrates a possible display on the computer . ~
screen 116, 118 of the EDI data af ter the VIEW EDI DATA dialog : ~
box has been selected in the screen display of FIG. 35. FIGS. 37-38 illustrate possible screen displays on the computer screen 116, 118 for selecting tracking criteria. FIG. 39 illustrates a possible screen display on the computer screen 116, 118 of an audit log, with FIGS. 40-41 illustrating possible screen dlsplays on the computer screen 116, 118 for selecting audit log selection criteria .
Referring now to FIG. 2, the preferred process of authentication and non-repudiation of origin in accordance with the presently prQferred method of the present invention shall now be described. As shown and preferred in FIG. 2, block 200 represents a typical EDI interchange in accordance with the present invention. Block 202 represents the preferred action of the server at the sender end with respect to this EDI interchange in accordance with the method of the present invention. As shown and preferred, the sender server preferably computes the MD5 for the entire EDI interchange, such as from ISA to the last character of IEA (termed MD5EDIINTERCHANGE) . This value is then preferably inserted into a predetermined position in the AUTACK
message, such as pref erably the second element of segment USY in the AUTACK message. The sender server then preferably computes the MD5 of the AUTACK message, such as preferably from t~le first character of USH to the first character of UST. The sender server . --then preferably signs the AUTACK by encrypting the MD5 with the sender' s private key. Thls computed value is then preferably inserted in a predetermined location in the AUTACK, such as preferably as the first element of segment USR in the AUTACK
message. Block 204 represents a typical AUTACK message in accordance with the preferred method of the present invention af ~er the sender server has taken the action illustrated in block 202. The AUTACK 204 is then preferably transmitted to the receiver server where the receiver action and verification illustrated in block 206 preferably takes place. If the EDI
interchange is encrypted, then the receiver server preferably decrypts it and computes the ~qD5 of the received EDI interchange.
Assumin~ that non-repudiation of origin is desired or requested, the receiver server then preferably, using the sender' s public key, decrypts the contents of the first element of the USR
segment in the AUTACK message 204, which is the location where the sender server has inserted the MD5 of the AUTACK. The value thus obtained by the decryption is the MD5 of the AUTACK message, in the above example, from the first character of USH to the first character of UST. The receiver server then preferably computes the MD5 of the AUTACK message and compares the computed MD5 with the value of the MD5 obtained by decrypting the contents of the first element of the USR segment in the AUTACK message. If both values of MD5 are equal, then the receiver server knows that ~

the integrity of the AUTACK is preserved and non-repudiation of origin is established. The receiver server then preferably compares the MD5 of the EDI interchange with the MD5 in the USY
segment of the AUTACK message, which is the location where the sender server has inserted the MD5 of the EDI interchange, and, if the two MD5 values are equal, the receiver server knows that the integrity of the EDI interchange is preserved, authenticity is verified, and non-repudiation of origin is established.
Ref erring now to FIG . 3, the pref erred process of non-repudiation of receipt in accordance with the presently preferred method of the present invention shall now be described. As shown and preferred in block 208, the action of the roceiver server in verifying the integrity and authenticity of the EDI interchange received is pref~rably as described above with respect to block 206 of FIG. 2. Thereafter, the receiver server preferably creates a new AUTACK, such as the AUTACK message represented by block 210, and transmlts the new AUTACK 210 to the sender server for ~ .
verification by the original sender server, as represented by block 212. As shown and preferred in FIG. 3, in creating the new AUTACK, the reciver server preferably populates a~l segments and elements as appropriate, such as all segments and elements up to and inclusive of UST. The receiver server then preferably computes the MD5 of the new AUTACK, such as from USH to the first 2~8i~97 private key. The receiver 9erver then preferably inserts the digitally signed MD5 into a predetermined location in the new AUTACK, such as the first element of the USR segment. The receiver server then preferably populates the UNT and UNZ
segments of the new AUTACK as appropriate and transmits the prepared new AUTACK to the original sender server. The original sender server then preferably verifies the digital signature of the received new AUTACK by decrypting it with the receiver' s public key, with the value obtained by this decryption being the MD5 of the received new AUTACK. The original sender server then computes the MD5 of the received new AUTACK and compares it against the value of the MD5 obtained from the decryption process. If the two values of MD5 are the same, then the original sender server knows that the integrity of the new AUTACK is preserved and non-repudiation of origin of the new AUTACK is established. The original sender server also knows that if the MD5 contained in the USY segment of the received new AUTACK in the above eY.ample is equal to the MD5 of the EDI interchange previously transmitted and the acknowledgement is positive (such as preferably obtained by testing the security code in the new AUTACK message), then the EDI interchange in question is known to both sender and receiver because the MD5 of the EDI interchange and the interchange number are contained in the AUTACK message and have been duly recognized. In addition, the integrity and .

- 218l~97 ` ~ ~
.
authenticity of the EDI interchange upon receipt has been verif ied and the receiver sender does not deny having received the EDI interchange in question.
Referring now to FIGS. 4-5, a process flow diagram of the presently preferred method of receiving and sending E-mail, respectively, in accordance with the presently preferred method of the present invention is 6hown. In this regard, TEMPLAR, the controller for carrying out the opresently preferred method of the present invention, preferably sits between the conventional mailer and the user specified EDI flat-file on the sending and receiving systems, with the conventional SENDMAIL supplied with the UNIX X-WINDOWS OR MICROSOFT WINDOWS operatins system being preferably used to send and receive mail, Wit~l the mail which is being sent and received preferably being MIME compliant, and with PKCS being preferably used to encrypt and decrypt MIME encoded body parts. Preferably, the MIME identifiers are not encrypted.
As noted above, the EDIFACT AUTACK message is preferably used to deliver secure authentication, non-repudiation of origin and/or receipt, and acknowledgement or denial of acknowledgement for one or more X. 12 or EDIFACT envelopes . Preferably, multiple EDI
envelopes are viewed as one block of data in the system of the present invention. Preferably, if a received AUTACK message ~ails message integrity, an acknowledgement of receipt is not sent back to the original sender of the messagé, although, if desired, the system can be readily modified to accomplish this.
Referring now to FIGS. 6-9, these are process flow diagrams with respect to trading partner management, audit log management, tracking management, and job monitoring, respectively, in accordance with the presently preferred method of the present invention. These diagrams are self explanatory when considered in conjunction with the foregoing discussion and will not be described in any greater detail hereinafter.
FIG. 10 is a functional diagram of the organi2ation of the presently preferred method of the present invention as represented by the script of TA3LE A and the foregoing discussion and will not be described in any greater detail hereinafter.
Lastly, FIGS. 11-13 comprise a process flow diagram of the presently preferred method of the present invention in accordance with the foregoing description, with FIG. 11 illustrating various steps of verif ication of the integrity of the AUTACK, the EDI interchange, and the certificate, with NRO
representing non-r~pudiation of origin and NRR representing non-repudiation of receipt. FIG. 12 illustrates the portion of the method devoted to TPA processing. FIG. 13 illustrates the portion of the method of the present invention devoted to processing of the public and private keys, as well as TPA, in carrying out the method of the present invention as described above.

-~8-2~8~597 , ~
Thus, by utilizing the AUTACK message as a document for the digital signature which is signed based on a public/private key system, such as RSA, an efficient, highly secure mailer for EDI over an open network, such as the INTERNET, is provided in which trading partners may readily obtain secure verification and authentication and non-repudiation of both origin and receipt, all of which are important in fast ~oving electronic business transactions over a widely dispersed geographic area in which an open network is the most viable communication media.
What is claimed is:

Claims

1. In a communication system for selectively interconnecting a plurality of computers over an open public network over which said computers exchange secure digital messages between a sender computer and a recipient computer in said plurality of computers, said sender computer having a first associated public key and a first associated private key, said recipient computer having a second associated public key and a second associated private key, said digital messages comprising an EDI interchange communication between said sender computer and said recipient computer, said EDI interchange communication having an associated EDI acknowledgement message; the improvement comprising means for computing a first hash for said EDI
interchange communication from said sender computer;
means for inserting said first hash in a predetermined location in said associated EDI acknowledgement message;
means for computing a second hash of said associated EDI acknowledgement message;
means for digitally signing said associated acknowledgement message, said message digitally signing means comprising means for encrypting said second hash with said sender computer's private key;

means for inserting said second hash in a predetermined location in said associated EDI acknowledgement message;
means for transmitting said EDI interchange communication along with said digitally signed associated EDI
acknowledgement message to said recipient computer over said open public network; and means associated with said recipient computer for receiving and processing said received EDI interchange communication and said digitally signed EDI acknowledgement message for providing authentication and non-repudiation of said EDI interchange communication from said sender computer, said means comprising means for decrypting said encrypted second hash with said sender computer's public key; whereby secure private EDI interchange communications can occur over an open public network while providing authentication and non-repudiation of said EDI communications.

2. An improved secure open network communication system in accordance with claim 1 wherein said means associated with said recipient computer further comprises means for computing a third hash of said received EDI acknowledgement message; and means for comparing said third hash with said decrypted second hash from said received EDI acknowledgement message, said comparing means comprising means for providing an indication of integrity of said EDI acknowledgement message and non-repudiation of origin when said decrypted second hash and said third hash match.

3. An improved secure open network communication system in accordance with claim 2 wherein said means associated with said recipient computer further comprises means for computing a fourth hash of said received EDI interchange communication; and means for comparing said fourth hash of said received EDI interchange communication with said first hash in said received EDI acknowledgement message, said comparing means comprising means for providing an indication of integrity and verification of authenticity of said EDI interchange communication and non-repudiation of origin when said first and fourth hash match.

4. An improved secure open network communication system in accordance with claim 3 wherein said means associated with said recipient computer further comprises means for creating a reply EDI acknowledgement message and transmitting said reply EDI acknowledgement message to said sender computer over said open public network, said reply EDI acknowledgement message creating means comprising means for computing a fifth hash of said reply EDI acknowledgement message and for digitally signing said fifth hash by encrypting said fifth hash with said recipient computer's private key; and means for inserting said digitally signed fifth hash into a predetermined location in said transmitted reply EDI acknowledgement message.

5. An improved secure open network communication system in accordance with claim 4 further comprising means associated with said sender computer for receiving said transmitted reply EDI acknowledgement message, and for decrypting said encrypted fifth hash with said recipient computer's public key for verifying said digital signature of said reply EDI
acknowledgement message; and means for computing a sixth hash of said received reply reply EDI acknowledgement message; and means for comparing said sixth hash against said decrypted fifth hash, said comparing means comprising means for providing an indication of integrity of said received reply EDI acknowledgement message and non-repudiation of origin of said reply EDI acknowledgement message; whereby non-repudiation of receipt of said EDI
interchange communication is established boy said sender computer.

6. An improved secure open network communication system in accordance with claim 5 wherein said means for creating said reply EDI acknowledgement message further comprises means for inserting said fourth hash in a predetermined location in said transmitted reply EDI acknowledgement message, and said means associated with said sender computer further comprises means for comparing said fourth hash in said received reply EDI
acknowledgement message with said first hash, said comparing means providing an indication of integrity and authenticity of said EDI interchange when said first and fourth hash match.

7. An improved secure open network communication system in accordance with claim 6 wherein said EDI
acknowledgement message comprises an AUTACK message.

8. An improved secure open network communication system in accordance with claim 7 wherein said reply EDI
acknowledgement message comprises an AUTACK message.

9. An improved secure open network communication system in accordance with claim 8 wherein each of said hashes comprise an MD5.

10. An improved secure open network communication system in accordance with claim 9 wherein said public and private keys comprise an RSA type cryptographic communication system.

11. An improved secure open network communication system in accordance with claim 10 wherein said open public network comprises the Internet.

12. An improved secure open network communication system in accordance with claim 1 wherein said open public network comprises the Internet.

13. An improved secure open network communication system in accordance with claim 1 wherein said means associated with said recipient computer further comprises means for creating a reply EDI acknowledgement message and transmitting said reply EDI acknowledgement message to said sender computer over said open public network, said reply EDI acknowledgement message creating means comprising means for computing a third hash of said reply EDI acknowledgement message and for digitally signing said third hash by encrypting said third hash with said recipient computer's private key; and means for inserting said digitally signed third hash into a predetermined location in said transmitted reply EDI acknowledgement message.

14. An improved secure open network communication system in accordance with claim 13 wherein said open public network comprises the Internet.

15. An improved secure open network communication system in accordance with claim 14 further comprising means associated with said sender computer for receiving said transmitted reply EDI acknowledgement message, and for decrypting said encrypted third hash with said recipient computer's public key for verifying said digital signature of said reply EDI
acknowledgement message; and means for computing a fourth hash of said received reply reply EDI acknowledgement message; and means for comparing said fourth hash against said decrypted third hash, said comparing means comprising means for providing an indication of integrity of said received reply EDI acknowledgement message and non-repudiation of origin of said reply EDI acknowledgement message; whereby non-repudiation of receipt of said EDI
interchange communication is established by said sender computer.

16. An improved secure open network communication system in accordance with claim 13 further comprising means associated with said sender computer for receiving said transmitted reply EDI acknowledgement message, and for decrypting said encrypted third hash with said recipient computer's public key for verifying said digital signature of said reply EDI
acknowledgement message; and means for computing a fourth hash of said received reply reply EDI acknowledgement message; and means for comparing said fourth hash against said decrypted third hash, said comparing means comprising means for providing an indication of integrity of said received reply EDI acknowledgement message and non-repudiation of origin of said reply EDI acknowledgement message; whereby non-repudiation of receipt of said EDI
interchange communication is established by said sender computer.

17. An improved secure open network communication system in accordance with claim 4 wherein said means for creating said reply EDI acknowledgement message further comprises means for inserting said fourth hash in a predetermined location in said transmitted reply EDI acknowledgement message, and said means associated with said sender computer further comprises means for comparing said fourth hash in said received reply EDI
acknowledgement message with said first hash, said comparing means providing an indication of integrity and authenticity of said EDI interchange when said first and fourth hash match.

18. An improved secure open network communication system in accordance with claim 1 wherein said EDI
acknowledgement message comprises an AUTACK message.

19. An improved secure open network communication system in accordance with claim 18 wherein said open public network comprises the Internet.

20. An improved secure open network communication system in accordance with claim 19 wherein each of said hashes comprise an MD5.

21. An improved secure open network communication system in accordance with claim 1 wherein each of said hashes comprise an MD5.

22. An improved secure open network communication system in accordance with claim 21 wherein said open public ;network comprises the Internet.

23. An improved secure open network communication system in accordance with claim 21 where said EDI acknowledgement message comprises an AUTACK message.

24. An improved secure open network communication system in accordance with claim 23 wherein said public and private keys comprise an RSA type cryptographic communication system.

25. An improved secure open network communication system in accordance with claim 24 wherein said open public network comprises the Internet.

26. An improved secure open network communication system in accordance wtih claim 1 wherein said public and private keys comprise an RSA type cryptographic communication system.

27. An improved secure open network communication system in accordance with claim 26 wherein said open public network comprises the Internet.

28. An improved secure open network communication system in accordance with claim 13 wherein said EDI
acknowledgement message comprises an AUTACK message.

29. An improved secure open network communication system in accordance with claim 28 wherein said reply EDI
acknowledgement message comprises an AUTACK message.

30. An improved secure open network communication system in accordance with claim 13 wherein said reply EDI
acknowledgement message comprises an AUTACK message.

31. An improved secure open network communication system in accordance with claim 1 further comprising means for generating a trading partner agreement communication between said sender computer and said recipient computer, said sender computer and said recipient computer comprising trading partners, said trading partner agreement communication comprising said public keys in said EDI interchange communication for enabling said ttrading partners to provide certification to each other.

32. An improved secure open network communication system in accordance with claim 31 wherein said open public network comprises the Internet.

33. An improved secure open network communication system in accordance with claim 32 wherein said EDI
acknowledgement message comprises an AUTACK message.

34. An improved secure open network communication system in accordance with claim 31 wherein said EDI
acknowledgement message comprises an AUTACK message.

35. A method for selectively interconnecting a plurality of computers over an open public network for providing a computer exchange of private secure digital messages between a sender computer and a recipient computer in said plurality of computers, said sender computer having a first associated public key and a first associated private key, said recipient computer having a second associated public key and a second associated private key, said digital messages comprising an EDI interchange communication between said sender computer and said recipient computer, said EDI interchange communication having an associated EDI acknowledge message, said method comprising the steps of digitally signing said associated EDI acknowledgement message with said sender computer's private key; transmitting said EDI

interchange communication along with said digitally signed associated EDI acknowledgement message to said recipient computer over said open public network; and processing said received digitally signed EDI acknowledgement message for providing authentication and non-repudiation of said EDI interchange communication from said sender computer, said processing step comprising the step of processing said received digitally signed associated EDI acknowledgement message with said sender's public key; wherby secure private EDI interchange communications can occur over an open public network while providing authentication and non-repudiation of said EDI communications using said associated EDI acknowledgement message.

36. A method for providing secure private communications over an open public network in accordance with claim 35 wherein said open public network comprises the Internet.

37. A method for providing secure private communications over an open public network in accordance with claim 36 further comprising the steps of creating a reply EDI
acknowledgement message from said recipient computer; digitally signing said reply EDI acknowledgement message with said recipient computer's private key; transmitting said digitally signed reply EDI acknowledgement message to said sender computer over said open public network, said sender computer receiving said digitally signed reply EDI acknowledgement message; and processing said received digitally signed reply EDI
acknowledgement message for providing non-repudiation of receipt of said EDI interchange communication by said sender computer, said processing step comprising the step of processing said received digitally signed reply EDI acknowledgement message with said recipient computer's public key; whereby non-repudiation of receipt of said EDI interchange communication is established by said sender computer.

38. A method for providing secure private communications over an open public network in accordance with claim 35 further comprising the steps of creating a reply EDI
acknowledgement message from said recipient computer; digitally signing said reply EDI acknowledgement message with said recipient computer's private key; transmitting said digitally signed reply EDI acknowledgement message to said sender computer over said open public network, said sender computer receiving said digitally signed reply EDI acknowledgement message; and processing said received digitally signed reply EDI
acknowledgement message for providing non-repudiation of receipt of said EDI interchange communication by said sender computer, said processing step comprising the step of processing said received digitally signed reply EDI acknowledgement message with said recipient computer's public key; whereby non-repudiation of receipt of said EDI interchange communication is established by said sender computer.

39. A method for providing secure private communications over an open public network in accordance with claim 38 wherein said processing step further comprises the step of providing non-repudiation of origin at said recipient computer from said received EDI aknowledgement message.

40. A method for providing secure private communications over an open public network in accordance with claim 39 wherein said open public network comprises the Internet.

41. A method for providing secure private communications over an open public network in accordance with claim 35 wherein said processing step further comprises the step of providing non-repudiation of origin at said recipient computer from said received EDI aknowledgement message.

42. A method for providing secure private communications over an open public network in accordance with claim 35 wherein said EDI acknowledgement message comprises an AUTACK message;

43. A method for providing secure private communications over an open public network in accordance with claim 38 wherein said reply EDI acknowledgement message comprises an AUTACK message.

44. A method for providing secure private communications over an open public network in accordance with claim 43 wherein said EDI acknowledgement message comprises an AUTACK message.

45. A method for providing secure private communications over an open public network in accordance with claim 35 wherein said public and private keys comprise an RSA
type cryptographic communication system.

46. A method for providing secure private communications over an open public network in accordance with claim 45 wherein said open public network comprises the Internet.

47. A method for providing secure private communications over an open public network in accordance with claim 45 wherein said EDI acknowledgement message comprises an AUTACK message.

48. A method for providing secure private communications over an open public network in accordance with claim 47 further comprising the steps of creating a reply EDI
acknowledgement message from said recipient computer; digitally signing said reply EDI acknowledgement message with said recipient computer's private key; transmitting said digitally signed reply EDI acknowledgement message to said sender computer over said open public network, said sender computer receiving said digitally signed reply EDI acknowledgement message; and processing said received digitally signed reply EDI
acknowledgement message for providing non-repudiation of receipt of said EDI interchange communication by said sender computer, said processing step comprising the step of processing said received digitally signed reply EDI acknowledgement message with said recipient computer's public key; whereby non-repudiation of receipt of said EDI interchange communication is established by said sender computer.

49. A method for providing secure private communications over an open public network in accordance with claim 48 wherein said reply EDI ackowledgement message comprises an an AUTACK message.

50. A method for providing secure private communications over an open public network in accordance with claim 49 wherein said open public network comprises the Internet.