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

From: Alan Lloyd <[email-masked]>
Date: Mon, 26 Oct 1998 10:40:25 +1100

Fantastic... this one has got my vote.
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 (distributed object oriented,
protected, name base transactions, etc) and then apply the security
paradigms necessary to protect a) internal services and; b) customer
authorisation on to the busines's systems used for service delivery.
Importantly and in line with business expansion through customer and
other organisation acquisition strategies - and in line with dealing
with the dynamics of such. It is better to consolidate the information
model (via directories), apply a business strategy re staff and
customers and then apply the security regimes in line with cost, risk
and trust and the business.

I think that trying to shoehorn a PKI onto a company without a directory
system is hard work. In fact very hard work. Simply because there is not
a consolidated information system, no consolidated approach to services
or no consolidated approach to the staff or customers - re the
application of 509.

As said in previous postings, the theory of CAs and 509 has a place.
Buts its application will be (eg.) a telco giving a customer a phone on
which the telco can verify the phone and what services are afforded to
that phone (or attched smartcard).. ie. there is no third party
verification here, just millions of very fast verification actions - via
very large distributed directory services that have directory enabled
validation functions.

Just thoughts - regards alan

	PS should we change the subject line?

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Saturday, 24 October 1998 3:45
> To:	Al Arsenault
> Cc:	Stephen Kent; [email-masked] '
> Subject:	Re: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
> 
> 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: "Phillip M Hallam-Baker" <[email-masked]>
Date: Mon, 26 Oct 1998 12:01:00 -0500

> 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