RE: ldapv2-schema and CA Certificates

[Santosh Chokhani <chokhani@xxxxxxxxxxxx>]

Sharon:

I have studied the path development a lot.  I am not claiming that I am
correct.  But, here are some of the conclusions I have come to:

1.	Path development is efficient when done backward from the
direction of trust, i.e.,  from subject end entity to relying party
trust anchor(s).
2.	Path processing has to be done in the forward direction of
trust, i.e., from the relying party trust anchor(s) to subject.
3.	Due the nature of processing of certificate policy related
extensions, it may not help to process based on certificate policies.
4.	However, if the certificate policy can be specified by an
application (when inhibit policy mapping is initialized or set to TRUE
and when require explicit policy is initialized or set to TRUE), both
attributes could be queried based on the matching filter(s).

	-----Original Message-----
	From:	Sharon Boeyen [SMTP:sharon.boeyen@entrust.com]
	Sent:	Monday, August 17, 1998 9:51 AM
	To:	Sharon Boeyen; 'Dave Horvath'
	Cc:	Larry Layten; 'Santosh Chokhani'; ietf-pkix@imc.org;
'kpcm'
	Subject:	RE: ldapv2-schema and CA Certificates



	> ----------
	> From: 	Dave Horvath[SMTP:dave@chromatix.com]
	> Sent: 	August 14, 1998 6:36 PM
	> To: 	Sharon Boeyen
	> Cc: 	Larry Layten; 'Santosh Chokhani'; ietf-pkix@imc.org;
'kpcm'
	> Subject: 	Re: ldapv2-schema and CA Certificates
	> 
		-- stuff deleted --


	> Could you please explain why this is a detriment of
interoperability and
	> of efficient path building on other bases.  If you want to
retrieve all
	> CA certificates, just invoke a search request specifying the
OIDs of
	> both attributes.  I believe your requirement is satisfied by
issuing one
	> search request.  Why is this a problem, unless you have an
installed
	> base issue?  If the problem is installed base, I understand. 
	> 
	SB - You are correct that a client interested in finding a path
based on
	criteria other than 'internal' versus 'external' can always
retrieve
	multiple attributes, however that is exactly one of the problems
with the
	option of splitting the values into two separate attributes.
Those clients
	not wanting to optimize based on 'internal' versus 'external'
but on some
	other criterion, such as values of the certificatePolicy
extension, would
	always be required to filter on two attributes rather than one.
This whole
	discussion has been about efficiency in path building and I am
arguing that
	LDAP tools will be able to provide significant help in gaining
efficiences
	in a general way with the extensible match facility afforded by
LDAPv3.
	While it is true that the spec we are currently discussing is
schema for
	LDAPv2, which does not perform the extensible match function,  I
don't want
	to see us paint ourselves into a corner where we will not be
able to
	capitalize on such  features without defining a whole new schema
for PKIX
	(bringing along another whole set of interop issues which would
probably
	prevent us from moving forward anyway). By forcing clients to
issue LDAP
	queries that filter against two attributes instead of one,
efficiency that
	can be provided on the LDAP side is lost. Also, I don't believe
that we
	should be requiring CAs to split the certificates they issue to
other CAs in
	this or any other particular fashion. Rather, in the interest of
	interoperability and simplicity I think the PKIX WG should be
requiring that
	certificates issued by one CA to another CA be placed in a
single attribute
	and any additional schema which is used in a particular
environment to gain
	efficiency with any given path building algorithm be additional
and
	optional. Because of the forward and reverse nature of the
	crossCertificatePairs attribute I believe this is the one that
is best
	suited to these certificates.  

	--more stuff deleted--

	> How can you make the statement "since a relying party really
has no a
	> prior way to know what they should be looking for or how a CA
has placed
	> the material in the directory"?  We are attempting to define
the rules. 
	> The only way you can make this statement is if you don't allow
us to
	> define the rules.  Then we have chaos. 
	> 
	SB - What I mean by that statement is that under the proposal,
the relying
	party would not know whether a given CA whose entry was being
searched, had
	split certificates into two attributes or placed them all in
one. Therefore
	it wouldn't know which attribute to search and would be required
always to
	search both. Two attributes is less efficient than one.

	> Again, if your interests are backward compatibility I
understand your
	> concern.  
	> 
	SB - I am looking forward not backward and concerned with making
rules that
	are more general in nature and don't arbitrarily force one
model, which does
	not fit the needs of others, on everyone. I'm trying to propose
a generic
	solution that can be used in many models and leave the
particular model and
	path development process up to the business requirements of each
particular
	deployed environment, in a strong belief that there will be many
differing
	business requirements and different models deployed. If we can
agree on a
	single common attribute that is supported, as a minimum, to
contain the
	certificates issued by one CA to another CA, and leave optional
additions up
	to the deployed environment, I think we'll be doing a lot for
	interoperability. If we arbitrarily impose a particular model
that doesn't
	fit generic business requirements it won't be followed anyway
regardless of
	it standards status. I do recall during PKIX part 1 discussions
opinions
	being stated that PKIX should not be defining path development
algorithms
	but should be concerned with path validation and I agree with
those
	opinions. We should not be pre-supposing any particular
algorithm for path
	building. 

	Sharon
	>