Subject: RE: finding services : DCS, OCSP, Timestamping, ..

From: Alan Lloyd <[email-masked]>
Date: Fri, 15 Jan 1999 09:09:30 +1100

Stephen, just a few comments - but it seems we are almost agreeing :-)

> -----Original Message-----
> From:	Stephen Kent [SMTP:[email-masked]]
> Sent:	Friday, 15 January 1999 2:52
> To:	Alan Lloyd
> Cc:	[email-masked]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Alan & John,
> 
> >Thanks for that John. My comments on OCSP also mentioned the use of
> this
> >extension in that in a domain agile and global wanderer envrionment -
> >and to deal with errors or failures in OCSP servers - it would be
> better
> >if the certificate did not cryptographically tie its validation
> server
> >to the users details. ie. if a "named" OCSP server failed the cert
> >cannot be validated however, if a fault tollerant and replicated
> >directory backbone service - that supported many OCSP validation
> >processes failed, then an alternative validation process can be dealt
> >with in the system. Its a question that OCSP seems to want to fix the
> >OCSP server details in the cert, whereas a directory enabled OCSP
> >approach with-distributed and replicated OCSP server funtions offers
> >better utility and scaleability without the need to crypto-bind
> config
> >info into certs.
> 
> I think we have to pay close attention to the specific services in
> deciding
> what constitutes a good way to find appropriate servers.  For
> revocation, I
> think the CA has an obligation to state how/where is makes revocation
> data
> available, because the CA is the ultimate authority for this data.
> Thus,
> for example, we can bind into each cert one or more CRL distribution
> pointers. If a CA chooses to delegate that authority to some 3rd
> party, it
> needs to do so in a highly secure fashion. 
	[Alan Lloyd]  
	The X.500 CA related data structures do provide some of this.
The  CA entry can have  its CRL DP  reference pointing to a directory
entry of a third party that has the CRL DP with signed CRLs in. My usual
point here is that it is easier to add a new data structures to a
directory service to solve the prolem than hand config info objects with
server knowledge all over the place.
	I think the issue is that its back to the approach of hand
crafted knowledge of where things are and configuring them into
everything or using the naming/knowledge/authentication/ACI regimes of
directory services and appyling these in the CA issuer/subject and CRL
DP objects.

	The directory service provides exactly that - named items in  a
distributed environment. So why try to emulate that service in data
structures with manual effort.

> One could include a set of OCSP
> server pointers, which would permit a more robust mechanism, though at
> the
> cost of cert size growth.
> 
> For a directory system to provide a highly secure way to discover such
> delegation, I think we must have some way for a CA to post a signed,
> dated,
> attestation that provides the equivalent info.  We currently have no
> structure for such data.  Also, there is a potential performance
> tradeoff
> here as well, i.e., use of a directory server seems to add another
> level of
> indirection to the process, thus requiring more network accesses, ...
	[Alan Lloyd]  Dont think of the directory as a server, but as a
distributed service. If things are all over the place then by definition
the network traffic through a directory service will be the similar or
less than the client making the same requests to independent items. Its
just that with the directory service, the directory service has the
distribution mechanisms and knowledge all built in. And in this case all
the client does is access the single interface of the directory service
with requests for named items. Whereas with the client identifying with
bits of config info from many data structures (eg. like the WEB mode of
working), just means that all such structures are hand configured and
the client has many connections to retrieve all these fragments. And in
addition, each time the client connects to these fragmented servers, it
has to authenticate itself. Yet more hand crafted configuration,
replicated passwords and/or and key management.
	Ie. The latter model is more complex, key management starts to
get N*N, its harder to manage and has more network traffic and
interaction from the clients perspective.

>  In contrast, use of a timestamping service doesn't seem to be so
> closely
> tied to a specific cert and so it is not clear that a pointer needs to
> be
> included in a cert for such services.
	[Alan Lloyd]  agree

	As a bit of an after thought and thinking about OCSP-directory
integration. In a multi domain environment where domain a users send a
signed transaction to users in domain b. And domain A uses convetional
CA/CRL processes for its own validation , but domain B choses to use
OSCP validation processes, the certificate server configuration approach
will have problems. The point is that a user or a CA in one domain may
not know or care (at that level) the validation techniques of another
domain as this will be a system design and policy issue.
	It would be very hard for a CA issuer in any domain to foresee
where the cert would be propageted to and what servers (and the server
configs and mechanisms) it would be validated on. Naturally very small
systems dont have this issue.

	I still quite like that the approach that a receiving client of
a cert, presents it to its "local" validation process (via OCSP) and
that server, can off load that to other OCSP validation servers if it is
necessary -  and these OCSP servers use the distributed information
services of the directory to find CRLs or validation items or references
to where CRLs might live. ie the business policy for within domains and
between domains is engineered as directory information objects (signed
or otherwise) according to trust requirements.

	thoughts are welcome

	regards alan 

> Steve

---

From: Stephen Kent <[email-masked]>
Date: Sun, 17 Jan 1999 17:10:32 -0500

Alan,

Well, we may be getting closer, but I'm not completely sure.

>structures with manual effort.

I'm confused by this example. If I attack the directory and change the CRL
pointer to a different entry, this would be a serious security problem,
unless the CRL in the other entry is signed by the CA.  If so, then what
difference does it make in which entry it is stored?  Is your suggestion
that the layer of indirection provided by the directory is important, even
if the CRL is signed by the same entity in any case?

>interaction from the clients perspective.

We certainly disagree here.  Nothing in the example I described changes the
key management to an order N**2 problem, from an order N problem. We
certainly are NOT introducing passwords into these systems; we are trying
to replace them with certificates.  I still don't see how the number of
transactions does not grow as a result of putting more data into the
directory.  Your comment is rather vague on this point; perhaps the intent
is to say that "if we distribute all of the admin data need to communicate,
then  what's a few more items?"  I understand that analysis, and might
agree with it in general.  But, if we pursue that path, we will definately
create a more fragile system, by requiring a greater number of directory
accesses and requiring that the directory services be highly available.  I
think your point is that this is a good tradeoff if it results in an easier
to manage system, overall.  Here too I think we need to look at specific
cases; sometimes the tradeoff may be appropriate, but in other cases we may
be creating unacceptably fragile systems.  Maybe my work on the Trust in
Cyberspace report for the NRC over the last 2 years has heightened my
concerns over fragile infrastructures :-).

>systems dont have this issue.

Validation for certificates is a standard process, codified in X.509 and
PKIX. It is not a purely local policy matter.  Local policy comes into play
with regard to how to make use of the data extracted from the certificate.
Also, some aspects of the validation process are under the control of the
CA issuing the certificate being validated, e.g., marking extensions with a
critical bit or choosing to use CRLs vs. OCSP.

>or otherwise) according to trust requirements.

Here is where we disagree again, though I appreciate the attraction this
holds. As I noted some time ago, if one offloads all of the validation
process, in order to construct a very thin client, then the opportunities
for subverting validation for a potentially large number of subscribers is
greatly increased. The local validation server becomes a prime tagret for a
wide range fo attacks, and its required high availability makes denial of
service an even greater concern.  With cacheing and normal, client
validation capabilities, an inability to access a directory for a CRL may
be an annoyance, but may not be fatal in many instances.  However, if one
pushes off all of the processing, ...

Steve