RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Comments in line. Agree with some of the comments - but like to add.

----------
From: Stephen Kent
To: Al Arsenault
Cc: 'ietf-pkix@imc.org '
Sent: 10/22/98 4:51:41 AM
Subject: Re: A different architecture?  (was Re: certificate path
services  [ was RE: NEW Data type for certificate selection ? ])

snip
One of the biggest features of a well designed PKI is that it embodies a
distributed security model that scales through simple replication of
static
data, a problem we know how to solve. 


Alan: However a major weakness in any system occurs when one replicates
data - particularly when that data forms a linkages to a point of trust
- and in the path there are other objects that may or may not exist (eg
CRLs) that could be placed in these paths in non uniform ways...
EG LDAP -  one of the major deficiencies cannot ask for master data from
a CA directory ie. If a CRL has been placed in the master but not yet
propagated to replicas, then a client could consider the cert being
validated - valid if it (without its knowlege - accesses the replica).

(ie. why talk of trust and how one achieves trust in a distributed and
replicated information system and then use a protocol that has so many
untrusted deficiencies???? eg. LDAP. 



 It also has the property that to
spoof the identity of an end entity, one ought to have to subvert the CA
that issued the cert to that entity, although sloppy cross certification
and bad choices for PKI structure can make this situation worse.

Alan: Bad PKI designs come from weaknesses and complexities in the CA
and the related client information model and service interaction
software - as one adds complexity the components that work with an ill
defined and variable information model, then all things get into a mess.
EG LDAP - no system service model, add and extension here there and
everywhere. Outcome - LDAP is not universal anymore - an operational
mess.

Limited scale systems, complex clients and weak/variable CA information
models is what we have. Its better to have consistency in service and
place trust in the implementation of that service. There is no point in
discussing trust in theoretical Objects and certificates and the
processes that might happen in someones CA or "cert server".




The notion of cert validation servers is thus very disturbing.  

Alan:
If a client goes to a CAs directory to get a cert in the path and the
directory provides the wrong one and therefore user to user transaction
is invalidated - then denial of service happens. 
Something - somewhere in the system has to be trusted. And in my book
its the implementation that is trusted not theoretical models.

eg. I can build a highy trusted directory system that does cert
matching, has bullet proof access controls, has trusted processes that
generate valid flags from processing CRLs...for the client.

OR I could  write sloppy, bug ridden, fragile process that serves no
purpose in terms of trust.

OR I could promote a protocol to a server without any distributed,
directory relevant CA information model and say that solves the problem.


In the above the following observations MUST be made.
Using good directory technology, with sound information services to
support CA functions provide scaleability and measureable trust models.

Using bad anything .. provides no trust

Having a protocol to a server without any notion of the CA function and
the directory support that CAs need or any notion of scaling or how it
deals with multiple CA domains or the complexity of the client,  only
generates problems.

IE.
IMHO Talking of trust in the CA/X.509/directory environment without any
reference to implemtation and system design qualitative characteristics
becomes an endless debate - without resolution.

regards alan


Steve