[Ldap-dir] Review of draft-wahl-ldap-p3p
Kurt Zeilenga <Kurt.Zeilenga@Isode.com> Fri, 25 May 2007 14:24 UTC
Return-path: <ldap-dir-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hraid-0000aP-IP; Fri, 25 May 2007 10:24:39 -0400
Received: from ldap-dir by megatron.ietf.org with local (Exim 4.43) id 1Hraib-0000Yw-Fe for ldap-dir-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 10:24:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hraia-0000YY-R6; Fri, 25 May 2007 10:24:36 -0400
Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HraiY-0000wB-BR; Fri, 25 May 2007 10:24:36 -0400
Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <RlbxnwBlQL96@rufus.isode.com>; Fri, 25 May 2007 15:24:33 +0100
X-SMTP-Protocol-Errors: NORDNS
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <7039DF2B-2C9A-46DC-8D0E-16971083F942@Isode.com>
Content-Transfer-Encoding: 7bit
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
Date: Fri, 25 May 2007 07:24:27 -0700
To: Mark Wahl <Mark.Wahl@informed-control.com>, Chris Newman <Chris.Newman@Sun.COM>
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
Cc: Ldapext <ldapext@ietf.org>, ldap-dir@ietf.org, apps-review@ietf.org
Subject: [Ldap-dir] Review of draft-wahl-ldap-p3p
X-BeenThere: ldap-dir@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: LDAP Directorate <ldap-dir.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ldap-dir@ietf.org>
List-Help: <mailto:ldap-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ldap-dir>, <mailto:ldap-dir-request@ietf.org?subject=subscribe>
Errors-To: ldap-dir-bounces@ietf.org
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. _______________________________________________ Ldap-dir mailing list Ldap-dir@ietf.org https://www1.ietf.org/mailman/listinfo/ldap-dir
- [Ldap-dir] Review of draft-wahl-ldap-p3p Kurt Zeilenga