RE: Private email re LDAP and ;binary

From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 6 14:58:37 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29958 for ; Wed, 6 Feb 2002 14:58:37 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g16Ju6J30120; Wed, 6 Feb 2002 19:56:06 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 6 Feb 2002 19:56:06 +0000 Received: from smtp.opengroup.org (smtp.opengroup.org [192.153.166.4]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g16Ju3U30113 for ; Wed, 6 Feb 2002 19:56:03 GMT Received: from CHRIS-H.opengroup.org (dhcp192-153-166-45.rdg.opengroup.org [192.153.166.45]) by smtp.opengroup.org (8.11.6/8.11.6) with ESMTP id g16JtLg13720; Wed, 6 Feb 2002 19:55:21 GMT Message-Id: <5.1.0.14.1.20020206192832.06778cc0@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Feb 2002 19:37:04 +0000 To: ietf-ldapext@netscape.com, ietf-ldup@imc.org, ietf-ldapbis@OpenLDAP.org, ldap@umich.edu From: Chris Harding Subject: Directory Interoperability Forum Hosts its 2nd Plugfest, February 26 and 27, 2002 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_121644966==_.ALT" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: --=====================_121644966==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi - Test your applications for Works with LDAP 2000 compliance! The DIF's 2nd Plugfest offers you the opportunity to test your applications for interoperability with servers from leading vendors such as Oracle, Novell, IBM and more, all at the time and the same location. At our last Plugfest, 8 leading server vendors provided hardware and HP, PeopleSoft and SAP were among the 20 applications that tested and received the Open Group's Works with LDAP certification. Expand the market for your applications by providing prospects with guaranteed interoperability in a host of infrastructure environments. This event takes place February 26 and 27, 2002 in Redwood Shores, CA. The cost to participate is $495 dollars, which is waived when you choose to brand your application as Works with LDAP. More detailed information about this Plugfest and Works with LDAP certification is available at the DIF website at http://www.opengroup.org/dif/. Register on the web, or contact me. I look forward to seeing you, Regards, Chris +++++ ======================================================================== Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Mobile: +44 774 063 1520 ======================================================================== The Open Group Conference - "Managing The Mobile Workforce" Paris, France, 8-12 April 2002 http://www.opengroup.org/paris2002 ======================================================================== --=====================_121644966==_.ALT Content-Type: text/html; charset="us-ascii" Hi -

Test your applications for Works with LDAP 2000 compliance!

The DIF's 2nd Plugfest offers you the opportunity to test your applications for interoperability with servers from leading vendors such as Oracle, Novell, IBM and more, all at the time and the same location. At our last Plugfest, 8 leading server vendors provided hardware and HP, PeopleSoft and SAP were among the 20 applications that tested and received the Open Group's Works with LDAP certification.

Expand the market for your applications by providing prospects with guaranteed interoperability in a host of infrastructure environments.

This event takes place February 26 and 27, 2002 in Redwood Shores, CA. The cost to participate is $495 dollars, which is waived when you choose to brand your application as Works with LDAP.

More detailed information about this Plugfest and Works with LDAP certification is available at the DIF website at http://www.opengroup.org/dif/. Register on the web, or contact me.

I look forward to seeing you,

Regards,

Chris
+++++

======================================================================== Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Mobile: +44 774 063 1520 ========================================================================The Open Group Conference - "Managing The Mobile Workforce"
Paris, France, 8-12 April 2002
http://www.opengroup.org/paris2002
======================================================================== --=====================_121644966==_.ALT-- From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 7 23:29:30 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19458 for ; Thu, 7 Feb 2002 23:29:30 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g184R5f53988; Fri, 8 Feb 2002 04:27:06 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 8 Feb 2002 04:27:05 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g184R1U53981 for ; Fri, 8 Feb 2002 04:27:01 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g184R0C56430 for ; Fri, 8 Feb 2002 04:27:00 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020207195957.01774ec8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Feb 2002 20:27:27 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: DN/Filter quizzes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I've updated the quizzes based upon feedback from early reporters. http://www.openldap.org/ietf/ldapbis/dn.txt http://www.openldap.org/ietf/ldapbis/filters.txt I'd like to have one more independently developed client implementation and one more server implementation to round out the basic reporting. When reporting, please detail which implementations you have tested with. Also, please note any dependent implementations (such as dependency on U-Mich LDAP code). Kurt From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 10 18:45:53 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12118 for ; Sun, 10 Feb 2002 18:45:52 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1ANg8b42163; Sun, 10 Feb 2002 23:42:08 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Sun, 10 Feb 2002 23:42:08 +0000 Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1ANfpU42153 for ; Sun, 10 Feb 2002 23:41:54 GMT Received: (qmail 16516 invoked from network); 10 Feb 2002 23:29:25 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 10 Feb 2002 23:29:25 -0000 Reply-To: From: "Steven Legg" To: "'Hoyt L. Kesterson II'" , "'OSI Directory List'" , "'IETF LDAP'" , Subject: RE: RE: DTCs against X.520 / 9594-6 Date: Mon, 11 Feb 2002 10:40:11 +1100 Message-ID: <002901c1b28c$487690e0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Importance: Normal Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hoyt, Hoyt L. Kesterson II wrote: > sorry, forgot to copy to all recipients > > > Date: Fri, 8 Feb 2002 00:34:55 -0700 > To: > From: "Hoyt L. Kesterson II" > Subject: RE: DTCs against X.520 / 9594-6 > Cc: > Bcc: "ź:Directory:Defects" > X-Attachments: > > hi steven > > ok, i plea total confusion here. TelephoneNumber is a type that is > identical to PrintableString It is not identical because it has both an actual constraint, i.e. (SIZE(1..ub-telephone-number)) and a notional constraint, i.e. -- String complying with ITU-T Rec. E.123 only making it different from a vanilla PrintableString. LDAP reflects that difference by assigning different syntax OIDs to the two types. Knowing that a string is a telephone number rather than an arbitrary string of characters allows one to do interesting things like call connection in the DUA. > > is this a thing where ldap has assigned OIDs to syntaxes? and even > though the universal type is the same, it would be handy to align > with the specific type specified in the type assignment statement? Yes. I support both LDAP and X.500 so I have a requirement to translate between LDAP syntax OIDs and the ASN.1 types of X.500 attribute and assertion syntaxes. A one-to-one mapping between the two makes things easier for me. With the current definitions, an attribute or assertion syntax of PrintableString could map into either the LDAP Telephone Number syntax, 1.3.6.1.4.1.1466.115.121.1.50, or the LDAP Printable String syntax, 1.3.6.1.4.1.1466.115.121.1.44, depending on the attribute type or matching rule. It would be much better if TelephoneNumber were used instead of PrintableString in all cases of the former. > i > want to be sure that these are not attribute OIDs you are talking > about That's right. > > i don't have a problem with specifying TelephoneNumber in both > places. However, if we are going to do that, should we amend the > asn.1 definition of TelephoneNumber to constrain to the characters > allowed in E.123? You could. It may also be possible to formally constrain the format to be E.123 using the new PATTERN constraint of ASN.1. However, the most important thing for me is a one-to-one mapping between LDAP syntax OIDs and ASN.1 types. I don't mind if the constraints are specified only in ASN.1 comments, provided the constrained type has a distinct name. Regards, Steven > > if we agree on this, i'll need some country to put it on their ballot > for the dtc. > > hoyt > > >Hoyt, > > > >Hoyt L. Kesterson II wrote: > > > Although I had put the DTCs against X.520 / 9594-8 up on the > > > server, I neglected to announce them. The ballots on the DTCs > > > close 27 February. > > > > > > The DTCs clarify the handling of an attribute with a > > > NamedBitList syntax and add the definition of a matching rule > > > for facsimile number. There are two DTCs - one against the > > > 3rd edition, the other against the 4th. > > > >With regard to the matching rule for facsimile number, would it > >not be more appropriate for the assertion syntax for > >facsimileNumberMatch (and likewise for telephoneNumberMatch) to > >be TelephoneNumber rather than PrintableString ? > > > >This would align better with LDAP where the assertion syntax for > >telephoneNumberMatch is the same as the attribute syntax for > >telephoneNumber (i.e. 1.3.6.1.4.1.1466.115.121.1.50, corresponding > >to the TelephoneNumber ASN.1 type). The Printable String syntax > >in LDAP is distinctly separate and has the identifier > >1.3.6.1.4.1.1466.115.121.1.44. > > > >Regards, > >Steven > > > > > > > > They can be found on the server in Word and PDF formats at > > > > >ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTec hnicalCorrigend >a/closing26Feb2002/6N12080X.520DTC-4%283rd%29.doc > >ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigen d >a/closing26Feb2002/6N12080X.520DTC-4%283rd%29.pdf > >ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigen d >a/closing26Feb2002/6N12081X.520DTC-3%284th%29.doc > >ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigen d >a/closing26Feb2002/6N12081X.520DTC-3%284th%29.pdf > >The DTCs correct defect reports 287 and 288. They can be found at > >ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/AllDefec t >Reports/DR_287.pdf > >ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/AllDefec t >Reports/DR_288.pdf > > hoyt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 14 20:01:30 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13971 for ; Thu, 14 Feb 2002 20:01:29 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1F0vIg05746; Fri, 15 Feb 2002 00:57:18 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 15 Feb 2002 00:57:18 +0000 Received: from smtpproxy1.mitre.org (smtpproxy1.mitre.org [129.83.20.90]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1F0vGU05739 for ; Fri, 15 Feb 2002 00:57:16 GMT Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.11.3/8.11.3) with ESMTP id g1F0ut802936 for ; Thu, 14 Feb 2002 19:56:55 -0500 (EST) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtpsrv1.mitre.org (8.11.3/8.11.3) with ESMTP id g1F0urk26928 for ; Thu, 14 Feb 2002 19:56:53 -0500 (EST) Received: from mwestc012-mwmp1port6.mitre.org (128.29.250.6) by mailhub2.mitre.org with SMTP id 9257601; Thu, 14 Feb 2002 19:56:49 -0500 Message-ID: <3C6C5CD3.69045D4D@mitre.org> Date: Thu, 14 Feb 2002 19:56:51 -0500 From: Kathy Dally Organization: The MITRE Corporation X-Mailer: Mozilla 4.76 [en]C-20010313M (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: LDAPbis list Subject: length of octetstring Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi All! In the syntaxes draft (2252bis), a definition is needed for "octetstring". My proposal is below. The question is whether octetstring can be empty (that is, *OCTET)? The definition of OCTET, from [RFC 2234], is: OCTET = %x00-FF ; 8 bits of data octetstring = 1*OCTET Thanks, Kathy Dally From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 14 20:10:21 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14079 for ; Thu, 14 Feb 2002 20:10:20 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1F17SB06037; Fri, 15 Feb 2002 01:07:28 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 15 Feb 2002 01:07:28 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1F17RU06030 for ; Fri, 15 Feb 2002 01:07:27 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1F17KC99284; Fri, 15 Feb 2002 01:07:20 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020214170216.017c0fe8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 14 Feb 2002 17:07:35 -0800 To: Kathy Dally From: "Kurt D. Zeilenga" Subject: Re: length of octetstring Cc: LDAPbis list In-Reply-To: <3C6C5CD3.69045D4D@mitre.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 04:56 PM 2002-02-14, Kathy Dally wrote: >In the syntaxes draft (2252bis), a definition is needed for >"octetstring". My proposal is below. The question is whether >octetstring can be empty (that is, *OCTET)? Yes. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 14 20:12:21 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14106 for ; Thu, 14 Feb 2002 20:12:21 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1F19BD06066; Fri, 15 Feb 2002 01:09:11 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 15 Feb 2002 01:09:11 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1F199U06059 for ; Fri, 15 Feb 2002 01:09:09 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id <15RCXP71>; Fri, 15 Feb 2002 12:08:48 +1100 Message-ID: From: "Ramsay, Ron" To: Kathy Dally , LDAPbis list Subject: RE: length of octetstring Date: Fri, 15 Feb 2002 12:08:44 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Yes, it can. Ron. -----Original Message----- From: Kathy Dally [mailto:kdally@mitre.org] Sent: Friday, 15 February 2002 11:57 To: LDAPbis list Subject: length of octetstring Hi All! In the syntaxes draft (2252bis), a definition is needed for "octetstring". My proposal is below. The question is whether octetstring can be empty (that is, *OCTET)? The definition of OCTET, from [RFC 2234], is: OCTET = %x00-FF ; 8 bits of data octetstring = 1*OCTET Thanks, Kathy Dally From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 14 20:25:23 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14281 for ; Thu, 14 Feb 2002 20:25:22 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1F1MNL06486; Fri, 15 Feb 2002 01:22:23 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 15 Feb 2002 01:22:23 +0000 Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1F1MLU06476 for ; Fri, 15 Feb 2002 01:22:21 GMT Received: (qmail 25801 invoked from network); 15 Feb 2002 01:09:55 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 15 Feb 2002 01:09:55 -0000 Reply-To: From: "Steven Legg" To: "'Kathy Dally'" Cc: "'LDAPbis list'" Subject: RE: length of octetstring Date: Fri, 15 Feb 2002 12:21:06 +1100 Message-ID: <002401c1b5bf$0b065570$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <3C6C5CD3.69045D4D@mitre.org> Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kathy, Kathy Dally wrote: > Hi All! > > In the syntaxes draft (2252bis), a definition is needed for > "octetstring". My proposal is below. The question is whether > octetstring can be empty (that is, *OCTET)? In all the cases where the Octet String syntax is used in RFC 2256, the corresponding X.500 definition allows zero-length OCTET STRINGs, so *OCTET is appropriate. Regards, Steven > > The definition of OCTET, from [RFC 2234], is: > > OCTET = %x00-FF > ; 8 bits of data > > octetstring = 1*OCTET > > Thanks, > Kathy Dally > > From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 19 05:42:28 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13847 for ; Tue, 19 Feb 2002 05:42:27 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1JAdn848742; Tue, 19 Feb 2002 10:39:49 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Feb 2002 10:39:48 +0000 Received: from smtp.opengroup.org (smtp.opengroup.org [192.153.166.4]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1JAdXU48723 for ; Tue, 19 Feb 2002 10:39:39 GMT Received: from CHRIS-H.opengroup.org (dhcp192-153-166-52.rdg.opengroup.org [192.153.166.52]) by smtp.opengroup.org (8.11.6/8.11.6) with ESMTP id g1JAc7g04893; Tue, 19 Feb 2002 10:38:08 GMT Message-Id: <5.1.0.14.1.20020219103818.00ac6550@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 19 Feb 2002 10:40:22 +0000 To: ietf-ldapext@netscape.com, ietf-ldup@imc.org, ietf-ldapbis@OpenLDAP.org, ldap@umich.edu From: Chris Harding Subject: Plugfest - Last Chance to Register Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_4233607==_.ALT" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: --=====================_4233607==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi - Registrations close tomorrow! (At midnight PST on, Wednesday February 20th). >Test your applications for Works with LDAP 2000 compliance! > >The DIF's 2nd Plugfest offers you the opportunity to test your >applications for interoperability with servers from leading vendors such >as Oracle, Novell, IBM and more, all at the time and the same location. At >our last Plugfest, 8 leading server vendors provided hardware and HP, >PeopleSoft and SAP were among the 20 applications that tested and received >the Open Group's Works with LDAP certification. > >Expand the market for your applications by providing prospects with >guaranteed interoperability in a host of infrastructure environments. > >This event takes place February 26 and 27, 2002 in Redwood Shores, CA. The >cost to participate is $495 dollars, which is waived when you choose to >brand your application as Works with LDAP. > >More detailed information about this Plugfest and Works with LDAP >certification is available at the DIF website at >http://www.opengroup.org/dif/. Register on the web, or contact me. > >I look forward to seeing you, Regards, Chris +++++ ======================================================================== Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Mobile: +44 774 063 1520 ======================================================================== The Open Group Conference - "Managing The Mobile Workforce" Paris, France, 8-12 April 2002 http://www.opengroup.org/paris2002 ======================================================================== --=====================_4233607==_.ALT Content-Type: text/html; charset="us-ascii" Hi - Registrations close tomorrow! (At midnight PST on, Wednesday February 20th). Test your applications for Works with LDAP 2000 compliance! The DIF's 2nd Plugfest offers you the opportunity to test your applications for interoperability with servers from leading vendors such as Oracle, Novell, IBM and more, all at the time and the same location. At our last Plugfest, 8 leading server vendors provided hardware and HP, PeopleSoft and SAP were among the 20 applications that tested and received the Open Group's Works with LDAP certification. Expand the market for your applications by providing prospects with guaranteed interoperability in a host of infrastructure environments. This event takes place February 26 and 27, 2002 in Redwood Shores, CA. The cost to participate is $495 dollars, which is waived when you choose to brand your application as Works with LDAP. More detailed information about this Plugfest and Works with LDAP certification is available at the DIF website at http://www.opengroup.org/dif/. Register on the web, or contact me. I look forward to seeing you, Regards, Chris +++++ ======================================================================== Dr. Christopher J. Harding T H E Executive Director for the Directory Interoperability Forum O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Phone: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Mobile: +44 774 063 1520 ======================================================================== The Open Group Conference - "Managing The Mobile Workforce" Paris, France, 8-12 April 2002 http://www.opengroup.org/paris2002 ======================================================================== --=====================_4233607==_.ALT-- From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 19 12:40:00 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28722 for ; Tue, 19 Feb 2002 12:39:59 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1JHbs967150; Tue, 19 Feb 2002 17:37:54 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Feb 2002 17:37:54 +0000 Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1JHbpU67142 for ; Tue, 19 Feb 2002 17:37:51 GMT Received: from [194.249.69.6] (helo=salford.ac.uk) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 16dED4-0000lp-00; Tue, 19 Feb 2002 17:37:46 +0000 Message-ID: <3C728DFA.4819D0DC@salford.ac.uk> Date: Tue, 19 Feb 2002 17:40:10 +0000 From: David Chadwick Organization: University of Salford X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christopher Oliva CC: Sharon Boeyen , LDAP BIS Subject: Re: Private email re LDAP and ;binary References: Content-Type: multipart/mixed; boundary="------------0F4BC7002B38338632A93FAD" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. --------------0F4BC7002B38338632A93FAD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Chris I have copied this to the LDAPBis group for their comments > Christopher Oliva wrote: > > Hi David, > > thanks very much for your response. > > I have a few more questions related to this issue. > > Given that the current Certificate, CertificateList (etc) definitions > are now contained within the PKIX draft > (http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-schema-02.txt), > should the discussion about this be directed to the PKIX group ? Well the problem is that the PKIX group dont know much about LDAP. So I would prefer the LDAPbis folks to be involved since they do know a lot about LDAP and about certificates in general. They dont really need to know about PKIs to be able to comment on the schema specification and how LDAP carries certificates. >I > believe the arrangement with LDAPbis was to remove the Certificate > (etc.) definitions from their I-Ds. I suppose in this case, that it > would be up to the PKIX working group to progress changes to the draft > (and these syntax definitions) ? > This is correct. All the X.509 attributes have been removed from core LDAP and are now in Steven's and my ID > The only argument for insisting on the mandatory ";binary" is the > possibility that the old RFC 1778 string formats will be presented in > a response. However, those old RFC 1778 syntaxes were updated by RFC > 2559. > Yes, I guess you are correct. The ;binary was really a hack job to cater for the broken string encoding of certificates. I dont really see why we need to use it now, if the PKIX document states specifically what the LDAP transfer syntax is, we should just be able to just simply ask for certificates (without ;binary) and get BER back. Since BER is the only recognised syntax in the latest specification. > Also, any directory server that supports PKIX (and the X.509 v2 CRL > syntax and v3 Certificate syntax) must support the ability to encode > X.509 extensions in their response (and clients to encode this to add > new values). It does not appear that it is possible to encode > extensions in the broken RFC 1778 string syntaxes. Yes, I agree with all of the above > Therefore the only > option (prior to ldapv3) is the "undefined" syntax of RFC 1778 which > is equivalent to the ";binary" encoding and RFC 2559. Cant comment on that without further review, which I dont have time for at the moment. >This would mean > that any server supporting v2 CRL and v3 Certificates cannot possibly > be returning/accepting the RFC 1778 string syntax therefore > eliminating that argument. > < stuff cut from earlier emails>> > > > > Now this has changed so that the ";binary" option is no longer a > > subtype (see section 4.1.5 of > > > http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-06.txt). > > > This means that current products requesting "userCertificate" in > > requests would no longer be valid queries. > > > > Instead, it would be preferable to see the Certificate, > > CertificatePair and CertificateList syntaxes in ldap have a "native > > encoding" that is equivalent to the asn.1/binary encoding used when > > the ";binary" option is specified. This will allow userCertificate > to > > be requested without ";binary". > > I think the above is perfectly reasonable. I suggest you raise this > issue on the LDAP bis email list to get their response. I am currently > > not participating in the LDAP bis work. (However note that there is a > difference between returning a binary attribute and an attribute with > ;binary. You get an extra TLV wrapping with one - the former I think) > > David > --------------0F4BC7002B38338632A93FAD Content-Type: text/x-vcard; charset=us-ascii; name="d.w.chadwick.vcf" Content-Description: Card for David Chadwick Content-Disposition: attachment; filename="d.w.chadwick.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Chadwick;David tel;cell:+44 77 96 44 7184 tel;fax:+44 1484 532930 tel;home:+44 1484 352238 tel;work:+44 161 295 5351 x-mozilla-html:FALSE url:http://www.salford.ac.uk/its024/chadwick.htm org:University of Salford;IS Institute version:2.1 email;internet:d.w.chadwick@salford.ac.uk title:Professor of Information Security adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5 x-mozilla-cpt:;-4856 fn:David Chadwick end:vcard --------------0F4BC7002B38338632A93FAD-- From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 19 13:32:12 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00524 for ; Tue, 19 Feb 2002 13:32:08 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1JIUA368576; Tue, 19 Feb 2002 18:30:10 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Feb 2002 18:30:09 +0000 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1JIU7U68568 for ; Tue, 19 Feb 2002 18:30:07 GMT Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id g1JITi711065 for ; Tue, 19 Feb 2002 10:29:45 -0800 (PST) Received: from netscape.com ([10.169.184.46]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GRSM1K01.GDI; Tue, 19 Feb 2002 10:29:44 -0800 Message-ID: <3C729994.7030409@netscape.com> Date: Tue, 19 Feb 2002 13:29:40 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: David Chadwick CC: Christopher Oliva , Sharon Boeyen , LDAP BIS Subject: Re: Private email re LDAP and ;binary References: <3C728DFA.4819D0DC@salford.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit David Chadwick wrote: > >>The only argument for insisting on the mandatory ";binary" is the >>possibility that the old RFC 1778 string formats will be presented in >>a response. However, those old RFC 1778 syntaxes were updated by RFC >>2559. >> >> > > Yes, I guess you are correct. The ;binary was really a hack job to cater > for the broken string encoding of certificates. I dont really see why we > need to use it now, if the PKIX document states specifically what the > LDAP transfer syntax is, we should just be able to just simply ask for > certificates (without ;binary) and get BER back. Since BER is the only > recognised syntax in the latest specification. Do you care about backwards compatibility? Any change to the on-the-wire protocol for retrieving certificates over LDAPv3 makes me nervous. The entire installed base of LDAPv3 servers and clients uses an AttributeDescription of userCertificate;binary, as mandated by RFC 2252. Now you are suggesting that we change all clients and servers to use userCertificate. What value does such a change really have? Why propose such a change when it will very likely break some existing implementations? -Mark Smith Netscape From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 19 15:14:27 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03938 for ; Tue, 19 Feb 2002 15:14:27 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1JKCFo71879; Tue, 19 Feb 2002 20:12:16 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Feb 2002 20:12:15 +0000 Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1JKCCU71872 for ; Tue, 19 Feb 2002 20:12:13 GMT Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Feb 2002 15:13:57 -0500 Message-ID: From: Christopher Oliva To: "'mcs@netscape.com'" , David Chadwick Cc: Christopher Oliva , Sharon Boeyen , LDAP BIS Subject: RE: Private email re LDAP and ;binary Date: Tue, 19 Feb 2002 15:13:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B981.F5A7A910" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B981.F5A7A910 Content-Type: text/plain; charset="iso-8859-1" I don't believe the suggestion was to eliminate ";binary". I won't speak for David but I believe the suggestion is to make the default encoding for Certificate, Certificate List and Certificate Pair the BER encoding. This means that it would not be necessary to use ";binary" but if it were used, everything will work as expected. I'm glad you mentioned backwards compatibility because this change would enable compatibility with ldapv2 and RFC 2559. When ldapv3 was deployed many systems that were already deployed became broken because of the stringent ";binary" requirement. So in order to truly fix backwards compatibility, the ";binary" rules must be relaxed. This proposed fix would only apply to servers (not clients) and increase interoperability as well as backwards compatibility. Chris. -----Original Message----- From: mcs@netscape.com [mailto:mcs@netscape.com] Sent: Tuesday, February 19, 2002 1:30 PM To: David Chadwick Cc: Christopher Oliva; Sharon Boeyen; LDAP BIS Subject: Re: Private email re LDAP and ;binary David Chadwick wrote: > >>The only argument for insisting on the mandatory ";binary" is the >>possibility that the old RFC 1778 string formats will be presented in >>a response. However, those old RFC 1778 syntaxes were updated by RFC >>2559. >> >> > > Yes, I guess you are correct. The ;binary was really a hack job to cater > for the broken string encoding of certificates. I dont really see why we > need to use it now, if the PKIX document states specifically what the > LDAP transfer syntax is, we should just be able to just simply ask for > certificates (without ;binary) and get BER back. Since BER is the only > recognised syntax in the latest specification. Do you care about backwards compatibility? Any change to the on-the-wire protocol for retrieving certificates over LDAPv3 makes me nervous. The entire installed base of LDAPv3 servers and clients uses an AttributeDescription of userCertificate;binary, as mandated by RFC 2252. Now you are suggesting that we change all clients and servers to use userCertificate. What value does such a change really have? Why propose such a change when it will very likely break some existing implementations? -Mark Smith Netscape ------_=_NextPart_001_01C1B981.F5A7A910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Private email re LDAP and ;binary I don't believe the suggestion was to eliminate = ";binary". I won't speak for David but I believe the = suggestion is to make the default encoding for Certificate, Certificate = List and Certificate Pair the BER encoding. This means that it would = not be necessary to use ";binary" but if it were used, = everything will work as expected. I'm glad you mentioned backwards compatibility = because this change would enable compatibility with ldapv2 and RFC = 2559. When ldapv3 was deployed many systems that were already deployed = became broken because of the stringent ";binary" requirement. = So in order to truly fix backwards compatibility, the = ";binary" rules must be relaxed. This proposed fix would only apply to servers (not = clients) and increase interoperability as well as backwards = compatibility. Chris. -----Original Message----- From: mcs@netscape.com [mailto:mcs@netscape.com] Sent: Tuesday, February 19, 2002 1:30 PM To: David Chadwick Cc: Christopher Oliva; Sharon Boeyen; LDAP = BIS Subject: Re: Private email re LDAP and = ;binary David Chadwick wrote: > >>The only argument for insisting on the = mandatory ";binary" is the >>possibility that the old RFC 1778 string = formats will be presented in >>a response. However, those old RFC 1778 = syntaxes were updated by RFC >>2559. >> >> > > Yes, I guess you are correct. The ;binary was = really a hack job to cater > for the broken string encoding of certificates. = I dont really see why we > need to use it now, if the PKIX document states = specifically what the > LDAP transfer syntax is, we should just be able = to just simply ask for > certificates (without ;binary) and get BER = back. Since BER is the only > recognised syntax in the latest = specification. Do you care about backwards compatibility? Any change = to the on-the-wire protocol for retrieving certificates over LDAPv3 = makes me nervous. The entire installed base of LDAPv3 servers and clients = uses an AttributeDescription of userCertificate;binary, as = mandated by RFC 2252. Now you are suggesting that we change all clients = and servers to use userCertificate. What value does such a change = really have? Why propose such a change when it will very likely break some = existing implementations? -Mark Smith Netscape ------_=_NextPart_001_01C1B981.F5A7A910-- From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 19 15:45:02 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04941 for ; Tue, 19 Feb 2002 15:45:01 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1JKh1773342; Tue, 19 Feb 2002 20:43:01 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Feb 2002 20:43:01 +0000 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1JKh0U73335 for ; Tue, 19 Feb 2002 20:43:00 GMT Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id g1JKgc708969 for ; Tue, 19 Feb 2002 12:42:38 -0800 (PST) Received: from netscape.com ([10.169.184.15]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GRSS7200.SGC; Tue, 19 Feb 2002 12:42:38 -0800 Message-ID: <3C72B8BC.50509@netscape.com> Date: Tue, 19 Feb 2002 15:42:36 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Christopher Oliva CC: David Chadwick , Sharon Boeyen , LDAP BIS Subject: Re: Private email re LDAP and ;binary References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Christopher Oliva wrote: > > I don't believe the suggestion was to eliminate ";binary". I won't speak > for David but I believe the suggestion is to make the default encoding > for Certificate, Certificate List and Certificate Pair the BER encoding. > This means that it would not be necessary to use ";binary" but if it > were used, everything will work as expected. Okay. > I'm glad you mentioned backwards compatibility because this change would > enable compatibility with ldapv2 and RFC 2559. When ldapv3 was deployed > many systems that were already deployed became broken because of the > stringent ";binary" requirement. So in order to truly fix backwards > compatibility, the ";binary" rules must be relaxed. LDAPv2 is dead. Long live LDAPv3. Which is to say, let's not break things again. > This proposed fix would only apply to servers (not clients) and increase > interoperability as well as backwards compatibility. Would the standards advise clients to use ;binary in the AttributeDescription or not? If not, then the proposed change does apply to clients as well as to servers. -Mark From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 19 16:06:45 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05576 for ; Tue, 19 Feb 2002 16:06:44 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1JL4lJ74020; Tue, 19 Feb 2002 21:04:47 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 19 Feb 2002 21:04:46 +0000 Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1JL4hU74013 for ; Tue, 19 Feb 2002 21:04:44 GMT Received: from [194.249.69.6] (helo=salford.ac.uk) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 16dHQn-00020z-00; Tue, 19 Feb 2002 21:04:10 +0000 Message-ID: <3C72BE4D.942D45D7@salford.ac.uk> Date: Tue, 19 Feb 2002 21:06:21 +0000 From: David Chadwick Organization: University of Salford X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark C Smith CC: Christopher Oliva , Sharon Boeyen , LDAP BIS Subject: Re: Private email re LDAP and ;binary References: <3C728DFA.4819D0DC@salford.ac.uk> <3C729994.7030409@netscape.com> Content-Type: multipart/mixed; boundary="------------619E0D981419CC1E2F861E90" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. --------------619E0D981419CC1E2F861E90 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark C Smith wrote: > Do you care about backwards compatibility? Yes. We must be backwards compatible with LDAPv3 as a minimum. But note that up until now, LDAPv3 has not defined matching rules for any X.509 stuff, nor the syntax for many of the X.509 data structures. SO the PKIX document is the first one in which syntaxes have been specified for everything in X.509. Thus my point is, once syntaxes are specified and known about, then the attributes and assertion values can be carried in their known-about syntaxes, without any special instructions (such as ;binary) being needed. ;binary becomes an anachronism from the past and can quietly die. But it will be needed during a period of migration for those LDAPv3 servers that DONT know the syntaxes of the X.509 stuff so that they will still be able to transfer it correctly. Therefore we should allow for both now, with the intention of phasing out ;binary in the next version (or when it goes to full standard, say). Thus my suggestion is that if ;binary is not used, the client and the server must know what they are dealing with, and what its syntax is. Values are carried in BER format. However, if ;binary is used, those products that understand the syntax simply ignore the ;binary, those that dont know the syntax, know they have to transfer the data as BER encoded octets. >Any change to the on-the-wire > protocol for retrieving certificates over LDAPv3 makes me nervous. The > entire installed base of LDAPv3 servers and clients uses an > AttributeDescription of userCertificate;binary, as mandated by RFC 2252. I agree, they do (or should do!!) But note that the entire installed base of LDAPv2 clients and servers (if there are many left) dont use ;binary and can still transfer X.509 stuff successfully. So ;binary is not essential for certificates to work. > Now you are suggesting that we change all clients and servers to use > userCertificate. No, not at all. Here's how it would work in practice V3 Server Older V3 Server Understands Does not understand Client sends OK Error userCertificate Client sends userCert;binary OK OK So we have a problem with older LDAPv3 servers who dont know much about the syntax of the X.509 stuff they are storing, just that it should be sent and received in BER format using ;binary. (they wont know how to match on values either). Clearly if a client tries to add a certificate to one of these servers without using ;binary, (this could be a v3 client evolved from a v2 one for example) the server should reject it. Thats OK. If another client uses ;binary the certificate can be stored, but if the original client then tries to retrieve it, it will fail. So the rule for clients is, to be on the safe side in the short to medium term, use ;binary. My question to the server guys is "once you understand the syntax of X.509 attributes and assertion values, why do you want ;binary to be there?" You probably dont, so will be glad to see it go. My question to v2 client migrators is "what is the big deal in adding ;binary to the X.509 attribute requests, since you will have to be making other changes anyway when you migrate to v3" > What value does such a change really have? Why propose > such a change when it will very likely break some existing implementations? > I guess in short, it tidies things up for the future, and removes an anomaly from the standard. David > -Mark Smith > Netscape -- ***************************************************************** 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 161 745 8169 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Understanding X.500: http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** --------------619E0D981419CC1E2F861E90 Content-Type: text/x-vcard; charset=us-ascii; name="d.w.chadwick.vcf" Content-Description: Card for David Chadwick Content-Disposition: attachment; filename="d.w.chadwick.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Chadwick;David tel;cell:+44 77 96 44 7184 tel;fax:+44 1484 532930 tel;home:+44 1484 352238 tel;work:+44 161 295 5351 x-mozilla-html:FALSE url:http://www.salford.ac.uk/its024/chadwick.htm org:University of Salford;IS Institute version:2.1 email;internet:d.w.chadwick@salford.ac.uk title:Professor of Information Security adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5 x-mozilla-cpt:;-4856 fn:David Chadwick end:vcard --------------619E0D981419CC1E2F861E90-- From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 19 19:08:50 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08852 for ; Tue, 19 Feb 2002 19:08:49 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1K06d378102; Wed, 20 Feb 2002 00:06:39 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 20 Feb 2002 00:06:38 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1K06WU78095 for ; Wed, 20 Feb 2002 00:06:33 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Wed, 20 Feb 2002 11:06:14 +1100 Message-ID: From: "Ramsay, Ron" To: David Chadwick , Mark C Smith Cc: Christopher Oliva , Sharon Boeyen , LDAP BIS Subject: RE: Private email re LDAP and ;binary Date: Wed, 20 Feb 2002 11:06:15 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I think you've left out V2 client sends certificate;binary to V3 server which replies with certificate, which may not be handled properly by the client. It would be interesting to know how the common servers respond to a request for certificate, sans ;binary. Ron. -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] Sent: Wednesday, 20 February 2002 8:06 To: Mark C Smith Cc: Christopher Oliva; Sharon Boeyen; LDAP BIS Subject: Re: Private email re LDAP and ;binary Mark C Smith wrote: > Do you care about backwards compatibility? Yes. We must be backwards compatible with LDAPv3 as a minimum. But note that up until now, LDAPv3 has not defined matching rules for any X.509 stuff, nor the syntax for many of the X.509 data structures. SO the PKIX document is the first one in which syntaxes have been specified for everything in X.509. Thus my point is, once syntaxes are specified and known about, then the attributes and assertion values can be carried in their known-about syntaxes, without any special instructions (such as ;binary) being needed. ;binary becomes an anachronism from the past and can quietly die. But it will be needed during a period of migration for those LDAPv3 servers that DONT know the syntaxes of the X.509 stuff so that they will still be able to transfer it correctly. Therefore we should allow for both now, with the intention of phasing out ;binary in the next version (or when it goes to full standard, say). Thus my suggestion is that if ;binary is not used, the client and the server must know what they are dealing with, and what its syntax is. Values are carried in BER format. However, if ;binary is used, those products that understand the syntax simply ignore the ;binary, those that dont know the syntax, know they have to transfer the data as BER encoded octets. >Any change to the on-the-wire > protocol for retrieving certificates over LDAPv3 makes me nervous. The > entire installed base of LDAPv3 servers and clients uses an > AttributeDescription of userCertificate;binary, as mandated by RFC 2252. I agree, they do (or should do!!) But note that the entire installed base of LDAPv2 clients and servers (if there are many left) dont use ;binary and can still transfer X.509 stuff successfully. So ;binary is not essential for certificates to work. > Now you are suggesting that we change all clients and servers to use > userCertificate. No, not at all. Here's how it would work in practice V3 Server Older V3 Server Understands Does not understand Client sends OK Error userCertificate Client sends userCert;binary OK OK So we have a problem with older LDAPv3 servers who dont know much about the syntax of the X.509 stuff they are storing, just that it should be sent and received in BER format using ;binary. (they wont know how to match on values either). Clearly if a client tries to add a certificate to one of these servers without using ;binary, (this could be a v3 client evolved from a v2 one for example) the server should reject it. Thats OK. If another client uses ;binary the certificate can be stored, but if the original client then tries to retrieve it, it will fail. So the rule for clients is, to be on the safe side in the short to medium term, use ;binary. My question to the server guys is "once you understand the syntax of X.509 attributes and assertion values, why do you want ;binary to be there?" You probably dont, so will be glad to see it go. My question to v2 client migrators is "what is the big deal in adding ;binary to the X.509 attribute requests, since you will have to be making other changes anyway when you migrate to v3" > What value does such a change really have? Why propose > such a change when it will very likely break some existing implementations? > I guess in short, it tidies things up for the future, and removes an anomaly from the standard. David > -Mark Smith > Netscape -- ***************************************************************** 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 161 745 8169 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Understanding X.500: http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 20 11:23:21 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05298 for ; Wed, 20 Feb 2002 11:23:20 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1KGJbm18704; Wed, 20 Feb 2002 16:19:37 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 20 Feb 2002 16:19:37 +0000 Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1KGJVU18697 for ; Wed, 20 Feb 2002 16:19:31 GMT Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Feb 2002 11:17:57 -0500 Message-ID: From: Christopher Oliva To: "'Ramsay, Ron'" , David Chadwick , Mark C Smith Cc: Christopher Oliva , Sharon Boeyen , LDAP BIS Subject: RE: Private email re LDAP and ;binary Date: Wed, 20 Feb 2002 11:20:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA2A.753F9AE0" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA2A.753F9AE0 Content-Type: text/plain; charset="iso-8859-1" In my experience, the ldap servers that exhibit a problem with ";binary" do not distinguish between ldapv2 or ldapv3 in a search request (when it comes to ";binary"-correctness). They treat both identically. I have also noticed that some of these servers tend to respond based on how a request was constructed - if the search asked for ";binary", then the ";binary" is used in the response and vice versa. There is a more problematic category of server ... for these, one version of the search (;binary or not) will fail. Usually, this depends on how the attribute was added to the server in the first place. If it was added with ";binary" then only ";binary" will work (even in ldapv2). If it was added without ";binary" (even in ldapv2), then a search using ";binary" (even in ldapv3) will fail. The next question will be: how should a server respond when the attribute name isn't explicitly requested? Current servers will do one of two things: 1) use ";binary" only if ";binary" was used when the attribute was added (regardless of whether this was done in ldapv2 or ldapv3) 2) return ;binary by default in ldapv3. Some will remove the ";binary" in an ldapv2 response, which, in my opinion, is the correct thing to do. If I had to pick an option, it would be (2). I will spare you from talking about what happens when you use a search filter like "userCertificate=*" or "userCertificate;binary=*" which only result in more chaos. I also will only mention that trying to follow referrals between such servers is quite challenging. You may also ask why I care about ldapv2 - because there are customers using ldapv2 that must migrate to ldapv3. In my opinion, ";binary" has caused more problems then it solved. It should either be eliminated or neutralized. That is why the changes that have been proposed must be applied. Chris. -----Original Message----- From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com] Sent: Tuesday, February 19, 2002 7:06 PM To: David Chadwick; Mark C Smith Cc: Christopher Oliva; Sharon Boeyen; LDAP BIS Subject: RE: Private email re LDAP and ;binary I think you've left out V2 client sends certificate;binary to V3 server which replies with certificate, which may not be handled properly by the client. It would be interesting to know how the common servers respond to a request for certificate, sans ;binary. Ron. -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] Sent: Wednesday, 20 February 2002 8:06 To: Mark C Smith Cc: Christopher Oliva; Sharon Boeyen; LDAP BIS Subject: Re: Private email re LDAP and ;binary Mark C Smith wrote: > Do you care about backwards compatibility? Yes. We must be backwards compatible with LDAPv3 as a minimum. But note that up until now, LDAPv3 has not defined matching rules for any X.509 stuff, nor the syntax for many of the X.509 data structures. SO the PKIX document is the first one in which syntaxes have been specified for everything in X.509. Thus my point is, once syntaxes are specified and known about, then the attributes and assertion values can be carried in their known-about syntaxes, without any special instructions (such as ;binary) being needed. ;binary becomes an anachronism from the past and can quietly die. But it will be needed during a period of migration for those LDAPv3 servers that DONT know the syntaxes of the X.509 stuff so that they will still be able to transfer it correctly. Therefore we should allow for both now, with the intention of phasing out ;binary in the next version (or when it goes to full standard, say). Thus my suggestion is that if ;binary is not used, the client and the server must know what they are dealing with, and what its syntax is. Values are carried in BER format. However, if ;binary is used, those products that understand the syntax simply ignore the ;binary, those that dont know the syntax, know they have to transfer the data as BER encoded octets. >Any change to the on-the-wire > protocol for retrieving certificates over LDAPv3 makes me nervous. The > entire installed base of LDAPv3 servers and clients uses an > AttributeDescription of userCertificate;binary, as mandated by RFC 2252. I agree, they do (or should do!!) But note that the entire installed base of LDAPv2 clients and servers (if there are many left) dont use ;binary and can still transfer X.509 stuff successfully. So ;binary is not essential for certificates to work. > Now you are suggesting that we change all clients and servers to use > userCertificate. No, not at all. Here's how it would work in practice V3 Server Older V3 Server Understands Does not understand Client sends OK Error userCertificate Client sends userCert;binary OK OK So we have a problem with older LDAPv3 servers who dont know much about the syntax of the X.509 stuff they are storing, just that it should be sent and received in BER format using ;binary. (they wont know how to match on values either). Clearly if a client tries to add a certificate to one of these servers without using ;binary, (this could be a v3 client evolved from a v2 one for example) the server should reject it. Thats OK. If another client uses ;binary the certificate can be stored, but if the original client then tries to retrieve it, it will fail. So the rule for clients is, to be on the safe side in the short to medium term, use ;binary. My question to the server guys is "once you understand the syntax of X.509 attributes and assertion values, why do you want ;binary to be there?" You probably dont, so will be glad to see it go. My question to v2 client migrators is "what is the big deal in adding ;binary to the X.509 attribute requests, since you will have to be making other changes anyway when you migrate to v3" > What value does such a change really have? Why propose > such a change when it will very likely break some existing implementations? > I guess in short, it tidies things up for the future, and removes an anomaly from the standard. David > -Mark Smith > Netscape -- ***************************************************************** 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 161 745 8169 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Understanding X.500: http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** ------_=_NextPart_001_01C1BA2A.753F9AE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Private email re LDAP and ;binary In my experience, the ldap servers that exhibit a = problem with ";binary" do not distinguish between ldapv2 or = ldapv3 in a search request (when it comes to = ";binary"-correctness). They treat both = identically. I have also noticed that some of these servers tend = to respond based on how a request was constructed - if the search asked = for ";binary", then the ";binary" is used in the = response and vice versa. There is a more problematic category of server ... = for these, one version of the search (;binary or not) will fail. = Usually, this depends on how the attribute was added to the server in = the first place. If it was added with ";binary" then only = ";binary" will work (even in ldapv2). If it was added without = ";binary" (even in ldapv2), then a search using = ";binary" (even in ldapv3) will fail. The next question will be: how should a server = respond when the attribute name isn't explicitly requested? Current servers will do one of two things: 1) use ";binary" only if = ";binary" was used when the attribute was added (regardless = of whether this was done in ldapv2 or ldapv3) 2) return ;binary by default in ldapv3. Some will = remove the ";binary" in an ldapv2 response, which, in my = opinion, is the correct thing to do. If I had to pick an option, it would be (2). I will spare you from talking about what happens when = you use a search filter like "userCertificate=3D*" or = "userCertificate;binary=3D*" which only result in more chaos. = I also will only mention that trying to follow referrals between such = servers is quite challenging. You may also ask why I care about ldapv2 = - because there are customers using ldapv2 that must migrate to = ldapv3. In my opinion, ";binary" has caused more = problems then it solved. It should either be eliminated or neutralized. = That is why the changes that have been proposed must be = applied. Chris. -----Original Message----- From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com] Sent: Tuesday, February 19, 2002 7:06 PM To: David Chadwick; Mark C Smith Cc: Christopher Oliva; Sharon Boeyen; LDAP = BIS Subject: RE: Private email re LDAP and = ;binary I think you've left out V2 client sends certificate;binary to V3 server which = replies with certificate, which may not be handled properly by = the client. It would be interesting to know how the common = servers respond to a request for certificate, sans ;binary. Ron. -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@salford.a= c.uk] Sent: Wednesday, 20 February 2002 8:06 To: Mark C Smith Cc: Christopher Oliva; Sharon Boeyen; LDAP BIS= Subject: Re: Private email re LDAP and = ;binary Mark C Smith wrote: > Do you care about backwards compatibility? = Yes. We must be backwards compatible with LDAPv3 as a = minimum. But note that up until now, LDAPv3 has not defined matching = rules for any X.509 stuff, nor the syntax for many of the X.509 data = structures. SO the PKIX document is the first one in which syntaxes have = been specified for everything in X.509. Thus my point is, once syntaxes = are specified and known about, then the attributes and assertion = values can be carried in their known-about syntaxes, without any special = instructions (such as ;binary) being needed. ;binary becomes an = anachronism from the past and can quietly die. But it will be needed during a period of migration = for those LDAPv3 servers that DONT know the syntaxes of the X.509 stuff so that they will still = be able to transfer it correctly. Therefore we should allow for both now, with the = intention of phasing out ;binary in the next version (or when it goes to = full standard, say). Thus my suggestion is that if ;binary is not used, = the client and the server must know what they are dealing with, and = what its syntax is. Values are carried in BER format. However, if = ;binary is used, those products that understand the syntax simply ignore = the ;binary, those that dont know the syntax, know they have to = transfer the data as BER encoded octets. >Any change to the on-the-wire > protocol for retrieving certificates over = LDAPv3 makes me nervous. The > entire installed base of LDAPv3 servers and = clients uses an > AttributeDescription of userCertificate;binary, = as mandated by RFC 2252. I agree, they do (or should do!!) But note that the entire installed base of LDAPv2 = clients and servers (if there are many left) dont use ;binary and can = still transfer X.509 stuff successfully. So ;binary is not essential for = certificates to work. > Now you are suggesting that we change all = clients and servers to use > userCertificate. No, not at all. Here's how it would work in = practice &nb= sp; V3 = Server = Older V3 Server &nb= sp; = Understands &= nbsp; Does not understand Client = sends = OK &nbs= p; Error userCertificate = Client sends userCert;binary = OK &nbs= p; OK So we have a problem with older LDAPv3 servers who = dont know much about the syntax of the X.509 stuff they are storing, just = that it should be sent and received in BER format using ;binary. (they wont = know how to match on values either). Clearly if a client tries to add = a certificate to one of these servers without using ;binary, (this could = be a v3 client evolved from a v2 one for example) the server should = reject it. Thats OK. If another client uses ;binary the certificate = can be stored, but if the original client then tries to retrieve it, it = will fail. So the rule for clients is, to be on the safe side in the short = to medium term, use ;binary. My question to the server guys is "once you = understand the syntax of X.509 attributes and assertion values, why do you = want ;binary to be there?" You probably dont, so will be glad to = see it go. My question to v2 client migrators is "what is = the big deal in adding ;binary to the X.509 attribute requests, since you = will have to be making other changes anyway when you migrate to = v3" > What value does such a change really have? Why = propose > such a change when it will very likely break = some existing implementations? > I guess in short, it tidies things up for the future, = and removes an anomaly from the standard. David > -Mark Smith > Netscape -- ***************************************************************= ** 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 161 745 = 8169 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Understanding X.500: http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************= ** ------_=_NextPart_001_01C1BA2A.753F9AE0-- From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 20 12:55:33 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11087 for ; Wed, 20 Feb 2002 12:55:31 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1KHqAa31970; Wed, 20 Feb 2002 17:52:19 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 20 Feb 2002 17:52:10 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1KHq8U31961 for ; Wed, 20 Feb 2002 17:52:08 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1KHpwC39085; Wed, 20 Feb 2002 17:51:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020220085219.0182e798@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 09:52:08 -0800 To: Christopher Oliva , "'Ramsay, Ron'" , David Chadwick , Mark C Smith , Christopher Oliva , Sharon Boeyen From: "Kurt D. Zeilenga" Subject: ;binary and userCertificate (Was: Private email ...) Cc: LDAP BIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: ;binary has uses beyond those with certificates. For example, to request transfer of a DN in BER form instead of RFC 2253 form. IMO, an attribute of syntax DN would serve as a better example of ;binary's "intended" use (as described in Section 4.1.5.1 of RFC 2251). It doesn't make much sense to return values in BER form when the client has not explicitly requested it. While RFC 2251 stated: Clients MUST NOT expect servers to return an attribute in binary format if the client requested that attribute by name without the binary option. This did not prevent, generally, a server from running any attribute in binary format even though requested without ;binary. Likely it was assumed to be obvious that a server shouldn't return CN;binary unless it was asked to. The revised specification explicitly states that servers must not use binary transfer when the attribute was requested without ;binary. As all attributes explicitly make use of binary transfer state that values MUST be requested and transferred with the ;binary option, the revised specification is self consistent. In regards to X.509 schema, one should not fix that which is not broken. The document should: a) indicate edition of X.500 recommendations used is different from those used in LDAPv3 and diccuss impacts of this difference, b) add missing matching rules, and c) state that values and their encoding forms be preserved. I see no reason to define a LDAPv3 native (octet)string encoding for these syntaxes as ;binary works just fine. Yes, there may be broken LDAPv3 implementations, they should be fixed. The fact that LDAPv2 uses a different mechanism is inconsequential to this discussion. From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 20 13:20:33 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12669 for ; Wed, 20 Feb 2002 13:20:31 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1KIHNM33585; Wed, 20 Feb 2002 18:17:23 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 20 Feb 2002 18:17:23 +0000 Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1KIHLU33578 for ; Wed, 20 Feb 2002 18:17:21 GMT Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA22040; Wed, 20 Feb 2002 19:16:58 +0100 (MET) Date: Wed, 20 Feb 2002 18:54:40 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: ietf-ldapbis@OpenLDAP.org, ietf-ldapext@netscape.com cc: Ned Freed Subject: Informational RFC to be: draft-fleming-ldap-printer-schema-01.txt (fwd) Message-ID: <1958012.1014231280@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Can some of you have a look at these and let me know what you think? paf ---------- Forwarded Message ---------- Date: onsdag 20 februari 2002 17.24 +0000 From: RFC Editor To: iesg@ietf.org Subject: Informational RFC to be: draft-fleming-ldap-printer-schema-01.txt IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-fleming-ldap-printer-schema-01.txt. Four week timeout is initiated (20 March 2002). LDAP Schema for Printer Services This document provides information for the Internet community. It does not specify an Internet standard of any kind. This document defines an LDAP schema, object classes and attributes, for printers and printer services, for use with directories that support Lightweight Directory Access Protocol (LDAPv3) [RFC2251]. This document is based on the printer attributes listed in Appendix E of Internet Printing Protocol (IPP/1.1) [RFC2911], the Service Location Protocol (SLPv2) [RFC2608] 'service:printer:' template defined in [SLPPRT], and the mapping between SLP service advertisements and LDAP descriptions of services defined in [RFC2926]. ** Please note that the RFC Editor intends to expand "LDAP" in the title if this document is accepted for publication as an RFC. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents Voice: (310) 822-1511 x89369 Fax: (310) 823-6714 EMAIL: RFC-ED@RFC-EDITOR.ORG ---------- End Forwarded Message ---------- From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 20 14:37:36 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17572 for ; Wed, 20 Feb 2002 14:37:36 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1KJY6Q35988; Wed, 20 Feb 2002 19:34:06 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 20 Feb 2002 19:34:06 +0000 Received: from sottmxs02.entrust.com (client52.entrust.com [216.191.251.52]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1KJY3U35968; Wed, 20 Feb 2002 19:34:03 GMT Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Feb 2002 14:35:49 -0500 Message-ID: From: Christopher Oliva To: "'Kurt D. Zeilenga'" , Christopher Oliva , "'Ramsay, Ron'" , David Chadwick , Mark C Smith , Christopher Oliva , Sharon Boeyen Cc: LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Wed, 20 Feb 2002 14:35:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA45.CC0E3F00" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA45.CC0E3F00 Content-Type: text/plain; charset="iso-8859-1" I am restricting my comments to the Certificate, Certificate List and Certificate Pair syntaxes. Other functionality for other syntaxes do not apply and no changes are needed as far as I am concerned. Comments in-line below. > It doesn't make much sense to return values in BER form > when the client has not explicitly requested it. While > RFC 2251 stated: > Clients MUST NOT expect servers to return an attribute > in binary format if the client requested that attribute > by name without the binary option. If the Certificate (etc.) syntax is changed so that the native encoding is the BER encoding, then the quote from RFC 2251 above does not apply. I believe the above statement applies to attributes whose native syntax is not BER encoding. Clients that are not aware of the native encoding will continue to request certificates with the ";binary" transfer option. > As all attributes explicitly make use of binary transfer > state that values MUST be requested and transferred with > the ;binary option, the revised specification is self > consistent. > The proposed change is not to alter the binary transfer syntax for certificates. Instead the native encoding of certificates will change to be BER encoding therefore the above statement about the binary transfer mechanism does not apply since the transfer of the native encoding will be BER. The fact that the native BER encoding for a certificate and the encoding used for the ";binary" transfer option are the same is inconsequential. > In regards to X.509 schema, one should not fix that which > is not broken. The document should: > a) indicate edition of X.500 recommendations used > is different from those used in LDAPv3 and diccuss > impacts of this difference, > b) add missing matching rules, and > c) state that values and their encoding forms > be preserved. > > I see no reason to define a LDAPv3 native (octet)string encoding > for these syntaxes as ;binary works just fine. Yes, there > may be broken LDAPv3 implementations, they should be fixed. > > The fact that LDAPv2 uses a different mechanism is > inconsequential to this discussion. > In reality there are serious interoperability and backwards compatibility problems. Vendors have not been able to implement the strict interpretations of ";binary". The proposed solution is clean, simple and preserves interoperability in all cases. I don't think we can simply choose to ignore interoperability and backwards compatibility. I have still not seen a compelling reason to enforce the strict ";binary" interpretation. On the other hand, there are many compelling reasons to adopt the proposed change. Chris. ------_=_NextPart_001_01C1BA45.CC0E3F00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ;binary and userCertificate (Was: Private email ...) I am restricting my comments to the Certificate, = Certificate List and Certificate Pair syntaxes. Other functionality for = other syntaxes do not apply and no changes are needed as far as I am = concerned. Comments in-line below. > It doesn't make much sense to return values in = BER form > when the client has not explicitly requested = it. While > RFC 2251 stated: > Clients MUST NOT expect = servers to return an attribute > in binary format if the = client requested that attribute > by name without the binary = option. If the Certificate (etc.) syntax is changed so that = the native encoding is the BER encoding, then the quote from RFC 2251 = above does not apply. I believe the above statement applies to = attributes whose native syntax is not BER encoding. Clients that are = not aware of the native encoding will continue to request certificates = with the ";binary" transfer option. > As all attributes explicitly make use of binary = transfer > state that values MUST be requested and = transferred with > the ;binary option, the revised specification = is self > consistent. > The proposed change is not to alter the binary = transfer syntax for certificates. Instead the native encoding of = certificates will change to be BER encoding therefore the above = statement about the binary transfer mechanism does not apply since the = transfer of the native encoding will be BER. The fact that the native = BER encoding for a certificate and the encoding used for the = ";binary" transfer option are the same is = inconsequential. > In regards to X.509 schema, one should not fix = that which > is not broken. The document = should: > a) indicate = edition of X.500 recommendations used > is = different from those used in LDAPv3 and diccuss > = impacts of this difference, > b) add missing = matching rules, and > c) state that = values and their encoding forms > be = preserved. > > I see no reason to define a LDAPv3 native = (octet)string encoding > for these syntaxes as ;binary works just = fine. Yes, there > may be broken LDAPv3 implementations, they = should be fixed. > > The fact that LDAPv2 uses a different mechanism = is > inconsequential to this discussion. > In reality there are serious interoperability and = backwards compatibility problems. Vendors have not been able to = implement the strict interpretations of ";binary". The = proposed solution is clean, simple and preserves interoperability in = all cases. I don't think we can simply choose to ignore = interoperability and backwards compatibility. I have still not seen a compelling reason to enforce = the strict ";binary" interpretation. On the other hand, there = are many compelling reasons to adopt the proposed change. Chris. ------_=_NextPart_001_01C1BA45.CC0E3F00-- From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 20 20:03:50 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25277 for ; Wed, 20 Feb 2002 20:03:50 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1L10ZU46420; Thu, 21 Feb 2002 01:00:35 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 01:00:35 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1L10WU46400; Thu, 21 Feb 2002 01:00:32 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Thu, 21 Feb 2002 12:00:15 +1100 Message-ID: From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Thu, 21 Feb 2002 12:00:18 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt, Where is your idea of returning an X500 DN by asking for dn;binary spelled out? I would expect LDAP servers to regard the DN as a string and simply wrap it with an octet string tag. In fact, I don't remember any description of a non-string encoding of DN in the LDAP documents. As regards your other arguments, I have trouble getting a handle on them. The only attributes that MUST be requested with ;binary are the certificate bunch. A client MUST always expect these to be returned with ;binary regardless of the request. Requesting other attributes with ;binary just seems wrong. (I reject your notion that servers will perform some unspecified action to return a novel encoding of an attribute. Chris seems to be saying that servers will only return the value that is stored and only in the way it is stored, apart, I guess, from being able to wrap strings in octet string wrappers.) I do agree with Chris that ;binary was a BAD idea. Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, 21 February 2002 4:52 To: Christopher Oliva; Ramsay, Ron; David Chadwick; Mark C Smith; Christopher Oliva; Sharon Boeyen Cc: LDAP BIS Subject: ;binary and userCertificate (Was: Private email ...) ;binary has uses beyond those with certificates. For example, to request transfer of a DN in BER form instead of RFC 2253 form. IMO, an attribute of syntax DN would serve as a better example of ;binary's "intended" use (as described in Section 4.1.5.1 of RFC 2251). It doesn't make much sense to return values in BER form when the client has not explicitly requested it. While RFC 2251 stated: Clients MUST NOT expect servers to return an attribute in binary format if the client requested that attribute by name without the binary option. This did not prevent, generally, a server from running any attribute in binary format even though requested without ;binary. Likely it was assumed to be obvious that a server shouldn't return CN;binary unless it was asked to. The revised specification explicitly states that servers must not use binary transfer when the attribute was requested without ;binary. As all attributes explicitly make use of binary transfer state that values MUST be requested and transferred with the ;binary option, the revised specification is self consistent. In regards to X.509 schema, one should not fix that which is not broken. The document should: a) indicate edition of X.500 recommendations used is different from those used in LDAPv3 and diccuss impacts of this difference, b) add missing matching rules, and c) state that values and their encoding forms be preserved. I see no reason to define a LDAPv3 native (octet)string encoding for these syntaxes as ;binary works just fine. Yes, there may be broken LDAPv3 implementations, they should be fixed. The fact that LDAPv2 uses a different mechanism is inconsequential to this discussion. From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 20 21:06:33 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26042 for ; Wed, 20 Feb 2002 21:06:31 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1L238K48226; Thu, 21 Feb 2002 02:03:08 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 02:03:08 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1L236U48219 for ; Thu, 21 Feb 2002 02:03:06 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1L234C41138; Thu, 21 Feb 2002 02:03:04 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020220173919.0181e8b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 18:03:13 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: ;binary and userCertificate (Was: Private email ...) Cc: LDAP BIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 05:00 PM 2002-02-20, Ramsay, Ron wrote: >Where is your idea of returning an X500 DN by asking for dn;binary spelled >out? I was referring to attributes of DN syntax, not to a DN of an entry. Maybe using attributes of directoryString syntax in the example would make a less confusing. ;binary applies to all attributes. A client can request CN;binary, member;binary, userCertificate;binary, etc.. In all cases, if the server supports ;binary for that attribute, the server returns BER encoded values. It's spelled out in RFC 2251, Section 4.1.5.1. One of its primary uses is in security applications, see RFC 2252 9.2 (but s/Binary syntax/binary transfer/ in last sentence for it to make sense). >I would expect LDAP servers to regard the DN as a string and simply wrap it >with an octet string tag. In fact, I don't remember any description of a >non-string encoding of DN in the LDAP documents. DNs transferred in fields of LDAPDN type in the protocol are RFC 2253 strings. Assertion and attribute values of distinguishName syntax can be transferred using the native (octet) string encoding, e.g. an RFC 2253 string, or using ;binary transfer, e.g. BER. >As regards your other arguments, I have trouble getting a handle on them. >The only attributes that MUST be requested with ;binary are the certificate >bunch. A client MUST always expect these to be returned with ;binary >regardless of the request. And the client MUST request them as ;binary. RFC 2256: This attribute is to be stored and REQUESTED in the binary form, as 'userCertificate;binary'. (emphasis added) RFC 2252: ... values in this syntax MUST only be transferred using the binary encoding, by requesting or returning the attributes with descriptions "userCertificate;binary" or "caCertificate;binary". RFC 2256: clients MUST NOT expect servers to return an attribute in binary format if the client requested that attribute by name without the binary option. A client which requests "userCertificate" (without ;binary) does not conform to the specification. >Requesting other attributes with ;binary just seems wrong. >(I reject your notion that servers will perform some >unspecified action to return a novel encoding of an attribute. It's specified quite clearly in RFC 2251, 4.1.5.1. >I do agree with Chris that ;binary was a BAD idea. IMO, ;binary, as "intended" by 4.1.5.1, is a useful feature of LDAPv3. From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 20 21:40:18 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27323 for ; Wed, 20 Feb 2002 21:40:18 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1L2b1Z48759; Thu, 21 Feb 2002 02:37:01 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 02:37:01 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1L2axU48752 for ; Thu, 21 Feb 2002 02:36:59 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1L2ZgC41260; Thu, 21 Feb 2002 02:35:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020220180611.01767f40@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 18:35:51 -0800 To: Christopher Oliva From: "Kurt D. Zeilenga" Subject: RE: ;binary and userCertificate (Was: Private email ...) Cc: Christopher Oliva , "'Ramsay, Ron'" , David Chadwick , Mark C Smith , Christopher Oliva , Sharon Boeyen , LDAP BIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Let me boil this down... The specification says certificates are to be requested and transferred using ;binary. There are multiple independently developed interoperable implementations of this specification. You state that the specification should be changed because some other implementors have produced implementations which don't interoperate with the above implementations. If these other implementors' interpretation of the specification was reasonable, that is, a result of ambiguity in the specification, then it could be argued that specification should be clarified to one of the two (or more) reasonable interpretations. If on the other hand, these implementors simply did not adhere to the specification, they are broken. They should be fixed. It's my belief that this is a case of the latter. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 20 21:59:05 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27552 for ; Wed, 20 Feb 2002 21:59:05 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1L2tlA49127; Thu, 21 Feb 2002 02:55:47 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 02:55:47 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1L2tiU49107; Thu, 21 Feb 2002 02:55:44 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Thu, 21 Feb 2002 13:55:27 +1100 Message-ID: From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Thu, 21 Feb 2002 13:55:27 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt, Replies inline. See [RR] Ron -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, 21 February 2002 13:03 To: Ramsay, Ron Cc: LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) At 05:00 PM 2002-02-20, Ramsay, Ron wrote: >Where is your idea of returning an X500 DN by asking for dn;binary spelled >out? I was referring to attributes of DN syntax, not to a DN of an entry. Maybe using attributes of directoryString syntax in the example would make a less confusing. [RR] I was also referring to attributes. ;binary applies to all attributes. A client can request CN;binary, member;binary, userCertificate;binary, etc.. In all cases, if the server supports ;binary for that attribute, the server returns BER encoded values. [RR] For most attributes this BER is simply an octet string wrapping. Certificate stuff is the exception. It's spelled out in RFC 2251, Section 4.1.5.1. [RR] This section is more a hint than a spelling-out. Note that the only attributes that this is expected to apply to are certificate releated (last sentance of the section). It would not be possible, for example, for a server to reconstitute the X500 definition of DirectoryString because the actual CHOICE tag has been lost (was never supplied). Also, the section assumes there is an ASN.1 definition. If you assume that X.520 is implied, you can make up ASN.1 values, in principle, but as I've indicated with DirectoryString, it is not always possible to go from the possible to the actual. But if this were to be possible, LDAP should have specified these ASN.1 syntaxes. I believe, though, as in the case of DistinguishedName, that LDAP was actually trying to break away from X.500. One of its primary uses is in security applications, see RFC 2252 9.2 (but s/Binary syntax/binary transfer/ in last sentence for it to make sense). [RR] This is just certificate stuff again! >I would expect LDAP servers to regard the DN as a string and simply wrap it >with an octet string tag. In fact, I don't remember any description of a >non-string encoding of DN in the LDAP documents. DNs transferred in fields of LDAPDN type in the protocol are RFC 2253 strings. Assertion and attribute values of distinguishName syntax can be transferred using the native (octet) string encoding, e.g. an RFC 2253 string, or using ;binary transfer, e.g. BER. [RR] You seem to be saying that DNs can't be returned in their X500 form? >As regards your other arguments, I have trouble getting a handle on them. >The only attributes that MUST be requested with ;binary are the certificate >bunch. A client MUST always expect these to be returned with ;binary >regardless of the request. And the client MUST request them as ;binary. RFC 2256: This attribute is to be stored and REQUESTED in the binary form, as 'userCertificate;binary'. (emphasis added) RFC 2252: ... values in this syntax MUST only be transferred using the binary encoding, by requesting or returning the attributes with descriptions "userCertificate;binary" or "caCertificate;binary". RFC 2256: clients MUST NOT expect servers to return an attribute in binary format if the client requested that attribute by name without the binary option. A client which requests "userCertificate" (without ;binary) does not conform to the specification. [RR] Once certificates are taken out of the base spec, conformance it moot! >Requesting other attributes with ;binary just seems wrong. >(I reject your notion that servers will perform some >unspecified action to return a novel encoding of an attribute. It's specified quite clearly in RFC 2251, 4.1.5.1. [RR] That waffle is not clear. The only clear statement is that it is expected to apply to certificates. No other syntaxes have been given an ASN.1 form. If you look at the mailing list of the time (asid?) you will see that the interpretation of this paragraph was to wrap the string representation in an octet string. Once again, except for certificate related stuff, the BER was taken to be 04 xx ...... >I do agree with Chris that ;binary was a BAD idea. IMO, ;binary, as "intended" by 4.1.5.1, is a useful feature of LDAPv3. [RR] I think this thread has revealed that others regard it as a BAD idea. From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 20 22:01:58 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27610 for ; Wed, 20 Feb 2002 22:01:57 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1L2wjk49181; Thu, 21 Feb 2002 02:58:45 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 02:58:44 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1L2whU49160; Thu, 21 Feb 2002 02:58:43 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Thu, 21 Feb 2002 13:58:28 +1100 Message-ID: From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , Christopher Oliva Cc: LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Thu, 21 Feb 2002 13:58:30 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt, Once certificates are removed for the base spec, these arguments are moot. Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, 21 February 2002 13:36 To: Christopher Oliva Cc: Christopher Oliva; Ramsay, Ron; David Chadwick; Mark C Smith; Christopher Oliva; Sharon Boeyen; LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Let me boil this down... The specification says certificates are to be requested and transferred using ;binary. There are multiple independently developed interoperable implementations of this specification. You state that the specification should be changed because some other implementors have produced implementations which don't interoperate with the above implementations. If these other implementors' interpretation of the specification was reasonable, that is, a result of ambiguity in the specification, then it could be argued that specification should be clarified to one of the two (or more) reasonable interpretations. If on the other hand, these implementors simply did not adhere to the specification, they are broken. They should be fixed. It's my belief that this is a case of the latter. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 00:13:35 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00970 for ; Thu, 21 Feb 2002 00:13:35 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1L5AEm54175; Thu, 21 Feb 2002 05:10:14 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 05:10:14 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1L5ADU54168 for ; Thu, 21 Feb 2002 05:10:13 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1L599C42769; Thu, 21 Feb 2002 05:09:09 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020220210728.017f3750@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 21:09:18 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: ;binary and userCertificate (Was: Private email ...) Cc: Christopher Oliva , LDAP BIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 06:58 PM 2002-02-20, Ramsay, Ron wrote: >Once certificates are removed for the base spec, these arguments are moot. Yes, but they are not moot for an I-D replacing portions of an Proposed Standard. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 00:16:49 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01011 for ; Thu, 21 Feb 2002 00:16:49 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1L5DeV54283; Thu, 21 Feb 2002 05:13:40 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 05:13:40 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1L5DcU54249; Thu, 21 Feb 2002 05:13:38 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Thu, 21 Feb 2002 16:13:20 +1100 Message-ID: From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: Christopher Oliva , LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Thu, 21 Feb 2002 16:13:24 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I can't see how that can work. They will be removed, creating a proposed standard with less functionality, which is OK. The standard no longer applies, so certificates can go their own way? -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, 21 February 2002 16:09 To: Ramsay, Ron Cc: Christopher Oliva; LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) At 06:58 PM 2002-02-20, Ramsay, Ron wrote: >Once certificates are removed for the base spec, these arguments are moot. Yes, but they are not moot for an I-D replacing portions of an Proposed Standard. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 01:01:04 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01491 for ; Thu, 21 Feb 2002 01:01:04 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1L5vnP55259; Thu, 21 Feb 2002 05:57:49 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 05:57:49 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1L5vlU55252 for ; Thu, 21 Feb 2002 05:57:47 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1L5uiC42967; Thu, 21 Feb 2002 05:56:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020220213414.0611faa8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 21:56:53 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: ;binary and userCertificate (Was: Private email ...) Cc: Christopher Oliva , LDAP BIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 09:13 PM 2002-02-20, Ramsay, Ron wrote: >I can't see how that can work. They will be removed, creating a proposed >standard with less functionality, which is OK. For clarity, The certificate schema will be split out from the "core" specification. The intent is for the "core" to progress to Draft Standard directly. The certificate schema specification, due to addition of matching rules and possibly other changes, will be issued at a Proposed Standard. If issued prior to the revised "core" specification, this I-D would update RFC 2252 and RFC 2256. If issued after, this I-D would extend the revised "core" specification. >The standard no longer applies, so certificates can go their own way? Sure, you can throw out the old specification and start over. I don't believe that is warranted in this case. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 01:35:42 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01749 for ; Thu, 21 Feb 2002 01:35:41 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1L6WNt55917; Thu, 21 Feb 2002 06:32:23 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 06:32:23 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1L6WKU55910 for ; Thu, 21 Feb 2002 06:32:20 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1L6W1C43088; Thu, 21 Feb 2002 06:32:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020220210942.0181e8b0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 20 Feb 2002 22:32:10 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: ;binary and userCertificate (Was: Private email ...) Cc: LDAP BIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 06:55 PM 2002-02-20, Ramsay, Ron wrote: >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Thursday, 21 February 2002 13:03 >To: Ramsay, Ron >Cc: LDAP BIS >Subject: RE: ;binary and userCertificate (Was: Private email ...) > > >At 05:00 PM 2002-02-20, Ramsay, Ron wrote: >>Where is your idea of returning an X500 DN by asking for dn;binary spelled >>out? > >I was referring to attributes of DN syntax, not to a DN >of an entry. Maybe using attributes of directoryString syntax >in the example would make a less confusing. > >[RR] I was also referring to attributes. > >;binary applies to all attributes. A client can request CN;binary, >member;binary, userCertificate;binary, etc.. In all cases, if the >server supports ;binary for that attribute, the server returns >BER encoded values. > >[RR] For most attributes this BER is simply an octet string wrapping. >Certificate stuff is the exception. > >It's spelled out in RFC 2251, Section 4.1.5.1. > >[RR] This section is more a hint than a spelling-out. Note that the only >attributes that this is expected to apply to are certificate releated (last >sentance of the section). No. The last sentence only provides an example. The example does not constrain use of the mechanism with other attributes. The second to last sentence states: "This option is intended to be used with attributes whose syntax is a complex ASN.1 data type, and the structure of values of that type is needed by clients." Directory String is a complex ASN.1 data type. Distinguished Name is a complex ASN.1 data type. .... >It would not be possible, for example, for a >server to reconstitute the X500 definition of DirectoryString because the >actual CHOICE tag has been lost (was never supplied). Just as an LDAP/DAP gateway can infer the CHOICE when mapping between LDAP and DAP, an LDAP server can infer the CHOICE. Where the client desires a particular CHOICE, it should use ;binary. >Also, the section assumes there is an ASN.1 definition. Yes. Each and every LDAP syntax is defined in terms of an ASN.1 data type definition. >If you assume that X.520 is implied, I do, LDAP is an access protocol to an X.500 Directory. >you can make up ASN.1 values, in principle, but as I've indicated with >DirectoryString, it is not always possible to go from the possible to the >actual. But if this were to be possible, LDAP should have specified these >ASN.1 syntaxes. They are specified, see 4.3.2 of RFC 2252. >I believe, though, as in the case of DistinguishedName, that >LDAP was actually trying to break away from X.500. No. LDAP was trying to make things easier on clients to access an X.500 directory. LDAP is an access protocol to an X.500 directory. >One of its primary uses is in security applications, see >RFC 2252 9.2 (but s/Binary syntax/binary transfer/ in last >sentence for it to make sense). > >[RR] This is just certificate stuff again! The example is certificate related. However the issue as well as the mechanism provided to address the issue are general. >>I would expect LDAP servers to regard the DN as a string and simply wrap it >>with an octet string tag. In fact, I don't remember any description of a >>non-string encoding of DN in the LDAP documents. > >DNs transferred in fields of LDAPDN type in the protocol are >RFC 2253 strings. Assertion and attribute values of distinguishName >syntax can be transferred using the native (octet) string >encoding, e.g. an RFC 2253 string, or using ;binary transfer, >e.g. BER. > >[RR] You seem to be saying that DNs can't be returned in their X500 form? LDAPDN fields are restricted to the LDAP string representation. However, assertion and attribute values of distinguishedName syntax can be transferred using BER. Both are X.500 forms. That is, both are encodings of the X.500 distinguishedNames. >>As regards your other arguments, I have trouble getting a handle on them. >>The only attributes that MUST be requested with ;binary are the certificate >>bunch. A client MUST always expect these to be returned with ;binary >>regardless of the request. > >And the client MUST request them as ;binary. > >RFC 2256: > This attribute is to be stored and REQUESTED in the binary form, as > 'userCertificate;binary'. (emphasis added) > >RFC 2252: > ... values in this syntax MUST only be transferred using the > binary encoding, by requesting or returning the attributes > with descriptions "userCertificate;binary" or > "caCertificate;binary". > >RFC 2256: > clients MUST NOT expect servers to return an attribute in > binary format if the client requested that attribute by name > without the binary option. > >A client which requests "userCertificate" (without ;binary) >does not conform to the specification. > >[RR] Once certificates are taken out of the base spec, conformance it moot! The RFC 2251 statement remains, it is not certificate specific. >>Requesting other attributes with ;binary just seems wrong. >>(I reject your notion that servers will perform some >>unspecified action to return a novel encoding of an attribute. > >It's specified quite clearly in RFC 2251, 4.1.5.1. > >[RR] That waffle is not clear. The only clear statement is that it is >expected to apply to certificates. Examples are just examples. The interpretation of the section is the same whether it's "userCertificate;binary", "member;binary" or " >If you look at the mailing list of the time (asid?) Do you have a copy of the archives? If so, please forward me a copy of it so I can make it publicly available. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 02:02:37 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05462 for ; Thu, 21 Feb 2002 02:02:36 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1L6xML56403; Thu, 21 Feb 2002 06:59:22 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 06:59:22 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1L6xIU56381; Thu, 21 Feb 2002 06:59:18 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Thu, 21 Feb 2002 17:59:00 +1100 Message-ID: From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Thu, 21 Feb 2002 17:59:04 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt, It seems that much of your argument hinges on ASN.1 definitions of LDAP syntaxes. You referred me to RFC 2252 Section 4.3.2 for this. I read that section but could find no ASN.1 definitions. You also seem to think there are two ways to use DNs, in particular, the use of a DN as an attribute value allows the X.500 encoding. But look at Section 6.9 of RFC 2252 - Values in the Distinguished Name syntax are encoded to have the representation defined in [5]. Note that this representation is not reversible to an ASN.1 encoding used in X.500 for Distinguished Names, as the CHOICE of any DirectoryString element in an RDN is no longer known. That is, ALL DNs are strings and no other definition exists for them. You also make some statement about X.500 gateways. This is surely an implementation issue. If gatewaying were part of the LDAP standard then rules would have to be defined, particularly, rules for converting LDAP values to and from X500 values would have to be specified. Regarding the ;binary encoding of attributes on the mailing list, I just read, memorise and delete. I think Tim Howes was advising someone about wrapping strings, particularly that there would be two octet string tags around the string. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, 21 February 2002 17:32 To: Ramsay, Ron Cc: LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) At 06:55 PM 2002-02-20, Ramsay, Ron wrote: >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Thursday, 21 February 2002 13:03 >To: Ramsay, Ron >Cc: LDAP BIS >Subject: RE: ;binary and userCertificate (Was: Private email ...) > > >At 05:00 PM 2002-02-20, Ramsay, Ron wrote: >>Where is your idea of returning an X500 DN by asking for dn;binary spelled >>out? > >I was referring to attributes of DN syntax, not to a DN >of an entry. Maybe using attributes of directoryString syntax >in the example would make a less confusing. > >[RR] I was also referring to attributes. > >;binary applies to all attributes. A client can request CN;binary, >member;binary, userCertificate;binary, etc.. In all cases, if the >server supports ;binary for that attribute, the server returns >BER encoded values. > >[RR] For most attributes this BER is simply an octet string wrapping. >Certificate stuff is the exception. > >It's spelled out in RFC 2251, Section 4.1.5.1. > >[RR] This section is more a hint than a spelling-out. Note that the only >attributes that this is expected to apply to are certificate releated (last >sentance of the section). No. The last sentence only provides an example. The example does not constrain use of the mechanism with other attributes. The second to last sentence states: "This option is intended to be used with attributes whose syntax is a complex ASN.1 data type, and the structure of values of that type is needed by clients." Directory String is a complex ASN.1 data type. Distinguished Name is a complex ASN.1 data type. .... >It would not be possible, for example, for a >server to reconstitute the X500 definition of DirectoryString because the >actual CHOICE tag has been lost (was never supplied). Just as an LDAP/DAP gateway can infer the CHOICE when mapping between LDAP and DAP, an LDAP server can infer the CHOICE. Where the client desires a particular CHOICE, it should use ;binary. >Also, the section assumes there is an ASN.1 definition. Yes. Each and every LDAP syntax is defined in terms of an ASN.1 data type definition. >If you assume that X.520 is implied, I do, LDAP is an access protocol to an X.500 Directory. >you can make up ASN.1 values, in principle, but as I've indicated with >DirectoryString, it is not always possible to go from the possible to the >actual. But if this were to be possible, LDAP should have specified these >ASN.1 syntaxes. They are specified, see 4.3.2 of RFC 2252. >I believe, though, as in the case of DistinguishedName, that >LDAP was actually trying to break away from X.500. No. LDAP was trying to make things easier on clients to access an X.500 directory. LDAP is an access protocol to an X.500 directory. >One of its primary uses is in security applications, see >RFC 2252 9.2 (but s/Binary syntax/binary transfer/ in last >sentence for it to make sense). > >[RR] This is just certificate stuff again! The example is certificate related. However the issue as well as the mechanism provided to address the issue are general. >>I would expect LDAP servers to regard the DN as a string and simply wrap it >>with an octet string tag. In fact, I don't remember any description of a >>non-string encoding of DN in the LDAP documents. > >DNs transferred in fields of LDAPDN type in the protocol are >RFC 2253 strings. Assertion and attribute values of distinguishName >syntax can be transferred using the native (octet) string >encoding, e.g. an RFC 2253 string, or using ;binary transfer, >e.g. BER. > >[RR] You seem to be saying that DNs can't be returned in their X500 form? LDAPDN fields are restricted to the LDAP string representation. However, assertion and attribute values of distinguishedName syntax can be transferred using BER. Both are X.500 forms. That is, both are encodings of the X.500 distinguishedNames. >>As regards your other arguments, I have trouble getting a handle on them. >>The only attributes that MUST be requested with ;binary are the certificate >>bunch. A client MUST always expect these to be returned with ;binary >>regardless of the request. > >And the client MUST request them as ;binary. > >RFC 2256: > This attribute is to be stored and REQUESTED in the binary form, as > 'userCertificate;binary'. (emphasis added) > >RFC 2252: > ... values in this syntax MUST only be transferred using the > binary encoding, by requesting or returning the attributes > with descriptions "userCertificate;binary" or > "caCertificate;binary". > >RFC 2256: > clients MUST NOT expect servers to return an attribute in > binary format if the client requested that attribute by name > without the binary option. > >A client which requests "userCertificate" (without ;binary) >does not conform to the specification. > >[RR] Once certificates are taken out of the base spec, conformance it moot! The RFC 2251 statement remains, it is not certificate specific. >>Requesting other attributes with ;binary just seems wrong. >>(I reject your notion that servers will perform some >>unspecified action to return a novel encoding of an attribute. > >It's specified quite clearly in RFC 2251, 4.1.5.1. > >[RR] That waffle is not clear. The only clear statement is that it is >expected to apply to certificates. Examples are just examples. The interpretation of the section is the same whether it's "userCertificate;binary", "member;binary" or " >If you look at the mailing list of the time (asid?) Do you have a copy of the archives? If so, please forward me a copy of it so I can make it publicly available. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 03:37:52 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10934 for ; Thu, 21 Feb 2002 03:37:51 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1L8YKi58711; Thu, 21 Feb 2002 08:34:20 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 08:34:20 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1L8YIU58704 for ; Thu, 21 Feb 2002 08:34:18 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1L8YGC43435; Thu, 21 Feb 2002 08:34:16 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020220231901.06152058@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 00:34:25 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: ;binary and userCertificate (Was: Private email ...) Cc: LDAP BIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 10:59 PM 2002-02-20, Ramsay, Ron wrote: >Kurt, > >It seems that much of your argument hinges on ASN.1 definitions of LDAP >syntaxes. You referred me to RFC 2252 Section 4.3.2 for this. I read that >section but could find no ASN.1 definitions. RFC 2251 says: The syntax of the binary value is an ASN.1 data type definition which is referenced by the "SYNTAX" part of the attribute type definition. That reference is provided, for most every syntax (including certificate) by the table in RFC 2252, 4.3.2. >You also seem to think there are two ways to use DNs, In LDAPv3, you can transfer each and every value syntax in two ways. You can transfer the string representation or you can transfer a BER representation. >in particular, the use >of a DN as an attribute value allows the X.500 encoding. But look at Section >6.9 of RFC 2252 - > > Values in the Distinguished Name syntax are encoded to have the > representation defined in [5]. Note that this representation is not > reversible to an ASN.1 encoding used in X.500 for Distinguished > Names, as the CHOICE of any DirectoryString element in an RDN is no > longer known. > >That is, ALL DNs are strings and no other definition exists for them. That's paragraph is not precise. Each DN has multiple string representations. While some of these representations may not be reversible, each DN does have a reversible string representation. That form should be used when reversibility is desired. >You also make some statement about X.500 gateways. I make statements about LDAP/DAP gateways. The term "X.500 gateway" is misleading as both LDAP and DAP are access protocols to X.500 directories. >If gatewaying were part of the LDAP standard I never said it was. But LDAP is certainly designed to allow implementation of DAP/LDAP gateways. >Regarding the ;binary encoding of attributes on the mailing list, I just >read, memorise and delete. I think Tim Howes was advising someone about >wrapping strings, particularly that there would be two octet string tags >around the string. If, you transfer without ;binary, the AttributeValue, an OCTET STRING, contains just the octets of the value. E.g. an AttributeValue transferring userPassword:foo is encoded as the octets 04 03 66 6F 6F, not 04 05 04 03 66 6F 6F. However, If you use ;binary to transfer a value of OCTET STRING syntax, then the AttributeValue, itself an OCTET STRING, contains the BER encoding of the value. For example, the AttributeValue transferring userPassword;binary:foo is encoded as the octets 04 05 04 03 66 6F 6F not 04 03 66 6F 6F. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 10:25:10 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20196 for ; Thu, 21 Feb 2002 10:25:09 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1LFLLA81381; Thu, 21 Feb 2002 15:21:22 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 15:21:21 +0000 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1LFLKU81361; Thu, 21 Feb 2002 15:21:20 GMT Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id g1LFKv727112; Thu, 21 Feb 2002 07:20:57 -0800 (PST) Received: from netscape.com ([10.169.184.10]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GRW2MY02.FYE; Thu, 21 Feb 2002 07:20:58 -0800 Message-ID: <3C751058.6060007@netscape.com> Date: Thu, 21 Feb 2002 10:20:56 -0500 From: mcs@netscape.com (Mark C Smith) Organization: Netscape Communications Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: "Ramsay Ron" , Christopher Oliva , LDAP BIS Subject: Re: ;binary and userCertificate (Was: Private email ...) References: <5.1.0.14.0.20020220213414.0611faa8@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > >>The standard no longer applies, so certificates can go their own way? >> > > Sure, you can throw out the old specification and start over. > I don't believe that is warranted in this case. I agree with Kurt. But clearly there are at least two points of view: (1) Those who believe ;binary was a bad idea with respect to certificate attributes (I'll leave other uses of ;binary out of this discussion). The introduction of ;binary caused more interoperability problems than it solved. (2) Those who believe ;binary was a useful idea with respect to certificate attributes. It allowed people to build standards compliant LDAPv3 clients and servers that interoperate in this area. Now, I have never heard of any interoperability problems that involve an LDAPv3 client talking to an LDAPv3 server to search for, retrieve, or modify certificate attributes. In all operations, ;binary is used in the AttributeDescription. There is no ambiguity. Everyone is happy. Can someone who is subscribes to (1) provide an example of an interoperability problem that does not involve LDAPv2? If not, then the real question is whether we care about LDAPv2 any longer. I do not. -Mark Smith Netscape From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 11:40:30 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23598 for ; Thu, 21 Feb 2002 11:40:29 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1LGamd85773; Thu, 21 Feb 2002 16:36:48 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 16:36:48 +0000 Received: from sottmxs02.entrust.com (client52.entrust.com [216.191.251.52]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1LGafU85743; Thu, 21 Feb 2002 16:36:42 GMT Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Feb 2002 11:38:28 -0500 Message-ID: From: Christopher Oliva To: "'mcs@netscape.com'" , "Kurt D. Zeilenga" Cc: Ramsay Ron , Christopher Oliva , LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Thu, 21 Feb 2002 11:37:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BAF6.035DBAC0" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BAF6.035DBAC0 Content-Type: text/plain; charset="iso-8859-1" It still hasn't been made clear how the proposed change will have a negative impact. As explained, the change will only increase interoperability. I'll explain it again just to be clear (in point form): - new PKIX spec defining X.509 syntaxes will define their native encoding as BER - the native encoding would be identical to the ";binary" transfer syntax encoding (for X.509 syntaxes) - this means ";binary" will not be mandatory to request these values - no changes are needed to the LDAPbis specs (other than to remove any descriptions of X.509 syntaxes) - clients that use ";binary" (for x.509 syntaxes) can continue to use this without any impact - search add or modify involving such syntaxes can use ";binary" or not - makes no difference So you see, it's a win-win situation. What is the downside of making this change ? It will only increase interoperability. Yes, there are examples of non-ldapv2 problems but I will not get into specifics on this list. I have in a previous email detailed many issues on this topic. Anyway, I don't see how you can simply ignore ldapv2. How can you provide a migration path from ldapv2 to v3 if you ignore it? There are customers using ldapv2 today ... are you supposed to simply ignore that ? Many server products on the market still accept ldapv2 connections, therefore there is still a need for ldapv2. Chris. > -----Original Message----- > From: mcs@netscape.com [mailto:mcs@netscape.com] > Sent: Thursday, February 21, 2002 10:21 AM > To: Kurt D. Zeilenga > Cc: Ramsay Ron; Christopher Oliva; LDAP BIS > Subject: Re: ;binary and userCertificate (Was: Private email ...) > > > Kurt D. Zeilenga wrote: > > > > >>The standard no longer applies, so certificates can go > their own way? > >> > > > > Sure, you can throw out the old specification and start over. > > I don't believe that is warranted in this case. > > > I agree with Kurt. But clearly there are at least two points of view: > > (1) Those who believe ;binary was a bad idea with respect to > certificate > attributes (I'll leave other uses of ;binary out of this discussion). > The introduction of ;binary caused more interoperability > problems than > it solved. > > (2) Those who believe ;binary was a useful idea with respect to > certificate attributes. It allowed people to build standards > compliant > LDAPv3 clients and servers that interoperate in this area. > > Now, I have never heard of any interoperability problems that > involve an > LDAPv3 client talking to an LDAPv3 server to search for, retrieve, or > modify certificate attributes. In all operations, ;binary is > used in the > AttributeDescription. There is no ambiguity. Everyone is happy. > > Can someone who is subscribes to (1) provide an example of an > interoperability problem that does not involve LDAPv2? If > not, then the > real question is whether we care about LDAPv2 any longer. I do not. > > -Mark Smith > Netscape > ------_=_NextPart_001_01C1BAF6.035DBAC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ;binary and userCertificate (Was: Private email ...) It still hasn't been made clear how the proposed = change will have a negative impact. As explained, the change will only = increase interoperability. I'll explain it again just to be clear (in point = form): - new PKIX spec defining X.509 syntaxes will define = their native encoding as BER - the native encoding would be identical to the = ";binary" transfer syntax encoding (for X.509 = syntaxes) - this means ";binary" will not be = mandatory to request these values - no changes are needed to the LDAPbis specs (other = than to remove any descriptions of X.509 syntaxes) - clients that use ";binary" (for x.509 = syntaxes) can continue to use this without any impact - search add or modify involving such syntaxes can = use ";binary" or not - makes no difference So you see, it's a win-win situation. What is the = downside of making this change ? It will only increase = interoperability. Yes, there are examples of non-ldapv2 problems but I = will not get into specifics on this list. I have in a previous email = detailed many issues on this topic. Anyway, I don't see how you can simply ignore ldapv2. = How can you provide a migration path from ldapv2 to v3 if you ignore = it? There are customers using ldapv2 today ... are you supposed to = simply ignore that ? Many server products on the market still accept = ldapv2 connections, therefore there is still a need for = ldapv2. Chris. > -----Original Message----- > From: mcs@netscape.com [mailto:mcs@netscape.com] > Sent: Thursday, February 21, 2002 10:21 = AM > To: Kurt D. Zeilenga > Cc: Ramsay Ron; Christopher Oliva; LDAP = BIS > Subject: Re: ;binary and userCertificate (Was: = Private email ...) > > > Kurt D. Zeilenga wrote: > > > > >>The standard no longer applies, so = certificates can go > their own way? > >> > > > > Sure, you can throw out the old = specification and start over. > > I don't believe that is warranted in this = case. > > > I agree with Kurt. But clearly there are at = least two points of view: > > (1) Those who believe ;binary was a bad idea = with respect to > certificate > attributes (I'll leave other uses of ;binary = out of this discussion). > The introduction of ;binary caused more = interoperability > problems than > it solved. > > (2) Those who believe ;binary was a useful idea = with respect to > certificate attributes. It allowed people to = build standards > compliant > LDAPv3 clients and servers that interoperate in = this area. > > Now, I have never heard of any interoperability = problems that > involve an > LDAPv3 client talking to an LDAPv3 server to = search for, retrieve, or > modify certificate attributes. In all = operations, ;binary is > used in the > AttributeDescription. There is no ambiguity. = Everyone is happy. > > Can someone who is subscribes to (1) provide an = example of an > interoperability problem that does not involve = LDAPv2? If > not, then the > real question is whether we care about LDAPv2 = any longer. I do not. > > -Mark Smith > Netscape > ------_=_NextPart_001_01C1BAF6.035DBAC0-- From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 12:41:23 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25969 for ; Thu, 21 Feb 2002 12:41:23 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1LHc3r87892; Thu, 21 Feb 2002 17:38:03 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 17:38:03 +0000 Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1LHc1U87885 for ; Thu, 21 Feb 2002 17:38:01 GMT Received: from [192.168.1.5] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id SAA16904; Thu, 21 Feb 2002 18:37:34 +0100 (MET) Date: Thu, 21 Feb 2002 18:34:46 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: jhodges@oblix.com, rlmorgan@washington.edu cc: ietf-ldapbis@OpenLDAP.org Subject: IESG comments on draft-ietf-ldapbis-ldapv3-ts-00.txt Message-ID: <7070483.1014316486@localhost> X-Mailer: Mulberry/2.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id g1LHc2U87886 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Can you please look at these things? paf ---------- Forwarded Message ---------- Date: torsdag 21 februari 2002 17.39 +0100 From: Patrik Fältström To: Thomas Narten Subject: Re: draft-ietf-ldapbis-ldapv3-ts-00.txt I get the point, and agree with your view. Let me pass this to the authors. paf --On 2002-02-21 09.06 -0500 Thomas Narten wrote: > E.g.: > >> The term "LDAPv3" MAY be used to informally refer to the protocol speci- >> fied by this set of RFCs. The LDAPv3 protocol suite, as defined here, >> SHOULD be formally identified in other documents by a normative refer- >> ence to this document. > >> Other RFCs (and perhaps Internet-Drafts) MAY specify extensions to >> LDAPv3. Nomenclature denoting such combinations of LDAPv3-plus- >> extension(s) is not defined by this document, and MAY be defined in some >> future document(s). > > My suggestion would be to just downcase all usage of the terms. > > Your call if you think this is worth making an issue of. ---------- End Forwarded Message ---------- From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 13:25:07 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28012 for ; Thu, 21 Feb 2002 13:25:06 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1LILka89074; Thu, 21 Feb 2002 18:21:46 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 18:21:46 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1LILiU89067 for ; Thu, 21 Feb 2002 18:21:44 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1LIKLC45838; Thu, 21 Feb 2002 18:20:21 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020221093314.06175768@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 10:20:25 -0800 To: Christopher Oliva From: "Kurt D. Zeilenga" Subject: RE: ;binary and userCertificate (Was: Private email ...) Cc: "'mcs@netscape.com'" , Ramsay Ron , Christopher Oliva , LDAP BIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 08:37 AM 2002-02-21, Christopher Oliva wrote: >It still hasn't been made clear how the proposed change will have a negative impact. If there are two transfer mechanism, one should be a MUST, one should be a SHOULD or MAY. As one of the two would be not mandatory to implement, then implementations SHOULD NOT use the non-mandatory mechanism unless they have knowledge the peer supports it. Future implementations must be able to interoperate with existing conformant implementations. Existing conformant implementations should not be expected to be altered. So, servers should be restricted to ;binary unless the the client explicitly requested the native string representation. A client would only request the native encoding if it knows the server supports it. A discovery mechanism would have to be provided. Additionally, client developer's would have to be warned that some servers might use ;binary transfer even though the native string was requested. As this is a behavior which the existing specification allowed (due to an ambiguity in the specification which, I hope, will be removed). That is, a client MUST be prepared to interoperate with implementations which did not support the second transfer mechanism. The second transfer option, hence, should be a MAY. As a client would be prepared to interoperate with implementations which did not support the second transfer mechanism and the second transfer mechanism adds no functionality not offered by existing transfer mechanism, adding a second transfer mechanism is pointless. Adding pointless features does harm. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 13:53:59 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29316 for ; Thu, 21 Feb 2002 13:53:58 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1LIoZY91131; Thu, 21 Feb 2002 18:50:36 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 18:50:35 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1LIoYU91124 for ; Thu, 21 Feb 2002 18:50:34 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1LInoC45999; Thu, 21 Feb 2002 18:49:50 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020221104246.06184188@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 10:49:58 -0800 To: Christopher Oliva From: "Kurt D. Zeilenga" Subject: RE: ;binary and userCertificate (Was: Private email ...) Cc: "'mcs@netscape.com'" , Ramsay Ron , Christopher Oliva , LDAP BIS In-Reply-To: <5.1.0.14.0.20020221093314.06175768@127.0.0.1> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 10:20 AM 2002-02-21, Kurt D. Zeilenga wrote: >Additionally, client >developer's would have to be warned that some >servers might use ;binary transfer even though >the native string was requested. As this is a >behavior which the existing specification allowed >(due to an ambiguity in the specification which, >I hope, will be removed). I mispoke. The ambiguity I refer to above doesn't does apply in the certificate case as the existing specification mandates use of ;binary for certificate syntaxes. Hence, this warning would not be needed. My apologies for any confusion caused by my error. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 14:10:02 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29950 for ; Thu, 21 Feb 2002 14:09:59 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1LJ6gI92750; Thu, 21 Feb 2002 19:06:42 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 19:06:42 +0000 Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1LJ6cU92725; Thu, 21 Feb 2002 19:06:38 GMT Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Feb 2002 14:08:25 -0500 Message-ID: From: Christopher Oliva To: "'Kurt D. Zeilenga'" , Christopher Oliva Cc: "'mcs@netscape.com'" , Ramsay Ron , Christopher Oliva , LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Thu, 21 Feb 2002 14:08:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BB0B.228C29D0" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BB0B.228C29D0 Content-Type: text/plain; charset="iso-8859-1" It sounds like you agree with the whole concept but there are a few details to work out (like some strategically placed shoulds and mays). Correct me if I'm wrong. comments below. > At 08:37 AM 2002-02-21, Christopher Oliva wrote: > >It still hasn't been made clear how the proposed change will > have a negative impact. > > If there are two transfer mechanism, one should be a MUST, > one should be a SHOULD or MAY. > > As one of the two would be not mandatory to implement, > then implementations SHOULD NOT use the non-mandatory > mechanism unless they have knowledge the peer supports > it. > > Future implementations must be able to interoperate > with existing conformant implementations. Existing > conformant implementations should not be expected > to be altered. Yes and there are existing conformant implementations using RFC 2559. But the new requirements of the revised RFC 2251 will probably result in some existing implementations to change. Let me explain: in RFC 2251, the original definition of attribute options said they should be treated like attribute subtypes. So, if you define a search filter like "userCertificate=*", by all rights, this should match any entry that contains a userCertificate value. According to the revised RFC 2251bis document, this functionality would no longer work. > > So, servers should be restricted to ;binary unless the > the client explicitly requested the native string > representation. > > A client would only request the native encoding if it > knows the server supports it. A discovery mechanism > would have to be provided. Additionally, client I disagree. Existing client implementations that only use ";binary" would continue to work. Once a server supports the native encoding, the same clients would still continue to work. Clients that are only capable of requesting the native encoding have no choice therefore a discovery mechanism will not help them. This sounds more like a SHOULD requirement directed to the clients that states they should use ;binary - but they don't have to. The point is: why would a client requesting the ;binary transfer suddenly try to switch to use the native encoding? Clients that only support the native encoding can't switch. > developer's would have to be warned that some > servers might use ;binary transfer even though > the native string was requested. As this is a > behavior which the existing specification allowed > (due to an ambiguity in the specification which, > I hope, will be removed). > See my above comment about ambiguity in the search filter. > That is, a client MUST be prepared to interoperate > with implementations which did not support the > second transfer mechanism. The second transfer > option, hence, should be a MAY. > > As a client would be prepared to interoperate with > implementations which did not support the second > transfer mechanism and the second transfer mechanism > adds no functionality not offered by existing transfer > mechanism, adding a second transfer mechanism is > pointless. > > Adding pointless features does harm. Are you suggesting this is pointless ? I disagree. The ";binary" was never needed to work with certificates and the proof is that ldapv2 systems were deployed using RFC 2559 (standard) that did not use ";binary". So I ask you, what do you call a feature that is not necessary ? Chris. ------_=_NextPart_001_01C1BB0B.228C29D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ;binary and userCertificate (Was: Private email ...) It sounds like you agree with the whole concept but = there are a few details to work out (like some strategically placed = shoulds and mays). Correct me if I'm wrong. comments below. > At 08:37 AM 2002-02-21, Christopher Oliva = wrote: > >It still hasn't been made clear how the = proposed change will > have a negative impact. > > If there are two transfer mechanism, one should = be a MUST, > one should be a SHOULD or MAY. > > As one of the two would be not mandatory to = implement, > then implementations SHOULD NOT use the = non-mandatory > mechanism unless they have knowledge the peer = supports > it. > > Future implementations must be able to = interoperate > with existing conformant implementations. = Existing > conformant implementations should not be = expected > to be altered. Yes and there are existing conformant implementations = using RFC 2559. But the new requirements of the revised RFC 2251 will = probably result in some existing implementations to change. Let me = explain: in RFC 2251, the original definition of attribute = options said they should be treated like attribute subtypes. So, if you = define a search filter like "userCertificate=3D*", by all = rights, this should match any entry that contains a userCertificate = value. According to the revised RFC 2251bis document, this = functionality would no longer work. > > So, servers should be restricted to ;binary = unless the > the client explicitly requested the native = string > representation. > > A client would only request the native encoding = if it > knows the server supports it. A discovery = mechanism > would have to be provided. Additionally, = client I disagree. Existing client implementations that only = use ";binary" would continue to work. Once a server supports = the native encoding, the same clients would still continue to work. = Clients that are only capable of requesting the native encoding have no = choice therefore a discovery mechanism will not help them. This sounds = more like a SHOULD requirement directed to the clients that states they = should use ;binary - but they don't have to. The point is: why would a client requesting the = ;binary transfer suddenly try to switch to use the native encoding? = Clients that only support the native encoding can't switch. > developer's would have to be warned that = some > servers might use ;binary transfer even = though > the native string was requested. As this = is a > behavior which the existing specification = allowed > (due to an ambiguity in the specification = which, > I hope, will be removed). > See my above comment about ambiguity in the search = filter. > That is, a client MUST be prepared to = interoperate > with implementations which did not support = the > second transfer mechanism. The second = transfer > option, hence, should be a MAY. > > As a client would be prepared to interoperate = with > implementations which did not support the = second > transfer mechanism and the second transfer = mechanism > adds no functionality not offered by existing = transfer > mechanism, adding a second transfer mechanism = is > pointless. > > Adding pointless features does harm. Are you suggesting this is pointless ? I = disagree. The ";binary" was never needed to work with = certificates and the proof is that ldapv2 systems were deployed using = RFC 2559 (standard) that did not use ";binary". So I ask you, = what do you call a feature that is not necessary ? Chris. ------_=_NextPart_001_01C1BB0B.228C29D0-- From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 15:44:20 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03390 for ; Thu, 21 Feb 2002 15:44:19 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1LKegM97311; Thu, 21 Feb 2002 20:40:42 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 20:40:42 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1LKefU97304 for ; Thu, 21 Feb 2002 20:40:41 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1LKedC46544; Thu, 21 Feb 2002 20:40:39 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020221111414.061774e8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 12:40:47 -0800 To: Christopher Oliva From: "Kurt D. Zeilenga" Subject: RE: ;binary and userCertificate (Was: Private email ...) Cc: LDAP BIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 11:08 AM 2002-02-21, Christopher Oliva wrote: >Are you suggesting this is pointless ? Yes. Because adding a second transfer mechanism for these syntaxes solves no interoperability problem between independently developed implementations of the LDAPv3 technical specification. In regards to the handling of (userCertificate=*) versus (userCertificate;binary=*) I would have to agree that the revision I-D needs to be clarified. I will offer a minor clarification in a separate post. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 18:58:00 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07587 for ; Thu, 21 Feb 2002 18:57:59 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1LNsKr06105; Thu, 21 Feb 2002 23:54:20 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 21 Feb 2002 23:54:20 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1LNsFU06084; Thu, 21 Feb 2002 23:54:16 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Fri, 22 Feb 2002 10:53:58 +1100 Message-ID: From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Fri, 22 Feb 2002 10:53:56 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt, Comments inline - see [RR]. Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Thursday, 21 February 2002 19:34 To: Ramsay, Ron Cc: LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) At 10:59 PM 2002-02-20, Ramsay, Ron wrote: >Kurt, > >It seems that much of your argument hinges on ASN.1 definitions of LDAP >syntaxes. You referred me to RFC 2252 Section 4.3.2 for this. I read that >section but could find no ASN.1 definitions. RFC 2251 says: The syntax of the binary value is an ASN.1 data type definition which is referenced by the "SYNTAX" part of the attribute type definition. That reference is provided, for most every syntax (including certificate) by the table in RFC 2252, 4.3.2. [RR] If you search RFC 2252 for "SYNTAX" you will see there is no ASN.1 data type definition. There is an object identifier. We could go to the table, which you seem to regard as a reference to X.520, but look at a complex type, PresentationAddress, for example. Values in this syntax are encoded with the representation described in RFC 1278 [6]. This is not ASN.1! >You also seem to think there are two ways to use DNs, In LDAPv3, you can transfer each and every value syntax in two ways. You can transfer the string representation or you can transfer a BER representation. [RR] That's what you say! >in particular, the use >of a DN as an attribute value allows the X.500 encoding. But look at Section >6.9 of RFC 2252 - > > Values in the Distinguished Name syntax are encoded to have the > representation defined in [5]. Note that this representation is not > reversible to an ASN.1 encoding used in X.500 for Distinguished > Names, as the CHOICE of any DirectoryString element in an RDN is no > longer known. > >That is, ALL DNs are strings and no other definition exists for them. That's paragraph is not precise. Each DN has multiple string representations. While some of these representations may not be reversible, each DN does have a reversible string representation. That form should be used when reversibility is desired. [RR] Pardon! Please provide an example. A reference would also be nice. But thanks for the information that RFC 2252 is not to be believed - I think it cancels all of your arguments. >You also make some statement about X.500 gateways. I make statements about LDAP/DAP gateways. The term "X.500 gateway" is misleading as both LDAP and DAP are access protocols to X.500 directories. >If gatewaying were part of the LDAP standard I never said it was. But LDAP is certainly designed to allow implementation of DAP/LDAP gateways. [RR] Desiged how? Could you give me a reference. >Regarding the ;binary encoding of attributes on the mailing list, I just >read, memorise and delete. I think Tim Howes was advising someone about >wrapping strings, particularly that there would be two octet string tags >around the string. If, you transfer without ;binary, the AttributeValue, an OCTET STRING, contains just the octets of the value. E.g. an AttributeValue transferring userPassword:foo is encoded as the octets 04 03 66 6F 6F, not 04 05 04 03 66 6F 6F. However, If you use ;binary to transfer a value of OCTET STRING syntax, then the AttributeValue, itself an OCTET STRING, contains the BER encoding of the value. For example, the AttributeValue transferring userPassword;binary:foo is encoded as the octets 04 05 04 03 66 6F 6F not 04 03 66 6F 6F. [RR] Didn't I say precisely this? Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 19:27:08 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07996 for ; Thu, 21 Feb 2002 19:27:04 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1M0NL307154; Fri, 22 Feb 2002 00:23:21 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Feb 2002 00:23:21 +0000 Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1M0NIU07147 for ; Fri, 22 Feb 2002 00:23:18 GMT Received: from 209-239-195-130.oak.jps.net ([209.239.195.130] helo=asn-1.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16e3UY-0004nj-00 for ietf-ldapbis@OpenLDAP.org; Thu, 21 Feb 2002 19:23:14 -0500 Message-ID: <3C758EB0.20D42555@asn-1.com> Date: Thu, 21 Feb 2002 19:20:00 -0500 From: Phil Griffin Organization: Griffin Consulting - http://ASN-1.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: LDAP BIS Subject: Re: ;binary and userCertificate (Was: Private email ...) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote (in part): > > Kurt, > > Comments inline - see [RR]. > > Ron. > > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, 21 February 2002 19:34 > To: Ramsay, Ron > Cc: LDAP BIS > Subject: RE: ;binary and userCertificate (Was: Private email ...) > > At 10:59 PM 2002-02-20, Ramsay, Ron wrote: > >Kurt, > > > >It seems that much of your argument hinges on ASN.1 definitions of LDAP > >syntaxes. You referred me to RFC 2252 Section 4.3.2 for this. I read that > >section but could find no ASN.1 definitions. > > RFC 2251 says: > The syntax of the binary value is an ASN.1 data type definition > which is referenced by the "SYNTAX" part of the attribute type > definition. > > That reference is provided, for most every syntax (including > certificate) by the table in RFC 2252, 4.3.2. > > [RR] If you search RFC 2252 for "SYNTAX" you will see there is no ASN.1 data > type definition. There is an object identifier. We could go to the table, > which you seem to regard as a reference to X.520, but look at a complex > type, PresentationAddress, for example. > > Values in this syntax are encoded with the representation described > in RFC 1278 [6]. > > This is not ASN.1! SYNTAX is an ASN.1 keyword but it is not a type name or an object or a class. It is part of the notation provided as part of an information object class definition and is used to describe objects of a given class. For example, in X.509 the definition of the EXTENSION class provides a useful notation so that users can define specific extension objects EXTENSION ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &ExtnType } WITH SYNTAX { SYNTAX &ExtnType IDENTIFIED BY &id } the notation "SYNTAX &ExtnType IDENTIFIED BY &id" indicates that the EXTENSION class field "&ExtnType" is an open type, which can be any ASN.1 type. &id is the value of an OID and the UNIQUE modifier states that each OID in an information object set of class EXTENSION must be unique in that context. Generally, information objects are placed in sets and used to bind the valid values in two or more components of a sequence, so that (for example) when the OID id-ce-authorityKeyIdentifier appears in one component of a sequence, a value of type AuthorityKeyIdentifier is the only valid value allowed in an associated component. This is really ANY DEFINED BY corrected and made to be of actual use by ASN.1 tools in enforcing a given schema (specification). This notation is not defined in the superseded X.208 standard, but is a part of the current ASN.1 standards available for free on the web at http://www.itu.int/ITU-T/studygroups/com17/languages/index.html and in the draft version of the 2002 edition at Host: ftp://ties.itu.int login: asn1 password: notation1 So, SYNTAX is ASN.1, but it's probably correct to say it's not treated as actual ASN.1 in the context of LDAP. Phil Griffin From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 20:00:19 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08350 for ; Thu, 21 Feb 2002 20:00:18 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1M0vwD08071; Fri, 22 Feb 2002 00:57:58 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Feb 2002 00:57:58 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1M0vuU08064 for ; Fri, 22 Feb 2002 00:57:56 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Fri, 22 Feb 2002 11:57:36 +1100 Message-ID: From: "Ramsay, Ron" To: Phil Griffin , LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Fri, 22 Feb 2002 11:57:34 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Thanks, Phil, but I thought Kurt was referring to LDAP. He has been arguing that LDAP defines an ASN.1 type for its syntaxes, because he wants ;binary to transfer this type, but I have failed to find specific references in the LDAP specs. For x.500, I'm with you 100% - we use X.500 ourselves! Ron. -----Original Message----- From: Phil Griffin [mailto:phil.griffin@asn-1.com] Sent: Friday, 22 February 2002 11:20 To: LDAP BIS Subject: Re: ;binary and userCertificate (Was: Private email ...) "Ramsay, Ron" wrote (in part): > > Kurt, > > Comments inline - see [RR]. > > Ron. > > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, 21 February 2002 19:34 > To: Ramsay, Ron > Cc: LDAP BIS > Subject: RE: ;binary and userCertificate (Was: Private email ...) > > At 10:59 PM 2002-02-20, Ramsay, Ron wrote: > >Kurt, > > > >It seems that much of your argument hinges on ASN.1 definitions of LDAP > >syntaxes. You referred me to RFC 2252 Section 4.3.2 for this. I read that > >section but could find no ASN.1 definitions. > > RFC 2251 says: > The syntax of the binary value is an ASN.1 data type definition > which is referenced by the "SYNTAX" part of the attribute type > definition. > > That reference is provided, for most every syntax (including > certificate) by the table in RFC 2252, 4.3.2. > > [RR] If you search RFC 2252 for "SYNTAX" you will see there is no ASN.1 data > type definition. There is an object identifier. We could go to the table, > which you seem to regard as a reference to X.520, but look at a complex > type, PresentationAddress, for example. > > Values in this syntax are encoded with the representation described > in RFC 1278 [6]. > > This is not ASN.1! SYNTAX is an ASN.1 keyword but it is not a type name or an object or a class. It is part of the notation provided as part of an information object class definition and is used to describe objects of a given class. For example, in X.509 the definition of the EXTENSION class provides a useful notation so that users can define specific extension objects EXTENSION ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &ExtnType } WITH SYNTAX { SYNTAX &ExtnType IDENTIFIED BY &id } the notation "SYNTAX &ExtnType IDENTIFIED BY &id" indicates that the EXTENSION class field "&ExtnType" is an open type, which can be any ASN.1 type. &id is the value of an OID and the UNIQUE modifier states that each OID in an information object set of class EXTENSION must be unique in that context. Generally, information objects are placed in sets and used to bind the valid values in two or more components of a sequence, so that (for example) when the OID id-ce-authorityKeyIdentifier appears in one component of a sequence, a value of type AuthorityKeyIdentifier is the only valid value allowed in an associated component. This is really ANY DEFINED BY corrected and made to be of actual use by ASN.1 tools in enforcing a given schema (specification). This notation is not defined in the superseded X.208 standard, but is a part of the current ASN.1 standards available for free on the web at http://www.itu.int/ITU-T/studygroups/com17/languages/index.html and in the draft version of the 2002 edition at Host: ftp://ties.itu.int login: asn1 password: notation1 So, SYNTAX is ASN.1, but it's probably correct to say it's not treated as actual ASN.1 in the context of LDAP. Phil Griffin From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 20:14:00 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08528 for ; Thu, 21 Feb 2002 20:13:59 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1M1Bsk08434; Fri, 22 Feb 2002 01:11:54 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Feb 2002 01:11:54 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1M1BpU08413; Fri, 22 Feb 2002 01:11:51 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Fri, 22 Feb 2002 12:11:35 +1100 Message-ID: From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , Christopher Oliva Cc: "'mcs@netscape.com'" , Christopher Oliva , LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Fri, 22 Feb 2002 12:11:33 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I don't understand this business about two transfer syntaxes. Certificate is to be given a native encoding which is, basically, the certificate. If you request "certificate", you get a binary blob which is the certificate. If you request "certificate;binary", you get the same thing! As regards compatibility, if a client requests "certificate;binary", the server returns "certificate;binary". If a client requests "certificate" (and no current conforming client will), the server returns "certificate". Seems self-correcting to me! Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, 22 February 2002 5:20 To: Christopher Oliva Cc: 'mcs@netscape.com'; Ramsay, Ron; Christopher Oliva; LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) At 08:37 AM 2002-02-21, Christopher Oliva wrote: >It still hasn't been made clear how the proposed change will have a negative impact. If there are two transfer mechanism, one should be a MUST, one should be a SHOULD or MAY. As one of the two would be not mandatory to implement, then implementations SHOULD NOT use the non-mandatory mechanism unless they have knowledge the peer supports it. Future implementations must be able to interoperate with existing conformant implementations. Existing conformant implementations should not be expected to be altered. So, servers should be restricted to ;binary unless the the client explicitly requested the native string representation. A client would only request the native encoding if it knows the server supports it. A discovery mechanism would have to be provided. Additionally, client developer's would have to be warned that some servers might use ;binary transfer even though the native string was requested. As this is a behavior which the existing specification allowed (due to an ambiguity in the specification which, I hope, will be removed). That is, a client MUST be prepared to interoperate with implementations which did not support the second transfer mechanism. The second transfer option, hence, should be a MAY. As a client would be prepared to interoperate with implementations which did not support the second transfer mechanism and the second transfer mechanism adds no functionality not offered by existing transfer mechanism, adding a second transfer mechanism is pointless. Adding pointless features does harm. Kurt From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 21:51:08 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10609 for ; Thu, 21 Feb 2002 21:51:07 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1M2maZ10747; Fri, 22 Feb 2002 02:48:36 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Feb 2002 02:48:36 +0000 Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1M2mUU10727; Fri, 22 Feb 2002 02:48:31 GMT Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Feb 2002 21:48:04 -0500 Message-ID: From: Christopher Oliva To: "'Kurt D. Zeilenga'" , Christopher Oliva Cc: "'mcs@netscape.com'" , Ramsay Ron , Christopher Oliva , LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Thu, 21 Feb 2002 21:50:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BB4B.A8F42B40" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BB4B.A8F42B40 Content-Type: text/plain; charset="iso-8859-1" If you yourself have made this error ... it is very possible that some vendor has made the same error and might explain broken implementations. I for one think the spec is ambiguous ... let me explain: RFC 2251, clause 4.1.5 defines attribute descriptions as subtypes of the attribute without any options. Neither this clause nor clause 4.1.5.1 says anything special about this not holding for ";binary". The first problem is that subtypes are not defined in this RFC. As it turns out, the X.501 definition explicitly says that values can be accessed via the "supertype" as well as the subtype (I'm paraphrasing). Now, clause 4.1.5.1 says that "clients MUST NOT expect servers to return an attribute in binary format if the client requested that attribute by name without the binary option". The implication is that servers may infact, return the binary encoding even if the binary option was not used by the client since the clause says nothing about the behaviour of the servers in this instance. So who's wrong here? The server for generating the binary encoding? Not according to the RFC. This is in my opinion, sufficient proof that there is ambiguity. There is sufficient grounds to say that servers should be allowed to return binary encodings if a client makes a request without ";binary". Now look at RFC 2252. Clause 6.5 defining the certificate syntax says this: "... values in this syntax MUST only be transferred using the binary encoding, by requesting or returning the attributes with descriptions 'userCertificate;binary' or 'caCertificate;binary'." The main point being stressed by the MUST is the transfer encoding. One could argue that the MUST only applies to the transfer using the binary encoding but not necessarily to the following clause that talks about the attribute descriptions. Now look at the word "or" between 'requesting' and 'returning'. It is possible that the word "or" was used instead of the word "and" in order to account for the fact that clients might request userCertificates without the ;binary option. This directly conflicts with the MUST NOT of 4.1.5.1 from RFC 2251 above. This same thing could be used to justify a server returning userCertificate instead of userCertificate;binary. Chris. > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, February 21, 2002 1:50 PM > To: Christopher Oliva > Cc: 'mcs@netscape.com'; Ramsay Ron; Christopher Oliva; LDAP BIS > Subject: RE: ;binary and userCertificate (Was: Private email ...) > > > At 10:20 AM 2002-02-21, Kurt D. Zeilenga wrote: > >Additionally, client > >developer's would have to be warned that some > >servers might use ;binary transfer even though > >the native string was requested. As this is a > >behavior which the existing specification allowed > >(due to an ambiguity in the specification which, > >I hope, will be removed). > > I mispoke. The ambiguity I refer to above doesn't > does apply in the certificate case as the existing > specification mandates use of ;binary for certificate > syntaxes. Hence, this warning would not be needed. > > My apologies for any confusion caused by my error. > > Kurt > > ------_=_NextPart_001_01C1BB4B.A8F42B40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ;binary and userCertificate (Was: Private email ...) If you yourself have made this error ... it is very = possible that some vendor has made the same error and might explain = broken implementations. I for one think the spec is ambiguous ... let me = explain: RFC 2251, clause 4.1.5 defines attribute descriptions = as subtypes of the attribute without any options. Neither this clause = nor clause 4.1.5.1 says anything special about this not holding for = ";binary". The first problem is that subtypes are not defined = in this RFC. As it turns out, the X.501 definition explicitly says that = values can be accessed via the "supertype" as well as the = subtype (I'm paraphrasing). Now, clause 4.1.5.1 says that "clients MUST NOT = expect servers to return an attribute in binary format if the client = requested that attribute by name without the binary option". The = implication is that servers may infact, return the binary encoding even = if the binary option was not used by the client since the clause says = nothing about the behaviour of the servers in this instance. So who's wrong here? The server for generating the = binary encoding? Not according to the RFC. This is in my opinion, sufficient proof that there is = ambiguity. There is sufficient grounds to say that servers should be = allowed to return binary encodings if a client makes a request without = ";binary". Now look at RFC 2252. Clause 6.5 defining the certificate syntax says = this: "... values in this syntax MUST only be = transferred using the binary encoding, by requesting or = returning the attributes with descriptions = 'userCertificate;binary' or 'caCertificate;binary'." The main point being stressed by the MUST is the = transfer encoding. One could argue that the MUST only applies to the = transfer using the binary encoding but not necessarily to the following = clause that talks about the attribute descriptions. Now look at the word "or" between = 'requesting' and 'returning'. It is possible that the word = "or" was used instead of the word "and" in order to = account for the fact that clients might request userCertificates = without the ;binary option. This directly conflicts with the MUST NOT = of 4.1.5.1 from RFC 2251 above. This same thing could be used to = justify a server returning userCertificate instead of = userCertificate;binary. Chris. > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, February 21, 2002 1:50 = PM > To: Christopher Oliva > Cc: 'mcs@netscape.com'; Ramsay Ron; Christopher = Oliva; LDAP BIS > Subject: RE: ;binary and userCertificate (Was: = Private email ...) > > > At 10:20 AM 2002-02-21, Kurt D. Zeilenga = wrote: > >Additionally, client > >developer's would have to be warned that = some > >servers might use ;binary transfer even = though > >the native string was requested. As = this is a > >behavior which the existing specification = allowed > >(due to an ambiguity in the specification = which, > >I hope, will be removed). > > I mispoke. The ambiguity I refer to above = doesn't > does apply in the certificate case as the = existing > specification mandates use of ;binary for = certificate > syntaxes. Hence, this warning would not = be needed. > > My apologies for any confusion caused by my = error. > > Kurt > > ------_=_NextPart_001_01C1BB4B.A8F42B40-- From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 22:30:44 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11420 for ; Thu, 21 Feb 2002 22:30:44 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1M3SZC11481; Fri, 22 Feb 2002 03:28:35 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Feb 2002 03:28:35 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1M3SVU11461; Fri, 22 Feb 2002 03:28:31 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Fri, 22 Feb 2002 14:28:14 +1100 Message-ID: From: "Ramsay, Ron" To: Christopher Oliva , "'Kurt D. Zeilenga'" Cc: LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Fri, 22 Feb 2002 14:28:12 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Hi, Regarding 6.5, this is actually a feature of English, not of the spec. One may request an attribute or return an attribute (though not both at the same time) and in each case ;binary should (MUST) be used. Regarding the supertype issue, the new version of the specs propose that ;binary is a transfer ooption and is not related to normal attribute subtyping. The radicals on the list would like ;binary to be dropped as it appears to be solving a problem that doesn't actually exist. Ron. -----Original Message----- From: Christopher Oliva [mailto:Chris.Oliva@entrust.com] Sent: Friday, 22 February 2002 13:50 To: 'Kurt D. Zeilenga'; Christopher Oliva Cc: 'mcs@netscape.com'; Ramsay, Ron; Christopher Oliva; LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) If you yourself have made this error ... it is very possible that some vendor has made the same error and might explain broken implementations. I for one think the spec is ambiguous ... let me explain: RFC 2251, clause 4.1.5 defines attribute descriptions as subtypes of the attribute without any options. Neither this clause nor clause 4.1.5.1 says anything special about this not holding for ";binary". The first problem is that subtypes are not defined in this RFC. As it turns out, the X.501 definition explicitly says that values can be accessed via the "supertype" as well as the subtype (I'm paraphrasing). Now, clause 4.1.5.1 says that "clients MUST NOT expect servers to return an attribute in binary format if the client requested that attribute by name without the binary option". The implication is that servers may infact, return the binary encoding even if the binary option was not used by the client since the clause says nothing about the behaviour of the servers in this instance. So who's wrong here? The server for generating the binary encoding? Not according to the RFC. This is in my opinion, sufficient proof that there is ambiguity. There is sufficient grounds to say that servers should be allowed to return binary encodings if a client makes a request without ";binary". Now look at RFC 2252. Clause 6.5 defining the certificate syntax says this: "... values in this syntax MUST only be transferred using the binary encoding, by requesting or returning the attributes with descriptions 'userCertificate;binary' or 'caCertificate;binary'." The main point being stressed by the MUST is the transfer encoding. One could argue that the MUST only applies to the transfer using the binary encoding but not necessarily to the following clause that talks about the attribute descriptions. Now look at the word "or" between 'requesting' and 'returning'. It is possible that the word "or" was used instead of the word "and" in order to account for the fact that clients might request userCertificates without the ;binary option. This directly conflicts with the MUST NOT of 4.1.5.1 from RFC 2251 above. This same thing could be used to justify a server returning userCertificate instead of userCertificate;binary. Chris. > -----Original Message----- > From: Kurt D. Zeilenga [ mailto:Kurt@OpenLDAP.org ] > Sent: Thursday, February 21, 2002 1:50 PM > To: Christopher Oliva > Cc: 'mcs@netscape.com'; Ramsay Ron; Christopher Oliva; LDAP BIS > Subject: RE: ;binary and userCertificate (Was: Private email ...) > > > At 10:20 AM 2002-02-21, Kurt D. Zeilenga wrote: > >Additionally, client > >developer's would have to be warned that some > >servers might use ;binary transfer even though > >the native string was requested. As this is a > >behavior which the existing specification allowed > >(due to an ambiguity in the specification which, > >I hope, will be removed). > > I mispoke. The ambiguity I refer to above doesn't > does apply in the certificate case as the existing > specification mandates use of ;binary for certificate > syntaxes. Hence, this warning would not be needed. > > My apologies for any confusion caused by my error. > > Kurt > > From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 21 23:25:31 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12912 for ; Thu, 21 Feb 2002 23:25:30 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1M4N9F12361; Fri, 22 Feb 2002 04:23:09 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Feb 2002 04:23:09 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1M4N5U12351 for ; Fri, 22 Feb 2002 04:23:05 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1M4MqC49044; Fri, 22 Feb 2002 04:22:52 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020221200054.017d3e60@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 20:23:00 -0800 To: "Ramsay, Ron" From: "Kurt D. Zeilenga" Subject: RE: ;binary and userCertificate (Was: Private email ...) Cc: Phil Griffin , LDAP BIS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 04:57 PM 2002-02-21, Ramsay, Ron wrote: >Thanks, Phil, but I thought Kurt was referring to LDAP. He has been arguing >that LDAP defines an ASN.1 type for its syntaxes, because he wants ;binary >to transfer this type, but I have failed to find specific references in the >LDAP specs. Even if ;binary was stricken from RFC 2251, I would argue that there is the LDAP syntax OID identifies the corresponding ASN.1 data type in X.500. Because without this relationship, little of LDAP would actually make sense. For consider, ( 2.5.13.29 NAME 'integerFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) There is zero text in LDAP RFCs which say how to implement this, but yet there are multiple interoperable implementations of this matching rule. Why? Because 2.5.13.29 is associated with the X.500 matching rule integerFirstComponentMatch and 1.3.6.1.4.1.1466.115.121.1.27 is associated with the ASN.1 date type INTEGER. While the LDAP specification uses poor mechanism to relate OIDs with elements of X.500 schema, most implementors have figured out not only that there are relationships, but agree to which OID refers to what. If they didn't agree, things wouldn't interoperate. In revising the specification, it's our job to clarify the specification so that others may repeatedly development which interoperate. This will require being a lot clearer about the relationship between LDAP and X.500. I will take your above comments as indications of an area where we need to provide clarification. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 22 00:04:47 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13756 for ; Fri, 22 Feb 2002 00:04:47 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1M52eb13107; Fri, 22 Feb 2002 05:02:40 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Feb 2002 05:02:40 +0000 Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1M52bU13100 for ; Fri, 22 Feb 2002 05:02:37 GMT Received: (qmail 23877 invoked from network); 22 Feb 2002 04:49:21 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 22 Feb 2002 04:49:21 -0000 Reply-To: From: "Steven Legg" To: "'Ramsay, Ron'" Cc: "'LDAP BIS'" Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Fri, 22 Feb 2002 16:01:00 +1100 Message-ID: <004b01c1bb5d$ec48ef40$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ron, Comments in-line. Ramsay, Ron wrote: > Sent: Friday, 22 February 2002 10:54 > To: Kurt D. Zeilenga > Cc: LDAP BIS > Subject: RE: ;binary and userCertificate (Was: Private email ...) > > > Kurt, > > Comments inline - see [RR]. > > Ron. > > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Thursday, 21 February 2002 19:34 > To: Ramsay, Ron > Cc: LDAP BIS > Subject: RE: ;binary and userCertificate (Was: Private email ...) > > > At 10:59 PM 2002-02-20, Ramsay, Ron wrote: > >Kurt, > > > >It seems that much of your argument hinges on ASN.1 > definitions of LDAP > >syntaxes. You referred me to RFC 2252 Section 4.3.2 for > this. I read that > >section but could find no ASN.1 definitions. RFC 2252 is deficient in that it doesn't formally state the corresponding ASN.1 type for each LDAP syntax. That's something we should fix in LDAPbis. However, the correlation between LDAP syntaxes and the ASN.1 types of X.500 attributes is pretty obvious to anyone who supports both LDAP and X.500 (and these are the people who are supporting ;binary for all LDAP syntaxes). For example, given these LDAP definitions: ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) ( 2.5.21.6 NAME 'objectClasses' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation ) and this X.500 definition: objectClasses ATTRIBUTE ::= { WITH SYNTAX ObjectClassDescription EQUALITY MATCHING RULE objectIdentifierFirstComponentMatch USAGE directoryOperation ID { 2 5 21 6 } } it is not hard to reach the conclusion that ObjectClassDescription is the "ASN.1 data type definition which is referenced by the SYNTAX part of the attribute type definition" for the objectClasses attribute. > > RFC 2251 says: > The syntax of the binary value is an ASN.1 data type definition > which is referenced by the "SYNTAX" part of the attribute type > definition. > > That reference is provided, for most every syntax (including > certificate) by the table in RFC 2252, 4.3.2. > > [RR] If you search RFC 2252 for "SYNTAX" you will see there > is no ASN.1 data > type definition. There is an object identifier. We could go > to the table, > which you seem to regard as a reference to X.520, but look at > a complex > type, PresentationAddress, for example. > > Values in this syntax are encoded with the representation described > in RFC 1278 [6]. > > This is not ASN.1! I observe that the description of the Certificate syntax (RFC 2252, 6.5) has no ASN.1 and makes no specific mention of the Certificate ASN.1 type from X.509, yet I am 99.99% certain that when you ask for userCertificate;binary it is the BER encoding of a value of the Certificate ASN.1 type that you are expecting to see. You seem to be quite happy to make the leap of faith for the Certificate syntax. Why not for the other syntaxes ? > > >You also seem to think there are two ways to use DNs, > > In LDAPv3, you can transfer each and every value syntax in > two ways. You can transfer the string representation or > you can transfer a BER representation. > > [RR] That's what you say! That's what LDAP/X.500 implementations do! [snip] > >Regarding the ;binary encoding of attributes on the mailing > list, I just > >read, memorise and delete. I think Tim Howes was advising > someone about > >wrapping strings, particularly that there would be two octet > string tags > >around the string. > > If, you transfer without ;binary, the AttributeValue, an OCTET STRING, > contains just the octets of the value. E.g. an AttributeValue > transferring userPassword:foo is encoded as the octets 04 03 66 6F 6F, > not 04 05 04 03 66 6F 6F. > > However, If you use ;binary to transfer a value of OCTET STRING > syntax, then the AttributeValue, itself an OCTET STRING, contains > the BER encoding of the value. For example, the AttributeValue > transferring userPassword;binary:foo is encoded as the octets > 04 05 04 03 66 6F 6F not 04 03 66 6F 6F. > > [RR] Didn't I say precisely this? I believe you said "For most attributes this BER is simply an octet string wrapping.". Kurt had the misfortune to pick a syntax from RFC 2252 where this is actually the case. For the vast majority of the RFC 2252 syntaxes the third octet will be something other than the tag for OCTET STRING. For example, for a value of objectClasses;binary the third octet will be the tag for a SEQUENCE type. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 22 00:05:14 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13769 for ; Fri, 22 Feb 2002 00:05:12 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1M518D13084; Fri, 22 Feb 2002 05:01:08 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Feb 2002 05:01:08 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1M516U13064; Fri, 22 Feb 2002 05:01:06 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Fri, 22 Feb 2002 16:00:49 +1100 Message-ID: From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: Phil Griffin , LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Fri, 22 Feb 2002 16:00:32 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt, Excuse me, but 1.3.6.1.4.1.1466.115.121.1.27 is not associated with INTEGER from the X.500 point of view. INTEGER is pretty simple, but if you consider PresentationAddress, I would say that the SYNTAX doesn't specify it at all. This should be clarified by relating it more strongly to the X.500 definition (or including the definitions in, say, a syntax document) and moving into the X.500 world by indicating that all syntaxes have an ASN.1 form and some also have a string form. Thanks, Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Friday, 22 February 2002 15:23 To: Ramsay, Ron Cc: Phil Griffin; LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) At 04:57 PM 2002-02-21, Ramsay, Ron wrote: >Thanks, Phil, but I thought Kurt was referring to LDAP. He has been arguing >that LDAP defines an ASN.1 type for its syntaxes, because he wants ;binary >to transfer this type, but I have failed to find specific references in the >LDAP specs. Even if ;binary was stricken from RFC 2251, I would argue that there is the LDAP syntax OID identifies the corresponding ASN.1 data type in X.500. Because without this relationship, little of LDAP would actually make sense. For consider, ( 2.5.13.29 NAME 'integerFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) There is zero text in LDAP RFCs which say how to implement this, but yet there are multiple interoperable implementations of this matching rule. Why? Because 2.5.13.29 is associated with the X.500 matching rule integerFirstComponentMatch and 1.3.6.1.4.1.1466.115.121.1.27 is associated with the ASN.1 date type INTEGER. While the LDAP specification uses poor mechanism to relate OIDs with elements of X.500 schema, most implementors have figured out not only that there are relationships, but agree to which OID refers to what. If they didn't agree, things wouldn't interoperate. In revising the specification, it's our job to clarify the specification so that others may repeatedly development which interoperate. This will require being a lot clearer about the relationship between LDAP and X.500. I will take your above comments as indications of an area where we need to provide clarification. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 22 02:29:23 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23683 for ; Fri, 22 Feb 2002 02:29:23 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1M7RHt17844; Fri, 22 Feb 2002 07:27:17 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Feb 2002 07:27:17 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1M7RFU17836 for ; Fri, 22 Feb 2002 07:27:15 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1M7RDC49841; Fri, 22 Feb 2002 07:27:13 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020221214930.017c67e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Feb 2002 23:27:20 -0800 To: Christopher Oliva From: "Kurt D. Zeilenga" Subject: RE: ;binary Cc: Christopher Oliva , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 06:50 PM 2002-02-21, Christopher Oliva wrote: >There is sufficient grounds to say that servers should be allowed to return binary encodings if a client makes a request without ";binary". The problem with this is that if a server is allowed to return ;binary when the client makes a request without ;binary then the servers might actually do that. That would be bad as client wouldn't get what they asked for. The solution is simple, a client gets what they ask for. If they ask for "foo", they get "foo". If they ask for "foo;binary", they get "foo;binary". While RFC 2251 did say "foo;binary" is to be treated as a subtype as "foo", it also said clients MUST NOT expect "foo;binary" when "foo" was requested. The approach specified in -06 lets the MUST NOT trump the "is to be treated as" statement. This leads to a specification would addresses the ambiguity while not break existing LDAPv3 compliant implementations. Kurt From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 22 10:08:12 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04948 for ; Fri, 22 Feb 2002 10:08:11 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1MF5oY34743; Fri, 22 Feb 2002 15:05:50 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Feb 2002 15:05:49 +0000 Received: from sottmxs02.entrust.com (client52.entrust.com [216.191.251.52]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1MF5kU34723; Fri, 22 Feb 2002 15:05:47 GMT Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Feb 2002 10:07:35 -0500 Message-ID: From: Christopher Oliva To: "'Ramsay, Ron'" , Christopher Oliva , "'Kurt D. Zeilenga'" Cc: LDAP BIS Subject: RE: ;binary and userCertificate (Was: Private email ...) Date: Fri, 22 Feb 2002 10:07:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBB2.97720790" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BBB2.97720790 Content-Type: text/plain; charset="iso-8859-1" > > Regarding 6.5, this is actually a feature of English, not of > the spec. One > may request an attribute or return an attribute (though not > both at the same > time) and in each case ;binary should (MUST) be used. > You cannot deny that the particular wording in 6.5 is clumsy and can be interpreted in different ways. A more clear wording should have been used. It is possible, because of unclear english, to interpret this clause to mean that the MUST (strictly) applies only to the encoding and not the use of ;binary in both the request and response. That is one possible interpretation. I will suggest another in a following email. Chris. ------_=_NextPart_001_01C1BBB2.97720790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ;binary and userCertificate (Was: Private email ...) > > Regarding 6.5, this is actually a feature of = English, not of > the spec. One > may request an attribute or return an attribute = (though not > both at the same > time) and in each case ;binary should (MUST) be = used. > You cannot deny that the particular wording in 6.5 is = clumsy and can be interpreted in different ways. A more clear wording = should have been used. It is possible, because of unclear english, to = interpret this clause to mean that the MUST (strictly) applies only to = the encoding and not the use of ;binary in both the request and = response. That is one possible interpretation. I will suggest = another in a following email. Chris. ------_=_NextPart_001_01C1BBB2.97720790-- From owner-ietf-ldapbis@OpenLDAP.org Fri Feb 22 10:58:53 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07303 for ; Fri, 22 Feb 2002 10:58:52 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1MFuQZ37684; Fri, 22 Feb 2002 15:56:26 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 22 Feb 2002 15:56:26 +0000 Received: from sottmxs02.entrust.com (client52.entrust.com [216.191.251.52]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1MFuJU37664; Fri, 22 Feb 2002 15:56:19 GMT Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Feb 2002 10:54:29 -0500 Message-ID: From: Christopher Oliva To: "'Kurt D. Zeilenga'" , Christopher Oliva Cc: Christopher Oliva , ietf-ldapbis@OpenLDAP.org, "David Chadwick SMTP (E-mail)" Subject: RE: ;binary Date: Fri, 22 Feb 2002 10:57:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBB9.AB1616E0" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BBB9.AB1616E0 Content-Type: text/plain; charset="iso-8859-1" I think it is possible to build and deploy an ldapv3 compliant system where the clients request certificates without ";binary" and actually receive valid BER encoded certificates from the server. Let me explain: First, look again at 6.5 of 2252. Because of the particular wording that is used, it is possible to interpret the clause as follows: as long as the encoding used is the binary encoding, either the request or the response can use the ";binary" attribute option but not necessarily both. This makes perfect sense. If the client requests "userCertificate" then the server returns "userCertificate;binary" and the condition is satisfied (the client knows what they are getting). Now look at 4.1.5.1 of 2251. The statement is that "... clients MUST NOT expect servers to return an attribute in binary format if the client requested that attribute by name without the binary option." Note that nothing prohibits the client from actually performing the search without ;binary - it only says "don't expect this to work". Similarly, nothing prohibits the server from responding to a request where the search did not use ";binary". Now, to deal with the "MUST NOT expect" clause, there are two possibilities - first, because of the interpretation of 6.5 shown above, the client actually can expect this request to work, for the Certificate syntax, since the 6.5 clause allows it (the expectation is provided by the 6.5 clause). The generic "MUST NOT expect" statement then applies to other syntaxes but not to the Certificate (and the other X.509 syntaxes). The second possibility is that the "MUST NOT expect" clause directed to the clients can be easily dealt with. All that is needed for an ldapv3 compliant client is to show that there is reasonable error recovery procedures that have been implemented. Since the RFC does not indicate what those error processing procedures can be, almost anything can satisfy this statement. The MUST NOT expect statement does not actually preclude this query from actually working. I submit to you that this type of system can exist and that the revisions of LDAPbis and PKIX must account for the given ambiguity. I also suggest the perfect way to do this is to accept the suggestions for the new PKIX I-D. More comments below. > At 06:50 PM 2002-02-21, Christopher Oliva wrote: > >There is sufficient grounds to say that servers should be > allowed to return binary encodings if a client makes a > request without ";binary". > > The problem with this is that if a server is allowed to > return ;binary when the client makes a request without > ;binary then the servers might actually do that. That > would be bad as client wouldn't get what they asked for. > As I have shown above, the client would know what they are getting since the server has replied with ";binary". > The solution is simple, a client gets what they ask for. > If they ask for "foo", they get "foo". If they ask for > "foo;binary", they get "foo;binary". While RFC 2251 > did say "foo;binary" is to be treated as a subtype as > "foo", it also said clients MUST NOT expect > "foo;binary" when "foo" was requested. > I have explained above why the "MUST NOT expect" clause does not apply for Certificates. > The approach specified in -06 lets the MUST NOT trump > the "is to be treated as" statement. This leads to a > specification would addresses the ambiguity while not > break existing LDAPv3 compliant implementations. > > Kurt > If this -06 breaks the scenario I have described above, it should be changed in order to satisy existing ldapv3 compliant implementations. Chris. ------_=_NextPart_001_01C1BBB9.AB1616E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ;binary I think it is possible to build and deploy an ldapv3 = compliant system where the clients request certificates without = ";binary" and actually receive valid BER encoded certificates = from the server. Let me explain: First, look again at 6.5 of 2252. Because of the = particular wording that is used, it is possible to interpret the clause = as follows: as long as the encoding used is the binary encoding, either = the request or the response can use the ";binary" attribute = option but not necessarily both. This makes perfect sense. If the = client requests "userCertificate" then the server returns = "userCertificate;binary" and the condition is satisfied (the = client knows what they are getting). Now look at 4.1.5.1 of 2251. The statement is that = "... clients MUST NOT expect servers to return an attribute in = binary format if the client requested that attribute by name without = the binary option." Note that nothing prohibits the client from actually = performing the search without ;binary - it only says "don't expect = this to work". Similarly, nothing prohibits the server from = responding to a request where the search did not use = ";binary". Now, to deal with the "MUST NOT expect" = clause, there are two possibilities - first, because of the = interpretation of 6.5 shown above, the client actually can expect this = request to work, for the Certificate syntax, since the 6.5 clause = allows it (the expectation is provided by the 6.5 clause). The generic = "MUST NOT expect" statement then applies to other syntaxes = but not to the Certificate (and the other X.509 syntaxes). The second possibility is that the "MUST NOT = expect" clause directed to the clients can be easily dealt with. = All that is needed for an ldapv3 compliant client is to show that there = is reasonable error recovery procedures that have been implemented. = Since the RFC does not indicate what those error processing procedures = can be, almost anything can satisfy this statement. The MUST NOT expect = statement does not actually preclude this query from actually = working. I submit to you that this type of system can exist = and that the revisions of LDAPbis and PKIX must account for the given = ambiguity. I also suggest the perfect way to do this is to accept the = suggestions for the new PKIX I-D. More comments below. > At 06:50 PM 2002-02-21, Christopher Oliva = wrote: > >There is sufficient grounds to say that = servers should be > allowed to return binary encodings if a client = makes a > request without ";binary". > > The problem with this is that if a server is = allowed to > return ;binary when the client makes a request = without > ;binary then the servers might actually do = that. That > would be bad as client wouldn't get what they = asked for. > As I have shown above, the client would know what = they are getting since the server has replied with = ";binary". > The solution is simple, a client gets what they = ask for. > If they ask for "foo", they get = "foo". If they ask for > "foo;binary", they get = "foo;binary". While RFC 2251 > did say "foo;binary" is to be treated = as a subtype as > "foo", it also said clients MUST NOT = expect > "foo;binary" when "foo" was = requested. > I have explained above why the "MUST NOT = expect" clause does not apply for Certificates. > The approach specified in -06 lets the MUST NOT = trump > the "is to be treated as" = statement. This leads to a > specification would addresses the ambiguity = while not > break existing LDAPv3 compliant = implementations. > > Kurt > If this -06 breaks the scenario I have described = above, it should be changed in order to satisy existing ldapv3 = compliant implementations. Chris. ------_=_NextPart_001_01C1BBB9.AB1616E0-- From owner-ietf-ldapbis@OpenLDAP.org Sat Feb 23 12:56:37 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22384 for ; Sat, 23 Feb 2002 12:56:36 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1NHs1l73480; Sat, 23 Feb 2002 17:54:05 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Sat, 23 Feb 2002 17:54:01 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1NHrwU73473 for ; Sat, 23 Feb 2002 17:53:59 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1NHrtC59147; Sat, 23 Feb 2002 17:53:55 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020223083655.05d302e0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Feb 2002 09:54:02 -0800 To: Christopher Oliva From: "Kurt D. Zeilenga" Subject: RE: ;binary Cc: Christopher Oliva , Christopher Oliva , ietf-ldapbis@OpenLDAP.org, "David Chadwick SMTP (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 07:57 AM 2002-02-22, Christopher Oliva wrote: >I submit to you that this type of system can exist and that the revisions of LDAPbis and PKIX must account for the given ambiguity. The LDAPbis, which is responsible for the LDAP "core" specification, is addressing this ambiguity. The current approach addresses the ambiguity by removing a number of "possible" interpretations. >I also suggest the perfect way to do this is to accept the suggestions for the new PKIX I-D. Resolving this ambiguity is beyond the scope of the PKIX I-D. The ambiguity is not within the specification of certificate schema, but within the specification of LDAP attribute options and the ;binary transfer option. This needs to be addressed in the "core" specification. Once addressed in the "core" specification, extensions to the core should be made consistent with it. I suggest that those who advocate an approach different from that described in protocol-06 offer a specification of their approach for WG review. >If this -06 breaks the scenario I have described above, it should be changed in order to satisy existing ldapv3 compliant implementations. Sorry, but I believe that the TS is quite clear in stating: A compliant implementation must request userCertificate using ;binary. A compliant implementation must return userCertificate using ;binary. and quite clear in stating: A complaint implementation must not expect the return of userCertificate using ;binary unless it requested userCertificate using ;binary. The only ambiguity I see is with the RFC 2251 statement that an AttributeDescription with one or more options is treated as a subtype of the attribute type without any options. However, this is a general statement. More specific statements should be viewed as trumping it. In particular, RFC 2251 continues to describe binary option in a manner which doesn't treat an an attribute type with the binary option as a subtype of of the attribute type without the binary option. That is, "userCertificate;binary" and "userCertificate" don't refer to distinct attributes but return to the same attribute. The ;binary only affects transfer of that attribute. To avoid going in circles on this, I think we should agree to disagree. Kurt From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 24 15:34:07 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15837 for ; Sun, 24 Feb 2002 15:34:02 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1OKUCY17703; Sun, 24 Feb 2002 20:30:12 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Sun, 24 Feb 2002 20:30:12 +0000 Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1OKU9U17682; Sun, 24 Feb 2002 20:30:09 GMT Received: from fionn.es.net (localhost.es.net [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id MAA00632; Sun, 24 Feb 2002 12:30:09 -0800 (PST) Message-Id: <200202242030.MAA00632@fionn.es.net> X-Authentication-Warning: fionn.es.net: Host localhost.es.net [127.0.0.1] claimed to be fionn.es.net To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org cc: Lawrence Greenfield , IETF ldapext WG , "RL 'Bob' Morgan" Reply-to: helm@fionn.es.net Subject: Service name + host check [Re: Last Call: Discovering LDAP Services with DNS to Proposed Standard] In-reply-to: Your message of "Fri, 22 Feb 2002 19:35:00 PST." <5.1.0.14.0.20020222192011.017c0fc0@127.0.0.1> Date: Sun, 24 Feb 2002 12:30:08 -0800 From: Michael Helm Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: "Kurt D. Zeilenga" writes: > >"example.net" OR "ldap/example.net" > > How a client checks the certificate is defined in RFC 2830, not > state that RFC 2830 provides the normative specification > of the check algorithm, not this I-D). > > Service base certificate issue is NOT specific to LDAP > Defining a service-base certificate check mechanism, if > desired, should be drafted as an update to RFC 2830. (If there is further discussion on this ... perhaps we should continue it in ldapbis and not on the DNS SRV thread.) This would be a useful thing... we already have some deployment with this kind of naming (cn=ldap/foobar.lbl.gov). I assume this would mod draft-ietf-ldapbis-authmeth-xx? pkix gives me the impression of not liking subject names that don't fit naturally in the directory, don't represent a real object, and/or introduce some other hierarchical structure at a point intermediate in the tree. (cf the history of e=mike@foo.lbl.gov" in subject names). I think Microsoft has been putting kerberos principal names in subjectaltname ... I don't have one I can get at to check at the moment. So is this kind of naming viable? Michael Helm ESnet/LBL From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 24 18:16:53 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16829 for ; Sun, 24 Feb 2002 18:16:52 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1ONEik21317; Sun, 24 Feb 2002 23:14:44 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Sun, 24 Feb 2002 23:14:44 +0000 Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1ONEfU21310 for ; Sun, 24 Feb 2002 23:14:41 GMT Received: from [194.249.69.6] (helo=salford.ac.uk) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 16f7qm-0002ZT-00; Sun, 24 Feb 2002 23:14:36 +0000 Message-ID: <3C797493.22183239@salford.ac.uk> Date: Sun, 24 Feb 2002 23:17:39 +0000 From: David Chadwick Organization: University of Salford X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Sermersheim CC: ietf-ldapbis@OpenLDAP.org Subject: Re: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt References: Content-Type: multipart/mixed; boundary="------------0BA6CA1AEFFE247626007C83" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. --------------0BA6CA1AEFFE247626007C83 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim I think the new text for attribute descriptions is very good. Much better than before, especially the description of subtyping. However, the subsection on Binary Option (4.1.5.1) could still do with some improvement I feel. Firstly, the section is not as clear as recent email we have had on the list, explaining that the attribute value, whatever it is, is treated (or turned into) as an octet string containing BER, and then a TL octet wrapper is placed around it. Secondly, the section talks about overriding the native encoding and sending it as BER instead. But then your example uses certificates, that are native BER encoded. So what overriding is there to take place. It would seem like none, and therefore the effect of ;binary is null. In other words the section does not clearly indicate to me what the difference would be in transferring a certificate without ;binary and one with i.e. certificate;binary. This is unfortunate and confusing to the reader. I suggest you use an example that is not a certificate, but is a simple string. You might then also add text to say what the effect of ;binary is on a value that is already BER encoded. I find this sentence particular confusing "Instead the attribute is to be transferred as a binary value encoded using the Basic Encoding Rules [X.690]." The reason it is confusing is that all values in BER are binary. So if the value is already BER what more needs to be done to it? It would seem nothing. Perhaps the sentence might read better as "Instead the attribute value is transferred as an ASN.1 OctetStringType, where the embedded octet string value is itself a BER encoded value" The second sentence "The syntax of the binary value is an ASN.1 data type definition, which is referenced by the "SYNTAX" part of the attribute type definition." also has some errors in it, and could then be changed to "The syntax of the BER encoded value is an ASN.1 data type, which must conform to the "SYNTAX" part of the AttributeTypeDescription." Is that any better? David Jim Sermersheim wrote: > > All, > > This revision contains the changes recommended by the attribute options > engineering team. Please review section 4.1.5 carefully. > > Other changes are listed in section B.7 > > Jim > > >>> 01/31/02 05:00AM >>> > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the LDAP (v3) Revision Working Group of > the IETF. > > Title : Lightweight Directory Access Protocol (v3) > Author(s) : J. Sermersheim > Filename : draft-ietf-ldapbis-protocol-06.txt > Pages : 56 > Date : 30-Jan-02 > > The protocol described in this document is designed to provide access > to directories supporting the [X.500] models, while not incurring the > resource requirements of the X.500 Directory Access Protocol (DAP). > This protocol is specifically targeted at management applications and > browser applications that provide read/write interactive access to > directories. When used with a directory supporting the X.500 > protocols, it is intended to be a complement to the X.500 DAP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-06.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ldapbis-protocol-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ldapbis-protocol-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation > on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- ***************************************************************** 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 161 745 8169 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Understanding X.500: http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** --------------0BA6CA1AEFFE247626007C83 Content-Type: text/x-vcard; charset=us-ascii; name="d.w.chadwick.vcf" Content-Description: Card for David Chadwick Content-Disposition: attachment; filename="d.w.chadwick.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Chadwick;David tel;cell:+44 77 96 44 7184 tel;fax:+44 1484 532930 tel;home:+44 1484 352238 tel;work:+44 161 295 5351 x-mozilla-html:FALSE url:http://www.salford.ac.uk/its024/chadwick.htm org:University of Salford;IS Institute version:2.1 email;internet:d.w.chadwick@salford.ac.uk title:Professor of Information Security adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5 x-mozilla-cpt:;-4856 fn:David Chadwick end:vcard --------------0BA6CA1AEFFE247626007C83-- From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 24 18:50:09 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17210 for ; Sun, 24 Feb 2002 18:50:07 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1ONmHs21720; Sun, 24 Feb 2002 23:48:17 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Sun, 24 Feb 2002 23:48:17 +0000 Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1ONmAU21713 for ; Sun, 24 Feb 2002 23:48:11 GMT Received: (qmail 4951 invoked from network); 24 Feb 2002 23:34:33 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 24 Feb 2002 23:34:33 -0000 Reply-To: From: "Steven Legg" To: "'Christopher Oliva'" Cc: , "'David Chadwick SMTP (E-mail)'" Subject: RE: ;binary Date: Mon, 25 Feb 2002 10:46:43 +1100 Message-ID: <005901c1bd8d$842a07f0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Chris, Christopher Oliva wrote: > > The problem with this is that if a server is allowed to > > return ;binary when the client makes a request without > > ;binary then the servers might actually do that. That > > would be bad as client wouldn't get what they asked for. > > > As I have shown above, the client would know what they are getting > since the server has replied with ";binary". Unfortunately, client implementors often don't take into account all the potential responses they can get. They usually do enough to make their client work with their preferred LDAP server and leave it at that. So even if we explicitly specify that servers are allowed to return ";binary" without it being requested, there will still be people implementing clients that don't expect it. Apropos of the current discussion, I've found a good reason for NOT specifying that the native LDAP encoding for some syntax is the same as its ";binary" encoding. I've just submitted an I-D for an LDAP profile of X.500's Basic Access Control (it should appear in a few days) which uses the ACI Item syntax from RFC 2252. I've defined a human-readable native LDAP encoding for this syntax. However, I would have had a problem if the native LDAP encoding for this syntax had been previously defined to be the same as its ";binary" encoding. By not defining the native LDAP encoding to be the same as the ";binary" encoding for syntaxes that don't have a defined human-readable encoding, we leave open the possibility that we might define one in the future. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 24 19:38:24 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17809 for ; Sun, 24 Feb 2002 19:38:23 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P0a7Y22581; Mon, 25 Feb 2002 00:36:07 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 00:36:07 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1P0a5U22574 for ; Mon, 25 Feb 2002 00:36:05 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Mon, 25 Feb 2002 11:35:48 +1100 Message-ID: From: "Ramsay, Ron" To: steven.legg@adacel.com.au, "'Christopher Oliva'" Cc: ietf-ldapbis@OpenLDAP.org, "'David Chadwick SMTP (E-mail)'" Subject: RE: ;binary Date: Mon, 25 Feb 2002 11:35:47 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Steven, I think you have stepped over the edge with this proposal. After Kurt was so careful to explain that we must use the ASN.1 implied by the attribute OID with reference to the X.500 documents! What about aci;encoding=novel;. Would this be a subtype? Ron. -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Monday, 25 February 2002 10:47 To: 'Christopher Oliva' Cc: ietf-ldapbis@OpenLDAP.org; 'David Chadwick SMTP (E-mail)' Subject: RE: ;binary Chris, Christopher Oliva wrote: > > The problem with this is that if a server is allowed to > > return ;binary when the client makes a request without > > ;binary then the servers might actually do that. That > > would be bad as client wouldn't get what they asked for. > > > As I have shown above, the client would know what they are getting > since the server has replied with ";binary". Unfortunately, client implementors often don't take into account all the potential responses they can get. They usually do enough to make their client work with their preferred LDAP server and leave it at that. So even if we explicitly specify that servers are allowed to return ";binary" without it being requested, there will still be people implementing clients that don't expect it. Apropos of the current discussion, I've found a good reason for NOT specifying that the native LDAP encoding for some syntax is the same as its ";binary" encoding. I've just submitted an I-D for an LDAP profile of X.500's Basic Access Control (it should appear in a few days) which uses the ACI Item syntax from RFC 2252. I've defined a human-readable native LDAP encoding for this syntax. However, I would have had a problem if the native LDAP encoding for this syntax had been previously defined to be the same as its ";binary" encoding. By not defining the native LDAP encoding to be the same as the ";binary" encoding for syntaxes that don't have a defined human-readable encoding, we leave open the possibility that we might define one in the future. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 24 19:48:35 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17897 for ; Sun, 24 Feb 2002 19:48:34 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P0kek22741; Mon, 25 Feb 2002 00:46:40 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 00:46:40 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1P0kbU22734 for ; Mon, 25 Feb 2002 00:46:37 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Mon, 25 Feb 2002 11:46:25 +1100 Message-ID: From: "Ramsay, Ron" To: David Chadwick , Jim Sermersheim Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt Date: Mon, 25 Feb 2002 11:46:25 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: David, This looks like a good idea. I think the references to octet strings, though, may imply an additional tag, particularly when you refer to the OctetStringType. In view of Steven's recent mail, this may be an opportune time to nail this down. I am a bit concerned about syntax of the binary value is an ASN.1 data type definition, which is referenced by the "SYNTAX" part of the attribute type definition." The SYNTAX part refers only to an OID which has not been defined. The only reference to an ASN.1 structure would have to be the OID of the attribute type itself, which can be looked up in X.520. I doubt you would find any reference to 1.3.6.1.4.1.1466.115.121.1.6 (for example) in any X.500 document. Or do you think RFC 2252 should include ASN.1 definitions against the syntax OIDs? Thus, I don't see your suggestion as an improvement. Ron. -----Original Message----- From: David Chadwick [mailto:d.w.chadwick@salford.ac.uk] Sent: Monday, 25 February 2002 10:18 To: Jim Sermersheim Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt Jim I think the new text for attribute descriptions is very good. Much better than before, especially the description of subtyping. However, the subsection on Binary Option (4.1.5.1) could still do with some improvement I feel. Firstly, the section is not as clear as recent email we have had on the list, explaining that the attribute value, whatever it is, is treated (or turned into) as an octet string containing BER, and then a TL octet wrapper is placed around it. Secondly, the section talks about overriding the native encoding and sending it as BER instead. But then your example uses certificates, that are native BER encoded. So what overriding is there to take place. It would seem like none, and therefore the effect of ;binary is null. In other words the section does not clearly indicate to me what the difference would be in transferring a certificate without ;binary and one with i.e. certificate;binary. This is unfortunate and confusing to the reader. I suggest you use an example that is not a certificate, but is a simple string. You might then also add text to say what the effect of ;binary is on a value that is already BER encoded. I find this sentence particular confusing "Instead the attribute is to be transferred as a binary value encoded using the Basic Encoding Rules [X.690]." The reason it is confusing is that all values in BER are binary. So if the value is already BER what more needs to be done to it? It would seem nothing. Perhaps the sentence might read better as "Instead the attribute value is transferred as an ASN.1 OctetStringType, where the embedded octet string value is itself a BER encoded value" The second sentence "The syntax of the binary value is an ASN.1 data type definition, which is referenced by the "SYNTAX" part of the attribute type definition." also has some errors in it, and could then be changed to "The syntax of the BER encoded value is an ASN.1 data type, which must conform to the "SYNTAX" part of the AttributeTypeDescription." Is that any better? David Jim Sermersheim wrote: > > All, > > This revision contains the changes recommended by the attribute options > engineering team. Please review section 4.1.5 carefully. > > Other changes are listed in section B.7 > > Jim > > >>> 01/31/02 05:00AM >>> > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the LDAP (v3) Revision Working Group of > the IETF. > > Title : Lightweight Directory Access Protocol (v3) > Author(s) : J. Sermersheim > Filename : draft-ietf-ldapbis-protocol-06.txt > Pages : 56 > Date : 30-Jan-02 > > The protocol described in this document is designed to provide access > to directories supporting the [X.500] models, while not incurring the > resource requirements of the X.500 Directory Access Protocol (DAP). > This protocol is specifically targeted at management applications and > browser applications that provide read/write interactive access to > directories. When used with a directory supporting the X.500 > protocols, it is intended to be a complement to the X.500 DAP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-06.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ldapbis-protocol-06.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ldapbis-protocol-06.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation > on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- ***************************************************************** 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 161 745 8169 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Understanding X.500: http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 24 20:26:16 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18169 for ; Sun, 24 Feb 2002 20:26:15 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P1OM123356; Mon, 25 Feb 2002 01:24:22 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 01:24:22 +0000 Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P1OJU23348 for ; Mon, 25 Feb 2002 01:24:19 GMT Received: (qmail 13246 invoked from network); 25 Feb 2002 01:10:42 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 25 Feb 2002 01:10:42 -0000 Reply-To: From: "Steven Legg" To: "'David Chadwick'" Cc: Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt Date: Mon, 25 Feb 2002 12:22:52 +1100 Message-ID: <005b01c1bd9a$f2b95510$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <3C797493.22183239@salford.ac.uk> Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit David, David Chadwick wrote: > I think the new text for attribute descriptions is very good. Much > better than before, especially the description of subtyping. However, > the subsection on Binary Option (4.1.5.1) could still do with some > improvement I feel. Firstly, the section is not as clear as > recent email > we have had on the list, explaining that the attribute value, whatever > it is, is treated (or turned into) as an octet string containing BER, > and then a TL octet wrapper is placed around it. This is not the interpretation Kurt and I have been describing. An AttributeValue in LDAP is an OCTET STRING. The contents octets of this OCTET STRING are either a series of UTF8 encoded characters (being a human-readable native LDAP encoding), a series of arbitrary octets (being the native LDAP encoding for, e.g., the Octet String syntax - 1.3.6.1.4.1.1466.115.121.1.40) or a BER encoded value (comforming to the ASN.1 type corresponding to the LDAP syntax). There is no extra OCTET STRING wrapper around the BER encoding. By way of example, the contents octets of AttributeValue for the value "foo" returned as a value of cn would be (in hexadecimal): 66 6F 6F . Returned as a value of cn;binary it would be: 13 03 66 6F 6F, the BER for a value of the printableString alternative from the DirectoryString{} CHOICE. No OCTET STRING tags to be seen. > > Secondly, the section talks about overriding the native encoding and > sending it as BER instead. But then your example uses > certificates, that > are native BER encoded. The Certificate syntax does not have a native encoding in LDAPv3. > So what overriding is there to take place. It > would seem like none, and therefore the effect of ;binary is null. "Overriding" is perhaps the wrong way to describe it, since for some syntaxes there is no native LDAP encoding to override. I prefer to think of binary as an *alternative* way of encoding a value. For some syntaxes, like Certificate, there is no choice because there is only one alternative defined. > In > other words the section does not clearly indicate to me what the > difference would be in transferring a certificate without ;binary and > one with i.e. certificate;binary. The difference is that "certificate" without ";binary" is illegal. The native LDAP encoding is, at present, undefined. > This is unfortunate and > confusing to > the reader. I suggest you use an example that is not a > certificate, but > is a simple string. You might then also add text to say what > the effect > of ;binary is on a value that is already BER encoded. > > I find this sentence particular confusing > > "Instead the attribute is to be transferred as > a binary value encoded using the Basic Encoding Rules [X.690]." > > The reason it is confusing is that all values in BER are binary. So if > the value is already BER what more needs to be done to it? It > would seem > nothing. RFC 2252 allows a server to store a value in any format it likes. If a value is stored as BER then it can be returned in ";binary" form without conversion. If stored in the native LDAP encoding then to be returned in ";binary" form it must first be re-encoded (as BER). The converse applies if the value is requested in native LDAP form. > > Perhaps the sentence might read better as > > "Instead the attribute value is transferred as an ASN.1 > OctetStringType, > where the embedded octet string value is itself a BER encoded value" No, this suggests an extra OCTET STRING wrapper. > > > The second sentence > "The > syntax of the binary value is an ASN.1 data type > definition, which is > referenced by the "SYNTAX" part of the attribute type definition." > > also has some errors in it, and could then be changed to > > "The syntax of the BER encoded value is an ASN.1 data type, which > must conform to the "SYNTAX" part of the AttributeTypeDescription." > > Is that any better? I would prefer: "The value is BER encoded according to the ASN.1 data type corresponding to the attribute's LDAP syntax. The LDAP syntax is indicated by the "SYNTAX" part of the AttributeTypeDescription." ... with corresponding ASN.1 types nominated for each syntax in RFC 2252bis. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 24 20:43:55 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18432 for ; Sun, 24 Feb 2002 20:43:55 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P1for23861; Mon, 25 Feb 2002 01:41:51 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 01:41:50 +0000 Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P1fmU23854 for ; Mon, 25 Feb 2002 01:41:48 GMT Received: (qmail 14508 invoked from network); 25 Feb 2002 01:28:16 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 25 Feb 2002 01:28:16 -0000 Reply-To: From: "Steven Legg" To: "'Ramsay, Ron'" , "'Christopher Oliva'" Cc: , "'David Chadwick SMTP (E-mail)'" Subject: RE: ;binary Date: Mon, 25 Feb 2002 12:40:27 +1100 Message-ID: <005c01c1bd9d$674cdc10$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ron, Ramsay, Ron wrote: > I think you have stepped over the edge with this proposal. > After Kurt was so > careful to explain that we must use the ASN.1 implied by the > attribute OID > with reference to the X.500 documents! I said nothing that changes the interpretation of ";binary". My statements are completely consistent with Kurt's explanation. I was pointing out a reason for leaving the native LDAP encoding as undefined, rather than specifying it to be the same as the ";binary" encoding. > > What about aci;encoding=novel;. Would this be a subtype? The LDAPbis working group has already reached consensus that there are at least two categories of attribute options: subtyping options and transfer encoding options. "aci;encoding=novel" would be considered a subtype if and only if "encoding=novel" were defined to be a subtyping option. BTW, '=' is not a legal character for an attribute option. Regards, Steven > > Ron. > > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Monday, 25 February 2002 10:47 > To: 'Christopher Oliva' > Cc: ietf-ldapbis@OpenLDAP.org; 'David Chadwick SMTP (E-mail)' > Subject: RE: ;binary > > > > Chris, > > Christopher Oliva wrote: > > > The problem with this is that if a server is allowed to > > > return ;binary when the client makes a request without > > > ;binary then the servers might actually do that. That > > > would be bad as client wouldn't get what they asked for. > > > > > As I have shown above, the client would know what they are getting > > since the server has replied with ";binary". > > Unfortunately, client implementors often don't take into account all > the potential responses they can get. They usually do enough to make > their client work with their preferred LDAP server and leave it at > that. So even if we explicitly specify that servers are > allowed to return > ";binary" without it being requested, there will still be people > implementing clients that don't expect it. > > > Apropos of the current discussion, I've found a good reason for NOT > specifying that the native LDAP encoding for some syntax is the > same as its ";binary" encoding. I've just submitted an I-D for > an LDAP profile of X.500's Basic Access Control (it should appear in > a few days) which uses the ACI Item syntax from RFC 2252. I've defined > a human-readable native LDAP encoding for this syntax. However, I > would have had a problem if the native LDAP encoding for this syntax > had been previously defined to be the same as its ";binary" encoding. > > By not defining the native LDAP encoding to be the same as > the ";binary" > encoding for syntaxes that don't have a defined > human-readable encoding, > we leave open the possibility that we might define one in the future. > > > Regards, > Steven > From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 24 21:02:07 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18654 for ; Sun, 24 Feb 2002 21:02:07 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P204524280; Mon, 25 Feb 2002 02:00:04 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 02:00:04 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1P1xxU24236 for ; Mon, 25 Feb 2002 02:00:00 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Mon, 25 Feb 2002 12:59:44 +1100 Message-ID: From: "Ramsay, Ron" To: steven.legg@adacel.com.au, "'David Chadwick'" Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt Date: Mon, 25 Feb 2002 12:59:44 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Steven, I've got to resist this notion of the undefined native LDAP encoding. There are only two encodings for an LDAP value (and I think Kurt was saying this also): o The ASN.1 value inherited from the X.500 definition o Possibly a string definition defined in RFC 2252 (possibly referencing other documents - 2253, 1778?) If you request an attribute with ;binary, you get the first one. If you request a value which has a string encoding, you get the second one. If it doesn't have a string encoding, it is probably one of the certificate types and the "fix" is to request it with ;binary. The types audio and jpegPhoto are anomalous (if they are their own string encoding (but then, what is a string?), they have no ASN.1 definition, so what effect does ;binary have?). so, the certificate syntax has a native encoding but not a string encoding. I think it would be fair enough, in the future, to request it without ;binary as any LDAP implementor should realise it is binary. There have been no complaints about audio or jpegPhoto. ;binary was simply a BAD idea. Ron. -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Monday, 25 February 2002 12:23 To: 'David Chadwick' Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt David, David Chadwick wrote: > I think the new text for attribute descriptions is very good. Much > better than before, especially the description of subtyping. However, > the subsection on Binary Option (4.1.5.1) could still do with some > improvement I feel. Firstly, the section is not as clear as > recent email > we have had on the list, explaining that the attribute value, whatever > it is, is treated (or turned into) as an octet string containing BER, > and then a TL octet wrapper is placed around it. This is not the interpretation Kurt and I have been describing. An AttributeValue in LDAP is an OCTET STRING. The contents octets of this OCTET STRING are either a series of UTF8 encoded characters (being a human-readable native LDAP encoding), a series of arbitrary octets (being the native LDAP encoding for, e.g., the Octet String syntax - 1.3.6.1.4.1.1466.115.121.1.40) or a BER encoded value (comforming to the ASN.1 type corresponding to the LDAP syntax). There is no extra OCTET STRING wrapper around the BER encoding. By way of example, the contents octets of AttributeValue for the value "foo" returned as a value of cn would be (in hexadecimal): 66 6F 6F . Returned as a value of cn;binary it would be: 13 03 66 6F 6F, the BER for a value of the printableString alternative from the DirectoryString{} CHOICE. No OCTET STRING tags to be seen. > > Secondly, the section talks about overriding the native encoding and > sending it as BER instead. But then your example uses > certificates, that > are native BER encoded. The Certificate syntax does not have a native encoding in LDAPv3. > So what overriding is there to take place. It > would seem like none, and therefore the effect of ;binary is null. "Overriding" is perhaps the wrong way to describe it, since for some syntaxes there is no native LDAP encoding to override. I prefer to think of binary as an *alternative* way of encoding a value. For some syntaxes, like Certificate, there is no choice because there is only one alternative defined. > In > other words the section does not clearly indicate to me what the > difference would be in transferring a certificate without ;binary and > one with i.e. certificate;binary. The difference is that "certificate" without ";binary" is illegal. The native LDAP encoding is, at present, undefined. > This is unfortunate and > confusing to > the reader. I suggest you use an example that is not a > certificate, but > is a simple string. You might then also add text to say what > the effect > of ;binary is on a value that is already BER encoded. > > I find this sentence particular confusing > > "Instead the attribute is to be transferred as > a binary value encoded using the Basic Encoding Rules [X.690]." > > The reason it is confusing is that all values in BER are binary. So if > the value is already BER what more needs to be done to it? It > would seem > nothing. RFC 2252 allows a server to store a value in any format it likes. If a value is stored as BER then it can be returned in ";binary" form without conversion. If stored in the native LDAP encoding then to be returned in ";binary" form it must first be re-encoded (as BER). The converse applies if the value is requested in native LDAP form. > > Perhaps the sentence might read better as > > "Instead the attribute value is transferred as an ASN.1 > OctetStringType, > where the embedded octet string value is itself a BER encoded value" No, this suggests an extra OCTET STRING wrapper. > > > The second sentence > "The > syntax of the binary value is an ASN.1 data type > definition, which is > referenced by the "SYNTAX" part of the attribute type definition." > > also has some errors in it, and could then be changed to > > "The syntax of the BER encoded value is an ASN.1 data type, which > must conform to the "SYNTAX" part of the AttributeTypeDescription." > > Is that any better? I would prefer: "The value is BER encoded according to the ASN.1 data type corresponding to the attribute's LDAP syntax. The LDAP syntax is indicated by the "SYNTAX" part of the AttributeTypeDescription." ... with corresponding ASN.1 types nominated for each syntax in RFC 2252bis. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 24 22:47:53 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21435 for ; Sun, 24 Feb 2002 22:47:53 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P3jpf26088; Mon, 25 Feb 2002 03:45:51 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 03:45:51 +0000 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1P3jnU26081 for ; Mon, 25 Feb 2002 03:45:49 GMT Received: from user-2ivf861.dialup.mindspring.com ([165.247.160.193] helo=asn-1.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 16fC5D-00007I-00 for ietf-ldapbis@OpenLDAP.org; Sun, 24 Feb 2002 22:45:47 -0500 Message-ID: <3C79B2A0.6FB3EC90@asn-1.com> Date: Sun, 24 Feb 2002 22:42:24 -0500 From: Phil Griffin Organization: Griffin Consulting - http://ASN-1.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: Re: ;binary References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The possibility of defining a human-readable format for binary ASN.1 values in the future is here, right now. Done already - or at least very near final approval. It's called the 2002 edition of ISO/IEC 8824-1 | ITU-T Recommendation X.680, and it defines an XML markup representation for every value of every ASN.1 type. Interestingly, it defines a dotted format, borrowed from LDAP, for values of type OBJECT IDENTIFIER. And there's XML Encoding Rules (XER), defined in ISO/IEC 8825-3 | ITU-T Recommendation X.693. These encodings carry the exact same abstract values as defined in the ASN.1 standards, but in a human- readable textual format. Having XER allows you to easily switch back and forth between binary and textual representations of the exact same values. Phil "Ramsay, Ron" wrote: > > Steven, > > I think you have stepped over the edge with this proposal. After Kurt was so > careful to explain that we must use the ASN.1 implied by the attribute OID > with reference to the X.500 documents! > > What about aci;encoding=novel;. Would this be a subtype? > > Ron. > > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Monday, 25 February 2002 10:47 > To: 'Christopher Oliva' > Cc: ietf-ldapbis@OpenLDAP.org; 'David Chadwick SMTP (E-mail)' > Subject: RE: ;binary > > Chris, > > Christopher Oliva wrote: > > > The problem with this is that if a server is allowed to > > > return ;binary when the client makes a request without > > > ;binary then the servers might actually do that. That > > > would be bad as client wouldn't get what they asked for. > > > > > As I have shown above, the client would know what they are getting > > since the server has replied with ";binary". > > Unfortunately, client implementors often don't take into account all > the potential responses they can get. They usually do enough to make > their client work with their preferred LDAP server and leave it at > that. So even if we explicitly specify that servers are allowed to return > ";binary" without it being requested, there will still be people > implementing clients that don't expect it. > > Apropos of the current discussion, I've found a good reason for NOT > specifying that the native LDAP encoding for some syntax is the > same as its ";binary" encoding. I've just submitted an I-D for > an LDAP profile of X.500's Basic Access Control (it should appear in > a few days) which uses the ACI Item syntax from RFC 2252. I've defined > c for this syntax. However, I > would have had a problem if the native LDAP encoding for this syntax > had been previously defined to be the same as its ";binary" encoding. > > By not defining the native LDAP encoding to be the same as the ";binary" > encoding for syntaxes that don't have a defined human-readable encoding, > we leave open the possibility that we might define one in the future. > > Regards, > Steven From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 24 23:03:14 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21555 for ; Sun, 24 Feb 2002 23:03:13 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P418F26442; Mon, 25 Feb 2002 04:01:08 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 04:01:08 +0000 Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P40wU26432 for ; Mon, 25 Feb 2002 04:00:59 GMT Received: (qmail 25838 invoked from network); 25 Feb 2002 03:47:22 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 25 Feb 2002 03:47:22 -0000 Reply-To: From: "Steven Legg" To: "'Ramsay, Ron'" Cc: Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt Date: Mon, 25 Feb 2002 14:59:33 +1100 Message-ID: <005d01c1bdb0$d63277d0$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ron, Ramsay, Ron wrote: > I've got to resist this notion of the undefined native LDAP encoding. I originally introduced the term "native LDAP encoding" as a replacement for "string encoding" because of the confusion "string" causes. It means the encoding of values one gets when requesting an attribute without specifying an explicit transfer option (like ";binary"). The native encoding may or may not be a human-readable character string. > > There are only two encodings for an LDAP value (and I think > Kurt was saying > this also): Yes, the native encoding and the binary encoding. It would be more correct to say that the LDAP core specification defines only two transfer encodings. Others may be defined in the future. > > o The ASN.1 value inherited from the X.500 definition The binary encoding. > o Possibly a string definition defined in RFC 2252 (possibly > referencing > other documents - 2253, 1778?) ... which RFC2251bis refers to as the "native encoding". > > If you request an attribute with ;binary, you get the first > one. If you > request a value which has a string encoding, you get the > second one. If it > doesn't have a string encoding, it is probably one of the > certificate types > and the "fix" is to request it with ;binary. Saying it doesn't have a string encoding is the same as saying it doesn't have a native LDAP encoding (unless by "string" you mean a human-readable representation). > The types audio > and jpegPhoto > are anomalous (if they are their own string encoding (but > then, what is a > string?), they have no ASN.1 definition, so what effect does > ;binary have?). They do have corresponding ASN.1 definitions, but they're hard to find since the attributes that use them aren't X.500 standard ones. I eventually tracked down the ASN.1 definitions by inspecting the Quipu source code. It turns out both syntaxes are treated as OCTET STRING for X.500 purposes. The effect of ";binary" on these syntaxes is the same as the effect on the LDAP Octet String syntax. > so, the certificate syntax has a native encoding but not a > string encoding. It would appear that you are using "string" to mean human-readable character string. The Certificate syntax certainly doesn't have a human-readable character string encoding. However, since LDAPv3 doesn't specify what you get if you ask for userCertificate without ";binary", the native encoding is undefined (or if you prefer, the Certificate syntax doesn't have a native encoding). > > I think it would be fair enough, in the future, to request it without > ;binary as any LDAP implementor should realise it is binary. It wouldn't be fair enough if in future a human-readable character string encoding is defined, which is what I've done with the ACI Item syntax. Regards, Steven > There have been > no complaints about audio or jpegPhoto. ;binary was simply a BAD idea. > > Ron. > > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Monday, 25 February 2002 12:23 > To: 'David Chadwick' > Cc: ietf-ldapbis@OpenLDAP.org > Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt > > > > > David, > > David Chadwick wrote: > > I think the new text for attribute descriptions is very good. Much > > better than before, especially the description of > subtyping. However, > > the subsection on Binary Option (4.1.5.1) could still do with some > > improvement I feel. Firstly, the section is not as clear as > > recent email > > we have had on the list, explaining that the attribute > value, whatever > > it is, is treated (or turned into) as an octet string > containing BER, > > and then a TL octet wrapper is placed around it. > > This is not the interpretation Kurt and I have been describing. An > AttributeValue in LDAP is an OCTET STRING. The contents octets of this > OCTET STRING are either a series of UTF8 encoded characters (being a > human-readable native LDAP encoding), a series of arbitrary octets > (being the native LDAP encoding for, e.g., the Octet String syntax - > 1.3.6.1.4.1.1466.115.121.1.40) or a BER encoded value (comforming to > the ASN.1 type corresponding to the LDAP syntax). > There is no extra OCTET STRING wrapper around the BER encoding. > > By way of example, the contents octets of AttributeValue for the value > "foo" returned as a value of cn would be (in hexadecimal): 66 6F 6F . > > Returned as a value of cn;binary it would be: 13 03 66 6F 6F, > the BER for a value of the printableString alternative from the > DirectoryString{} CHOICE. No OCTET STRING tags to be seen. > > > > > Secondly, the section talks about overriding the native encoding and > > sending it as BER instead. But then your example uses > > certificates, that > > are native BER encoded. > > The Certificate syntax does not have a native encoding in LDAPv3. > > > So what overriding is there to take place. It > > would seem like none, and therefore the effect of ;binary is null. > > "Overriding" is perhaps the wrong way to describe it, since for some > syntaxes there is no native LDAP encoding to override. I > prefer to think > of binary as an *alternative* way of encoding a value. For > some syntaxes, > like Certificate, there is no choice because there is only > one alternative > defined. > > > In > > other words the section does not clearly indicate to me what the > > difference would be in transferring a certificate without > ;binary and > > one with i.e. certificate;binary. > > The difference is that "certificate" without ";binary" is illegal. > The native LDAP encoding is, at present, undefined. > > > This is unfortunate and > > confusing to > > the reader. I suggest you use an example that is not a > > certificate, but > > is a simple string. You might then also add text to say what > > the effect > > of ;binary is on a value that is already BER encoded. > > > > I find this sentence particular confusing > > > > "Instead the attribute is to be transferred as > > a binary value encoded using the Basic Encoding Rules [X.690]." > > > > The reason it is confusing is that all values in BER are > binary. So if > > the value is already BER what more needs to be done to it? It > > would seem > > nothing. > > RFC 2252 allows a server to store a value in any format it likes. > If a value is stored as BER then it can be returned in ";binary" > form without conversion. If stored in the native LDAP encoding > then to be returned in ";binary" form it must first be re-encoded > (as BER). The converse applies if the value is requested in native > LDAP form. > > > > > Perhaps the sentence might read better as > > > > "Instead the attribute value is transferred as an ASN.1 > > OctetStringType, > > where the embedded octet string value is itself a BER encoded value" > > No, this suggests an extra OCTET STRING wrapper. > > > > > > > The second sentence > > "The > > syntax of the binary value is an ASN.1 data type > > definition, which is > > referenced by the "SYNTAX" part of the attribute type > definition." > > > > also has some errors in it, and could then be changed to > > > > "The syntax of the BER encoded value is an ASN.1 data type, which > > must conform to the "SYNTAX" part of the AttributeTypeDescription." > > > > Is that any better? > > I would prefer: > > "The value is BER encoded according to the ASN.1 data type > corresponding to the attribute's LDAP syntax. The LDAP syntax is > indicated by the "SYNTAX" part of the AttributeTypeDescription." > > ... with corresponding ASN.1 types nominated for each syntax > in RFC 2252bis. > > Regards, > Steven > From owner-ietf-ldapbis@OpenLDAP.org Sun Feb 24 23:31:26 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22015 for ; Sun, 24 Feb 2002 23:31:26 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P4TYG26800; Mon, 25 Feb 2002 04:29:34 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 04:29:34 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1P4TWU26793 for ; Mon, 25 Feb 2002 04:29:32 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Mon, 25 Feb 2002 15:29:19 +1100 Message-ID: From: "Ramsay, Ron" To: Phil Griffin , ietf-ldapbis@OpenLDAP.org Subject: RE: ;binary Date: Mon, 25 Feb 2002 15:29:18 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Phil, I would think that this wouldn't encode an address as "1 First Avanue, Downtown" (human readable) or "1 FirstAvanue$Downtown" (LDAP) but as 1 First AvanueDowntown ? Ron. -----Original Message----- From: Phil Griffin [mailto:phil.griffin@asn-1.com] Sent: Monday, 25 February 2002 14:42 To: ietf-ldapbis@OpenLDAP.org Subject: Re: ;binary The possibility of defining a human-readable format for binary ASN.1 values in the future is here, right now. Done already - or at least very near final approval. It's called the 2002 edition of ISO/IEC 8824-1 | ITU-T Recommendation X.680, and it defines an XML markup representation for every value of every ASN.1 type. Interestingly, it defines a dotted format, borrowed from LDAP, for values of type OBJECT IDENTIFIER. And there's XML Encoding Rules (XER), defined in ISO/IEC 8825-3 | ITU-T Recommendation X.693. These encodings carry the exact same abstract values as defined in the ASN.1 standards, but in a human- readable textual format. Having XER allows you to easily switch back and forth between binary and textual representations of the exact same values. Phil "Ramsay, Ron" wrote: > > Steven, > > I think you have stepped over the edge with this proposal. After Kurt was so > careful to explain that we must use the ASN.1 implied by the attribute OID > with reference to the X.500 documents! > > What about aci;encoding=novel;. Would this be a subtype? > > Ron. > > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Monday, 25 February 2002 10:47 > To: 'Christopher Oliva' > Cc: ietf-ldapbis@OpenLDAP.org; 'David Chadwick SMTP (E-mail)' > Subject: RE: ;binary > > Chris, > > Christopher Oliva wrote: > > > The problem with this is that if a server is allowed to > > > return ;binary when the client makes a request without > > > ;binary then the servers might actually do that. That > > > would be bad as client wouldn't get what they asked for. > > > > > As I have shown above, the client would know what they are getting > > since the server has replied with ";binary". > > Unfortunately, client implementors often don't take into account all > the potential responses they can get. They usually do enough to make > their client work with their preferred LDAP server and leave it at > that. So even if we explicitly specify that servers are allowed to return > ";binary" without it being requested, there will still be people > implementing clients that don't expect it. > > Apropos of the current discussion, I've found a good reason for NOT > specifying that the native LDAP encoding for some syntax is the > same as its ";binary" encoding. I've just submitted an I-D for > an LDAP profile of X.500's Basic Access Control (it should appear in > a few days) which uses the ACI Item syntax from RFC 2252. I've defined > c for this syntax. However, I > would have had a problem if the native LDAP encoding for this syntax > had been previously defined to be the same as its ";binary" encoding. > > By not defining the native LDAP encoding to be the same as the ";binary" > encoding for syntaxes that don't have a defined human-readable encoding, > we leave open the possibility that we might define one in the future. > > Regards, > Steven From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 01:02:01 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22935 for ; Mon, 25 Feb 2002 01:02:00 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P601l32208; Mon, 25 Feb 2002 06:00:01 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 06:00:00 +0000 Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1P5xwU32191 for ; Mon, 25 Feb 2002 05:59:58 GMT Received: from user-2ivf8ii.dialup.mindspring.com ([165.247.162.82] helo=asn-1.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 16fEB2-0005GX-00 for ietf-ldapbis@OpenLDAP.org; Mon, 25 Feb 2002 00:59:56 -0500 Message-ID: <3C79D20C.FE8CF7B5@asn-1.com> Date: Mon, 25 Feb 2002 00:56:28 -0500 From: Phil Griffin Organization: Griffin Consulting - http://ASN-1.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: Re: ;binary References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ron, You can likely achieve the LDAP string encoding and the other representation that you show below by style sheet processing of an XER encoding. Many such textual representations are possible. But you are correct, for the ASN.1 XML Encoding Rules the encoding will be XML 1.0 markup. And this markup is human-readable, though not as readable as plain text. But it can be easily transformed into other textual formats in a standard way, using readily available tools. And this XML markup representation does exist for each and every ASN.1 value, regardless of whether or not an alternative LDAP defined encoding exists. For example, there is an XER representation of ASN.1 type Certificate that is human-readable. This representation will be defined in the X9.96 XML Cryptographic Message Syntax NWI just approved last week by X9. It carries X.509 certificates in one of the saddle bags of type SignedData. In X9.96, the messages defined in X9.73 CMS (the ANSI X9 version of IETF S/MIME and RSA PKCS #7) will be specified using the ASN.1 from that standard, in a canonical XML variant of XER (CXER), so that the resulting XML messages can be cryptographically enhanced. I spoke on this subject at the RSA conference last week (http://ASN-1.com/cxer.zip). Phil "Ramsay, Ron" wrote: > > Phil, > > I would think that this wouldn't encode an address as "1 First Avanue, > Downtown" (human readable) or "1 FirstAvanue$Downtown" (LDAP) but as > > 1 First > AvanueDowntown > > ? > > Ron. > > -----Original Message----- > From: Phil Griffin [mailto:phil.griffin@asn-1.com] > Sent: Monday, 25 February 2002 14:42 > To: ietf-ldapbis@OpenLDAP.org > Subject: Re: ;binary > > The possibility of defining a human-readable > format for binary ASN.1 values in the future > is here, right now. Done already - or at least > very near final approval. > > It's called the 2002 edition of ISO/IEC 8824-1 | > ITU-T Recommendation X.680, and it defines an XML > markup representation for every value of every ASN.1 > type. Interestingly, it defines a dotted format, > borrowed from LDAP, for values of type OBJECT > IDENTIFIER. > > And there's XML Encoding Rules (XER), defined in > ISO/IEC 8825-3 | ITU-T Recommendation X.693. These > encodings carry the exact same abstract values as > defined in the ASN.1 standards, but in a human- > readable textual format. > > Having XER allows you to easily switch back and > forth between binary and textual representations > of the exact same values. > > Phil > > "Ramsay, Ron" wrote: > > > > Steven, > > > > I think you have stepped over the edge with this proposal. After Kurt was > so > > careful to explain that we must use the ASN.1 implied by the attribute OID > > with reference to the X.500 documents! > > > > What about aci;encoding=novel;. Would this be a subtype? > > > > Ron. > > > > -----Original Message----- > > From: Steven Legg [mailto:steven.legg@adacel.com.au] > > Sent: Monday, 25 February 2002 10:47 > > To: 'Christopher Oliva' > > Cc: ietf-ldapbis@OpenLDAP.org; 'David Chadwick SMTP (E-mail)' > > Subject: RE: ;binary > > > > Chris, > > > > Christopher Oliva wrote: > > > > The problem with this is that if a server is allowed to > > > > return ;binary when the client makes a request without > > > > ;binary then the servers might actually do that. That > > > > would be bad as client wouldn't get what they asked for. > > > > > > > As I have shown above, the client would know what they are getting > > > since the server has replied with ";binary". > > > > Unfortunately, client implementors often don't take into account all > > the potential responses they can get. They usually do enough to make > > their client work with their preferred LDAP server and leave it at > > that. So even if we explicitly specify that servers are allowed to return > > ";binary" without it being requested, there will still be people > > implementing clients that don't expect it. > > > > Apropos of the current discussion, I've found a good reason for NOT > > specifying that the native LDAP encoding for some syntax is the > > same as its ";binary" encoding. I've just submitted an I-D for > > an LDAP profile of X.500's Basic Access Control (it should appear in > > a few days) which uses the ACI Item syntax from RFC 2252. I've defined > > c for this syntax. However, I > > would have had a problem if the native LDAP encoding for this syntax > > had been previously defined to be the same as its ";binary" encoding. > > > > By not defining the native LDAP encoding to be the same as the ";binary" > > encoding for syntaxes that don't have a defined human-readable encoding, > > we leave open the possibility that we might define one in the future. > > > > Regards, > > Steven From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 01:42:20 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23295 for ; Mon, 25 Feb 2002 01:42:19 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P6eJv34145; Mon, 25 Feb 2002 06:40:19 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 06:40:19 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1P6eHU34138 for ; Mon, 25 Feb 2002 06:40:17 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Mon, 25 Feb 2002 17:39:57 +1100 Message-ID: From: "Ramsay, Ron" To: Phil Griffin , ietf-ldapbis@OpenLDAP.org Subject: RE: ;binary Date: Mon, 25 Feb 2002 17:39:56 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Thanks, Phil. You raise two implicit matters. The first relates to style sheets and LDAP browsers. Style sheets are not a part of LDAP and, though many clients may be HTML aware, the dependency needs to be pointed out. The second relates to your representation of certificates in XML. Are you saying that CXER can be uniquely mapped to DER? I assume you preserve the original signature (over the DER), otherwise you would be defining an XML certificate? Ron. -----Original Message----- From: Phil Griffin [mailto:phil.griffin@asn-1.com] Sent: Monday, 25 February 2002 16:56 To: ietf-ldapbis@OpenLDAP.org Subject: Re: ;binary Ron, You can likely achieve the LDAP string encoding and the other representation that you show below by style sheet processing of an XER encoding. Many such textual representations are possible. But you are correct, for the ASN.1 XML Encoding Rules the encoding will be XML 1.0 markup. And this markup is human-readable, though not as readable as plain text. But it can be easily transformed into other textual formats in a standard way, using readily available tools. And this XML markup representation does exist for each and every ASN.1 value, regardless of whether or not an alternative LDAP defined encoding exists. For example, there is an XER representation of ASN.1 type Certificate that is human-readable. This representation will be defined in the X9.96 XML Cryptographic Message Syntax NWI just approved last week by X9. It carries X.509 certificates in one of the saddle bags of type SignedData. In X9.96, the messages defined in X9.73 CMS (the ANSI X9 version of IETF S/MIME and RSA PKCS #7) will be specified using the ASN.1 from that standard, in a canonical XML variant of XER (CXER), so that the resulting XML messages can be cryptographically enhanced. I spoke on this subject at the RSA conference last week (http://ASN-1.com/cxer.zip). Phil "Ramsay, Ron" wrote: > > Phil, > > I would think that this wouldn't encode an address as "1 First Avanue, > Downtown" (human readable) or "1 FirstAvanue$Downtown" (LDAP) but as > > 1 First > AvanueDowntown > > ? > > Ron. > > -----Original Message----- > From: Phil Griffin [mailto:phil.griffin@asn-1.com] > Sent: Monday, 25 February 2002 14:42 > To: ietf-ldapbis@OpenLDAP.org > Subject: Re: ;binary > > The possibility of defining a human-readable > format for binary ASN.1 values in the future > is here, right now. Done already - or at least > very near final approval. > > It's called the 2002 edition of ISO/IEC 8824-1 | > ITU-T Recommendation X.680, and it defines an XML > markup representation for every value of every ASN.1 > type. Interestingly, it defines a dotted format, > borrowed from LDAP, for values of type OBJECT > IDENTIFIER. > > And there's XML Encoding Rules (XER), defined in > ISO/IEC 8825-3 | ITU-T Recommendation X.693. These > encodings carry the exact same abstract values as > defined in the ASN.1 standards, but in a human- > readable textual format. > > Having XER allows you to easily switch back and > forth between binary and textual representations > of the exact same values. > > Phil > > "Ramsay, Ron" wrote: > > > > Steven, > > > > I think you have stepped over the edge with this proposal. After Kurt was > so > > careful to explain that we must use the ASN.1 implied by the attribute OID > > with reference to the X.500 documents! > > > > What about aci;encoding=novel;. Would this be a subtype? > > > > Ron. > > > > -----Original Message----- > > From: Steven Legg [mailto:steven.legg@adacel.com.au] > > Sent: Monday, 25 February 2002 10:47 > > To: 'Christopher Oliva' > > Cc: ietf-ldapbis@OpenLDAP.org; 'David Chadwick SMTP (E-mail)' > > Subject: RE: ;binary > > > > Chris, > > > > Christopher Oliva wrote: > > > > The problem with this is that if a server is allowed to > > > > return ;binary when the client makes a request without > > > > ;binary then the servers might actually do that. That > > > > would be bad as client wouldn't get what they asked for. > > > > > > > As I have shown above, the client would know what they are getting > > > since the server has replied with ";binary". > > > > Unfortunately, client implementors often don't take into account all > > the potential responses they can get. They usually do enough to make > > their client work with their preferred LDAP server and leave it at > > that. So even if we explicitly specify that servers are allowed to return > > ";binary" without it being requested, there will still be people > > implementing clients that don't expect it. > > > > Apropos of the current discussion, I've found a good reason for NOT > > specifying that the native LDAP encoding for some syntax is the > > same as its ";binary" encoding. I've just submitted an I-D for > > an LDAP profile of X.500's Basic Access Control (it should appear in > > a few days) which uses the ACI Item syntax from RFC 2252. I've defined > > c for this syntax. However, I > > would have had a problem if the native LDAP encoding for this syntax > > had been previously defined to be the same as its ";binary" encoding. > > > > By not defining the native LDAP encoding to be the same as the ";binary" > > encoding for syntaxes that don't have a defined human-readable encoding, > > we leave open the possibility that we might define one in the future. > > > > Regards, > > Steven From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 01:48:30 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23351 for ; Mon, 25 Feb 2002 01:48:29 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1P6kMO34302; Mon, 25 Feb 2002 06:46:22 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 06:46:22 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1P6kJU34295 for ; Mon, 25 Feb 2002 06:46:19 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Mon, 25 Feb 2002 17:46:07 +1100 Message-ID: From: "Ramsay, Ron" To: steven.legg@adacel.com.au Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt Date: Mon, 25 Feb 2002 17:46:07 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Steven, Thanks for the definition. As you say, audio and jpegPhoto behave correctly, hanks for pointing that out. Ron. -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Monday, 25 February 2002 15:00 To: Ramsay, Ron Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt Ron, Ramsay, Ron wrote: > I've got to resist this notion of the undefined native LDAP encoding. I originally introduced the term "native LDAP encoding" as a replacement for "string encoding" because of the confusion "string" causes. It means the encoding of values one gets when requesting an attribute without specifying an explicit transfer option (like ";binary"). The native encoding may or may not be a human-readable character string. > > There are only two encodings for an LDAP value (and I think > Kurt was saying > this also): Yes, the native encoding and the binary encoding. It would be more correct to say that the LDAP core specification defines only two transfer encodings. Others may be defined in the future. > > o The ASN.1 value inherited from the X.500 definition The binary encoding. > o Possibly a string definition defined in RFC 2252 (possibly > referencing > other documents - 2253, 1778?) ... which RFC2251bis refers to as the "native encoding". > > If you request an attribute with ;binary, you get the first > one. If you > request a value which has a string encoding, you get the > second one. If it > doesn't have a string encoding, it is probably one of the > certificate types > and the "fix" is to request it with ;binary. Saying it doesn't have a string encoding is the same as saying it doesn't have a native LDAP encoding (unless by "string" you mean a human-readable representation). > The types audio > and jpegPhoto > are anomalous (if they are their own string encoding (but > then, what is a > string?), they have no ASN.1 definition, so what effect does > ;binary have?). They do have corresponding ASN.1 definitions, but they're hard to find since the attributes that use them aren't X.500 standard ones. I eventually tracked down the ASN.1 definitions by inspecting the Quipu source code. It turns out both syntaxes are treated as OCTET STRING for X.500 purposes. The effect of ";binary" on these syntaxes is the same as the effect on the LDAP Octet String syntax. > so, the certificate syntax has a native encoding but not a > string encoding. It would appear that you are using "string" to mean human-readable character string. The Certificate syntax certainly doesn't have a human-readable character string encoding. However, since LDAPv3 doesn't specify what you get if you ask for userCertificate without ";binary", the native encoding is undefined (or if you prefer, the Certificate syntax doesn't have a native encoding). > > I think it would be fair enough, in the future, to request it without > ;binary as any LDAP implementor should realise it is binary. It wouldn't be fair enough if in future a human-readable character string encoding is defined, which is what I've done with the ACI Item syntax. Regards, Steven > There have been > no complaints about audio or jpegPhoto. ;binary was simply a BAD idea. > > Ron. > > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Monday, 25 February 2002 12:23 > To: 'David Chadwick' > Cc: ietf-ldapbis@OpenLDAP.org > Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt > > > > > David, > > David Chadwick wrote: > > I think the new text for attribute descriptions is very good. Much > > better than before, especially the description of > subtyping. However, > > the subsection on Binary Option (4.1.5.1) could still do with some > > improvement I feel. Firstly, the section is not as clear as > > recent email > > we have had on the list, explaining that the attribute > value, whatever > > it is, is treated (or turned into) as an octet string > containing BER, > > and then a TL octet wrapper is placed around it. > > This is not the interpretation Kurt and I have been describing. An > AttributeValue in LDAP is an OCTET STRING. The contents octets of this > OCTET STRING are either a series of UTF8 encoded characters (being a > human-readable native LDAP encoding), a series of arbitrary octets > (being the native LDAP encoding for, e.g., the Octet String syntax - > 1.3.6.1.4.1.1466.115.121.1.40) or a BER encoded value (comforming to > the ASN.1 type corresponding to the LDAP syntax). > There is no extra OCTET STRING wrapper around the BER encoding. > > By way of example, the contents octets of AttributeValue for the value > "foo" returned as a value of cn would be (in hexadecimal): 66 6F 6F . > > Returned as a value of cn;binary it would be: 13 03 66 6F 6F, > the BER for a value of the printableString alternative from the > DirectoryString{} CHOICE. No OCTET STRING tags to be seen. > > > > > Secondly, the section talks about overriding the native encoding and > > sending it as BER instead. But then your example uses > > certificates, that > > are native BER encoded. > > The Certificate syntax does not have a native encoding in LDAPv3. > > > So what overriding is there to take place. It > > would seem like none, and therefore the effect of ;binary is null. > > "Overriding" is perhaps the wrong way to describe it, since for some > syntaxes there is no native LDAP encoding to override. I > prefer to think > of binary as an *alternative* way of encoding a value. For > some syntaxes, > like Certificate, there is no choice because there is only > one alternative > defined. > > > In > > other words the section does not clearly indicate to me what the > > difference would be in transferring a certificate without > ;binary and > > one with i.e. certificate;binary. > > The difference is that "certificate" without ";binary" is illegal. > The native LDAP encoding is, at present, undefined. > > > This is unfortunate and > > confusing to > > the reader. I suggest you use an example that is not a > > certificate, but > > is a simple string. You might then also add text to say what > > the effect > > of ;binary is on a value that is already BER encoded. > > > > I find this sentence particular confusing > > > > "Instead the attribute is to be transferred as > > a binary value encoded using the Basic Encoding Rules [X.690]." > > > > The reason it is confusing is that all values in BER are > binary. So if > > the value is already BER what more needs to be done to it? It > > would seem > > nothing. > > RFC 2252 allows a server to store a value in any format it likes. > If a value is stored as BER then it can be returned in ";binary" > form without conversion. If stored in the native LDAP encoding > then to be returned in ";binary" form it must first be re-encoded > (as BER). The converse applies if the value is requested in native > LDAP form. > > > > > Perhaps the sentence might read better as > > > > "Instead the attribute value is transferred as an ASN.1 > > OctetStringType, > > where the embedded octet string value is itself a BER encoded value" > > No, this suggests an extra OCTET STRING wrapper. > > > > > > > The second sentence > > "The > > syntax of the binary value is an ASN.1 data type > > definition, which is > > referenced by the "SYNTAX" part of the attribute type > definition." > > > > also has some errors in it, and could then be changed to > > > > "The syntax of the BER encoded value is an ASN.1 data type, which > > must conform to the "SYNTAX" part of the AttributeTypeDescription." > > > > Is that any better? > > I would prefer: > > "The value is BER encoded according to the ASN.1 data type > corresponding to the attribute's LDAP syntax. The LDAP syntax is > indicated by the "SYNTAX" part of the AttributeTypeDescription." > > ... with corresponding ASN.1 types nominated for each syntax > in RFC 2252bis. > > Regards, > Steven > From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 07:29:25 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07075 for ; Mon, 25 Feb 2002 07:29:25 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1PCRJ746612; Mon, 25 Feb 2002 12:27:20 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 12:27:19 +0000 Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1PCRGU46604 for ; Mon, 25 Feb 2002 12:27:16 GMT Received: from user-2ivf6md.dialup.mindspring.com ([165.247.154.205] helo=asn-1.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 16fKDq-0003JV-00 for ietf-ldapbis@OpenLDAP.org; Mon, 25 Feb 2002 07:27:14 -0500 Message-ID: <3C7A2CCB.CD0240A2@asn-1.com> Date: Mon, 25 Feb 2002 07:23:39 -0500 From: Phil Griffin Organization: Griffin Consulting - http://ASN-1.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapbis@OpenLDAP.org Subject: Re: ;binary References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Ramsay, Ron" wrote: > > Thanks, Phil. > > You raise two implicit matters. > > The first relates to style sheets and LDAP browsers. Style sheets are not a > part of LDAP and, though many clients may be HTML aware, the dependency > needs to be pointed out. Yes. This XML encoding is a way to better leverage browsers for ASN.1 users, and other formats can be produced using style sheets as well. > The second relates to your representation of certificates in XML. Are you > saying that CXER can be uniquely mapped to DER? I assume you preserve the > original signature (over the DER), otherwise you would be defining an XML > certificate? Yes, CXER cand DER are two encodings of the same abstract values which are based on the same underlying schema - the ASN.1 definitions defined in the X.680 series. The 2002 Draft is at Host: ftp://ties.itu.int login: asn1 password: notation1, but X.693 was not there when last I looked. In X9.96, the signatures on X.509 and X9.68 certificates will be over the DER encoding (or PER in the case of X9.68 which allows either) - nothing new there. But the signature in SignedData will be over an XML encoding, not DER. But this work will also define an XML representation of the values of all of the types it references, so there will be an XML representation of an X.509 certificate produced in this work. Phil > > Ron. > > -----Original Message----- > From: Phil Griffin [mailto:phil.griffin@asn-1.com] > Sent: Monday, 25 February 2002 16:56 > To: ietf-ldapbis@OpenLDAP.org > Subject: Re: ;binary > > Ron, > > You can likely achieve the LDAP string encoding and > the other representation that you show below by style > sheet processing of an XER encoding. Many such textual > representations are possible. But you are correct, for > the ASN.1 XML Encoding Rules the encoding will be XML > 1.0 markup. > > And this markup is human-readable, though not as readable > as plain text. But it can be easily transformed into other > textual formats in a standard way, using readily available > tools. And this XML markup representation does exist for > each and every ASN.1 value, regardless of whether or not > an alternative LDAP defined encoding exists. > > For example, there is an XER representation of ASN.1 type > Certificate that is human-readable. This representation > will be defined in the X9.96 XML Cryptographic Message > Syntax NWI just approved last week by X9. It carries > X.509 certificates in one of the saddle bags of type > SignedData. > > In X9.96, the messages defined in X9.73 CMS (the ANSI X9 > version of IETF S/MIME and RSA PKCS #7) will be specified > using the ASN.1 from that standard, in a canonical XML > variant of XER (CXER), so that the resulting XML messages > can be cryptographically enhanced. I spoke on this subject > at the RSA conference last week (http://ASN-1.com/cxer.zip). > > Phil > > "Ramsay, Ron" wrote: > > > > Phil, > > > > I would think that this wouldn't encode an address as "1 First Avanue, > > Downtown" (human readable) or "1 FirstAvanue$Downtown" (LDAP) but as > > > > 1 First > > AvanueDowntown > > > > ? > > > > Ron. > > > > -----Original Message----- > > From: Phil Griffin [mailto:phil.griffin@asn-1.com] > > Sent: Monday, 25 February 2002 14:42 > > To: ietf-ldapbis@OpenLDAP.org > > Subject: Re: ;binary > > > > The possibility of defining a human-readable > > format for binary ASN.1 values in the future > > is here, right now. Done already - or at least > > very near final approval. > > > > It's called the 2002 edition of ISO/IEC 8824-1 | > > ITU-T Recommendation X.680, and it defines an XML > > markup representation for every value of every ASN.1 > > type. Interestingly, it defines a dotted format, > > borrowed from LDAP, for values of type OBJECT > > IDENTIFIER. > > > > And there's XML Encoding Rules (XER), defined in > > ISO/IEC 8825-3 | ITU-T Recommendation X.693. These > > encodings carry the exact same abstract values as > > defined in the ASN.1 standards, but in a human- > > readable textual format. > > > > Having XER allows you to easily switch back and > > forth between binary and textual representations > > of the exact same values. > > > > Phil > > > > "Ramsay, Ron" wrote: > > > > > > Steven, > > > > > > I think you have stepped over the edge with this proposal. After Kurt > was > > so > > > careful to explain that we must use the ASN.1 implied by the attribute > OID > > > with reference to the X.500 documents! > > > > > > What about aci;encoding=novel;. Would this be a subtype? > > > > > > Ron. > > > > > > -----Original Message----- > > > From: Steven Legg [mailto:steven.legg@adacel.com.au] > > > Sent: Monday, 25 February 2002 10:47 > > > To: 'Christopher Oliva' > > > Cc: ietf-ldapbis@OpenLDAP.org; 'David Chadwick SMTP (E-mail)' > > > Subject: RE: ;binary > > > > > > Chris, > > > > > > Christopher Oliva wrote: > > > > > The problem with this is that if a server is allowed to > > > > > return ;binary when the client makes a request without > > > > > ;binary then the servers might actually do that. That > > > > > would be bad as client wouldn't get what they asked for. > > > > > > > > > As I have shown above, the client would know what they are getting > > > > since the server has replied with ";binary". > > > > > > Unfortunately, client implementors often don't take into account all > > > the potential responses they can get. They usually do enough to make > > > their client work with their preferred LDAP server and leave it at > > > that. So even if we explicitly specify that servers are allowed to > return > > > ";binary" without it being requested, there will still be people > > > implementing clients that don't expect it. > > > > > > Apropos of the current discussion, I've found a good reason for NOT > > > specifying that the native LDAP encoding for some syntax is the > > > same as its ";binary" encoding. I've just submitted an I-D for > > > an LDAP profile of X.500's Basic Access Control (it should appear in > > > a few days) which uses the ACI Item syntax from RFC 2252. I've defined > > > c for this syntax. However, I > > > would have had a problem if the native LDAP encoding for this syntax > > > had been previously defined to be the same as its ";binary" encoding. > > > > > > By not defining the native LDAP encoding to be the same as the ";binary" > > > encoding for syntaxes that don't have a defined human-readable encoding, > > > we leave open the possibility that we might define one in the future. > > > > > > Regards, > > > Steven From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 11:31:22 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16718 for ; Mon, 25 Feb 2002 11:31:21 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1PGT3R59572; Mon, 25 Feb 2002 16:29:04 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 16:29:03 +0000 Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1PGSwU59547 for ; Mon, 25 Feb 2002 16:28:58 GMT Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 11:30:55 -0500 Message-ID: From: Christopher Oliva To: "'steven.legg@adacel.com.au'" Cc: ietf-ldapbis@OpenLDAP.org, "'David Chadwick SMTP (E-mail)'" Subject: RE: ;binary Date: Mon, 25 Feb 2002 11:30:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BE19.CC10FDD0" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BE19.CC10FDD0 Content-Type: text/plain; charset="iso-8859-1" So what is the correct behavior of an ldapv3 server when a client does a wildcard search for "all attributes" ? Is the server supposed to include the userCertificate or omit it? In this case the client did not specify the binary transfer mechanism. So I guess the server should omit the attribute. My argument here is that the current ldapv3 RFCs do not really say one way or another what should happen. Since there is no obvious reason to omit the certificate, an implementation may elect to include it. Since the only way to transfer the values is to use the binary encoding, then one might conclude a couple of things. First, all syntaxes should have a native encoding so that all user attributes can be returned. This is an encoding that a client can expect. Second, the default way to transmit certificates is to use the binary encoding. You can call this the certificate's implicit native encoding. If you accept that a current implementation might behave this way, then wouldn't changing the specs break interoperability ? Or can interoperability be preserved simply by defining the native encoding for a certificate as the binary encoding. Chris. > > Unfortunately, client implementors often don't take into account all > the potential responses they can get. They usually do enough to make > their client work with their preferred LDAP server and leave it at > that. So even if we explicitly specify that servers are > allowed to return > ";binary" without it being requested, there will still be people > implementing clients that don't expect it. > ------_=_NextPart_001_01C1BE19.CC10FDD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ;binary So what is the correct behavior of an ldapv3 server = when a client does a wildcard search for "all attributes" = ? Is the server supposed to include the userCertificate = or omit it? In this case the client did not specify the binary transfer = mechanism. So I guess the server should omit the attribute. My argument here is that the current ldapv3 RFCs do = not really say one way or another what should happen. Since there is no = obvious reason to omit the certificate, an implementation may elect to = include it. Since the only way to transfer the values is to use the = binary encoding, then one might conclude a couple of things. First, all syntaxes should have a native encoding so = that all user attributes can be returned. This is an encoding that a = client can expect. Second, the default way to transmit certificates is = to use the binary encoding. You can call this the certificate's = implicit native encoding. If you accept that a current implementation might = behave this way, then wouldn't changing the specs break = interoperability ? Or can interoperability be preserved simply by = defining the native encoding for a certificate as the binary = encoding. Chris. > > Unfortunately, client implementors often don't = take into account all > the potential responses they can get. They = usually do enough to make > their client work with their preferred LDAP = server and leave it at > that. So even if we explicitly specify that = servers are > allowed to return > ";binary" without it being requested, = there will still be people > implementing clients that don't expect = it. > ------_=_NextPart_001_01C1BE19.CC10FDD0-- From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 14:33:54 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26490 for ; Mon, 25 Feb 2002 14:33:54 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1PJVnV69208; Mon, 25 Feb 2002 19:31:49 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 19:31:49 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1PJVkU69190; Mon, 25 Feb 2002 19:31:46 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1PJViC69756; Mon, 25 Feb 2002 19:31:44 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020224204343.017cf618@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Feb 2002 11:31:48 -0800 To: helm@fionn.es.net From: "Kurt D. Zeilenga" Subject: Re: Service name + host check [Re: Last Call: Discovering LDAP Services with DNS to Proposed Standard] Cc: ietf-ldapbis@OpenLDAP.org, ietf-ldapext@OpenLDAP.org In-Reply-To: <200202242030.MAA00632@fionn.es.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I believe supporting service (protocol) information in TLS checks would be useful. I would think an optimal solution would be service neutral. That is, the TLS check would be defined in a manner supporting not only LDAP, but all protocols which use TLS. Maybe this is something which PKIX WG or interested individuals should consider taking on. Once a general mechanism for using service information in TLS checks was establish, the LDAP "core" specification could just use it by reference. Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 14:43:59 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26841 for ; Mon, 25 Feb 2002 14:43:58 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1PJg4770148; Mon, 25 Feb 2002 19:42:04 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 19:42:04 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1PJg3U70141 for ; Mon, 25 Feb 2002 19:42:03 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1PJg2C69827 for ; Mon, 25 Feb 2002 19:42:02 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020225100000.01708688@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Feb 2002 11:42:06 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: ;binary and * Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: There needs to a clarification regarding transfer encoding to use when the attribute was not requested by attribute description. E.g., by * or an empty attribute list. I suggest that if "foo" is to returned (when not requested by attribute description), that the server is to use the "native" transfer encoding if the server supports such for that attribute. Otherwise, the server may choose to return the attribute in any one of the transfer encodings it does support OR not return the attribute. Additionally, the TS should say that clients MUST NOT expect any particular transfer encoding of attributes which are not requested by attribute description. Where a client desires a particular transfer encoding, including the native encoding, the client SHOULD request the attribute using an attribute description indicating the desired transfer encoding. In examples, please avoid use of userCertificate and other attributes which mandate use of particular transfer encoding options. Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 14:44:17 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26864 for ; Mon, 25 Feb 2002 14:44:15 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1PJgOd70235; Mon, 25 Feb 2002 19:42:24 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 19:42:24 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1PJgNU70228 for ; Mon, 25 Feb 2002 19:42:23 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1PJY1C69770; Mon, 25 Feb 2002 19:34:01 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020225094116.01719320@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Feb 2002 11:34:05 -0800 To: Christopher Oliva From: "Kurt D. Zeilenga" Subject: RE: ;binary Cc: "'steven.legg@adacel.com.au'" , ietf-ldapbis@OpenLDAP.org, "'David Chadwick SMTP (E-mail)'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 08:30 AM 2002-02-25, Christopher Oliva wrote: >So what is the correct behavior of an ldapv3 server when a client does a wildcard search for "all attributes" ? I assume you mean when the client provides an empty attributes list or an attribute list which contains "*". That is, the client has failed to request userCertificate using ;binary as indicated in the specification [RFC 2252,RFC 2256]. >Is the server supposed to include the userCertificate or omit it? In this case the client did not specify the binary transfer mechanism. So I guess the server should omit the attribute. The behavior is undefined as the client was expected to request the userCertificate attribute using ;binary. >My argument here is that the current ldapv3 RFCs do not really say one way or another what should happen. It doesn't need to. The specification requires the client to request the userCertificate attribute using ;binary. If the client fails this mandate, then the behavior it gets is undefined. >Since there is no obvious reason to omit the certificate, an implementation may elect to include it. There are obvious reasons to omit it and, IIRC, there are implementations which do exactly this. I would consider such implementations as being conformant. >If you accept that a current implementation might behave this way, then wouldn't changing the specs break interoperability ? Clients are expected to request the userCertificate attribute using ;binary. Clients which fail to follow the specification will not interoperate with all compliant servers. I do see a need for a general (not userCertificate specific clarification). I will offer a suggestion separately. Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 14:52:09 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27222 for ; Mon, 25 Feb 2002 14:52:07 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1PJoEY71149; Mon, 25 Feb 2002 19:50:14 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 19:50:14 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1PJoBU71142 for ; Mon, 25 Feb 2002 19:50:12 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1PJfAC69821; Mon, 25 Feb 2002 19:41:10 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020225114106.01708820@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Feb 2002 11:41:14 -0800 To: Christopher Oliva From: "Kurt D. Zeilenga" Subject: RE: ;binary Cc: "'steven.legg@adacel.com.au'" , ietf-ldapbis@OpenLDAP.org, "'David Chadwick SMTP (E-mail)'" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 08:30 AM 2002-02-25, Christopher Oliva wrote: >So what is the correct behavior of an ldapv3 server when a client does a wildcard search for "all attributes" ? I assume you mean when the client provides an empty attributes list or an attribute list which contains "*". That is, the client has failed to request userCertificate using ;binary as indicated in the specification [RFC 2252,RFC 2256]. >Is the server supposed to include the userCertificate or omit it? In this case the client did not specify the binary transfer mechanism. So I guess the server should omit the attribute. The behavior is undefined as the client was expected to request the userCertificate attribute using ;binary. >My argument here is that the current ldapv3 RFCs do not really say one way or another what should happen. It doesn't need to. The specification requires the client to request the userCertificate attribute using ;binary. If the client fails this mandate, then the behavior it gets is undefined. >Since there is no obvious reason to omit the certificate, an implementation may elect to include it. There are obvious reasons to omit it and, IIRC, there are implementations which do exactly this. I would consider such implementations as being conformant. >If you accept that a current implementation might behave this way, then wouldn't changing the specs break interoperability ? Clients are expected to request the userCertificate attribute using ;binary. Clients which fail to follow the specification will not interoperate with all compliant servers. I do see a need for a general (not userCertificate specific clarification). I will offer a suggestion separately. Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 15:50:14 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29432 for ; Mon, 25 Feb 2002 15:50:13 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1PKlpa73436; Mon, 25 Feb 2002 20:47:51 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 20:47:51 +0000 Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1PKlmU73416; Mon, 25 Feb 2002 20:47:49 GMT Received: from fwd02.sul.t-online.de by mailout08.sul.t-online.com with smtp id 16fRPA-0000YK-02; Mon, 25 Feb 2002 21:07:24 +0100 Received: from junker.stroeder.com (520010731148-0001@[217.1.21.234]) by fmrl02.sul.t-online.com with esmtp id 16fROu-0VFWbIC; Mon, 25 Feb 2002 21:07:08 +0100 Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 6DF73157D06; Mon, 25 Feb 2002 21:06:57 +0100 (CET) Message-ID: <3C7A9960.1040006@stroeder.com> Date: Mon, 25 Feb 2002 21:06:56 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= Reply-To: michael@stroeder.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020224 X-Accept-Language: de-DE, de, en MIME-Version: 1.0 To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: ;binary References: <5.1.0.14.0.20020225094116.01719320@127.0.0.1> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Sender: 520010731148-0001@t-dialin.net Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > > At 08:30 AM 2002-02-25, Christopher Oliva wrote: > > > > My argument here is that the current ldapv3 RFCs do not > > really say one way or another what should happen. > > It doesn't need to. The specification requires the client to > request the userCertificate attribute using ;binary. If the > client fails this mandate, then the behavior it gets is undefined. > [..] > Clients are expected to request the userCertificate attribute > using ;binary. Clients which fail to follow the specification > will not interoperate with all compliant servers. Sorry for jumping in that late. Hmm, now you're telling us that e.g. a generic client has to explicitly request all attributes it might handle additionally with transfer encoding? Ciao, Michael. From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 16:09:02 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00094 for ; Mon, 25 Feb 2002 16:09:00 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1PL7A474383; Mon, 25 Feb 2002 21:07:10 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 21:07:10 +0000 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1PL79U74363; Mon, 25 Feb 2002 21:07:09 GMT Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id g1PL6l711622; Mon, 25 Feb 2002 13:06:47 -0800 (PST) Received: from netscape.com ([10.169.184.31]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GS3XBB02.8L3; Mon, 25 Feb 2002 13:06:47 -0800 Message-ID: <3C7AA766.1B1704C1@netscape.com> Date: Mon, 25 Feb 2002 16:06:46 -0500 From: Mark Smith Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 To: michael@stroeder.com CC: "Kurt D. Zeilenga" , ietf-ldapbis@OpenLDAP.org Subject: Re: ;binary References: <5.1.0.14.0.20020225094116.01719320@127.0.0.1> <3C7A9960.1040006@stroeder.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id g1PL79U74364 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Michael Ströder wrote: > > Kurt D. Zeilenga wrote: > > > > At 08:30 AM 2002-02-25, Christopher Oliva wrote: > > > > > > My argument here is that the current ldapv3 RFCs do not > > > really say one way or another what should happen. > > > > It doesn't need to. The specification requires the client to > > request the userCertificate attribute using ;binary. If the > > client fails this mandate, then the behavior it gets is undefined. > > [..] > > Clients are expected to request the userCertificate attribute > > using ;binary. Clients which fail to follow the specification > > will not interoperate with all compliant servers. > > Sorry for jumping in that late. > > Hmm, now you're telling us that e.g. a generic client has to explicitly > request all attributes it might handle additionally with transfer encoding? I don't think so. Section 4.3.1 of 2252 (Binary Transfer of Values) says in part: ... Clients which request that all attributes be returned from entries MUST be prepared to receive values in binary (e.g. userCertificate;binary), and SHOULD NOT simply display binary or unrecognized values to users. and section 6.5 of 2252 (Certificate) says: ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' ) Because of the changes from X.509(1988) and X.509(1993) and additional changes to the ASN.1 definition to support certificate extensions, no string representation is defined, and values in this syntax MUST only be transferred using the binary encoding, by requesting or returning the attributes with descriptions "userCertificate;binary" or "caCertificate;binary". The BNF notation in RFC 1778 for "User Certificate" is not recommended to be used. I read that to say that servers are free to return userCertificate;binary and other strings that end in ";binary" within the AttributeDescriptions that are part of the SearchResultEntry messages. Unfortunately, I do not know where text that is similar to section 4.3.1 of 2252 appears in the LDAPbis I-Ds. I believe it is common practice for LDAPv3 clients to expect to receive userCertificate;binary in the AttributeDescription. -- Mark Smith AOL Strategic Business Solutions My words are my own, not my employer's. From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 16:35:53 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00818 for ; Mon, 25 Feb 2002 16:35:52 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1PLXvR75070; Mon, 25 Feb 2002 21:33:57 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 21:33:57 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1PLXtU75063 for ; Mon, 25 Feb 2002 21:33:55 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1PLXqC70552; Mon, 25 Feb 2002 21:33:52 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020225131641.01731218@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Feb 2002 13:33:55 -0800 To: michael@stroeder.com From: "Kurt D. Zeilenga" Subject: Re: ;binary Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: <3C7A9960.1040006@stroeder.com> References: <5.1.0.14.0.20020225094116.01719320@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by galois.openldap.org id g1PLXtU75064 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit At 12:06 PM 2002-02-25, Michael Ströder wrote: >Kurt D. Zeilenga wrote: >> >> At 08:30 AM 2002-02-25, Christopher Oliva wrote: >> > >> > My argument here is that the current ldapv3 RFCs do not >> > really say one way or another what should happen. >> >> It doesn't need to. The specification requires the client to >> request the userCertificate attribute using ;binary. If the >> client fails this mandate, then the behavior it gets is undefined. >> [..] >>Clients are expected to request the userCertificate attribute >>using ;binary. Clients which fail to follow the specification >>will not interoperate with all compliant servers. > >Sorry for jumping in that late. > >Hmm, now you're telling us that e.g. a generic client has to explicitly request all attributes it might handle additionally with transfer encoding? I am saying clients are expected to request userCertificate as userCertificate;binary and that if they don't they will not interoperate with all existing compliant implementations. The problem is that the specification only states that '*' implies "all user attributes", it doesn't say anything about transfer encoding. Clearly we need to clarify the handling of '*'. See my suggestion in this area. From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 18:16:54 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03566 for ; Mon, 25 Feb 2002 18:16:53 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1PNEqd78844; Mon, 25 Feb 2002 23:14:52 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Mon, 25 Feb 2002 23:14:52 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1PNEnU78837 for ; Mon, 25 Feb 2002 23:14:49 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1PNEmC71083 for ; Mon, 25 Feb 2002 23:14:48 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020225141944.0176b5d0@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 25 Feb 2002 15:14:52 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: (foo=*) v (foo;binary=*) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: When ;binary appears in the AttributeDescription in a Filter component, it indicates that the associated AttributeValueAssertion is binary (BER) encoded. If the server does not support ;binary transfer of assertion value, then it MUST treat the attribute description as unrecognized. But here, as the present CHOICE has no associated AttributeValueAssertion, the transfer encoding option (if recognized) is extraneous (otherwise treated as unrecognized). If a server which recognizes "foo;binary", it should likely treat (foo=*) and (foo;binary=*) as equivalent. That is, both are asserting that the attribute "foo" (or one of its subtypes) is present. But note that a server may recognize "foo" but not "foo;binary" and, in such cases, (foo=*) and (foo;binary=*) are not equivalent. That is, the former may evaluate to True yet the latter to False. Kurt From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 23:11:05 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09542 for ; Mon, 25 Feb 2002 23:11:03 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1Q48xk85431; Tue, 26 Feb 2002 04:08:59 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 26 Feb 2002 04:08:59 +0000 Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1Q48uU85424 for ; Tue, 26 Feb 2002 04:08:57 GMT Received: (qmail 32350 invoked from network); 26 Feb 2002 04:09:30 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 26 Feb 2002 04:09:30 -0000 Reply-To: From: "Steven Legg" To: Subject: Filter Items and Absent Attributes Date: Tue, 26 Feb 2002 15:07:34 +1100 Message-ID: <006201c1be7b$1f659390$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, A statement that is in the 4th edition of X.511, but not in the 2nd edition, was recently brought to my attention. I found it surprising. I suspect I not the only one. In X.511:2001, Clause 7.8.2: "An assertion" ... "evaluates to UNDEFINED if it relates to an attribute value and the attribute type is not present in an" [ entry ] "against which the assertion is being tested." This means, for example, that a filter item like (givenName=Bob) evaluates to UNDEFINED, rather than FALSE, if an entry doesn't have the givenName attribute. This affects how negated filter items are evaluated. For example, the filter (!(givenName=Bob)) only returns entries that have the givenName attribute, but not the givenName value "Bob". The entries that don't have the givenName attribute are not returned (giving the impression that they *do* have "Bob" as a givenName). Apparently this behaviour was the original intention in the 2nd edition of X.511 as well. It just wasn't explained properly. Personally, I think returning UNDEFINED instead of FALSE would be counter-intuitive to most users, and therefore a bad idea. Does anyone's server implementation evaluate filter items to UNDEFINED instead of FALSE when the attribute doesn't exist (obviously mine doesn't) ? The answer determines how I apply access controls to searches in my I-D on X.500 Basic Access Control for LDAP. The current specification is based on the assumption that everyone else is returning FALSE too. If that is the case then we have to decide whether we want to define LDAP searches to behave exactly like X.500 searches (and change our implementations), or explicitly specify that LDAP behaves differently, or influence the X.500 working group to change X.511. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Mon Feb 25 23:43:23 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10287 for ; Mon, 25 Feb 2002 23:43:22 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1Q4fND86028; Tue, 26 Feb 2002 04:41:23 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 26 Feb 2002 04:41:23 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1Q4fLU86021 for ; Tue, 26 Feb 2002 04:41:22 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Tue, 26 Feb 2002 15:41:10 +1100 Message-ID: From: "Ramsay, Ron" To: steven.legg@adacel.com.au, ietf-ldapbis@OpenLDAP.org Subject: RE: Filter Items and Absent Attributes Date: Tue, 26 Feb 2002 15:41:07 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Steven, Our implementation treats it as UNDEFINED. It is counter-intuitive only in the same way that all logic assertions seem to defy logic. For example, an empty AND is TRUE. The logic must be: Can I evaluate givenName=Bob if there is no givenName attribute? The answer clearly is NO. Therefore, the assertion is UNDEFINED. The assertion !(givenName=Bob) is therefore also UNDEFINED. This is logical. I think you have been trying to apply heuristics. That is a choice, but then logic cannot be your guide. Ron. -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Tuesday, 26 February 2002 15:08 To: ietf-ldapbis@OpenLDAP.org Subject: Filter Items and Absent Attributes Folks, A statement that is in the 4th edition of X.511, but not in the 2nd edition, was recently brought to my attention. I found it surprising. I suspect I not the only one. In X.511:2001, Clause 7.8.2: "An assertion" ... "evaluates to UNDEFINED if it relates to an attribute value and the attribute type is not present in an" [ entry ] "against which the assertion is being tested." This means, for example, that a filter item like (givenName=Bob) evaluates to UNDEFINED, rather than FALSE, if an entry doesn't have the givenName attribute. This affects how negated filter items are evaluated. For example, the filter (!(givenName=Bob)) only returns entries that have the givenName attribute, but not the givenName value "Bob". The entries that don't have the givenName attribute are not returned (giving the impression that they *do* have "Bob" as a givenName). Apparently this behaviour was the original intention in the 2nd edition of X.511 as well. It just wasn't explained properly. Personally, I think returning UNDEFINED instead of FALSE would be counter-intuitive to most users, and therefore a bad idea. Does anyone's server implementation evaluate filter items to UNDEFINED instead of FALSE when the attribute doesn't exist (obviously mine doesn't) ? The answer determines how I apply access controls to searches in my I-D on X.500 Basic Access Control for LDAP. The current specification is based on the assumption that everyone else is returning FALSE too. If that is the case then we have to decide whether we want to define LDAP searches to behave exactly like X.500 searches (and change our implementations), or explicitly specify that LDAP behaves differently, or influence the X.500 working group to change X.511. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 26 07:07:13 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24810 for ; Tue, 26 Feb 2002 07:07:12 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1QC54F02891; Tue, 26 Feb 2002 12:05:04 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 26 Feb 2002 12:05:04 +0000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1QC50U02878 for ; Tue, 26 Feb 2002 12:05:01 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24634; Tue, 26 Feb 2002 07:04:57 -0500 (EST) Message-Id: <200202261204.HAA24634@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapbis@OpenLDAP.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapbis-roadmap-00.txt Date: Tue, 26 Feb 2002 07:04:57 -0500 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP (v3) Revision Working Group of the IETF. Title : LDAP: Technical Specification Road Map Author(s) : K. Zeilenga Filename : draft-ietf-ldapbis-roadmap-00.txt Pages : 5 Date : 25-Feb-02 The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services which act in accordance with X.500 data and service models. This document provides a roadmap of the LDAP Technical Specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-roadmap-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapbis-roadmap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapbis-roadmap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020225143211.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapbis-roadmap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapbis-roadmap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020225143211.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 26 07:59:46 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24811 for ; Tue, 26 Feb 2002 07:07:12 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1QC57h02894; Tue, 26 Feb 2002 12:05:07 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 26 Feb 2002 12:05:07 +0000 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1QC51U02879 for ; Tue, 26 Feb 2002 12:05:01 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24615; Tue, 26 Feb 2002 07:04:52 -0500 (EST) Message-Id: <200202261204.HAA24615@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapbis@OpenLDAP.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapbis-models-00.txt Date: Tue, 26 Feb 2002 07:04:52 -0500 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP (v3) Revision Working Group of the IETF. Title : LDAP: Directory Information Models Author(s) : K. Zeilenga Filename : draft-ietf-ldapbis-models-00.txt Pages : 39 Date : 25-Feb-02 The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services which act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-models-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ldapbis-models-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ldapbis-models-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020225143159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapbis-models-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapbis-models-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020225143159.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 26 10:26:44 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03278 for ; Tue, 26 Feb 2002 10:26:44 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1QFOi410707; Tue, 26 Feb 2002 15:24:44 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 26 Feb 2002 15:24:44 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1QFOgU10698 for ; Tue, 26 Feb 2002 15:24:42 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1QFOVC76004; Tue, 26 Feb 2002 15:24:31 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020226072305.017122b8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Feb 2002 07:24:34 -0800 To: Internet-Drafts@ietf.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldapbis-roadmap-00.txt Cc: IETF-Announce:;, ietf-ldapbis@OpenLDAP.org In-Reply-To: <200202261204.HAA24634@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This I-D is intended to provide a roadmap of the technical specification. This is especially needed due to reorganization of the technical specification. At 04:04 AM 2002-02-26, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the LDAP (v3) Revision Working Group of the IETF. > > Title : LDAP: Technical Specification Road Map > Author(s) : K. Zeilenga > Filename : draft-ietf-ldapbis-roadmap-00.txt > Pages : 5 > Date : 25-Feb-02 > >The Lightweight Directory Access Protocol (LDAP) is an Internet >protocol for accessing distributed directory services which act in >accordance with X.500 data and service models. This document provides >a roadmap of the LDAP Technical Specification. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-roadmap-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ldapbis-roadmap-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ldapbis-roadmap-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20020225143211.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-ldapbis-roadmap-00.txt > > From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 26 10:46:01 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04342 for ; Tue, 26 Feb 2002 10:46:00 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1QFhea11422; Tue, 26 Feb 2002 15:43:40 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 26 Feb 2002 15:43:40 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1QFhcU11414 for ; Tue, 26 Feb 2002 15:43:38 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1QFhcC76104 for ; Tue, 26 Feb 2002 15:43:38 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020226072451.01748670@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Feb 2002 07:43:41 -0800 To: ietf-ldapbis@OpenLDAP.org From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldapbis-models-00.txt In-Reply-To: <200202261204.HAA24615@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: This I-D is a strawman proposal for a "LDAP Overview / Data Model" I-D. Due to time constraints, I was not able to complete the I-D as fully as I had hoped. In particular I was not able to complete a requirement by requirement comparison with the existing specification. Hence, I may have inadvertently missed/added something. For intended changes, I did try to note such in Appendix A. These issues will be addressed in a subsequent revision. Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 26 14:15:02 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17102 for ; Tue, 26 Feb 2002 14:15:02 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1QJCu529487; Tue, 26 Feb 2002 19:12:56 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 26 Feb 2002 19:12:56 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1QJCrU29480 for ; Tue, 26 Feb 2002 19:12:53 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1QJCDC77503; Tue, 26 Feb 2002 19:12:13 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020226103330.01704f28@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Feb 2002 11:12:15 -0800 To: From: "Kurt D. Zeilenga" Subject: Re: Filter Items and Absent Attributes Cc: In-Reply-To: <006201c1be7b$1f659390$a518200a@osmium.mtwav.adacel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Ugh! Logically, I understand the distinction being made in the 4th edition. The problem I see is that most server implementation likely don't implement it this way and it might be every difficult for them to change. Changing the logic of a filter evaluation routine is likely simple enough, but changing the logic of indexing supporting filter evaluation would likely be quite complex. Briefly (just to indicate why implementations might find it difficult to implement the 4th edition semantics), if one has an equality index where AVAs are used as key, the AVA selects the set of entries which have that AVA is True (or may be True). For all entries which are not in this set, the filter won't evaluate to True. However, the equality index doesn't say whether it would evaluate to False or Undefined. For this, another index (such as for presence) must be used. I've run into clients which desire the semantics which the 4th edition suggests. They tend to use (&(foo=*)(foo=bar)) to achieve this as, I believe, most implementations do not consistently evaluate (foo=bar) as described in the 4th edition. I note as well that the 4th edition statement is somewhat problematic as it implies (not intentionally) that (foo=*) should be Undefined if the entry doesn't contain the attribute foo. RFC 2251, of course, clarifies that (foo=*) cannot evaluate to Undefined. Anyways, I think the first thing we need to establish is whether there are multiple interoperable implementations of filters as clarified in the 4th Edition. Ron states he has one implementation, are there others? Kurt At 08:07 PM 2002-02-25, Steven Legg wrote: >Folks, > >A statement that is in the 4th edition of X.511, but not in the 2nd >edition, was recently brought to my attention. I found it surprising. >I suspect I not the only one. > >In X.511:2001, Clause 7.8.2: > > "An assertion" ... "evaluates to UNDEFINED if it relates to an attribute > value and the attribute type is not present in an" [ entry ] "against > which the assertion is being tested." > >This means, for example, that a filter item like (givenName=Bob) evaluates >to UNDEFINED, rather than FALSE, if an entry doesn't have the givenName >attribute. This affects how negated filter items are evaluated. >For example, the filter (!(givenName=Bob)) only returns entries >that have the givenName attribute, but not the givenName value "Bob". >The entries that don't have the givenName attribute are not returned >(giving the impression that they *do* have "Bob" as a givenName). > >Apparently this behaviour was the original intention in the 2nd edition >of X.511 as well. It just wasn't explained properly. > >Personally, I think returning UNDEFINED instead of FALSE would be >counter-intuitive to most users, and therefore a bad idea. > >Does anyone's server implementation evaluate filter items to UNDEFINED >instead of FALSE when the attribute doesn't exist (obviously mine >doesn't) ? The answer determines how I apply access controls to searches >in my I-D on X.500 Basic Access Control for LDAP. The current specification >is based on the assumption that everyone else is returning FALSE too. > >If that is the case then we have to decide whether we want to define >LDAP searches to behave exactly like X.500 searches (and change our >implementations), or explicitly specify that LDAP behaves differently, >or influence the X.500 working group to change X.511. > >Regards, >Steven From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 26 15:43:12 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20742 for ; Tue, 26 Feb 2002 15:43:11 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1QKfCJ34463; Tue, 26 Feb 2002 20:41:12 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 26 Feb 2002 20:41:12 +0000 Received: (from kurt@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) id g1QKfBs34455 for ietf-ldapbis@openldap.org; Tue, 26 Feb 2002 20:41:11 GMT Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1QKX4U33711 for ; Tue, 26 Feb 2002 20:33:05 GMT Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA26704 for ; Tue, 26 Feb 2002 14:29:48 -0600 Received: from d04nm205.raleigh.ibm.com (d04nm205.raleigh.ibm.com [9.27.5.151]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g1QKX2e127430 for ; Tue, 26 Feb 2002 15:33:02 -0500 Subject: Re: I-D ACTION:draft-ietf-ldapbis-models-00.txt To: ietf-ldapbis@OpenLDAP.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Steve Omrani" Date: Tue, 26 Feb 2002 14:33:01 -0600 X-MIMETrack: Serialize by Router on D04NM205/04/M/IBM(Release 5.0.9 |November 16, 2001) at 02/26/2002 03:33:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt, The top left had corner of the I-D says, "Obsoletes: RFC 2251". Do you mean that? Or is it a typo? Thanks, Steve Omrani LDAP Senior Software Developer Internet: somrani@us.ibm.com Phone: 512-838-8375 (TL 678-8375) Fax: 512-838-8597 From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 26 16:00:09 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21497 for ; Tue, 26 Feb 2002 16:00:09 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1QKvqq34907; Tue, 26 Feb 2002 20:57:52 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Tue, 26 Feb 2002 20:57:52 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1QKvpU34900 for ; Tue, 26 Feb 2002 20:57:51 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1QKvmC78045; Tue, 26 Feb 2002 20:57:48 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020226124516.0175b510@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Feb 2002 12:57:51 -0800 To: "Steve Omrani" From: "Kurt D. Zeilenga" Subject: Re: I-D ACTION:draft-ietf-ldapbis-models-00.txt Cc: ietf-ldapbis@OpenLDAP.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: At 12:33 PM 2002-02-26, Steve Omrani wrote: >The top left had corner of the I-D says, "Obsoletes: RFC 2251". >Do you mean that? Or is it a typo? It likely should say: Obsoletes: RFC 2251, RFC 2252, RFC 2256 so that Obsoleted-by relationships for the older documents will properly reflected in the RFC-Index. Thanks, Kurt From owner-ietf-ldapbis@OpenLDAP.org Tue Feb 26 23:50:59 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02663 for ; Tue, 26 Feb 2002 23:50:58 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1R4mo247731; Wed, 27 Feb 2002 04:48:50 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 27 Feb 2002 04:48:50 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1R4mkU47711; Wed, 27 Feb 2002 04:48:47 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Wed, 27 Feb 2002 15:48:36 +1100 Message-ID: From: "Ramsay, Ron" To: "Kurt D. Zeilenga" Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Filter Items and Absent Attributes Date: Wed, 27 Feb 2002 15:48:34 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt, I'd just like to make two points. Firstly, X.500 haven't changed the rules. I've always worked from the 2nd edition (1993) and found no ambiguity in the specification of filter handling. The note in the 4th edition may have been a clarification for those who missed the power of the logic. The second one relates to (foo=*). In X.500, this would be converted to foo:present, which is not UNDEFINED when the attribute is not in the entry. However, LDAPv3, or some implementations, I'm not sure which, allows the passing of '*' in a filter. In this case, a strict application of the X.500 rules would result in UNDEFINED. (Although the X.500 rules would then require you to find '*' in each entry!) X.500 gateways would be expected to convert this filter to foo:present and so they would operate correctly. Therefore, I see no problems for anyone correctly implementing the X.500 standards. Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Wednesday, 27 February 2002 6:12 To: steven.legg@adacel.com.au Cc: ietf-ldapbis@OpenLDAP.org Subject: Re: Filter Items and Absent Attributes Ugh! Logically, I understand the distinction being made in the 4th edition. The problem I see is that most server implementation likely don't implement it this way and it might be every difficult for them to change. Changing the logic of a filter evaluation routine is likely simple enough, but changing the logic of indexing supporting filter evaluation would likely be quite complex. Briefly (just to indicate why implementations might find it difficult to implement the 4th edition semantics), if one has an equality index where AVAs are used as key, the AVA selects the set of entries which have that AVA is True (or may be True). For all entries which are not in this set, the filter won't evaluate to True. However, the equality index doesn't say whether it would evaluate to False or Undefined. For this, another index (such as for presence) must be used. I've run into clients which desire the semantics which the 4th edition suggests. They tend to use (&(foo=*)(foo=bar)) to achieve this as, I believe, most implementations do not consistently evaluate (foo=bar) as described in the 4th edition. I note as well that the 4th edition statement is somewhat problematic as it implies (not intentionally) that (foo=*) should be Undefined if the entry doesn't contain the attribute foo. RFC 2251, of course, clarifies that (foo=*) cannot evaluate to Undefined. Anyways, I think the first thing we need to establish is whether there are multiple interoperable implementations of filters as clarified in the 4th Edition. Ron states he has one implementation, are there others? Kurt At 08:07 PM 2002-02-25, Steven Legg wrote: >Folks, > >A statement that is in the 4th edition of X.511, but not in the 2nd >edition, was recently brought to my attention. I found it surprising. >I suspect I not the only one. > >In X.511:2001, Clause 7.8.2: > > "An assertion" ... "evaluates to UNDEFINED if it relates to an attribute > value and the attribute type is not present in an" [ entry ] "against > which the assertion is being tested." > >This means, for example, that a filter item like (givenName=Bob) evaluates >to UNDEFINED, rather than FALSE, if an entry doesn't have the givenName >attribute. This affects how negated filter items are evaluated. >For example, the filter (!(givenName=Bob)) only returns entries >that have the givenName attribute, but not the givenName value "Bob". >The entries that don't have the givenName attribute are not returned >(giving the impression that they *do* have "Bob" as a givenName). > >Apparently this behaviour was the original intention in the 2nd edition >of X.511 as well. It just wasn't explained properly. > >Personally, I think returning UNDEFINED instead of FALSE would be >counter-intuitive to most users, and therefore a bad idea. > >Does anyone's server implementation evaluate filter items to UNDEFINED >instead of FALSE when the attribute doesn't exist (obviously mine >doesn't) ? The answer determines how I apply access controls to searches >in my I-D on X.500 Basic Access Control for LDAP. The current specification >is based on the assumption that everyone else is returning FALSE too. > >If that is the case then we have to decide whether we want to define >LDAP searches to behave exactly like X.500 searches (and change our >implementations), or explicitly specify that LDAP behaves differently, >or influence the X.500 working group to change X.511. > >Regards, >Steven From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 27 00:52:23 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03626 for ; Wed, 27 Feb 2002 00:52:23 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1R5oHS49174; Wed, 27 Feb 2002 05:50:17 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 27 Feb 2002 05:50:17 +0000 Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1R5oEU49167 for ; Wed, 27 Feb 2002 05:50:14 GMT Received: (qmail 17276 invoked from network); 27 Feb 2002 05:50:38 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 27 Feb 2002 05:50:38 -0000 Reply-To: From: "Steven Legg" To: "'Ramsay, Ron'" Cc: Subject: RE: Filter Items and Absent Attributes Date: Wed, 27 Feb 2002 16:48:49 +1100 Message-ID: <006301c1bf52$6e933850$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ron, Ramsay, Ron wrote: > Our implementation treats it as UNDEFINED. > > It is counter-intuitive only in the same way that all logic > assertions seem > to defy logic. For example, an empty AND is TRUE. > > The logic must be: Can I evaluate givenName=Bob if there is > no givenName > attribute? The answer clearly is NO. Therefore, the assertion > is UNDEFINED. What is "clear" critically depends on how one models the entry contents and how one interprets the meaning of the assertions. I could model an entry's contents as a set of (type, value) tuples and the assertion (givenName=Bob) as the question "does the entry contain the tuple (givenName, Bob)?" If the givenName attribute is absent then the assertion is "clearly" FALSE. Such an interpretation is more in keeping with LDAP, where no distinction is drawn between adding an attribute and adding attribute values. Given that there are multi-valued attributes and attribute subtyping, we have a situation where the absence of an attribute could be interpreted two ways: (1) The value(s) of the attribute for the entity represented by the entry are not known. (2) There are no values of the attribute for the entity represented by the entry. For example, the absence of the telephoneNumber attribute could mean that the telephone numbers for the entity are not known, or it could mean that the entity doesn't have a phone (and hence no phone numbers). The X.500 model doesn't provide us with a way to distinguish between these two cases. For the sake of argument, let us suppose that we can provide a mark for each attribute type, whether the attribute is present or not, to indicate whether the existing set of values (possibly empty) is complete (all values are known) or incomplete (there may be other unknown values). Case (1) above corresponds to an incomplete attribute with an empty set of values. Case (2) corresponds to a complete attribute with an empty set of values. There are two more cases: an incomplete attribute with a non-empty set of values, and a complete attribute with a non-empty set of values. In reality, we don't have these complete/incomplete markers, so what we are really talking about is whether we are to assume that an attribute is complete or incomplete, in the absence of such indicators. The 4th edition of X.511 treats an absent attribute as incomplete and a present attribute as complete, which strikes me as inconsistent and leads to some weird outcomes. Why should it be that if I add one known value to a multi-valued attribute, it can suddenly mean that there are no other unknown values ? Or the converse, if I remove one known value, that it can suddenly mean there are now some unknown values as well. For example, if the telephoneNumber attribute in a particular entry has the value "+61 3 9999 9999" and I ask for: (!(telephoneNumber=+61 3 8888 8888)) I will get the entry back in the search result. If the telephoneNumber value "+61 3 9999 9999" is removed, the entry is no longer returned by the search filter, though the status of the entry with respect to the particular value "+61 3 8888 8888" hasn't changed. There are two consistent treatments: either assume every attribute (whether or not it is empty/absent) is complete, or assume every attribute is incomplete. The former implies that a filter item evaluates to FALSE if the attribute is not present. The latter implies that filter items evaluate to TRUE or UNDEFINED (never FALSE) for multi-valued attributes that are present. My expectation is that most users will unconsciously assume the former. Both of the consistent treatments have the property that adding or removing an unrelated value doesn't alter the outcome of a search. Regards, Steven > The assertion !(givenName=Bob) is therefore also UNDEFINED. > This is logical. > > I think you have been trying to apply heuristics. That is a > choice, but then > logic cannot be your guide. > > Ron. > > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Tuesday, 26 February 2002 15:08 > To: ietf-ldapbis@OpenLDAP.org > Subject: Filter Items and Absent Attributes > > > > Folks, > > A statement that is in the 4th edition of X.511, but not in the 2nd > edition, was recently brought to my attention. I found it surprising. > I suspect I not the only one. > > In X.511:2001, Clause 7.8.2: > > "An assertion" ... "evaluates to UNDEFINED if it relates to > an attribute > value and the attribute type is not present in an" [ entry > ] "against > which the assertion is being tested." > > This means, for example, that a filter item like > (givenName=Bob) evaluates > to UNDEFINED, rather than FALSE, if an entry doesn't have the > givenName > attribute. This affects how negated filter items are evaluated. > For example, the filter (!(givenName=Bob)) only returns entries > that have the givenName attribute, but not the givenName value "Bob". > The entries that don't have the givenName attribute are not returned > (giving the impression that they *do* have "Bob" as a givenName). > > Apparently this behaviour was the original intention in the > 2nd edition > of X.511 as well. It just wasn't explained properly. > > Personally, I think returning UNDEFINED instead of FALSE would be > counter-intuitive to most users, and therefore a bad idea. > > Does anyone's server implementation evaluate filter items to UNDEFINED > instead of FALSE when the attribute doesn't exist (obviously mine > doesn't) ? The answer determines how I apply access controls > to searches > in my I-D on X.500 Basic Access Control for LDAP. The current > specification > is based on the assumption that everyone else is returning FALSE too. > > If that is the case then we have to decide whether we want to define > LDAP searches to behave exactly like X.500 searches (and change our > implementations), or explicitly specify that LDAP behaves differently, > or influence the X.500 working group to change X.511. > > Regards, > Steven > From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 27 01:55:01 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04392 for ; Wed, 27 Feb 2002 01:54:59 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1R6qqS51097; Wed, 27 Feb 2002 06:52:52 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 27 Feb 2002 06:52:52 +0000 Received: from pretender.boolean.net (root@router.boolean.net [198.144.206.49]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1R6qpU51090 for ; Wed, 27 Feb 2002 06:52:51 GMT Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g1R6qjC81509; Wed, 27 Feb 2002 06:52:45 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.1.0.14.0.20020226221932.017d3560@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 26 Feb 2002 22:52:47 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: Filter Items and Absent Attributes Cc: "'Ramsay, Ron'" , In-Reply-To: <006301c1bf52$6e933850$a518200a@osmium.mtwav.adacel.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: I think a very strong case can be made that (foo=bar) should evaluate to False if foo is known, has an equality rule, the assertion value conforms to the assertion syntax, and the attribute (or its subtypes) does contain the value "bar". In particular, X.511(93), 7.8.2 details conditions for which any assertion about values is only defined. IMO, the assertion meets the conditions. 7.8.2 also states that filter items are evaluated as attribute value assertions. X.501(93) states: An AVA is: a) undefined, if any of the following hold: 1) the attribute type is unknown, 2) the attribute type has no equality matching rule, 3) the value does not conform to the data type indicated by the syntax of the assertion of the attribute’s equality matching rule; b) true, if the entry contains an attribute of that type, one of whose values matches that value; c) false, otherwise. It appears that most server implementations in accordance with this interpretation and not the 4th edition. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 27 02:03:20 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05627 for ; Wed, 27 Feb 2002 02:03:20 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1R71O051416; Wed, 27 Feb 2002 07:01:24 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 27 Feb 2002 07:01:24 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1R71LU51407 for ; Wed, 27 Feb 2002 07:01:22 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Wed, 27 Feb 2002 18:01:11 +1100 Message-ID: From: "Ramsay, Ron" To: steven.legg@adacel.com.au Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Filter Items and Absent Attributes Date: Wed, 27 Feb 2002 18:01:08 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Steven, I believe the X.500 take is, can the question foo=bar be answered. If the entry doesn't contain the attribute foo, the question cannot be answered. The entry may not contain the attribute because, possibly, the attribute is optional or not allowed by schema. The question cannot be answered. It is a bit metaphysical to refer to the collection of all possible answers, the practical approach is not to try to answer the question. If I try to find everyone with a shoe size of 12, and Bob doesn't have a shoe size attribute in his entry, shoudl I return Bob's entry? You say no and I fail to be convinced. The only time 'no' is appropriate is if Bob's shoe size has actually been entered into the directory. You can't say that Bob doesn't have a shoe size just because it is not in his entry, you can only say "don't know." Ron. -----Original Message----- From: Steven Legg [mailto:steven.legg@adacel.com.au] Sent: Wednesday, 27 February 2002 16:49 To: Ramsay, Ron Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Filter Items and Absent Attributes Ron, Ramsay, Ron wrote: > Our implementation treats it as UNDEFINED. > > It is counter-intuitive only in the same way that all logic > assertions seem > to defy logic. For example, an empty AND is TRUE. > > The logic must be: Can I evaluate givenName=Bob if there is > no givenName > attribute? The answer clearly is NO. Therefore, the assertion > is UNDEFINED. What is "clear" critically depends on how one models the entry contents and how one interprets the meaning of the assertions. I could model an entry's contents as a set of (type, value) tuples and the assertion (givenName=Bob) as the question "does the entry contain the tuple (givenName, Bob)?" If the givenName attribute is absent then the assertion is "clearly" FALSE. Such an interpretation is more in keeping with LDAP, where no distinction is drawn between adding an attribute and adding attribute values. Given that there are multi-valued attributes and attribute subtyping, we have a situation where the absence of an attribute could be interpreted two ways: (1) The value(s) of the attribute for the entity represented by the entry are not known. (2) There are no values of the attribute for the entity represented by the entry. For example, the absence of the telephoneNumber attribute could mean that the telephone numbers for the entity are not known, or it could mean that the entity doesn't have a phone (and hence no phone numbers). The X.500 model doesn't provide us with a way to distinguish between these two cases. For the sake of argument, let us suppose that we can provide a mark for each attribute type, whether the attribute is present or not, to indicate whether the existing set of values (possibly empty) is complete (all values are known) or incomplete (there may be other unknown values). Case (1) above corresponds to an incomplete attribute with an empty set of values. Case (2) corresponds to a complete attribute with an empty set of values. There are two more cases: an incomplete attribute with a non-empty set of values, and a complete attribute with a non-empty set of values. In reality, we don't have these complete/incomplete markers, so what we are really talking about is whether we are to assume that an attribute is complete or incomplete, in the absence of such indicators. The 4th edition of X.511 treats an absent attribute as incomplete and a present attribute as complete, which strikes me as inconsistent and leads to some weird outcomes. Why should it be that if I add one known value to a multi-valued attribute, it can suddenly mean that there are no other unknown values ? Or the converse, if I remove one known value, that it can suddenly mean there are now some unknown values as well. For example, if the telephoneNumber attribute in a particular entry has the value "+61 3 9999 9999" and I ask for: (!(telephoneNumber=+61 3 8888 8888)) I will get the entry back in the search result. If the telephoneNumber value "+61 3 9999 9999" is removed, the entry is no longer returned by the search filter, though the status of the entry with respect to the particular value "+61 3 8888 8888" hasn't changed. There are two consistent treatments: either assume every attribute (whether or not it is empty/absent) is complete, or assume every attribute is incomplete. The former implies that a filter item evaluates to FALSE if the attribute is not present. The latter implies that filter items evaluate to TRUE or UNDEFINED (never FALSE) for multi-valued attributes that are present. My expectation is that most users will unconsciously assume the former. Both of the consistent treatments have the property that adding or removing an unrelated value doesn't alter the outcome of a search. Regards, Steven > The assertion !(givenName=Bob) is therefore also UNDEFINED. > This is logical. > > I think you have been trying to apply heuristics. That is a > choice, but then > logic cannot be your guide. > > Ron. > > -----Original Message----- > From: Steven Legg [mailto:steven.legg@adacel.com.au] > Sent: Tuesday, 26 February 2002 15:08 > To: ietf-ldapbis@OpenLDAP.org > Subject: Filter Items and Absent Attributes > > > > Folks, > > A statement that is in the 4th edition of X.511, but not in the 2nd > edition, was recently brought to my attention. I found it surprising. > I suspect I not the only one. > > In X.511:2001, Clause 7.8.2: > > "An assertion" ... "evaluates to UNDEFINED if it relates to > an attribute > value and the attribute type is not present in an" [ entry > ] "against > which the assertion is being tested." > > This means, for example, that a filter item like > (givenName=Bob) evaluates > to UNDEFINED, rather than FALSE, if an entry doesn't have the > givenName > attribute. This affects how negated filter items are evaluated. > For example, the filter (!(givenName=Bob)) only returns entries > that have the givenName attribute, but not the givenName value "Bob". > The entries that don't have the givenName attribute are not returned > (giving the impression that they *do* have "Bob" as a givenName). > > Apparently this behaviour was the original intention in the > 2nd edition > of X.511 as well. It just wasn't explained properly. > > Personally, I think returning UNDEFINED instead of FALSE would be > counter-intuitive to most users, and therefore a bad idea. > > Does anyone's server implementation evaluate filter items to UNDEFINED > instead of FALSE when the attribute doesn't exist (obviously mine > doesn't) ? The answer determines how I apply access controls > to searches > in my I-D on X.500 Basic Access Control for LDAP. The current > specification > is based on the assumption that everyone else is returning FALSE too. > > If that is the case then we have to decide whether we want to define > LDAP searches to behave exactly like X.500 searches (and change our > implementations), or explicitly specify that LDAP behaves differently, > or influence the X.500 working group to change X.511. > > Regards, > Steven > From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 27 02:27:06 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12777 for ; Wed, 27 Feb 2002 02:27:05 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1R7PAj51827; Wed, 27 Feb 2002 07:25:10 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Wed, 27 Feb 2002 07:25:10 +0000 Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1R7P7U51807; Wed, 27 Feb 2002 07:25:08 GMT Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id ; Wed, 27 Feb 2002 18:24:58 +1100 Message-ID: From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , steven.legg@adacel.com.au Cc: ietf-ldapbis@OpenLDAP.org Subject: RE: Filter Items and Absent Attributes Date: Wed, 27 Feb 2002 18:24:56 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Kurt, It's there in black and white! I'm gobsmacked! Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Wednesday, 27 February 2002 17:53 To: steven.legg@adacel.com.au Cc: Ramsay, Ron; ietf-ldapbis@OpenLDAP.org Subject: RE: Filter Items and Absent Attributes I think a very strong case can be made that (foo=bar) should evaluate to False if foo is known, has an equality rule, the assertion value conforms to the assertion syntax, and the attribute (or its subtypes) does contain the value "bar". In particular, X.511(93), 7.8.2 details conditions for which any assertion about values is only defined. IMO, the assertion meets the conditions. 7.8.2 also states that filter items are evaluated as attribute value assertions. X.501(93) states: An AVA is: a) undefined, if any of the following hold: 1) the attribute type is unknown, 2) the attribute type has no equality matching rule, 3) the value does not conform to the data type indicated by the syntax of the assertion of the attribute's equality matching rule; b) true, if the entry contains an attribute of that type, one of whose values matches that value; c) false, otherwise. It appears that most server implementations in accordance with this interpretation and not the 4th edition. Kurt From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 27 20:36:15 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27519 for ; Wed, 27 Feb 2002 20:36:14 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1S1Xkn52383; Thu, 28 Feb 2002 01:33:46 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 28 Feb 2002 01:33:46 +0000 Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1S1XiU52376 for ; Thu, 28 Feb 2002 01:33:44 GMT Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 27 Feb 2002 18:33:12 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Wed, 27 Feb 2002 18:33:03 -0700 From: "Mark Hinckley" To: , , Cc: Subject: Re: Informational RFC to be: draft-fleming-ldap-printer-schema-01.txt(fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Not being sure which list to send any comments to, I chose the cheap way out with reply to all the original message was sent to. Reading the proposed schema brings the following issues to my mind (in order of importance): 1)Several of the attribute definitions have upper limits (I know that the LDAP standard says these are suggestions, but I know of at least one implementation that treats them as hard upper limits), and I question first of all why even have suggested upper limits. Some of these attributes contain specific values, and thus would probably be OK with the limits, but others, e.g. printer-info, contain arbitrary data, and that should not be set to such a low limit as 127. 2) All the names seem to go against standard ldap convention. All are of the form printer-word1-word2-word3. Convention in the ldap world would have the names be printerWord1Word2Word3 instead, without the '-' character. 3) Section 4.24 printer-resolution-supported. This defines a multi part field which is delimited with the '>' character. Typically, LDAP delimits fields with a '$' character. I would thing this attribute either a) deserves its own syntax (not my first choice), b) should be specified in three attributes rather than one, or c) should use a more standard delimiter. That said, any delimiter is legal here, so if there is good reason for the '>' delimiter, it could be used. Also, is the final delimiter necessary? Mark Hinckley >>> Patrik Fältström 02/20/02 10:54AM >>> Can some of you have a look at these and let me know what you think? paf ---------- Forwarded Message ---------- Date: onsdag 20 februari 2002 17.24 +0000 From: RFC Editor To: iesg@ietf.org Subject: Informational RFC to be: draft-fleming-ldap-printer-schema-01.txt IESG, This RFC-to-be was submitted to the RFC Editor to be published as Informational: draft-fleming-ldap-printer-schema-01.txt. Four week timeout is initiated (20 March 2002). LDAP Schema for Printer Services This document provides information for the Internet community. It does not specify an Internet standard of any kind. This document defines an LDAP schema, object classes and attributes, for printers and printer services, for use with directories that support Lightweight Directory Access Protocol (LDAPv3) [RFC2251]. This document is based on the printer attributes listed in Appendix E of Internet Printing Protocol (IPP/1.1) [RFC2911], the Service Location Protocol (SLPv2) [RFC2608] 'service:printer:' template defined in [SLPPRT], and the mapping between SLP service advertisements and LDAP descriptions of services defined in [RFC2926]. ** Please note that the RFC Editor intends to expand "LDAP" in the title if this document is accepted for publication as an RFC. Sincerely, Sandy Ginoza - USC/ISI Request for Comments Documents Voice: (310) 822-1511 x89369 Fax: (310) 823-6714 EMAIL: RFC-ED@RFC-EDITOR.ORG ---------- End Forwarded Message ---------- From owner-ietf-ldapbis@OpenLDAP.org Wed Feb 27 21:14:15 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28558 for ; Wed, 27 Feb 2002 21:14:14 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1S2CDn53990; Thu, 28 Feb 2002 02:12:13 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 28 Feb 2002 02:12:13 +0000 Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1S2CAU53969 for ; Thu, 28 Feb 2002 02:12:10 GMT Received: (qmail 9095 invoked from network); 28 Feb 2002 02:12:31 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 28 Feb 2002 02:12:31 -0000 Reply-To: From: "Steven Legg" To: "'Kurt D. Zeilenga'" Cc: Subject: RE: Filter Items and Absent Attributes Date: Thu, 28 Feb 2002 13:10:47 +1100 Message-ID: <007c01c1bffd$23432a80$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <5.1.0.14.0.20020226221932.017d3560@127.0.0.1> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kurt, Nice pick up! Kurt D. Zeilenga wrote: > I think a very strong case can be made that (foo=bar) should > evaluate to False if foo is known, has an equality rule, > the assertion value conforms to the assertion syntax, and > the attribute (or its subtypes) does contain the value "bar". I think you left a "not" out. > > In particular, X.511(93), 7.8.2 details conditions for which > any assertion about values is only defined. IMO, the > assertion meets the conditions. 7.8.2 also states that > filter items are evaluated as attribute value assertions. > X.501(93) states: It is clause 8.7.2 in my copy of X.501(93). Given the absence of anything in the description of Filter in X.511(93) that contradicts 8.7.2, I think the obvious conclusion is that the second edition of X.500 specifies that a filter item evaluates to FALSE if the attribute is not present. > > An AVA is: > a) undefined, if any of the following hold: > 1) the attribute type is unknown, > 2) the attribute type has no equality matching rule, > 3) the value does not conform to the data type indicated > by the syntax of the assertion of the attribute's > equality matching rule; > b) true, if the entry contains an attribute of that type, > one of whose values matches that value; > c) false, otherwise. > > It appears that most server implementations in accordance > with this interpretation and not the 4th edition. I've had a look at the corresponding clause in X.501(93), 8.8.2, and apart from some extra guff about contexts, it says the same thing, which means that X.501(2001) and X.511(2001) contradict each other! It looks like the X.500 working group has some cleaning up to do. Regards, Steven From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 28 11:22:13 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01425 for ; Thu, 28 Feb 2002 11:22:13 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g1SGHbg04638; Thu, 28 Feb 2002 16:17:38 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Thu, 28 Feb 2002 16:17:37 +0000 Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with ESMTP id g1SGHaU04627 for ; Thu, 28 Feb 2002 16:17:36 GMT Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 28 Feb 2002 09:17:02 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Thu, 28 Feb 2002 09:13:23 -0700 From: "Jim Sermersheim" To: Subject: Teletex Terminal Identifier in draft-ietf-ldapbis-syntaxes-01 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This syntax has the encoding: teletex-id = ttx-term 0*("$" ttx-param) where ttx-param ends in an octetstring. Some escapment policy must be noted regarding the occurance of %0x24 in the octetstring (due to the $ delimiter). It probably would have been easier if ttx-param was defined as: ttx-param = ttx-key ":" ttx-value-len ":" ttx-value but I think we're beyond going back and changing it. Jim From owner-ietf-ldapbis@OpenLDAP.org Thu Feb 28 23:14:00 2002 Received: from galois.openldap.org (root@galois.openldap.org [204.152.186.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03099 for ; Thu, 28 Feb 2002 23:13:59 -0500 (EST) Received: from localhost (majordomo@localhost) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g214Baa37470; Fri, 1 Mar 2002 04:11:36 GMT Received: by OpenLDAP.org (bulk_mailer v1.12); Fri, 1 Mar 2002 04:11:36 +0000 Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by galois.openldap.org (8.10.0.Beta10/8.10.0.Beta10/OpenLDAP/Hub) with SMTP id g214BXU37407 for ; Fri, 1 Mar 2002 04:11:33 GMT Received: (qmail 10672 invoked from network); 1 Mar 2002 04:11:40 -0000 Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 1 Mar 2002 04:11:40 -0000 Reply-To: From: "Steven Legg" To: "'Jim Sermersheim'" Cc: Subject: RE: Teletex Terminal Identifier in draft-ietf-ldapbis-syntaxes-01 Date: Fri, 1 Mar 2002 15:10:00 +1100 Message-ID: <007401c1c0d6$f565fa40$a518200a@osmium.mtwav.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-ldapbis@OpenLDAP.org Priority: non-urgent X-Loop: OpenLDAP Precedence: bulk Comment: ietf-ldapbis mailing list List-Archive: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim, Jim Sermersheim wrote: > This syntax has the encoding: > teletex-id = ttx-term 0*("$" ttx-param) > where ttx-param ends in an octetstring. > > Some escapment policy must be noted regarding the occurance of %0x24 in > the octetstring (due to the $ delimiter). It probably would have been > easier if ttx-param was defined as: > ttx-param = ttx-key ":" ttx-value-len ":" ttx-value > > but I think we're beyond going back and changing it. The rule isn't actually defined anywhere so we're free to define it to be something sensible. I suggest we make it a hexadecimal string. Note that the 4th edition of X.500 has deprecated this syntax. The X.500 working group has even gone to the extent of removing the teletexTerminalIdentifier attribute from every object class that used to reference it. An option for us is to throw it out too. Regards, Steven