RE: Finding PKIX Servers!

[Andrew Probert <AndrewP@xxxxxxxxxxxx>]

Disagree on some items..

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171



> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent:	Saturday, February 13, 1999 3:36 AM
> To:	ekr@rtfm.com; Andrew Probert
> Cc:	David P. Kemp; ietf-pkix@imc.org
> Subject:	RE: Finding PKIX Servers!
> 
	[Andrew Probert]  <snip>
> Actually, the idea we had was to remove the unnecessary work from
> the application. FTP's twin connection is far more complex for any
> application to manage than the HTTP 'idempotent request' model.
> Similarly the LDAP BIND operation achieves nothing of real value.
> 
> The 'complexity' of HTTP/1.1 is due to the caching model. No other
> retrieval protocol I am aware of has any caching model - the applications
> were too busy performing unnecessary operations such as BIND and UNBIND.
> Caching is not a particular burden on applications however.
> 
	[Andrew Probert]  I am not taking a dig at HTTP, merely stating a
partitioning example of functionality up into infrastructure, the work's got
to be done somewhere!

	Why do you think BIND/UNBIND is unnecessary?  


> Even with every 1.1 boondoggle, HTTP is by far the most straightforward
> protocol to implement at the application level.
> 
	[Andrew Probert]  My personal experience is that strong
authentication has been pushed down into SSL model, then I had to do lots of
backflips and spend real development $$ to intercept SSL strong
authentication, encode it as HTTP header vars and pass it back up to my
applications which were on top of HTTP.  (Live ecommerce site, now doing
20,000 transactions per month)

	Where's the integrated authentication in this model?
>  
> In retrospect I think that the confusion that HTTP ended concerned
> the interface between the authentication/authorization model (an
> application concern) and the transport connection. 
	[Andrew Probert]  Disagree, see above.
> For some reason it
> was assumed to be a good idea to keep TCP/IP sessions going
> indefinitely - instead of simply caching the access control context
> at each end.
> 
	[Andrew Probert]  Agree SSL is a good model and does cache access
control.  However, policy regarding timeouts of SSL sessions and generation
of new session keys is weak e.g. do I need to re-authentication every 10
minutes, 1 hour etc, normally a server side setting!

> Unfortunately some folk took this a bit far, maybe Eric can remember
> the name of that chap from Chicago who he used to work with who had
> the idea of downloding every image in a page as a separate TCP/IP
> connection. That was definitely a bad idea!
> 
	[Andrew Probert]  Agree..

> 		Phill