Subject: RE: Scale (and the SRV record)

From: Alan Lloyd <[email-masked]>
Date: Thu, 29 Oct 1998 10:52:22 +1100

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

---

From: Bill Burr <[email-masked]>
Date: Thu, 29 Oct 1998 10:33:31 -0500

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.

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.

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? 

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.

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.  

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.

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.

>> > all of the possible repository alternatives.
Regards,

Bill Burr