Subject: Re: Huge CRLs

From: "valicert" <[email-masked]>
Date: Fri, 17 Sep 1999 12:49:51 -0700

Alistair,

Ambarish is not at work today, so may not reply early; so let
me try to address your comment, as best as I can.

I use my experience of X.500 distributed directory design to
discuss the security relationships between OCSP and
information management techniques like CRTs. Just as X.500
has a security procedure for securing client access, so PKIX has
OCSP. Just as X.500 has another security procedure (DSP)  for
server-server cooperation, so we use CRTs. X.500 has
additional secured protocols for DIB partion
replication, also. CRTs also facilitate partioning,
replication, and failure-tolerant partition
synchronization as a core  value.

As Phil said the other day, a client can access
an OCSP responder, and a not standardized "backend" thing
at the server talks to the source of status information.
This design of this backend thing and its integration
with OCSP has security  implications concerning the integrity
and fidelity of the status information delivered by the OCSP
channel.

In one ValiCert design of a distributed repository,
the CRT-based "backend thing" addressed the needs
for confirmed integrity of the server-server channel
used to distribute status information to the autonomous
OCSP servers.  It was assumed that these
servers would need to respond in an offline mode to queries,
and would not necessarily maintain a connection to the
source of status information.  (This is just
one mode, note. Other customers have different
connectivity and chained-OCSP
responsibility requirements.)

Two customers specifically required that we show
we had technical means deployed to show
the "fidelity" of the status values delivered at the
OCSP server . It was necessary to provide
assurace that the OCSP response would be consistent
with a given CRL source, and no other, at the
the various OCSP access points. This was critical
to their distributed security model. They did
not want the CA's more uptodate status db to
signal to clients; they wanted the
CRL, and only the CRL-status to be signaled. (This
is just one mode, note. Other knowlegeable
customers have different requirements.)

Hope this addresses your question.

-----Original Message-----
From: Grant, Alistair <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: Ambarish Malpani <[email-masked]>; 'Daniel Lanz'
<[email-masked]>
Date: Friday, September 17, 1999 9:53 AM
Subject: RE: Huge CRLs

>Hi Ambarish,
>
>You wrote:
>     Basically, with OCSP, the responder needs to have its key
> available online to sign responses (you can mitigate this risk to
> some extent by having a proxy between your responder and the rest
> of the world, but it is still an issue). So you need to make your
> responder available for people to talk to, but if anybody ever
> manages to break into your responder and get access to your private
> key, your whole OCSP response system is open to compromise.
>
> With CRTs, you can acctually have the Tree Issuer be separate from
> the CRT responders. The Tree Issuer has access to your CRT private
> key and can create new CRTs, which it then distributes to one or
> more CRT responders (which don't have the highly trusted private
> key), which actually provide the CRT responses.
>
>I think I must be missing something, even with CRT's the OCSP responder
>still has to sign its response, so the situation does not seem to be
>improved by the use of CRT's.
>
>
>Cheers,
>
>Alistair Grant
>Phone: +61 3 9727 8912
>Mobile: +61 408 565 080
>Fax:  +61 3 9727 3491
>E-Mail: [email-masked]
>
>> > -----Original Message-----
>> > From: Daniel Lanz [mailto:[email-masked]]
>> > Sent: Tuesday, September 14, 1999 7:57 AM
>> > To: 'Ambarish Malpani'
>> > Cc: [email-masked]
>> > Subject: RE: Huge CRLs
>> >
>> >
>> >
>> >
>> > >CRTs are a proprietary method to implement OCSP in a more scalable
>> > >and secure way.
>> >
>> > Ambarish,
>> >
>> > How do CRTs make OCSP more secure?
>> >
>> > Regards,
>> >
>> > Dan Lanz
>> >
>> >
>> >