Subject: RE: FW: OCSP-X Internet Draft: Extensions to OCSP

From: "Linn, John" <[email-masked]>
Date: Thu, 14 Oct 1999 11:44:06 -0400

Stephen wrote:

> > I fully agree with the additional explanations you have provided.
> 
> 'Fraid I don't, not "fully" anyway. Like I said in 
> my previous mail, I'd still love to see a worked case 
> showing why its a good thing to use a server to 
> construct *and* validate *all* certificate paths
> that a client will *ever* use. Even for one 
> application, (e.g. TLS or S/MIME), I'm far from
> convinced that this is a good approach. Until
> I do see such an example, I'll be very sceptical.

I don't think that the viability or utility of offloaded validation is
something which would vary as a function of the application protocol(s) with
which the validated certificates are being used.  It's a design tradeoff
(probably more visible within PKI provider layers than in their consumer
applications) which incurs additional reliance on a central server but
reduces the amount of data which must be propagated to the clients in order
for validation to be performed.  

> 
> (Don't forget, this isn't free, we'd be creating
> a new highly attractive target for attacks, that
> also has to be highly available and widely
> contactable! Just imagine using this if you had
> a mobile IP connection. Yuk!)

If I understood earlier discussion on this thread correctly, Stephen had
already agreed about the merits of support for server-based path
construction.  If a client depends on its server for path construction
purposes, it's already accepted the dependency on server availability; given
this acceptance, I don't see a strong availability-oriented argument against
broader scope for the server-side functions.  By extending OCSP (already
accepted as an on-line service trusted for validation support purposes), the
proposal isn't adding an additional attack target, though it arguably makes
the existing target more attractive by broadening the impact of a successful
compromise.     

--jl

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Oct 1999 16:58:36 +0100

John,

> for validation to be performed.

Well, some of the arguments in SCVP and OCSP-X relate to
"footprint", "device complexity" etc. One of the questions
I'd want answered is how these arguments stand up in
real cases - if such protocols don't actually reduce
the footprint etc. when used in real applications
then the arguments fall.

There are also issues to do with mapping from 
application specific naming to certificates. E.g.
if I want to encrypt a mail for someone, do I
first get their cert, then check with the server
for a valid path, or do I send up the email
address? The answers to such questions may well
mean that the claimed centralisation of policy
isn't really there (in addition to also affecting
the footprint stuff again).

Another reason for wanting to see the effect
of this is that it changes the trust model
of any PKI consuming application, and given
the ways things are implemented, potentially
without the application being modified. I'm
concerned that replacing a current PKI library 
(which has path validation) with one with 
only remote path validaiton may open up 
new vulnerabilities. Maybe I'm just stupid, 
but I want to see what the consequences would 
be before recommending this.

Basically, in the absence of worked cases, we're
assuming a lot in saying that such protocols 
should be on the standards track.

> the existing target more attractive by broadening the impact of a successful

Not quite. Paths can be cached and re-used. A clever client
(of a path constructing server) could even relate them to 
build a "picture" of the PKI which is relevant for it.
The protocol I'd like to see would also have a "didn't
like that path, can you find another?" option for the
client to use. This means that the server doesn't have to
be trusted for much, nor need it be as "available" as
a putative SCVP/OCSP-X server.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com