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

From: Alan Lloyd <[email-masked]>
Date: Wed, 3 Feb 1999 10:21:22 +1100

Comments in line.

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Wednesday, February 03, 1999 2:53 AM
> To:	Alan Lloyd
> Cc:	[email-masked]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Alan,
> 
> 
> Let metry to condense our debate to spare the rest of the list from
> reading
> lost of text:
> 
> 1. You state that "in addition to signing data, we can also place
> >"some" trust on the distributed authentication and access controls of
> >the directory system. Particularly when the user or certficate reader
> >has been requested to do strong authentication on the directory
> service
> >itself to read the CA entry. We do deal with trusted directory
> systems
> >you know."
> 
> You also say "And in the case where this extra strengh is needed we
> can do
> >strong auth and signed ops on the directory service.. with DAP - you
> >know the protocol thats half the size of LDAP with twicw as many
> feature
> >including trusted signed operations."
> 
> This line of argument seem to ignore the fact that the vast majority
> of
> successful, detected attacks against computers of any sort are
> effected
> through exploitation of design, implementation, or management
> vulnerabilities that are NOT prevented through the use of cryptography
> for
> communication security, including signed directory operations.  This
> characteristic has been true for the last 20+ years and is well
> documented
> through analysis of CERT advisories.  A vast set of directory
> resources
> provides an obvious target and if one were to adopt the approaches you
> promote, which place ever greater reliance on these resources, the
> value of
> these targets grows enormously.  That is why signing data that is
> stored in
> any repository, and not relying on secure management of a set of
> repositories, is a preferred security paradigm.
> 
	I got confused with your logic in this  debate  - are you
agreeing with me. 

	If you want to talk threat to large scale systems I will. And
yes all threats to systems are generally operational ones (cutting
cables, power, sand in the fuel line etc.)
	In military we have a term - a big system is a big target. Eg.
the Internet, the Telephone network... However, that does not stop them
being built. So we tend to follow through threat analysis with risk
assessment, risk avoidance and risk acceptance. After all, even  living
is a risk :-).

	To debate signed data as being the preferred paradigm and saying
putting that in a secure or insecure large scale repository ( a
directory service)creates an operational risk - (which is obvious) so
dont build one... seems a pointless statement. For the cryptographically
protected information to have any UTILITY AT ALL in a large scale
system,   it has to be provided by something in a way that can be found
by those distributed users who wish to use it.

	Also note  and please do note that a directory is a distributed
information function - that provides greater utility than conventional
databases. One of these can be used in a Top secret env, many can be
used privately on a restricted network or thousands can be used on low
value, high volume transaction , global service systems. The
trust/cost/risk/integrity and threat issues of these  are all
operational/project/deployment issues.. and have very little to do with
with the details of a signed cert or cRL (although they do factor in the
debate).
	ie do I use Type 1 algorithms to sign certs but leave the power
switch for the CA visible on the road side.
	 
> 2. Later, in response to my observation that the phone system is not a
> great analogy for the global, distributed directory system you
> envision you
> say "We need to talk re the two paradigms. Many people find the phone
> system/directory system paradigm very useful. As for infrastructures.
> They
> tend to be in fact very big systems>- by definition. If OCSP wants to
> be
> big - it will become an>infrastructure - but if it wants to be big it
> will
> have to be supported by a big distributed information base... some
> thing
> like a directory
> service. Otherwise its hand carved..."  This response seems to ignore
> all
> of the details of my argument of why the phone system is a poor
> analogy,
> and the vast evidence of the fragility of this and analogous
> infrastructures.  I refer you to the recent "Trust in Cyberspace"
> report by
> the (U.S.) National Academy of Sciences, which makes similar point.
> Of
> course, as a member of the committee that wrote the report, I may be
> prejudiced :-). Also, your comment about the growth of OCSP seems to
> focus
> on ONE way of using it, namely having a network of TTPs act as oracles
> for
> queries about certificate status or validity.  This is not the only
> model
> for OCSP, and it is not the one that prompted the development of OCSP.
> If
> CAs operate OCSP responders for the certs that they issue, there is no
> need
> to create the sort of highly vulnerable infrastructure you seem to
> propose.
> 
	See conmments above. Again the logic confuses me. I will always
agree that one can build a small system without an infrastructure. :-)
In fact a small system is not an infrastructure :-))) ... One can put a
dozen OCSP servers around a CA - not a problem. 
	However if one want to run a business level system with
tranactions and users that are verified for business products/ access
with profiles  for global use- what is the information model, who/what
administers it, how is it distributed and deployed, what is the
busines's product, customer and inter-oganisation acquisition strategy
and what are the information policies and procedures that deal with
that....These are the system issues..

	Where does this "information" stuff live - in a commercially
optimised way....

	Big systems are infrastructure, by definition. And threats are
always on them. This does not mean that because of theoretical ideology
we will always build small ones. PKI systems and directories means that
infrastructure, large scale PKI systems can be built ( may be not for
everything) but there is a big market for them - because they are big
systems - and as everyone knows, the engineering processes in small
systems eg LDAP is a lot different to big ones (distributed directory
services)

> OCSP servers operated by CAs, vs. outsourcing OCSP services for a CA
> to a
> TTP, don't concentrate vulnerabilities, they distribute them.  So,
> depending on the model one envisions, OCSP may be fine froma  security
> standpoint, or it can be made into another disaster waiting to happen.
> 
	Operational and system design issues... Can debate this for
ever, if all we have to argue with is a protocol spec and a signed data
item.

> 3. In our discussion about the nature of OCSP support, you state "How
> many
> OCSP servers will be needed for 100m users. What is the information
> system
> that supports this?"  Again, this seems to confuse your model for OCSP
> use
> vs. other approaches, as noted above.  We both agree that distributed
> directories are a good and necessary part of most PKIs; the issue is
> whether we should use them in a fashion that creates new
> vulnerabilities.
	See above. 

> 4. I stated that "What it seems to boil down to is an assertion by
> you that directories will be ubiquitous, very fast, ultra reliable,
> and sufficiently secure so that we should abandon the crypto-integrity
> model upon which X.509 is based." You responded "Thats it. Got it in
> one.'
> well, it is nice to be clear on this point. However, you have not
> provided
> a set of coherent, comprehensive arguments to presuade me to believe
> that
> your assertion. Insetad, the argument seems to be that of course it
> will
> happen becauise it must happen to enable the future and because the
> use of
> such serves is being actively "promoted."  This does not sound like an
> architecture to me; it sounds like a marketing pitch from a seller of
> directory technology and/or services.  This is the PKIX WG mailing
> list.
> We try to develop standards for PKI technology that based on sound
> architectural principles, period.
> 
	Agree - standards are good - I have been involved with standards
for ISO/ITU for 20 years, the military for 8, transport and traffic
management for 4 and the IETF for about 8. However please note that  a
set of ASN.1 data definitions is not a system architecture.
	A standard eg. X.500 is 20% of a product which is 20% of the
effort in a deployable system.

	Let me get these points over.
	1. X.509 is part of X.500 - why. X.500 - the directory service
supports the distributed authentication process and domain level access
controls which are needed in a distributed business environment.

	2. A directory service when applied to systems provides an User
and Information Services approach to system design by definition because
thats what a directory holds...  the User/Subsciber information base as
well as the data models and objects for the products/services being
used.

	3. When one designs around a protocol and a database, one is
designing a communication and data system. When one uses a directory
service approach one is designing a distributed information SERVICE
which is full scaleable, has built in protection capabilities, a common
information model, a common information management model and a common
security paradigm.
	When applying a directory service to a system design one needs
to take a totally different approach to that design to that of using
databases and protocols. Because a directory service  is more than that.
IT system design approaches HAVE evolved to meet the business and
information management requirements of the global user and customer. It
is wrong to compare this approach with a protocol/server/database
approach.

	4. If I wanted to pitch the product -  I would not be talking
large scale system issues, development approaches and standards.

	5. The Internet and its technologies is being integrated with
voice systems and being applied to commercial use. The customers dictate
that a system solution must be applied on this. Inventing more protocols
has its place - but there is a lot more work going on around the
Internet than that.

> 5. Finally, in response to my complaint that your proposals would
> degrade
> the security of PKIs, you respond "No infact we are enhancing the PKI
> with
> the reality of deployed directory systems. A PKI without a business
> purpose
> and information and service deployment scaleability will be an orphan
> technology."  This does not respond to my point.  It deflects the
> question
> by asserting, again without substantiation, that yours is the
> ONLY/BEST
> approach to achieving scaleability, and it makes the highly
> questionable
> claim re the reality of deployed directory systems.  We don't conduct
> debates on this list based on assertions about the inevitability of a
> partciular solution; we debate proposals based on their merits.
> 
	Please define what you mean by scale and approaches to scale. If
one is in the PKI and information services business and writing
standards for PKI - which must have a named - globally named information
components what is the database/protocol that you use that does "scale"
- 

	why does the phone system have a directory service?
	why are all the PKI vendors on this planet embracing
directories?

	what is the debate here. 
	Is it small systems can be designed in way that makes them small
	and that some systems can use a protocol/database approach - but
weve done that for 20 years and these do work but have scaling issues
	and that when one builds a secure information service that needs
to scale globally - it will be an infrastructure and use directories and
that the approaches to this are different to that of traditional
methods.

	regards alan

> Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 Feb 1999 18:14:25 -0500

Alan,

 <deleted text from my point #1>

>	I got confused with your logic in this  debate  - are you

Not at all, and I don't think the argument was unclear.

>cables, power, sand in the fuel line etc.)

First, a threat is defined as a motivated, capable adversary" so the use of
the term "threat" here is inappprpriate.  Second, we have simple
counterexamples to your assertion, e.g., the massive, distributed switch
failure suffered by AT&T due to a propogated software error.  Benign
failures for such systems may often be of the "backhoe induced fading"
variety, but malicious attacks need not follow the same profile.

>assessment, risk avoidance and risk acceptance. After all, even  living

Yes, but some of us are better at risk avoidance than others :-). However,
smart designers try to avoid creating unnecessary risks in systems through
over concentration.

>by those distributed users who wish to use it.

Now it's my turn to question the logic of your statements. Please stick to
responding to specific points, not issuing general, fluffly pronouncements.

>switch for the CA visible on the road side.

Oh please, no more "directories as panacea" rhetoric.

<deleted text of my point #2>

>systems eg LDAP is a lot different to big ones (distributed directory

No, big systems are not necessarily infrastructures. "Infrastructures" are
systems that serve other systems in an underlying, supportive fashion.  A
big system built for a given application, which is an end unto itself, is
not an infrastructure.  But we are taking about PKIs, so I don't mean to
dwell on the erroneous defintion above.  However,  I again find that your
responses seem orthogonal to my comments, i.e., they do not refute my
criticisms, but rather make more high level statements in support of your
position.  This is a waste of my time, and that of the mailing list members.

>ever, if all we have to argue with is a protocol spec and a signed data

if we were debating this would be true, but you're ducking my points, so
it's hardly a debate :-).

<deleted text of my point #4>

>set of ASN.1 data definitions is not a system architecture.

We agree on what is and is not an architecture, but that's about it.  We
can compare records re standards participation, if you wish.  I didn't do
much in the ISO/ITU arena, but I've been an active IETF paritcipant since
its inception, served on the IAB for a decade, chaired two WGs in the 90s,
and authored a handfull of standards tracks RFCs over the last decade.

>controls which are needed in a distributed business environment.

Yes, X.509 was created to support string authentication for X.500, but
X.509 lives outside of X.500.  Many v3 extensions were added to compensate
for the fact that certs and CRLs will not always be retrieved from
directories and because reliance on directory access controls, vs. signed
data structures, is a dangerous design approach.  For example, we now mark
CRLs to indicate which ones are for CAs vs. users, rather that relying on
the indications provided by the directory attributes in which they were
stored.

>well as the data models and objects for the products/services being

and the relevfane of this to our discussion would be ....

>information model, a common information management model and a common

One certainly cannot assume uniform security from a distributed directory
service of a large scale, even if the paradigm is uniform.  But the rigor
of implementation and management significantly affects the quality of the
security afforded by the service, so commonality of the model is not
sufficient.

>is wrong to compare this approach with a protocol/server/database

Sorry, but this sounds like more fluff to me.

>large scale system issues, development approaches and standards.

Why not?  Systems are composed from products.

>has its place - but there is a lot more work going on around the

Since I work for a firm that is offering such integrated services I am well
aware of these issues, but again this seems irrelevant to the meat of the
discussion.

<deleted test from my point #5>

>components what is the database/protocol that you use that does "scale"

One can design scaleable solutions in various ways.  One may emphasize
highly distributed, largely independent components with minimal
interdependence.  One also may emphasize a tightly integrated, highly
interdependent design approach.  You seem to be proposing the later, I am
advocating the former.

>	why does the phone system have a directory service?

"A directory service?"  We don't have one, we have many.  What's the one
number I call to get a phone number for any subscriber anywhere in the
world?

>	why are all the PKI vendors on this planet embracing

Joint marketing opportunities produce increased revenues with lower costs,
irrespective of the merits of the jointly marketed products/services :-).
On a more serious note, users want solutions, and PKI solutions often
require a directory, though not usually a globaly accessible one, nor one
in which we create unnecessary vulnerabilities.

>that the approaches to this are different to that of traditional

Nice rhetoric, but you persist in not addressing specific criticisms
directly, so why bother?

Steve