Subject: Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])

From: "Andrew Csinger" <[email-masked]>
Date: Tue, 20 Oct 1998 18:59:37 -0700

This is more or less what I've been trying to sell for years :)  In other
words, I think it's the right model, but so far, the market hasn't been
aggressively demanding the concept.  It's an extremely simple model that
lends itself to a wide range of applications, from basic web access control
to a variety of on-line payment protocols.  You might call it Connected-Mode
PKI (I do).

The strongest counter-argument has always been the contention that it would
be difficult, if not impossible, to guarantee reliability, availability and
performance.  The best defense to this counter-argument is still the
"dial-tone argument," which is why I now work at a telecommunications
company :)  Our approach involves a replicated, geographically distributed
directory server built for vendor-independent PKI.  Available for sale or
lease :)

If PKIX were to head off on this road, I would be happy to help pave it.

Andrew

--------------------------------------------------------------
Andrew Csinger, VP Electronic Commerce        GT Group Telecom
840 Howe Street, 3rd Floor                 tel:   604-688-3010
Vancouver, B.C., Canada  V6Z 2L2           fax:   604-688-3011
http://www.gt.ca                         email:  [email-masked]
           **** Information is Power.  Plug in. ****
--------------------------------------------------------------

-----Original Message-----
From: Al Arsenault <[email-masked]>
To: Denis Pinkas <[email-masked]>; Sarbari Gupta
<[email-masked]>
Cc: 'Alan Lloyd' <[email-masked]>; [email-masked] '
<[email-masked]>
Date: October 20, 1998 6:50 AM
Subject: A different architecture? (was Re: certificate path services [ was
RE: NEW Data type for certificate selection ? ])

>
>The recent postings by Sarbari Gupta and Denis Pinkas, along with the draft
>DCS protocol <draft-ietf-pkix-dcs-00.txt> seem to be further steps toward
>an architecture that I've looked at in the past.  I'm  curious as to
>whether that's where some people really want to go.
>
>The architecture in question is modeled after what many people believe is
>the way the credit card system works.  That is, I go into a store to
>purchase an item.  I hand my credit card to the clerk to pay for the item.
>The clerk contacts an account authority, and asks the question "is this
>user (i.e., the credit card number) valid for this transaction (giving the
>dollar amount in question)?".  The system responds with one of a variety of
>possible answers:
>
> - reject the transaction because:
> - the credit card has been reported stolen (i.e., the "private key" has
>been compromised)
> - the credit card has expired
> - this transaction exceeds the available credit on the card
> - ...
>
> - accept the transaction; here's the authorization code.
>
>(Obviously, this is generally done electronically - the clerk or the
>customer swipes the card and the data are fed to a computer which provides
>the answer; the human clerk doesn't talk to another human unless there's
>some problem.)
>
>The clerk's next action depends on the account authority's response:  write
>down the authorization code if approved; return the card with explanation
>if expired; keep card and call police if stolen; etc.
>
>
>To replicate this in the world of certificates, one would do something
like:
>
> - establish an account authority or transaction server to do all of the
>certificate path construction and validation; policy checking; etc.  (You'd
>probably have more than one, depending on overall system load, reliability
>requirements, etc.)
> - configure each end-entity with the name and certificate of the
>transaction server to trust (again, you'd probably configure each one with
>a primary and one or more back-ups, but that could be worked on a
>case-by-case basis).
> - when an end-entity receives something to be validated (e.g., a signed
>S/MIME message; a request for SSL session set-up) it sends that information
>to the transaction server; basically, it's asking "right now, to the best
>of your knowledge, is this valid for what the sender wants to do?"
> - the transaction server receives the request, crunches through all of the
>signature validation, cert path construction and validation, policy
>processing, etc., and determines an answer which it sends to the requesting
>end-entity
> - the end-entity accepts or rejects the initial request based on the
>response it gets.
>
>We actually looked at this for a while in the MISSI effort (well, at least
>some of us did :-).  There were a number of potential customers who wanted
>something like this because of some perceived advantages:
>
> 1 - it seems to fit the 'thin client' model that was all the rage a year
>or so ago.  All the end-entity has to know is how to contact a transaction
>server; it doesn't have to have all of the cert path construction and
>validation logic.  This makes the software with the most copies deployed be
>as small, simple, and cheap as possible.
>
> 2 - it doesn't force any user interactions at the end-entity.  At worst,
>the user is told "accepted; authorization code = .." or "rejected:
reason...".
>
> 3 - it results in all of the information needed for non-repudiation (e.g.,
>certificates, cert paths, CRLs, etc.) being stored at one or a few central
>places, rather than having it scattered at various workstations all over
>the net.  Further, since it was envisioned that the transaction servers
>would be high-end machines located in data centers, it would be easier to
>establish the procedures and processes necessary to protect and store the
>non-repudiation information.
>
> 4 - it seems to provide the most timely revocation notification of the
>system designs presented so far.  Particularly if the transaction server is
>also the CA who issued the certificate in the first place, revocation
>notification can be distributed almost instantly upon the revocation
>decision being made.
>
>On the other hand, it does have a number of potential "issues" (to be
>polite). Some of them were:
>
> 1 - as Steve Kent has pointed out, it makes the transaction server an
>attractive target.  I can derive great benefit from taking it over, and I
>can probably derive some benefit just from crashing the thing.  (Military
>folk tend not to like designs with single points of failure; it's too
>darned easy to just drop a bomb on the thing.)As Denis Pinkas pointed out,
>you can alleviate some of this, but there's a cost attached.
>
> 2 - without worrying about attacks, it's likely that the transaction
>server will have major reliability & communications bandwidth requirements,
>especially if we're dealing with approvals required prior to the
>establishment of real-time connections.  This will cause it to be a very
>expensive suite of hardware & software, compared with the rest of the
>system.
>
> 3 - it's relatively straightforward to handle signed messages.  Encryption
>is worse, though - if you want the transaction server to handle encrypting
>and decrypting of data, you've turned your environment into something that
>looks a lot like what's described in Dean & Ottaway's
><draft-ietf-smime-domsec-00.txt>.  You lose the ability to have data
>encrypted from end-user to end-user; you can only encrypt it from end-user
>to server or even server to server.  Then, the data pass in the clear
>between end-user and server, or have to be separately encrypted for that
>link. That's not necessarily bad, but it may not be something that
>everybody wants to do.  (If you want to have the transaction server handle
>signature but not encryption, you lose much of the benefit, because the
>end-entity will have to do all of the certificate path construction and
>validation just to encrypt & decrpyt data.)
>
>
>None of these "issues" is necessarily unsolvable in general, but they may
>be too hard in any particular environment, and taken together they can
>cause a lot of pain.  (Ultimately, we didn't implement anything like this,
>because it was going to take a lot of time and money to solve the "issues",
>and it wasn't clear that all of them were readily solvable given our
>particular constraints.)
>
>Now, the reason for this long-winded message:  with OCSP, PKIX took the
>first step toward this architecture, by setting up a server to basically
>check CRLs for the end-user.  With DCS, it looks like we're taking the
>second step, with the cs and cpkc transaction types.  So:  will PKIX
>eventually move toward supporting the full architecture?  If that's
>anybody's goal, should we be starting to look now at the entire set of
>things necessary to get there, rather than taking it piece by piece?
>
>Or, is it the case that nobody thinks that the architecture I described is
>ever in the plans, and all we're looking at is incremental service
>enhancements?
>
> Al Arsenault
>
>- my opinions are my own, yada, yada, yada

---

From: Alan Lloyd <[email-masked]>
Date: Thu, 22 Oct 1998 21:48:11 +1000

Comments in line. Agree with some of the comments - but like to add.

----------
From: Stephen Kent
To: Al Arsenault
Cc: [email-masked] '
Sent: 10/22/98 4:51:41 AM
Subject: Re: A different architecture?  (was Re: certificate path
services  [ was RE: NEW Data type for certificate selection ? ])

snip
One of the biggest features of a well designed PKI is that it embodies a
distributed security model that scales through simple replication of
static
data, a problem we know how to solve. 

Alan: However a major weakness in any system occurs when one replicates
data - particularly when that data forms a linkages to a point of trust
- and in the path there are other objects that may or may not exist (eg
CRLs) that could be placed in these paths in non uniform ways...
EG LDAP -  one of the major deficiencies cannot ask for master data from
a CA directory ie. If a CRL has been placed in the master but not yet
propagated to replicas, then a client could consider the cert being
validated - valid if it (without its knowlege - accesses the replica).

(ie. why talk of trust and how one achieves trust in a distributed and
replicated information system and then use a protocol that has so many
untrusted deficiencies???? eg. LDAP. 

 It also has the property that to
spoof the identity of an end entity, one ought to have to subvert the CA
that issued the cert to that entity, although sloppy cross certification
and bad choices for PKI structure can make this situation worse.

Alan: Bad PKI designs come from weaknesses and complexities in the CA
and the related client information model and service interaction
software - as one adds complexity the components that work with an ill
defined and variable information model, then all things get into a mess.
EG LDAP - no system service model, add and extension here there and
everywhere. Outcome - LDAP is not universal anymore - an operational
mess.

Limited scale systems, complex clients and weak/variable CA information
models is what we have. Its better to have consistency in service and
place trust in the implementation of that service. There is no point in
discussing trust in theoretical Objects and certificates and the
processes that might happen in someones CA or "cert server".

The notion of cert validation servers is thus very disturbing.  

Alan:
If a client goes to a CAs directory to get a cert in the path and the
directory provides the wrong one and therefore user to user transaction
is invalidated - then denial of service happens. 
Something - somewhere in the system has to be trusted. And in my book
its the implementation that is trusted not theoretical models.

eg. I can build a highy trusted directory system that does cert
matching, has bullet proof access controls, has trusted processes that
generate valid flags from processing CRLs...for the client.

OR I could  write sloppy, bug ridden, fragile process that serves no
purpose in terms of trust.

OR I could promote a protocol to a server without any distributed,
directory relevant CA information model and say that solves the problem.

In the above the following observations MUST be made.
Using good directory technology, with sound information services to
support CA functions provide scaleability and measureable trust models.

Using bad anything .. provides no trust

Having a protocol to a server without any notion of the CA function and
the directory support that CAs need or any notion of scaling or how it
deals with multiple CA domains or the complexity of the client,  only
generates problems.

IE.
IMHO Talking of trust in the CA/X.509/directory environment without any
reference to implemtation and system design qualitative characteristics
becomes an endless debate - without resolution.

regards alan

Steve

---

From: [email-masked]
Date: Fri, 23 Oct 1998 10:45:05 -0700

Many of the infrastructures involving authorization ... include many
factors in addition to strong authentication, some real-time and some not.
Accont-based infrastructures have been a part of business infrastructures
for some time to bind together the necessary information necessary to
support authorization. The accont authority digital signature model
attempts to integrate public key registration and digital signature
authentication into the core business process ... as opposed to working on
ways of figuring out what pieces might be exportable to a certificate, then
realizing that there are real-time requirements ... which means real-time
contact of the CA which is maintaining various critical information.

As the number of attributes are exported into certificates increases ...
and the real-time status of those attributes are required to be maintained
at the CA for authorization ... a CA would eventually begin to migrate to
becoming an accont authority. The current main distinction of a CA is that
it is maybe 20-30% handling cryptography for certificates and 70-80%
account management. As number of attributes and real-time status
requirements increase ... the role of cryptography in the CA becomes
smaller and smaller ... and the account management starts to grow to 95+%.

From the financial infrastructure standpoint ... once past toy pilot stage,
it is much more cost effective to start with the most robust
account-management infrastructure in existance today and retrofit the 1-2%
cryptography necessary to support digital signature authentication ... than
it is to try and upgrade CAs into business-critical, industrial strength
account management support.

---

From: [email-masked]
Date: Mon, 26 Oct 1998 14:27:00 -0800

PKI tends to represent a binding between some set of attributes and a
public key. Accounts have been used for a long time for attribute binding
in business scenerios.

If the PKI attributes start to take on real-time status requirements for
various business processes ... then a certificate approach will tend to
represent stale status ... and something else must be created to provide
real-time status. If business process completion is dependent on obtaining
that real-time status ... and some of the status has been PKI linked ...
and some of the status is core business process, account-record links ...
then availability is impacted (i.e. attribute status like requiring real
time information on whether a certificate is even still valid).

---

From: Alan Lloyd <[email-masked]>
Date: Wed, 28 Oct 1998 11:32:44 +1100

Totally agree. 
 PKI is not a God on High, it is a security function that is applied to
a business (with various levels of trust) commensurate and in line with
the service provisioning and investments (of IT systems) of that
business. And first and foremost in that application process, the PKI
and the business information concepts and models have to integrate. Ie.
if databases integrate with the directory systems (or become them), the
PKI functions can be applied. 

A key system is there to protect the delivery of IT services - and the
investments in the implementation, delivery and management those
services in a global market will probably be 20 times that of any PKI
expenditure. And generally experience is showing that the PKI function
is applied to existing services. Not the other way round.

regards alan

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Tuesday, 27 October 1998 6:16
> To:	Phillip M Hallam-Baker
> Cc:	Alan Lloyd; Al Arsenault; Stephen Kent; [email-masked]
> Subject:	RE: A different architecture? (was Re: certificate path
> there are business operations with account-based systems with
> >100million
> entries and raw
> data in tens of terabytes. for business process that have to access
> the
> account record to complete the transaction, splitting responsibility
> for
> the transaction between an account infrastructure and a PKI
> infrastructure
> ... doesn't improve availability ... it actually lowers it since now
> there
> has to be two things that are operational for transaction completion
> i.e.
> availability to complete is the product of the availability of the two
> infrastructures; for availability to improve, transaction would have
> to be
> able to complete even if the whole PKI infrastructure or the whole
> account
> infrastructure was not operational (and since the original premise was
> that
> at least the account infrastructure has to be operational for the
> transaction to complete; adding a PKI infrastructure can't improve the
> availibitliy)
>

---

From: Alan Lloyd <[email-masked]>
Date: Wed, 28 Oct 1998 11:22:53 +1100

You may disagree Phill - but do you have an alternative
information/services solution for organisations who want to represent
and manage their customers, 10s if not 100's of millions of customers in
a distributed way across this planet.

The bottom line is that a "PKI" technologies on their own with
customised databases and odd validation protocols do not scale well.
Also a free standing PKI does not represent a complete service
provisioning system for dealing with customers over a distributed
environment. Also PKI on its own does not provide a consistent approach
the business or operational issues which usually dominate real, large
scale information systems.

Please note, that when I say a coherent directory strategy is needed, I
dont mean that there is one directory for the whole world or for a
complete organisation. There will be directory system (s) aligned to
specific vertical markets (WP, retail, defence, transport, libraries,
etc), there will also be WEB systems, there will also be databases, etc.
and there will be integration between these information functions
through tools, etc. And companies will apply directory technology to
support a service over a sphere of influence. eg. Customer
authentication and access.

My comment is that, one cannot put, IMHO, attributes such as
certificates, that relate to objects (X.500 style) into a serviceable
environment without a directory system - if you want to add business
related information to such objects and you want scaleability (ie.
distribution - with distributed acccess and administration). 
The other way of doing this is via a dedicated database and bespoke
validation protocols onto bespoke information models. ie. no
scaleability and and one cannot add business information. Where would
such a system be used? Well only limited, very complex enclaves with
"small" (10k) numbers of users with limited services.

The world is moving toward a directory infrastructure - ie. the
evolution is from customised databases--> WEB based for browsing
text---> and additionally distributed object texhnologies (directories).
The DEN initiative and many vendors "directory enabling" their
applications prove this  - eg. see SAP and Peoplesoft announcements re
directory enabling...

I think that PKIX wont go far without considering the fundamental issues
of being directory enabled or supported.

And to date - all I hear is that PKI can happen without
directories...Well I travel the planet and work with big organisations
and in my book,  no directories = no PKI. 
So perhaps there is a market for small dedicated PKIs but what is the
PKIX list's view in providing a PKI for the Internet - ie. 100m users? a
customised central database?

regards alan  

> From:	Phillip M Hallam-Baker [SMTP:[email-masked]]
> Sent:	Tuesday, 27 October 1998 4:01
> To:	Alan Lloyd; [email-masked]; Al Arsenault
> Cc:	Stephen Kent; [email-masked]
> > ie. The direction today is to consolidate business information
> models in
> > line with current systems be it "internal" for Staff and "external"
> > Customers with X.500 directory systems ....
> 
> I disagree.
> 
> The idea that there is one 'direction' that is appropriate for the 
> market as a whole is simply ridiculous. There are directions that 
> will be more appropriate for some applications than others.
> 
> There are many organizations in which the deployment of a PKI will
> never happen if the precondition is the deployment of a coherent
> directory strategy. The 'consolidated approach' to information
> systems has been tried and the current CIO got where he did by
> dismantling it.
> 
> 
> As Steve said, been there, done that.
> 
> Having built systems which by anyone's definition are 'extreeme'
> scale-wise (anyone else here commissioned machines dealing with 
> 6Tb/sec raw data?) the major lesson I have drawn from this
> experience is the need to insist on tight compartmentalization
> of functionality. The interdependencies between complex
> infrastructure must be ruthlessly pruned to the bare minimum.
> 
> The 'directory-centric' PKI that Alan is promoting is simply
> a further step in a direction that is already causing severe
> scaling problems. Directory dependent PKI can only scale as
> far as the directory. Where is the global X.500 directory? 
> 
> A PKI should be able to take advantage of a directory if it is
> there (call it directory linkable?) - but collapse in a quivering 
> heap if the directory has a bad day? - NEVER!
> 
> 
> Until someone can show me a directory system with 100 million
> users that is deployed the 'directories scale hypothesis' is
> unproven in my view.
> 
> More seriously however the ability of directories to scale 
> rests upon a very tightly circumscribed set of duties which 
> they respond to. After all the difference between a directory 
> and a database is simply that the transaction coherency 
> requirements which are costly to implement in conjunction
> with replication are not supported by a directory.
> 
> In other words a directory might scale to 100 million users,
> but not if we start tampering with the assumptions on which
> that scalability depends. The scaling of Web servers became
> much more difficult once they became stateful.
> 
> 
> 		Phill

---

From: [email-masked]
Date: Wed, 28 Oct 1998 08:27:45 -0800

small note ... from business standpoint ... it might be better explained
that no directories no authentication infrastructure (which is the business
process/requirement) ... a PKI is then a method of implementing that
infrastructure. Part of the problem with starting with PKI as a solution
and then asking what the problem is .... one might might be led into
presuming that some of the existing PKIs deployed for independent pilots
are the structure one would automatically use as an integrated business
solution.

directories actually have other business needs independent of the
authentication infrastructure. in past life, looked at one customer that
had on the order of 6000 RDBMS where 90% of the data was common. schema
integration directory was needed just so that simple things like changing
the name on an account is consistently done thruout the business (side
problem was wide variety of different terms that were used in schemas for
common things like name).

---

From: [email-masked]
Date: Wed, 28 Oct 1998 09:20:39 -0800

... and the other serious problem that is starting to show up is the
privacy issues related to information that might be in a directory ....
even a name field might represent a privacy concern.

---

From: Alan Lloyd <[email-masked]>
Date: Thu, 29 Oct 1998 09:22:17 +1100

Perhaps one of the approaches here is to put public information into
"Border" or Public DSAs that serve the external interactions of an
organisation - as Read Only systems.
These DSAs are used to protect aggregation threats and possibly
name/semantic dissemination. Some systems being designed explicitly
state such devices with trusted oneway/mapping replication unctions from
the core internal systems.

regards alan
> Sent:	Thursday, 29 October 1998 4:21
> To:	Alan Lloyd
> Cc:	'Phillip M Hallam-Baker'; Al Arsenault; Stephen Kent;
> [email-masked]

---

From: Alan Lloyd <[email-masked]>
Date: Thu, 29 Oct 1998 10:15:55 +1100

Agree Lynn. We (OpenDirectory) are obviously directory centric and its
that view that sees the issues you describe. Most organisations have
high cost information islands for all sorts of reasons - and as they try
to reduce operating costs and optimise information management then the
directory approach works well. In fact its designed exactly for that.
One cannot add to information islands supporting service delivery a PKI
unless one wants more costs and more risk. So its "consolidate (into OO)
and then authenticate" is the way to go.
We see directories as the new wave in distributed OO engineering for all
forms of business information infrastructures. I think there has been a
view that directories are about email address books, white pages and
DNS. And this of course is just a limited subset of the directory
capability.

regards alan
> Sent:	Thursday, 29 October 1998 3:28
> To:	Alan Lloyd