RE: Finding PKIX Servers!

[Andrew Probert <[e-mail]>]

Comments Inline..

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  [phone]
Fax [phone]



> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[e-mail]]
> Sent:	Thursday, February 11, 1999 8:03 AM
> To:	David P. Kemp; [e-mail]
> 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.
> 
> 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. This is the 'directory
> dependent' model of PKI, I don't like that idea.
> 
	[Andrew Probert]  If your DNS is down and you dont have backup
servers, then the Internet is down.

	If you are doing online/realtime checking of CRLs etc, then if a CRL
server is down, PKI is down.  

	This is technology neutral, the issue is the same whether its a
directory server or any other form of server.
>  
> 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 [e-mail] so you can
> do email. URLs in the cert don't help in this case :-)
> 
	[Andrew Probert]  I think the current discussion is also centric on
having the cert and trying to find the CRL.  a)  You would be looking for a
Cert that matched the SubjectName, at the Issuer, all of which is encoded in
the X.509 Cert in the first place. Good fit. b) You would be querying a
server based upon IssuerDistinguishedName and Certficate Serial Number.
Extension required, but an easy one.

	Also, when you have a scenario where you want to route a query
server -> server -> server across the planet and trust the results, then its
also a good fit because strongly authenticated sessions are a part of the
protocol.

	As I understand Alan's Draft he is proposing extending the X.500
specification, to support OCSP-like functions.  This has the benefit of
inheriting a lot of features of X.500, as above, from mature deployed
technology.  Features are strong authentication between server - server,
client - server, flexible / extensible object model etc.

> 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, 
	[Andrew Probert]  Directories do exist now.  I know of CA's already
running them for certficiate and CRL publishing.  KeyPOST in Australia for
example.  Most CA vendors cite directory interoperability already.  CISCO,
Microsoft, Netcape, Sun and many more are promoting them.

> second if it did it might get tiresome doing a search of
> the entire directory space for an entry with the right attribute, 
> 
	[Andrew Probert]  Why tiresome, I would assume software does this
transparently for you and easily, if the namespace is rational and
connectivity is there.  Directories are a form of database, and if properly
design have Indexing strategies to ensure minimal resource usage.

> third
> X.500 is only standardized over the OSI network stack and not over IP,
> LDAP does not include the replication protocols being promoted as the
> basis
> for the 'global scalability' claim.
> 
	[Andrew Probert]  LDAP is alive and kicking.  Microsoft have
included it..  Netscape and many others are promoting it.

	Vendors have LDAP front-ends to X.500 backend servers, so an LDAP
client can transparently utilise the backend features of X.500.  This exists
today.

	DAP itself can easily run in workstations, if one wants tighter
control of what servers are doing, and contrary to Urban Myth, is in some
ways lighter than LDAP.  Besides people are putting strong authentication
into LDAP anyway.

	X.500 does run over IP, RFC1006 has been around for years to support
this, talk to all of the vendors!

> In conclusion I really don't know why we need the argument. We have
> established a function for directories in PKIX that makes sense. 
> 
	[Andrew Probert]  But .. other protocols are being invented, whereas
the alternate of extending existing products / protocols is avoided?  Why?
> We
> have revocation mechanisms which make sense. 
	[Andrew Probert]  Disagree.  Pasadena Ladies Club scenario, recently
discussed shows this is not the case.  Server to Server protocols have
immature.
> 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.
> 
	[Andrew Probert]  !
> 		Phill