Subject: RE: Finding PKIX Servers!

From: Andrew Probert <[email-masked]>
Date: Mon, 8 Feb 1999 09:47:55 +1100

Nothing like some heat for a discussion...

We could park the X500 thing as "jumping-to-solutions" and go back to
requirements ...

My thoughts run to business requirements like world-wide EDI trading,
shipping around contracts and documents, which require an integrated global
infrastructure.  I see other commentators requiring disparate, fragmented
pockets of PKIX servers with very loose relationships.  Closed user group
PKI is relatively easy.  Global PKI needs a lot of operational /
administrative thought.

1.  I think there is broad issue "Finding PKIX" servers in a global
interoperable scenario, which needs to be addressed. I personally don't want
hand code lots of browsers and software.  Is the agreed way to find a PKIX
server going to be via URL/DNS reference as an active / informed decision.
Requirements and discussion please?

2.  I have responded to the Pasadena Ladies Club scenario, where coding a
explicit reference into a cert to a bureau may cause an operational issue
forcing re-issuance of all certificates, which hopefully people should admit
is an problem?  This is a clear case where one needs a Naming Service to
provide a level of indirection between what's hardcoded into Certs and what
services can be used to find certs and crls.

3.  Does PKIX need the equivalent of a Naming Service / indirection of some
sort?

Sundry Comments below..

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

<SNIP>

> 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.
> 
	[Andrew Probert]  Sorry this is not the OSI debate again.  This is
about using approaches that are being adopted by major industry players as
we speak.  You could take a look at the planets biggest router manufacture,
CISCO, to see they are building Directory Enabled Networking (DEN) which is
certficate enabled.  You could take a look at Microsoft to find Active
Directory as a core part of their architecture.  You could take a look at
Sun's JDNI to see the Java view.  This is part of the industry 2 - 5 year
view of what the majors are doing.
	<SNIP>

> 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.
> 
	[Andrew Probert]  Wrong, the IssuerDistinguishedName of X.509 is
there in the certificate to be used for what it is, a globally unique Name
with registration authorities supporting country by country issuing of
names.  Is it going to be used for what it was designed?

	With regard to tying to the Numbering System, there are multiples of
numbering systems, the Internet, ISDN, NETBIOS, Phone Messaging (SMS) etc.
Are these services going to be certificate enabled?

>  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.
> 
	[Andrew Probert]  It is still a name service, whether it gets
deployed as a system is up to the requirements..

> 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.
> 
	[Andrew Probert]  Wrong.  
	Today, most products run on IP, whats the relevence of 'lower
levels' in this case?  

	DSP is not replication, it is online realtime routing of queries to
other online realtime servers.  

	Is PKIX going to invent a protocol for server-server communications
for OCSP servers etc etc. $$?

	DISP is replication.  

	The world *may* need replication of a name space to provide local
caching for higher performance and redundancy, if the business requirement
dictates it.

> 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.
> 
	[Andrew Probert]  DNS has very simple information, are its 'design
optimisations' good or bad for PKIX, needs to be discussed?	If the
requirements are discussed, then one can decide whether DNS is an
appropriate vehicle for extension.

	Particularly, if PKIX has requirements that require upgrading of the
planets DNS servers, this could be operationally destabiling and it would be
better to introduce a parallel service!

> 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.
> 
	[Andrew Probert]  Yep, I agree things like this are a good start to
answering the "Finding PKIX Server" requirement.  Is this simple solution
all we need?

> 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.
> 
	[Andrew Probert]  Citing techical failure of OSI is an incorrect
generalisation and is unsupportable, but I'm actually not an OSI bigot and
I'm not going to clutter this discussion with it..  

	As a pragmatist, bootstraping this to 'a directory service is not a
name service' flies in the face of what CISCO, Microsoft, Sun and others
seem to building directory infstracture for?

> 		Phill

---

From: "Perry E. Metzger" <[email-masked]>
Date: 07 Feb 1999 19:36:04 -0500

Andrew Probert <[email-masked]> writes:
> infrastructure.

No it doesn't. In fact, a global infrastructure is totally unneeded
for this.

This sort of claim shows up all the time among people who haven't
actually analyzed the real needs of real businesses. The truth of the
matter is that no global PKI is either needed or desirable.

When people trade, they don't care about identities. They care about
things like getting paid. That means you need a working banking
infrastructure, not a PKI. Public key methods can help assure a
transacting entity that its bank will pay it if it presents an
electronic draft, or to help a transacting entity order the creation
of such a payment, but such protocols are necessarily bilateral.

To put it another way: when you walk in to the book store to buy a
book, the store doesn't care a bit about who you are. They care about
whether they will be PAID, and knowing you have a valid cert tells
them nothing about that. What they need is a signed statement from their
accepting bank saying they will be paid -- and that doesn't require a
Global PKI to set up. It might use a PKI set up by the bank or credit
network for its own use, but it doesn't need a *GLOBAL* PKI.

Perry

---

From: Michael Sierchio <[email-masked]>
Date: Sun, 07 Feb 1999 23:25:40 -0800

> network for its own use, but it doesn't need a *GLOBAL* PKI.

There are two separate issues here -- if we're talking about
presenting a cert as part of authorizing a transaction,  the
merchant may very well be interested in identity -- certainly
in non-repudiation.  One of the current hazards of ecommerce
is that it is considered a "mail order" transaction,  and the
merchant may be liable in the case of fraud -- both by statute
and bank agreement.  So, that's the issue of identity, or
presenting a trusted credential (which is trusted because
the signer of the cert is trusted).

The other issue is one of maintaining directories of such
certs -- it has to be asked what purpose this serves.  It
is a form of publishing trusted public key values, perhaps?
A way for parties without prior agreement to exchange secure
mail?  Does this have anything to do with PKI in se?   It 
has no effect in the example described.

Cert directories,  however implemented,  are independent of whether
a hierarchical or web-of-trust model applies.   For the recipient
of a certificate the only thing that matters is if it is valid and
signed by a trusted party.  This has nothing to do with where we
find it.  A reference to a repository (other than that of the
signer) in the cert itself violates sense -- it doesn't matter.

---

From: "Perry E. Metzger" <[email-masked]>
Date: 08 Feb 1999 11:28:07 -0500

Michael Sierchio <[email-masked]> writes:
> in non-repudiation.

Again, no, this is not the case.

What the merchant wants is to get word back from the accepting bank
that they will be paid. The issuing bank wants to know that you are
who you say you are -- not the merchant.

> One of the current hazards of ecommerce
> and bank agreement.

That only happens right now because the issuing bank has no strong
authentication of the request to pay. Again, ultimately, the merchant
does not care who you are except for things like the ability to do
marketing or customer service -- and just knowing who you are tells
them *nothing* about whether they will be paid or not. Their real need 
is for a digitally signed message from the accepting bank saying "you
will be paid $100", not for some vague knowledge that somewhere out
there some bank has issued you a cert.

> has no effect in the example described.

Cert directories are totally unneeded in the model I'm describing
because the issuing bank can just store the cert (or even a naked
public key) with the account information.

Perry

---

From: Michael Sierchio <[email-masked]>
Date: Mon, 08 Feb 1999 15:12:05 -0800

> public key) with the account information.

Agreed on that count.  I suppose that what I was trying to say is
that the signer of a cert (or issuer of a keypair,  maybe a bank?)
has an authoritative role.  A directory is just a collection, a
means of publication,  and has no authoritative role.

A business enterprise may find an internal (LDAP) directory of certs
useful for DH key agreement for IPsec, for example.  But there is
no need for a GLOBAL directory structure, AFAICT. 

Other than arguing against the need for such a global directory
infrastructure,  do you have philosophical or aesthetic problems
with it?

---

From: "Perry E. Metzger" <[email-masked]>
Date: 08 Feb 1999 18:20:47 -0500

> infrastructure,  do you have philosophical or aesthetic problems

Since such an infrastructure would be very expensive and hard to
manage, I'd say that the lack of need or use probably argues on its
own against its implementation.

Perry