RE: ldapv2-schema and CA Certificates

[Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx>]

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