RE: Finding PKIX Servers!

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Comments in line - to  more incorrect statements

> -----Original Message-----
> From:	Phillip M Hallam-Baker 
> Sent:	Thursday, February 11, 1999 8:03 AM
> To:	David P. Kemp; ietf-pkix@imc.org
> Subject:	RE: Finding PKIX Servers!
> 
> > I'm at a loss to understand Phill's suggestion to use DNS SRV
> records
> > (instead of just putting the CA's URL in the cert itself), and Alan
> > Lloyd's suggestion that putting a URL in a cert would require an
> > army of administrators.  Running a directory tightly coupled to
> > the security management infrastructure requires the army; running
> > a loosely coupled directory/repository named in a URL is easier.
> 
> The URL in the cert method is fine but some folk have a problem. For
> example
> the revocation service may be other than the CA originally specified.
> It may
> not be possible to access the URL specified in the Cert when the time
> comes
> to rely on it.
	Absolutly - in addition if a URL is tied to a server - and not a
named object in a directory system - that may be replicated for
redundancy and local context reasons to ensure serviceability, then
using URLs would be restrictive. 


> My interpretation of Alan's post was that he is proposing much more.
> He wants to weld the PKI to the directory so that if the Directory is
> down it is certain the PKI will be as well.
> 
	What if DNS goes down, or the cert database, or the (anything
else you want to name) goes down.   

	Can I repeat this yet again 
	A PKI is a function  - a directory is a function - they are
applied with products into an operational system according to the system
design and business requirements.
	ie if  I remove the old fashion database from the PKI function
and replaced it with a directory on the same platform - and this was not
connected to the world - the system has the same construction and
limitations , but using the directory service instead of a traditional
RDB  - means that it can use the standard distribution, replication and
authentication/ACI features to connect with other PKI and directory
processes as the system scales - in a uniform manner.

	A database approach is a restricted approach - a directory
approach - for the same cost - offers functional and information
scaleability.


>  This is the 'directory
> dependent' model of PKI, I don't like that idea.
	Thats because I think you are not seeing the utility of
directory systems correctly.


> The 'directory linked' approach I believe is sensible uses the
> directory,
> but only for purposes that are a good fit - i.e. locating parties -
> One problem is how you obtain the cert in the first place given that
> you probably are looking for a Cert which maps to fred@xyz.org so you
> can
> do email. URLs in the cert don't help in this case :-)
	Perhaps we are looking for a Cert by the DN = subject name in a
directory system.

> According to Alan you go to the Global X.500 directory system and
> perform a lookup. This approach only has three problems, first no such
> directory exists, 
> 
	wrong perception - a directory is a function that is being
applied - There will never be ONE and only ONE directory service. eg we
have a public telephone system - we also have many private networks for
voice communication...
	One tends to build systems - that have a sphere of influence -
and the naming and service provisioning issues are tied to that.

> second if it did it might get tiresome doing a search of
> the entire directory space for an entry with the right attribute, 
> 
	directories dont actually do that - operationally (real world
again :-)) - and this comment is a pointless comment.
	directories are about defined schema with reasonably defined
accesses - if you dont apply this then  limit parameters
(size/time/context) get applied by the system.
> third
> X.500 is only standardized over the OSI network stack and not over IP,
> 
	this is wrong, wrong and wrong - I think all those who have ever
dealt with directory systems at all KNOW that DAP, DSP, DISP and LDAP do
run over TCP/IP
> LDAP does not include the replication protocols being promoted as the
> basis
> for the 'global scalability' claim.
	? well we all know about the limitations of LDAP. That is why
the industry is using it for access only and X.500 for the core systems.

> In conclusion I really don't know why we need the argument. We have
> established a function for directories in PKIX that makes sense. We
> have revocation mechanisms which make sense. I don't know why we need
> to conflate revocation of authentication credentials and the
> directory.
> Authorization credentials might be another matter, but those are not
> currently in PKIX scope.
> 
	But these are in the scope of those who are designing systems
that incorporate PKI, directories, messaging, information management,
and end user services. Just because the PKIX  group explicitly has not
dealt with distributed and mutual authentication across large scale
information systems using X.509 - it does not mean that a) it wont be,
b) it wont take input from those that do or c) that those who deal with
the bigger issues of PKI - dont want to understand these things in an
open forum.

	I think first and foremost - is not useful to put statements on
this list (for debate) that are so wrong.
	Secondly it must be seen that PKIs without directory capability
at the functional level will hit scaling issues by definition.
	And that there are those around this planet (lots of us) that
understand directory systems at many levels, and PKI systems at many
levels who see the value and utility in applying both - Big customers
have recognised such integration and benefit.

	To debate the integration of two functions with incorrect
statements about one of them is absolutely pointless.
	regards alan
> 		Phill