RE: NEW Data type for certificate selection ?

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

Comments in line....

> -----Original Message-----
> From:	Stephen Kent [SMTP:kent@bbn.com]
> Sent:	Thursday, 15 October 1998 23:40
> To:	Alan Lloyd
> Cc:	'ietf-pkix@imc.org '
> Subject:	RE: NEW Data type for certificate selection ?
> 
> Alan,
> 
> >Yes the problem is a path issue. where CAs may have multiple paths to
> >their roots or other CAs, multiple approaches to revokation, Users
> have
> >multiple certficates, clients might be root and domain agile, etc.
> >
> >I have views on this which says we should not complicate the
> certificate
> >any more-  so the client gets even more complex and untrusted, we
> should
> >use some simpler methods of validation with the assistance of the
> >directory service.
> 
> Yes, one can imagine offloading this processing, but a fundamental
> assumption underlying certificates is that one does not need to rely
> on
> other parties for such processing and storage.  Thus directories are
> untrusted repositories, which can do not worse than store bad data. 
	[Alan Lloyd]  
	That is why a certficate is signed so that in can be stored and
transferred with and between "cryptographically" untrusted repositories.
>  I
> would not want to confuse this long term existing model of what a
> directory
> does with the notion you;re suggesting, of a component/system that
> performs
> lots of processing that we currently envision being done by a
> certificate
> consuming system.  I'm not saying we ought not consider such
> alternative
> models, but le's not confuse folks by calling them directories,
> trusted
> directories, etc.
	[Alan Lloyd]  There is no confusion with the systems I work
with. There are two approaches.

	1. Where the CA's information model re root paths and cross
certs and CRLs etc are sensibly designed and organised and matching
rules applied from standard directory access (Search Ops) that can
return a result. In this case the "processing" is placed on the
directory  to "validate" the certificate path issues.. all the clent
needs to do is offer the cert require validation without prior knowledge
of the information designs or the operational relationships that a
directory enabled CA function might have.

	2. The second approach - which still promotes a validation -
service based model is to have directory attached, directory enabled
processes.. This is a nicer approach because these can scale easier -
eg. we (the third rock from the sun) need to deal with global services
that have 100m + users with at least 10 certs each -- and simple,
business domain agile clients.

>   >Phone systems are good - my telephone does not have software in it
> to
> >prove the telephone company can provide it with its phone number !
> :-)
> 
> I don't really see the relevance of this last analogy.
	[Alan Lloyd]  This quite straight forward. I do not see the
sense behind writing complex clients that when validating a certificate,
the client goes has to know all the relationships of a CA, eg roots and
cross certs, what extensions are used in CA certs, what may or may not
be valid, etc for all the subjects (the cert subject) it deals with in
the many domains of business they might work in.
	CAs may wish to improve their information models and objects
over time that deal with cross certs and multiple roots - at any time.
Why should such a change invalidate all the client software that deals
with validation?.

	As said the PKI /CA design at present has not dealt with (IMHO
)very well  the way large scale directory systems are needed for wider
use of X.509 and EC or the operational and service based issues of
validation - with the emphasis of making client software as portable and
as simple as possible. The designs at the moment are "technically
orchestrated" re a CA information functional and information
relationship design and certainly too complex - because the designs of
the CA with all its mystery points is enforced on the client process.

	This is similar situation why LDAP is in a mess. 

	If one designs a system with (distributed) functions (like the
phone system or a directory SERVICE) and then one designs the access
protocol, the system services actually constrains what is in the access
protocol is and the software  in the client that uses the access
protocol ca actually do. ie. the system services and operations
constrain any shift in what upgrades can occur on the access interface.

	LDAP approach - make the directory system as vague as possible,
add protocol features that have an effect in the client and the server
in a random way, ie make the processing of the protocol elements affect
how the system  and the clients evolve to a point where any new feature
affects the wider interoperability of clients and servers/services. ie
many features in LDAP MAY work OK with a single server address book (and
need a lot of human effort), but if LDAP is used with a real distributed
directory service (eg. X.500) then many of the funny features of LDAP
cannot be used. - in addition , different knowledge, referral,
replication, authentication, password and certficate management issues
apply depending on what type of service supports the "LDAP" interface.

	A system model re services (such as  cert validation) would
strike me as the only way to start.

	regards alan
	 
>  Steve