Re: EDI over http?

[chucks@xxxxxxxxxxxxx (Chuck Shih)]

Matthew,

No I don't think you are missing anything here. My point was that
whether we adopt a "real time SMTP" as Carl Hage suggested, or use HTTP
POST over SSL, some amount of server side implementation is required. I
thought some of the discussion was assuming that you get HTTP over SSL
for "free", when you use a web server.

Matthew James Gering wrote:
> 
> > Using HTTP POST over SLL does require client to server authentication,
> > but there is no reason why the client side can't actually be a server -
> > we therefore have server-to-server authentication using SSL.  Am I
> > missing somethnig here??
> 
> No, I don't think so. For SSL, one side initiates the session, but the once
> established it is symmetrical, no client/server distinguishment. I thought
> the original poster did not realize that SSL support X.509 certificates on
> either end -- although I'm not sure if the below handshake shows that.
> 
> Although that says nothing about the protocol underneath SSL. HTTP is most
> definitely client/server -- but yes, a /server/ per say could act as a
> client. Also, SSL is not tied to HTTP, there have been attempts to use SSL
> as a secure channel for other protocols.
> 
> Hopefully I am not bastardizing the specs, but that is my understanding
> anyway.
> 
>         Matt
> 
> > >-----Original Message-----
> > >From:        chucks@xxxxxxxxxxxxx [SMTP:chucks@xxxxxxxxxxxxx]
> > >Sent:        Monday, June 23, 1997 12:24 AM
> > >To:  Matthew James Gering
> > >Cc:  ietf-ediint@xxxxxxx
> > >Subject:     Re: EDI over http?
> > >
> > >Matt,
> > >
> > >I'm looking over the SSL3 protocol spec and there definitely is
> > >something client side and server side about it. For instance this is the
> > >possible message flow defined for the SSL handshake:
> > >
> > >
> > >CLIENT                     SERVER
> > >
> > >ClientHello --------------> ServerHello
> > >                            Certificate
> > >                            CertificateRequest
> > >                            ServerKeyExchange
> > >            <--------------
> > >
> > >Certificate
> > >ClientKeyExchange
> > >CertificateVerify
> > >change cipher spec
> > >Finished------------------->change cipher spec
> > >    |                        Finished
> > >    |                            |
> > >    |                            |
> > >    |                            |
> > >    |                            |
> > >    |                            |
> > >    V                            V
> > >
> > >   application <-------------> application
> > >      data                       data
> > >
> > >
> > >Matthew James Gering wrote:
> > >>
> > >> SSL is end-to-end session encryption -- there is nothing client-side
> or
> > >> server-side about it.
> > >>
> > >> If you are referring to the X.509 certificate on the server used for
> server
> > >> identity verification, X.509 certificates are also supported on the
> client
> > >> for client identity verification and security login by most web
> servers.
> > >>
> > >>         Matt
> > >>
> > >> > Since EDI is generally server to server, doesn't adopting a http/SSL
> > >> > transport also imply that the client side http/SSL implementation be
> > >> > done on the server side as well?
> > >> >
> > >> > For instance, the browser will implement the client side SSL
> functions
> > >> > such as server certificate authentication, etc. In the situation
> where
> > >> > there is no browser, and a server needs to send the EDI file to
> another
> > >> > server, doesn't the sending server need to implement the http/SSL
> client
> > >> > side dialogues?
> > >> >
> > >> > Does this mean that companies would need to go to the expense of
> > >> > creating a "customised" http/SSL server to support client side
> > >> > functionality?