Subject: RE: Scale (and the SRV record)

From: Alan Lloyd <[email-masked]>
Date: Fri, 30 Oct 1998 08:37:13 +1100

Comments in line.

> -----Original Message-----
> From:	Bill Burr [SMTP:[email-masked]]
> Sent:	Friday, 30 October 1998 2:34
> To:	Alan Lloyd; 'Phillip M Hallam-Baker'; Russ Housley;
> [email-masked]
> Subject:	RE: Scale (and the SRV record)
> 
> Alan,
> 
> I'm more than a little confused about what it is that makes X.500
> directories particularly OO things.  Is mashing the world into an
> X.500 DIT
> an object oriented approach?  There is a level of OO theology here
> that
> seems beyond my grasp.
	[Alan Lloyd]  X.500 defines an information model that uses
Object Classes, Attributes, in a distributed Named Tree. A X.509 CA is
in fact an auxilliary Object Class, A certificate is an attribute of an
object class. A CRL Distribution Point is an Object Class. A country
entry in the DIT is an Object Class. All things in X.500 are identified
with Object Identifiers and when instanciated in a DIB they are named.
Operations on X.500 entries are atomic - ie a property of object
processing.....

>   I think that we would want to think very hard about basing PKI names
> on
> domain names.  It seems desirable to make names in certificates more
> directly related to the "real world" than domain names and e-mail
> addresses
> often seem to be.  But, if we are dong a PKI for the Internet (and
> isn't
> this what PKIX is about?), then domain names and the DNS are the
> foundation
> that we build the whole Internet on anyhow.
	[Alan Lloyd]  
	The Internet has many layers in my book. The physical layer and
Lans and things, the Internet layer, the domain layer for machine based
names, and the application layer. DNS deals with Internet addresses and
Domains. Its history that domains relate to organisations. However, as
applications over the Internet evolve, then the higher level naming
constructs relate to real life. Ie. I have a name of Alan, but I may get
services from many internet domains eg Ozemail, Compuserve, MSN, etc. I
dont want 10 names because I use 10 domain based services.

> If the car, or perhaps the toll road operator, in your toll plaza
> example,
> doesn't have a domain name, or an IP address, why is it the concern of
> PKIX, which is, after all, an Internet standard group.  Is it even
> appropriate for the PKIX group to worry about things that don't relate
> to
> the Internet? 
	[Alan Lloyd]  Thats a view. I tend to think that the Internet
and Internet style technologies get used where they can. So why not
build things with the widest capability. Thats what the market wants.

> I have been saying for some time that don't know of anybody who has
> built
> an X.500 directory of a size that convinces me that it is a viable
> technology to base a US national PKI, or even a US Federal
> government-wide
> PKI on. I keep asking the question, where are the really big
> distributed
> X.500 directories? Particularly multivendor directories.  But I don't
> seem
> to get any answers.  What I hear are horror stories about the
> difficulties
> of getting any two X.500 products to work together.
	[Alan Lloyd]  
	No horror stories from us. 20 million entries, 1000s of searches
a second, distributed, multi master, etc We have very scaleable,
distributed technology - that also integrates LDAP servers, etc We are
very busy deploying X.500 into major corporate infrastructures who are
following the themes I described. Including those in the US. Please read
our WEB site. "Uses of Directory Services"

>   If the X.500 directory industry builds products that interoperate
> and scale
> well, it has done a really bad job of getting the word out.  
	[Alan Lloyd]  
	My view here is that the LDAP hype has done a really good job of
damaging X.500. However, now the LDAP hype has dissipated and reality
has set in we are left with a protocol that can only ACCESS a directory
service ? is twice as big as DAP and has half the functionality. In
addition, getting LDAP only solutions is proving to many that X.500 is
the way to go because of LDAPs NO distribution and a model that demands
Replicate everything to everywhere. LDAP has high operational costs and
gets to a point where it is unworkable.
	So LDAP accessed X.500 in my book is the way to go and is being
deployed globally.

>  Until now, I have also been saying, does anybody have a believable
> alternative to the mythological, pervasive X.500 directory service?
> It
> seemed almost a rhetorical question.  But I think perhaps Phill has
> outlined an alternative, that looks like it probably ought to work,
> and is
> based on something, DNS, that we know works well, scales well, and
> exists
> now. Moreover, we should be able to create the service we need
> incrementally, by just by adding servers as we need them, one at  a
> time.
> And, If I understand the proposal, all we have to do is agree on some
> simple naming conventions.
	[Alan Lloyd]  I am not against alternative proposals - its all a
question of how much effort and implementation goes behind it. Phills
solution has to be backed by all the DNS and PKI suppliers on this
planet and DNS then has to become secure - with signed operations,
mutual authentication, access controls, real life naming, and scale a
lot better and of course be easy to manage and follow Object Oriented
design. (does this mean turning DNS into X.500?) I would vote for that -
thats more X.500!

> That seems very, very appealing.
> 
> Once we accept domain names as the basis PKI naming, we are probably
> stuck
> with it forever.  Folks who aren't even on the Internet themselves,
> may
> wind up getting domain names for PKI purposes.  Perhaps the world
> would, in
> the end, be a better place if we waited for X.500 directory technology
> to
> mature, and then built a pervasive PKI DIT that has nothing to do with
> Internet domain names.  But solutions that we can get to work
> reasonably
> well now, with a fairly small effort, usually seem to beat arguably
> better,
> but more distant solutions.
> 
	[Alan Lloyd]  Thats a view but its not mine or the major
organisations that I work with. 
	I think the best way forward is for who want to build
distributed information systems for business purposes to use X.500 and
for those who want high configuration, low trust, high operational costs
and wait for 5 years go down the DNS route.

	Isnt it odd that X.509 is used for PKI and X.500 is discounted? 

	In addition X.500 solves a complex problem - ie. distributed,
object oriented, name based transaction systems that scale and provide
business information infrastructures. Yet as we have seen with LDAP,
trying to address a complex problem with a simple solution just does not
work. LDAP has taken three years to re invent 10% of a standard that was
released 10 years ago. But LDAP did prove that directorys are difficult
and complex and X.500 got most things right. Is this DNS approach about
to set off on the same track. Ie if distributed PKI is a complex problem
its going to take the same time?

	regards alan

> At 10:52 AM 10/29/98 +1100, Alan Lloyd wrote:
> >But why do this - this is yet more configuration and operational cost
> to
> >large systems  - and it means relating certificates and CAs to DNS
> when
> >they are in fact (from an OO perspective) just attributes of
> >objects/functions in real life. Ie a Car might have a key and
> >certificate issued by a traffic controller or toll plaza - to deal
> with
> >acqisition, identification and charging of the vehicle through Toll
> >sections on a freeway. Where does DNS fit here? The "DNS SRV
> configure
> >everything" route just seems to denegrate the , real life OO
> principles
> >of directories  - which are there so that we can get away from these
> >machine level plumbing issues.
> >
> >I think of CAs as functions and certs that are applied to real life
> >entities which are represented as attributes of objects in a business
> >level directory system.
> >
> >Bashing DNS records into certs and CA operations and validation paths
> >just complicates life with a higher operational costs and does not
> use
> >the utility of distributed information infrastructures. Its like
> >configuring every phone with every one elses phone number. When in
> fact
> >we use the distributed telephone network and its directory system to
> >avoid that.
> >
> >
> >regards alan
> >
> >> -----Original Message-----
> >> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> >> Sent:	Thursday, 29 October 1998 6:02
> >> To:	Russ Housley; [email-masked]
> >> Subject:	RE: Scale (and the SRV record)
> >> 
> >> Russ,
> >> 
> >> 	You are right of course! Note that the scheme I propose allows a
> >> certificate repository whose naming scheme is PKIX compatible to
> also
> >> be
> >> advertised. We might have:
> >> 
> >> 	__pkix._http._tcp.arius.com
> >> 	__pkix._ldap._tcp.arius.com
> >> 	__pkix._finger._tcp.arius.com
> >> 
> >> 	or even!
> >> 
> >> 	__pkix._verynewprotocol.arius.com
> >> 
> >> 	And since an SRV record is simply an MX record on steroids each
> >> can define server priorities and preferences.
> >> 
> >> 	What would then be required is a draft describing the naming
> >> conventions such a server would conform to and how clients should
> >> interpret the scope of the statement. __pkix._http._tcp.arius.com
> >> is essentially saying "look at the corresponding server where you
> >> will find a PKIX repository whose scope includes (all?)
> certificates
> >> issued which are bound to DNS names within the scope 'arius.com'."
> >> 
> >> 	Alan will have a directory there (we presume) as I would expect
> >> would most enterprises. There might be a move in favour of an HTTP
> >> service acting as a border directory and an LDAP server providing
> >> a more flexible, searchable service inside the enterprise.
> >> 
> >> 		Phill
> >> 
> >> > -----Original Message-----
> >> > From: [email-masked] [mailto:[email-masked]]On
> >> Behalf
> >> > Of Russ Housley
> >> > Sent: Wednesday, October 28, 1998 1:29 PM
> >> > To: Alan Lloyd
> >> > Cc: [email-masked]
> >> > Subject: Scale (and the SRV record)
> >> >
> >> >
> >> > Alan asks:
> >> >
> >> > > I need to be enlightened - How does one deploy a large scale
> >> distributed
> >> > > PKI without a large scale object oriented distributed (and
> >> protected by
> >> > > ACI, etc) directory system?
> >> >
> >> > Directory is the preferred certificate repository, but it is not
> the
> >> only
> >> > repository that will scale.  People have used FTP, Finger, HTTP,
> and
> >> other
> >> > mechanisms to distribute certificates.
> >> >
> >> > The PKI is not dependent on the deployment of a Directory, as
> these
> >> other
> >> > mechanism can be used until the Directory become widely
> available.
> >> >
> >> > Further, a trusted repository is not a requirement.  Since
> >> > certificates and
> >> > CRLs are signed, the repository cannot make undetected
> modification
> >> to the
> >> > data structures.  Denial of service is allways an issue; it is a
> >> > concern in
> >> > all of the possible repository alternatives.
> >> >
> >> > Russ
> >> >
> >> >
> >
> >
> Regards,
> 
> Bill Burr

---

From: Al Arsenault <[email-masked]>
Date: Fri, 30 Oct 1998 09:04:20 -0500

I tend to agree with Bill Burr on this one. Phill's proposal makes a lot of
sense, as long as we're willing to understand its limits. If we're building
a PKI for the Internet (supposedly, that's PKIX's charter), then it is is
wholly appropriate to think in terms of the Internet paradigm.  I have no
problem with names of entities being based on Internet things like domain
names, IP addresses, etc.  

This is one of the areas where the SPKI folk make sense.  There is not, and
will not ever be, a single, unified, global directory where everything has
a name that fits into the schema.  There are instead "directories" of
information that apply to a specific "domain".  In PKIX's case, it's the
information that applies to the Internet.  The namespace covers those
things that are important in the Internet context, and nothing else.  To
me, that's (right now), IP addresses, domain names, port numbers, service
names, user names/mailbox names, and maybe one or two other things. If the
Internet expands to cover toll plazas, then a naming space will have to be
developed for them, and after it's defined and standardized we can figure
out how to put the proper names in certificates.

(You can learn more about my views on this by reading the "naming" section
of the Roadmap document.  If you think it's wrong, please let Sean and/or
me know.)  

Now, a few specific comments:

<Snip>
>dont want 10 names because I use 10 domain based services.

AWA:  I disagree.  Last time I counted closely, I had at least six
different Internet access points, in at least five different domains.  I
use them for different purposes - one for working on this job; one for
working on this other thing; one for my use at home; one for shared use
with my children; etc.  I want them to have different names and different
certificates, with rights/limits/policies that reflect what I use them for.
 That's the way things work in real life.

That's what I like about using the existing Internet paradigms for cert
names, etc.  The account I let my children use is one that only allows
text-based e-mail, for example.  Picture attachments don't work; that's the
way the provider sets it up.  Thus, I'm not as worried about spam with
offensive pictures showing up in the mailbox - if such a message does make
it through, it won't be rendered as an image without massive human
intervention.  I'd like a certificate for this account that reflects its
capabilities and uses - e.g., since I don't use it for on-line purchases, a
certificate should have a financial limit of 0; and a low trust level.  For
other accounts, I'd like more "powerful" certificates.

I'm one of those people who think that the "ideal world" painted by some
(like, some of the DII designers) of one certificate per person is simply
wrong.  It may make their system design easier, but it doesn't reflect the
real world.  I want different certificates for the different things I do,
just like I have different physical pieces of identification for different
purposes.  Following an Internet paradigm is a good thing - just as I have
those different e-mail addresses and different service providers, I'd like
different certificates that match them.

>build things with the widest capability. Thats what the market wants.

AWA:  I disagree that that's what the "market wants".  Some people do, but
many share my views about separation (at least I think many do.  I'm
willing to be corrected.)

>design. (does this mean turning DNS into X.500?) I would vote for that -

AWA:  I disagre with these assertions.  DNS does not need to be secure,
unless what you're trying to stop is the denial of service problem. If
you're implementing the PKI properly, you can't get fooled into using the
wrong certificate just because DNS is defeated; the worst that will happen
is that you can't get the real certificate or CRL.  I'll post another
transaction today that explains my views on that in more detail.  (Yes, I
agree with those who argue that a denial of service problem that prevents
you from getting the current CRL can lead to a violation of confidentiality
or integrity, because you won't know that a key has been compromised.  The
threat also applies to OCSP services, unless you're operating in a mode
where "no response from the OCSP responder means reject everything".)

>	Isnt it odd that X.509 is used for PKI and X.500 is discounted? 

AWA - X.509 (and ASN.1) are used as a lingua franca of the PKI business.
X.509 is not used for its original, X.500-based purpose, which was actually
to control access to the directory for the purpose of limiting who could
modify entries.  We - the PKI community - needed a common terminology to
express things.  The X.509 syntax existed and seemed to be reasonably well
understood, and thus was adopted.  We could have easily gone down a SPKI
path and invented "S expressions" or some other similar thing, but that
seemed to be a waste of time.

							Al Arsenault

 -- my opinions only; no employer endorsement implied; etc., etc.,  etc.

---

From: David Boyce <[email-masked]>
Date: Fri, 30 Oct 1998 15:22:28 +0000

Al Arsenault writes:
>modify entries.

I'm sorry, Al, but it is factually incorrect to say that X.509 is not
used for its original, X.500-based purpose.  There is at least one
commercial implementation of X.500 which supports strong authentication
using X.509 certificates, and makes use of the fact for Access Control
purposes.

I'll grant that X.509 is being used beyond its original purpose, but
that's just a measure of its utility.

David.
-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
Email:	[email-masked]	Isode's WWW: http://www.isode.com/

---

From: Al Arsenault <[email-masked]>
Date: Fri, 30 Oct 1998 10:33:26 -0500

David,

	I was unaware of such use.  I stand corrected.  I'll change my statement to 

		X.509 is not used in PKIX for its original, X.500-based purpose.

			Al Arsenault

-- as if any employer would want to claim my opinions...