RE: NEW Data type for certificate selection ?

[Stephen Kent <kent@xxxxxxx>]

Alan,


>> 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.

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.

>>  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.

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.

>	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.

I don't know what this is saying.

>>   >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?.

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.

>	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.

Sorry.  These are vague complaints.

>	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.

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