[ldapext] Review of draft-wahl-ldap-p3p

[Kurt Zeilenga <Kurt.Zeilenga@Isode.com>]

I reviewed this draft on behalf of the Apps Area Review team and the  
LDAP Directorate.
Such reviews have no special weight in the IETF.

Summary: This I-D specifies LDAP schema for holding URIs for privacy  
policy
documents.

Though it seems a good idea for a directory service to publish its
privacy policy information, I rather see the information stored in
the directory so that directory clients need not use another access
protocol.  Aside from avoiding complexity in client implementations,  
there
may be some security considerations specific to the use of a second  
protocol,
and second connection to retrieve the policy information.  The key  
issues
here center around trust.

Another issue with the expectation that an LDAP client can talk
HTTP, is that LDAP clients often use authentication and data services
which are not supported in HTTP.  For instance, LDAP supports SASL, and
HTTP doesn't.

I dislike "subtree scoped" attributes as they make it more difficult  
than
necessary for clients to obtain the information.

The last paragraph of page 7 says "Clients MUST NOT assume the  
absence of this
class in an entry's objectClass implies that the subtreeP3PrivacyPolicy
attribute is not present in the entry...."  This implies, however, that
a client can assume the absence of the subtreeP3PrivacyPolicy in results
requesting its return implies absence in the entry.  A client, of  
course,
cannot assume this.  Unfortunately, because of the apparent absence, the
client will likely go looking for this attribute in superior  
entries.  If
it finds one, or one in the Root DSE, the client will get the wrong  
privacy
policy.

I think it would be far better to define privacy policy in terms of the
LDAP/X.500 administrative model.  I note the community discussed use of
subtree policy attributes v. use of subentries on multiple occasions,
and seems to favor use of subentries (as evident by both ACI and  
password
policy proposals, initially submitted using subtree scoped  
attributes, to
being re-engineered to use subentries).  That said, these discussions  
may
not completely apply here.  More discussion is needed.

Lastly, a few minor things:

The serverP3PrivacyPolicy attribute likely should have usage  
dSAOperation
as it's DSA-specific (as are all root DSE attributes).

The last paragraph on page 7 says "... this attribute might ... be  
provided
through collective attributes".  However, as the attribute is not  
defined
as being COLLECTIVE, it simply cannot be provided as a collective  
attribute
(as defined in [RFC 3671]).  You likely meant something else.  I  
suggest you
say "provided by other means".   For instance, the attribute could be
specifically allowed by the controlling DIT content rule.

Should note that caseExactMatch is not designed for matching of URIs and
will return False for URIs which are equivalent, like http:// 
www.example.com
v. HTTP://WWW.EXAMPLE.COM.  Given serverP3PrivacyPolicy attribute is  
single
valued, use of caseIgnoreMatch might be more appropriate (as it will  
return
TRUE in cases such as the above).  Of course, caseIgnoreMatch will  
ignore
differences in URIs that are similar, like http://www.example.com/x and
http://www.example.com/X.  In either case, the inadequency of the  
matching
rule chosen should be discussed in the I-D (and possibly the security
considerations section.

Also note that the LDAP data preservation requirements is also  
problematic,
especially for the subtreeP3PrivacyPolicy (as its a user applications
attribute).   LDAP only requirements only require the server to return a
value which is equivalent per the matching rule.  To ensure the value is
actually preserved, it might be best to use octetString and  
octetStringMatch
to hold the URI.  The document likely should include a statement of  
how a
client is to treat a value which is not a valid URI.

The attribute type and object class definitions were line-wrapped for  
readability.
A note stating this is required (per Section 5 of BCP 118).

Should include a references for UTF-8, XML, and LDAP URL.  HTTP cite  
should be
on first mention.  Acronyms should be spelled out on first use in title,
in Abstract, and in body.



_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext