X-Envelope-to: EDI-L@uccvma.ucop.edu
X-VMS-To: EI3500::IN%"EDI-L@uccvma.ucop.edu"
X-VMS-Cc: FUDAN
Newsgroups: bit.listserv.edi-l
Date:         Wed, 22 Jul 1992 06:39:03 -0700
From:         FUDAN@RZ8300.CSELT.STET.IT
Subject:      EDI and Security ( also RE: FAQ)
Comments: To: EDI-L@uccvma.ucop.edu

	Sorry, this message is too late. But I still send it to the List
	as I see:

	>Date: Tue, 21 Jul 1992 17:01:00 GMT
	>From: "Donal O'Mahony, Comp Sc,Trinity College Dublin"
	>Subject: RE: Frequently asked questions (FAQ)

	>I would add something on activity in Europe e.g. the TEDIS programme,
	>possibly under heading 1.

	>A seperate heading on Open EDI
	>X.400, X.435
	>brief description
	>products/VANs (VARs??) that support it.

	>Planned and Current Practices relating to Security in EDI
	>......

	----------------------------------------------------------------

			   EDI and Security
					----OPEN-EDI(3)

	0.

	One could hardly avoid SECURITY when talking about EDI. Thank Mr.
	( Richard Hintz, Bill Laidley, Peter Williams, Randall O. Smith,
	John Nagle, etc.) give us good views. In this message some may be
	repeating,some may be ABC, anyway I should fulfil my promise.

	1. Scope

	Security related to OPEN-EDI at least includes the following
	asepcts:

		. mutual authentication of EDI pareners;
		. end to end message content integrity;
		. non-repudiation;
		. end to end acknowledgements at all necessary level;
		. electronic contract signatures;
		. cryptorgraphic key management;
		. electronic notary and court system

	Here does not list general network security, which is basis to
	transfer important information via network. Also, interior EDI
	applications security in a system is not considered.

	2. Pedi security function

	"Based on X.400(88) and X.500(X.509), Pedi( X.435 and F.435)
	provide relative complete security service..."

	The following Fig. shows EDIM responsibility transfer in Pedi.
	In fact X.400(88) provides more security sevice than Fig., eg,
	secure access management, etc.


	   EDIM originator			   EDIM recipient
        Trusted functionality			Trusted functionality
	.------------------.			.------------------.
	| .--------------. |  Proof of content  | .--------------. |
	| |   EDIM user	 | |<------------------>| |   EDIM user	 | |
	| `--------------' |			| `-------|------' |
	| 		   |      Proof of	|	  |	   | Proof
	| .--------------. |  EDI notification  | .-------|------. |   of
	| |    EDI-UA    | |<------------------>| |    EDI-UA 	 | |retrieval
      ^	| `-------|------' |			| `-------|------' |   |
      |	`---------|--------'<-------\ 		`---------|--------'   |
      |		  |	    	  Proof of	          |            |
      |	  .-------|------. 	  delivery        .-------|------.     |
      |	  |    EDI-MS 	 | 	       \	  |    EDI-MS    |     V
      |	  `-------|------' 	        \         `-------|------'
      |	 	  |	   	         `---------       |
      |	  .-------|------.    .--------------.    .-------|------.
      |	  |      MTA     |----|     MTA      |----|      MTA     |
   Proof  `--------------'    `--------------'    `--------------'
     of        Domain A		  Domain B	      Domain C
  submission      <----------------     <----------------
		  Proof of transfer	Proof of transfer


	Pedi currently  allows the use  of both standard  symmetric and
	standard asymmetric  tokens. In the  Heading Field there are a
	lot of security fields, also including authorization-information
	from ANSIX12 ISA.

	Of course further details about Pedi security functions should
	be obtained from studying F.435/X.435 and X.400 standards.

	3. Key management and X.500

	In theroy, X.509 considers every aspect of asymmetric key management:

		. Key generating;
		. Key store;
		. Key distributing;
		. Public key obtaining;
		. Key maintaining.....

	But it may be very slow process to use public key cryptography
	in EDI, first of all, how to set CA( Certification Authority),
	who can act as CA.... Without CA it is not easy to manage key
	in PKCS( Public Key CryptoSystem). Although X.500 directory
	is set in the world, real directory applications in business
	process needs further study. In fact someone propose it, no
	well discussion is set off in detail.

	4. Future topics

	I think :

	" OPEN-EDI > > EDI based on Pedi + EDI based on INTERNET +
			+ EDI based on VAN + EDI based on all Comm. Tech.
			+ EDI based on Future Tech.+....."

	So the OPEN-EDI security should resolve:

	1) Electronic notary and court system, i.e, a third party taking
	part in the activity of EDI transaction...

	2) Super-security, there are some users who want this service,
	how they do business with general users via OPEN-EDI...

	3) ....

	I stop here, by the way I am very interested in AI and EDI,
	modelling business is developed in SWG-3 on EDI/JTC1/ISO, it may be
	there is a OPEN-EDI RM like OSI RM in 1993. We are waitting....

	Liu
	===============================================================
	Liu Dahong CSELT Torino Italy
	Fudan@RZ8300.CSELT.STET.IT
Newsgroups: bit.listserv.edi-l