Subject: Finding PKIX Servers!

From: Andrew Probert <[email-masked]>
Date: Fri, 5 Feb 1999 09:44:32 +1100

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
> [email-masked]

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 04 Feb 1999 17:06:36 -0700

Andrew,

[snip]

[RRJ]  Ok, I think we are getting somewhere.

But...

Suppose the relying party is the legendary little old lady in Dubuque.  
All she wants to do is be sure that amazon.com is really who they say they 
are.  Let's imagine that she has an LDAP client available through her generic 
browser -- what does she do?

She is knowledgeable enough to check the certificate for Amazon before 
placing an order, and finds that there is one, but being a little suspicious, 
decides to check on who issued it, and clicks on "Issuer".  Yup, there it is,
     US
     "RSA Data Security, Inc."
     Secure Server Certification Authority

Great! Now her LDAP server knows exactly where to go (assuming that this was 
the next certificate in the chain, and not the root.)  Go to the US, and search for 
RSA Data Security, Inc. in the US's X.500 directory!  Maybe, just maybe, it will tell
you what the DNS name, port number, etc., are that LDAP would have to use to 
do anything.

Does she have to be preconfigured with the LDAP server address of her ISP or portal?
What if the Issuer is not a well-known public CA, but the Pasadena Ladies Garden
Club,  which hands out certificates to the members once a year, and then shuts down
the server.

All the members of the Garden Club know that they use an external repository to maintain
their CRL list, but how does the LOLFD know that?  Or even AOL?

The more I think about it, the more I like the idea of including a URL for the issuer's
directory in the certificate itself.

Bob

---

From: "Tammy Carter" <[email-masked]>
Date: Fri, 05 Feb 1999 11:20:11 -0700

I don't understand.  Several of the people on this list seem to believe that the way to find a CA is via some kind of advertisement.  However, what I don't understand is why?  Bob's suggestion of using the certificate to contain information about where to find the CA seems to work AND it is more similar to the mechanism that we already have for finding revocation information.  

Why do we want to come up with something different?  Is there something wrong with what we already have?  This debate must have been waged before, and must have been lost.  Has something changed in the world since then?

Tammy Green Carter
[email-masked]

---

From: Alan Lloyd <[email-masked]>
Date: Mon, 8 Feb 1999 09:10:36 +1100

I am amazed at this- - this is so wrong.

> -----Original Message-----
> From:	Phillip M Hallam-Baker 
> Sent:	Saturday, February 06, 1999 4:42 AM
> To:	Alan Lloyd; 'Bob Jueneman'; [email-masked]; Tammy Carter;
> [email-masked]
> Subject:	RE: Finding PKIX Servers!
> 
> 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.
> 
	No its not. I wonder why major PKI companies are using directory
services - Please answer this if you want to respond. Because the
majority of out her that are applying directory services to big PKIs
would like a answer.
	Just keep the thought that businesses are using the internet and
providing services on the internet. And at these levels they dont want
"more dedicated servers" and "fragmented information management".

	I think most accept that OSI is a seven layer reference model
that most people use.
	See Cisco wall charts etc.

> This discussion really has nothing to do with the design of PKIX and
> is ultimately counter-productive since many lurkers following the 
> discussion will have recieved a very negative opinion concerning
> X.500 and interpreted this to mean that directories generally are out
> of favour and not as is the case certain (rather eccentric)
> applications
> thereof.
> 
	Well please for the lists sake tell us how you attach
certficates to business entities and identify certificate authorities as
information - in a common scaleable information environment.

> Any chance this discussion can be taken up on [email-masked]?
	Perhaps the reverse is true. Perhaps holding onto the old way
protocol/rdb approach to systems that has existed for 30 years when the
industry wants large scale information services might be a little flat
earth.

> > 	No all one needs is a "port" on a directory service 
> 
> You do not just need a port on any old directory service, it has to be
> 
> a global NAME service with naming consistency. 
	Oh dear. I have a phone - a mobile phone. It has a number, I
wander the world and use a "port" - in the abstract sense - on the
global mobile telephone system. 
	With a directory service - which they may be many of - run for
different service reasons, they manage and service a name space for that
service which is distributed. I have my entry in that directory service
by which it recognises me. And when I connect to that directory service
(via a "port" ) the distributed  authentication processes verify me. (as
per the phone service does) -

> Furthermore to be usefull 
> in the proposed application it has to tie to the numbering
> infrastructure 
> of the Internet.
	Oh dear - WE have our X.500 directory services providing
DNS/DHCP/RADIUS front ends (from a famous supplier) for ISPs  - simply
because the directories permit their service provisioning to scale -
heard that one before! (See DEN)

> 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.
	See above.
	Well its was designed as a name based directory service - read
X.500 1988 and look at the standard schema
	Its best to read the standards before making such comments.

> 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.
	I think OSI is a reference model in which protocols are
positioned. eg 802.x, HDLC, etc
	TCP - happens to be Transport Layer - IP is Networking Layer

> DNS is widely deployed on a global scale, DST ain't.
	Whats DST?
>  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.
> 
	There is a major difference between a name to IP service - and a
directory system that does mutual authentication, has information
doctrine to the extent it has - a  common information management model,
the replication and distribution, the access control regimes...and deals
with business level information systems etc, etc..

> 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.
> 
	Thats one way - and its a much lower level perspective of the
knowledge issue about large scale PKI systems. ie.  It does not add PKI
related information and their functional aspects to real life entities
(as represented in a business level directory service by information
objects)

> A directory service is not a name service. 
	Oh dear - a directory service relies on information being
organised by name - and interactions on such information is through the
use of system knowledge of that name space.

	A directory - a service that organises information by name so
that names can be related to information.

> Failure to understand
> this was the principle reason for the technical failure of OSI. We
> should not make the same mistake.
> 
	It is very obvious the biggest mistake ever made was considering
that X.509 formats would make a scaleable service without a directory
system. I never understood this view. If one reads X.500 on total and
the part X.509 which relies on the functionality and process of mutual
authentication through a distributed name based directory system - How
could one ever expect it (the format of 509) to work on its own.

	Thats like taking the wheel off a car and then expecting to
drive the wheel to work. :-)

> 		Phill

---

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

Comments inline...

Andew Probert

> From:	Tammy Carter [SMTP:[email-masked]]
> Sent:	Saturday, February 06, 1999 5:20 AM
> To:	[email-masked]; Bob Jueneman; [email-masked];
> [email-masked]; [email-masked]
> I don't understand.  Several of the people on this list seem to believe
> that the way to find a CA is via some kind of advertisement.  However,
> what I don't understand is why?  Bob's suggestion of using the certificate
> to contain information about where to find the CA seems to work AND it is
> more similar to the mechanism that we already have for finding revocation
> information.  
> 
	[Andrew Probert]  I dont propose advertisement.  A structured
approach is fine.  The proposed method for finding revocation works for some
of the simple scenarios, but ..

> Why do we want to come up with something different?  Is there something
> wrong with what we already have?  This debate must have been waged before,
> and must have been lost.  Has something changed in the world since then?
> 
	[Andrew Probert]  The Pasadena Ladies Club scenario doesn't work
under one scenario!   Is it acceptable to re-issue all certficates if one
changes revocation servers, bureaus etc?  

	It is acceptable to have revocation servers rely on DNS/URL
resolving name-> IP address.  What are the implications of vulnerability to
DNS?

	To go with the current scenario ...

	*  If I am a CA, am I better off coding
ocsp://123.123.123.123:pppp/parms in certs, as a hardcoded IP reference to
my revocation server with a hardcoded 'port', as a way of proofing my
customers against a denial of service attack on their nearest DNS server
(with a cheaper-net ISP whom I hardly trust)?  

	*  If I do this and then I need to I change my IP addressing scheme,
I've got to recall all certs and re-issue!

	*  What if I have the newest / next generation revocation server
that has just been lobbed in as Draft-xx, which solves lots of CRL problems
I discovered in the last month or two, but its a totally new protocol and I
want to turn it on.  Do I reissue certs for this, or wait a year for them to
expire!

	In my view a Naming Service helps the network, devices and apps
configure themselves.  It needs to be a stable service that is not changing
too much.  They don't need to be accessed all of the time, for example local
workstations can cache what the know (rules are needed of course).

---

From: Andrew Probert <[email-masked]>
Date: Mon, 8 Feb 1999 13:10:08 +1100

Andew Probert

> From:	Perry E. Metzger [SMTP:[email-masked]]
> Sent:	Monday, February 08, 1999 12:42 PM
> To:	Andrew Probert
> Cc:	[email-masked]
> Subject:	Re: Finding PKIX Servers!
> 
> 
	[Andrew Probert]  <SNIP> 

	The point, probably oblique, that I was trying to make is that for
PKI to work it needs infrastructure of Naming and transaction routing
(EFTPOS analogy).. and of course a driving business case.  

	In our country, its all CardNumbers over SSL and application of MOTO
rules to Internet tranding.  The risk of GETTING PAID hasn't been addressed.
I can agree SET is not yet relevant.

	<snip>

> > 	[Andrew Probert]  Banks dont need global PKI, as they will set up
> > their own.  Others do, for lessor things.
> 
> Who? For what?
> 
> 
	[Andrew Probert]  I personally think there are many applications for
PKI that are not related to GETTING PAID i.e. digitally signed documents for
non-ecommerce such as Health and Medical, Access Control systems, EDI
ordering (proof of authority etc) .  Therefore, the operational scenarios
are important.  So your question above is a vital one!

> Perry

---

From: Alan Lloyd <[email-masked]>
Date: Mon, 8 Feb 1999 13:01:55 +1100

And mine - in line.

> From:	Andrew Probert 
> Sent:	Monday, February 08, 1999 11:09 AM
> To:	[email-masked]
	A naming service for domain names - to IP addresses is fine for
network - server configurations and servers are organised in domains.

	A directory approach is that real world entities such as ships,
bus ticket machines, mobile phones that are represented by a named
objects in a directory service will interact with real life entities
that are represented in the directory service that have certificate
responsibility. eg a country entry, an organisation entry, and
organisational unit, a device, a role, a person, a kiosk, etc.

	It is not true that all certficates will need to have a url
placed in them when they work in a business domain that is supported by
directory services.

	The difference in opinion is that:

	a) DNS can be tweaked for PKI servers and that certificates can
hold this information. In this case what protects DNS how does it do
distributed mutual authentication - and how on earth do we relate such
"connectivity" with which entity in the real world (as represented by
information) that these PKI servers relate to.
	Do the PKIX servers need a directory service anyway??????

	b) We can use a directory service as is - as designed and as
being deployed.

	In all this debate I have only seen the argument about how do we
"find a server" - and the answer is a URL in the certificate. Can anyone
tell me how the information sets that relate the certificate user and
the CAs that deal with it and the service domains their in.

	I can do all this very well with a directory approach to life.

	All I can do with a URL approach to life is connect to a client
with a cert to server. I suppose after this debate we will all end up
with:
	Directory Enabled PKIX servers.

	regards alan

---

From: Alan Lloyd <[email-masked]>
Date: Mon, 8 Feb 1999 16:25:09 +1100

Is there a point to this - re what we mean by global - 
For my two bobs worth - and as I work with the bigger organisations -
which I refer to as global - I like to think that the systems we
build/design scale well into those operations. ie a global PKI is not
THE global PKI. a global PKI just means the system as designed scales
well, applies engineering, operational, information and commercial
practices in the best knowledge that ensures really bad scaling, service
level and operational cost factors wont be dropped on us or the
customer.

Other comments in line
> From:	Perry E. Metzger 
> Sent:	Monday, February 08, 1999 3:29 PM
> To:	Alan Lloyd
> Cc:	Andrew Probert; [email-masked]
> Alan Lloyd <[email-masked]> writes:
> > I think what Andy is implying is that we require a Banking
> > infrastructure which is global
> 
> We have one already -- or hadn't you noticed?
	No - I just travel the globe 10 times a year - but I carry
chickens and and a few vegies and barter with those. :-)

> > - similar to that of the telephone
> > system. As said a PKI is a function. It will be applied into
> vertical
> > markets according to business models. Its a logical process to say
> that
> > because of the I in PKI that such functionality will be part of a
> bigger
> > infrastructure system and some organisations will apply that to
> operate
> > what they deem as global services.
> 
> Banks are never going to want a global PKI. 
	Thats a view - see definition of global above....

> Third party transaction
> organization has the least possible application in the banking
> industry, where the main function of the industry is itself management
> 
> and handling of transaction risk. Indeed, the actions of companies
> like Verisign to try to eliminate their liability all but eliminate
> them from usefulness to the banks.
	Thats a view also - I have different ones that are under NDAs.

> Remember, we are talking here about "Global" public key
> infrastructure. Public key methods are obviously of use. "Global"
> public key infrastructure is not of obvious use.
	See definition of Global above. A PKI is a function which is
applied to a business services delivery model that has subscribers and
providers that do transactions. Domains of these will exist and they
will interoperate on a technical, operational or business level policy
base. The size and scope of the PKI or PKIs that service such a market
will be big by nature and built to commercial policy.

	I would never say how big something will be, particularly when
its someone elses investment that will define that.
	However, as an informations systems engineer - working on the
subject matter I deal with, in the vertical markets that request our
efforts - I dont like building obvious walls, limitations and
operational costs purely to satisfy a "quick mechanism" to 2% of the
problem. When that mechanism has to be followed through to get to the
real solution to the real problem. IE. Appying PKI functionality to a
business information and service requirement - for global use.

> > I never buy into the points that users dont care about the
> technology -
> > that is obvious.
> 
> "Don't care" is different from "don't need" or "don't want". Sure, we
> can build computerized tongue depressors, but will the hot dog vendors
> 
> the eager manufacturer is  targeting WANT computerized tongue
> depressors?
	no comment

	regards alan

---

From: Andrew Probert <[email-masked]>
Date: Mon, 8 Feb 1999 17:39:26 +1100

Agree..  We could see global PKIs from:  Postal Services, Health, Stock
Exchanges, Traffic control systems, Network control systems ad infinitum,
all with their own business purpose, policy etc.  Ideally, common
infrastructure can be designed once and deployed multiple times, saving
development costs, reinvention of wheel etc.

Andew Probert

> From:	Alan Lloyd [SMTP:[email-masked]]
> Sent:	Monday, February 08, 1999 4:25 PM
> To:	[email-masked]'

---

From: Andrew Probert <[email-masked]>
Date: Wed, 10 Feb 1999 17:36:06 +1100

The discussion has slipped from infrastructure management to account
management alone, with the last couple of exchanges e.g. simply a Cert and
an Account number!

Again .. Banking infrastructure relies upon giving a customer a simple
'name'  (card-number) within a naming scheme:

   prefix-account number

Where the prefixes are globally registered in a process agreed amongst
financial institutions, the authorities have an established registration
process and a naming convention for these, to ensure global
interoperability.  It works.  

The customer view of it all is very simple i.e. Card and PIN.

The naming scheme's prefixes implicitly indicate the routing of transactions
to the Issuer for Authorisation.  Its a good model.  We are not seeing the
same design elegence in the current standards, we are seeing complicated
mechanisms.

Behind the scenes in banking are *heavy* *costly* infrastructure to support
Online Authorisation providing receipts, which includes EFT terminal to
switch, switch to switch protocols, terminal key management, switch key
managment, plus of course the black lists handled by each issuer.

Recent dialogue ignores the clerical and administrative effort that is
expended in managing the infrastructure, Help Desks, Technicians, Operators,
to a simple Cert <--> Account number technical paradigm.

I like the banking system analogy if we look at the totality of its
operations.  I think a broader vision of the infrastructure that needs to be
managed, is required.

Andew Probert

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 10 Feb 1999 11:06:30 -0600

Andrew,

Like some others on this list, I took part in a design
using  PKI in the banking-centric SET protocol. Banking
infrastructure is indeed complex, and has little
in common with residential or corporate infrastructures for
email accounts. It has little to do with domain-names
used by routers, and has even less to do with
political/telco/postal notions of physical
and telco addresses. It is true that as a global infrastructure,
banking does tend to touch a little on all the above, as it joins
in with the Internet. It touches on those ideas however
in a banking regulation-induced manner, which it itself
highly specialized.

In summary, banking policies for global PKI is best
addressed in specialist banking forums. Our role
is to ensure the underlying standard software can
be configured in the field to enable those policies
for each type of service infrastructure: banking, insurance,
trading, switching, factoring, and any other
similar business.

Where names are concerned, it would be right for
IETF PKIX to advise that schematic support for
naming architectures be built into the better PKI
component implementations. It would be
quite wrong to mandate that the
SET protocol's prescribed banking name schema be
supported by all conforming implementations
for example.

Similarly, it is useful that PKIX interacts with
directories using the X.500 information model. It
would be quite wrong to mandate that all PKI
implementations address chained and replicated
directories, or even be forced to become dependent
on the data accuracy and knowledge distribution
issues associated with any (distributed) directory
operation.

What can one do to address these important
but not critical matters to aid PKIX make
a difference to the actual PKI deployment world?

One could evangelize the PKI-oriented naming and
chaining issues in the IETF directory groups.
One could also evangelize use of PKIX
as a mandatory technical baseline in whichever
industry groups you deal with - and
encourage them to write up formal profiles
and certification polices to tune PKIX
technical infrastructure to their modes
of doing business.

Peter.

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 10 Feb 1999 11:27:13 -0600

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, February 10, 1999 9:52 AM
Subject: RE: Finding PKIX Servers!
 
>Similarly, the PKIX community should require that any proposal for
>a standardized cert retrieval mechanism enable a similar separation
>between CAs and repositories.  A repository can have one or more
>names; it doesn't matter whether they are in the DNS space or the
>X.500 space except that: 1) names registered under DNS are global
>today, and 2) if you are going to use the Internet to move data
>around, you have to wind up with an IP address for the repository
>at some point.  Mapping X.500 names to IP addresses involves
>either creating a separate infrastructure parallel to DNS, or using
>a three step lookup: X.500 name -> DNS name -> IP address.

PKIX already enables any deployment to separate CAs from
Repository agents. Today, a VeriSign Certificate can contain
a URL to a ValiCert OCSP responder. Or not. Similarly,
the same certificate can implicitly point a user to
the formal notice Repository (VeriSign Repository) or
explicitly point to one managed by the US Dept. of Defense.

I do not believe we need to first standardize a global name server 
infrastructure to enable PKIX to succeed. Nor should we
make a conformance condition hinge on the requirement
for PKIX conformance-claiming software to deal with
name servers. Of course it should be an option for
those making integrated PKI/Directory/URN solutions,
particularly in the corporate LAN world of NDS and 
ActiveDirectory.

 Peter.

---

From: Andrew Probert <[email-masked]>
Date: Thu, 11 Feb 1999 09:41:02 +1100

Thks.  For clarification, I am not advocating SET or the banking naming
model as specific solutions, merely operational analogies to the
requirements.

I am suggesting is that there are design analogies for banking -> PKI that
are useful to consider for other industries / uses.  Banking is a high
volume business with a big customer base and they, driven by operational
needs, have adopted certain operational approaches, albeit highly
specilised...

Comments inline.

Andew Probert

> From:	Peter Williams [SMTP:[email-masked]]
> Sent:	Thursday, February 11, 1999 4:07 AM
> To:	Andrew Probert; [email-masked]
> in with the Internet. 
	[Andrew Probert]  Agreed and interfacing issues are going to
increase!  In different ways PKI is more complex, because we have to deal
with Privacy which SET avoided by dealing with account numbers, only.
> It touches on those ideas however
	[Andrew Probert]  Agreed.
> addressed in specialist banking forums. 
	[Andrew Probert]  Agreed
> Our role
	[Andrew Probert]  These businesses have different policy drivers,
but similar infrastrcture needs.
> component implementations. 
	[Andrew Probert]  Absolutely!!
> It would be
	[Andrew Probert]  I agree and haven't been proposing this.

> issues associated with any (distributed) directory
	[Andrew Probert]  If they want to be "islands of incompatibility is
a sea of connectivity" its OK by me.  The first level of global
interoperability is a globally interoperable Name service for PKI.  That
should be put in place administratively, then connectivity should follow, as
required...

> a difference to the actual PKI deployment world?
	[Andrew Probert]  I would agreed the Urgency is not high, but it is
Critical.  If naming is not properly addressed, then their will be a big
retrofit cost in a few years time.

> chaining issues in the IETF directory groups.
	[Andrew Probert]  Yep.
> technical infrastructure to their modes
	[Andrew Probert]  Agreed, totally!

---

From: Alan Lloyd <[email-masked]>
Date: Fri, 12 Feb 1999 09:15:24 +1100

Sorry about being me again - but I just love these lines from people
that dictate what the whole world does.

> Sent:	Tuesday, February 09, 1999 3:28 AM
> To:	[email-masked]
> Michael Sierchio <[email-masked]> writes:
> > "Perry E. Metzger" wrote:
> > 
> > > 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.
> > 
> > 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.
> 
> Again, no, this is not the case.
> 
	I would never, repeat never say in one paragraph what the whole
world does when vetting a transaction with a customer across a counter
and who does the authentication and transaction verification. One can
only cite that in some cases (a) happens and in some cases (b) happens.
Sometimes I get asked for a passport or driving licence to prove who I
am when doing bank transactions and sometimes not.

	By making such a statement (as below) one can only assume you
have met every merchant in the whole world :-)

	SNIP

	regards alan

---

From: Alan Lloyd <[email-masked]>
Date: Fri, 12 Feb 1999 09:18:57 +1100

Comments in line

> Sent:	Tuesday, February 09, 1999 10:21 AM
> To:	[email-masked]
> Cc:	[email-masked]
> > Other than arguing against the need for such a global directory
> > infrastructure,  do you have philosophical or aesthetic problems
> > with it?
> 
> 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.
	I bet the same was said about canals and waterways, freeways,
the telephone system and air travel.
	 regards alan

---

From: "Kurn, David" <[email-masked]>
Date: Tue, 16 Feb 1999 11:45:02 -0800

Bob Jueneman's comments do raise some nice "wouldn't it have been nicer if"
points, but I think he has identified a real need in our efforts to deploy
PKI.  

Ignoring, for the moment, how I obtained Bob's key-encryption cert in the
first place, there are two other places I must go to before I can evaluate
trust.  

1)  I must find the certificate of the issuer (signer) of the certificate
2)  I must find the CRL which covers this cert.

Of course, this is a recursive problem.

Maybe Bob's suggestion should be augmented so that the LDAP service address
(DNS name) for each is specified in all PKI certs.  Call it optional (to
satisfy the purists), but make it painful to omit.

David Kurn
Compaq Computers Corp
Tandem Division

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Tuesday, February 16, 1999 10:56 AM
To: [email-masked]
Subject: RE: Finding PKIX Servers!

On the heat vs. light scale, a lot of the commentary on this thread 
has been well down in the infrared, but with a few flashes of insight.

Let me try to readdress the points I was trying to make.

<---- snip ---->

So I'll say again, wouldn't it be a Good Thing if we could have an optional
attribute
in a certificate that is associated with the Issuer's name somehow, one that
would 
provide the DNS name of an LDAP server that contains the Issuer's
certificate?

At this point in time, I don't care particularly what form the attribute
takes -- it could be
an agreed-upon semantics for DNS name as a form of alternateSubjectName, or
it 
could be some other alternateSubjectName attribute, or some other attribute
entirely.

But is there at least some agreement about the potential utility of this
concept?

Bob

Robert R. Jueneman
Security Architect
Network Security Development
Novell, Inc.
122 East 1700 South
Provo, UT 84606
[email-masked]
1-801-861-7387

---

From: [email-masked]
Date: Mon, 22 Feb 1999 11:51:41 -0500

I don't think the location of an LDAP server should be mandatory, but
an LDAP URL would be a reasonable option within issuerAltName.  While the
DNS name could be used instead, it might be ambiguous in that existing
extension, so it would probably need a new extension.

          Tom Gindin

"Kurn, David" <[email-masked]> on 02/16/99 02:45:02 PM

To:   [email-masked]
cc:    (bcc: Tom Gindin/Watson/IBM)
Subject:  RE: Finding PKIX Servers!

David Kurn
Compaq Computers Corp
Tandem Division

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Tuesday, February 16, 1999 10:56 AM
To: [email-masked]
Subject: RE: Finding PKIX Servers!

<---- snip ---->

So I'll say again, wouldn't it be a Good Thing if we could have an optional
attribute
in a certificate that is associated with the Issuer's name somehow, one
that
would
provide the DNS name of an LDAP server that contains the Issuer's
certificate?

Bob

Robert R. Jueneman
Security Architect