Subject: RE: NEW Data type for certificate selection ?

From: Alan Lloyd <[email-masked]>
Date: Mon, 19 Oct 1998 12:13:33 +1000

Comments in line....

> -----Original Message-----
> From:	Stephen Kent [SMTP:[email-masked]]
> Sent:	Thursday, 15 October 1998 23:40
> To:	Alan Lloyd
> Cc:	[email-masked] '
> 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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 19 Oct 1998 19:55:01 -0400

Alan,

>transferred with and between "cryptographically" untrusted repositories.

The issue here is not the storage of signed data in directories, it is the
notion that the directory would perform a search for a user to collect
certs and CRLs, process them, and tell the user whether the cert was valid
or not.  This abrogation of responsibility by the user, to a third party,
is dangerous.

>directory enabled CA function might have.

I believe that we do fundamentally disagree here.  Directories are
repositories that can return data stored in them, e.g., in response to
searches.  Validation of cert paths is something a directory does for its
own use when employing certs for authentication in support of directory
access control.  It is the relying party in such circumstances and thus is
doing what any such party ought to do as part of cert validation.

>business domain agile clients.

I don't know what this is saying.

>Why should such a change invalidate all the client software that deals

It should not invalidate client software, because such software should be
just as capable of validating the resvied PKI structure as it was of
validating certs under the previous structure.  We have standards for cert
processing procisely so that clients can do this correctly, in a standard
fashion.

>the CA with all its mystery points is enforced on the client process.

Sorry.  These are vague complaints.

>strike me as the only way to start.

I don't want to debate LDAP issues; this is a PKI list. Your e-mail address
suggests that you may work for a company that believes directories are the
solution to lots of problems.  Personally, I don't share that belief, but
the more central issues is that I'd like us to not confuse the current
definition of directory services, as defined in X.500 and LDAP, with some
possible future set of cert validation services.  About 5 years ago we
developed such a service as part of a DARPA program; it validated certs
that a client could not validate because of algorithm incompatability or
similar constraints.  Been there, done that.  However, the better use of
the service was to collect certs and CRLs for the client and deliver them
in a form to simplify client cert path validation.  That's not an
unreasonable service, but it's a far cry fro asking a third party to do the
validation for you.

Steve