Subject: Re: draft-ietf-pkix-ldap-* consistency issues

From: David Chadwick <[email-masked]>
Date: Thu, 02 Dec 2004 16:14:18 +0000

Kurt

I agree that certificates should be stored in the person's entry if that 
is what clients require or expect. I do not see data redundancy as being 
a problem do you? Its not rocket science but standard database stuff. 
After all, most LDAP servers support single master or multiple master 
replication. So what is all the fuss about?

I think we should simply water down this text by removing the MUSTs and 
replace it with something like the following (note that people are not 
the only objects to have certificates)

Note. If certificates are stored redundantly in subject entries and in
certificate entries below the subject entries, these obviously should be
consistent.

regards

David

Kurt D. Zeilenga wrote:
> draft-ietf-pkix-ldap-pkc-schema-01 basically proposes to copy certificate
> information from the entries representing the entity which possess the
> certificate to a separate certificate entry.  I consider relocation not to
> be feasible option whatsoever as it will simply break some
> existing clients which use basic certificate matching, as well as
> existing and future clients which makes component matching with
> certificates.  However, the document actually reads as if relocation
> of the information is intended.
> 
> This text causes me concern:
> 
>>  If certificates are stored redundantly in person entries and in      
>>  certificate entries below the person entries, maintainers of
>>  repositories MUST make sure that the same certificates are stored in
>>  the person entry and the respective certificate entries and keep this
>>  consistency.  Alternatively, they MUST leave out any certificates in
>>  the person entry.
> 
> 
> Now, given that maintainers will be hard pressed to ensure
> consistency, this specification has stated that the standard
> track approach of storing certificates in the person entry
> is not to be followed.   This MUST will lead to breakage.
> 
> Instead, this document needs to needs to make it clear that
> certificates will be stored redundantly, there will be
> consistency issues, and then discuss how applications are
> to address these consistency issues.
> 
> Kurt
> 
> PS: I note that these MUSTs appear to apply to users, not to
> implementations... they likely should be downcased.
> 
> 
> 

-- 

*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 1484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Web site: http://sec.isi.salford.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 03 Dec 2004 04:10:11 -0800

At 08:14 AM 12/2/2004, David Chadwick wrote:
>I agree that certificates should be stored in the person's entry if that is what clients require or expect. I do not see data redundancy as being a problem do you?

Yes.  Aside from consistency issues (which I will touch on in response to
one of your other posts), there are other concerns.  By duplicating the
data, you are creating separate points of access which must be properly
controlled.  Obviously, the burden (and a significant burden at that)
to duplicate the access controls would fall onto the directory administrator.
It is quite possible, due to aspects of current access facilities, that the
directory administrator will not be easily able to duplicate the access
controls.  For instance, to support value extraction, the administrator
needs to give entry creation rights to entities which previously only
had the right to create values of certificate attributes and, by doing
so, granting more access than desirable.  Or, because other entities
have permission to create entries subordinate to the person entries
(for instance, the person herself might be allowed to create subordinate
entries at will), some of which could contain certificates, these entities
can potentially (intentionally or unintentionally) spoof others into
believing that certificates of subordinate entries belong to superior
entries.

>Its not rocket science but standard database stuff.
>After all, most LDAP servers support single master or multiple master replication. So what is all the fuss about?

These are services provided by and managed by LDAP servers.  The value
extraction approach, by its very nature, is managed by LDAP clients or,
as the pkix-pkc-schema document suggests, managed by the maintainer of
the directory service.

Kurt