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

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

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:	Lynn.Wheeler@firstdata.com [SMTP:Lynn.Wheeler@firstdata.com]
> Sent:	Saturday, 24 October 1998 3:45
> To:	Al Arsenault
> Cc:	Stephen Kent; 'ietf-pkix@imc.org '
> 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.
>