Finding PKIX Servers!

[Andrew Probert <AndrewP@xxxxxxxxxxxx>]

Comments  inline...
I have renamed this thread subject above to reflect subject the matter.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171
	[Andrew Probert]  <SNIP> 
> Here I would beg to differ.  There are several vendors (Entrust, Netscape,
> Microsoft, and Novell to name a few) which sell create-your-own-PKI
> software.  Using this software, any company can establish it's own
> top-level CA and set up their very own PKI.  Perhaps there aren't very
> many "roots" which are recognized by the world or listed in the major
> browsers, but I would hypothesize that there are several burgeoning PKIs
> which are known only within particular communities.  
> 
	[Andrew Probert]  .. and its quite OK for companies to run internal
DNS servers with proprietary / closed user groups, this is normal.  But when
one wants to play in the global network of Internet one adopts the Naming
rules and Registration Authorities etc that tie it all together, so the DNS
servers can find each other and exchange the commonly agreed information
objects (albiet there are only about 3 attributes in MX records).

	To me, the operational success of the Internet has been based upon
DNS (as a form of directory) and for example allowed SMTP mail to gain its
runaway success against stronger protocols like X.400, because
pre-registration of a company to the infrastructure allowed their mail
servers to be easily found, with minimal configuration by the sender's
company in a somewhat more promiscuous manner.

	By analogy, PKIX needs to be aware of these registration models and
emulate them .. to gain runaway success ..

> It is certainly an option to have a "PKI root CA registry."  But, do we
> really want to?  Is there a better way?  When an extension was added to a
> certificate to hold a location at which revocation information could be
> found, the registry option must have been considered and rejected.  Why
> was is rejected?  Perhaps Bob is right and a similar extension should be
> added for the location of the issuer's certificate.
> 
	[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.   The result of my lookup should be an
information object telling me the supported protocol(s) and services of that
CA.  

	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.
> <snip>
> 
> >> Unfortunately, the performance hit in this case would be even worse
> than
> >> in the 
> >> local directory. 
> >> 
> >	[Andrew Probert] Performance hits are relative.  If I have a
> >directory with a 30 millisecond response time to a single read, out of a
> >directory with > million entries, is this slow or fast enough?  
> >
> >	We need to provide some operational criteria about retrieval rates,
> >volumes etc required for Global PKI, then apply technology, partitioning,
> >cacheing strategies to suit the requirement.
> 
> Criteria would be a great thing to see.  But, I'm not sure that it helps
> when you consider some of the worst-case-scanrios.  My biggest concern is
> not a 30 millisecond retrieval time.  Instead, it is that the client may
> not be able to get to a server (or to the right server) for hours or even
> days due to network outages, protocol incompatibilities, downed WAN links,
> etc.
> 
	[Andrew Probert]  Certainly true, thats why true infrastructure has
service and availability levels and banks run branches on facilities other
than the Internet.  If the network is down, good old CRLs work well as they
can be cached, implicitly OCSP and other real-time lookups require a
real-time network.

> <snip>
> 
> >	[Andrew Probert]  I think it will be located in many / multiple
> >places.  So may as well start by defining its structure, then where to
> put
> >it etc is the second issue.  An ASN.1 structure, maybe PKCS#7?  What else
> do
> >we need to know about it?
> 
> As Francois Rousseau reminded me, an ASN.1 structure does exist.  It is
> called CertificateChain.  However, as I said in a previous email, I
> haven't heard of anyone using it yet.  Perhaps it has fallen out of favor?
> 
> 
> Tammy Green Carter
> tcarter@novell.com