Subject: RE: Finding PKIX Servers!

From: Alan Lloyd <[email-masked]>
Date: Fri, 5 Feb 1999 13:27:48 +1100

some comments

> -----Original Message-----
> From:	Bob Jueneman 
> Sent:	Friday, February 05, 1999 11:07 AM
> To:	[email-masked]; Tammy Carter; [email-masked]
> Subject:	Re: Finding PKIX Servers!
> 
> Andrew,
> 
> [snip]
> > 
> 	[Andrew Probert]  Yep.. I agree that an extension could be used
> because the current extension is a Uniform Resource Locator, which
> constrains the reference to a WWW style protocol http://, ftp://, (and
> even
> ldap://).  This current extension presupposes / forces certificate
> validation paths into the infrastructure of URN/DNS/IP/ARP resolution
> and
> protocols.
> 
> 	Alternatively, when I already have the IssuerDistinguishedName,
> if
> there was actually a PKIX naming resolution protocol in place I can
> simply
> look this up to find the servers.   
	No all one needs is a "port" on a directory service  and use the
name to find the issuer - which should I know the comms addresses or
URLs of the issuer. I do not know the wire identifiers or the switch
numbers of the telephone system - I use a phone number for the target
recipient....
	In directories ...  I would use the name to get to the target
object - an entity which is an organisation, an organisational unit, a
device, a role or a person that performs the CA FUNCTION.

	I think of CAs as a function of a real world entity represented
in a directory as an object that INCLUDEs the properties of a CA.

	It seems that some think of CAs a servers with URLs

	The difference is: directories provide an information services
paradigm to this requirement

	directory less approaches provide a protocols and URLs
technology approach - scaleability, application, operations and
management overheads do not seem to be addressed - 
	whereas the directory approach deals with this..

	snip

> 	I suggest that X.500/DSP is stable and mature for online relay
> of
> queries.  X.500/DISP addresses some replication / caching issues.  The
> protocol is already certficate / crypto aware.  It can be accessed by
> front-end protocols of LDAP, DAP and Web/LDAP gateways.
> 
> [RRJ]  Ok, I think we are getting somewhere.
> 
> But...
> 
> Suppose the relying party is the legendary little old lady in Dubuque.
> 
> All she wants to do is be sure that amazon.com is really who they say
> they 
> are.  Let's imagine that she has an LDAP client available through her
> generic 
> browser -- what does she do?
> 
> She is knowledgeable enough to check the certificate for Amazon before
> 
> placing an order, and finds that there is one, but being a little
> suspicious, 
> decides to check on who issued it, and clicks on "Issuer".  Yup, there
> it is,
>      US
>      "RSA Data Security, Inc."
>      Secure Server Certification Authority
> 
> Great! Now her LDAP server knows exactly where to go (assuming that
> this was 
> the next certificate in the chain, and not the root.)  Go to the US,
> and search for 
> RSA Data Security, Inc. in the US's X.500 directory!  Maybe, just
> maybe, it will tell
> you what the DNS name, port number, etc., are that LDAP would have to
> use to 
> do anything.
> 
> Does she have to be preconfigured with the LDAP server address of her
> ISP or portal?
> What if the Issuer is not a well-known public CA, but the Pasadena
> Ladies Garden
> Club,  which hands out certificates to the members once a year, and
> then shuts down
> the server.
> 
> All the members of the Garden Club know that they use an external
> repository to maintain
> their CRL list, but how does the LOLFD know that?  Or even AOL?
> 
	This is a very heart waming story  - but am totally convinced
that little old ladies wont do anything where they have to understand
the stuff that gets discussed on this list.
	Its best if they bash on something with their pension book and
it all happens -  And we know it  will just happen better with a
directory service there.

	eg. I gave my mum my book on OSI and X.500 for xmas some years
go - she got to the part that dealt with DOP and DSA entry updates
across DSA boundaries and multiple superior references and then gave up
... QED :-)))

> The more I think about it, the more I like the idea of including a URL
> for the issuer's
> directory in the certificate itself.
	I dont. Simply because its unnecessary.

	X.509 is part of X.500 - ie the names in a cert should be
entries in the directory system that supports the certficate service.
The only reason you need URLs is the fact you are not using a directory
service. And we all know we need directories for the internet and
telephone and PKI systems to scale and be well managed.

	regards alan
> Bob

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Fri, 5 Feb 1999 12:41:45 -0500

This discussion starts to sound as if it not about PKIX, or even
directories. The real agenda appears to be resurrecting OSI, or at the
very least attempting to promote the version of history in which OSI
failed for purely political reasons.

This discussion really has nothing to do with the design of PKIX and
is ultimately counter-productive since many lurkers following the 
discussion will have recieved a very negative opinion concerning
X.500 and interpreted this to mean that directories generally are out
of favour and not as is the case certain (rather eccentric) applications
thereof.

Any chance this discussion can be taken up on [email-masked]?

> 	No all one needs is a "port" on a directory service 

You do not just need a port on any old directory service, it has to be 
a global NAME service with naming consistency. Furthermore to be usefull 
in the proposed application it has to tie to the numbering infrastructure 
of the Internet.

X.500 satisfies neither condition. It is a directory and NOT, repeat NOT
a name sytem at this point. X.500 was originally intended to provide a
name service but grew into something different.

Suggesting widespread deployment of X.500/DSP ignores the fact that the
lower level OSI protocols are an abject failPure at this point. The rate
of deployment is actually negative at this point. The world does not
require a directory replication protocol for replication of a name space.

DNS is widely deployed on a global scale, DST ain't. If it were 
necessary to redesign DNS I would not consider DST as a substitute.
There is no evidence that DST is more scalable than DNS and plenty
of reason to believe it to be less scalable - DNS has the advantage
of applying highly domain specific optimizations which a general
purpose directory system cannot. Nor is the approach taken by OSI
particularly different in structure so as to make me believe it to
be capable of greater scalability.

The solution to finding PKIX servers is very simple. Write a profile
which defines what information a 'PKIX server' must provide via a
specific transport. Advertise a PKIX server providing information 
corresponding to the xyz.net domain via an SRV record of the form
__pkix._ldap._tcp.xyz.net.

A directory service is not a name service. Failure to understand
this was the principle reason for the technical failure of OSI. We
should not make the same mistake.

		Phill