Re: Finding PKIX Servers!

[EKR <ekr@xxxxxxxx>]

"Phillip M Hallam-Baker" <pbaker@verisign.com> writes:
> > 	[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)
> 
> Which is why Eric and myself were integrating strong authentication 
> at the transfer/message layer. I still don't believe it is necessary
> to waste a round trip delay on a separate BIND operation.
Neither do I. 

> I don't see why an SSL implementation should have difficulty providing
> the necessary information to the application. Certainly I am familliar
> with several APIs which have provided the necessary information.
Correct. If you have to jump through hoops to get this information,
it's not because of a deficiency in SSL, but merely because of
your implementation. (Not that I haven't seen such implementations).
This is encouraged by the use of CGI, where pretty much everything
has to be stuffed in such variables.

> > 	[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!
> 
> I believe the TLS folk have been addressing this.
Not particularly well. There's a sort of consensus that a day
is about right, but it's not written down as a requirement.

That said, it can't be only a server setting. Both client and
server have to agree. To see why, realize that clients typically
store this information in memory, so there's got to be a way
for the client to not cache the information. 

-Ekr

-- 
[Eric Rescorla                                   ekr@rtfm.com]