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

From: Stephen Kent <[email-masked]>
Date: Wed, 4 Nov 1998 23:02:52 -0500

Alan,

>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).

I'm not an LDAP fan and I keep observing that one does not always require
directory systems to support a PKI.

>(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.

See comments re LDAP above.
>
> 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.

Aw, come on now.  Stop using LDAP as a strawman to make more complex
directory systems seem like the only (preferred?) answer. Complex cert
models are bad, I agree, but they are bad whether one has to deal with them
in fat clients or in fat, fancy validation servers.

>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".

We have poor examples of PKIs now, but I reject the view that we cannot
make them better, or that we have to fundamentally change the model
underlying X.509 to address these problems.

>
>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.

If a directory provides the wrong cert in response to a READ, this is
immediately apparent to the client and thus the bug/attack can be detected.
Implementations must be correct to make things work, but good
implementations of an insecure model are not necessarily better than
mediocre implementations of a secure model.

>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.

Maybe, but I am not convinced.  We may have good client implementatins and
bad ones.  Even bad ones may have to be attacked individually to subvert
the security for a lot of users, whereas a successful attack against a good
server that many users rely upon would be much more devastating, and that
makes it more worthwhile to attack it.

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

You could write it, but I may not choose to buy it. :-)  Be careful here;
if you push too far one might ask whether it's worthwhile having a high
quality cert validation process at all (distributed or centralized) if all
of the clients are running a vulnerable OS anyway!

>OR I could promote a protocol to a server without any distributed,
>directory relevant CA information model and say that solves the problem.
>
What protocol?  OCSP?  We're still working on the scope of the model, but
if the OCSP responder is the CA for the cert in question, we have a fine,
simple, model.

>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.

"measurable trust models?"  What metrics do we use?

>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.

Well, we can terminate this debate now, to avoid falling into that trap.

Steve

---

From: "Steve Russell" <[email-masked]>
Date: Thu, 5 Nov 1998 08:33:02 -0500

General comments on this particular thread:

Can a PKI operate and survive without a directory?  Yes.

Could PKI, as envisioned by most companies, be deployed without a directory?
No.

One of the most fundamental issues that we are dealing with is certificate
and CRL retrieval because it deals with the deployability of PKI rather than
its mathematical validity.  To mandate the implementation of a certain style
or type of directory would be wrong.  However, to not formalize the
standards so that the process of retrieving CRLs and certs from a directory
would be interoperable would be just as wrong.

There are some major headaches that we inherit when we start looking at
directories such as does the directory need to be trusted, what is the
access protocol, how is the personal data in the directory protected, how
are multiple non-related directories referenced by a PKI client.  I won't
attempt to address all of these in this mail, but...

Having worked a lot with X.500 directories, I would rather have a limb
removed than mandate X.500 as a foundation for PKI, but some customers will
choose to do that.  Looking at a set of the sample PKI applications I do
think that accessibility via LDAP is necessary.  Having said that, DNS is a
much better model for the quick retrieval of specific data because of it
simplicity and very loose referral relationships.  The structure of a DNS
address is also much easier to process within an application than the
umpteen levels that are commonly implemented in X.500 and LDAP DITs.  The
question is do we place the certificate in DNS and maybe slap (pun intended)
a LDAP server on the database or do we design a separate structure which has
a similar format and build up the relations over time...

May I suggest a compromise?  Make one change to DNS to add a new record type
which is a directory server, however, the certificate repository would
remain separate from the DNS database.  When a user references 'foo.com' to
attempt to find a certificate or a CRL the appropriate DNS would refer them
to appropriate directory server much like MX records work today.  This also
allows users the flexibility to transparently maintain internal directories
separately from publicly available directories based on which DNS their
users reference.  It has the advantage of potentially providing a much
richer set of data storage and access controls (through LDAP or X.500) than
would ever be feasible to build into DNS.  Lastly, it resolves a potential
paging problem that would exist with DNS when requesting a large number of
certificates or CRLs.

Comments?

Steve
_______________________________________________________
Steve Russell
Chief Technologist
Public Key Strategies, Inc.
_______________________________________________________