Re: Z39.50 and SSL

Bob

Why cant you just listen on both the secure and insecure ports? - also
even though some of your records dont need to be encrypted - is there any
harm (except for the overhead) of just encrypting all of the data?

mark


On Mon, 14 Aug 2000, Robert Waldstein wrote:

> 
> > 
> > Securing Z39.50 was discussed at the Belgium ZIG, and the consensus was that
> > security should be at a different layer to Z39.50 rather than built into the
> > standard. 
> 
>   I have mixed emotions about this.  I agree running Z39.50 over a secure
> socket is the easiest solution to deploy, and thus should be strongly
> considered (actually - I do think this will be the method used, so the below
> is just making sure the issue was raised).
> 
>   But I guess I have the same problem with this as with authenticating in
> a Z39.50 init APDU (which I also support).  THe problem is that on many
> servers you need different levels of security.  THat is, my EXPLAIN records,
> and for that matter most of my records, and travel freely and can be swiped for
> all I care.  However, some records, or parts of records do need encryption.
>    So I am all ready, for the day I serve data outside the Lucent firewall,
> to encrypt only those record aspects I consider requiring security. If this
> is done using SSL-type methods, this means bouncing the user to a different
> server (I guess via some sort of Z39.50 URL redirect).
> 
>   Both methods have their advantages, suspect I would go with encrypting
> the desired record parts if I was designing the world from scratch.  But 
> given the difference in gaining acceptance/deployment of the two methods
> suspect going with the SSL approach is what will happen.  But thought I
> should voice my concern that I am not confident it is the best method...
>    bob
> 
> -- 
> Robert K. Waldstein                Email: wald@lucent.com
> Bell Laboratories, Room 3D-591     Phone: (908) 582-6171
> 600 Mountain Avenue
> Murray Hill, New Jersey  07974
> 
>

Received on Monday, 14 August 2000 10:33:53 UTC