Subject: RE: Finding PKIX Servers!

From: Andrew Probert <[email-masked]>
Date: Fri, 12 Feb 1999 09:16:13 +1100

Comments inline ..

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

> -----Original Message-----
> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Friday, February 12, 1999 3:11 AM
> To:	Andrew Probert; David P. Kemp; [email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
> > 	[Andrew Probert]  If your DNS is down and you dont have backup
> > servers, then the Internet is down.
> 
> Which is why folk have backup servers and as a result the Internet is
> always up. 
> 
> > 	This is technology neutral, the issue is the same whether its a
> > directory server or any other form of server.
> 
> No, it is not. DNS supports a very minimal name translation service. As a 
> result replication is easy and does not introduce major interdependencies
> between servers.
> 
	[Andrew Probert]  PKI has complex data objects and requires more
complex interaction between servers, availability issues are similar,
service features are more complex!

> > 	As I understand Alan's Draft he is proposing extending the X.500
> > specification, 
> 
> PRECISELY.
> 
> Alan is not talking about X.500. He is talking about Alan.500, an unproven
> protocol with ZERO operational experience.
> 
	[Andrew Probert]  .. based upon extension of an existing protocol
and products with lots of experience.  The same comment can be said of OCSP,
ICAP etc. etc.  

> > > 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.  
> 
> But the namespace is not rational. The name space is IANA, partitioned
> over X.500 DN's.
> 
	[Andrew Probert]  No, Namespace of certficates is incoded as an
X.500 DN.  The namespace of the transport system is IANA.  You are mixing
two things that shouldn't be mixed.  See my previous postings about issues
of DN->URL assumptions.

> > > 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.
> 
> And neither have yet agreed on a common replication protocol - except
> that neither wants to use the X.500 replication protocols.
> 
	[Andrew Probert]  See a previous posting.  DISP is replication.  DSP
is online query routing, multicasting to servers etc, which is particularly
useful to the topic in question.

> Standardization of server-server protocols in the same domain of authority
> is rarely urgent. I doubt that many enterprises will be installing 
> heterogeneous directory systems. Certainly interoperability between
> 'X.500' products from different vendors is less than seamless.
> 
	[Andrew Probert]  I agree its not urgent, unless you want global
interoperability.

> I don't see a need therefore to use LDAP or X.500 as the transfer
> protocol for OCSP. Not only is HTTP considerably more efficient,
> the much vaunted data model and replication protocols are a poor
> match for the particular needs of an online status protocol.
> 
	[Andrew Probert]  Well .. HTTP is an overlay of simple verbs GET,
POST over Telnet, with some service controls and it is certainly a simple
protocol.  OCSP is a service overlaid.

	Alans suggestion is to overlay a CRL lookup service over X.500
DAP/LDAP protocol, which would automatically inherit the existing technical
infrastructure to route these queries.  This can be gained by incremental
development over existing working protocols.  I see your logic above is to
defer the design issue.  His is to address it now!

	As to efficiency, Urban Myth again, when you compare apples to
apples, you find that computers can decode structures and pointers faster
than they can decode / parse text and delimiters.  Take a look at
application / decoder efficiency when you cite transport protocol
efficiency.

> 	Phill

---

From: EKR <[email-masked]>
Date: 11 Feb 1999 16:14:51 -0800

Andrew Probert <[email-masked]> writes:
> protocol. 
I don't know where you get the idea that HTTP is an overlay over
TELNET. It most certainly is not. HTTP runs over a TCP connection,
as does TELNET, yes, but that doesn't make HTTP an overlay over TELNET
wny more than FTP is. RFC-854 specifies all sorts of stuff that HTTP
doesn't have any notion of, including some terminal behavior, control
information, etc.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]