From list@netscape.com Sun Apr 1 00:06:48 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17958 for ; Sun, 1 Apr 2001 00:06:46 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3156WS05473; Sat, 31 Mar 2001 21:06:32 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3156Xw29035; Sat, 31 Mar 2001 21:06:33 -0800 (PST) Resent-Date: Sat, 31 Mar 2001 21:06:33 -0800 (PST) Message-Id: <5.0.2.1.2.20010331205115.00a6ad80@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 31 Mar 2001 21:04:11 -0800 To: Rob Weltman From: Bruce Greenblatt Subject: Re: LDAP Enhancement Style Guide Cc: ietf-ldapext@netscape.com In-Reply-To: <3AC6528B.1CABF9EA@coscend.com> References: <5.0.2.1.2.20010330164511.00a68b40@pop.walltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"Xz8zz.A.RFH.Ydrx6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 01:56 PM 3/31/2001 -0800, Rob Weltman wrote: >Bruce Greenblatt wrote: > > > > I have been requested to publish an update of this draft. So, attached is > > an update of my "LDAP Enhancement Style Guide" internet draft. Please > > publish it as an update to draft-greenblatt-ldapextstyle-00.txt. Several > > comments were received on the previous edition, and have been > > incorporated. Many thanks to those who responded, especially Kurt > Z! Thanks, > > > > Bruce Greenblatt > > Interesting about control extensibility. My first draft on the proxy > auth control didn't include extensibility hooks. It only specified the > fields required by the control as conceived. A couple of people suggested > that perhaps in the future it could be extended to passing other > credential fields, so I changed its value contents to a SEQUENCE in the > second revision. Then other people (well-known within LDAPEXT) said no, > that's wrong. An extension should result in a new control, rather than > additional fields in an existing control. So a subsequent revision > reverted to just specifying a single non-extensible credentials field. OK. If you allow for new fields in the control, and the meaning of the control doesn't change, why should you have to get a new OID and a new control. I think that it is appropriate to allow for future extensibility. If the client puts a field in a control that the server doesn't know about, how is that any different than the client putting a control in an operation that the server doesn't know about? > Your draft says: > >"The definition of a control SHOULD be defined in such a manner that >it is extensible. For extensibility, extra binary fields SHOULD be >built into the definition. In ASN.1, use of a SEQUENCE is helpful." > > Has there been a change in the opinion generally among the LDAP > luminaries on extensibility in controls, or are the opinions strongly > divergent? Probably the latter, if past experience is any judgement. In any case, it's only my opinion, and it's only a SHOULD. I'm sure that there are some situations in which the allowance for extensibility is inappropriate. That's why its a SHOULD and not a MUST. >Rob > > > > > > ============================================== > > Bruce Greenblatt, Ph. D. > > Directory Tools and Application Services, Inc. > > http://www.directory-applications.com > > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Name: ldapstyleguide.out > > ldapstyleguide.out Type: Plain Text (text/plain) > > Encoding: base64 ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Sun Apr 1 01:13:26 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02667 for ; Sun, 1 Apr 2001 01:13:25 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f316DIv01956; Sat, 31 Mar 2001 22:13:18 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f316DJc10069; Sat, 31 Mar 2001 22:13:19 -0800 (PST) Resent-Date: Sat, 31 Mar 2001 22:13:19 -0800 (PST) Message-ID: <3AC6C82E.B9696B6F@coscend.com> Date: Sat, 31 Mar 2001 22:18:22 -0800 From: Rob Weltman X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: Bruce Greenblatt CC: ietf-ldapext@netscape.com Subject: Re: LDAP Enhancement Style Guide References: <5.0.2.1.2.20010330164511.00a68b40@pop.walltech.com> <5.0.2.1.2.20010331205115.00a6ad80@pop.walltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"MLLdJD.A.9cC.-bsx6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Bruce Greenblatt wrote: > > > Interesting about control extensibility. My first draft on the proxy > > auth control didn't include extensibility hooks. It only specified the > > fields required by the control as conceived. A couple of people suggested > > that perhaps in the future it could be extended to passing other > > credential fields, so I changed its value contents to a SEQUENCE in the > > second revision. Then other people (well-known within LDAPEXT) said no, > > that's wrong. An extension should result in a new control, rather than > > additional fields in an existing control. So a subsequent revision > > reverted to just specifying a single non-extensible credentials field. > > OK. If you allow for new fields in the control, and the meaning of the > control doesn't change, why should you have to get a new OID and a new > control. I think that it is appropriate to allow for future > extensibility. If the client puts a field in a control that the server > doesn't know about, how is that any different than the client putting a > control in an operation that the server doesn't know about? I agree in principle, but in practice I think it varies. How is a client to know if the server understands the additional field? A client can check if a server supports a particular control by OID by reading the root DSE, but there is no way to check for a version of a control. In some cases it's OK; for example the field might indicate that the client wants the server to return some additional information besides the response implied by the "base" control fields, it can check the response to see if the additional info is there, and it doesn't matter much if it's not there. But in other cases it would not be acceptable - e.g. the operation is useless or worse to the client if the server doesn't understand the new field, or the client can't tell from the response if the server took the additional field into account or not. Rob From list@netscape.com Sun Apr 1 13:22:59 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29354 for ; Sun, 1 Apr 2001 13:22:59 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f31HMpv28558; Sun, 1 Apr 2001 10:22:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f31HMrk26491; Sun, 1 Apr 2001 10:22:53 -0700 (PDT) Resent-Date: Sun, 1 Apr 2001 10:22:53 -0700 (PDT) Message-Id: <5.0.2.1.2.20010401101939.00a63b20@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sun, 01 Apr 2001 10:20:35 -0700 To: Rob Weltman From: Bruce Greenblatt Subject: Re: LDAP Enhancement Style Guide Cc: ietf-ldapext@netscape.com In-Reply-To: <3AC6C82E.B9696B6F@coscend.com> References: <5.0.2.1.2.20010330164511.00a68b40@pop.walltech.com> <5.0.2.1.2.20010331205115.00a6ad80@pop.walltech.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"Qb6bCB.A.UdG.rP2x6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 10:18 PM 3/31/2001 -0800, Rob Weltman wrote: > I agree in principle, but in practice I think it varies. How is a > client to know if the server understands the additional field? A client > can check if a server supports a particular control by OID by reading the > root DSE, but there is no way to check for a version of a control. In > some cases it's OK; for example the field might indicate that the client > wants the server to return some additional information besides the > response implied by the "base" control fields, it can check the response > to see if the additional info is there, and it doesn't matter much if > it's not there. But in other cases it would not be acceptable - e.g. the > operation is useless or worse to the client if the server doesn't > understand the new field, or the client can't tell from the response if > the server took the additional field into account or not. You make good points. I still think that it should be a SHOULD. I will add your arguments to the next revision. >Rob ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Sun Apr 1 20:22:46 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01938 for ; Sun, 1 Apr 2001 20:22:45 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f320MZv18112; Sun, 1 Apr 2001 17:22:35 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f320McM11984; Sun, 1 Apr 2001 17:22:38 -0700 (PDT) Resent-Date: Sun, 1 Apr 2001 17:22:38 -0700 (PDT) Date: Tue, 27 Feb 2001 06:14:18 +0200 From: Message-Id: <200102270414.GAA17954@absasecurities.co.za> To: cbltvdscrmblrs@yahoo.de Subject: 100% LEGAL WAY TO GET EVERY CABLE CHANNEL! SAVE $$$ ON YOUR CABLE BILL MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Resent-Message-ID: <"oK8pHD.A.26C.MZ8x6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com HOTTEST New Universal Cable Descrambler!!! The GLOBAL 2600 100% LEGAL WAY TO GET EVERY CABLE CHANNEL!!! Are you tired of paying the cable company to rent you a cable converter? Then why continue to pay them when you can own your own LEGALLY? With recent advances in technology it is now cheaper and easier to buy your own descrambler and never have to rent a converter again. Our Global Universal Cable Descrambler works with 99% of all cable companies and it is 100% Bullet Proof so it will never get deprogrammed by your cable company. This ALL IN ONE UNIT is so UNIVERSAL that if you move, it moves with you. YOU WILL NEVER HAVE TO RENT OR BUY ANOTHER CONVERTER/DESCRAMBLER AGAIN! We are so sure that you will love our product that it comes with a NO QUESTIONS ASKED 30 DAY MONEY BACK GUARANTEE! Global 2600 $269 Includes UPS 2-Day delivery! Quantity Discounts are available so please ask. If you have questions, comments or want to place an order please call 1-888-339-8137 ****************************************** * This is a one-time mailing. No future * * emails will be sent to you from our * * organization. No request for removal * * is necessary. * ****************************************** From list@netscape.com Sun Apr 1 21:06:29 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09626 for ; Sun, 1 Apr 2001 21:06:28 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3216Jv20646; Sun, 1 Apr 2001 18:06:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3216MU21897; Sun, 1 Apr 2001 18:06:22 -0700 (PDT) Resent-Date: Sun, 1 Apr 2001 18:06:22 -0700 (PDT) From: cerri@hotmail.com To: majto@selectedfriends.netscape.com Reply-To: t2m49@bigfoot.com Subject: Making Serious Money Has Never Been This Easy! [fnpmz] Message-Id: <9a5fb4132a90eb8292765564b2124d953ac7d106@> Date: Sun, 1 Apr 2001 20:08:25 -0500 Resent-Message-ID: <"8FKwCC.A.xVF.NC9x6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com NEW CD ROM is helping to Create HUGE FORTUNES!! Free Info directly from a self-Made $40,000/Mo. earner * What if you could make a full time income handing/sending out a $1.25 CD ROM? * What if the company paid you EVERY DAY? * What if it was a New York Stock Exchange Company? * What if there was no "real" competition, and everybody needs our service? * What if you got paid when somebody goes to your website and views the hottest video presentation ever and signs up? If you are the least bit curious about why this CD ROM is making us Fortunes!! All you need to do is simply: 1.Send an email to: mailto:t2m37@bigfoot.com?subject=CD_ROM 2. Put " CD ROM " in the subject heading We will email you all you need to know to get signed up and making money TODAY!!! Waiting to hear from you soon! Greg From list@netscape.com Mon Apr 2 13:09:15 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21146 for ; Mon, 2 Apr 2001 13:09:14 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f32H94S08140; Mon, 2 Apr 2001 10:09:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f32H94A00085; Mon, 2 Apr 2001 10:09:04 -0700 (PDT) Resent-Date: Mon, 2 Apr 2001 10:09:04 -0700 (PDT) Message-Id: <5.0.2.1.0.20010402113009.00a77a98@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 12:08:49 -0500 To: rvh@qsun.mt.att.com (Richard V Huber), ietf-ldapext@netscape.com From: Ellen Stokes Subject: Re: Comments on Access Control Model - authentication levels In-Reply-To: <200103291856.NAA00957@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"KZuN9C.A.6.vILy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com There have been many notes on authentication levels. This response addresses those notes. Below is the BNF. In section 4.2.3 I'll incorporate the following points below. In the Security Considerations section I'll note that ipAddresses are easily forged (as stated in requirement S6), but that it is an accepted though non-secure practice. Ranges of ipaddress are not supported, but wild-carded dns names are for the most-specific part of the name. I've incorporated authentication definitions from LDAP and X.500 as noted below. Instead of hiding domain and wild-carded domain names with ipAddress, I've surface them as a subject (see below). Only the left-most (most specific) part of the dns name can be wild-carded. There are 4 authn levels: non, anonymous, simple, and sasl, and 2 groupings: unauthn and authn. If authnLevel is omitted in the access control information, authnLevel defaults to 'authn'. authnLevel only makes sense to be applied to certain subjects (see below). I've omitted(for brevity) in this email the BNF expansion of IPv6address (taken from RFC 2373) since it did not change. subject = ([ "authnLevel:" authnLevel ":" ] ( "authzID-" authzID ) / ( "role:" dn ) / ( "group:" dn ) / ( "subtree:" dn ) / "this:" ) / ( "ipAddress:" ipAddress ) / ( "dns:" [ "*." ] domainname ) / "public:" authnLevel = "none" / ; from X.500: name but no password, same as LDAPBIS unauthenticated "anonymous" / ; from LDAP: no name and no password "simple" / ; from LDAP: name and password sasl / ; from LDAP "unauthn" / ; groups none + anonymous "authn" ; groups simple or sasl, this is the default is authnLevel is omitted sasl = "sasl:" ("any" / mechanism) mechanism = ' sasl mechanism from 4.2 of [LDAPv3] ipAddress = IPv6address domainname = domaincomponent *( "." domaincomponent ) domaincomponent = ALPHA [ *61( ALPHA / DIGIT / "-" ) ( ALPHA / DIGIT )] Ellen At 01:56 PM 3/29/2001 -0500, Richard V Huber wrote: >The BNF allows the authentication level to be omitted from ACI. It >also allows specification of "none" and "any". > >Section 4.2.3 explains the difference between omitting the >specification and using "any", but it does not explain "none". I >suggest "none" be removed from the BNF. > >Section 4.2.3 also says "For permission to be granted, the subject must >have been authenticated to at least the level specified, but that if >the right is a deny, then everyone is denied access unless they have >been authenticated to at least the level specified in authnLevel." > >I think we will have a lot of problems trying to agree on a >well-ordering of authnLevels. I suggest we remove the parts about "at >least the level specified". I also feel the part about "... then >everyone is denied access unless ..." is unclear. > >Can we just say "For permission to be granted, the subject must have >been authenticated to the level specified." > >Rick Huber From list@netscape.com Mon Apr 2 14:37:15 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25328 for ; Mon, 2 Apr 2001 14:37:10 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f32Ia0S27899; Mon, 2 Apr 2001 11:36:00 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f32Ia1U00392; Mon, 2 Apr 2001 11:36:01 -0700 (PDT) Resent-Date: Mon, 2 Apr 2001 11:36:01 -0700 (PDT) Date: Mon, 2 Apr 2001 14:35:43 -0400 Message-Id: <200104021835.OAA22992@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldapbis@openldap.org, ietf-ldapext@netscape.com, stokes@austin.ibm.com Subject: Re: Comments on Access Control Model - authentication levels Resent-Message-ID: <"flvlO.A.pF.PaMy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I'm copying this to the LDAPBIS list since one of the comments in the Ellen's new BNF points out something that may be of interest. The specification of "none" as an authorization level comes from X.501. The X.501 4th edition draft says (section 18.4.2.3): For access control purposes, the "simple" authentication level requires a password; the case of identification only, with no password supplied, is considered "none". This is relevant to the discussion we had in Minneapolis concerning "anonymous" vs. "unauthorized". It seems to give support to the idea that they are NOT the same thing. Rick Huber : From stokes@austin.ibm.com Mon Apr 2 13:08:58 2001 : Return-Path: : X-Sender: stokes@popmail2.austin.ibm.com : To: rvh@qsun.mt.att.com (Richard V Huber), ietf-ldapext@netscape.com : From: Ellen Stokes : Subject: Re: Comments on Access Control Model - authentication levels : Mime-Version: 1.0 : : There have been many notes on authentication levels. This response : addresses those notes. : Below is the BNF. In section 4.2.3 I'll incorporate the following points : below. In the Security : Considerations section I'll note that ipAddresses are easily forged (as : stated in requirement : S6), but that it is an accepted though non-secure practice. Ranges of : ipaddress are not : supported, but wild-carded dns names are for the most-specific part of the : name. : : I've incorporated authentication definitions from LDAP and X.500 as noted : below. : Instead of hiding domain and wild-carded domain names with ipAddress, I've : surface : them as a subject (see below). Only the left-most (most specific) part of : the dns : name can be wild-carded. : There are 4 authn levels: non, anonymous, simple, and sasl, and 2 : groupings: unauthn and : authn. If authnLevel is omitted in the access control information, : authnLevel defaults to 'authn'. : authnLevel only makes sense to be applied to certain subjects (see below). : I've omitted(for brevity) in this email the BNF expansion of IPv6address : (taken from : RFC 2373) since it did not change. : : : subject = ([ "authnLevel:" authnLevel ":" ] : ( "authzID-" authzID ) / : ( "role:" dn ) / : ( "group:" dn ) / : ( "subtree:" dn ) / : "this:" ) / : ( "ipAddress:" ipAddress ) / : ( "dns:" [ "*." ] domainname ) / : "public:" : : authnLevel = "none" / ; from X.500: name but no password, : same as LDAPBIS unauthenticated : "anonymous" / ; from LDAP: no name and no password : "simple" / ; from LDAP: name and password : sasl / ; from LDAP : "unauthn" / ; groups none + anonymous : "authn" ; groups simple or sasl, this : is the default is authnLevel is omitted : : sasl = "sasl:" : ("any" / : mechanism) : : mechanism = ' sasl mechanism from 4.2 of [LDAPv3] : : ipAddress = IPv6address : : domainname = domaincomponent *( "." domaincomponent ) : : domaincomponent = ALPHA [ *61( ALPHA / DIGIT / "-" ) ( ALPHA / DIGIT )] : : : Ellen : : : : At 01:56 PM 3/29/2001 -0500, Richard V Huber wrote: : >The BNF allows the authentication level to be omitted from ACI. It : >also allows specification of "none" and "any". : > : >Section 4.2.3 explains the difference between omitting the : >specification and using "any", but it does not explain "none". I : >suggest "none" be removed from the BNF. : > : >Section 4.2.3 also says "For permission to be granted, the subject must : >have been authenticated to at least the level specified, but that if : >the right is a deny, then everyone is denied access unless they have : >been authenticated to at least the level specified in authnLevel." : > : >I think we will have a lot of problems trying to agree on a : >well-ordering of authnLevels. I suggest we remove the parts about "at : >least the level specified". I also feel the part about "... then : >everyone is denied access unless ..." is unclear. : > : >Can we just say "For permission to be granted, the subject must have : >been authenticated to the level specified." : > : >Rick Huber From list@netscape.com Mon Apr 2 14:53:11 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26063 for ; Mon, 2 Apr 2001 14:53:10 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f32IpYv00885; Mon, 2 Apr 2001 11:51:34 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f32IpYI12781; Mon, 2 Apr 2001 11:51:34 -0700 (PDT) Resent-Date: Mon, 2 Apr 2001 11:51:34 -0700 (PDT) Message-Id: <5.0.2.1.0.20010402114624.00aa23d0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 11:53:14 -0700 To: Ellen Stokes From: "Kurt D. Zeilenga" Subject: Re: Comments on Access Control Model - authentication levels Cc: rvh@qsun.mt.att.com (Richard V Huber), ietf-ldapext@netscape.com In-Reply-To: <5.0.2.1.0.20010402113009.00a77a98@popmail2.austin.ibm.com> References: <200103291856.NAA00957@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"DKkwlB.A.AHD.0oMy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:08 PM 4/2/01 -0500, Ellen Stokes wrote: > domaincomponent = ALPHA [ *61( ALPHA / DIGIT / "-" ) ( ALPHA / DIGIT )] note that domain components have been allowed to start with digits for quite some time... domaincomponent = (ALPHA/DIGIT) [ *61(ALPHA/DIGIT/HYPHEN) (ALPHA/DIGIT) ] IIRC, hyphens are still restricted. From list@netscape.com Mon Apr 2 15:29:59 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26904 for ; Mon, 2 Apr 2001 15:29:59 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f32JTGv08257; Mon, 2 Apr 2001 12:29:16 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f32JTGg11487; Mon, 2 Apr 2001 12:29:16 -0700 (PDT) Resent-Date: Mon, 2 Apr 2001 12:29:16 -0700 (PDT) Message-Id: <5.0.2.1.0.20010402121631.00ab6560@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 12:31:02 -0700 To: rvh@qsun.mt.att.com (Richard V Huber) From: "Kurt D. Zeilenga" Subject: Re: Comments on Access Control Model - authentication levels Cc: ietf-ldapbis@openldap.org, ietf-ldapext@netscape.com, stokes@austin.ibm.com In-Reply-To: <200104021835.OAA22992@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id f32JTEf11457 Resent-Message-ID: <"l0p6yC.A.HzC.KMNy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id f32JTGv08257 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA26904 I note that in the 2nd edition, the word 'unauthenticated' only appears once in X.501 as part of the non-normative Appendix K. PF-2: General Public access may be unauthenticated, but an identity must be presented. The word 'anonymous' does not appear at all. At 02:35 PM 4/2/01 -0400, Richard V Huber wrote: >I'm copying this to the LDAPBIS list since one of the comments in the >Ellen's new BNF points out something that may be of interest. The >specification of "none" as an authorization level comes from X.501. > >The X.501 4th edition draft says (section 18.4.2.3): > > For access control purposes, the "simple" authentication level > requires a password; the case of identification only, with no > password supplied, is considered "none". > >This is relevant to the discussion we had in Minneapolis concerning >"anonymous" vs. "unauthorized". It seems to give support to the idea >that they are NOT the same thing. A little more (from X.501, 2nd edition, 16.4.2.3 AuthenticationLevel: AuthenticationLevel defines the minimum requestor authentication level required for this ACIItem. It has two forms: – basicLevels which indicates the level of authentication, optionally qualified by positive or negative integer localQualifier; – other – an externally defined measure. When basicLevels is used, an AuthenticationLevel consisting of a level and optional localQualifier shall be assigned to the requestor by the DSA according to local policy. For a requestor’s authentication level to exceed a minimum requirement, the requestor’s level must meet or exceed that specified in the ACIItem, and in addition the requestor’s localQualifier must be arithmetically greater than or equal to that of the ACIItem. Strong authentication of the requestor is considered to exceed a requirement for simple or no authentication, and simple authentication exceeds a requirement for no authentication. For access control purposes, the “simple” authentication level requires a password; the case of identification only, with no password supplied, is considered “none”. Note the absence of an "anonymous" authentication level. This implies to me that for the purposes of access control, "no authentication" and "anonymous authentication" are both authentication level "none". Kurt From list@netscape.com Mon Apr 2 15:37:53 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27115 for ; Mon, 2 Apr 2001 15:37:52 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f32Jaxv09970; Mon, 2 Apr 2001 12:36:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f32JaxY16331; Mon, 2 Apr 2001 12:36:59 -0700 (PDT) Resent-Date: Mon, 2 Apr 2001 12:36:59 -0700 (PDT) Message-Id: <5.0.2.1.0.20010402143620.00b14658@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 14:36:39 -0500 To: "Kurt D. Zeilenga" From: Ellen Stokes Subject: Re: Comments on Access Control Model - authentication levels Cc: rvh@qsun.mt.att.com (Richard V Huber), ietf-ldapext@netscape.com In-Reply-To: <5.0.2.1.0.20010402114624.00aa23d0@127.0.0.1> References: <5.0.2.1.0.20010402113009.00a77a98@popmail2.austin.ibm.com> <200103291856.NAA00957@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"kBsY0D.A.q9D.XTNy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com OK, so noted and updated in the BNF. Ellen At 11:53 AM 4/2/2001 -0700, Kurt D. Zeilenga wrote: >At 12:08 PM 4/2/01 -0500, Ellen Stokes wrote: > > domaincomponent = ALPHA [ *61( ALPHA / DIGIT / "-" ) ( ALPHA / DIGIT )] > >note that domain components have been allowed to start with >digits for quite some time... > > domaincomponent = (ALPHA/DIGIT) [ *61(ALPHA/DIGIT/HYPHEN) (ALPHA/DIGIT) ] > >IIRC, hyphens are still restricted. From list@netscape.com Mon Apr 2 17:21:18 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01704 for ; Mon, 2 Apr 2001 17:21:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f32LL8v28578; Mon, 2 Apr 2001 14:21:08 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f32LL7U05755; Mon, 2 Apr 2001 14:21:07 -0700 (PDT) Resent-Date: Mon, 2 Apr 2001 14:21:07 -0700 (PDT) Message-Id: <5.0.2.1.2.20010402141712.00a614c0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 02 Apr 2001 14:20:15 -0700 To: internet-drafts@ietf.org From: Bruce Greenblatt Subject: new application defined permissions draft Cc: ietf-ldapext@netscape.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_25316663==_" Resent-Message-ID: <"RA01cC.A.SYB.60Oy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=====================_25316663==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Please published the attached new draft. I have written this as a companion document to the ACL Model draft. Comments welcome. Bruce Greenblatt ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com --=====================_25316663==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="adp-00.txt" Content-Transfer-Encoding: quoted-printable LDAPEXT Working Group B. Greenblatt=20 Internet Draft Directory Tools and=20 Application=20 Services, Inc.=20 Document: April 2001=20 Category: Standards Track =20 =20 =20 Application Defined Permissions for LDAP=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026 [1]. =20 =20 Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of=20 six months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet- Drafts=20 as reference material or to cite them other than as "work in=20 progress." =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 =20 =20 1. Abstract=20 =20 In the current ACL Model draft [2], the kinds of permissions that an=20 LDAP server understands are limited to those defined in clause=20 4.1.1. Certain LDAP integrated applications need to store their own=20 Application Defined Permissions (ADP) as well. For example,=20 consider an application that allows users to perform several=20 different actions on various types of objects. Let's call these=20 objects foo objects, and the actions foo-1 through foo-n. None of=20 these correspond to the add, delete, export, etc. permissions=20 defined in clause 4.1.1. The application should be able to have a=20 ACI assigned to an entry that represents a foo object that grants=20 permissions to perform some foo-i actions to some list of subject=20 entries (i.e. users, groups, organizationalUnits, domainContexts,=20 etc.). =20 =20 These permissions can=92t be granted with the mechanisms currently=20 defined in the ACL Model draft. This would require a new permission=20 level, but it is not appropriate to shoe-horn this in to the BNF of=20 4.1.1 or the ASN.1 of 4.1.2. This draft will define new LDAP Schema=20 information for holding the application defined permissions, and=20 =20 Greenblatt Standards Track =96 Expires October 2001 1=20 =0C Application Defined Permissions for LDAP April 2001=20 =20 =20 show how the mechanism of the ACL Model can be used with these new=20 schema elements.=20 =20 In addition to granting rights, the applications also need to be=20 able to verify that a subject entry has the appropriate rights to=20 perform an operation against a specified object. This should work=20 as defined in the existing model. The effective rights control or=20 extended operation will work for this. The application also would=20 like to be able to find all of the entries in a specified scope to=20 which a specified user has permission to perform action foo. =20 =20 This draft provides new definitions which build upon those in the=20 ACL Model draft that allow for application defined permissions in=20 addition to the system defined permissions of the ACL Model. This=20 draft should only be read after reading [2], as it builds on the=20 definitions and concepts defined there.=20 =20 2. Conventions used in this document=20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [3].=20 =20 =20 3. Schema for Application Defined Permissions=20 =20 Servers that support ADPs MUST advertise their support by placing=20 the following object identifier in the=20 =93supportedAccessControlSchemes=94 attribute of the root DSE:=20 =20 1.3.6.1.4.1.5515.3.1=20 =20 If an LDAP Server supports ADPs, the above OID MUST be specified as=20 a value in the accessControlSchemes attribute of the ldapACISubEntry=20 entry in naming contexts as appropriate.=20 =20 1.3.6.1.4.1 has been assigned as IANA-registered Private=20 Enterprises, and IANA has assigned 5515 to Directory Tools and=20 Application Services, Inc. (DTASI).=20 =20 1.3.6.1.4.1.5515.3 is the root OID for specified attribute values. =20 =20 3.1 The Application Defined Access Control Information Attributes=20 =20 The application defined access control information attributes,=20 applicationDefinedEntryACI and applicationDefinedSubtreeACI are=20 defined as:=20 =20 ( 1.3.6.1.4.1.5515.2.9 NAME 'applicationDefinedEntryACI' SUP=20 'entryACI' ) =20 =20 ( 1.3.6.1.4.1.5515.2.10 NAME 'applicationDefinedSubtreeACI' SUP=20 'subtreeACI' ) =20 Greenblatt Standards Track 2=20 =0C Application Defined Permissions for LDAP April 2001=20 =20 =20 =20 3.1.1 The BNF=20 =20 Here's the BNF for permissions to include application defined=20 permissions. Values of this syntax use BNF encoding conventions=20 described in [4]. This is a slightly modified version of the BNF=20 defined in [2].=20 =20 applicationDefinedEntryACI =3D rights "#" attr "#" subject=20 =20 applicationDefinedSubtreeACI =3D rights "#" attr "#" subject=20 =20 rights =3D (("grant:" / "deny:") permissions) /=20 ("grant:" permissions ";deny:" permissions)=20 =20 permissions =3D ([permission ("," permission)*])=20 =20 permission =3D oidstring ; application defined permission=20 =20 oidstring =3D digit ("." digit)*=20 =20 digit =3D "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"=20 =20 ; attr and subject are defined in [2]=20 =20 3.1.2 The ASN.1 Binary Format=20 =20 Here's the modified ASN.1 for permissions to include application=20 defined permissions. Thie following data type is used to represent=20 this syntax when transferred in binary form. This is a slightly=20 modified version of the ASN.1 defined in [2].=20 =20 =20 ApplicationDefinedEntryACI ::=3D SEQUENCE {=20 =20 rights SEQUENCE OF CHOICE {=20 grant [0] ApplicationDefinedPermissions,=20 deny [1] ApplicationDefinedPermissions},=20 attr CHOICE {=20 all [0] NULL,=20 entry [1] NULL,=20 attributes [2] SEQUENCE OF Attribute },=20 subject SEQUENCE {=20 authnLevel CHOICE {=20 any [0] NULL,=20 simple [1] NULL,=20 sasl [2] CHOICE {=20 any [0] NULL,=20 mechanism [1] LDAPString -- from [LDAPv3]=20 }=20 none [3] NULL,=20 anonymous [4] NULL=20 },=20 Greenblatt Standards Track 3=20 =0C Application Defined Permissions for LDAP April 2001=20 =20 =20 subjectName CHOICE {=20 dn [0] DN,=20 user [1] UTF8String=20 role [1] DN,=20 group [2] DN,=20 subtree [3] DN,=20 ipAddress [4] IPAddress,=20 public [6] NULL,=20 this [7] NULL }, } -- may be expanded=20 per [AuthMeth]=20 =20 ApplicationDefinedSubtreeACI ::=3D SEQUENCE {=20 =20 rights SEQUENCE OF CHOICE {=20 grant [0] ApplicationDefinedPermissions,=20 deny [1] ApplicationDefinedPermissions },=20 attr CHOICE {=20 all [0] NULL,=20 entry [1] NULL,=20 attributes [2] SEQUENCE OF Attribute },=20 subject SEQUENCE {=20 authnLevel CHOICE {=20 any [0] NULL,=20 simple [1] NULL,=20 sasl [2] CHOICE {=20 any [0] NULL,=20 mechanism [1] LDAPString -- from [LDAPv3]=20 }=20 none [3] NULL,=20 anonymous [4] NULL=20 },=20 subjectName CHOICE {=20 dn [0] DN,=20 user [1] UTF8String=20 role [1] DN,=20 group [2] DN,=20 subtree [3] DN,=20 ipAddress [4] IPAddress,=20 public [6] NULL,=20 this [7] NULL }, } =20 =20 =20 ApplicationDefinedPermission ::=3D OID=20 =20 ApplicationDefinedPermissions ::=3D SEQUENCE OF =20 ApplicationDefinedPermission=20 =20 4. Notes on Application Defined Permissions=20 =20 In order to define an ADP, the application developer needs to=20 register an OID with some registration authority (such as IANA). =20 Once the application developer has obtained the OID, it can be used=20 as the root for defining the ADPs needed by the LDAP integrated=20 Greenblatt Standards Track 4=20 =0C Application Defined Permissions for LDAP April 2001=20 =20 =20 application. Servers that advertise their support of the ADP=20 through the use 1.3.6.1.4.1.5515.3.1 the OID in the=20 =91supportedAccesControlSchemes=92 MUST support any OID in values of the= =20 the ACI information attributes: applicationDefinedEntryACI and=20 applicationDefinedSubtreeACI.=20 =20 5. Example of an Application Defined Permissions=20 =20 =20 Application defined permissions are not intended to restrict the=20 ability of any subject to perform LDAP operations against any LDAP=20 entry. Application defined permissions are defined to allow LDAP=20 applications to store their access control information within LDAP=20 entries. For example, an electronic commerce application may make=20 use of LDAP to store access control information about which=20 customers have the ability to purchase various items that the=20 electronic commerce application provides. This application can=20 create an OID to represent the "purchase" permission. Then the=20 application can create entries in the DIT representing the inventory=20 items that are under access control. Finally, the application can=20 assign rights to purchase these items, by creating ACI attributes to=20 the inventory item entries, using other DIT entries as the subject=20 of the ACI attribute.=20 =20 Once the DIT has been set up, the GetEffectiveRights operation and=20 controls can be used to determine which users have rights to=20 purchase various inventory items.=20 =20 Example #1=20 =20 dn: o=3DXYZ, c=3DUS=20 applicationDefinedSubtreACI:=20 grant:5.4.3.2.1#[entry]#group:cn=3DG1,ou=3DABC,o=3DXYZ,c=3DUS=20 =20 Assume that the OID 5.4.3.2.1 (which is not a legal OID), defines=20 the "purchase" permission. This ACI means that for the entire=20 subtree rooted at "o =3D XYZ, c=3Dus", all members of the named group=20 have the permission to purchase all entries in the subtree.=20 =20 Example #2=20 =20 dn: cn=3DpartNumber1,ou=3Dparts,o=3DXYZ, c=3DUS=20 applicationDefinedentryACI: grant:5.4.3.2.1#[entry]#authzID- dn:cn=3Dbgreenblatt,dc=3Ddtasi,dc=3Dcom=20 =20 Assume again the OID 5.4.3.2.1, defines the "purchase" permission. =20 This ACI means that the entry defined by the distinguished name=20 =93cn=3Dbgreenblatt,dc=3Ddtasi,dc=3Dcom=94 has the permission to purchase= the=20 item denoted by the entry =93cn=3DpartNumber1,ou=3Dparts,o=3DXYZ, c=3DUS= =94.=20 =20 =20 6. Security Considerations=20 =20 This document proposes protocol elements for transmission of=20 security policy information. Security considerations are discussed=20 Greenblatt Standards Track 5=20 =0C Application Defined Permissions for LDAP April 2001=20 =20 =20 throughout this draft. Because subject security attribute=20 information is used to evaluate decision requests by applications,=20 it is security-sensitive information and must be protected against=20 unauthorized modification whenever it is stored or transmitted.=20 =20 There is no interaction of application defined access controls with=20 any directory functions (other than the ones defined in this [2]).=20 =20 =20 7. References=20 =20 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP=20 9, RFC 2026, October 1996.=20 =20 2 Stokes, E., et. al., =93Access Control Model for LDAPv3=94, Internet= =20 Draft (work in Progress), March 2001.=20 =20 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement=20 Levels", BCP 14, RFC 2119, March 1997=20 =20 4 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax=20 Specifications: ABNF", RFC 2234, Internet Mail Consortium and=20 Demon Internet Ltd., November 1997=20 =20 8. Author's Address=20 =20 Bruce Greenblatt=20 Directory Tools and Application Services, Inc.=20 6841 Heaton Moor Drive=20 San Jose, CA 95119=20 Email: bgreenblatt@directory-applications.com=20 =20 Full Copyright Statement=20 =20 "Copyright (C) The Internet Society (date). All Rights Reserved.=20 This document and translations of it may be copied and furnished to=20 others, and derivative works that comment on or otherwise explain it=20 or assist in its implmentation may be prepared, copied, published=20 and distributed, in whole or in part, without restriction of any=20 kind, provided that the above copyright notice and this paragraph=20 are included on all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by removing=20 the copyright notice or references to the Internet Society or other=20 Internet organizations, except as needed for the purpose of=20 developing Internet standards in which case the procedures for=20 copyrights defined in the Internet Standards process must be=20 followed, or as required to translate it into languages other than=20 English. The limited permissions granted above are perpetual and=20 will not be revoked by the Internet Society or its successors or=20 assigns.=20 =20 This document and the information contained herein is provided on an=20 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=20 Greenblatt Standards Track 6=20 =0C Application Defined Permissions for LDAP April 2001=20 =20 =20 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=20 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 Greenblatt Standards Track 7=20 =0C --=====================_25316663==_-- From list@netscape.com Tue Apr 3 00:00:59 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09945 for ; Tue, 3 Apr 2001 00:00:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3340sS18903; Mon, 2 Apr 2001 21:00:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3340tY13999; Mon, 2 Apr 2001 21:00:55 -0700 (PDT) Resent-Date: Mon, 2 Apr 2001 21:00:55 -0700 (PDT) From: sy_79@hotmail.com Message-ID: <000038aa3b7e$00007708$000023dd@hotmail.com> To: Subject: Get Your Viagra Online Now !!! 9181 Date: Mon, 02 Apr 2001 23:54:54 -1600 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Resent-Message-ID: <"8zlGwB.A.XaD.1rUy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: quoted-printable = Get VIAGRA



the breakthrough medication for impotence

delivered to your mailbox...



..without leaving your computer.



Simply Click Here:ht= tp://www.renetcom.net/user6/home1.html



In less than 5 minutes you can complete the on-line consultation and in
many cases have the medication in 24 hours.





Simply Click Here:ht= tp://www.renetcom.net/user6/home1.html



>From our website to your mailbox.

On-line consultation for treatment of compromised sexual function.





Convenient...affordable....confidential.

We ship VIAGRA worldwide at US prices.





To Order Visit:http:= //www.renetcom.net/user6/home1.html





This is not a SPAM. You are receiving this because

you are on a list of email addresses that I have bought.

And you have opted to receive information about

business opportunities. If you did not opt in to receive

information on business opportunities then please accept

our apology. To be REMOVED from this list simply reply

with REMOVE as the subject. And you will NEVER receive

another email from me.mailto:remove432= @businessinfo-center.com

















































































 From list@netscape.com Tue Apr 3 07:54:50 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27495 for ; Tue, 3 Apr 2001 07:54:50 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f33BrGv23971; Tue, 3 Apr 2001 04:53:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f33BrFk07898; Tue, 3 Apr 2001 04:53:15 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 04:53:15 -0700 (PDT) Message-Id: <200104031152.HAA27095@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-dnsref-00.txt Date: Tue, 03 Apr 2001 07:52:21 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"HEZgp.A.k6B.pmby6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use of DNS SRV in LDAP Named Subordinate References Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-dnsref-00.txt Pages : 5 Date : 02-Apr-01 This document describes how LDAP service location information stored on DNS SRV resource records may be used to in conjunction with named subordinate referral objects. This document defines the dNSReferral object class. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-dnsref-00.txt 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-zeilenga-ldap-dnsref-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-zeilenga-ldap-dnsref-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: <20010402124656.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-dnsref-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-dnsref-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010402124656.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Apr 3 07:54:51 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27506 for ; Tue, 3 Apr 2001 07:54:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f33Bqxv23844; Tue, 3 Apr 2001 04:53:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f33BqwU07563; Tue, 3 Apr 2001 04:52:58 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 04:52:58 -0700 (PDT) Message-Id: <200104031151.HAA26933@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-cancel-03.txt Date: Tue, 03 Apr 2001 07:51:24 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"C45DqB.A.x1B.Ymby6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAP Cancel Extended Operation Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-cancel-03.txt Pages : 5 Date : 02-Apr-01 This specification describes an extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation [RFC2251] but like the DAP Abandon operation [X.511], this operation has a response which provides an indication of its outcome. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-cancel-03.txt 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-zeilenga-ldap-cancel-03.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-zeilenga-ldap-cancel-03.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: <20010402124523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-cancel-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-cancel-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010402124523.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Apr 3 11:08:18 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03600 for ; Tue, 3 Apr 2001 11:08:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f33F6cv11142; Tue, 3 Apr 2001 08:06:38 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f33F6cM05795; Tue, 3 Apr 2001 08:06:38 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 08:06:38 -0700 (PDT) Message-Id: <200104031151.HAA26983@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldapv3bis-opattrs-06.txt Date: Tue, 03 Apr 2001 07:51:41 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"SOdGs.A.FaB.8bey6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAPv3: All Operational Attributes Author(s) : K. Zeilenga Filename : draft-zeilenga-ldapv3bis-opattrs-06.txt Pages : 5 Date : 02-Apr-01 X.500 [X.500] provides a mechanism for clients to request all operational attributes be returned with entries provided in response to a search operation. This mechanism is often used by clients to discover which operatinal attributes are present in an entry. LDAP [RFC2251] does not provide a similar mechanism to clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldapv3bis-opattrs-06.txt 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-zeilenga-ldapv3bis-opattrs-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-zeilenga-ldapv3bis-opattrs-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. --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: <20010402124551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldapv3bis-opattrs-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldapv3bis-opattrs-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010402124551.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Apr 3 11:16:26 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03932 for ; Tue, 3 Apr 2001 11:16:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f33FFPv12996; Tue, 3 Apr 2001 08:15:25 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f33FFOs11675; Tue, 3 Apr 2001 08:15:24 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 08:15:24 -0700 (PDT) Date: Tue, 3 Apr 2001 11:14:19 -0400 Message-Id: <200104031514.LAA04795@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldapext@netscape.com Subject: Comments on Access Control Model draft - grant/deny evaluation rules Resent-Message-ID: <"eC8m6D.A.21C.Kkey6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I'm afraid this one is a bit long, but at least it's the last of my comments on the access control model draft. While the current draft has improvements over earlier ones, I think there are still some ambiguities in the grant/deny evaluation rules (Section 4.3). I agree that "more specific policies MUST override less specific ones", but there are some places where it is not clear which policy is more specific. There are also some missing elements in the precedence lists, and there are some interactions among different precedences that need to be clarified. Some of the things that I don't think are clear in the current draft: - Groups and roles may contain other groups and roles. Subtrees may contain groups and roles. Since groups, roles, and subtrees are of different precedence, the interactions need to be spelled out. - Subtrees contain subtrees. I assume that subtreeACI for a contained subtree has precedence over subtreeACI for the containing subtree, but that doesn't seem to be explicitly stated. - There are some things missing from the precedence lists (e.g. "authzID-dn:" vs. "authzID-u:", precedence of attribute specifications). - There are some interactions between precedence lists that are not well defined. - authnLevel checking is not well integrated with the rest of the evaluation rules. - The term "more specific" is useful in guidelines, but it should not be used in actual requirements since it is not well defined. I've attached a revised version of the precedence lists and the access decision algorithm below. It attempts to resolve the issues above. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Precedence of Scope Types: 1. Entry 2. Subtree For a given subject DN (including authentication level) and target DN, subtreeACI lower in the tree take precedence over those higher in the tree. Precedence of Subjects within a Scope: 1. ipAddress 2. Wildcarded DNS name If multiple wildcarded DNS names are applicable, they are of equal precedence. 3. authzID distinguished name ("authzID-dn:") 4. authzID userid ("authzID-u:") 5. this 6. role If the DN of a role or a group appears in a role (e.g. appears as a value of roleOccupant in an organizationalRole), it is recursively expanded. For determination of precedence, the resulting expanded collection of names is considered to have come from a role regardless of the original source. 7. group If the DN of a role or a group appears in a group, it is recursively expanded. For determination of precedence, the resulting expanded collection of names is considered to have come from a group regardless of the original source. 8. subtree Subtrees may contain groups and/or roles. They should be recursively expanded. For determination of precedence, members of groups or occupants of roles that apply because (after recursive expansion) the group or role is contained in a subtree are considered to have come from the subtree regardless of the original source. 9. public Precedence of Attribute Specifications 1. Access controls for a list of specific attributes (regardless of the number of attributes on the list) are all of equal precedence. 2. Access controls specifying "[all]" attributes are of lower precedence than specific lists. Precedence of grant/deny: Deny takes precedence over grant Precedence of Authentication Levels 1. ACI that specifies a specific authentication level applies only if the subject has authenticated at the specified level. It takes precedence over ACI that specifies the same subject with "authn" or "unauthn" authentication level or with no authentication level specified. 2. ACI that specifies "authn" or "unauthn" has lower precedence. 3. If the authentication level is omitted, it is treated as though "authn" had been specified. Default Deny is the default when there is no access control information or when evaluation of the access control information yields no result that allows the requester access. Access Decision Algorithm 1. Determine all the entryACI and subtreeACI values which could apply to the target DN which is being accessed. This is the DN of the entry which is being queried in a search, modified, deleted, etc. Precedence of values from different ACIs are handled according to the "Precedence of Scope Types" above. 2. Determine which of the collected ACI values (determined in step 1) apply to the bound DN. Process one Subject Type at a time in order of precedence from the "Precedence of Subjects within a Scope" Within each Subject Type, apply the the precedence rules for Authentication Level from "Precedence of Authentication Levels". If at least one ACI value exists for a Subject Type when all ACI values for that Subject Type have been processed, proceed to Step 3 without processing any additional Subject Types. If no ACI values remain after processing all Subject Types, access is denied. 3. Evaluate the remaining ACI values and determine a grant/deny decision. For permissions that apply to attributes rather than entries, if conflicting ACI values exist for one attribute, apply the "Precedence of Attribute Specifications". 4. If conflicting values still exist, deny takes precedence over grant. 5. If more than one ACI value remains, union semantics apply. 6. If there is no grant for one or more of the permissions required for the operation in question, access is denied. From list@netscape.com Tue Apr 3 11:25:19 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04261 for ; Tue, 3 Apr 2001 11:25:18 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f33FOkS10238; Tue, 3 Apr 2001 08:24:46 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f33FOjY22931; Tue, 3 Apr 2001 08:24:45 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 08:24:45 -0700 (PDT) Message-Id: <200104031151.HAA26999@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-grouping-02.txt Date: Tue, 03 Apr 2001 07:51:45 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"wKizzD.A.nlF.8sey6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAPv3: Grouping of Related Operations Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-grouping-02.txt Pages : 10 Date : 02-Apr-01 This document provides a general mechanism for grouping related LDAP operations. Grouping of operations may be used to support replication, proxies, and higher level operations such as transactions. This document describes a set of LDAP [RFC2251] extended operations and other protocol and schema elements to support grouping of related operations. Uses of this grouping mechanism will be detailed in separate documents (e.g. LDAP Transactions [LDAPT]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-grouping-02.txt 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-zeilenga-ldap-grouping-02.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-zeilenga-ldap-grouping-02.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: <20010402124600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-grouping-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-grouping-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010402124600.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Apr 3 14:48:17 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12903 for ; Tue, 3 Apr 2001 14:48:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f33IiBS17660; Tue, 3 Apr 2001 11:44:12 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f33IiB219404; Tue, 3 Apr 2001 11:44:11 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 11:44:11 -0700 (PDT) Message-Id: <200104031841.OAA12687@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-dnsref-00.txt Date: Tue, 03 Apr 2001 14:41:55 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"-epqO.A.stE.2nhy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use of DNS SRV in LDAP Named Subordinate References Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-dnsref-00.txt Pages : 5 Date : 02-Apr-01 This document describes how LDAP service location information stored on DNS SRV resource records may be used to in conjunction with named subordinate referral objects. This document defines the dNSReferral object class. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-dnsref-00.txt 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-zeilenga-ldap-dnsref-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-zeilenga-ldap-dnsref-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: <20010403134520.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-dnsref-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-dnsref-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010403134520.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Tue Apr 3 14:58:48 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13312 for ; Tue, 3 Apr 2001 14:58:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f33Iw1S21270; Tue, 3 Apr 2001 11:58:02 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f33Irnk25454; Tue, 3 Apr 2001 11:53:49 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 11:53:49 -0700 (PDT) Message-Id: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 03 Apr 2001 11:54:41 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: java api bind() methods Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"3A_O1D.A.jKG.1why6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com A few questions regarding the LDAPConnectionbind methods... How does bind() interact with outstanding operations which are implicitly abandoned by the bind request? In particular, with listeners for outstanding operations? How does bind() behave when a referral is returned? In particular, if the referral is successfully chased, what is the authentication state of the connection? How does an application cancel an in-progress SASL multiple-step bind operation? Maybe an empty (not null) mechanism could be used for this. During an in-progress SASL multiple-step bind operation, what happens with one attempt to issue other operations upon the same session (via a clone of the connection)? The SASL bind() methods appears to negotiate mechanisms between those requested by the application and those advertised by the server. If so, is there a way to disable this negotiation and explicitly mandate the use of a particular mechanism? I am also concerned by this statement: If mechanisms is null, or if the first version of the method is called, the LDAP server will be interrogated for its supportedSaslMechanisms attribute of its root DSE. This implies supportedSaslMechanisms is not checked after: 1) reconnection 2) StartTLS() 3) establishment of SASL provided security services Also, > Parameters are: > > dn If non-null and non-empty, specifies that the > connection and all operations through it should > be authenticated with dn as the distinguished > name. This implies the provided DN is the authentication identity to be associated with the connection. Generally, the authentication identity to be associated with the connection is that provided in the credentials associated with the SASL mechanism. From list@netscape.com Tue Apr 3 18:15:23 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18679 for ; Tue, 3 Apr 2001 18:15:22 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f33MCSv00746; Tue, 3 Apr 2001 15:12:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f33MCRY09166; Tue, 3 Apr 2001 15:12:27 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 15:12:27 -0700 (PDT) Message-Id: <5.0.2.1.0.20010403144107.00ac6070@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 03 Apr 2001 15:13:45 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: java api startTLS() method Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"YfcM0D.A.0OC.Krky6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com A few more questions regarding startTLS(). Does the startTLS() taking any action due to any outstanding operations within the session it may be aware of? During the processing of the startTLS() call, are there any restrictions placed upon the connection and its clones? In particular, how would a call to issue some other to be handled? How are referrals returned in response to the startTLS operation handled? > If the server does not support the transition to a TLS session, > an LDAPException is thrown with the error code UNWILLING_TO_PERFORM. I would think the API would return whatever non-success result code was returned by the server in the LDAPexception. Kurt From list@netscape.com Tue Apr 3 19:41:02 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20368 for ; Tue, 3 Apr 2001 19:41:02 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f33Ndcv15908; Tue, 3 Apr 2001 16:39:38 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f33Ndc225221; Tue, 3 Apr 2001 16:39:38 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 16:39:38 -0700 (PDT) Message-Id: <5.0.2.1.0.20010403160353.00ae8bb0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 03 Apr 2001 16:40:27 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: java getAuthenticationMethod Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"f-NSAB.A.pJG.38ly6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is described as: >4.6.14 getAuthenticationMethod > > public String getAuthenticationMethod() > > Returns the method used to authenticate the connection. The return > value is one of the following: > > "none" If the connection is not authenticated > > "simple" If simple authentication was used, also if a null > or empty authentication DN was specified > > "sasl" If a SASL mechanism was used to authenticate 4.6.14 I'm a bit confused by the "also if a null or empty authentication DN was specified" clause upon "simple". An empty bind name in simple bind may be used for anonymous authentication. I assume it wasn't meant to encompass SASL bind operations where the bind name was empty. Hence, I assume, "simple" implies: The current authentication state was established by the successful completion of simple bind (including anonymous, unauthenticated, or authenticated). and "sasl": The current authentication state was established by the successful completion of a sasl bind. and "none": The current authentication state has not been established by use of the bind operation. This is the initial state upon connect(). The issuing of any bind request also returns the method associated with the connection to bind. Also, in regards to getAuthenticationDN(), after rereading the I-D, I assume it just returns whatever DN was passed into a bind() method and used as the bind name during the authentication. That is: public String getAuthenticationDN() Returns the distinguished name (DN) used as the bind name during the last successful bind operation. From list@netscape.com Tue Apr 3 20:25:55 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20876 for ; Tue, 3 Apr 2001 20:25:54 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f340PFv23592; Tue, 3 Apr 2001 17:25:15 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f340PFs20631; Tue, 3 Apr 2001 17:25:15 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 17:25:15 -0700 (PDT) Message-Id: <5.0.2.1.0.20010403171003.00ac0800@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 03 Apr 2001 17:26:19 -0700 To: rvh@qsun.mt.att.com (Richard V Huber) From: "Kurt D. Zeilenga" Subject: Re: Comments on Access Control Model draft - grant/deny evaluation rules Cc: ietf-ldapext@netscape.com In-Reply-To: <200104031514.LAA04795@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"KiRS-C.A.7BF.pnmy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:14 AM 4/3/01 -0400, Richard V Huber wrote: >I'm afraid this one is a bit long, but at least it's the last of my >comments on the access control model draft. > >While the current draft has improvements over earlier ones, I think >there are still some ambiguities in the grant/deny evaluation rules >(Section 4.3). > >I agree that "more specific policies MUST override less specific ones", >but there are some places where it is not clear which policy is more >specific. There are also some missing elements in the precedence >lists, and there are some interactions among different precedences that >need to be clarified. > >Some of the things that I don't think are clear in the current draft: > > - Groups and roles may contain other groups and roles. Subtrees may > contain groups and roles. Since groups, roles, and subtrees are of > different precedence, the interactions need to be spelled out. I would recommend that subtrees, groups and roles not be recursively evaluated. > - There are some things missing from the precedence lists (e.g. > "authzID-dn:" vs. "authzID-u:", precedence of attribute > specifications). I believe they should have the same precedence as they are equally specific. > - The term "more specific" is useful in guidelines, but it should not > be used in actual requirements since it is not well defined. I concur. >I've attached a revised version of the precedence lists and the access >decision algorithm below. It attempts to resolve the issues above. > >Rick Huber > >--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- >Precedence of Scope Types: > > 1. Entry > > 2. Subtree > For a given subject DN (including authentication level) and target > DN, subtreeACI lower in the tree take precedence over those higher > in the tree. lower and applicable / higher and applicable. >Precedence of Subjects within a Scope: > > 1. ipAddress I don't understand why ipAddress is viewed as being more specific than an authzID. > 2. Wildcarded DNS name > If multiple wildcarded DNS names are applicable, they are of equal > precedence. I don't understand why ipAddress is viewed as being more specific than an authzID. > 3. authzID distinguished name ("authzID-dn:") > > 4. authzID userid ("authzID-u:") All forms of authzID should have equal precedence. > 5. this > > 6. role > If the DN of a role or a group appears in a role (e.g. appears as > a value of roleOccupant in an organizationalRole), it is > recursively expanded. For determination of precedence, the > resulting expanded collection of names is considered to have come > from a role regardless of the original source. > > 7. group > If the DN of a role or a group appears in a group, it is > recursively expanded. For determination of precedence, the > resulting expanded collection of names is considered to have come > from a group regardless of the original source. > > 8. subtree > Subtrees may contain groups and/or roles. They should be > recursively expanded. For determination of precedence, members of > groups or occupants of roles that apply because (after recursive > expansion) the group or role is contained in a subtree are > considered to have come from the subtree regardless of the > original source. > > 9. public > >Precedence of Attribute Specifications > > 1. Access controls for a list of specific attributes (regardless of > the number of attributes on the list) are all of equal > precedence. > > 2. Access controls specifying "[all]" attributes are of lower > precedence than specific lists. > >Precedence of grant/deny: > > Deny takes precedence over grant > >Precedence of Authentication Levels > > 1. ACI that specifies a specific authentication level applies only if > the subject has authenticated at the specified level. It takes > precedence over ACI that specifies the same subject with "authn" > or "unauthn" authentication level or with no authentication level > specified. I note: X.501(93) 16.4.2.3 AuthenticationLevel AuthenticationLevel defines the minimum requestor authentication level required for this ACIItem. > 2. ACI that specifies "authn" or "unauthn" has lower precedence. > > 3. If the authentication level is omitted, it is treated as though > "authn" had been specified. > >Default > > Deny is the default when there is no access control information or > when evaluation of the access control information yields no result > that allows the requester access. > >Access Decision Algorithm > > 1. Determine all the entryACI and subtreeACI values which could apply > to the target DN which is being accessed. This is the DN of the > entry which is being queried in a search, modified, deleted, etc. > Precedence of values from different ACIs are handled according to > the "Precedence of Scope Types" above. > > 2. Determine which of the collected ACI values (determined in step 1) > apply to the bound DN. Process one Subject Type at a time in > order of precedence from the "Precedence of Subjects within a > Scope" Within each Subject Type, apply the the precedence rules > for Authentication Level from "Precedence of Authentication > Levels". If at least one ACI value exists for a Subject Type when > all ACI values for that Subject Type have been processed, proceed > to Step 3 without processing any additional Subject Types. If no > ACI values remain after processing all Subject Types, access is > denied. > > 3. Evaluate the remaining ACI values and determine a grant/deny > decision. For permissions that apply to attributes rather than > entries, if conflicting ACI values exist for one attribute, apply > the "Precedence of Attribute Specifications". > > 4. If conflicting values still exist, deny takes precedence over > grant. > > 5. If more than one ACI value remains, union semantics apply. > > 6. If there is no grant for one or more of the permissions required > for the operation in question, access is denied. From list@netscape.com Tue Apr 3 22:10:36 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23203 for ; Tue, 3 Apr 2001 22:10:35 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3428dS28069; Tue, 3 Apr 2001 19:08:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3428fc29549; Tue, 3 Apr 2001 19:08:41 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 19:08:41 -0700 (PDT) From: malm31@hotmail.com Message-ID: <0000448f59d6$00004556$00006057@32.102.75.227> To: Subject: Receive a F R E E Pager - Click Here NOW ... 24663 Date: Tue, 03 Apr 2001 17:57:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Resent-Message-ID: <"Bu2TgC.A.VNH.nIoy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit BRAND NEW Pager FREE Stop wondering where your kids are. Stay in touch by given them a FREE pager Here at Paging America we are excited to be offering you this exclusive, top of the line, full-featured pager in your choice of color for FREE. This side viewable display pager is one of the smallest and lightest pagers on the market today. This high tech pager holds 20 numeric messages - 9 alerts & silent vibration - New FLEX Technology provides 3 times the battery life - Time & Date stamping and smart alarm so you can set a daily or weekly reminder. Call 1(877)699-7409 and take advantage of this exciting offer - in days you will receive a BRAND NEW PAGER - in your choice of color and already programmed with a local telephone number Find out where your loves ones are. To be taken off this list send email to summer265us@yahoo.com From list@netscape.com Wed Apr 4 02:20:00 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10122 for ; Wed, 4 Apr 2001 02:20:00 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f346E1S15067; Tue, 3 Apr 2001 23:14:11 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f346DcM02807; Tue, 3 Apr 2001 23:13:38 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 23:13:38 -0700 (PDT) From: jonahsmy@hostpro.net Message-Id: <200104040610.PAA07336@unify.hoseo.or.kr> DATE: 03 Apr 01 11:11:11 PM Reply-to: jonahsmy@hostpro.net TO: jonahsmy@hostpro.net SUBJECT: NEW!! 142 MILLION Email Addresses - $149 Resent-Message-ID: <"ItlKY.A.xp.ytry6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com TO BE REMOVED FROM FUTURE MAILINGS, SIMPLY REPLY TO THIS MESSAGE AND PUT "REMOVE" IN THE SUBJECT. 142 MILLION EMAIL ADDRESSES FOR ONLY $149 You want to make some money? I can put you in touch with over 140 million people at virtually no cost. Can you make one cent from each of theses names? If you can you have a profit of over $1,400,000.00 That's right, I have over 142 Million Fresh email addresses that I will sell for only $149. These are all fresh addresses that include almost every person on the Internet today, with no duplications. They are all sorted and ready to be mailed. That is the best deal anywhere today! Imagine selling a product for only $5 and getting only a 1% response. That's OVER $7,000,000 IN YOUR POCKET !!! Don't believe it? People are making that kind of money right now by doing the same thing, that is why you get so much email from people selling you their product....it works! I will even tell you how to mail them with easy to follow step-by-step instructions I include with every order. I will send you a copy of every law concerning email. It is easy to obey the law and make a fortune. These 142 Million email addresses are yours to keep, so you can use them over and over. They come on a collection of several CDs. This offer is not for everyone. If you can not see the just how excellent the risk / reward ratio in this offer is then there is nothing I can do for you. To make money you must stop dreaming and TAKE ACTION. THREE PACKAGES - BRONZE (addresses ONLY) SILVER (mailing software included) GOLD ( everything to make the Internet your personal bank account) PACKAGE DESCRIPTIONS BELOW; **************************************** THE BRONZE MARKETING SETUP (addresses ONLY) 142,000,000 email addresses on CD These name are all in text files ready to mail!!! $149.00 SEVERAL WAYS TO ORDER !!! TO ORDER BY PHONE - CALL 530-343-9681 OTHER PACKAGES AND OTHER METHODS - SEE BELOW **************************************** THE SILVER MARKETING SETUP 142,000,000 email addresses on CD These name are all in text files ready to mail!!! AND Several different email programs and tools to help with your mailings and list management. $ 189.00 SEVERAL WAYS TO ORDER !!! TO ORDER BY PHONE - CALL 530-343-9681 OTHER PACKAGES AND OTHER METHODS - SEE BELOW **************************************** THE GOLD MARKETING SETUP VIRTUALLY EVERYTHING!! 142,000,000 email addresses on CD These name are all in text files ready to mail!!! AND Several different email programs and tools to help with your mailings and list management. AND Over 500 different Business Reports now being sold on the Internet for up to $100 each. You get full rights to resell these reports. With this package you get the email addresses, the software to mail them AND ready to sell information products. AND ...... . a collection of the 100 best money making adds currently floating around on the Internet. $ 249 SEVERAL WAYS TO ORDER !!! TO ORDER BY PHONE - CALL 530-343-9681 OTHER METHODS - SEE BELOW ************************************************************* THE PLATINUM MARKETING SETUP VIRTUALLY EVERYTHING!! 142,000,000 email addresses on CD These name are all in text files ready to mail!!! AND Several different email programs and tools to help with your mailings and list management. AND Over 500 different Business Reports now being sold on the Internet for up to $100 each. You get full rights to resell these reports. With this package you get the email addresses, the software to mail them AND ready to sell information products. AND ...... . a collection of the 100 best money making adds currently floating around on the Internet. AND..... LIVE TECH SUPPORT... WHENEVER YOU NEED IT... FOR AS LONG AS YOU NEED IT!!! $339 ********************************************************** SEVERAL WAYS TO ORDER !!! TO ORDER BY PHONE - CALL 530-343-9681 OTHER METHODS - SEE BELOW IF YOU ORDER BY PHONE OR FAX WE WILL SHIP YOUR CD CONTAINING THE 142 MILLION + NAMES WITHIN 12 HOURS OF YOUR ORDER!!! WE ACCEPT: AMERICAN EXPRESS, VISA & MASTERCARD TYPE OF CARD AMX / VISA / MC??_______________ EXPIRATION DATE ___________________________ NAME ON CREDIT CARD________________________ CREDIT CARD #_______________________________ BILLING ADDRESS ____________________________ CITY_________________________________________ STATE___________________ZIP__________________ COUNTRY____________________________________ PHONE INCLUDE AREA CODE___________________ EMAIL ADDRESS______________________________ WE WILL BILL selected amount to your account PLUS one of the following shipping costs: SHIPPING COST OF $3.85 FIRST CLASS MAIL SHIPPING COST OF $15.00 FEDERAL EXPRESS INTERNATIONAL SHIPPING CHARGE $25.00 + SALES TAX added where required 1) FAX your order and a copy of your SIGNED check payable to Cyber FirePower! for the appropriate amount to FAX # 530-343-1808. 2) Fax the same above requested credit card information to FAX # 530-343-1808. 3) Call phone # 530-343-9681. This is a 24 hour phone number to place a CREDIT CARD order. This is an ORDER LINE only. ALL INFORMATION NECESSARY FOR YOU TO SUCCESSFULLY MAIL QUICKLY, PROPERLY, & LEGALLY IS PROVIDED WITH YOUR ORDER. Copyright 2000, 2001 Please NOTE: This advertisement is NOT sponsored by ANY Internet Service Provider. This is an advertisement that is produced and sponsored by Cyber FirePower! for Cyber FirePower! to reach potential customers. ALSO TAKE NOTE: At the time of this mailing the return email address is a bonafide legitimate return email address that was signed up for with the express purpose of receiving all undeliverable emails as well as remove requests. On occasion the return email address provided may become disrupted by the efforts of, what we define as, Internet terrorists. If this is the case and you wish removal please call us. If you fax a copy of your phone bill where you called us for removal we will reimburse you via PayPal. Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof, or abridging the freedom of speech or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances. Amendment I, The US Constitution From list@netscape.com Wed Apr 4 02:21:20 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10140 for ; Wed, 4 Apr 2001 02:21:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f346IDS15568; Tue, 3 Apr 2001 23:18:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f346Hok04231; Tue, 3 Apr 2001 23:17:50 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 23:17:50 -0700 (PDT) From: Subject: The best yet ... Date: Mon, 10 Jan 2000 16:16:13 Message-Id: <397.145958.426185@ozemail.com.au> Reply-To: lovedoctor66@yeahbaby18i.net.uk.netscape.com Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Resent-Message-ID: <"ZdWtuD.A.z_.vxry6"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com

Mandi - 19 - "I love being a cheerleader, it gives me so much freedom of expression. A heaps of great sex!"

 

AMATEUR BABE UPDATE #4

ALL NEW - FANTASY BABES

Meet the Girls!

Meet Melanie - 18 - "I've got a secret, I love having a threesome with a guy I like and my girlfriend, have a peek...."

Meet Kathy - 19 - "My favourtie time of the week is when I do a new video or photoshoot, it makes me so horny"

Meet Sonia - 20 - "Just click on me to see all of my great photosets, you're not going to see my tits from here"

 

 

 

 

 

 

 

 

 


OVER 100,000 Movies

Live Sex Shows 24/7

Best Quality Photo Archive

 

What are you waiting for, the BABES are THIS WAY!

http://www.bestteenbabesonthenet.com

 

 

 

Karma-Sutra - weekly sex guide by email. subscribe HERE

 

 

 

 

Removal Instructions. This is the The Adult NewsLink Newsletter. We appreciate you being on our list. However, if you would prefer to be removed from our OPT IN newsletter, as always, all you have to do is send an email here with your email address as the subject line and you'll be removed immediately from our lists.

From list@netscape.com Wed Apr 4 02:21:26 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10151 for ; Wed, 4 Apr 2001 02:21:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f346Guv22909; Tue, 3 Apr 2001 23:17:07 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f346GWQ03670; Tue, 3 Apr 2001 23:16:32 -0700 (PDT) Resent-Date: Tue, 3 Apr 2001 23:16:32 -0700 (PDT) Date: Wed, 4 Apr 2001 02:14:23 -0400 Message-Id: <200104040614.CAA05728@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: Kurt@openldap.org Subject: Re: Comments on Access Control Model draft - grant/deny evaluation rules Cc: ietf-ldapext@netscape.com Resent-Message-ID: <"Jk86FB.A.70.fwry6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Kurt's comments on my comments are preceeded by colons. My replies are on the lines that do not have colons. Rick Huber : >Some of the things that I don't think are clear in the current draft: : > : > - Groups and roles may contain other groups and roles. Subtrees may : > contain groups and roles. Since groups, roles, and subtrees are of : > different precedence, the interactions need to be spelled out. : : I would recommend that subtrees, groups and roles not be : recursively evaluated. If groups and roles are not recursively evaluated, I think that the principle of least surprise will be violated - it won't work the way people expect it to. If a group DN appears as a member of another group, I believe the expected behavior is that the members of the "inner" group get the access granted to the "outer" group. How do we get this behavior if groups/roles are not recursively evaluated? As for subtrees, are you saying that a group or role should not get the access that is granted to a subtree containing the group? : > - There are some things missing from the precedence lists (e.g. : > "authzID-dn:" vs. "authzID-u:", precedence of attribute : > specifications). : : I believe they should have the same precedence as they are : equally specific. I wrote my comments to reflect my preference, but I could live with Kurt's version. The important thing is to explicitly state how it should work to avoid implementaion inconsistencies down the road. : > - The term "more specific" is useful in guidelines, but it should not : > be used in actual requirements since it is not well defined. : : I concur. : : >I've attached a revised version of the precedence lists and the access : >decision algorithm below. It attempts to resolve the issues above. : > : >Rick Huber : > : >--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- : >Precedence of Scope Types: : > : > 1. Entry : > : > 2. Subtree : > For a given subject DN (including authentication level) and target : > DN, subtreeACI lower in the tree take precedence over those higher : > in the tree. : : lower and applicable / higher and applicable. OK. how about "... applicable ACI values from subtreeACI lower in the tree take precedence over those higher in the tree." : >Precedence of Subjects within a Scope: : > : > 1. ipAddress : : I don't understand why ipAddress is viewed as being more : specific than an authzID. : : : > 2. Wildcarded DNS name : > If multiple wildcarded DNS names are applicable, they are of equal : > precedence. : : I don't understand why ipAddress is viewed as being more : specific than an authzID. Bob Blakley sent some mail about this explaining the precedence. This isn't a subject type I would really want to use, but if you DO want to use IP address to determine access controls, I agree with Bob that it needs to have high precedence. : > 3. authzID distinguished name ("authzID-dn:") : > : > 4. authzID userid ("authzID-u:") : : All forms of authzID should have equal precedence. : : > 5. this : > : > 6. role : > If the DN of a role or a group appears in a role (e.g. appears as : > a value of roleOccupant in an organizationalRole), it is : > recursively expanded. For determination of precedence, the : > resulting expanded collection of names is considered to have come : > from a role regardless of the original source. : > : > 7. group : > If the DN of a role or a group appears in a group, it is : > recursively expanded. For determination of precedence, the : > resulting expanded collection of names is considered to have come : > from a group regardless of the original source. : > : > 8. subtree : > Subtrees may contain groups and/or roles. They should be : > recursively expanded. For determination of precedence, members of : > groups or occupants of roles that apply because (after recursive : > expansion) the group or role is contained in a subtree are : > considered to have come from the subtree regardless of the : > original source. : > : > 9. public : > : >Precedence of Attribute Specifications : > : > 1. Access controls for a list of specific attributes (regardless of : > the number of attributes on the list) are all of equal : > precedence. : > : > 2. Access controls specifying "[all]" attributes are of lower : > precedence than specific lists. : > : >Precedence of grant/deny: : > : > Deny takes precedence over grant : > : >Precedence of Authentication Levels : > : > 1. ACI that specifies a specific authentication level applies only if : > the subject has authenticated at the specified level. It takes : > precedence over ACI that specifies the same subject with "authn" : > or "unauthn" authentication level or with no authentication level : > specified. : : I note: : : X.501(93) 16.4.2.3 AuthenticationLevel : AuthenticationLevel defines the minimum requestor authentication level required for this ACIItem. : But then we have to define a well-ordering of authentication levels, and I believe that is a rathole. And the rathole reopens every time someone comes out with a new SASL mechanism. : > 2. ACI that specifies "authn" or "unauthn" has lower precedence. : > : > 3. If the authentication level is omitted, it is treated as though : > "authn" had been specified. : > : >Default : > : > Deny is the default when there is no access control information or : > when evaluation of the access control information yields no result : > that allows the requester access. : > : >Access Decision Algorithm : > : > 1. Determine all the entryACI and subtreeACI values which could apply : > to the target DN which is being accessed. This is the DN of the : > entry which is being queried in a search, modified, deleted, etc. : > Precedence of values from different ACIs are handled according to : > the "Precedence of Scope Types" above. : > : > 2. Determine which of the collected ACI values (determined in step 1) : > apply to the bound DN. Process one Subject Type at a time in : > order of precedence from the "Precedence of Subjects within a : > Scope" Within each Subject Type, apply the the precedence rules : > for Authentication Level from "Precedence of Authentication : > Levels". If at least one ACI value exists for a Subject Type when : > all ACI values for that Subject Type have been processed, proceed : > to Step 3 without processing any additional Subject Types. If no : > ACI values remain after processing all Subject Types, access is : > denied. : > : > 3. Evaluate the remaining ACI values and determine a grant/deny : > decision. For permissions that apply to attributes rather than : > entries, if conflicting ACI values exist for one attribute, apply : > the "Precedence of Attribute Specifications". : > : > 4. If conflicting values still exist, deny takes precedence over : > grant. : > : > 5. If more than one ACI value remains, union semantics apply. : > : > 6. If there is no grant for one or more of the permissions required : > for the operation in question, access is denied. From list@netscape.com Wed Apr 4 07:30:49 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14255 for ; Wed, 4 Apr 2001 07:30:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34BSZv17218; Wed, 4 Apr 2001 04:28:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34BSZM00517; Wed, 4 Apr 2001 04:28:35 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 04:28:35 -0700 (PDT) Message-Id: <200104041127.HAA13962@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-idn-01.txt Date: Wed, 04 Apr 2001 07:27:31 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"-KRc0D.A.CH.iVwy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : International Domain Names and LDAP Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-idn-01.txt Pages : 5 Date : 03-Apr-01 This document describes schema and mechanisms extending the Lightweight Directory Access Protocol [RFC 2251] to support the International Domain Name System [IDN]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-idn-01.txt 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-zeilenga-ldap-idn-01.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-zeilenga-ldap-idn-01.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: <20010403124234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-idn-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-idn-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010403124234.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Wed Apr 4 07:30:50 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14263 for ; Wed, 4 Apr 2001 07:30:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34BSdS08588; Wed, 4 Apr 2001 04:28:44 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34BSf200703; Wed, 4 Apr 2001 04:28:41 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 04:28:41 -0700 (PDT) Message-Id: <200104041127.HAA13982@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-txn-02.txt Date: Wed, 04 Apr 2001 07:27:37 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"HjulXD.A.LK.nVwy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAPv3 Transactions Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-txn-02.txt Pages : 5 Date : 03-Apr-01 LDAP [RFC2251] update operations have atomic properties upon individual entries. However, it is often desirable to update two or more entries as one atomic action, a transaction. Transactions are necessary to support a number of applications including resource provisioning and information replication. This document defines an LDAP extension to support transactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-txn-02.txt 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-zeilenga-ldap-txn-02.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-zeilenga-ldap-txn-02.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: <20010403124243.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-txn-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-txn-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010403124243.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Wed Apr 4 09:50:28 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19185 for ; Wed, 4 Apr 2001 09:50:28 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34Dkxv28546; Wed, 4 Apr 2001 06:46:59 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34DkxU09186; Wed, 4 Apr 2001 06:46:59 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 06:46:59 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3ACB259F.4D863509@Sun.COM> Date: Wed, 04 Apr 2001 15:46:07 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Richard V Huber CC: ietf-ldapext@netscape.com Subject: Re: Comments on Access Control Model - GetEffectiveRights References: <200103302321.SAA04366@qsun.mt.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"GGvABB.A.mOC.RXyy6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Rick, I agree that there is some work to do in section 9.1: In particular for the points you raise: . I also find "*" hard to understand and my intention is to propose dropping it. In other words you would only be able to ask about a _particular_ subject, not "everyone". . The "rights required" to use the getEffectiveRights control is certainly an issue. I see a few options: view it as core to the model (I believe it is) and so make an explicit permission for it, limit the getEffectiveRights concept so you cannot ask about "his" rights, but just your own (ie. remove the subject entirely as a parameter), define a way to extended operational permissions and express the permission in that scheme and probably lots of others. Once you have defined the required rights then I think the "discovery"/discloseOnError type problem you mention should be easier to resolve. I hope to have a proposal which will clear up or at least be explicit about these 9.1 issues for the next draft. Rob. Richard V Huber wrote: > > Section 9.1 says that the subject for GetEffectiveRights may be "*", in > which case "all DN types are to be used in returning the effective > rights". I'm not sure what this means. > > I had a similar question on a previous version of the draft. The > response was: > > < djb > * is intended to return the effective access for all DNs > which are defined within the ACI. This is different from simply > reading the ACI b/c it does the expansions and evaluations of grant / > deny / group memberships etc and returns the granted rights after > evaluation. > > But I don't see anything specifying this in the current draft. And do > we really want to do this? What is the intended use? If I ask for > effective rights with subject "*" for an object whose ACI is > "grant:r#[all]#subtree:dc=com" do I get back a list of all the users in > the dc=com part of the DIT? And isn't that a security problem? > > I think there are a number of other security issues for > GetEffectiveRights. In the "work still to be done" part of Ellen's > email sending out version -07, she notes: > > - getEffectiveRights: address what if not sufficient rights on > ldapACI? (get rights based on the bind authzID)". > > Beyond that, don't we need to consider what happens when there are > insufficient rights on a group or role that needs to be examined to > calculate effective rights? And as noted above, the use of subject "*" > may give back lists of DNs that would otherwise not be accessible to > the requester. Even without the "*", GetEffectiveRights might allow > the requester to confirm the existence of a DN even if the requester > has no browseDN or returnDN rights for that DN. > > Should we just say that the requester for GetEffectiveRights MUST have > authorization to access to all data touched during evaluation? Then we > need go down the list of things touched and say what permissions are > needed for each access. > > Rick Huber From list@netscape.com Wed Apr 4 11:59:03 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24105 for ; Wed, 4 Apr 2001 11:59:03 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34FwNS05422; Wed, 4 Apr 2001 08:58:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34FwNA06162; Wed, 4 Apr 2001 08:58:23 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 08:58:23 -0700 (PDT) Message-ID: <3ACB45A0.C860A11F@coscend.com> Date: Wed, 04 Apr 2001 09:02:40 -0700 From: Rob Weltman X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: java api startTLS() method References: <5.0.2.1.0.20010403144107.00ac6070@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BmIy4B.A.4fB.dS0y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > A few more questions regarding startTLS(). > > Does the startTLS() taking any action due to any outstanding > operations within the session it may be aware of? RFC 2830 says that a client MUST NOT attempt startTLS if there are any LDAP operations outstanding on the connection. If there are outstanding LDAP operations on the connection, an LDAPException is thrown (I see that 4.6.42 is missing the exception in its signature, although it is mentioned in the following description). > During the processing of the startTLS() call, are there any > restrictions placed upon the connection and its clones? No other operations may be issued on the connection during the processing of the call. An LDAPException is thrown if another operation is requested during the startTLS establishment. Clones are independent. Issuing startTLS dissociates a connection from its siblings. > In > particular, how would a call to issue some other to be handled? I'm not sure what that means. Maybe it is answered above. > How are referrals returned in response to the startTLS operation > handled? RFC 2830 says: "If the server does not support TLS (whether by design or by current configuration), it MUST set the resultCode to protocolError (see section 4.1.1 of [LDAPv3]), or to referral. The server MUST include an actual referral value in the LDAP Result if it returns a resultCode of referral. The client's current session is unaffected if the server does not support TLS. The client MAY proceed with any LDAP operation, or it MAY close the connection." If the servere returns a referral, then startTLS returns an LDAPReferralException if the application is chasing its own referrals. If the API implementation is chasing referrals, it will do so also with a startTLS referral. > > If the server does not support the transition to a TLS session, > > an LDAPException is thrown with the error code UNWILLING_TO_PERFORM. > > I would think the API would return whatever non-success > result code was returned by the server in the LDAPexception. Yes. Rob From list@netscape.com Wed Apr 4 12:02:10 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24197 for ; Wed, 4 Apr 2001 12:02:10 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34G0dS06107; Wed, 4 Apr 2001 09:00:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34G0dE08782; Wed, 4 Apr 2001 09:00:39 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 09:00:39 -0700 (PDT) Message-ID: <3ACB4620.14AE1E17@coscend.com> Date: Wed, 04 Apr 2001 09:04:48 -0700 From: Rob Weltman X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: java getAuthenticationMethod References: <5.0.2.1.0.20010403160353.00ae8bb0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"93iTG.A._HC.lU0y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > This is described as: > > >4.6.14 getAuthenticationMethod > > > > public String getAuthenticationMethod() > > > > Returns the method used to authenticate the connection. The return > > value is one of the following: > > > > "none" If the connection is not authenticated > > > > "simple" If simple authentication was used, also if a null > > or empty authentication DN was specified > > > > "sasl" If a SASL mechanism was used to authenticate 4.6.14 > > I'm a bit confused by the "also if a null or empty authentication > DN was specified" clause upon "simple". An empty bind name in > simple bind may be used for anonymous authentication. I assume > it wasn't meant to encompass SASL bind operations where the bind > name was empty. > > Hence, I assume, "simple" implies: > The current authentication state was established by > the successful completion of simple bind (including > anonymous, unauthenticated, or authenticated). > > and "sasl": > The current authentication state was established by > the successful completion of a sasl bind. > > and "none": > The current authentication state has not been established > by use of the bind operation. This is the initial state > upon connect(). The issuing of any bind request also > returns the method associated with the connection to bind. > > Also, in regards to getAuthenticationDN(), after rereading the > I-D, I assume it just returns whatever DN was passed into a bind() > method and used as the bind name during the authentication. > > That is: > public String getAuthenticationDN() > > Returns the distinguished name (DN) used as the bind name > during the last successful bind operation. Yes Rob From list@netscape.com Wed Apr 4 12:11:03 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24492 for ; Wed, 4 Apr 2001 12:11:03 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34GAKv17844; Wed, 4 Apr 2001 09:10:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34GAKs05709; Wed, 4 Apr 2001 09:10:20 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 09:10:20 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404081427.00b22850@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 09:11:33 -0700 To: rvh@qsun.mt.att.com (Richard V Huber) From: "Kurt D. Zeilenga" Subject: Re: Comments on Access Control Model draft - grant/deny evaluation rules Cc: ietf-ldapext@netscape.com In-Reply-To: <200104040614.CAA05728@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"TGvmD.A._XB.qd0y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 02:14 AM 4/4/01 -0400, Richard V Huber wrote: >: >Some of the things that I don't think are clear in the current draft: >: > >: > - Groups and roles may contain other groups and roles. Subtrees may >: > contain groups and roles. Since groups, roles, and subtrees are of >: > different precedence, the interactions need to be spelled out. >: >: I would recommend that subtrees, groups and roles not be >: recursively evaluated. > >If groups and roles are not recursively evaluated, I think that the >principle of least surprise will be violated - it won't work the way >people expect it to. Maybe David or someone from the X.500 crowd could comment on why X.500 does not recursively evaluate groups and roles their ACM. X.500(93): nested groups are not supported when evaluating access controls. I note that recursive evaluation could be quite expensive. >: >Precedence of Subjects within a Scope: >: > >: > 1. ipAddress >: >: I don't understand why ipAddress is viewed as being more >: specific than an authzID. >: >: >: > 2. Wildcarded DNS name >: > If multiple wildcarded DNS names are applicable, they are of equal >: > precedence. >: >: I don't understand why ipAddress is viewed as being more >: specific than an authzID. > >Bob Blakley sent some mail about this explaining the precedence. Yes. I'll post a specific message on this subject... >: >: X.501(93) 16.4.2.3 AuthenticationLevel >: AuthenticationLevel defines the minimum requestor authentication level required for this ACIItem. >: > >But then we have to define a well-ordering of authentication levels, >and I believe that is a rathole. And the rathole reopens every time >someone comes out with a new SASL mechanism. Yes, but "simple" and "sasl" are not authentication levels, they are authentication methods. Authenticated simple with transport layer security (w/ a strong cipher) is actually stronger than say CRAM-MD5. But then SASL/EXTERNAL might actually offer less security than CRAM-MD5 (as SASL/EXTERNAL allows the server to choose any suitable authentication identity it might have available to it... including an IP address). Now, I don't mind having support for authentication methods and mechanisms, ie: "none", "simple/anonymous", "simple/unauthenticated", "simple/authenticated", "sasl/mechanism" (where mechanism is any SASL mechanism). and I note that many of these will have questionable value in ACIs. For example, "sasl/external" does not imply any particular authentication level. I would rather we just define four levels: "none" (includes methods/mechanisms: "none", "simple/anonymous", "simple/unauthenticated", and SASL equivalents (none should be used)) "weak" (includes unprotected password methods such as "simple/authenticated" (without TLS*), SASL/PLAIN (without TLS), etc.) "protected" (includes protected password mechanisms such as "simple/authenticated" w/ TLS*, SASL/PLAIN w/ TLS*, SASL/CRAM-MD5, SASL-DIGEST-MD5, etc.) "strong" (includes mechanisms better than "protected" such as SASL/GSSAPI). (* TLS w/ an adequate cipher). Note that such classifications need to be subjective to allow the directory implementor (who may delegate to the admin) which mechanisms fall within what categories. A case in point is SASL/EXTERNAL cannot possibly be categorized unless you know what lower level authentication method was used to produce the identity the implementation chooses to pull up into LDAP. Kurt From list@netscape.com Wed Apr 4 12:57:43 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25828 for ; Wed, 4 Apr 2001 12:57:42 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34GtNv26315; Wed, 4 Apr 2001 09:55:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34GtOY29282; Wed, 4 Apr 2001 09:55:24 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 09:55:24 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 09:54:10 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: java api bind() methods Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACB4163.6815CB6B@coscend.com> References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"mybTOB.A.GJH.6H1y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 08:44 AM 4/4/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> Also, >> > Parameters are: >> > >> > dn If non-null and non-empty, specifies that the >> > connection and all operations through it should >> > be authenticated with dn as the distinguished >> > name. >> >> This implies the provided DN is the authentication identity to >> be associated with the connection. Generally, the authentication >> identity to be associated with the connection is that provided in >> the credentials associated with the SASL mechanism. > > If the provided DN is non-null and non-empty, then it is the credential that will be provided to the SASL mechanism(s). IMO, that's inappropriate for a number of reasons. First, it disallows the client from specifying a different bind name from a SASL authentication identity (which may be useful in some environments). Second, it assumes that the mechanism used supports an identity in the form of an LDAP DN. I note also that mechanisms such as DIGEST-MD5 are designed to work with arbitrary UTF-8 user names and as such two strings which might represent equivalent LDAP DNs are not generally treated as equivalent user names. >If the SASL negotiation is successful, it will be the authentication identity. > > If the provided DN is null or is empty, the SASL mechanism will (unless it is the external or the anonymous mechanism) use a callback to obtain a credential from the application if a callback is available. The SASL callback should be used regardless of whether the provided DN is null or empty. The provided bind DN should ONLY be used as the bind name. From list@netscape.com Wed Apr 4 13:35:59 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26850 for ; Wed, 4 Apr 2001 13:35:59 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34HWXv04546; Wed, 4 Apr 2001 10:32:33 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34HWX228268; Wed, 4 Apr 2001 10:32:33 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 10:32:33 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404100920.00aaeec0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 10:33:53 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: Re: IP Address in the ACM (Was: Comments on Access Control Model - BNF) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"mcQn2B.A.U5G.vq1y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Bob said: >I agree in general that IP addresses shouldn't be used >as identities and that RFC2820 is correct on this count. >However the goal at the time the original model draft was >written was to support (or at least not exclude) things >which existing implementations were already doing, however >misguided they might be from a "pure security" point of >view. Several implementations supported and still >support IP addresses as subject attributes. I note that most implementations actually support IP address with some form of wildcard support. Requiring an ACI value per IP address just doesn't scale. >To your second point, the precedence assignment was based >on the observation that it's usually not a single IP >address which is included in a policy, but a range of IP >addresses. Normally everything within (or everything >except) a specific IP address range is excluded from access >-- REGARDLESS of other attributes. Hence IP address became >the highest precedence -- because the mechanism is essentially >enforcing topology control & hence to be effective has >to be enforced first. Since you did note "IP address range", my general comment is that this subject is less specific than varous other subjects and hence should be lower. Also, as far as implementing "topology controls", non-ACM mechanisms are often far more effective. For example, our server implements "TCP wrappers" (an internal "firewalling" mechanism) to enforce topology controls. We also do support IP addresses in our ACM (only in ACLs, not ACIs), but normally their use is in combination with other factors. Kurt From list@netscape.com Wed Apr 4 13:54:49 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27425 for ; Wed, 4 Apr 2001 13:54:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34Hs3v08737; Wed, 4 Apr 2001 10:54:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34Hs3U10635; Wed, 4 Apr 2001 10:54:03 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 10:54:03 -0700 (PDT) Message-ID: <3ACB5F96.1F40902@coscend.com> Date: Wed, 04 Apr 2001 10:53:26 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: java api bind() methods References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"a2M7NB.A.4kC.4-1y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > At 08:44 AM 4/4/01 -0700, Rob Weltman wrote: > >"Kurt D. Zeilenga" wrote: > >> Also, > >> > Parameters are: > >> > > >> > dn If non-null and non-empty, specifies that the > >> > connection and all operations through it should > >> > be authenticated with dn as the distinguished > >> > name. > >> > >> This implies the provided DN is the authentication identity to > >> be associated with the connection. Generally, the authentication > >> identity to be associated with the connection is that provided in > >> the credentials associated with the SASL mechanism. > > > > If the provided DN is non-null and non-empty, then it is the credential that will be provided to the SASL mechanism(s). > > IMO, that's inappropriate for a number of reasons. First, it > disallows the client from specifying a different bind name > from a SASL authentication identity (which may be useful in > some environments). Second, it assumes that the mechanism > used supports an identity in the form of an LDAP DN. I note > also that mechanisms such as DIGEST-MD5 are designed to work > with arbitrary UTF-8 user names and as such two strings which > might represent equivalent LDAP DNs are not generally treated > as equivalent user names. > > >If the SASL negotiation is successful, it will be the authentication identity. > > > > If the provided DN is null or is empty, the SASL mechanism will (unless it is the external or the anonymous mechanism) use a callback to obtain a credential from the application if a callback is available. > > The SASL callback should be used regardless of whether the provided > DN is null or empty. The provided bind DN should ONLY be used as the > bind name. That is all up to the mechanism implementation. Neither the Java LDAP API implementation nor an application can force a mechanism (which is protocol-independent and most likely from a different supplier than either the LDAP API implementation or the application) to call back to an application. If it decides to call back, it will. If it decides to use the bind DN as sole credential identity, it will do so. If it decides it needs additional credentials, it will request them through a callback. The Java LDAP API neither can nor should define or restrict how a SASL mechanism uses credentials during authentication. Rob From list@netscape.com Wed Apr 4 14:06:44 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27712 for ; Wed, 4 Apr 2001 14:06:44 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34I36S29316; Wed, 4 Apr 2001 11:03:06 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34I36w18407; Wed, 4 Apr 2001 11:03:06 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 11:03:06 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404092749.00b28c20@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 11:04:19 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: java api startTLS() method Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACB45A0.C860A11F@coscend.com> References: <5.0.2.1.0.20010403144107.00ac6070@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"9sYxYC.A.PfE.YH2y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 09:02 AM 4/4/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> >> A few more questions regarding startTLS(). >> >> Does the startTLS() taking any action due to any outstanding >> operations within the session it may be aware of? > > RFC 2830 says that a client MUST NOT attempt startTLS if there are any LDAP operations outstanding on the connection. Yes. But the I-D did not make it clear whether this requirement was the responsibility of the application, the API, or shared between the two. >If there are outstanding LDAP operations on the connection, an LDAPException is thrown (I see that 4.6.42 is missing the exception in its signature, although it is mentioned in the following description). Okay, so the API takes on this responsibility. That is reasonable (but was not all that clear in the current I-D). >> During the processing of the startTLS() call, are there any >> restrictions placed upon the connection and its clones? > > No other operations may be issued on the connection during the processing of the call. An LDAPException is thrown if another operation is requested during the startTLS establishment. > > Clones are independent. Issuing startTLS dissociates a connection from its siblings. I thought clones were only dissociated on disconnect(). Anyways, why would the API dissociate upon startTLS and not SASL bind? Both can establish security associations and protections. From list@netscape.com Wed Apr 4 14:21:26 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28165 for ; Wed, 4 Apr 2001 14:21:25 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34IKfS03370; Wed, 4 Apr 2001 11:20:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34IKfw29797; Wed, 4 Apr 2001 11:20:41 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 11:20:41 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404110802.00b2c120@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 11:21:50 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: java api bind() methods Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACB5F96.1F40902@coscend.com> References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"sd2OS.A.nPH.0X2y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 10:53 AM 4/4/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> >> At 08:44 AM 4/4/01 -0700, Rob Weltman wrote: >> >"Kurt D. Zeilenga" wrote: >> >> Also, >> >> > Parameters are: >> >> > >> >> > dn If non-null and non-empty, specifies that the >> >> > connection and all operations through it should >> >> > be authenticated with dn as the distinguished >> >> > name. >> >> >> >> This implies the provided DN is the authentication identity to >> >> be associated with the connection. Generally, the authentication >> >> identity to be associated with the connection is that provided in >> >> the credentials associated with the SASL mechanism. >> > >> > If the provided DN is non-null and non-empty, then it is the credential that will be provided to the SASL mechanism(s). >> >> IMO, that's inappropriate for a number of reasons. First, it >> disallows the client from specifying a different bind name >> from a SASL authentication identity (which may be useful in >> some environments). Second, it assumes that the mechanism >> used supports an identity in the form of an LDAP DN. I note >> also that mechanisms such as DIGEST-MD5 are designed to work >> with arbitrary UTF-8 user names and as such two strings which >> might represent equivalent LDAP DNs are not generally treated >> as equivalent user names. >> >> >If the SASL negotiation is successful, it will be the authentication identity. >> > >> > If the provided DN is null or is empty, the SASL mechanism will (unless it is the external or the anonymous mechanism) use a callback to obtain a credential from the application if a callback is available. >> >> The SASL callback should be used regardless of whether the provided >> DN is null or empty. The provided bind DN should ONLY be used as the >> bind name. > > That is all up to the mechanism implementation. Neither the Java LDAP API implementation nor an application can force a mechanism (which is protocol-independent and most likely from a different supplier than either the LDAP API implementation or the application) to call back to an application. >If it decides to call back, it will. If it decides to use the bind DN as sole credential identity, it will do so. Only because the API told it that the bind name was the SASL authentication identity. The bind name is NOT the SASL authentication identity. It's whatever the user provides (upon callback or other means) as the SASL authentication identity. >If it decides it needs additional credentials, it will request them through a callback. The Java LDAP API neither can nor should define or restrict how a SASL mechanism uses credentials during authentication. The Java LDAP API should not be providing the bind name as a SASL authentication identity. It should leave the specification of the SASL authentication identity to the application through interaction with SASL API. The LDAP API is just fouling the works by assuming that bind name is or could be the SASL authentication identity. Assuming use of SASL/DIGEST-MD5, how would an application specify the use of a bind name which is different from the DIGEST-MD5 authentication identity in a reliable manner? From list@netscape.com Wed Apr 4 14:57:40 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28985 for ; Wed, 4 Apr 2001 14:57:40 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34IufS10007; Wed, 4 Apr 2001 11:56:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34IufQ27258; Wed, 4 Apr 2001 11:56:41 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 11:56:41 -0700 (PDT) Message-ID: <3ACB6E38.FA01EBDD@coscend.com> Date: Wed, 04 Apr 2001 11:55:52 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: java api startTLS() method References: <5.0.2.1.0.20010403144107.00ac6070@127.0.0.1> <5.0.2.1.0.20010404092749.00b28c20@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"R3JmVB.A.gpG.o52y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > > Clones are independent. Issuing startTLS dissociates a connection from its siblings. > > I thought clones were only dissociated on disconnect(). Anyways, > why would the API dissociate upon startTLS and not SASL bind? Both > can establish security associations and protections. True. On bind, all clones are affected as if they were threads operating on the same connection object: "Reauthenticating in a clone, however, is a global operation which will affect the source object and all associated clones, because it applies to the single shared physical connection. Any request by an associated object after one has reauthenticated will carry the new identity." Rob From list@netscape.com Wed Apr 4 15:03:51 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29083 for ; Wed, 4 Apr 2001 15:03:50 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34J11S11119; Wed, 4 Apr 2001 12:01:03 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34J11U00214; Wed, 4 Apr 2001 12:01:01 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 12:01:01 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404114804.01f5bdd0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 12:02:12 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: java api bind() methods Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACB4163.6815CB6B@coscend.com> References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Mquim.A.uC.q92y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 08:44 AM 4/4/01 -0700, Rob Weltman wrote: >> During an in-progress SASL multiple-step bind operation, what >> happens with one attempt to issue other operations upon the >> same session (via a clone of the connection)? > > Nothing. When a clone begins a bind operation, it is dissociated from its siblings. That seems counter to section 4.6.6. >>>emphasis added<<< The clone can freely modify options and search constraints, and issue requests, without affecting the source object or other clones. If the clone disconnects or reconnects, it is completely dissociated from the source object and other clones. >>>Reauthenticating in a clone, however, is a global operation which will affect the source object and all associated clones, because it applies to the single shared physical connection. Any request by an associated object after one has reauthenticated will carry the new identity.<<< > The fact that in LDAP the supported mechanisms are published outside of an authentication session can and should be used by a Java LDAP API implementation to conserve bandwidth (i.e. not attempt to authenticate with a mechanism not supported by the server) but it doesn't affect the ultimate selection of mechanisms because that is defined by the site configuration of the client and that of the server. The proposed Java LDAP API still allows a client to limit the acceptable mechanisms to a subset of the site-configured ones. There are still cases, such as the existence of some a priori agreement or belief a man-in-the-middle has deleted a particular server supported mechanism, were the client wants to mandate a specific mechanism which is not listed by the server. There is also the more common case where the client just wishes to avoid an unnecessary (to a particular application) discovery exchange. Kurt From list@netscape.com Wed Apr 4 15:57:03 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00119 for ; Wed, 4 Apr 2001 15:57:03 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34Ju5v04202; Wed, 4 Apr 2001 12:56:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34Ju4Y03770; Wed, 4 Apr 2001 12:56:04 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 12:56:04 -0700 (PDT) Date: Wed, 4 Apr 2001 15:55:03 -0400 Message-Id: <200104041955.PAA00232@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: Kurt@openldap.org Subject: Re: Comments on Access Control Model draft - grant/deny evaluation rules Cc: ietf-ldapext@netscape.com Resent-Message-ID: <"ES3RLC.A.15.Qx3y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com : From Kurt@OpenLDAP.org Wed Apr 4 12:09:29 2001 : To: rvh@qsun.mt.att.com (Richard V Huber) : From: "Kurt D. Zeilenga" : Subject: Re: Comments on Access Control Model draft - grant/deny : evaluation rules : Cc: ietf-ldapext@netscape.com : : At 02:14 AM 4/4/01 -0400, Richard V Huber wrote: : >: >Some of the things that I don't think are clear in the current draft: : >: > : >: > - Groups and roles may contain other groups and roles. Subtrees may : >: > contain groups and roles. Since groups, roles, and subtrees are of : >: > different precedence, the interactions need to be spelled out. : >: : >: I would recommend that subtrees, groups and roles not be : >: recursively evaluated. : > : >If groups and roles are not recursively evaluated, I think that the : >principle of least surprise will be violated - it won't work the way : >people expect it to. : : Maybe David or someone from the X.500 crowd could comment on : why X.500 does not recursively evaluate groups and roles their : ACM. I'd like to hear it. There are cases that come up frequently in my life (e.g. tiered support organizations) where nested groups are really important and useful as a way to control administrative overhead and reduce the chances of making security mistakes. Of course, like most useful tools, nested groups can be misused. : X.500(93): : nested groups are not supported when evaluating access controls. : : I note that recursive evaluation could be quite expensive. Yes it could. But only if you use it in a way that MAKES it expensive. It is not expensive for people who do not use nesting or are careful about nesting. Rick Huber From list@netscape.com Wed Apr 4 15:57:06 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00130 for ; Wed, 4 Apr 2001 15:57:05 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34JuJS21565; Wed, 4 Apr 2001 12:56:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34JuKU04135; Wed, 4 Apr 2001 12:56:20 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 12:56:20 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IP Address in the ACM (Was: Comments on Access Control Model - BNF) Date: Wed, 4 Apr 2001 10:59:30 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C0762657406005CE6@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: IP Address in the ACM (Was: Comments on Access Control Model - BNF) Thread-Index: AcC9LluXkump4n0ZSta1Ed+AAzhSQQAAaJTQ From: "Paul Leach" To: "Kurt D. Zeilenga" , X-OriginalArrivalTime: 04 Apr 2001 17:59:30.0671 (UTC) FILETIME=[FF5C8FF0:01C0BD30] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id f34JuFf04062 Resent-Message-ID: <"Jlf8gC.A.v_.gx3y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit I hope that IP addresses as subjects are OPTIONAL, and that the security considerations section is appropriately negative on their security. In fact, I believe they should be a SHOULD NOT in the spec -- i.e., you must have good reason to believe that they are secure before you use them. Paul From list@netscape.com Wed Apr 4 16:07:21 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00336 for ; Wed, 4 Apr 2001 16:07:20 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34K6OS23334; Wed, 4 Apr 2001 13:06:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34K6OQ09729; Wed, 4 Apr 2001 13:06:24 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 13:06:24 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404130054.00aeb660@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 13:07:36 -0700 To: rvh@qsun.mt.att.com (Richard V Huber) From: "Kurt D. Zeilenga" Subject: Re: Comments on Access Control Model draft - grant/deny evaluation rules Cc: ietf-ldapext@netscape.com In-Reply-To: <200104041955.PAA00232@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Dagw1.A.gWC.-63y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 03:55 PM 4/4/01 -0400, Richard V Huber wrote: >: I note that recursive evaluation could be quite expensive. > >Yes it could. But only if you use it in a way that MAKES it >expensive. It is not expensive for people who do not use nesting or >are careful about nesting. I don't think this is true. If an implementation does not support recursion, then it can just check to see if the authorization DN matches one of the members of the group. If the specification requires no recursion, then implementations just need to check the see if the authorization identity is one of the listed members. If the specification requires recursion, then implementations would be required to check to see if any listed member was a group and recurse. Even if there were no nested groups, the check itself can be expensive. Kurt From list@netscape.com Wed Apr 4 16:10:07 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00463 for ; Wed, 4 Apr 2001 16:10:07 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34K9hv07797; Wed, 4 Apr 2001 13:09:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34K9gc11404; Wed, 4 Apr 2001 13:09:42 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 13:09:42 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404130816.00b02a10@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 13:09:42 -0700 To: "Paul Leach" From: "Kurt D. Zeilenga" Subject: RE: IP Address in the ACM (Was: Comments on Access Control Model - BNF) Cc: In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657406005CE6@DF-BOWWOW.platinu m.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Ih1l4B.A.nsC.593y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 10:59 AM 4/4/01 -0700, Paul Leach wrote: >I hope that IP addresses as subjects are OPTIONAL, and that the security >considerations section is appropriately negative on their security. > >In fact, I believe they should be a SHOULD NOT in the spec -- i.e., you >must have good reason to believe that they are secure before you use >them. I concur. I also note that DNS names have all the security concerns of the IP Addresses they are derived from and the DNS system used to generate them. From list@netscape.com Wed Apr 4 16:16:28 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00689 for ; Wed, 4 Apr 2001 16:16:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34KG1S25680; Wed, 4 Apr 2001 13:16:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34KEfI14327; Wed, 4 Apr 2001 13:14:41 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 13:14:41 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404131225.00aebec0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 13:15:38 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: Re: Comments on Access Control Model draft - grant/deny evaluation rules Cc: rvh@qsun.mt.att.com (Richard V Huber) In-Reply-To: <5.0.2.1.0.20010404130054.00aeb660@127.0.0.1> References: <200104041955.PAA00232@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"3RFeaD.A.8dD.pC4y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 01:07 PM 4/4/01 -0700, Kurt D. Zeilenga wrote: >At 03:55 PM 4/4/01 -0400, Richard V Huber wrote: >>: I note that recursive evaluation could be quite expensive. >> >>Yes it could. But only if you use it in a way that MAKES it >>expensive. It is not expensive for people who do not use nesting or >>are careful about nesting. > >I don't think this is true. If an implementation does >not support recursion, then it can just check to see >if the authorization DN matches one of the members of >the group. If the specification requires no recursion, >then implementations just need to check the see if the >authorization identity is one of the listed members. That was a bit redundant... the first "If ..." sentence should be ignored. Sorry for any confusion. >If the specification requires recursion, then implementations >would be required to check to see if any listed member >was a group and recurse. Even if there were no nested >groups, the check itself can be expensive. From list@netscape.com Wed Apr 4 16:41:25 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01447 for ; Wed, 4 Apr 2001 16:41:24 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34Kehv13270; Wed, 4 Apr 2001 13:40:44 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34Keic27507; Wed, 4 Apr 2001 13:40:44 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 13:40:44 -0700 (PDT) Message-ID: <3ACB86A9.78D47321@coscend.com> Date: Wed, 04 Apr 2001 13:40:09 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: java api bind() methods References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> <5.0.2.1.0.20010404110802.00b2c120@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"EFnD2D.A.ZtG.Kb4y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > At 10:53 AM 4/4/01 -0700, Rob Weltman wrote: > >"Kurt D. Zeilenga" wrote: > >> > >> At 08:44 AM 4/4/01 -0700, Rob Weltman wrote: > >> >"Kurt D. Zeilenga" wrote: > >> >> Also, > >> >> > Parameters are: > >> >> > > >> >> > dn If non-null and non-empty, specifies that the > >> >> > connection and all operations through it should > >> >> > be authenticated with dn as the distinguished > >> >> > name. > >> >> > >> >> This implies the provided DN is the authentication identity to > >> >> be associated with the connection. Generally, the authentication > >> >> identity to be associated with the connection is that provided in > >> >> the credentials associated with the SASL mechanism. > >> > > >> > If the provided DN is non-null and non-empty, then it is the credential that will be provided to the SASL mechanism(s). > >> > >> IMO, that's inappropriate for a number of reasons. First, it > >> disallows the client from specifying a different bind name > >> from a SASL authentication identity (which may be useful in > >> some environments). Second, it assumes that the mechanism > >> used supports an identity in the form of an LDAP DN. I note > >> also that mechanisms such as DIGEST-MD5 are designed to work > >> with arbitrary UTF-8 user names and as such two strings which > >> might represent equivalent LDAP DNs are not generally treated > >> as equivalent user names. > >> > >> >If the SASL negotiation is successful, it will be the authentication identity. > >> > > >> > If the provided DN is null or is empty, the SASL mechanism will (unless it is the external or the anonymous mechanism) use a callback to obtain a credential from the application if a callback is available. > >> > >> The SASL callback should be used regardless of whether the provided > >> DN is null or empty. The provided bind DN should ONLY be used as the > >> bind name. > > > > That is all up to the mechanism implementation. Neither the Java LDAP API implementation nor an application can force a mechanism (which is protocol-independent and most likely from a different supplier than either the LDAP API implementation or the application) to call back to an application. > >If it decides to call back, it will. If it decides to use the bind DN as sole credential identity, it will do so. > > Only because the API told it that the bind name was the SASL > authentication identity. The bind name is NOT the SASL > authentication identity. It's whatever the user provides > (upon callback or other means) as the SASL authentication > identity. > > >If it decides it needs additional credentials, it will request them through a callback. The Java LDAP API neither can nor should define or restrict how a SASL mechanism uses credentials during authentication. > > The Java LDAP API should not be providing the bind name as a > SASL authentication identity. It should leave the specification > of the SASL authentication identity to the application through > interaction with SASL API. The LDAP API is just fouling the > works by assuming that bind name is or could be the SASL > authentication identity. > > Assuming use of SASL/DIGEST-MD5, how would an application > specify the use of a bind name which is different from > the DIGEST-MD5 authentication identity in a reliable manner? It might help to show the layers of the SASL implementation: ------------------------- | Application or server | ------------------------- ------------------------- | Protocol driver | ------------------------- ------------------------- | SASL middleware | ------------------------- ------------------ ------------------ ------------------ | SASL mechanism | | SASL mechanism | | SASL mechanism | ------------------ ------------------ ------------------ For a Java application using LDAP, the Java LDAP API implementation is the protocol driver. It shares the SASL middleware layer with other protocol drivers (e.g. imap). It would be wrong for a protocol driver to dictate a certain behavior to the middleware layer, or to a mechanism. For example, it would be wrong to require that for LDAP "The SASL callback should be used regardless of whether the provided DN is null or empty.". There are mechanisms that don't want credentials at all (ANONYMOUS and the anonymous of EXTERNAL) and mechanisms that only know how to deal with a single identity. The Java LDAP API can not and should not impose specific semantics (SASL/DIGEST-MD5 with a user name different from the bind DN) on the middleware layer or on the SASL mechanisms. The semantics of a specific mechanism are implemented by the mechanism. Also, there are LDAP servers that only understand DNs and not usernames or other types of identity (as far as I know it does not conflict with RFC 2251 or other relevant documents for an LDAP server to only accept DNs for authentication, directly or through certificate mapping). A requirement that the bind DN not be the SASL authentication identity would not be reasonable for those servers. Rob From list@netscape.com Wed Apr 4 17:01:14 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01720 for ; Wed, 4 Apr 2001 17:01:14 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34KwmS03314; Wed, 4 Apr 2001 13:58:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34Kwm606533; Wed, 4 Apr 2001 13:58:48 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 13:58:48 -0700 (PDT) Message-Id: <5.0.2.1.2.20010404135419.00a69ec0@pop.walltech.com> X-Sender: bgreenblatt@pop.walltech.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 13:57:24 -0700 To: rvh@qsun.mt.att.com From: Bruce Greenblatt Subject: Re: Comments on Access Control Model draft - grant/deny evaluation rules Cc: ietf-ldapext@netscape.com In-Reply-To: <200104041955.PAA00232@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"tXm-y.A.llB.Gs4y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com >: >: Maybe David or someone from the X.500 crowd could comment on >: why X.500 does not recursively evaluate groups and roles their >: ACM. > >I'd like to hear it. There are cases that come up frequently in my >life (e.g. tiered support organizations) where nested groups are really >important and useful as a way to control administrative overhead and >reduce the chances of making security mistakes. I strongly agree. Nested groups are very useful. If an LDAP server supports the Access Control Model, and it supports nesting of groups, then it certainly ought to support nesting of groups when evaluating access controls. This is one of the strong points of using LDAP to store access control information. >: X.500(93): >: nested groups are not supported when evaluating access controls. >: ============================================== Bruce Greenblatt, Ph. D. Directory Tools and Application Services, Inc. http://www.directory-applications.com From list@netscape.com Wed Apr 4 17:01:17 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01731 for ; Wed, 4 Apr 2001 17:01:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34Kvkv16593; Wed, 4 Apr 2001 13:57:46 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34KvkQ05229; Wed, 4 Apr 2001 13:57:46 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 13:57:46 -0700 (PDT) Message-ID: <3ACB8A93.29E2C875@coscend.com> Date: Wed, 04 Apr 2001 13:56:51 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: java api bind() methods References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404114804.01f5bdd0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"jVKB2.A.TRB.Hr4y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > At 08:44 AM 4/4/01 -0700, Rob Weltman wrote: > >> During an in-progress SASL multiple-step bind operation, what > >> happens with one attempt to issue other operations upon the > >> same session (via a clone of the connection)? > > > > Nothing. When a clone begins a bind operation, it is dissociated from its siblings. > > That seems counter to section 4.6.6. >>>emphasis added<<< > The clone can freely modify options and search constraints, and issue > requests, without affecting the source object or other clones. If the > clone disconnects or reconnects, it is completely dissociated from > the source object and other clones. >>>Reauthenticating in a clone, > however, is a global operation which will affect the source object > and all associated clones, because it applies to the single shared > physical connection. Any request by an associated object after one > has reauthenticated will carry the new identity.<<< True, as I wrote a little earlier today. Since clones continue to share the connection during and after binding, they are subject to the same requirements and behavior as a thread sharing the connection that is doing the bind: "Clients MUST NOT invoke operations between two Bind requests made as part of a multi-stage bind." Invoking an operation while bind is in progress will therefor result in an LDAPException being thrown, just as for a thread invoking an operation on the binding connection. > > The fact that in LDAP the supported mechanisms are published outside of an authentication session can and should be used by a Java LDAP API implementation to conserve bandwidth (i.e. not attempt to authenticate with a mechanism not supported by the server) but it doesn't affect the ultimate selection of mechanisms because that is defined by the site configuration of the client and that of the server. The proposed Java LDAP API still allows a client to limit the acceptable mechanisms to a subset of the site-configured ones. > > There are still cases, such as the existence of some > a priori agreement or belief a man-in-the-middle has > deleted a particular server supported mechanism, were > the client wants to mandate a specific mechanism which > is not listed by the server. There is also the more > common case where the client just wishes to avoid an > unnecessary (to a particular application) discovery > exchange. My comment was a response to your statement: > I am also concerned by this statement: > If mechanisms is null, or if the first version of the method > is called, the LDAP server will be interrogated for its > supportedSaslMechanisms attribute of its root DSE. > > This implies supportedSaslMechanisms is not checked after: > 1) reconnection > 2) StartTLS() > 3) establishment of SASL provided security services How does reading the supported mechanisms of the server help in the cases you describe? If there is an a priori agreement on what mechanism(s) to use, or the client (I assume you mean the application) wants to mandate a specific mechanism, or to avoid a discovery exchange, why would the client even bother to read the supported mechanisms of the server? Rob From list@netscape.com Wed Apr 4 17:10:36 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01887 for ; Wed, 4 Apr 2001 17:10:35 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34L9oS04868; Wed, 4 Apr 2001 14:09:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34L9p212730; Wed, 4 Apr 2001 14:09:51 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 14:09:51 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404135314.00b02420@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 14:10:59 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: java api bind() methods Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACB86A9.78D47321@coscend.com> References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> <5.0.2.1.0.20010404110802.00b2c120@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"cRJj6D.A.aGD.c24y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 01:40 PM 4/4/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> >> At 10:53 AM 4/4/01 -0700, Rob Weltman wrote: >> >"Kurt D. Zeilenga" wrote: >> >> >> >> At 08:44 AM 4/4/01 -0700, Rob Weltman wrote: >> >> >"Kurt D. Zeilenga" wrote: >> >> >> Also, >> >> >> > Parameters are: >> >> >> > >> >> >> > dn If non-null and non-empty, specifies that the >> >> >> > connection and all operations through it should >> >> >> > be authenticated with dn as the distinguished >> >> >> > name. >> >> >> >> >> >> This implies the provided DN is the authentication identity to >> >> >> be associated with the connection. Generally, the authentication >> >> >> identity to be associated with the connection is that provided in >> >> >> the credentials associated with the SASL mechanism. >> >> > >> >> > If the provided DN is non-null and non-empty, then it is the credential that will be provided to the SASL mechanism(s). >> >> >> >> IMO, that's inappropriate for a number of reasons. First, it >> >> disallows the client from specifying a different bind name >> >> from a SASL authentication identity (which may be useful in >> >> some environments). Second, it assumes that the mechanism >> >> used supports an identity in the form of an LDAP DN. I note >> >> also that mechanisms such as DIGEST-MD5 are designed to work >> >> with arbitrary UTF-8 user names and as such two strings which >> >> might represent equivalent LDAP DNs are not generally treated >> >> as equivalent user names. >> >> >> >> >If the SASL negotiation is successful, it will be the authentication identity. >> >> > >> >> > If the provided DN is null or is empty, the SASL mechanism will (unless it is the external or the anonymous mechanism) use a callback to obtain a credential from the application if a callback is available. >> >> >> >> The SASL callback should be used regardless of whether the provided >> >> DN is null or empty. The provided bind DN should ONLY be used as the >> >> bind name. >> > >> > That is all up to the mechanism implementation. Neither the Java LDAP API implementation nor an application can force a mechanism (which is protocol-independent and most likely from a different supplier than either the LDAP API implementation or the application) to call back to an application. >> >If it decides to call back, it will. If it decides to use the bind DN as sole credential identity, it will do so. >> >> Only because the API told it that the bind name was the SASL >> authentication identity. The bind name is NOT the SASL >> authentication identity. It's whatever the user provides >> (upon callback or other means) as the SASL authentication >> identity. >> >> >If it decides it needs additional credentials, it will request them through a callback. The Java LDAP API neither can nor should define or restrict how a SASL mechanism uses credentials during authentication. >> >> The Java LDAP API should not be providing the bind name as a >> SASL authentication identity. It should leave the specification >> of the SASL authentication identity to the application through >> interaction with SASL API. The LDAP API is just fouling the >> works by assuming that bind name is or could be the SASL >> authentication identity. >> >> Assuming use of SASL/DIGEST-MD5, how would an application >> specify the use of a bind name which is different from >> the DIGEST-MD5 authentication identity in a reliable manner? > > It might help to show the layers of the SASL implementation: > > ------------------------- > | Application or server | > ------------------------- > ------------------------- > | Protocol driver | > ------------------------- > ------------------------- > | SASL middleware | > ------------------------- > ------------------ ------------------ ------------------ > | SASL mechanism | | SASL mechanism | | SASL mechanism | > ------------------ ------------------ ------------------ > > For a Java application using LDAP, the Java LDAP API implementation is the protocol driver. It shares the SASL middleware layer with other protocol drivers (e.g. imap). It would be wrong for a protocol driver to dictate a certain behavior to the middleware layer YES! By passing the LDAP bind name to the middleware layer, the LDAP API dictating behavior which should be left to the application. That is, the application should be the one dictating what the value of the bind name is and what the SASL authentication identity is. The LDAP API should not assume that the application wants them to be the same. >, or to a mechanism. For example, it would be wrong to require that for LDAP "The SASL callback should be used regardless of whether the provided DN is null or empty.". My point here is its the application which should drive what is sent as the bind name and what is used as the SASL authentication identity. There are cases where they can and should be different. >There are mechanisms that don't want credentials at all (ANONYMOUS and the anonymous of EXTERNAL) and mechanisms that only know how to deal with a single identity. The Java LDAP API can not and should not impose specific semantics It is impose the semantics that the bind name cannot be different from the user name by providing this value to the SASL middleware layer. The LDAP API should leave this to the application. >(SASL/DIGEST-MD5 with a user name different from the bind DN) on the middleware layer or on the SASL mechanisms. The semantics of a specific mechanism are implemented by the mechanism. > Also, there are LDAP servers that only understand DNs and not usernames or other types of identity (as far as I know it does not conflict with RFC 2251 or other relevant documents for an LDAP server to only accept DNs for authentication, directly or through certificate mapping). And the Application is free to provide a DN as the SASL authentication identity. But there are also LDAP implementations which don't understand DNs as the authentication identity and make use of the bind name, a DN, for other (non-authentication) purposes. This is also not in conflict with RFC 2251/RFC2829. >A requirement that the bind DN not be the SASL authentication identity would not be reasonable for those servers. That's not the requirement I'm after. I'm after the requirement: The DN provided with a bind() call is sent to the server as the bind name. It is not provided to the SASL layer as the authentication identity nor as the authorization identity. The application may provide an authentication identity and/or authorization identity or other information appropriate used by the SASL mechanism to the SASL layer using the facilities of the SASL API. From list@netscape.com Wed Apr 4 17:13:57 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01977 for ; Wed, 4 Apr 2001 17:13:55 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34LDWv20271; Wed, 4 Apr 2001 14:13:33 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34LDXU14972; Wed, 4 Apr 2001 14:13:33 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 14:13:33 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404141216.00b0cb00@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 14:14:47 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: java api bind() methods Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACB8A93.29E2C875@coscend.com> References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404114804.01f5bdd0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"idD8O.A.ipD.854y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 01:56 PM 4/4/01 -0700, Rob Weltman wrote: > How does reading the supported mechanisms of the server help in the cases you describe? The case I raised is an independent issue. That is, the desire for an application to bypass discovery is independent from ensuring the API properly does rediscovery (when not bypassed). From list@netscape.com Wed Apr 4 17:45:08 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02584 for ; Wed, 4 Apr 2001 17:45:08 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34LiXv25676; Wed, 4 Apr 2001 14:44:33 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34LiXo04718; Wed, 4 Apr 2001 14:44:33 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 14:44:33 -0700 (PDT) Message-ID: <3ACB9589.E09E81EE@coscend.com> Date: Wed, 04 Apr 2001 14:43:37 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: java api bind() methods References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> <5.0.2.1.0.20010404110802.00b2c120@127.0.0.1> <5.0.2.1.0.20010404135314.00b02420@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"tk76y.A.7IB.-W5y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > > Also, there are LDAP servers that only understand DNs and not usernames or other types of identity (as far as I know it does not conflict with RFC 2251 or other relevant documents for an LDAP server to only accept DNs for authentication, directly or through certificate mapping). > > And the Application is free to provide a DN as the SASL authentication > identity. But there are also LDAP implementations which don't understand > DNs as the authentication identity and make use of the bind name, > a DN, for other (non-authentication) purposes. This is also not in > conflict with RFC 2251/RFC2829. > > >A requirement that the bind DN not be the SASL authentication identity would not be reasonable for those servers. > > That's not the requirement I'm after. I'm after the requirement: > The DN provided with a bind() call is sent to the server > as the bind name. It is not provided to the SASL layer > as the authentication identity nor as the authorization > identity. The application may provide an authentication > identity and/or authorization identity or other information > appropriate used by the SASL mechanism to the SASL layer > using the facilities of the SASL API. The point is that you cannot require that, because you cannot mandate that a SASL mechanism will use the callback facility (which is all it has at its disposal) to ask the application for an authentication identity. It is up to the SASL mechanism. A DIGEST/MD5 mechanism will ignore the DN provided in the bind() call, send an empty credentials field to the server, and obtain credentials from the user with a callback. It will then use them to create a "digest-response" to send to the server. Other mechanisms will send the DN in the initial SASL bind request. They may or may not request additional credentials from the application. Again, it is up to the mechanism, not the Java LDAP API, to decide what credentials to use, how to use them, and when to obtain them. Rob From list@netscape.com Wed Apr 4 18:16:50 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03084 for ; Wed, 4 Apr 2001 18:16:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34MG7v02126; Wed, 4 Apr 2001 15:16:07 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34MG7c24393; Wed, 4 Apr 2001 15:16:07 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 15:16:07 -0700 (PDT) Message-ID: <3ACB9CFB.57A6E861@coscend.com> Date: Wed, 04 Apr 2001 15:15:23 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: java api bind() methods References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> <5.0.2.1.0.20010404110802.00b2c120@127.0.0.1> <5.0.2.1.0.20010404135314.00b02420@127.0.0.1> <5.0.2.1.0.20010404145256.00b0b680@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Y0l8HD.A.y7F.g05y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > At 02:43 PM 4/4/01 -0700, Rob Weltman wrote: > >"Kurt D. Zeilenga" wrote: > >> > >> > Also, there are LDAP servers that only understand DNs and not usernames or other types of identity (as far as I know it does not conflict with RFC 2251 or other relevant documents for an LDAP server to only accept DNs for authentication, directly or through certificate mapping). > >> > >> And the Application is free to provide a DN as the SASL authentication > >> identity. But there are also LDAP implementations which don't understand > >> DNs as the authentication identity and make use of the bind name, > >> a DN, for other (non-authentication) purposes. This is also not in > >> conflict with RFC 2251/RFC2829. > >> > >> >A requirement that the bind DN not be the SASL authentication identity would not be reasonable for those servers. > >> > >> That's not the requirement I'm after. I'm after the requirement: > >> The DN provided with a bind() call is sent to the server > >> as the bind name. It is not provided to the SASL layer > >> as the authentication identity nor as the authorization > >> identity. The application may provide an authentication > >> identity and/or authorization identity or other information > >> appropriate used by the SASL mechanism to the SASL layer > >> using the facilities of the SASL API. > > > > The point is that you cannot require that, because you cannot mandate that a SASL mechanism will use the callback facility (which is all it has at its disposal) to ask the application for an authentication identity. It is up to the SASL mechanism. A DIGEST/MD5 mechanism will ignore the DN provided in the bind() call, send an empty credentials field to the server, and obtain credentials from the user with a callback. It will then use them to create a "digest-response" to send to the server. Other mechanisms will send the DN in the initial SASL bind request. They may or may not request additional credentials from the application. Again, it is up to the mechanism, not the Java LDAP API, to decide what credentials to use, how to use them, and when to obtain them. > > My point is that it *should* be up to the application to specify > the value it wants to send as the bind name and the value it > wants to use as the authentication identity. If the application > choose them to be the same or different, that's it's choice. > The job of the LDAP API is to provide a means for the application > to provide the value for specific uses, but not to make any > assumptions that a value provided in one use (a bind name) can > or should be used in another use (a SASL authentication identity). > > If the application wants to do a DIGEST-MD5 authentication with > an bind name of "cn=john" and a SASL authentication identity of > "mary", the LDAP API should provide facilities to accomplish. > If this is not possible with the current LDAP API then the API > is flawed. That is supported. It is also supported for a mechanism to not request a separate SASL identity but to either use the bind DN for that or to not use any identity (for ANONYMOUS or SASL). If you broaden the examination to mechanisms other than DIGEST-MD5 I think you will see that it is up to the mechanism, not the application, to decide what credentials are required and how and when to send them to the server. Rob > > Kurt From list@netscape.com Wed Apr 4 18:40:49 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03625 for ; Wed, 4 Apr 2001 18:40:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34Mdmv06545; Wed, 4 Apr 2001 15:39:48 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34MdnM05397; Wed, 4 Apr 2001 15:39:49 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 15:39:49 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404152113.00b07460@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 15:40:59 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: java api bind() methods Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACB9CFB.57A6E861@coscend.com> References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> <5.0.2.1.0.20010404110802.00b2c120@127.0.0.1> <5.0.2.1.0.20010404135314.00b02420@127.0.0.1> <5.0.2.1.0.20010404145256.00b0b680@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"2JdCHB.A.3TB.0K6y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 03:15 PM 4/4/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> If the application wants to do a DIGEST-MD5 authentication with >> an bind name of "cn=john" and a SASL authentication identity of >> "mary", the LDAP API should provide facilities to accomplish. >> If this is not possible with the current LDAP API then the API >> is flawed. > > That is supported. It's not obvious to me how to do it. An example would do wonders. Kurt From list@netscape.com Wed Apr 4 18:51:57 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03916 for ; Wed, 4 Apr 2001 18:51:57 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34MpGv09290; Wed, 4 Apr 2001 15:51:16 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34MpHQ11362; Wed, 4 Apr 2001 15:51:17 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 15:51:17 -0700 (PDT) Date: Wed, 4 Apr 2001 15:46:13 -0700 (PDT) Message-Id: <200104042246.f34Mk0V22467@ywing.netscape.com> From: info@ajmcsl.com.hk To: 126.COM@ywing.aoltw.net, 163.NET@ywing.aoltw.net, 188.NET@ywing.aoltw.net, 21CN.COM@ywing.aoltw.net, 263.NET@ywing.aoltw.net, 371.NET@ywing.aoltw.net, 5415.COM@ywing.aoltw.net, 990.NET@ywing.aoltw.net, BTAMAIL.NET.CN@ywing.aoltw.net, CHINA.COM@ywing.aoltw.net, CMAIL.NET@ywing.aoltw.net, CMMAIL.COM@ywing.aoltw.net, EASTMAIL.COM@ywing.aoltw.net, CN@ywing.aoltw.net, FUN.21CN.COM@ywing.aoltw.net, MAIL.777.NET.CN@ywing.aoltw.net, MAIL.777.NET.CN@ywing.aoltw.net, MAIL.TSINGHUA.EDU.CN@ywing.aoltw.net, PRIVATE.21CN.COM@ywing.aoltw.net, TONGHUA.COM.CN@ywing.aoltw.net, SILKROAD.NET@ywing.aoltw.net, YEAH.NET@ywing.aoltw.net, YNMAIL.COM@ywing.aoltw.net Subject: =?big5?Q?=B1M=B7~=B7|=ADp=A4=CE=B5|=B0=C8=A5=D3=B3=F8?= X-Mailer: VDQslHCT55EcdZF4NhOVA Content-Type: text/plain; X-Priority: 3 X-MSMail-Priority: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by aka.mcom.com id f34MpCf11303 Resent-Message-ID: <"7nCMJB.A.KxC.jV6y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit ³Ð«Ø¥ø·~ÅU°Ý¦³­­¤½¥q ¥»¤½¥q¤w¦¨¥ß¦h¦~¤Î¦³¤j¶qµ|°È¤Î·|­p±M·~¤H¤~,±Mªù³B²z¦U¤½¥q©Î­Ó¤H¦U¶µµ|°È°ÝÃD, ¯à¬°¦U«È¤á¥Ó½Ð¤Î¾¨¶q§Q¥Î¦U¶µ§Kµ|ÃB, ÁקK¦h¥Iµ|´Ú, ¤Î¸Ñ¨M¦h¦~¿n±b? (¤@) µ| °È ³B²z­Ó¤H¤Î¦U¦æ·~¦³­­¤½¥q©ÎµL­­¤½¥q¤§µ|°È¥Ó³ø¨Ã¨ó§U¸Ñµª¦³Ãöµ|°È¤§°ÝÃD¤Îµ|°È¤W¶D, ¥]¬A: ´ä¹ô * §Q±oµ| µL­­¤½¥q/¦³­­¤½¥q 800/1,000¤¸°_ * ª«·~µ| 500¤¸°_ * Á~­Äµ| 500¤¸°_ * ­Ó¤H¤J®§½Òµ| 800¤¸°_ (¤G) ·|­pªA°È ³B²z¦U¦æ·~¦³­­¤½¥q, ¿W¸ê¤Î¦X¹Ù¥Í·N¥þ½L±b¥Ø, ²M²z¿n±b¤ÎÂà°µ¦³­­¤½¥q¤§±b¥Ø, «ö¤ë²z±b, ¥O¦h¤ë¦¬¤ä±b¥Ø¤@¥Ø¤FµM¤Î°]°È¤WÆF¬¡¹B¥Î, ªA°È¤jºõ¦p¤U: * ¨î©w°]°È³ø§iªí¤Î´£¨Ñ¹q¸£²z±b (¥]¬A:·l¯qªí, ¸ê²£­t¶Åªí, ¸Õºâªí) ¤ëµ²/¦~µ² 500.00/1,500¤¸°_ (¤T) ¤½¥q¯µ®Ñ ³B²z¦U¶µ¦³­­¤½¥q¯µ®Ñ¨Æ°È, ¦p§e³øªÑªF©P¦~¤j·|³øªí, µù¥U¦¨¥ß¦³­­¤½¥q, ÁʶR²{¦¨¦³­­¤½¥q, ÂàÅýªÑ¥÷, ¤½¥q°£¦W, §ó§ï¦WºÙ, ªÑ¥÷¤À°t, ¼W¥[¸ê¥», ©e¥ô¸³¨Æ, ¯µ®Ñ¥Nªíµ¥. * ¥N¿ì²z¦¨¥ß¦³­­¤½¥q (¥]¬A: ¥Ó³ø¦UÃþ¤½¥qµù¥U¤å¥ó) 3,800¤¸°_ * ´£¨Ñ¥N²z¤H 2,000¤¸ * ¤½¥q¯µ®ÑªA°È 2,000¤¸ * ¦w±Æ«H°U¤H 2,000¤¸ * ¤½¥q²M½L 10,000¤¸ * ¤½¥q°£¦W 4,000¤¸ ±z¥i¦w§¤¼g¦r¼Ó, ¤@¤Á·|­p¤Îµ|°È°ÝÃD§¡¦³±M¤H¤Wªù¬°±z¸Ñ¨M,¬Ù®É¤è«K Åwªï¸Ñµª¤@¤Áµ|°È°ÝÃD, ¤@«ß§K¶O ¹q¸Ü: 2351 4806 ªL¥ý¥Í¬¢ "¦pªG§A¤£·Q¦¬¨ì¥»¤½¥q©Òµo¥Xªº³oÃþ¸ê®Æ¡A½Ð­P¹q¥»¤½¥q©Î¥H¹q¶l¤è¦¡¡]¹q¶l¦a§}¡Ginfo@ajmcsl.com.hk¡^»P§Ú­ÌÁpµ¸¡A¥H«K¤é«á°±¤î¶Ç°e¸ê®Æµ¹§A¡C" From list@netscape.com Wed Apr 4 18:53:51 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03950 for ; Wed, 4 Apr 2001 18:53:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34M1nS14169; Wed, 4 Apr 2001 15:01:50 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34M1nw14567; Wed, 4 Apr 2001 15:01:49 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 15:01:49 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404145256.00b0b680@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 15:02:32 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: java api bind() methods Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACB9589.E09E81EE@coscend.com> References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> <5.0.2.1.0.20010404110802.00b2c120@127.0.0.1> <5.0.2.1.0.20010404135314.00b02420@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"7qBoC.A.NjD.Mn5y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 02:43 PM 4/4/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> >> > Also, there are LDAP servers that only understand DNs and not usernames or other types of identity (as far as I know it does not conflict with RFC 2251 or other relevant documents for an LDAP server to only accept DNs for authentication, directly or through certificate mapping). >> >> And the Application is free to provide a DN as the SASL authentication >> identity. But there are also LDAP implementations which don't understand >> DNs as the authentication identity and make use of the bind name, >> a DN, for other (non-authentication) purposes. This is also not in >> conflict with RFC 2251/RFC2829. >> >> >A requirement that the bind DN not be the SASL authentication identity would not be reasonable for those servers. >> >> That's not the requirement I'm after. I'm after the requirement: >> The DN provided with a bind() call is sent to the server >> as the bind name. It is not provided to the SASL layer >> as the authentication identity nor as the authorization >> identity. The application may provide an authentication >> identity and/or authorization identity or other information >> appropriate used by the SASL mechanism to the SASL layer >> using the facilities of the SASL API. > > The point is that you cannot require that, because you cannot mandate that a SASL mechanism will use the callback facility (which is all it has at its disposal) to ask the application for an authentication identity. It is up to the SASL mechanism. A DIGEST/MD5 mechanism will ignore the DN provided in the bind() call, send an empty credentials field to the server, and obtain credentials from the user with a callback. It will then use them to create a "digest-response" to send to the server. Other mechanisms will send the DN in the initial SASL bind request. They may or may not request additional credentials from the application. Again, it is up to the mechanism, not the Java LDAP API, to decide what credentials to use, how to use them, and when to obtain them. My point is that it *should* be up to the application to specify the value it wants to send as the bind name and the value it wants to use as the authentication identity. If the application choose them to be the same or different, that's it's choice. The job of the LDAP API is to provide a means for the application to provide the value for specific uses, but not to make any assumptions that a value provided in one use (a bind name) can or should be used in another use (a SASL authentication identity). If the application wants to do a DIGEST-MD5 authentication with an bind name of "cn=john" and a SASL authentication identity of "mary", the LDAP API should provide facilities to accomplish. If this is not possible with the current LDAP API then the API is flawed. Kurt From list@netscape.com Wed Apr 4 19:13:12 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04324 for ; Wed, 4 Apr 2001 19:13:12 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34NC7v12866; Wed, 4 Apr 2001 16:12:07 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34NC7I20825; Wed, 4 Apr 2001 16:12:07 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 16:12:07 -0700 (PDT) Message-ID: <3ACBAA25.175942A@coscend.com> Date: Wed, 04 Apr 2001 16:11:33 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: java api bind() methods References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> <5.0.2.1.0.20010404110802.00b2c120@127.0.0.1> <5.0.2.1.0.20010404135314.00b02420@127.0.0.1> <5.0.2.1.0.20010404145256.00b0b680@127.0.0.1> <5.0.2.1.0.20010404152113.00b07460@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hOevv.A._EF.Gp6y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > At 03:15 PM 4/4/01 -0700, Rob Weltman wrote: > >"Kurt D. Zeilenga" wrote: > >> If the application wants to do a DIGEST-MD5 authentication with > >> an bind name of "cn=john" and a SASL authentication identity of > >> "mary", the LDAP API should provide facilities to accomplish. > >> If this is not possible with the current LDAP API then the API > >> is flawed. > > > > That is supported. > > It's not obvious to me how to do it. An example would > do wonders. > > Kurt class MarysCallbackHandler implements CallbackHandler { public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException { for (int i = 0; i < callbacks.length; i++) { if (callbacks[i] instanceof NameCallback) { NameCallback nc = (NameCallback)callbacks[i]; nc.setName( "mary" ); } else if (callbacks[i] instanceof PasswordCallback) { ... } } } } ... ... ldc.bind( "cn=john", new String[] {"DIGEST-MD5"}, null, new MarysCallbackHandler() ); For how to use callback handlers and callbacks, see http://java.sun.com/security/jaas/doc/api.html#CallbackHandler. Rob From list@netscape.com Wed Apr 4 19:28:40 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04478 for ; Wed, 4 Apr 2001 19:28:40 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34NRqS29013; Wed, 4 Apr 2001 16:27:53 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34NRrw00085; Wed, 4 Apr 2001 16:27:53 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 16:27:53 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404161627.00b269b0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 16:29:08 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: java api bind() methods Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACBAA25.175942A@coscend.com> References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> <5.0.2.1.0.20010404110802.00b2c120@127.0.0.1> <5.0.2.1.0.20010404135314.00b02420@127.0.0.1> <5.0.2.1.0.20010404145256.00b0b680@127.0.0.1> <5.0.2.1.0.20010404152113.00b07460@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"bSO5VD.A.m.336y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 04:11 PM 4/4/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> >> At 03:15 PM 4/4/01 -0700, Rob Weltman wrote: >> >"Kurt D. Zeilenga" wrote: >> >> If the application wants to do a DIGEST-MD5 authentication with >> >> an bind name of "cn=john" and a SASL authentication identity of >> >> "mary", the LDAP API should provide facilities to accomplish. >> >> If this is not possible with the current LDAP API then the API >> >> is flawed. >> > >> > That is supported. >> >> It's not obvious to me how to do it. An example would >> do wonders. >> >> Kurt > > class MarysCallbackHandler implements CallbackHandler { > public void handle(Callback[] callbacks) > throws IOException, UnsupportedCallbackException { > for (int i = 0; i < callbacks.length; i++) { > if (callbacks[i] instanceof NameCallback) { > NameCallback nc = (NameCallback)callbacks[i]; > nc.setName( "mary" ); > } else if (callbacks[i] instanceof PasswordCallback) { > ... > } > } > } > } >... >... > > ldc.bind( "cn=john", > new String[] {"DIGEST-MD5"}, > null, > new MarysCallbackHandler() ); Okay... so the confusion I had must have been this language: dn If non-null and non-empty, specifies that the connection and all operations through it should be authenticated with dn as the distinguished name. Shouldn't this just be: dn The distinguished name to use as the bind name. as clearly in your example it's the callback which is providing the authentication identity. From list@netscape.com Wed Apr 4 19:43:34 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04641 for ; Wed, 4 Apr 2001 19:43:34 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34NeuS01828; Wed, 4 Apr 2001 16:40:57 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34NevQ08820; Wed, 4 Apr 2001 16:40:57 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 16:40:57 -0700 (PDT) Message-ID: <3ACBB0E7.69839B1D@coscend.com> Date: Wed, 04 Apr 2001 16:40:23 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: java api bind() methods References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> <5.0.2.1.0.20010404110802.00b2c120@127.0.0.1> <5.0.2.1.0.20010404135314.00b02420@127.0.0.1> <5.0.2.1.0.20010404145256.00b0b680@127.0.0.1> <5.0.2.1.0.20010404152113.00b07460@127.0.0.1> <5.0.2.1.0.20010404161627.00b269b0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"1HRwTD.A.cJC.IE7y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > Okay... so the confusion I had must have been this language: > > dn If non-null and non-empty, specifies that the > connection and all operations through it should > be authenticated with dn as the distinguished > name. > > Shouldn't this just be: > > dn The distinguished name to use as the bind name. > > as clearly in your example it's the callback which is providing > the authentication identity. Your formulation is fine with me, if it is more clear than what is in the draft. Rob From list@netscape.com Wed Apr 4 19:54:11 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04727 for ; Wed, 4 Apr 2001 19:54:11 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34Nqgv21578; Wed, 4 Apr 2001 16:52:42 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34NqhI16897; Wed, 4 Apr 2001 16:52:43 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 16:52:43 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404164510.00a8ee70@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 16:53:58 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: java api bind() methods Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACBB0E7.69839B1D@coscend.com> References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> <5.0.2.1.0.20010404094324.00b150a0@127.0.0.1> <5.0.2.1.0.20010404110802.00b2c120@127.0.0.1> <5.0.2.1.0.20010404135314.00b02420@127.0.0.1> <5.0.2.1.0.20010404145256.00b0b680@127.0.0.1> <5.0.2.1.0.20010404152113.00b07460@127.0.0.1> <5.0.2.1.0.20010404161627.00b269b0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"_JF9QC.A.nHE.JP7y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 04:40 PM 4/4/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> >> Okay... so the confusion I had must have been this language: >> >> dn If non-null and non-empty, specifies that the >> connection and all operations through it should >> be authenticated with dn as the distinguished >> name. >> >> Shouldn't this just be: >> >> dn The distinguished name to use as the bind name. >> >> as clearly in your example it's the callback which is providing >> the authentication identity. > > > Your formulation is fine with me, if it is more clear than what is in the draft. My only concern would be to ensure that the API is not doing else with this name, such as providing it to the SASL layer as either an authentication or authorization identity, which would cause the example code you provided not to behave as intended. Hence, I would suggest: dn The distinguished name to use as the bind name. This value is not used as either a SASL authentication nor authorization identity. The application provides these identities via other facilities. Detailing these facilities, of course, would be quite appropriate. From list@netscape.com Wed Apr 4 20:49:12 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05244 for ; Wed, 4 Apr 2001 20:49:12 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f350m7S12365; Wed, 4 Apr 2001 17:48:08 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f350heI14489; Wed, 4 Apr 2001 17:43:40 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 17:43:40 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 17:45:04 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: createSaslClient by the Java LDAP API Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"1WEbtB.A.NiD.7-7y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com The Java LDAP API appears to be responsible for calling createSaslClient() method of the Sasl class which requires as a parameter: authorizationID The possibly null protocol-dependent identification to be used for authorization, e.g. user name or distinguished name. When the SASL authentication completes successfully, the entity named by authorizationId is granted access. If null, access is granted to a protocol-dependent default (for example, in LDAP this is the DN in the bind request) How does an application using the Java LDAP API specify the authorizationID it desires? Also, it appears the SASL API property: Sasl.POLICY_NOPLAINTEXT defaults to false. There should be LDAP API requirement that if the application provided properties do not include a an explicit Sasl.POLICY_NOPLAINTEXT setting, the LDAP API MUST set this property to true. Also, QOP ("javax.security.sasl.qop") defaults to 'auth' and not 'auth-conf'. And STRENGTH ("javax.security.sasl.strength") defaults to "high,medium,low". These and other properties should be carefully examined to be sure the LDAP API defaults them consistently with the LDAP SASL "profile" (RFC2251/2829). From list@netscape.com Wed Apr 4 21:35:03 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06399 for ; Wed, 4 Apr 2001 21:35:03 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f351YJv06836; Wed, 4 Apr 2001 18:34:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f351YKA06028; Wed, 4 Apr 2001 18:34:20 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 18:34:20 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404180511.00a88dd0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 18:35:15 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: Re: createSaslClient by the Java LDAP API Cc: rosanna.lee@eng.sun.com, jsr-comments@sun.com In-Reply-To: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"BrCPBD.A.ydB.bu8y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 05:45 PM 4/4/01 -0700, Kurt D. Zeilenga wrote: >The Java LDAP API appears to be responsible for >calling createSaslClient() method of the Sasl class >which requires as a parameter: > > authorizationID The possibly null protocol-dependent > identification to be used for authorization, e.g. > user name or distinguished name. When the SASL > authentication completes successfully, the entity > named by authorizationId is granted access. If > null, access is granted to a protocol-dependent > default (for example, in LDAP this is the DN in > the bind request) A little off-topic for this list, but I note parts of this definition seem inconsistent with RFC 2222 and RFC 2829. I offer this alternative wording which I believe is more consistent with RFC 2222 and RFC 2829. authorizationID The possible null identity which the client is requesting to have the authorization of. If null or empty, the server (not the API) derives an authorization identity from the mechanism authentication identity used. The form of the authorizationID is protocol dependent and defined in the protocol's SASL profile. For example, for LDAP (RFC2829) the authorizationID may be empty (null) or of the form "u:userid" where userid is some arbitrary UTF-8 string or "dn:distinguishedName" where distinguishedName is a string representation (RFC 2253) of a LDAP DN. I would suggest further discussion of the SASL API be directed to the ietf-sasl@imc.org mailing list or other suitable forum. From list@netscape.com Wed Apr 4 23:07:58 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08491 for ; Wed, 4 Apr 2001 23:07:57 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3536PS26690; Wed, 4 Apr 2001 20:06:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3536R206511; Wed, 4 Apr 2001 20:06:27 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 20:06:27 -0700 (PDT) Message-ID: <3ACBE252.2F45A9AB@coscend.com> Date: Wed, 04 Apr 2001 20:11:14 -0700 From: Rob Weltman X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: createSaslClient by the Java LDAP API References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"CqgypC.A.VlB.yE-y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > The Java LDAP API appears to be responsible for > calling createSaslClient() method of the Sasl class > which requires as a parameter: > > authorizationID The possibly null protocol-dependent > identification to be used for authorization, e.g. > user name or distinguished name. When the SASL > authentication completes successfully, the entity > named by authorizationId is granted access. If > null, access is granted to a protocol-dependent > default (for example, in LDAP this is the DN in > the bind request) > > How does an application using the Java LDAP API > specify the authorizationID it desires? As the DN parameter of the bind() operation. The Java LDAP API draft predates RFC 2829 by quite a bit. Perhaps it should change the definition of the parameter to allow a username as alternative to DN. > Also, it appears the SASL API property: > Sasl.POLICY_NOPLAINTEXT > > defaults to false. There should be LDAP API requirement that > if the application provided properties do not include a > an explicit Sasl.POLICY_NOPLAINTEXT setting, the LDAP API > MUST set this property to true. Also, > QOP ("javax.security.sasl.qop") defaults to 'auth' > and not 'auth-conf'. And STRENGTH ("javax.security.sasl.strength") > defaults to "high,medium,low". These and other properties > should be carefully examined to be sure the LDAP API defaults > them consistently with the LDAP SASL "profile" (RFC2251/2829). OK From list@netscape.com Wed Apr 4 23:36:14 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09072 for ; Wed, 4 Apr 2001 23:36:13 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f353ZSv17887; Wed, 4 Apr 2001 20:35:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f353ZUI13660; Wed, 4 Apr 2001 20:35:30 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 20:35:30 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404203024.00a8fb30@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 20:36:46 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: createSaslClient by the Java LDAP API Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACBE252.2F45A9AB@coscend.com> References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"VtpayD.A.CVD.Ag-y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 08:11 PM 4/4/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> >> The Java LDAP API appears to be responsible for >> calling createSaslClient() method of the Sasl class >> which requires as a parameter: >> >> authorizationID The possibly null protocol-dependent >> identification to be used for authorization, e.g. >> user name or distinguished name. When the SASL >> authentication completes successfully, the entity >> named by authorizationId is granted access. If >> null, access is granted to a protocol-dependent >> default (for example, in LDAP this is the DN in >> the bind request) >> >> How does an application using the Java LDAP API >> specify the authorizationID it desires? > > As the DN parameter of the bind() operation. > > The Java LDAP API draft predates RFC 2829 by quite a bit. Perhaps it should change the definition of the parameter to allow a username as alternative to DN. I would suggest the addition of a separate argument to the SASL bind() methods: authzId If not null nor empty, an LDAP authzId (RFC2829). This parameter SHOULD be passed to the SASL layer unmodified. From list@netscape.com Wed Apr 4 23:56:07 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09351 for ; Wed, 4 Apr 2001 23:56:06 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f353tRS00801; Wed, 4 Apr 2001 20:55:27 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f353tSs19551; Wed, 4 Apr 2001 20:55:28 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 20:55:28 -0700 (PDT) Message-Id: <5.0.2.1.0.20010404203941.00a8bcb0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 20:56:47 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: Re: createSaslClient by the Java LDAP API In-Reply-To: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"fPgVH.A.6wE.uy-y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 05:45 PM 4/4/01 -0700, Kurt D. Zeilenga wrote: >Also, it appears the SASL API property: > Sasl.POLICY_NOPLAINTEXT > >defaults to false. There should be LDAP API requirement that >if the application provided properties do not include a >an explicit Sasl.POLICY_NOPLAINTEXT setting, the LDAP API >MUST set this property to true. Also, >QOP ("javax.security.sasl.qop") defaults to 'auth' >and not 'auth-conf'. And STRENGTH ("javax.security.sasl.strength") >defaults to "high,medium,low". These and other properties >should be carefully examined to be sure the LDAP API defaults >them consistently with the LDAP SASL "profile" (RFC2251/2829). I note that this defaulting may be dependent on what level of TLS protections that are in place. For example, if TLS was enabled with a reasonable cipher, then plain text (or equivalent) mechanisms could be enabled. If TLS was established with mutual client/server authentication, then EXTERNAL could be allowed. Kurt From list@netscape.com Thu Apr 5 06:39:59 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26497 for ; Thu, 5 Apr 2001 06:39:59 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35AdsS01418; Thu, 5 Apr 2001 03:39:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35Adv226032; Thu, 5 Apr 2001 03:39:57 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 03:39:57 -0700 (PDT) Message-Id: <200104051039.f35AdaV20806@ywing.netscape.com> From: "Rita de Groot" To: Subject: huidziekte Sender: "Rita de Groot" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Thu, 5 Apr 2001 10:58:47 +0200 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"DW0X8B.A.WWG.7tEz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp. Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien.......... http://www.naardedokter.com/testimonials/sys_lup_eryth.htm From list@netscape.com Thu Apr 5 07:07:35 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27469 for ; Thu, 5 Apr 2001 07:07:35 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35B7Dv23922; Thu, 5 Apr 2001 04:07:14 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35B7Ds03865; Thu, 5 Apr 2001 04:07:13 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 04:07:13 -0700 (PDT) Message-Id: <200104051106.HAA27292@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-opattrs-00.txt Date: Thu, 05 Apr 2001 07:06:19 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"FwYKmB.A.g7.eHFz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LDAPv3: All Operational Attributes Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-opattrs-00.txt Pages : 4 Date : 04-Apr-01 X.500 [X.500] provides a mechanism for clients to request all operational attributes be returned with entries provided in response to a search operation. This mechanism is often used by clients to discover which operational attributes are present in an entry. LDAP [RFC2251] does not provide a similar mechanism to clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-opattrs-00.txt 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-zeilenga-ldap-opattrs-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-zeilenga-ldap-opattrs-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: <20010404074750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-opattrs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-opattrs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010404074750.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Thu Apr 5 07:07:58 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27481 for ; Thu, 5 Apr 2001 07:07:56 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35B73S04101; Thu, 5 Apr 2001 04:07:03 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35B75w03694; Thu, 5 Apr 2001 04:07:05 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 04:07:05 -0700 (PDT) Message-Id: <200104051106.HAA27260@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-zeilenga-ldap-features-00.txt Date: Thu, 05 Apr 2001 07:06:10 -0400 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"gw9bfD.A.S5.WHFz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Feature Discovery in LDAP Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-features-00.txt Pages : 3 Date : 04-Apr-01 LDAP [RFC2251] is an extensible protocol with numerous elective features. LDAP provides specific mechanisms for a client to discover supported protocol versions, control, extended operations, and SASL mechanisms. However, these mechanisms are not designed to support general feature discovery. This document details a simple supported feature discovery mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-features-00.txt 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-zeilenga-ldap-features-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-zeilenga-ldap-features-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: <20010404074732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-features-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-features-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010404074732.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Thu Apr 5 08:59:08 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00438 for ; Thu, 5 Apr 2001 08:59:07 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35Cuov04337; Thu, 5 Apr 2001 05:57:10 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35CupQ00072; Thu, 5 Apr 2001 05:56:51 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 05:56:51 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3ACC6B52.91EE0E1D@Sun.COM> Date: Thu, 05 Apr 2001 14:55:46 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Greenblatt CC: rvh@qsun.mt.att.com, ietf-ldapext@netscape.com Subject: Re: Comments on Access Control Model draft - grant/denyevaluation rules References: <5.0.2.1.2.20010404135419.00a69ec0@pop.walltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"yUFDXD.A.u.RuGz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit I also believe the ability to evaluate nested groups is something that directory users would expect to be able to do and would eventually request--and so is important for the ACM. On the implementation side I think caching group membership is a workable solution that would give acceptable performances. Rob. Bruce Greenblatt wrote: > > >: > >: Maybe David or someone from the X.500 crowd could comment on > >: why X.500 does not recursively evaluate groups and roles their > >: ACM. > > > >I'd like to hear it. There are cases that come up frequently in my > >life (e.g. tiered support organizations) where nested groups are really > >important and useful as a way to control administrative overhead and > >reduce the chances of making security mistakes. > > I strongly agree. Nested groups are very useful. If an LDAP server > supports the Access Control Model, and it supports nesting of groups, then > it certainly ought to support nesting of groups when evaluating access > controls. This is one of the strong points of using LDAP to store access > control information. > > >: X.500(93): > >: nested groups are not supported when evaluating access controls. > >: > > ============================================== > Bruce Greenblatt, Ph. D. > Directory Tools and Application Services, Inc. > http://www.directory-applications.com From list@netscape.com Thu Apr 5 10:05:56 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02710 for ; Thu, 5 Apr 2001 10:05:55 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35E51v11537; Thu, 5 Apr 2001 07:05:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35E51M24780; Thu, 5 Apr 2001 07:05:01 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 07:05:01 -0700 (PDT) Message-Id: <5.0.2.1.0.20010405064659.01f4d6b0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 05 Apr 2001 07:06:14 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: All Operational Attributes In-Reply-To: <200104051106.HAA27292@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"CH_gdC.A.0CG.MuHz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I have written another "All Operational Attributes" proposal based upon the "+" attribute type description approach. The proposal is written as an LDAP extension whereas the original proposal is written as an LDAP update. You'll note the former I-D depends upon a new feature discovery mechanism detailed in . Your comments on these I-D is solicited. Kurt From list@netscape.com Thu Apr 5 10:19:24 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02962 for ; Thu, 5 Apr 2001 10:19:23 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35EIkv13443; Thu, 5 Apr 2001 07:18:46 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35EIkQ29947; Thu, 5 Apr 2001 07:18:46 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 07:18:46 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3ACC7E95.AC4DF400@Sun.COM> Date: Thu, 05 Apr 2001 16:17:57 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Paul Leach , ietf-ldapext@netscape.com Subject: Re: IP Address in the ACM (Was: Comments on Access ControlModel - BNF) References: <5.0.2.1.0.20010404130816.00b02a10@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"iGpqZC.A.hTH.F7Hz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit I don't think we should put optional things in the spec--it will create interoperability problems. I don't see why you are particularly down on ip address subjects, but a subject with simple authentication doesn't seem to bother you. I mean, in practice I would say there is not much difference in the risk involved in granting rights based on ip addresses and granting rights to a subject with an authentication level of "simple". The point is that, depending on the environment, these might well be useful and acceptable ways of granting rights. As such I think we should keep the ip address subject, with the kind of warnings you suggest. Rob. "Kurt D. Zeilenga" wrote: > > At 10:59 AM 4/4/01 -0700, Paul Leach wrote: > >I hope that IP addresses as subjects are OPTIONAL, and that the security > >considerations section is appropriately negative on their security. > > > >In fact, I believe they should be a SHOULD NOT in the spec -- i.e., you > >must have good reason to believe that they are secure before you use > >them. > > I concur. > > I also note that DNS names have all the security concerns of > the IP Addresses they are derived from and the DNS system > used to generate them. From list@netscape.com Thu Apr 5 10:38:41 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03478 for ; Thu, 5 Apr 2001 10:38:41 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35Ecdv16421; Thu, 5 Apr 2001 07:38:39 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35Ecdk08502; Thu, 5 Apr 2001 07:38:39 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 07:38:39 -0700 (PDT) Message-ID: <000036dd7717$00006ae4$00007648@> To: From: bigbird_114@hotmail.com Subject: Enclosed: Financial Info. You Requested. 30280 Date: Thu, 05 Apr 2001 23:23:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Resent-Message-ID: <"76e2yD.A.TEC.tNIz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Are you ready to be successful? I am ready to teach you the secrets I have acquired in creating financial independence. This is not a multi-level marketing, a pyramid scheme or a get rich quick promise. THIS IS A REAL BUSINESS and requires a motivated and teachable individual who is ready to start earning at least $2000 per week, right away; and a SEVEN FIGURE income within the next 2 years. Call me TOLL FREE at 1(888)281-2694 24 hrs / 7 days. I will conduct a brief interview and answer any questions you have. BE A SUCCESSFUL PERSON THAT EVERYONE ADMIRES. Thank you and I hope to hear from you! Jason P.S. Call 1(888)281-2694 Today to Change YOUR Life! To receive no more of these send email to cash4672@yahoo.com From list@netscape.com Thu Apr 5 11:02:59 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04259 for ; Thu, 5 Apr 2001 11:02:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35F2cv19938; Thu, 5 Apr 2001 08:02:38 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35F2cA17458; Thu, 5 Apr 2001 08:02:38 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 08:02:38 -0700 (PDT) Message-ID: <3ACC8A07.F610D879@coscend.com> Date: Thu, 05 Apr 2001 08:06:47 -0700 From: Rob Weltman X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: createSaslClient by the Java LDAP API References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> <5.0.2.1.0.20010404203024.00a8fb30@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"xY0EW.A.NQE.NkIz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > At 08:11 PM 4/4/01 -0700, Rob Weltman wrote: > >"Kurt D. Zeilenga" wrote: > >> > >> The Java LDAP API appears to be responsible for > >> calling createSaslClient() method of the Sasl class > >> which requires as a parameter: > >> > >> authorizationID The possibly null protocol-dependent > >> identification to be used for authorization, e.g. > >> user name or distinguished name. When the SASL > >> authentication completes successfully, the entity > >> named by authorizationId is granted access. If > >> null, access is granted to a protocol-dependent > >> default (for example, in LDAP this is the DN in > >> the bind request) > >> > I would suggest the addition of a separate argument to the > SASL bind() methods: > authzId If not null nor empty, an LDAP authzId (RFC2829). > This parameter SHOULD be passed to the SASL layer > unmodified. That would cause ambiguity if both a DN and an authzId were supplied. Rob From list@netscape.com Thu Apr 5 11:13:27 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04678 for ; Thu, 5 Apr 2001 11:13:27 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35FCMS01486; Thu, 5 Apr 2001 08:12:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35FCLc21767; Thu, 5 Apr 2001 08:12:21 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 08:12:21 -0700 (PDT) Message-Id: <5.0.2.1.0.20010405074208.01f6e7a0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 05 Apr 2001 08:13:20 -0700 To: robert byrne From: "Kurt D. Zeilenga" Subject: Re: IP Address in the ACM (Was: Comments on Access ControlModel - BNF) Cc: Paul Leach , ietf-ldapext@netscape.com In-Reply-To: <3ACC7E95.AC4DF400@Sun.COM> References: <5.0.2.1.0.20010404130816.00b02a10@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"h4fOoB.A.sTF.TtIz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 04:17 PM 4/5/01 +0200, robert byrne wrote: >I don't think we should put optional things in the spec--it will create >interoperability problems. Interoperability at what level? There is nothing in this specification or LDAP that requires two independently developed implementations to act in the same manner given the same data. All that LDAP provides is that the client and server understand what each said; that is "protocol interoperbility" not "application interoperbility." LDAP does not require for implementations to be equally capable. A case in point is that user "foo" in realm "EXAMPLE" (via SASL/DIGEST-MD5) might have the implicit authzid of "u:foo" on one server and "dn:uid=foo,dc=example,dc=com" on one server (even though both hold the copies of the same naming contexts and share the same REALM information). There are obviously significant implications to this at the application level, but not at the protocol level. Please note there are very few MUSTs (or SHALLs) in the ACM technical specification. >I don't see why you are particularly down on ip address subjects, >but a subject with simple authentication doesn't seem to bother you. All of the current authnLevel stuff concerns me greatly. I have posted on this separately. Kurt From list@netscape.com Thu Apr 5 11:16:34 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04737 for ; Thu, 5 Apr 2001 11:16:34 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35FGMv22520; Thu, 5 Apr 2001 08:16:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35FGMI24507; Thu, 5 Apr 2001 08:16:22 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 08:16:22 -0700 (PDT) Message-Id: <5.0.2.1.0.20010405081413.01f757f0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 05 Apr 2001 08:17:28 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: createSaslClient by the Java LDAP API Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACC8A07.F610D879@coscend.com> References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> <5.0.2.1.0.20010404203024.00a8fb30@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"0zE94B.A.j-F.FxIz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 08:06 AM 4/5/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> >> At 08:11 PM 4/4/01 -0700, Rob Weltman wrote: >> >"Kurt D. Zeilenga" wrote: >> >> >> >> The Java LDAP API appears to be responsible for >> >> calling createSaslClient() method of the Sasl class >> >> which requires as a parameter: >> >> >> >> authorizationID The possibly null protocol-dependent >> >> identification to be used for authorization, e.g. >> >> user name or distinguished name. When the SASL >> >> authentication completes successfully, the entity >> >> named by authorizationId is granted access. If >> >> null, access is granted to a protocol-dependent >> >> default (for example, in LDAP this is the DN in >> >> the bind request) >> >> >> I would suggest the addition of a separate argument to the >> SASL bind() methods: >> authzId If not null nor empty, an LDAP authzId (RFC2829). >> This parameter SHOULD be passed to the SASL layer >> unmodified. > > That would cause ambiguity if both a DN and an authzId were supplied. The dn parameter is the bind name, the authzId parameter is the SASL authorization identity. That's a one-to-one API parameter to protocol element relationship, I see no ambiguity. Kurt From list@netscape.com Thu Apr 5 11:32:00 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05398 for ; Thu, 5 Apr 2001 11:31:59 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35FW1S05645; Thu, 5 Apr 2001 08:32:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35FVx603653; Thu, 5 Apr 2001 08:31:59 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 08:31:59 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3ACC8FBD.B351B701@Sun.COM> Date: Thu, 05 Apr 2001 17:31:09 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-ldapext@netscape.com Subject: Re: anonymous & none in the ACM (Was: Comments Access Control Model - authentication levels 2) References: <200103291942.OAA09782@qsun.mt.att.com> <3AC51A2A.D54CE884@openwave.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"9_5MrC.A.c4.t_Iz6"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Just to try to close this one item, is there anyone who thinks we need to differentiate in the ACM between, in the terms of Ellen's very last BNF, "anonymous" and "none" ? > authnLevel = "none" / ; from X.500: name but no password, > same as LDAPBIS unauthenticated > "anonymous" / ; from LDAP: no name and no password Rick says he doesn't care, Kurt says X.500 says they are the same thing (from an access control point of view). They seem pretty similar to me. If we do collapse them both then I would suggest "unauthenticated" as a good name for this kind of authentication level--looks like that's consistent with ldapbis teminology. Rob. Sanjay Panwar wrote: > > I am also not very clear on the differences and meaning of following > subject options. My list is little longer that Richard's. > > 1. null or no authnLevel vs "any" vs "none" vs "anonymous" > (same as the points made in the attached mail) > > 2. null or no subject vs "public:" vs anonymous > Is it legal to define a ACI without a subject ? How should it be > interpreted. How is public different from anonymous or no subject ? > > 3. "group:" vs "role:" > group is defined as the distinguished name of a groupOfNames or > groupOfUniqueNames entry. role is not defined that clearly. Is it the > distinguished name of a organizationalRole entry ? > > - Panwar > > Richard V Huber wrote: > > > The more I read Section 4.2.3, the less I understand the difference > > between "any" as an authnLevel and an omitted authnLevel. > > > > There are three statements in 4.2.3 that I am trying to figure out. > > I'm rephrasing them here: > > > > 1. No authnLevel -> no specific type of authentication is required > > > > 2. LDAP simple auth with no password is 'anonymous' > > > > 3. 'any' -> any mechanism except "no authentication" > > > > So here are my questions: > > > > A. Is an omitted authnLevel equivalent to 'any'? > > > > B. Is an omitted authnLevel equivalent to the union of 'any' and > > 'anonymous'? [This would be a fairly dangerous situation.] > > > > C. Does an omitted authnLevel mean "anyone bound with a non-null user > > ID"? [This seems just about as dangerous as B.] > > > > D. Is there a difference between a BIND with a non-null user ID and > > BIND with a null user ID if the password is null (anonymous and > > more anonymous)? [This is the anonymous vs. unauthenticated issue > > discussed at the LDAPBIS session last week.] > > > > E. If so, does 'anonymous' mean "any or no user ID as long as the > > password is null"? > > > > I think I lean towards YES on A and E, NO on B and C. I could live > > with either answer to D, but if it is YES, we need an explicit > > authnLevel to recognize 'unauthenticated'; it should not be included > > when the ACI omits the authnLevel. > > > > Rick Huber From list@netscape.com Thu Apr 5 11:33:14 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05439 for ; Thu, 5 Apr 2001 11:33:14 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35FV4v25210; Thu, 5 Apr 2001 08:31:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35FV4U02703; Thu, 5 Apr 2001 08:31:04 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 08:31:04 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3ACC8F8A.CD08CD2C@Sun.COM> Date: Thu, 05 Apr 2001 17:30:18 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Paul Leach , ietf-ldapext@netscape.com Subject: Re: IP Address in the ACM (Was: Comments on AccessControlModel - BNF) References: <5.0.2.1.0.20010404130816.00b02a10@127.0.0.1> <5.0.2.1.0.20010405074208.01f6e7a0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"n2A9qB.A.qp.3-Iz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > At 04:17 PM 4/5/01 +0200, robert byrne wrote: > >I don't think we should put optional things in the spec--it will create > >interoperability problems. > > Interoperability at what level? There is nothing in this > specification or LDAP that requires two independently > developed implementations to act in the same manner given the > same data. All that LDAP provides is that the client and > server understand what each said; that is "protocol > interoperbility" not "application interoperbility." LDAP > does not require for implementations to be equally capable. > > A case in point is that user "foo" in realm "EXAMPLE" > (via SASL/DIGEST-MD5) might have the implicit authzid > of "u:foo" on one server and "dn:uid=foo,dc=example,dc=com" > on one server (even though both hold the copies of the same > naming contexts and share the same REALM information). > There are obviously significant implications to this at > the application level, but not at the protocol level. > Well, there is certainly lots of stuff that we have not pinned down in this draft. I hope that that is because they are hard or beyond the scope of the draft. However, not specifying something as optional is definitely within our control and will avoid the situation where one server implements the ip subject and another server does not--simple as that. Rob. > Please note there are very few MUSTs (or SHALLs) in the > ACM technical specification. > > >I don't see why you are particularly down on ip address subjects, > >but a subject with simple authentication doesn't seem to bother you. > > All of the current authnLevel stuff concerns me greatly. I > have posted on this separately. > Kurt From list@netscape.com Thu Apr 5 12:12:38 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06680 for ; Thu, 5 Apr 2001 12:12:37 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35GC8S12498; Thu, 5 Apr 2001 09:12:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35GC7s19918; Thu, 5 Apr 2001 09:12:07 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 09:12:07 -0700 (PDT) Message-Id: <5.0.2.1.0.20010405083950.01f6a670@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 05 Apr 2001 09:12:50 -0700 To: robert byrne From: "Kurt D. Zeilenga" Subject: Re: IP Address in the ACM (Was: Comments on AccessControlModel - BNF) Cc: Paul Leach , ietf-ldapext@netscape.com In-Reply-To: <3ACC8F8A.CD08CD2C@Sun.COM> References: <5.0.2.1.0.20010404130816.00b02a10@127.0.0.1> <5.0.2.1.0.20010405074208.01f6e7a0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"QpsCLB.A.Z1E.TlJz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 05:30 PM 4/5/01 +0200, robert byrne wrote: >However, not specifying something as optional is >definitely within our control and will avoid the situation where one >server implements the ip subject and another server does not--simple as >that. All that is necessary for protocol interoperability is for implementations to recognize the complete syntax. We've training our users not to expect insecure features in our software. We are slowly eliminating these features WITH the support of our user community. Progressing a Standard Track ACM which would require us to add back in features, or preclude us from eliminating them, is a Bad Thing. Kurt From list@netscape.com Thu Apr 5 14:22:18 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10539 for ; Thu, 5 Apr 2001 14:22:16 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35IKqv00500; Thu, 5 Apr 2001 11:20:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35IKqs02111; Thu, 5 Apr 2001 11:20:52 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 11:20:52 -0700 (PDT) Message-Id: <5.0.2.1.0.20010405110227.01f455b0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 05 Apr 2001 11:21:58 -0700 To: robert byrne From: "Kurt D. Zeilenga" Subject: Re: anonymous & none in the ACM (Was: Comments Access Control Model - authentication levels 2) Cc: ietf-ldapext@netscape.com, ietf-ldapext@netscape.com In-Reply-To: <3ACC8FBD.B351B701@Sun.COM> References: <200103291942.OAA09782@qsun.mt.att.com> <3AC51A2A.D54CE884@openwave.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"QlibqD.A.Lg.BeLz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I think we need to decide first whether we are distinguishing authentication methods (none, simple, sasl), authentication mechanisms (none, simple/anonymous, simple/unauthenticated, simple/authenticated,sasl/digest-md5,sasl/external) or authentication levels? "simple" and "sasl" are not authentication levels, but authentication methods. Each has multiple mechanisms. Each mechanism offers different level of authentication which may depend on other factors (such as transport layer security). I see little value in supporting authentication methods in the ACM, however an argument could be made for specific authentication mechanisms. Personally, I see much more value in adding authentication level support. I think one can define simple levels like: "unauthenticated", "weak", "protected", "strong" in a useful and a fairly unambiguous manner. I note that "sasl" and "sasl/external" are quite ambiguous as to the level of authentication provided. Kurt At 05:31 PM 4/5/01 +0200, robert byrne wrote: >Just to try to close this one item, is there anyone who thinks we need >to differentiate in the ACM between, in the terms of Ellen's very last >BNF, "anonymous" and "none" ? > >> authnLevel = "none" / ; from X.500: name but no password, >> same as LDAPBIS unauthenticated >> "anonymous" / ; from LDAP: no name and no password > >Rick says he doesn't care, Kurt says X.500 says they are the same thing >(from an access control point of view). >They seem pretty similar to me. > >If we do collapse them both then I would suggest "unauthenticated" as a >good name for this kind of authentication level--looks like that's >consistent with ldapbis teminology. > >Rob. > >Sanjay Panwar wrote: >> >> I am also not very clear on the differences and meaning of following >> subject options. My list is little longer that Richard's. >> >> 1. null or no authnLevel vs "any" vs "none" vs "anonymous" >> (same as the points made in the attached mail) >> >> 2. null or no subject vs "public:" vs anonymous >> Is it legal to define a ACI without a subject ? How should it be >> interpreted. How is public different from anonymous or no subject ? >> >> 3. "group:" vs "role:" >> group is defined as the distinguished name of a groupOfNames or >> groupOfUniqueNames entry. role is not defined that clearly. Is it the >> distinguished name of a organizationalRole entry ? >> >> - Panwar >> >> Richard V Huber wrote: >> >> > The more I read Section 4.2.3, the less I understand the difference >> > between "any" as an authnLevel and an omitted authnLevel. >> > >> > There are three statements in 4.2.3 that I am trying to figure out. >> > I'm rephrasing them here: >> > >> > 1. No authnLevel -> no specific type of authentication is required >> > >> > 2. LDAP simple auth with no password is 'anonymous' >> > >> > 3. 'any' -> any mechanism except "no authentication" >> > >> > So here are my questions: >> > >> > A. Is an omitted authnLevel equivalent to 'any'? >> > >> > B. Is an omitted authnLevel equivalent to the union of 'any' and >> > 'anonymous'? [This would be a fairly dangerous situation.] >> > >> > C. Does an omitted authnLevel mean "anyone bound with a non-null user >> > ID"? [This seems just about as dangerous as B.] >> > >> > D. Is there a difference between a BIND with a non-null user ID and >> > BIND with a null user ID if the password is null (anonymous and >> > more anonymous)? [This is the anonymous vs. unauthenticated issue >> > discussed at the LDAPBIS session last week.] >> > >> > E. If so, does 'anonymous' mean "any or no user ID as long as the >> > password is null"? >> > >> > I think I lean towards YES on A and E, NO on B and C. I could live >> > with either answer to D, but if it is YES, we need an explicit >> > authnLevel to recognize 'unauthenticated'; it should not be included >> > when the ACI omits the authnLevel. >> > >> > Rick Huber From list@netscape.com Thu Apr 5 15:41:37 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12538 for ; Thu, 5 Apr 2001 15:41:36 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35JfIv17496; Thu, 5 Apr 2001 12:41:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35JfIo21859; Thu, 5 Apr 2001 12:41:18 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 12:41:18 -0700 (PDT) Message-Id: <5.0.2.1.0.20010405120717.01f470e0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 05 Apr 2001 12:43:01 -0700 To: Ellen Stokes From: "Kurt D. Zeilenga" Subject: Re: anonymous & none in the ACM (Was: Comments Access Control Model - authentication levels 2) Cc: robert byrne , ietf-ldapext@netscape.com In-Reply-To: <5.0.2.1.0.20010405133107.00b13d70@popmail2.austin.ibm.com> References: <5.0.2.1.0.20010405110227.01f455b0@127.0.0.1> <3ACC8FBD.B351B701@Sun.COM> <200103291942.OAA09782@qsun.mt.att.com> <3AC51A2A.D54CE884@openwave.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"8xeoUD.A.3UF.dpMz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com How is the use of an authentication method choice of "sasl" useful? Other than saying that some SASL mechanism was used, it's quite meaningless as to the level of authentication it implies. How is the use of an authentication mechanism choice of "sasl/EXTERNAL" useful? Other than saying that some lower level authentication mechanism was used, it's quite meaningless as to the level of authentication it implies. And "simple"... A server can be disallow "simple" when there is inadequate transport level protection. Here, "simple" is "protected" or better. But we could replicate an ACI to a server which didn't have this restriction in place. Here, "simple" is "weak". An application developer could easily expect "simple" to imply the implementations only supported "simple" bind when adequate protections were in place, as recommended by RFC 2829. This might be a false expectation. I do not support inclusion of authentication method/mechanism based subjects in the ACI specification. On the other hand, I do support inclusion of authentication level based subjects in the ACI specification. Yes, terms like "weak", "protected", "strong" are somewhat subjective. However, I believe it's possible to categorize existing standard track mechanisms into these (or similar) categories and to provide guidelines for the categorization of future, private, or other mechanisms which are not explicitly categorized. I am willing to take a stab at putting an 'authentication level' proposal together. There are contentious issues to be sorted out... but I believe the can be sorted out. As far as the 'expected behavior' argument, I believe folks are expecting a higher level of interoperability than can be provided by this specification. They certainly are not going to get 'equally capable' ACI implementations from this (or any) LDAP ACM specification. I note that all current subjects in the ACM have implementation specific behaviors. Kurt At 01:41 PM 4/5/01 -0500, Ellen Stokes wrote: >Kurt, > >We actually had this debate a long time ago both within >the small community working on this draft and also at a >ldapext meeting. > >The smaller group was content to define levels like >unauthenticated, weak, strong, etc as you suggest. >Our thinking here was based on a simplification of >what X.500 defined. > >The push back (big time) was what constituted a >weak authentication level vs a strong authentication level. >What some folks thought was 'strong', others thought >was weak, so the view was it would be difficult to get >consensus and hence expected behavior across vendor >implementations. > >So we decided to (as you would probably say) mix authn >levels with methods and mechanisms, the result being >what you see in the spec. This was consensus. > >Has consensus changed? I'd like to hear from others on this >topic - but I don't want a long drawn out debate because we've >had that already. > >So the question is do we >(1) use somewhat ambiguous terms as Kurt suggests? >(2) agree that the set posted to the mailing list last week is sufficient? >(3) make some small change? > >Ellen > > >At 11:21 AM 4/5/2001 -0700, Kurt D. Zeilenga wrote: >>I think we need to decide first whether we are distinguishing >>authentication methods (none, simple, sasl), authentication >>mechanisms (none, simple/anonymous, simple/unauthenticated, >>simple/authenticated,sasl/digest-md5,sasl/external) or >>authentication levels? >> >>"simple" and "sasl" are not authentication levels, but >>authentication methods. Each has multiple mechanisms. >>Each mechanism offers different level of authentication >>which may depend on other factors (such as transport >>layer security). >> >>I see little value in supporting authentication methods >>in the ACM, however an argument could be made for specific >>authentication mechanisms. >> >>Personally, I see much more value in adding authentication >>level support. I think one can define simple levels like: >>"unauthenticated", "weak", "protected", "strong" in a >>useful and a fairly unambiguous manner. >> >>I note that "sasl" and "sasl/external" are quite ambiguous >>as to the level of authentication provided. >> >>Kurt >> >>At 05:31 PM 4/5/01 +0200, robert byrne wrote: >> >>>Just to try to close this one item, is there anyone who thinks we need >>>to differentiate in the ACM between, in the terms of Ellen's very last >>>BNF, "anonymous" and "none" ? >>> >>>> authnLevel = "none" / ; from X.500: name but no password, >>>> same as LDAPBIS unauthenticated >>>> "anonymous" / ; from LDAP: no name and no password >>> >>>Rick says he doesn't care, Kurt says X.500 says they are the same thing >>>(from an access control point of view). >>>They seem pretty similar to me. >>> >>>If we do collapse them both then I would suggest "unauthenticated" as a >>>good name for this kind of authentication level--looks like that's >>>consistent with ldapbis teminology. >>> >>>Rob. >>> >>>Sanjay Panwar wrote: >>>> >>>> I am also not very clear on the differences and meaning of following >>>> subject options. My list is little longer that Richard's. >>>> >>>> 1. null or no authnLevel vs "any" vs "none" vs "anonymous" >>>> (same as the points made in the attached mail) >>>> >>>> 2. null or no subject vs "public:" vs anonymous >>>> Is it legal to define a ACI without a subject ? How should it be >>>> interpreted. How is public different from anonymous or no subject ? >>>> >>>> 3. "group:" vs "role:" >>>> group is defined as the distinguished name of a groupOfNames or >>>> groupOfUniqueNames entry. role is not defined that clearly. Is it the >>>> distinguished name of a organizationalRole entry ? >>>> >>>> - Panwar >>>> >>>> Richard V Huber wrote: >>>> >>>> > The more I read Section 4.2.3, the less I understand the difference >>>> > between "any" as an authnLevel and an omitted authnLevel. >>>> > >>>> > There are three statements in 4.2.3 that I am trying to figure out. >>>> > I'm rephrasing them here: >>>> > >>>> > 1. No authnLevel -> no specific type of authentication is required >>>> > >>>> > 2. LDAP simple auth with no password is 'anonymous' >>>> > >>>> > 3. 'any' -> any mechanism except "no authentication" >>>> > >>>> > So here are my questions: >>>> > >>>> > A. Is an omitted authnLevel equivalent to 'any'? >>>> > >>>> > B. Is an omitted authnLevel equivalent to the union of 'any' and >>>> > 'anonymous'? [This would be a fairly dangerous situation.] >>>> > >>>> > C. Does an omitted authnLevel mean "anyone bound with a non-null user >>>> > ID"? [This seems just about as dangerous as B.] >>>> > >>>> > D. Is there a difference between a BIND with a non-null user ID and >>>> > BIND with a null user ID if the password is null (anonymous and >>>> > more anonymous)? [This is the anonymous vs. unauthenticated issue >>>> > discussed at the LDAPBIS session last week.] >>>> > >>>> > E. If so, does 'anonymous' mean "any or no user ID as long as the >>>> > password is null"? >>>> > >>>> > I think I lean towards YES on A and E, NO on B and C. I could live >>>> > with either answer to D, but if it is YES, we need an explicit >>>> > authnLevel to recognize 'unauthenticated'; it should not be included >>>> > when the ACI omits the authnLevel. >>>> > >>>> > Rick Huber From list@netscape.com Thu Apr 5 16:53:34 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14123 for ; Thu, 5 Apr 2001 16:53:33 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35KpkS07573; Thu, 5 Apr 2001 13:51:46 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35KpkU05327; Thu, 5 Apr 2001 13:51:46 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 13:51:46 -0700 (PDT) Message-Id: To: ietf-ldapext@netscape.com From: brokerinfo@smallcaptimes.com Reply-To: info@smallcaptimes.com Subject: ITET up 30% since featured at smallcaptimes.com Date: Thu, 05 Apr 2001 16:47:12 -0500 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: CyberCreek Avalanche Millennium ; RSR Build:48351 Resent-Message-ID: <"CxqHZ.A.KSB.grNz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit ITET up 30% since coverage one week ago. Read the entire story at http://www.smallcaptimes.com From list@netscape.com Thu Apr 5 17:53:46 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15415 for ; Thu, 5 Apr 2001 17:53:46 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f34FeqS02261; Wed, 4 Apr 2001 08:40:53 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f34FeqA25270; Wed, 4 Apr 2001 08:40:52 -0700 (PDT) Resent-Date: Wed, 4 Apr 2001 08:40:52 -0700 (PDT) Message-ID: <3ACB4163.6815CB6B@coscend.com> Date: Wed, 04 Apr 2001 08:44:35 -0700 From: Rob Weltman X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: java api bind() methods References: <5.0.2.1.0.20010403104616.00adaec0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"aMcbv.A.6JG.AC0y6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > A few questions regarding the LDAPConnectionbind methods... > > How does bind() interact with outstanding operations which > are implicitly abandoned by the bind request? In particular, > with listeners for outstanding operations? As per RFC 2251 (to "simplify server implementation"), outstanding operations on the connection are abandoned. LDAPListener.getMessageIDs() returns a null-length array and LDAPListener.getResponse() throws an LDAPException. > How does bind() behave when a referral is returned? In > particular, if the referral is successfully chased, what > is the authentication state of the connection? If the API implementation successfully chases the referral and the bind completes successfully, the state of the connection is authenticated. This may or may not make sense in a particular environment. In some cases it may be a sign of an incorrectly configured server. In others there may be a pass-through authentication mechanism in place (such as that of the iPlanet Directory Server). > How does an application cancel an in-progress SASL multiple-step > bind operation? Maybe an empty (not null) mechanism could be > used for this. That is what is suggested by RFC 2251 (issue a new SASL bind request with an empty mechanism name). > During an in-progress SASL multiple-step bind operation, what > happens with one attempt to issue other operations upon the > same session (via a clone of the connection)? Nothing. When a clone begins a bind operation, it is dissociated from its siblings. > The SASL bind() methods appears to negotiate mechanisms between > those requested by the application and those advertised by the > server. If so, is there a way to disable this negotiation and > explicitly mandate the use of a particular mechanism? See below. > I am also concerned by this statement: > If mechanisms is null, or if the first version of the method > is called, the LDAP server will be interrogated for its > supportedSaslMechanisms attribute of its root DSE. > > This implies supportedSaslMechanisms is not checked after: > 1) reconnection > 2) StartTLS() > 3) establishment of SASL provided security services Short summary of SASL mechanism negotiation: successful completion of SASL authentication requires that the client and the server support at least one mechanism in common. If the server supports mechanisms a - d and the client supports mechanisms c - f, they can negotiate authentication using mechanisms c or d. The way a client or server indicates which mechanisms it supports is different for different protocols. LDAP is somewhat unique in that the server publishes a list of supported mechanisms outside of any authentication process. With IMAP, for example, the client just proposes a mechanism and the server either accepts it or rejects it, forcing the client to try various mechanisms until it finds one that the server accepts. [ftp://ftp.isi.edu/in-notes/rfc2222.txt]. The first version of my I-D on a Java SASL binding followed the low-level RFC 2222 sequencing closely. An application would have to try each mechanism it was capable of until it found one that the server accepted. But after discussions with John Myers (author of SASL) and with a couple of the implementors of the Cygnus SASL project at CMU, I modified the I-D to put the responsibility on the middleware (i.e. the API) implementation and on the site administrators instead. As currently envisioned, a site administrator will typically configure the mechanism factories that she will allow applications to use at her site. That configuration may limit the number of mechanisms that are available to a server or client at the site and also establish a priority order among them. An application doesn't need to know anything about them. The Java SASL API implementation is responsible for attempting to use only the site-configured mechanisms and to attempt each one in the site-configured! order. An application can find out afterwards which mechanism was ultimately negotiated, but it cannot (at least not directly) find out which mechanisms were discussed during the negotiations. That is also the approach of the C SASL binding developed at the Cygnus project (at least as it was presented to me by a couple of its developers). The fact that in LDAP the supported mechanisms are published outside of an authentication session can and should be used by a Java LDAP API implementation to conserve bandwidth (i.e. not attempt to authenticate with a mechanism not supported by the server) but it doesn't affect the ultimate selection of mechanisms because that is defined by the site configuration of the client and that of the server. The proposed Java LDAP API still allows a client to limit the acceptable mechanisms to a subset of the site-configured ones. > Also, > > Parameters are: > > > > dn If non-null and non-empty, specifies that the > > connection and all operations through it should > > be authenticated with dn as the distinguished > > name. > > This implies the provided DN is the authentication identity to > be associated with the connection. Generally, the authentication > identity to be associated with the connection is that provided in > the credentials associated with the SASL mechanism. If the provided DN is non-null and non-empty, then it is the credential that will be provided to the SASL mechanism(s). If the SASL negotiation is successful, it will be the authentication identity. If the provided DN is null or is empty, the SASL mechanism will (unless it is the external or the anonymous mechanism) use a callback to obtain a credential from the application if a callback is available. Rob From list@netscape.com Thu Apr 5 18:16:49 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15814 for ; Thu, 5 Apr 2001 18:16:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35MFVv14871; Thu, 5 Apr 2001 15:15:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35MFWY16556; Thu, 5 Apr 2001 15:15:32 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 15:15:32 -0700 (PDT) Message-Id: <5.0.2.1.0.20010405131842.01f4fec0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 05 Apr 2001 15:17:10 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: Authentication Levels for ACMs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"6c79gC.A.QCE.C6Oz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Here is how I suggest authentication levels be described: LDAP supports numerous authentication methods and which offer a wide range of security protections. Some methods support multiple mechanisms. The strength of each mechanism can depend on many variables. While it is possible to develop an access control factor which is a parameterization of the methods, mechanisms, and other variables; practical use of such a factor would be limited. The average directory administrator (or user) has no clue as to what strength (or level) of authentication of a parameterazation like: 'SASL/EXTERNAL/TLS/GSSAPI' or 'SIMPLE/TLS/X.509' implied. The average directory administrator (and user) can understand simple terms like "weak" and "strong". It is possible to define a small set of terms in a general manner allowing for uses of particular mechanisms to be categorized. The following authentication levels (in increasing order of strength) "unauthenticated", "weak", "limited", and "strong" based using terminology defined in [RFC 2828]. The "unauthenticated" level implies an anonymous authentication association. The "weak" level implies that the authentication mechanism is prone to both passive and active attacks. The "limited" level implies that the authentication is protects against passive attacks but may be prone to active attacks. The "strong" level implies the authentication mechanism protects against both passive and active attacks. A RECOMMENDED categorization is offered separately. For each mechanism categorized in the recommendation, implementations SHOULD NOT assign a higher authentication level but MAY assign a lower authentication level. For mechanisms not covered by the recommendation, the implementation SHOULD a conservative level. Implementations SHOULD provide a means for the directory administrator for disabling mechanisms and/or lowering the authentication level associated with a mechanism. ---- I would be willing to provide the RECOMMENDED categorization if the consensus of this WG is to pursue this. Kurt From list@netscape.com Thu Apr 5 23:11:47 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20297 for ; Thu, 5 Apr 2001 23:11:46 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3638LS01047; Thu, 5 Apr 2001 20:08:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3638Mo24835; Thu, 5 Apr 2001 20:08:22 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 20:08:22 -0700 (PDT) Date: Fri, 6 Apr 2001 10:54:30 +0800 (CST) From: Message-Id: <200104060254.KAA0000018503@ns1.npic.ac.cn> To: marketing1@fastermail.com Subject: Be Healthier: Clean Your Indoor Air! Resent-Message-ID: <"o1kSwD.A.rDG.jMTz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com ============================================================ Opt In Club Opportunities Help stamp out spam by going Opt In. ============================================================ ============================== Be Healthier: Clean Your Indoor Air! ============================== In many home and office environments, indoor air contributes to health problems. Visit our site for FREE information concerning the cleaning of your indoor air making it healthier to breathe. WE always have Internet specials! Our products are guaranteed to satisfy. For the Website Address, Send Email To Mailto:cleanair1@yahoo.com ============================================================= To be unsubscribe from future mailings, click the link mailto:unsub14@newmail.net?subject=405 ============================================================= From list@netscape.com Fri Apr 6 00:54:39 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21623 for ; Fri, 6 Apr 2001 00:54:39 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f364pLv00810; Thu, 5 Apr 2001 21:51:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f364pM219130; Thu, 5 Apr 2001 21:51:22 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 21:51:22 -0700 (PDT) Message-ID: <3ACD4C6A.3319597C@worldspot.com> Date: Thu, 05 Apr 2001 21:56:10 -0700 From: Rob Weltman X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Rob Weltman , ietf-ldapext@netscape.com Subject: Re: createSaslClient by the Java LDAP API References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> <5.0.2.1.0.20010404203024.00a8fb30@127.0.0.1> <5.0.2.1.0.20010405081413.01f757f0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"I4fmXD.A.gqE.ItUz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > At 08:06 AM 4/5/01 -0700, Rob Weltman wrote: > >"Kurt D. Zeilenga" wrote: > >> > >> At 08:11 PM 4/4/01 -0700, Rob Weltman wrote: > >> >"Kurt D. Zeilenga" wrote: > >> >> > >> >> The Java LDAP API appears to be responsible for > >> >> calling createSaslClient() method of the Sasl class > >> >> which requires as a parameter: > >> >> > >> >> authorizationID The possibly null protocol-dependent > >> >> identification to be used for authorization, e.g. > >> >> user name or distinguished name. When the SASL > >> >> authentication completes successfully, the entity > >> >> named by authorizationId is granted access. If > >> >> null, access is granted to a protocol-dependent > >> >> default (for example, in LDAP this is the DN in > >> >> the bind request) > >> >> > >> I would suggest the addition of a separate argument to the > >> SASL bind() methods: > >> authzId If not null nor empty, an LDAP authzId (RFC2829). > >> This parameter SHOULD be passed to the SASL layer > >> unmodified. > > > > That would cause ambiguity if both a DN and an authzId were supplied. > > The dn parameter is the bind name, the authzId parameter is the > SASL authorization identity. That's a one-to-one API parameter > to protocol element relationship, I see no ambiguity. OK, but if authzId IS null or empty, then the DN should be used as the SASL authorization identity? Or should the server derive the authorization identity from the authentication identity? For my own edification, not having experience with a directory that handles authzIds other than DNs: What are the respective influences of the authzId and the bind DN (which is not the authentication DN) on the authority of requests issued after successful authentication? Is it possible that one of the two could imply rights which would not be available to the other? Or does the bind DN no longer affect authorization if there is a separate authzId? Rob From list@netscape.com Fri Apr 6 03:57:11 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06129 for ; Fri, 6 Apr 2001 03:57:11 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f367swS19860; Fri, 6 Apr 2001 00:54:58 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f367sx201842; Fri, 6 Apr 2001 00:54:59 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 00:54:59 -0700 (PDT) Message-Id: <5.0.2.1.0.20010405221358.01a4bec0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 06 Apr 2001 00:56:13 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: createSaslClient by the Java LDAP API Cc: Rob Weltman , ietf-ldapext@netscape.com In-Reply-To: <3ACD4C6A.3319597C@worldspot.com> References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> <5.0.2.1.0.20010404203024.00a8fb30@127.0.0.1> <5.0.2.1.0.20010405081413.01f757f0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"1_IJ9.A.Tc.QZXz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 09:56 PM 4/5/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> The dn parameter is the bind name, the authzId parameter is the >> SASL authorization identity. That's a one-to-one API parameter >> to protocol element relationship, I see no ambiguity. > > OK, but if authzId IS null or empty, then the DN should be used as the SASL authorization identity? Or should the server derive the authorization identity from the authentication identity? no, yes. A client should not assert an authorization identity unless it wishes to assume an authorization identity different from that implied by the authentication identity. Also, I note that a client should not assume any authorization identity it might derive from its authentication identity will be treated by the server as being equivalent to the authorization identity it would derived from the authentication identity. >For my own edification, not having experience with a directory that handles authzIds other than DNs: > > What are the respective influences of the authzId and the bind DN (which is not the authentication DN) on the authority of requests issued after successful authentication? In general, server implementations ignore the bind name when provided in a SASL bind request. However, as the language of RFC 2251, 4.2 implies (in an odd way), the server might make use of the bind name when the SASL credentials do not contain an LDAP DN. First, I'll elaborate on possible uses in absence of a client asserted authorization identity. The server could just log the bind name. Or the server could use it to restrict the realms advertised (there was a thread discussing this use some years ago). Or, (as I think the authors of 2251 had in mind), the server can use the bind name to locate an entry associated with authentication identity. This entry might contain the mechanism specific secret and/or other information the server needs for the mechanism. Upon completion of the authentication, the DN of this entry (or other information in the entry) might be used to establish the authorization identity associated with the session. Second, in the present of a client asserted authorization identity, the server may (in addition to the above) rely on this entry to support evaluation of the proxy authorization policy. >Is it possible that one of the two could imply rights which would not be available to the other? Or does the bind DN no longer affect authorization if there is a separate authzId? It is possible that the server might not be able to establish the authentication and/or authorization association without a bind name. However, the rights granted to the client are those associated with the authorization identity regardless of whether it was asserted by the client or derived from the authentication identity. The bind name, at most, would be providing an association between the authentication identity and an entry used to support the authentication/authorization process. Lastly, I note there are a number of security considerations (namely the bind name is not protected by the mechanism) and other practical matters (users should need to know their DNs) which limit cases where a bind name should be provided and used. I generally recommend that clients not specify a bind name and that servers ignore the bind name. However, I do support the SASL bind() methods having both dn and authzid parameters as I believe the API should be complete (support all exchanges allowed by the protocol). Kurt From list@netscape.com Fri Apr 6 05:19:58 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06699 for ; Fri, 6 Apr 2001 05:19:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f369Bbv19442; Fri, 6 Apr 2001 02:11:37 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f369BaE23359; Fri, 6 Apr 2001 02:11:36 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 02:11:36 -0700 (PDT) Date: Fri, 6 Apr 2001 16:58:11 +0800 (CST) From: Message-Id: <200104060858.QAA0000005389@ns1.npic.ac.cn> To: subscribers1@businessweekmail.npic.ac.cn.netscape.com Subject: FOUR PROGRAMS - ONE DOWNLINE - ONE LOW PRICE $10!!! Resent-Message-ID: <"JAjdfB.A.nsF.HhYz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com ============================================================ Opt In Club Opportunities Help stamp out spam by going Opt In. ============================================================ ============================== FOUR PROGRAMS - ONE DOWNLINE - ONE LOW PRICE $10!!! ============================== Need A $5,000 A Month College Education Benefit? We are the only program on or off the Internet that has an "Education Benefit"..... Private School, College or University of your choice, Art School, Law School.... It doesn't matter..... If there is a need for education, we pay up to $5,000 per month..... We don't stop there!!!! There's more!!! Lots More... How about Retirement? Will you have enough salted away to provide you with a carefree life in those golden years? Really? Our Retirement Benefit will pay you $5,000 per month for life!!!!!!! And you don't have to wait 40 years till it's time to enjoy it!!! Check out our other "Benefits" Medical Expense - Up to $15,000 per month New Home Benefit - Up to $50,000 per year New Car Benefit - Up to $25,000 per year Guess what? There's more benefits.... Stop what you're doing.... send an email and request more information on how the Accelerator will change the Internet forever..... You can be a part of Internet history.... If you're on the Internet..... If you're trying to market on the Internet...... One downline..... 4 Programs.... Multiple Checks!!!!! You need to make The Accelerator Program part of your business portfolio..... A $10 dollar program that will change your life.... Join Us>>>>> For complete details Mailto:accelerator1us@yahoo.com?subject=moreinfo ============================================================= To be unsubscribe from future mailings, click the link mailto:unsubscribe12@newmail.net?subject=unsubscribe12 ============================================================= From list@netscape.com Fri Apr 6 08:25:44 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07980 for ; Fri, 6 Apr 2001 08:25:43 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36CMsS08312; Fri, 6 Apr 2001 05:23:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36CMvY06779; Fri, 6 Apr 2001 05:22:57 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 05:22:57 -0700 (PDT) Message-Id: <200104061209.IAA07299@tor-smtp4.attcanada.ca> X-Sender: amazingincome@opportunities.com From: Business Workshop To: "Opportunity Seeker" Date: Fri, 06 Apr 2001 05:19:37 -0700 Subject: Realistic Retirement Possibility Reply-To: amazingincome@opportunities.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0XVCyB.A.RpB.fUbz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Unbelievable Automated Business! Highest payplan in history! *No selling *No boss *No employees *No meetings and no traffic jams. *Very low start up cost and tremendous tax benefits. Our business is an honest, ethical business dedicated to helping you become financially independant in a realistic time frame. Our professionally managed "mutual fund" approach to business assures low risk, stability and a huge income potential. If you follow our plan, you will be able to retire on your present salary in 36 months. The extraordinary compensation system is so unique it has a patent pending! For more information send an email with your First Name and email address in the subject line to jonesandme321@yahoo.com *************************************************** You received this message because you are on our list of people interested in this opportunity, or we have corresponded in the past. To be removed, simply write to gonefromlistnow@hotmail.com, and type the address you want removed in the Subject line. Your own FREE ISP is waiting for you at netzero. Just visit www.netzero.net From list@netscape.com Fri Apr 6 09:26:14 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08853 for ; Fri, 6 Apr 2001 09:26:13 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36DNWS13661; Fri, 6 Apr 2001 06:23:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36DNWs25745; Fri, 6 Apr 2001 06:23:32 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 06:23:32 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3ACDC324.94579852@Sun.COM> Date: Fri, 06 Apr 2001 15:22:44 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Paul Leach , ietf-ldapext@netscape.com Subject: Re: IP Address in the ACM (Was: Comments on AccessControlModel- BNF) References: <5.0.2.1.0.20010404130816.00b02a10@127.0.0.1> <5.0.2.1.0.20010405074208.01f6e7a0@127.0.0.1> <5.0.2.1.0.20010405083950.01f6a670@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"s5jirB.A.5RG.TNcz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > At 05:30 PM 4/5/01 +0200, robert byrne wrote: > >However, not specifying something as optional is > >definitely within our control and will avoid the situation where one > >server implements the ip subject and another server does not--simple as > >that. > > All that is necessary for protocol interoperability is for > implementations to recognize the complete syntax. > So, why don't we just specify the BNF and stop there ? The reason is that the semantic content is important too--and we should be defining this semantics as precisely as we can, in order to arrive with implementations that, all else being equal, are interoperable. > We've training our users not to expect insecure features > in our software. We are slowly eliminating these features > WITH the support of our user community. Progressing a > Standard Track ACM which would require us to add back in > features, or preclude us from eliminating them, is a Bad > Thing. Mmmm...will the next version of your product not allow the ability to grant public access, becuase that's "insecure" ? I suspect not--because in some situations that's a useful policy, explicitly set by the administrator. It seems to me that the same is probably true of an ip-address subject and simple authentication. Rob. > > Kurt From list@netscape.com Fri Apr 6 10:33:08 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10381 for ; Fri, 6 Apr 2001 10:33:08 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36EUGv13796; Fri, 6 Apr 2001 07:30:17 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36EUGs18546; Fri, 6 Apr 2001 07:30:16 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 07:30:16 -0700 (PDT) Message-ID: <3ACDD3C8.52AB5B56@coscend.com> Date: Fri, 06 Apr 2001 07:33:44 -0700 From: Rob Weltman X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en-US,sv,ja MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: createSaslClient by the Java LDAP API References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> <5.0.2.1.0.20010404203024.00a8fb30@127.0.0.1> <5.0.2.1.0.20010405081413.01f757f0@127.0.0.1> <5.0.2.1.0.20010405221358.01a4bec0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"PYwQF.A.XhE.1Ldz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > I generally recommend that clients not specify a bind > name and that servers ignore the bind name. > > However, I do support the SASL bind() methods having both dn > and authzid parameters as I believe the API should be complete > (support all exchanges allowed by the protocol). So now it is clear how to implement the Java LDAP SASL binding, but it is extremely unclear what the server behavior will be if both a DN and an authzid are provided. Certainly not what the authors of RFCs 2222 and 2831 had in mind for SASL and for DIGEST-MD5. Isn't that a big hole? If I was writing an LDAP client application, I would want to know if the DN I provided on a bind request contributes to the rights of the connection, and I would want the behavior to be the same for all LDAPv3 servers. There are major access control implications of indeterminate authorization. Rob From list@netscape.com Fri Apr 6 10:41:13 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10382 for ; Fri, 6 Apr 2001 10:33:08 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36ETWS19813; Fri, 6 Apr 2001 07:29:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36ETW617663; Fri, 6 Apr 2001 07:29:32 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 07:29:32 -0700 (PDT) Message-Id: <5.0.2.1.0.20010406065205.01a4f200@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 06 Apr 2001 07:30:41 -0700 To: robert byrne From: "Kurt D. Zeilenga" Subject: Re: IP Address in the ACM (Was: Comments on AccessControlModel- BNF) Cc: Paul Leach , ietf-ldapext@netscape.com In-Reply-To: <3ACDC324.94579852@Sun.COM> References: <5.0.2.1.0.20010404130816.00b02a10@127.0.0.1> <5.0.2.1.0.20010405074208.01f6e7a0@127.0.0.1> <5.0.2.1.0.20010405083950.01f6a670@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"kpKNWB.A.jTE.HLdz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 03:22 PM 4/6/01 +0200, robert byrne wrote: >Mmmm...will the next version of your product not allow the ability to >grant public access, becuase that's "insecure" ? With "public", we're going to disable it by default and require the administrator take action to enable it when desired. >I suspect not--because >in some situations that's a useful policy, explicitly set by the >administrator. If explicitly set by the administrator, yes. >It seems to me that the same is probably true of an >ip-address subject and simple authentication. If you are not on the Internet, maybe. But on the Internet, use of simple or IP-addressed authentication is not appropriate and we should require implementations to such and, in fact, we should recommend against (i.e. with a SHOULD NOT) support such in our security considerations. Kurt From list@netscape.com Fri Apr 6 11:06:35 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11503 for ; Fri, 6 Apr 2001 11:06:34 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36F40S24285; Fri, 6 Apr 2001 08:04:00 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36F3x201574; Fri, 6 Apr 2001 08:03:59 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 08:03:59 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3ACDDA76.5CE94D64@Sun.COM> Date: Fri, 06 Apr 2001 17:02:14 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Paul Leach , ietf-ldapext@netscape.com Subject: Re: IP Address in the ACM (Was: Comments onAccessControlModel- BNF) References: <5.0.2.1.0.20010404130816.00b02a10@127.0.0.1> <5.0.2.1.0.20010405074208.01f6e7a0@127.0.0.1> <5.0.2.1.0.20010405083950.01f6a670@127.0.0.1> <5.0.2.1.0.20010406065205.01a4f200@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"anJq5.A.DY.drdz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > At 03:22 PM 4/6/01 +0200, robert byrne wrote: > >Mmmm...will the next version of your product not allow the ability to > >grant public access, becuase that's "insecure" ? > > With "public", we're going to disable it by default and require > the administrator take action to enable it when desired. > Do you mean that this action is external to your ACM...ie. it's not that he just has to create an aci granting public access but rather he has to turn on the ability to create such acis, external to the aci system ? > >I suspect not--because > >in some situations that's a useful policy, explicitly set by the > >administrator. > > If explicitly set by the administrator, yes. > > >It seems to me that the same is probably true of an > >ip-address subject and simple authentication. > > If you are not on the Internet, maybe. But on the > Internet, use of simple or IP-addressed authentication > is not appropriate and we should require implementations > to such and, in fact, we should recommend against (i.e. with > a SHOULD NOT) support such in our security considerations. > Well depends what you mean by "the Internet"--is my corporate intranet part of the Internet ? There's a boundary there, but they are connected and they all use IP. The intranet though is generally a less hostile place then the external Internet. LDAP directories are fairly popularly deployed in intranets and it seems to me that if one ACM can accomodate both intranets and the Internet at large then that's a good thing. Developing a different ACM for every type of environment you can think of doesn't sound like a great plan to me. Rob. > Kurt From list@netscape.com Fri Apr 6 11:49:54 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12688 for ; Fri, 6 Apr 2001 11:49:53 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36Fjiv23615; Fri, 6 Apr 2001 08:45:44 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36FjiY18318; Fri, 6 Apr 2001 08:45:44 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 08:45:44 -0700 (PDT) Message-ID: <1537895B1173D1118D9300A0246212B60907BD51@mcdc-atl-4.cdc.gov> X-Sybari-Space: 00000000 00000000 00000000 From: "Stoddard, Lander" To: "'ietf-ldapext@netscape.com'" Subject: FW: Request for LDAP Date: Fri, 6 Apr 2001 11:44:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"grSdQ.A.2dE.nSez6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Dear LDAP standards working group - Please consider the request below. thanks, Lander Lander Stoddard Associate Director for Strategic Planning and Information Management Scientific Resources Program National Center for Infectious Diseases Centers for Disease Control and Prevention lstoddard@cdc.gov -----Original Message----- From: Tim Howes [mailto:howes@loudcloud.com] Sent: Thursday, April 05, 2001 4:34 PM To: Stoddard, Lander Subject: Re: Request for LDAP Hi. Sounds like a reasonable request to me, one I've in fact heard before. You might send it to Mark Wahl or Mark Smith , both of whom are still actively involved in the LDAP standardization process (I am not). Or, you could try sending your request to ietf-ldapext@netscape.com, the LDAP standards working group mailing list. Hope that helps. -- Tim "Stoddard, Lander" wrote: > > Tim - > > I just read your article "LDAP: Use as Directed" Thanks for the great work. > > I am trying to architect a distributed directory and have run into a > functional roadblock that I think should be part of the LDAP spec. I don't > know who else to send this to since I have no entree to the LDAP standards > body. > > The needed functionality is a recursive search for group membership. We can > build something to do this but I think it optimally should be language > independent. It's a common enough problem that I think there should be a > common solution. Consider the following scenario: > > We are going to build a public health directory to manage access to > applications and distribution of information. Tom X is in an organizational > role of State Epidemiologist for State Q. All state epidemiologists are > members of > the group All State Epidemiologists. There are some 50 surveillance > applications for which there is an application role that the state > epidemiologists have access to. After a person authenticates, I want to > present them with a list of authorized applications and approles to choose > from. > > So, there is orgperson object in an orgrole object/group. There is an > orggroup object containing orgrole objects. There is an application group > containing applicationrole groups. With the current LDAP query > functionality, I have to place individual orgperson objects into the approle > groups. > > For ease of directory management, the better thing would be to put the > orggroup into the approle group. Then if Tom X is replaced by Mary Y, the > only change that has to be made is the membership of the orgrole, not the > membership of the org group and 50 approles. I would like an LDAP function > that recursively searches down through the group until it finds all the > orgperson objects and then do a match against the provided DN. And I would > like the LDAP directory to do the work. > > What do you think? Is this a reasonable request that can be submitted? I > know we can code this and distribute the component to our servers, but it > will probably be language specific. Just seems like there ought to be an > LDAP solution. > > thanks for your consideration, > Lander > > Lander Stoddard > Associate Director for Strategic Planning > and Information Management > Scientific Resources Program > National Center for Infectious Diseases > Centers for Disease Control and Prevention > lstoddard@cdc.gov From list@netscape.com Fri Apr 6 12:08:04 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13233 for ; Fri, 6 Apr 2001 12:08:03 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36G5Qv26896; Fri, 6 Apr 2001 09:05:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36G5Qo03726; Fri, 6 Apr 2001 09:05:26 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 09:05:26 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 06 Apr 2001 09:38:36 -0600 From: "Ed Reed" To: Cc: , , , , , "Ed Reed" , Subject: draft-ietf-ldup-subentry-08.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id f36G5Nf03645 Resent-Message-ID: <"OBCyQD.A.U5.Elez6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit Please publish the attached revised internet draft. Abstract: This document describes an administrative model for LDAP, and an object class called ldapSubEntry and a control ldapSubentriesControl (to control the visibility of entries of type ldapSubEntry) that are to be used by directory servers claiming support for the administrative model defined here. ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From list@netscape.com Fri Apr 6 12:35:51 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13993 for ; Fri, 6 Apr 2001 12:35:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36GXHS07511; Fri, 6 Apr 2001 09:33:17 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36GXFM16060; Fri, 6 Apr 2001 09:33:15 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 09:33:15 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 06 Apr 2001 10:06:47 -0600 From: "Ed Reed" To: , Subject: Re: FW: Request for LDAP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id f36GXAf15930 Resent-Message-ID: <"TJyBkC.A.I5D.G_ez6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit Dear Lander - A couple of comments with regard to your request: 1) you should understand that standards progression is a relatively slow process...a good idea, once proposed, will need to be taken up by some number of techology providers (ie, vendors) to consider how best to standardize an approach to the solution, then they'll build products and services which attempt to do the job, and then they'll figure out which approach works well for standarization. In the best of cases, you would expect the process to take a couple of years to have multiple interoperable products on the market place doing what you propose. That may not make the deadline for your project rollout ;-), but that's okay, there are other ways... 2) A number of vendors are working with nested group definitions to provide functionality similar to what you describe. Most of them rely on a centralized database to assist with the list explosion process (ie, the recursive enumeration of group members to obtain the full set of unique members). Previous attempts to do this in the distributed environment without some centralized database to do the recursive enumeration have proven to have such bad performance that many vendors have avoided the whole subject altogether. Centralized indexing databases, like the global catalog in Microsoft's Active Directory Service, and a variety of meta-directory solutions from companies like Critical Path, Novell, etc., are examples of what are still proprietary approaches to the problem, but ones which might meet your immediate needs. Some solutions already provide nested group semantics. 3) You're welcome to join the IETF working group dealing with LDAP features, extensions, and requirements. Please visit http://www.ietf.org/html.charters/ldapext-charter.html for information the working group, and instructions for joining the mailing list. Regards, Ed Reed >>> "Stoddard, Lander" 04/06/01 09:45AM >>> Dear LDAP standards working group - Please consider the request below. thanks, Lander Lander Stoddard Associate Director for Strategic Planning and Information Management Scientific Resources Program National Center for Infectious Diseases Centers for Disease Control and Prevention lstoddard@cdc.gov -----Original Message----- From: Tim Howes [mailto:howes@loudcloud.com] Sent: Thursday, April 05, 2001 4:34 PM To: Stoddard, Lander Subject: Re: Request for LDAP Hi. Sounds like a reasonable request to me, one I've in fact heard before. You might send it to Mark Wahl or Mark Smith , both of whom are still actively involved in the LDAP standardization process (I am not). Or, you could try sending your request to ietf-ldapext@netscape.com, the LDAP standards working group mailing list. Hope that helps. -- Tim "Stoddard, Lander" wrote: > > Tim - > > I just read your article "LDAP: Use as Directed" Thanks for the great work. > > I am trying to architect a distributed directory and have run into a > functional roadblock that I think should be part of the LDAP spec. I don't > know who else to send this to since I have no entree to the LDAP standards > body. > > The needed functionality is a recursive search for group membership. We can > build something to do this but I think it optimally should be language > independent. It's a common enough problem that I think there should be a > common solution. Consider the following scenario: > > We are going to build a public health directory to manage access to > applications and distribution of information. Tom X is in an organizational > role of State Epidemiologist for State Q. All state epidemiologists are > members of > the group All State Epidemiologists. There are some 50 surveillance > applications for which there is an application role that the state > epidemiologists have access to. After a person authenticates, I want to > present them with a list of authorized applications and approles to choose > from. > > So, there is orgperson object in an orgrole object/group. There is an > orggroup object containing orgrole objects. There is an application group > containing applicationrole groups. With the current LDAP query > functionality, I have to place individual orgperson objects into the approle > groups. > > For ease of directory management, the better thing would be to put the > orggroup into the approle group. Then if Tom X is replaced by Mary Y, the > only change that has to be made is the membership of the orgrole, not the > membership of the org group and 50 approles. I would like an LDAP function > that recursively searches down through the group until it finds all the > orgperson objects and then do a match against the provided DN. And I would > like the LDAP directory to do the work. > > What do you think? Is this a reasonable request that can be submitted? I > know we can code this and distribute the component to our servers, but it > will probably be language specific. Just seems like there ought to be an > LDAP solution. > > thanks for your consideration, > Lander > > Lander Stoddard > Associate Director for Strategic Planning > and Information Management > Scientific Resources Program > National Center for Infectious Diseases > Centers for Disease Control and Prevention > lstoddard@cdc.gov ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From list@netscape.com Fri Apr 6 12:51:05 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14270 for ; Fri, 6 Apr 2001 12:51:04 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36Gm8v04717; Fri, 6 Apr 2001 09:48:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36Gm9609245; Fri, 6 Apr 2001 09:48:09 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 09:48:09 -0700 (PDT) Message-Id: <5.0.2.1.0.20010406074205.01a710b0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 06 Apr 2001 09:48:59 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: createSaslClient by the Java LDAP API Cc: ietf-ldapext@netscape.com In-Reply-To: <3ACDD3C8.52AB5B56@coscend.com> References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> <5.0.2.1.0.20010404203024.00a8fb30@127.0.0.1> <5.0.2.1.0.20010405081413.01f757f0@127.0.0.1> <5.0.2.1.0.20010405221358.01a4bec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"mM4a0.A.sPC.GNfz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 07:33 AM 4/6/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> I generally recommend that clients not specify a bind >> name and that servers ignore the bind name. >> >> However, I do support the SASL bind() methods having both dn >> and authzid parameters as I believe the API should be complete >> (support all exchanges allowed by the protocol). > > So now it is clear how to implement the Java LDAP SASL binding, but it is extremely unclear what the server behavior will be if both a DN and an authzid are provided. I would say it's very unclear how a server might use the bind DN regardless of whether an authorization identity was provided or not. >Certainly not what the authors of RFCs 2222 and 2831 had in mind for SASL and for DIGEST-MD5. That might be true. But it seems the authors of RFC 2251 saw the need to ensure clients can provide a bind name when the authentication identity is not a DN. I presume they did so because they saw the need for the server to be able to locate an entry associated with the authentication identity. > Isn't that a big hole? If I was writing an LDAP client application, I would want to know if the DN I provided on a bind request contributes to the rights of the connection, and I would want the behavior to be the same for all LDAPv3 servers. There are major access control implications of indeterminate authorization. Normally the rights of the authentication identity are associated with the connection. If the an authorization identity is asserted and authentication identity has rights to assume this identity, the rights of the authorization identity are associated with the connection. The hole is that some servers might need a bind name to locate a directory entry to make the above happen. Fortunately, servers seem to have found ways not to need a bind name and just ignore the bind name if provided. I suspect one could make a good argument (on the LDAPbis list) that the bind name should always be empty when SASL is used. But, for LDAPext, I suggest we do not get caught up in LDAPbis issues. That is, I suggest this API just support independent setting of the bind name and authorization identity. I would recommend that the description of the bind name and authorization identity parameters both say "generally null." Kurt From list@netscape.com Fri Apr 6 13:23:36 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14991 for ; Fri, 6 Apr 2001 13:23:35 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36HKNS15925; Fri, 6 Apr 2001 10:20:23 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36HKNg23610; Fri, 6 Apr 2001 10:20:23 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 10:20:23 -0700 (PDT) Message-ID: <3ACDFAB3.50CC38B6@coscend.com> Date: Fri, 06 Apr 2001 10:19:47 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext Subject: Re: createSaslClient by the Java LDAP API References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> <5.0.2.1.0.20010404203024.00a8fb30@127.0.0.1> <5.0.2.1.0.20010405081413.01f757f0@127.0.0.1> <5.0.2.1.0.20010405221358.01a4bec0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"YpjwEC.A.cwF.Wrfz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > Second, in the present of a client asserted authorization > identity, the server may (in addition to the above) rely on > this entry to support evaluation of the proxy authorization > policy. What if the entry (pointed to by the DN supplied on bind) implies wide-ranging access rights that should not be granted based on the authzid or the authentication ID? When you say "may", do you mean "MAY" as in RFC 2119? That seems to me to lend itself to an indeterminate and insecure server implementation. Shouldn't there be mandatory behavior in evaluating the authorization policy? Rob From list@netscape.com Fri Apr 6 13:55:18 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15704 for ; Fri, 6 Apr 2001 13:55:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36G8CS03387; Fri, 6 Apr 2001 09:08:12 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36G8AE08147; Fri, 6 Apr 2001 09:08:10 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 09:08:10 -0700 (PDT) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Fri, 06 Apr 2001 09:41:43 -0600 From: "Ed Reed" To: Cc: , , , , , "Ed Reed" , Subject: draft-ietf-ldup-subentry-08.txt (with attachment, this time) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_A7FC5DDB.FF9EF389" Resent-Message-ID: <"Pkt1hD.A.g-B.nnez6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=_A7FC5DDB.FF9EF389 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish the attached (really!) revised draft. Abstract: This document describes an administrative model for LDAP,=20 and an object class called ldapSubEntry and a control=20 ldapSubentriesControl (to control the visibility of entries=20 of type ldapSubEntry) that are to be used by directory=20 servers claiming support for the administrative model=20 defined here.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM --=_A7FC5DDB.FF9EF389 Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-subentry-08.txt" Content-Transfer-Encoding: base64 DQoKCgoKCiBJTlRFUk5FVC1EUkFGVCANCiBkcmFmdC1pZXRmLWxkdXAtc3ViZW50cnktMDgudHh0 IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg RWQgUmVlZCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJlZWQt TWF0dGhld3MsIEluYy4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBcHJpbCA2LCAyMDAxIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgIExEQVAg U3ViZW50cnkgU2NoZW1hIA0KCgogMSAgU3RhdHVzIG9mIHRoaXMgTWVtbyANCgogVGhpcyBkb2N1 bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCANCiBjb25mb3JtYW5jZSB3 aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gDQogIA0KIEludGVy bmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IA0KIEVuZ2lu ZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyANCiBn cm91cHMuIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5n IA0KIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICANCiAgDQogSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiANCiBzaXggbW9udGhz IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSANCiBvdGhlciBk b2N1bWVudHMgYXQgYW55IHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIA0KIEludGVy bmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIA0K IHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIiAgDQogIA0KIFRoZSBsaXN0IG9mIGN1cnJlbnQg SW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiBodHRwOi8vd3d3LmlldGYub3Jn L2lldGYvMWlkLWFic3RyYWN0cy50eHQuICANCiAgDQogVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJh ZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSANCiBhY2Nlc3NlZCBhdCBodHRwOi8vd3d3Lmll dGYub3JnL3NoYWRvdy5odG1sLiANCiAgDQogVGhpcyBJbnRlcm5ldC1EcmFmdCBleHBpcmVzIG9u IE9jdG9iZXIgNiwgMjAwMS4gDQoKCiAyICBBYnN0cmFjdCAvIERlc2NyaXB0aW9uIA0KCiBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBhbiBhZG1pbmlzdHJhdGl2ZSBtb2RlbCBmb3IgTERBUCwgDQog YW5kIGFuIG9iamVjdCBjbGFzcyBjYWxsZWQgbGRhcFN1YkVudHJ5IGFuZCBhIGNvbnRyb2wgDQog bGRhcFN1YmVudHJpZXNDb250cm9sICh0byBjb250cm9sIHRoZSB2aXNpYmlsaXR5IG9mIGVudHJp ZXMgDQogb2YgdHlwZSBsZGFwU3ViRW50cnkpIHRoYXQgYXJlIHRvIGJlIHVzZWQgYnkgZGlyZWN0 b3J5IA0KIHNlcnZlcnMgY2xhaW1pbmcgc3VwcG9ydCBmb3IgdGhlIGFkbWluaXN0cmF0aXZlIG1v ZGVsIA0KIGRlZmluZWQgaGVyZS4gDQoKICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9U IiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgDQogIlNIQUxMIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxE IE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCANCiBhbmQgICJPUFRJT05BTCIgaW4gdGhpcyBk b2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgDQogZGVzY3JpYmVkIGluIFtSRkMyMTE5 XS4gVGhlIHNlY3Rpb25zIGJlbG93IHJlaXRlcmF0ZSB0aGVzZSANCiBkZWZpbml0aW9ucyBhbmQg aW5jbHVkZSBzb21lIGFkZGl0aW9uYWwgb25lcy4gDQoKCiBSZWVkICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxXSANCiAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNiwgMjAwMSAMDQoKCiBJTlRFUk5FVC1EUkFGVCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYgQXByaWwgMjAwMSANCiAgICAgICAgICAg ICAgICAgICAgIExEQVAgU3ViZW50cnkgU2NoZW1hIA0KCiAzICBUYWJsZSBvZiBDb250ZW50cyAN CgogMSAgU3RhdHVzIG9mIHRoaXMgTWVtbyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDEgDQogMiAgQWJzdHJhY3QgLyBEZXNjcmlwdGlvbiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDEgDQogMyAgVGFibGUgb2YgQ29udGVudHMgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIgDQogNCAgQWRtaW5pc3RyYXRpdmUg QXJlYXMgaW4gdGhlIERpcmVjdG9yeSAgICAgICAgICAgICAgICAgICAgICAgIDIgDQogNC4xICBY LjUwMSBBZG1pbmlzdHJhdGl2ZSBNb2RlbCBPdmVydmlldyAgICAgICAgICAgICAgICAgICAgICAg ICAyIA0KIDQuMiAgQW4gTERBUCBBZG1pbmlzdHJhdGl2ZSBNb2RlbCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMyANCiA1ICBPYmplY3QgQ2xhc3MgRGVmaW5pdGlvbnMgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgNCANCiA1LjEgIGxkYXBTdWJFbnRyeSBDbGFzcyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDQgDQogNS4xLjEgICAgIE5h bWluZyBhbmQgU3RydWN0dXJlIGNvbnN0cmFpbnRzICAgICAgICAgICAgICAgICAgICAgICA0IA0K IDUuMS4yICAgICBTY29wZSBSdWxlcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgNSANCiA2ICBWaXNpYmlsaXR5IENvbnRyb2wgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgNiANCiA2LjEgIGxkYXBTdWJlbnRyaWVzQ29udHJvbCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDYgDQogNi4xLjEgICAgIE90aGVyIExE QVAgb3BlcmF0aW9ucyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA2IA0KIDYuMS4y ICAgICBDb3JyZXNwb25kZW5jZSB0byBbWDUxMV0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgNiANCiA3ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgNyANCiA4ICBSZWZlcmVuY2VzICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgNyANCiA5ICBDb3B5cmlnaHQgTm90aWNlICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOCANCiAxMCBBY2tub3dsZWRn ZW1lbnRzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOCANCiAx MSBBdXRob3IncyBBZGRyZXNzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgOSANCiAgDQoKCiA0ICBBZG1pbmlzdHJhdGl2ZSBBcmVhcyBpbiB0aGUgRGlyZWN0b3J5 IA0KCgogNC4xIFguNTAxIEFkbWluaXN0cmF0aXZlIE1vZGVsIE92ZXJ2aWV3IA0KCiBbWDUwMV0g Y29udGFpbnMgdGhlIGRlZmluaXRpdmUgZGVzY3JpcHRpb24gb2YgDQogQWRtaW5pc3RyYXRpdmUg QXJlYXMgYW5kIHRoZWlyIHJvbGUgaW4gdGhlIG1hbmFnZW1lbnQgYW5kIA0KIGFkbWluaXN0cmF0 aW9uIG9mIGRpcmVjdG9yaWVzLiAgVGhlIExEQVAgYWRtaW5pc3RyYXRpdmUgDQogbW9kZWwgZGVm aW5lZCBoZXJlIGlzIGludGVuZGVkIHRvIGJlIGEgY29tcGF0aWJsZSwgcHJvcGVyIA0KIHN1YnNl dCBvZiB0aGUgW1g1MDFdIG1vZGVsLiAgVGhlIGRlc2NyaXB0aW9uIGhlcmUgZHJhd3MgDQogaGVh dmlseSBvbiB0aGUgZGVzY3JpcHRpb25zIGFuZCBjb25jZXB0cyBsYWlkIG91dCBpbiANCiBbWDUw MV0uIA0KICANCiBBbiBhZG1pbmlzdHJhdGl2ZSBhcmVhIGlzIGEgc3ViLXRyZWUgb2YgdGhlIGRp cmVjdG9yeSANCiBpbmZvcm1hdGlvbiB0cmVlLCByb290ZWQgYXQgYW4gYWRtaW5pc3RyYXRpdmUg cG9pbnQgKHRoZSANCiByb290LW1vc3QgZW50cnkgaW4gdGhlIHN1Yi10cmVlKSwgd2hlcmUgYWRt aW5pc3RyYXRpdmUgDQogZW50cmllcyAocGVyaGFwcyBpbmNsdWRpbmcgc3ViZW50cmllcywgb3Bl cmF0aW9uYWwgDQogYXR0cmlidXRlcywgb3IgYm90aCkgYXJlIGxvY2F0ZWQuICBBdXRvbm9tb3Vz IA0KIGFkbWluaXN0cmF0aXZlIGFyZWFzIGFyZSBkaXN0aW5jdCBwYXJ0aXRpb25zIG9mIHRoZSAN CiBkaXJlY3RvcnkgaW5mb3JtYXRpb24gdHJlZSB3aG9zZSBlbnRyaWVzIGFyZSBhbGwgDQogYWRt aW5pc3RlcmVkIGJ5IGEgc2luZ2xlIGFkbWluaXN0cmF0aXZlIGF1dGhvcml0eS4gIEVhY2ggDQog ZW50cnkgaW4gdGhlIGRpcmVjdG9yeSBpbmZvcm1hdGlvbiB0cmVlIGlzIGFkbWluaXN0ZXJlZCBi eSANCiBleGFjdGx5IG9uZSBhdXRvbm9tb3VzIGFkbWluaXN0cmF0aXZlIGF1dGhvcml0eS4gDQog IA0KCiBSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSAyXSANCiAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNiwgMjAwMSANCiAg DA0KCgogSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA2IEFw cmlsIDIwMDEgDQogICAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSANCgog VGhlcmUgbWF5IGJlIG1hbnkgYXNwZWN0cyBvZiBhZG1pbmlzdHJhdGlvbiBkZWZpbmVkIGJ5IHRo ZSANCiBkaXJlY3RvcnkgYW5kIG90aGVyIGFwcGxpY2F0aW9ucyBmb3Igc3BlY2lmaWMgcHVycG9z ZXMsIA0KIHN1Y2ggYXMgc3Vic2NoZW1hIGFkbWluaXN0cmF0aW9uIGFyZWFzLCBhY2Nlc3MgY29u dHJvbCANCiBhZG1pbmlzdHJhdGlvbiBhcmVhcywgY29sbGVjdGl2ZS1hdHRyaWJ1dGUgYWRtaW5p c3RyYXRpb24gDQogYXJlYXMsIGNvbnRleHQgZGVmYXVsdCBhZG1pbmlzdHJhdGl2ZSBhcmVhcywg YW5kIHNlcnZpY2UgDQogYWRtaW5pc3RyYXRpdmUgYXJlYXMuICBXaXRoaW4gYW4gYXV0b25vbW91 cyBhZG1pbmlzdHJhdGl2ZSANCiBhcmVhLCBzcGVjaWZpYyBhZG1pbmlzdHJhdGl2ZSBhcmVhcyBm b3IgdGhlc2UgKGFuZCBvdGhlcikgDQogZGlmZmVyZW50IGFzcGVjdHMgbWF5IG92ZXJsYXAgb25l IGFub3RoZXIuICAgDQogIA0KIFNwZWNpZmljIGFkbWluaXN0cmF0aXZlIGFyZWFzIG1heSBiZSBz dWItcGFydGl0aW9uZWQgYnkgdGhlIA0KIGFwcGxpY2F0aW9ucyBvciBzZXJ2aWNlcyB3aGljaCBk ZWZpbmUgdGhlbSB0byBmYWNpbGl0YXRlIA0KIGRlbGVnYXRpb24gb2YgYXV0aG9yaXR5IG9yIGZv ciBvdGhlciBwdXJwb3Nlcy4gIFRoYXQgbWVhbnMgDQogdGhhdCBhIHNpbmdsZSBlbnRyeSBpbiB0 aGUgZGlyZWN0b3J5IG1heSBiZSBwYXJ0IG9mIG1hbnkgDQogZGlmZmVyZW50IHNwZWNpZmljIGFk bWluaXN0cmF0aXZlIGFyZWFzLCBidXQgb25seSBiZSBwYXJ0IA0KIG9mIG9uZSBzcGVjaWZpYyBh ZG1pbmlzdHJhdGl2ZSBhcmVhIChvciBzdWItYXJlYSkgb2YgZWFjaCANCiBhc3BlY3Qgb2YgYWRt aW5pc3RyYXRpb24uIA0KICANCiBUaGUgW1g1MDFdIHN1YmVudHJ5IHNwZWNpZmljYXRpb24gb3B0 aW9uYWxseSB1c2VzIGEgDQogU3VidHJlZVNwZWNpZmljYXRpb24gdG8gaW5kaWNhdGUgYSBzdWJz ZXQgb2YgZW50cmllcyBpbiBhIA0KIHN1Yi10cmVlIHdpdGggd2hpY2ggdGhlIHN1YmVudHJ5IGlz IGNvbmNlcm5lZC4gIFdoZW4gdGhlIA0KIFN1YnRyZWVTcGVjaWZpY2F0aW9uIGlzIGVtcHR5IHRo ZSBzY29wZSBvZiB0aGUgW1g1MDFdIA0KIHN1YmVudHJ5IGlzIGltcGxpY2l0bHkgZGVmaW5lZCBi eSB0aGUgY29udGV4dCBpbiB3aGljaCBpdCANCiBvY2N1cnMuICAgDQoKIDQuMiBBbiBMREFQIEFk bWluaXN0cmF0aXZlIE1vZGVsIA0KCiBUaGUgYWRtaW5pc3RyYXRpdmUgbW9kZWwgZm9yIExEQVAg ZGVmaW5lZCBoZXJlIGlzIGEgDQogc2ltcGxpZmllZCB2ZXJzaW9uIG9mIHRoZSBvbmUgZGVzY3Jp YmVkIGluIFtYNTAxXSwgaW4gdGhhdCANCiB0aGUgc2NvcGUgZGVmaW5lZCBmb3IgdGhlIGxkYXBT dWJlbnRyeSBvYmplY3QgY2xhc3MgaXMgDQogbGltaXRlZC4gICANCiAgDQogVGhlIExEQVAgU3Vi ZW50cnkgZGVmaW5pdGlvbiBiZWxvdyBzcGVjaWZpY2FsbHkgZG9lcyBub3QgDQogaW5jbHVkZSBh IFN1YnRyZWVTcGVjaWZpY2F0aW9uLCBzbyBpdHMgc2NvcGUgaXMgZXhwbGljaXRseSANCiB0aGUg Y29tcGxldGUgc2V0IG9mIGVudHJpZXMgaW4gdGhlIHNwZWNpZmljIGFkbWluaXN0cmF0aXZlIA0K IGFyZWEgKG9yIHN1Yi1hcmVhKSBpbiB3aGljaCBpdCBvY2N1cnMuICBBbGwgYWRtaW5pc3RyYXRp dmUgDQogYXJlYXMgYXJlIGNvbnNpZGVyZWQgdG8gYmUgc3BlY2lmaWMgYWRtaW5pc3RyYXRpdmUg YXJlYXMgDQogd2l0aGluIGFuIGF1dG9ub21vdXMgYWRtaW5pc3RyYXRpdmUgYXJlYS4gICANCiAg DQogSWYgYSBzcGVjaWZpYyBhZG1pbmlzdHJhdGlvbiBhcmVhIGlzIG5vdCBwYXJ0aXRpb25lZCwg dGhlbiANCiBpdHMgZXh0ZW50IChvciBzY29wZSkgaXMgc2FpZCB0byBiZSB0aGF0IG9mIHRoZSBh dXRvbm9tb3VzIA0KIGFkbWluaXN0cmF0aXZlIGFyZWEgaW4gd2hpY2ggaXQgaXMgZGVmaW5lZC4g DQogIA0KIEFwcGxpY2F0aW9ucyBhbmQgc2VydmljZXMgd2hpY2ggZGVmaW5lIHNwZWNpZmljIA0K IGFkbWluaXN0cmF0aXZlIGFyZWFzIG11c3Qgc3BlY2lmeSB3aGV0aGVyIHRoZSBhcmVhcyBtYXkg YmUgDQogcGFydGl0aW9uZWQgb3Igbm90LiAgQnkgZGVmYXVsdCwgdGhlIHNjb3BlIG9mIExEQVAg DQogU3ViZW50cmllcyBpcyBsaW1pdGVkIHRvIHRoZSBzdWItYXJlYSBvZiB0aGUgcGFydGl0aW9u ZWQgDQogc3BlY2lmaWMgYWRtaW5pc3RyYXRpdmUgYXJlYSBpbiB3aGljaCB0aGV5IGFyZSBwcmVz ZW50LiAgDQoKCiBSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSAzXSANCiAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNiwgMjAw MSANCiAgDA0KCgogSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA2IEFwcmlsIDIwMDEgDQogICAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVt YSANCgogNSAgT2JqZWN0IENsYXNzIERlZmluaXRpb24gDQoKCiA1LjEgbGRhcFN1YkVudHJ5IENs YXNzIA0KCiAoIDIuMTYuODQwLjEuMTEzNzE5LjIuMTQyLjYuMS4xIE5BTUUgJ2xkYXBTdWJFbnRy eScgIA0KICAgIERFU0MgJ0xEQVAgU3ViZW50cnkgY2xhc3MsIHZlcnNpb24gMScgIA0KICAgICAg U1VQIHRvcCBTVFJVQ1RVUkFMICANCiAgICAgIE1BWSAoIGNuICkgKSAgDQoKIFRoZSBjbGFzcyBs ZGFwU3ViRW50cnkgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBhcyBhIHN1cGVyLQ0KIGNsYXNzIHdo ZW4gZGVmaW5pbmcgb3RoZXIgc3RydWN0dXJhbCBjbGFzc2VzIHRvIGJlIHVzZWQgYXMgDQogTERB UCBTdWJlbnRyaWVzLCBhbmQgYXMgdGhlIHN0cnVjdHVyYWwgY2xhc3MgdG8gd2hpY2ggDQogQXV4 aWxpYXJ5IGNsYXNzZXMgbWF5IGJlIGFkZGVkIGZvciBhcHBsaWNhdGlvbiBzcGVjaWZpYyANCiBz dWJlbnRyeSBpbmZvcm1hdGlvbi4gIFdoZXJlIHBvc3NpYmxlLCB0aGUgdXNlIG9mIEF1eGlsaWFy eSANCiBjbGFzc2VzIHRvIGV4dGVuZCBMREFQIFN1YmVudHJpZXMgaXMgc3Ryb25nbHkgcHJlZmVy cmVkLiANCiAgDQogVGhlIHByZXNlbmNlIG9mIGxkYXBTdWJFbnRyeSBpbiB0aGUgbGlzdCBvZiBz dXBlci1jbGFzc2VzIA0KIG9mIGFuIGVudHJ5IGluIHRoZSBkaXJlY3RvcnkgbWFrZXMgdGhhdCBl bnRyeSBhbiBMREFQIA0KIFN1YmVudHJ5LiAgT2JqZWN0IGNsYXNzZXMgZGVyaXZlZCBmcm9tIGxk YXBTdWJFbnRyeSBhcmUgDQogdGhlbXNlbHZlcyBjb25zaWRlcmVkIGxkYXBTdWJFbnRyeSBjbGFz c2VzLCBmb3IgdGhlIHB1cnBvc2UgDQogb2YgdGhpcyBkaXNjdXNzaW9uLiANCgoKIDUuMS4xTmFt aW5nIGFuZCBTdHJ1Y3R1cmUgY29uc3RyYWludHMgDQoKIExEQVAgU3ViZW50cmllcyBNQVkgYmUg bmFtZWQgYnkgdGhlaXIgY29tbW9uTmFtZSBhdHRyaWJ1dGUgDQogW1JGQzIyNTFdLiAgT3RoZXIg bmFtaW5nIGF0dHJpYnV0ZXMgYXJlIGFsc28gcGVybWl0dGVkLiAgDQogRm9yIGNvbXBhdGliaWxp dHkgd2l0aCBbWDUwMV0sIHRoZSBjb21tb25OYW1lIGF0dHJpYnV0ZSBpcyANCiBvcHRpb25hbCAo W1g1MDFdIHJlcXVpcmVzIEVJVEhFUiBjbiBPUiBhIA0KIFN1YlRyZWVTcGVjaWZpY2F0aW9uKSwg YnV0IG5vdGUgdGhhdCBpbiB0aGUgYWJzZW5jZSBvZiBhbnkgDQogb3RoZXIgbmFtaW5nIGF0dHJp YnV0ZSwgYSBjbiBpcyByZXF1aXJlZCB0byBuYW1lIHRoZSBMREFQIA0KIFN1YmVudHJ5LiANCgog TERBUCBTdWJlbnRyaWVzIE1BWSBiZSBjb250YWluZXJzLCB1bmxpa2UgdGhlaXIgW1g1MDFdIA0K IGNvdW50ZXJwYXJ0cy4gIFRoaXMgaXMgYSBkZXBhcnR1cmUgZnJvbSBbWDUwMV0sIGJ1dCBpcyAN CiBjb25zaWRlcmVkIGFuIGltcG9ydGFudCBleHRlbnNpb24gdG8gaW5jcmVhc2UgdGhlIGFiaWxp dHkgDQogdG8gbW9yZSBlYXNpbHkgY29uc3RydWN0IHJpY2hlciAoaS5lLiwgbW9yZSBjb21wbGV4 KSBwb2xpY3kgDQogcmVwcmVzZW50YXRpb25zIGluIHRoZSBkaXJlY3RvcnkgdXNpbmcgTERBUCBT dWJlbnRyaWVzLiAgDQogVXNpbmcgTERBUCBTdWJlbnRyeSBjb250YWluZXJzIHRvIGhvbGQgZW50 cmllcyB0aGF0IGFyZSBub3QgDQogdGhlbXNlbHZlcyBMREFQIFN1YmVudHJpZXMgaXMgcHJvaGli aXRlZCwgYXMgdGhhdCB3b3VsZCANCiBzaWduaWZpY2FudGx5IGFmZmVjdCBjb21wYXRpYmlsaXR5 IHdpdGggW1g1MDFdIHNlcnZpY2VzLiANCgogTERBUCBTdWJlbnRyaWVzIE1BWSBiZSBjb250YWlu ZWQgYnksIGFuZCB3aWxsIHVzdWFsbHkgYmUgDQogbG9jYXRlZCBpbiB0aGUgZGlyZWN0b3J5IGlu Zm9ybWF0aW9uIHRyZWUgaW1tZWRpYXRlbHkgDQogc3Vib3JkaW5hdGUgdG8gdGhlaXIgYWRtaW5p c3RyYXRpdmUgcG9pbnRzLiAgTERBUCANCiBTdWJlbnRyaWVzIE1BWSBhbHNvIGJlIGNvbnRhaW5l ZCBieSBvdGhlciBMREFQIFN1YmVudHJpZXMgDQogKHRoZSB3YXkgb3JnYW5pemF0aW9uYWwgdW5p dHMgbWF5IGJlIGNvbnRhaW5lZCBieSBvdGhlciANCgogUmVlZCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQogICAgICAgICAgICAgICAgICAg RXhwaXJlcyBPY3RvYmVyIDYsIDIwMDEgDQogIAwNCgoKIElOVEVSTkVULURSQUZUICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgNiBBcHJpbCAyMDAxIA0KICAgICAgICAgICAgICAgICAg ICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoKIG9yZ2FuaXphdGlvbmFsIHVuaXRzKS4gIERlZXAg bmVzdGluZyBvZiBMREFQIFN1YmVudHJpZXMgYXJlIA0KIGRpc2NvdXJhZ2VkLCBidXQgbm90IHBy b2hpYml0ZWQuICBEZXZlbG9wZXJzIGFyZSB3YXJuZWQgDQogdGhhdCBkZWVwIG5lc3Rpbmcgb2Yg TERBUCBTdWJlbnRyaWVzIG1heSBub3QgYmUgc3VwcG9ydGVkIA0KIGJ5IGFsbCAob3IgaW5kZWVk LCBieSBhbnkpIExEQVAgc2VydmVyIGltcGxlbWVudGF0aW9ucy4gIA0KIEZvciBjb21wYXRpYmls aXR5IHdpdGggW1g1MDFdLCBhIHN1Yi10cmVlIG1hZGUgdXAgb2YgYSANCiBjb2xsZWN0aW9uIG9m IExEQVAgU3ViZW50cmllcyBtYXkgYmUgbWFwcGVkIG9udG8gYSBzaW5nbGUgDQogKHBvc3NpYmx5 IHZlcnkgY29tcGxleCkgW1g1MDFdIHN1YmVudHJ5LCBhbmQgdmljZSB2ZXJzYS4gDQoKCiA1LjEu MlNjb3BlIFJ1bGVzIA0KCiBUaGUgZGVmYXVsdCBzY29wZSBvZiBhbiBMREFQIFN1YmVudHJ5IGlz IGxpbWl0ZWQgdG8gdGhlIA0KIHNwZWNpZmljIGFkbWluaXN0cmF0aXZlIGFyZWEgKG9yIHN1Yi1h cmVhKSBpbiB3aGljaCBpdCBpcyANCiBkZWZpbmVkLiAgU3BlY2lmaWNhbGx5LCB0aGUgc3VidHJl ZSBvZiB0aGUgZGlyZWN0b3J5IA0KIG5hbWVzcGFjZSBiYXNlZCBhdCB0aGUgYWRtaW5pc3RyYXRp dmUgcG9pbnQgbW9zdCANCiBpbW1lZGlhdGVseSBzdXBlcmlvciB0byB0aGUgTERBUCBTdWJlbnRy eSwgZG93biB0byBidXQgbm90IA0KIGluY2x1ZGluZyBhbnkgc3Vib3JkaW5hdGUgYWRtaW5pc3Ry YXRpdmUgcG9pbnRzIG9yIGFyZWFzIG9mIA0KIHRoZSBzYW1lIGFzcGVjdCBvciB0eXBlLiAgUG9s aWN5IGRlZmluZWQgaW4gYW4gTERBUCANCiBTdWJlbnRyeSBpcyBub3QgaW5oZXJpdGFibGUsIHVu bGVzcyBzdWNoIGluaGVyaXRhbmNlIGlzIA0KIGV4cGxpY2l0bHkgZGVmaW5lZCBieSBhbiBhcHBs aWNhdGlvbi1zcGVjaWZpYyBwb2xpY3kuIA0KCiBJZiBhbiBMREFQIFN1YmVudHJ5IGlzIHN1Ym9y ZGluYXRlIHRvIGFub3RoZXIgTERBUCANCiBTdWJlbnRyeSwgaXQgdGFrZXMgdGhlIHNhbWUgZGVm YXVsdCBzY29wZSBhcyB0aGUgcGFyZW50IA0KIExEQVAgU3ViZW50cnkuIA0KCiBBcHBsaWNhdGlv bnMgTUFZIGRlZmluZSBhbHRlcm5hdGl2ZSBzY29wZSBzZW1hbnRpY3MgZm9yIA0KIGNsYXNzZXMg dGhleSBkZWZpbmUgd2hpY2ggYXJlIGRlcml2ZWQgZnJvbSB0aGUgbGRhcFN1YkVudHJ5IA0KIGNs YXNzLiBUaGlzIG1lYW5zIHRoYXQgYW4gYXBwbGljYXRpb24gY2FuIGRlcml2ZSBhIG5ldyANCiBj bGFzcyBmcm9tIHRoZSBsZGFwU3ViRW50cnkgY2xhc3MgYW5kIGFkZCBhbiBhdHRyaWJ1dGUsIA0K IGxpa2UgU3ViVHJlZVNwZWNpZmljYXRpb24gW1g1MDFdIHRvIGRlZmluZSBhIG5ldyBzY29wZSBy dWxlIA0KIGZvciB0aGF0IGFwcGxpY2F0aW9uIHRvIHVzZS4gDQoKIEFwcGxpY2F0aW9ucyBNVVNU IE5PVCBkZWZpbmUgYWx0ZXJuYXRpdmUgc2NvcGUgcnVsZXMgZm9yIA0KIGF1eGlsaWFyeSBjbGFz c2VzIHVzZWQgdG8gZGVjb3JhdGUgZW50cmllcyBvZiB0aGUgDQogbGRhcFN1YkVudHJ5IGNsYXNz LiAgVGhpcyByZXN0cmljdGlvbiBpcyByZXF1aXJlZCB0byBhdm9pZCANCiBoYXZpbmcgY29uZmxp Y3Rpbmcgb3IgY29udHJhZGljdG9yeSBzY29wZSBkZWZpbml0aW9ucyANCiBhcHBsaWVkIGJ5IGRp ZmZlcmVudCBhcHBsaWNhdGlvbnMgdG8gdGhlIHNhbWUgTERBUCANCiBTdWJlbnRyeS4gDQoKCgoK CgoKCgoKCiBSZWVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSA1XSANCiAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgNiwgMjAwMSAN CiAgDA0KCgogSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA2 IEFwcmlsIDIwMDEgDQogICAgICAgICAgICAgICAgICAgICBMREFQIFN1YmVudHJ5IFNjaGVtYSAN CgogNiAgVmlzaWJpbGl0eSBDb250cm9sIA0KCgogNi4xIGxkYXBTdWJlbnRyaWVzQ29udHJvbCAN CgogVGhpcyBjb250cm9sIGlzIGluY2x1ZGVkIGluIHRoZSBzZWFyY2hSZXF1ZXN0IG1lc3NhZ2Ug YXMgDQogcGFydCBvZiB0aGUgY29udHJvbHMgZmllbGQgb2YgdGhlIExEQVBNZXNzYWdlLCBhcyBk ZWZpbmVkIA0KIGluIFNlY3Rpb24gNC4xLjEyIG9mIFtSRkMyMjUxXS4gDQoKIFRoZSBjb250cm9s VHlwZSBpcyBzZXQgdG8gIjEuMy42LjEuNC4xLjc2MjguNS4xMDEuMSIuIFRoZSANCiBjcml0aWNh bGl0eSBNQVkgYmUgc2V0IHRvIGVpdGhlciBUUlVFIG9yIEZBTFNFLiAgVGhlIA0KIGNvbnRyb2xW YWx1ZSBpcyBhYnNlbnQuICAgDQoKIFRoZXJlIGlzIG5vIGNvcnJlc3BvbmRpbmcgcmVzcG9uc2Ug Y29udHJvbCBkZWZpbmVkLiANCgogTERBUCBzZXJ2ZXJzIHRoYXQgc3VwcG9ydCB0aGlzIGNvbnRy b2wgTVVTVCB0cmVhdCBMREFQIA0KIFN1YmVudHJpZXMgYXMgIm9wZXJhdGlvbmFsIG9iamVjdHMi IGluIG11Y2ggdGhlIHNhbWUgd2F5IA0KIHRoYXQgIm9wZXJhdGlvbmFsIGF0dHJpYnV0ZXMiIGFy ZSBub3QgcmV0dXJuZWQgaW4gc2VhcmNoIA0KIHJlc3VsdHMgYW5kIFtYNTExXSByZWFkIG9wZXJh dGlvbnMgd2hlbiBvbmx5IHVzZXIgDQogYXR0cmlidXRlcyBhcmUgcmVxdWVzdGVkLiAgDQoKIEVu dHJpZXMgd2hpY2ggYXJlIG5vdCBMREFQIFN1YmVudHJpZXMgbWF5IGJlIHJlZmVyZW5jZWQgaW4g DQogdGhlIGJhc2Ugb2JqZWN0IG9mIHNlYXJjaCBvcGVyYXRpb25zIHdoZXJlIHRoZSANCiBsZGFw U3ViZW50cmllc0NvbnRyb2wgaXMgcHJlc2VudCBpbiB0aGUgcmVxdWVzdC4gICANCgogSW4gdGhl IGFic2VuY2Ugb2YgdGhlIExEQVAgU3ViZW50cmllcyB2aXNpYmlsaXR5IGNvbnRyb2wsIA0KIHN1 YmVudHJpZXMgYXJlIG5vdCB2aXNpYmxlIHRvIHNlYXJjaCBvcGVyYXRpb25zIFVOTEVTUyB0aGUg DQogdGFyZ2V0L2Jhc2Ugb2YgdGhlIG9wZXJhdGlvbiBpcyBhIHN1YmVudHJ5LiANCiAgDQogSW4g cHJlc2VuY2Ugb2YgdGhlIHN1YmVudHJ5IHZpc2liaWxpdHkgY29udHJvbCwgT05MWSANCiBzdWJl bnRyaWVzIGFyZSB2aXNpYmxlLiAgIA0KCiA2LjEuMU90aGVyIExEQVAgb3BlcmF0aW9ucyANCgog VGhlIGxkYXBTdWJlbnRyaWVzQ29udHJvbCBpcyBub3QgZGVmaW5lZCBmb3IgYW55IExEQVAgDQog b3BlcmF0aW9uIG90aGVyIHRoYW4gU2VhcmNoLiAgSG93ZXZlciwgYW4gTERBUHYzIEV4dGVuc2lv biANCiBNQVkgZGVmaW5lIGEgdXNlIG9mIHRoaXMgY29udHJvbCB3aXRoIHRoYXQgZXh0ZW5zaW9u IGFzIA0KIGxvbmcgYXMgc3VjaCB1c2UgaXMgY29uc2lzdGVudCB3aXRoIHRoaXMgc3BlY2lmaWNh dGlvbi4gDQoKCiA2LjEuMkNvcnJlc3BvbmRlbmNlIHRvIFtYNTExXSANCgogSW4gcHJlc2VuY2Ug b2YgdGhlIHZpc2liaWxpdHkgY29udHJvbCwgdGhlIHNlbWFudGljcyBvZiB0aGUgDQogTERBUFN1 YmVudHJpZXNDb250cm9sIGFyZSBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIGluZGljYXRpb24gDQog b2YgdGhlIFtYNTExXSBjb21tb24gYXJndW1lbnQgc2VydmljZUNvbnRyb2xzIG9wdGlvbnMgDQog c3ViZW50cmllcyBiZWluZyBzZXQuIA0KICANCgoKIFJlZWQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDZdIA0KICAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgT2N0b2JlciA2LCAyMDAxIA0KICAMDQoKCiBJTlRFUk5FVC1EUkFGVCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDYgQXByaWwgMjAwMSANCiAgICAgICAgICAgICAgICAgICAg IExEQVAgU3ViZW50cnkgU2NoZW1hIA0KCiBJbiBbWDUxMV0gYSBTZXJ2aWNlQ29udHJvbCBvcHRp b24gaXMgdXNlZCB0byBnb3Zlcm4gdGhlIA0KIHZpc2liaWxpdHkgb2YgW1g1MDFdIHN1YmVudHJp ZXMuICBUaGUgc3ViZW50cnkgDQogU2VydmljZUNvbnRyb2wgb3B0aW9uIGlzIGEgc3BlY2lmaWMg Yml0IG9mIGEgYml0c3RyaW5nIA0KIHRoYXQsIHdoZW4gc2V0IGluIHRoZSBjb21tb24gYXJndW1l bnRzIG9mIGFuIFtYNTExXSBTZWFyY2ggDQogb3IgTGlzdCBvcGVyYXRpb24sIGluZGljYXRlcyB0 aGF0IHRoZSBvcGVyYXRpb24gaXMgdG8gDQogYWNjZXNzIE9OTFkgdGhlIHN1YmVudHJpZXMgZm91 bmQgaW4gdGhlIGNvbnRleHQgb2YgdGhlIGxpc3QgDQogb3Igc2VhcmNoLiAgSW4gZmFjdCwgbm9y bWFsIGVudHJpZXMgYXJlIGV4cGxpY2l0bHkgTk9UIA0KIHJldHVybmVkIGluIHRoZSByZXN1bHQg b2YgYSBsaXN0IG9yIHNlYXJjaCBvcGVyYXRpb24gd2hlbiANCiB0aGUgW1g1MTFdIHN1YmVudHJp ZXMgU2VydmljZUNvbnRyb2wgaXMgc2V0LiAgIA0KCiBFbnRyaWVzIHdoaWNoIGFyZSBub3Qgc3Vi ZW50cmllcyBtYXkgYmUgdXNlZCBpbiB0aGUgYmFzZSANCiBvYmplY3Qgb2YgbGlzdCBhbmQgc2Vh cmNoIG9wZXJhdGlvbnMgd2hlcmUgdGhlIHN1YmVudHJpZXMgDQogY29udHJvbCBpcyBzZXQuICAg DQoKIFRoZSBbWDUxMV0gc3ViZW50cmllcyBTZXJ2aWNlQ29udHJvbCBoYXMgbm8gbWVhbmluZyBm b3IgDQogb3BlcmF0aW9ucyBvdGhlciB0aGFuIFNlYXJjaCBhbmQgTGlzdCAoaS5lLiwgaXQgaXMg bm90IA0KIGRlZmluZWQgZm9yIFJlYWQsIE1vZGlmeSwgRGVsZXRlLCBldGMuKS4gDQoKCgogNyAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQoKIExEQVAgU3ViZW50cmllcyB3aWxsIGZyZXF1ZW50 bHkgYmUgdXNlZCB0byBob2xkIGRhdGEgd2hpY2ggDQogcmVmbGVjdHMgZWl0aGVyIHRoZSBhY3R1 YWwgb3IgaW50ZW5kZWQgYmVoYXZpb3Igb2YgdGhlIA0KIGRpcmVjdG9yeSBzZXJ2aWNlLiAgQXMg c3VjaCwgcGVybWlzc2lvbiB0byByZWFkIHN1Y2ggDQogZW50cmllcyBNQVkgbmVlZCB0byBiZSBy ZXN0cmljdGVkIHRvIGF1dGhvcml6ZWQgdXNlcnMuICANCiBNb3JlIGltcG9ydGFudGx5LCBpZiBh IGRpcmVjdG9yeSBzZXJ2aWNlIHRyZWF0cyB0aGUgDQogaW5mb3JtYXRpb24gaW4gYW4gTERBUCBT dWJlbnRyeSBhcyB0aGUgYXV0aG9yaXRhdGl2ZSBzb3VyY2UgDQogb2YgcG9saWN5IHRvIGJlIHVz ZWQgdG8gY29udHJvbCB0aGUgYmVoYXZpb3Igb2YgdGhlIA0KIGRpcmVjdG9yeSwgdGhlbiBwZXJt aXNzaW9uIHRvIGNyZWF0ZSwgbW9kaWZ5LCBvciBkZWxldGUgDQogc3VjaCBlbnRyaWVzIE1VU1Qg YmUgY2FyZWZ1bGx5IHJlc3RyaWN0ZWQgdG8gYXV0aG9yaXplZCANCiBhZG1pbmlzdHJhdG9ycy4g DQoKCgogOCAgUmVmZXJlbmNlcyANCgogW1JGQzIxMTldIFMuIEJyYWRuZXIsICJLZXkgd29yZHMg Zm9yIHVzZSBpbiBSRkNzIHRvIA0KIEluZGljYXRlIFJlcXVpcmVtZW50IExldmVscyIsIFJGQyAy MTE5LCBNYXJjaCAxOTk3IA0KCiBbUkZDMjI1MV0gUy4gS2lsbGUsIE0uIFdhaGwsIGFuZCBULiBI b3dlcywgIkxpZ2h0d2VpZ2h0IA0KIERpcmVjdG9yeSBBY2Nlc3MgUHJvdG9jb2wgKHYzKSIsIFJG QyAyMjUxLCBEZWNlbWJlciAxOTk3IA0KCiBbWDUwMV0gSVRVLVQgUmVjLiBYLjUwMSwgIlRoZSBE aXJlY3Rvcnk6IE1vZGVscyIsIDE5OTMgYW5kIA0KIHN1YnNlcXVlbnQgdmVyc2lvbnMgDQoKIFtY NTAxXSBJVFUtVCBSZWMuIFguNTExLCAiVGhlIERpcmVjdG9yeTogQWJzdHJhY3QgU2VydmljZSAN CiBEZWZpbml0aW9uIiwgMTk5MyBhbmQgc3Vic2VxdWVudCB2ZXJzaW9ucyANCgogUmVlZCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10gDQogICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDYsIDIwMDEgDQogIAwNCgoKIElOVEVSTkVU LURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNiBBcHJpbCAyMDAxIA0KICAg ICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hlbWEgDQoKIDkgIENvcHlyaWdodCBO b3RpY2UgDQoKIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDApLiBBbGwg UmlnaHRzIA0KIFJlc2VydmVkLiAgDQogIA0KIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9u cyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCANCiBmdXJuaXNoZWQgdG8gb3RoZXJzLCBhbmQgZGVy aXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gDQogb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQg b3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgDQogYmUgcHJlcGFyZWQsIGNvcGll ZCwgcHVibGlzaGVkIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgDQogaW4gcGFydCwgd2l0 aG91dCByZXN0cmljdGlvbiBvZiBhbnkga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgDQogYWJvdmUg Y29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggYXJlIGluY2x1ZGVkIG9uIA0KIGFs bCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gSG93ZXZlciwgdGhpcyANCiBkb2N1 bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IA0K IHJlbW92aW5nIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVy bmV0IA0KIFNvY2lldHkgb3Igb3RoZXIgSW50ZXJuZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFz IG5lZWRlZCANCiBmb3IgdGhlIHB1cnBvc2Ugb2YgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFy ZHMgaW4gd2hpY2ggDQogY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0cyBkZWZpbmVk IGluIHRoZSBJbnRlcm5ldCANCiBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIGZvbGxvd2VkLCBv ciBhcyByZXF1aXJlZCB0byANCiB0cmFuc2xhdGUgaXQgaW50byBsYW5ndWFnZXMgb3RoZXIgdGhh biBFbmdsaXNoLiANCiAgDQogVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm92ZSBh cmUgcGVycGV0dWFsIGFuZCANCiB3aWxsIG5vdCBiZSByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBT b2NpZXR5IG9yIGl0cyANCiBzdWNjZXNzb3JzIG9yIGFzc2lnbnMuIA0KICANCiBUaGlzIGRvY3Vt ZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyANCiBwcm92aWRlZCBv biBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgDQogVEhFIElO VEVSTkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCANCiBXQVJSQU5USUVT LCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgDQogVE8gQU5Z IFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgDQog Tk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRiANCiBN RVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIiANCgoK IDEwIEFja25vd2xlZGdlbWVudHMgDQoKIFRoZSB1dGlsaXR5IG9mIHN1YkVudHJ5IG9iamVjdCBj bGFzcyB3YXMgb3JpZ2luYWxseSANCiBzdWdnZXN0ZWQgYXMgYSBtZWFucyB0byBzdG9yZSBSZXBs aWNhIGFuZCBSZXBsaWNhdGlvbiANCiBBZ3JlZW1lbnQgaW5mb3JtYXRpb24gd2l0aCBhIHRoZSBs dWNpZCBleHBsYW5hdGlvbiBieSBNYXJrIA0KIFdhaGwsICh0aGVuIG9mIElubm9zb2Z0KSwgb2Yg aG93IHRoZXkgY291bGQgYmUgdXNlZCBhbmQgDQogZXh0ZW5kZWQuIA0KICANCiBUaGUgSUVURiB0 YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIA0KIG9mIGFu eSBpbnRlbGxlY3R1YWwgcHJvcGVydHkgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgDQog Y2xhaW1lZCB0byBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIA0K IHRlY2hub2xvZ3kgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byAN CiB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cyBtaWdodCBvciBtaWdodCBub3Qg YmUgDQogYXZhaWxhYmxlOyBuZWl0aGVyIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzIG1h ZGUgYW55IA0KIGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuIEluZm9ybWF0aW9u IG9uIHRoZSANCgogUmVlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgOF0gDQogICAgICAgICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDYsIDIw MDEgDQogIAwNCgoKIElOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgNiBBcHJpbCAyMDAxIA0KICAgICAgICAgICAgICAgICAgICAgTERBUCBTdWJlbnRyeSBTY2hl bWEgDQoKIElFVEYncyBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gc3RhbmRh cmRzLXRyYWNrIA0KIGFuZCBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBiZSBm b3VuZCBpbiBCQ1AtMTEuIA0KIENvcGllcyBvZiBjbGFpbXMgb2YgcmlnaHRzIG1hZGUgYXZhaWxh YmxlIGZvciBwdWJsaWNhdGlvbiANCiBhbmQgYW55IGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8g YmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSANCiByZXN1bHQgb2YgYW4gYXR0ZW1wdCBtYWRlIHRv IG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciANCiBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9m IHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IA0KIGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0 aGlzIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIA0KIGZyb20gdGhlIElFVEYgU2VjcmV0 YXJpYXQuIA0KICANCiBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJy aW5nIHRvIGl0cyANCiBhdHRlbnRpb24gYW55IGNvcHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50 IGFwcGxpY2F0aW9ucywgDQogb3Igb3RoZXIgcHJvcHJpZXRhcnkgcmlnaHRzIHdoaWNoIG1heSBj b3ZlciB0ZWNobm9sb2d5IHRoYXQgDQogbWF5IGJlIHJlcXVpcmVkIHRvIHByYWN0aWNlIHRoaXMg c3RhbmRhcmQuIFBsZWFzZSBhZGRyZXNzIA0KIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBF eGVjdXRpdmUgRGlyZWN0b3IuIA0KCgogMTEgQXV0aG9yJ3MgQWRkcmVzcyANCgogICAgICBFZHdh cmRzIEUuIFJlZWQgDQogICAgICBSZWVkLU1hdHRoZXdzLCBJbmMuIA0KICAgICAgMTA2NCBFIDE0 MCBOb3J0aCANCiAgICAgIExpbmRvbiwgVVQgIDg0MDQyIA0KICAgICAgVVNBIA0KICAgICAgRS1t YWlsOiBlZXJAb25jYWxsZGJhLmNvbSAgDQogICAgICAgDQogICAgICBMRFVQIE1haWxpbmcgTGlz dDogaWV0Zi1sZHVwQGltYy5vcmcgIA0KICAgICAgTERBUEVYVCBNYWlsaW5nIExpc3Q6IGlldGYt bGRhcGV4dEBuZXRzY2FwZS5jb20gDQoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKIFJlZWQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDldIA0KICAgICAg ICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciA2LCAyMDAxIA0KICAM --=_A7FC5DDB.FF9EF389-- From list@netscape.com Fri Apr 6 14:07:56 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15981 for ; Fri, 6 Apr 2001 14:07:55 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36I4HS24116; Fri, 6 Apr 2001 11:04:17 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36I4HE15809; Fri, 6 Apr 2001 11:04:17 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 11:04:17 -0700 (PDT) Message-Id: <5.0.2.1.0.20010406103137.01a5d4f0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 06 Apr 2001 11:05:39 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: createSaslClient by the Java LDAP API Cc: ietf-ldapext In-Reply-To: <3ACDFAB3.50CC38B6@coscend.com> References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> <5.0.2.1.0.20010404203024.00a8fb30@127.0.0.1> <5.0.2.1.0.20010405081413.01f757f0@127.0.0.1> <5.0.2.1.0.20010405221358.01a4bec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"aCzcfB.A.f2D.gUgz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 10:19 AM 4/6/01 -0700, Rob Weltman wrote: >"Kurt D. Zeilenga" wrote: >> >> Second, in the present of a client asserted authorization >> identity, the server may (in addition to the above) rely on >> this entry to support evaluation of the proxy authorization >> policy. > > What if the entry (pointed to by the DN supplied on bind) implies wide-ranging access rights that should not be granted based on the authzid or the authentication ID? What I meant to imply is that the server might rely on information held in the entry located by the bind DN in the authentication/authorization process. For example, this entry might contain a list of authzIds which the authentication identity is allowed to assume the authorization identity of. >When you say "may", do you mean "MAY" as in RFC 2119? No, I meant "may" as in "might", that is, to express a possibility. Whether or not the specification allows this possibility is another matter. >That seems to me to lend itself to an indeterminate and insecure server implementation. I do believe there are some security considerations which do need to be noted when the specification is revised. Feel free to raise any you might have to LDAPbis anytime. >Shouldn't there be mandatory behavior in evaluating the authorization policy? That might be an area in which the IETF might want to consider doing some work in. Right now, RFC 2222, 2251, 2829, and 2830 leave authorization policy implementation up to servers. Kurt From list@netscape.com Fri Apr 6 14:48:53 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17151 for ; Fri, 6 Apr 2001 14:48:52 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36IkIv25830; Fri, 6 Apr 2001 11:46:18 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36IkHY07261; Fri, 6 Apr 2001 11:46:17 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 11:46:17 -0700 (PDT) Message-ID: <3ACE0E45.1592074F@americasm01.nt.com> Date: Fri, 06 Apr 2001 14:43:17 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Mircea Pana" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Stoddard, Lander" CC: "'ietf-ldapext@netscape.com'" Subject: Re: FW: Request for LDAP References: <1537895B1173D1118D9300A0246212B60907BD51@mcdc-atl-4.cdc.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Resent-Message-ID: <"lrpKhC.A.NwB.17gz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Lander, Take a look in the archive: ftp://ftp.ietf.org/ietf-mail-archive/ldapext/1999-08.mail and search for "Subject: Nested SearchRequests" and for the reply messages. The answers that I received back then may help you as well. Regards, Mircea. "Stoddard, Lander" wrote: > > Dear LDAP standards working group - > > Please consider the request below. > > thanks, Lander > > Lander Stoddard > Associate Director for Strategic Planning > and Information Management > Scientific Resources Program > National Center for Infectious Diseases > Centers for Disease Control and Prevention > lstoddard@cdc.gov > > -----Original Message----- > From: Tim Howes [mailto:howes@loudcloud.com] > Sent: Thursday, April 05, 2001 4:34 PM > To: Stoddard, Lander > Subject: Re: Request for LDAP > > Hi. Sounds like a reasonable request to me, one I've > in fact heard before. You might send it to Mark Wahl > or Mark Smith , > both of whom are still actively involved in the LDAP > standardization process (I am not). Or, you could > try sending your request to ietf-ldapext@netscape.com, > the LDAP standards working group mailing list. > > Hope that helps. -- Tim > > "Stoddard, Lander" wrote: > > > > Tim - > > > > I just read your article "LDAP: Use as Directed" Thanks for the great > work. > > > > I am trying to architect a distributed directory and have run into a > > functional roadblock that I think should be part of the LDAP spec. I > don't > > know who else to send this to since I have no entree to the LDAP standards > > body. > > > > The needed functionality is a recursive search for group membership. We > can > > build something to do this but I think it optimally should be language > > independent. It's a common enough problem that I think there should be a > > common solution. Consider the following scenario: > > > > We are going to build a public health directory to manage access to > > applications and distribution of information. Tom X is in an > organizational > > role of State Epidemiologist for State Q. All state epidemiologists are > > members of > > the group All State Epidemiologists. There are some 50 surveillance > > applications for which there is an application role that the state > > epidemiologists have access to. After a person authenticates, I want to > > present them with a list of authorized applications and approles to choose > > from. > > > > So, there is orgperson object in an orgrole object/group. There is an > > orggroup object containing orgrole objects. There is an application group > > containing applicationrole groups. With the current LDAP query > > functionality, I have to place individual orgperson objects into the > approle > > groups. > > > > For ease of directory management, the better thing would be to put the > > orggroup into the approle group. Then if Tom X is replaced by Mary Y, the > > only change that has to be made is the membership of the orgrole, not the > > membership of the org group and 50 approles. I would like an LDAP > function > > that recursively searches down through the group until it finds all the > > orgperson objects and then do a match against the provided DN. And I > would > > like the LDAP directory to do the work. > > > > What do you think? Is this a reasonable request that can be submitted? I > > know we can code this and distribute the component to our servers, but it > > will probably be language specific. Just seems like there ought to be an > > LDAP solution. > > > > thanks for your consideration, > > Lander > > > > Lander Stoddard > > Associate Director for Strategic Planning > > and Information Management > > Scientific Resources Program > > National Center for Infectious Diseases > > Centers for Disease Control and Prevention > > lstoddard@cdc.gov From list@netscape.com Fri Apr 6 19:01:17 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22780 for ; Fri, 6 Apr 2001 19:01:16 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f36Mw9v07915; Fri, 6 Apr 2001 15:58:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f36Mw9U23356; Fri, 6 Apr 2001 15:58:09 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 15:58:09 -0700 (PDT) Date: Fri, 06 Apr 01 13:18:14 EST From: vacations51@hotmail.com To: Friend@public.com Subject: Huge Hot CDs Amazing Message-ID: Reply-To: takeoff@marketing-tip.com X-PMFLAGS: 128 X-MIMETrack: Itemize by SMTP Server on Internet2/AlarmNet/Pittway(Release 5.0.7 |March 21, 2001) at 04/06/2001 04:18:10 PM, Serialize by Router on Internet2/AlarmNet/Pittway(Release 5.0.7 |March 21, 2001) at 04/06/2001 06:57:08 PM, Serialize complete at 04/06/2001 06:57:08 PM Resent-Message-ID: <"1EzCC.A.SsF._nkz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Check it Out

Check it Out!!!

 

http://www.netcolony.com/business/marketone/index.html

Software you won't find 

Anywhere else

The Amazing Mega Cd 

Action Packed 650 megs of

Information -Appz-Internet Spy-Graphics-Music-Games,too much to list

Check It Out !!!

The Hottest  Cd Ever

Online Payment     Check it Out

DISCLAIMER  This is not a spam - you are receiving this message because either
(a) we are both members of the same safe list or opt-in list or (b) you recently
communicated with me or submitted a link for publicizing, in either which event
this is effectively acknowledgment thereof  we are in ongoing correspondence.
If you wish to be removed from a list reply typing "REMOVE" in the subject box
of your reply and send to the appropriate list or
 mailto:offers4u@hotmail.com?subject=remove


From list@netscape.com Fri Apr 6 20:57:16 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23945 for ; Fri, 6 Apr 2001 20:57:15 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f370nDv24389; Fri, 6 Apr 2001 17:49:14 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f370n5I17945; Fri, 6 Apr 2001 17:49:05 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 17:49:05 -0700 (PDT) Message-Id: <5.0.2.1.0.20010406174003.01e6ea90@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 06 Apr 2001 17:50:20 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: createSaslClient by the Java LDAP API Cc: ietf-ldapext In-Reply-To: <3ACDFAB3.50CC38B6@coscend.com> References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> <5.0.2.1.0.20010404203024.00a8fb30@127.0.0.1> <5.0.2.1.0.20010405081413.01f757f0@127.0.0.1> <5.0.2.1.0.20010405221358.01a4bec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"w0sjRD.A.BYE._Pmz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Rob, Regarding the security issues previously discussed in this thread, I note RFC 2251 says: When used with SASL, it should be noted that the name field of the BindRequest is not protected against modification. Thus if the distinguished name of the client (an LDAPDN) is agreed through the negotiation of the credentials, it takes precedence over any value in the unprotected name field. and RFC 2829 says: The method by which a server composes and validates an authorization identity from the authentication credentials supplied by a client is implementation-specific. Though some clarification might be added as part of the LDAPbis effort, I suspect "implementation-specific" issue would be left to future standardization. Kurt From list@netscape.com Fri Apr 6 21:12:37 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24058 for ; Fri, 6 Apr 2001 21:12:37 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3718pS02792; Fri, 6 Apr 2001 18:08:51 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3718hw25377; Fri, 6 Apr 2001 18:08:43 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 18:08:43 -0700 (PDT) Message-ID: <3ACE687B.B0FF8747@coscend.com> Date: Fri, 06 Apr 2001 18:08:11 -0700 From: Rob Weltman X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext Subject: Re: createSaslClient by the Java LDAP API References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> <5.0.2.1.0.20010404203024.00a8fb30@127.0.0.1> <5.0.2.1.0.20010405081413.01f757f0@127.0.0.1> <5.0.2.1.0.20010405221358.01a4bec0@127.0.0.1> <5.0.2.1.0.20010406174003.01e6ea90@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"sjUKND.A.pLG.Yimz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Kurt D. Zeilenga" wrote: > > Rob, > > Regarding the security issues previously discussed in > this thread, I note RFC 2251 says: > When used with SASL, it should be noted that the name field of the > BindRequest is not protected against modification. Thus if the > distinguished name of the client (an LDAPDN) is agreed through the > negotiation of the credentials, it takes precedence over any value in > the unprotected name field. That implies that the authorization ID (from the credentials) is used for the bind DN, even if a bind DN is supplied. That means that there IS contamination between the DN parameter and the authzid parameter in the bind() call. If the authzid parameter is null, the DN parameter may be used as the bind DN. If it is not null, and if the server and the client derive a DN from authzid or some other information in the credentials, then the DN parameter will be ignored. Or does "credentials" here not refer to the authorization ID? Rob From list@netscape.com Fri Apr 6 21:35:27 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24820 for ; Fri, 6 Apr 2001 21:35:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f371Wsv00190; Fri, 6 Apr 2001 18:32:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f371UUA04319; Fri, 6 Apr 2001 18:30:30 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 18:30:30 -0700 (PDT) Message-Id: <5.0.2.1.0.20010406182727.01e73950@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 06 Apr 2001 18:32:03 -0700 To: Rob Weltman From: "Kurt D. Zeilenga" Subject: Re: createSaslClient by the Java LDAP API Cc: ietf-ldapext In-Reply-To: <3ACE687B.B0FF8747@coscend.com> References: <5.0.2.1.0.20010404172226.00b16ab0@127.0.0.1> <5.0.2.1.0.20010404203024.00a8fb30@127.0.0.1> <5.0.2.1.0.20010405081413.01f757f0@127.0.0.1> <5.0.2.1.0.20010405221358.01a4bec0@127.0.0.1> <5.0.2.1.0.20010406174003.01e6ea90@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"IV5W6.A.LDB.12mz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 06:08 PM 4/6/01 -0700, Rob Weltman wrote: > Or does "credentials" here not refer to the authorization ID? The credentials are used establish the authentication identity. That is, in SASL/PLAIN (for simplicity), the username/password pair form the credential. The authentication identity is the username. The authorization identity can be asserted a long side of a credential but is generally not part of the credential. Kurt From list@netscape.com Fri Apr 6 21:43:55 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25211 for ; Fri, 6 Apr 2001 21:43:55 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f371fMv00838; Fri, 6 Apr 2001 18:41:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f371fDs07732; Fri, 6 Apr 2001 18:41:13 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 18:41:13 -0700 (PDT) Message-Id: <5.0.2.1.0.20010406170456.01e667f0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 06 Apr 2001 18:42:41 -0700 To: robert byrne From: "Kurt D. Zeilenga" Subject: Re: IP Address in the ACM (Was: Comments on AccessControlModel- BNF) Cc: Paul Leach , ietf-ldapext@netscape.com In-Reply-To: <3ACDC324.94579852@Sun.COM> References: <5.0.2.1.0.20010404130816.00b02a10@127.0.0.1> <5.0.2.1.0.20010405074208.01f6e7a0@127.0.0.1> <5.0.2.1.0.20010405083950.01f6a670@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"sy0lND.A.c4B.4Anz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Robert, Given that the document allows additional subjects, there are already interoperability issues of the nature you seem to be concerned with. If someone specified a "foo" subject to a server that doesn't support the "foo" subject, an error should be returned. That ensures the client understands this server doesn't support the "foo" subject. How is that different for the server returning a error for the IP-Address subject? Kurt From list@netscape.com Sat Apr 7 05:53:18 2001 Received: from netscape.com ([205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12428 for ; Sat, 7 Apr 2001 05:53:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f378k8v24146; Sat, 7 Apr 2001 01:46:08 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f378k0Q01258; Sat, 7 Apr 2001 01:46:00 -0700 (PDT) Resent-Date: Sat, 7 Apr 2001 01:46:00 -0700 (PDT) Message-Id: <200104070847.EAA29155@news.bcn.net> From: "Pam Testa" Subject: Your Status To: <#field0#@corp.supernews.net> Date: Fri, 06 Apr 2001 20:34:56 -0700 X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE Vdiffondi.1712.3 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"eAfdt.A.ST.GPtz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Candidate, You have been selected as a potential candidate for a free listing in the 2001 Edition of the International Executive Guild Registry=2E Please accept our congratulations for this coveted honor=2E As this edition is so important in view of the new millennium, the International Executive Guild Registry will be published in two different formats; the searchable CD-ROM and the Online Registry=2E Since inclusion can be considered recognition of your career position and professionalism, each candidate is evaluated in keeping with high standards of individual achievement=2E In light of this, the International Executive Guild thinks that you may make an interesting biographical subject=2E We look forward to your inclusion and appearance in the International Executive Guild's Registry=2E Best wishes for your continued success=2E International Executive Guild Listing Dept=2E  If you wish to be removed from our list, please submit your request at the bottom of this email=2E   0); // returns false if empty } // --> International Executive Guild Registration Form (US and Canada Only) Please fill out this form if you would like to be included in The International Executive Guild's Registry=2E For accuracy and publication purposes, please= complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed in The International Executive Guild's Registry=2E Your Name Your Company Title Address City State or Province Country USACanada ZIP/Postal Code Day Time Telephone Home Phone (Not To Be Published) Email TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E Your Business (Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E) Type of Organization (Mfg, Dist/Wholesaler, Retailer, Law Firm, Investment Bank, Commercial Bank, University, Financial Consultants, Ad Agency, Contractor, Broker, etc=2E) Your Business Expertise (Corp=2EMgmt, Marketing, Civil Engineering, Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc=2E) Major Product Line (Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E) Note: Submitting this form will be made by email, not by use of  www=2E  Confirmation of its delivery is made by browsing your outgoing mail=2E Thank you for filling in this form, we will contact you with more information=2E List Removal Click Here ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Candidate,

You have been selected as a potential candidate= for a free listing in
the 2001 Edition of the International Executiv= e Guild Registry=2E

Please accept our congratulations for this cove= ted honor=2E

As this edition is so important in view of the new millennium, the
International Executive Guild Registry will be= published in two different
formats; the searchable CD-ROM and the Online Registry=2E

Since inclusion can be considered recognition of your career position
and professionalism, each candidate is evaluat= ed in keeping with high
standards of individual achievement=2E In ligh= t of this, the International Executive
Guild thinks that you may make an interesting biographical subject=2E

We look forward to your inclusion and appearanc= e in the International
Executive Guild's Registry=2E Best wishes for = your continued success=2E

International Executive Guild
Listing Dept=2E 

If you wish to be removed from our list, please submit your request
at= the bottom of this email=2E

 
International Execut= ive Guild
Registration Form
(US and Canada Only)
Please fill out this form if you would like to be included in The International Executive Guild's Registry=2E For accuracy and publication purposes, pleas= e complete and send this form at the earliest opportunity=2E There is no charge or obligation to be listed in The International Exe= cutive Guild's Registry=2E
Your Name
Your Company
Title
Address
City
State or Province
Country
ZIP/Postal Code
Day Time Telephone
Home Phone
 (Not To Be Published)
Email

TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF=2E=2E=2E

Your Business
(Fi= nancial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc=2E)
Type of Organization
(Mf= g, Dist/Wholesaler, Retailer, Law Firm,
Investment Bank, Commercial Bank, University,
Financial Consultants, Ad Agency, Contractor, Broker, etc=2E)
Your Business Expertise
(Co= rp=2EMgmt, Marketing, Civil Engineering,
Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortg= age Banking, etc=2E)
Major Product Line
(In= tegrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc=2E)


Note: Submitting this form = will be made by email, not by use of  www=2E  Confirmation of its del= ivery is made by browsing your outgoing mail=2E

Thank you for filling in this form, we will contact you with more information=2E=

List Removal
Click Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From list@netscape.com Sat Apr 7 08:09:10 2001 Received: from netscape.com ([205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13595 for ; Sat, 7 Apr 2001 08:09:08 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f37C6rv09639; Sat, 7 Apr 2001 05:06:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f37C6sU05345; Sat, 7 Apr 2001 05:06:54 -0700 (PDT) Resent-Date: Sat, 7 Apr 2001 05:06:54 -0700 (PDT) Date: Sat, 7 Apr 2001 05:06:29 -0700 (PDT) Message-Id: <200104071206.f37C6TI14172@xwing.aoltw.net> From: manwong@emperorgrouup.com.hk.netscape.com Subject: =?big5?Q?=AD^=AC=D3=AA=F7=BF=C4=B6=B0=B9=CE(=AD=BB=B4=E4)=A6=B3=AD=AD=A4=BD=A5q---=A7=EB=B8=EA=C1=BF=AEy?= MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_ALo8WsHoAiZAMoje5IriauM" X-Mailer: tXN1pZPwVisdpkyT0DQygXWNpH X-Priority: 3 X-MSMail-Priority: Normal Resent-Message-ID: <"tsWJ-C.A.oSB.aLwz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. ------=_NextPart_ALo8WsHoAiZAMoje5IriauM Content-Type: multipart/alternative; boundary="----=_NextPart_ALo8WsHoAiZAMoje5IriauMAA" ------=_NextPart_ALo8WsHoAiZAMoje5IriauMAA Content-Type: text/plain; Content-Transfer-Encoding: base64 UGxlYXNlIFJlYWQgSFRNTCBNZXNzYWdlICEhIQ== ------=_NextPart_ALo8WsHoAiZAMoje5IriauMAA Content-Type: text/html; charset="big5" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiDQp4bWxuczpvPSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiDQp4bWxuczp3PSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIg0KeG1sbnM9Imh0dHA6Ly93d3cudzMub3Jn L1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBl IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1CaWc1Ij4NCjxtZXRhIG5hbWU9UHJvZ0lkIGNv bnRlbnQ9V29yZC5Eb2N1bWVudD4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jv c29mdCBXb3JkIDkiPg0KPG1ldGEgbmFtZT1PcmlnaW5hdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBX b3JkIDkiPg0KPGxpbmsgcmVsPUZpbGUtTGlzdCBocmVmPSIuL61erNOq97/EtrC5zqfruOrBv655 LmZpbGVzL2ZpbGVsaXN0LnhtbCI+DQo8bGluayByZWw9RWRpdC1UaW1lLURhdGEgaHJlZj0iLi+t XqzTqve/xLawuc6n67jqwb+ueS5maWxlcy9lZGl0ZGF0YS5tc28iPg0KPCEtLVtpZiAhbXNvXT4N CjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2 aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwp O30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwhW2Vu ZGlmXS0tPg0KPHRpdGxlPq1erNOq97/EtrC5ziitu7TkKaazra2kvaVxICAgICAgICAgICAgICAg ICAgICC4Z8DZp+u46rDKplbBvzwvdGl0bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8 bzpEb2N1bWVudFByb3BlcnRpZXM+DQogIDxvOkF1dGhvcj5Db2NvIFlldW5nPC9vOkF1dGhvcj4N CiAgPG86VGVtcGxhdGU+Tm9ybWFsPC9vOlRlbXBsYXRlPg0KICA8bzpMYXN0QXV0aG9yPk1hbiBX b25nPC9vOkxhc3RBdXRob3I+DQogIDxvOlJldmlzaW9uPjI8L286UmV2aXNpb24+DQogIDxvOlRv dGFsVGltZT4xMDE8L286VG90YWxUaW1lPg0KICA8bzpMYXN0UHJpbnRlZD4yMDAwLTEyLTI3VDA2 OjM5OjAwWjwvbzpMYXN0UHJpbnRlZD4NCiAgPG86Q3JlYXRlZD4yMDAxLTA0LTAzVDEzOjE5OjAw WjwvbzpDcmVhdGVkPg0KICA8bzpMYXN0U2F2ZWQ+MjAwMS0wNC0wM1QxMzoxOTowMFo8L286TGFz dFNhdmVkPg0KICA8bzpQYWdlcz4yPC9vOlBhZ2VzPg0KICA8bzpXb3Jkcz4xMTQ8L286V29yZHM+ DQogIDxvOkNoYXJhY3RlcnM+NjU1PC9vOkNoYXJhY3RlcnM+DQogIDxvOkNvbXBhbnk+RllFVU5H PC9vOkNvbXBhbnk+DQogIDxvOkxpbmVzPjU8L286TGluZXM+DQogIDxvOlBhcmFncmFwaHM+MTwv bzpQYXJhZ3JhcGhzPg0KICA8bzpDaGFyYWN0ZXJzV2l0aFNwYWNlcz44MDQ8L286Q2hhcmFjdGVy c1dpdGhTcGFjZXM+DQogIDxvOlZlcnNpb24+OS4zODIxPC9vOlZlcnNpb24+DQogPC9vOkRvY3Vt ZW50UHJvcGVydGllcz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KIDx3OldvcmREb2N1bWVudD4NCiAgPHc6UHVuY3R1YXRpb25LZXJuaW5nLz4NCiAgPHc6RHJh d2luZ0dyaWRIb3Jpem9udGFsU3BhY2luZz42IHB0PC93OkRyYXdpbmdHcmlkSG9yaXpvbnRhbFNw YWNpbmc+DQogIDx3OkRpc3BsYXlIb3Jpem9udGFsRHJhd2luZ0dyaWRFdmVyeT4wPC93OkRpc3Bs YXlIb3Jpem9udGFsRHJhd2luZ0dyaWRFdmVyeT4NCiAgPHc6RGlzcGxheVZlcnRpY2FsRHJhd2lu Z0dyaWRFdmVyeT4yPC93OkRpc3BsYXlWZXJ0aWNhbERyYXdpbmdHcmlkRXZlcnk+DQogIDx3OkNv bXBhdGliaWxpdHk+DQogICA8dzpTcGFjZUZvclVMLz4NCiAgIDx3OkJhbGFuY2VTaW5nbGVCeXRl RG91YmxlQnl0ZVdpZHRoLz4NCiAgIDx3OkRvTm90TGVhdmVCYWNrc2xhc2hBbG9uZS8+DQogICA8 dzpVTFRyYWlsU3BhY2UvPg0KICAgPHc6RG9Ob3RFeHBhbmRTaGlmdFJldHVybi8+DQogICA8dzpG b290bm90ZUxheW91dExpa2VXVzgvPg0KICAgPHc6U2hhcGVMYXlvdXRMaWtlV1c4Lz4NCiAgIDx3 OkFsaWduVGFibGVzUm93QnlSb3cvPg0KICAgPHc6Rm9yZ2V0TGFzdFRhYkFsaWdubWVudC8+DQog ICA8dzpMYXlvdXRSYXdUYWJsZVdpZHRoLz4NCiAgIDx3OkxheW91dFRhYmxlUm93c0FwYXJ0Lz4N CiAgIDx3OlVzZUZFTGF5b3V0Lz4NCiAgPC93OkNvbXBhdGliaWxpdHk+DQogPC93OldvcmREb2N1 bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPg0KPHN0eWxlPg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5p dGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6t3Oy06n6xek7DQoJcGFub3NlLTE6 MiAyIDMgMCAwIDAgMCAwIDAgMDsNCgltc28tZm9udC1hbHQ6UE1pbmdMaVU7DQoJbXNvLWZvbnQt Y2hhcnNldDoxMzY7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6cm9tYW47DQoJbXNvLWZvbnQt cGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOjMgMTM3MjMyMzg0IDIyIDAgMTA0 ODU3NiAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6pf6vda9TqfrF6TsNCgltc28tZm9u dC1hbHQ6t3Oy06n6xek7DQoJbXNvLWZvbnQtY2hhcnNldDoxMzY7DQoJbXNvLWdlbmVyaWMtZm9u dC1mYW1pbHk6bW9kZXJuOw0KCW1zby1mb250LXBpdGNoOmZpeGVkOw0KCW1zby1mb250LXNpZ25h dHVyZToxIDEzNDc0MjAxNiAxNiAwIDEwNDg1NzYgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQLdzstOp+sXpIjsNCglwYW5vc2UtMToyIDIgMyAwIDAgMCAwIDAgMCAwOw0KCW1zby1m b250LWNoYXJzZXQ6MTM2Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJvbWFuOw0KCW1zby1m b250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZToxIDEzNDc0MjAxNiAxNiAw IDEwNDg1NzYgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQKX+r3WvU6n6xekiOw0K CW1zby1mb250LWNoYXJzZXQ6MTM2Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5Om1vZGVybjsN Cgltc28tZm9udC1waXRjaDpmaXhlZDsNCgltc28tZm9udC1zaWduYXR1cmU6MSAxMzQ3NDIwMTYg MTYgMCAxMDQ4NTc2IDA7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246bm9uZTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OrdzstOp+sXpOw0KCW1zby1mb250LWtlcm5pbmc6MS4wcHQ7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtVFc7fQ0KaDMNCgl7bXNvLXN0eWxlLW5leHQ6pLqk 5cFZscY7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbGluZS1oZWln aHQ6MzAwJTsNCgltc28tcGFnaW5hdGlvbjpub25lOw0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7 DQoJbXNvLW91dGxpbmUtbGV2ZWw6MzsNCglmb250LXNpemU6MTguMHB0Ow0KCW1zby1iaWRpLWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWZvbnQta2VybmluZzoxLjBwdDsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1UVzsNCgltc28tYmlkaS1mb250LXdlaWdodDpub3JtYWw7fQ0KcC5N c29Ob3JtYWxJbmRlbnQsIGxpLk1zb05vcm1hbEluZGVudCwgZGl2Lk1zb05vcm1hbEluZGVudA0K CXttYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNt Ow0KCW1hcmdpbi1sZWZ0OjI0LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBh Z2luYXRpb246bm9uZTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OrdzstOp+sXpOw0KCW1zby1mb250 LWtlcm5pbmc6MS4wcHQ7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtVFc7fQ0KcC5Nc29DYXB0 aW9uLCBsaS5Nc29DYXB0aW9uLCBkaXYuTXNvQ2FwdGlvbg0KCXttc28tc3R5bGUtbmV4dDqkuqTl Ow0KCW1hcmdpbi10b3A6Ni4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9t OjYuMHB0Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCgltc28tcGFnaW5hdGlvbjpub25lOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6t3Oy06n6xek7DQoJbXNvLWZvbnQta2VybmluZzoxLjBwdDsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1UVzt9DQpwLk1zb0JvZHlUZXh0LCBsaS5Nc29Cb2R5VGV4dCwg ZGl2Lk1zb0JvZHlUZXh0DQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CW1zby1wYWdpbmF0aW9uOm5vbmU7DQoJZm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OrdzstOp+sXpOw0KCW1zby1mb250LWtlcm5pbmc6MS4wcHQ7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtVFc7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6 c2luZ2xlO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5n bGU7fQ0KIC8qIFBhZ2UgRGVmaW5pdGlvbnMgKi8NCkBwYWdlDQoJe21zby1wYWdlLWJvcmRlci1z dXJyb3VuZC1oZWFkZXI6bm87DQoJbXNvLXBhZ2UtYm9yZGVyLXN1cnJvdW5kLWZvb3Rlcjpubzt9 DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjU5NS4zcHQgODQxLjlwdDsNCgltYXJnaW46Mi4wY20g NzAuOXB0IDIuMGNtIDcwLjlwdDsNCgltc28taGVhZGVyLW1hcmdpbjo0Mi41NXB0Ow0KCW1zby1m b290ZXItbWFyZ2luOjQyLjU1cHQ7DQoJbXNvLXBhcGVyLXNvdXJjZTowOw0KCWxheW91dC1ncmlk OjE4LjBwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQogLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTQ4OTU5MjAxNTsNCgltc28tbGlz dC10eXBlOnNpbXBsZTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6Njc2OTg3MDM7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDoyMS4yNXB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMS4yNXB0Ow0KCXRleHQtaW5kZW50Oi0y MS4yNXB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE1NDM4NjAxMzM7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04NDMzODYwNTQ7fQ0KQGxpc3Qg bDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDoxOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE4LjBwdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNt O30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjIwNTAiLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCiAg PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5r PXB1cnBsZSBzdHlsZT0ndGFiLWludGVydmFsOjI0LjBwdDt0ZXh0LWp1c3RpZnktdHJpbToNCnB1 bmN0dWF0aW9uJz4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMSBzdHlsZT0nbGF5b3V0LWdyaWQ6MTgu MHB0Jz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0YWItc3RvcHM6NDAuNXB0Jz48c3Bh biBzdHlsZT0nbXNvLXRhYi1jb3VudDoxJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwv cD4NCg0KPHRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCBzdHlsZT0n Ym9yZGVyLWNvbGxhcHNlOmNvbGxhcHNlOw0KIG1zby1wYWRkaW5nLWFsdDowY20gMS40cHQgMGNt IDEuNHB0Jz4NCiA8dHIgc3R5bGU9J2hlaWdodDo0NC43NXB0Jz4NCiAgPHRkIHdpZHRoPTM5NCB2 YWxpZ249dG9wIHN0eWxlPSd3aWR0aDoyOTUuNHB0O3BhZGRpbmc6MGNtIDEuNHB0IDBjbSAxLjRw dDsNCiAgaGVpZ2h0OjQ0Ljc1cHQnPg0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQt YWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KICBtc28tbGluZS1o ZWlnaHQtYWx0OjBwdCc+PCEtLVtpZiBndGUgdm1sIDFdPjx2OnNoYXBldHlwZSBpZD0iX3gwMDAw X3Q3NSINCiAgIGNvb3Jkc2l6ZT0iMjE2MDAsMjE2MDAiIG86c3B0PSI3NSIgbzpwcmVmZXJyZWxh dGl2ZT0idCIgcGF0aD0ibUA0QDVsQDRAMTFAOUAxMUA5QDV4ZSINCiAgIGZpbGxlZD0iZiIgc3Ry b2tlZD0iZiI+DQogICA8djpzdHJva2Ugam9pbnN0eWxlPSJtaXRlciIvPg0KICAgPHY6Zm9ybXVs YXM+DQogICAgPHY6ZiBlcW49ImlmIGxpbmVEcmF3biBwaXhlbExpbmVXaWR0aCAwIi8+DQogICAg PHY6ZiBlcW49InN1bSBAMCAxIDAiLz4NCiAgICA8djpmIGVxbj0ic3VtIDAgMCBAMSIvPg0KICAg IDx2OmYgZXFuPSJwcm9kIEAyIDEgMiIvPg0KICAgIDx2OmYgZXFuPSJwcm9kIEAzIDIxNjAwIHBp eGVsV2lkdGgiLz4NCiAgICA8djpmIGVxbj0icHJvZCBAMyAyMTYwMCBwaXhlbEhlaWdodCIvPg0K ICAgIDx2OmYgZXFuPSJzdW0gQDAgMCAxIi8+DQogICAgPHY6ZiBlcW49InByb2QgQDYgMSAyIi8+ DQogICAgPHY6ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4ZWxXaWR0aCIvPg0KICAgIDx2OmYgZXFu PSJzdW0gQDggMjE2MDAgMCIvPg0KICAgIDx2OmYgZXFuPSJwcm9kIEA3IDIxNjAwIHBpeGVsSGVp Z2h0Ii8+DQogICAgPHY6ZiBlcW49InN1bSBAMTAgMjE2MDAgMCIvPg0KICAgPC92OmZvcm11bGFz Pg0KICAgPHY6cGF0aCBvOmV4dHJ1c2lvbm9rPSJmIiBncmFkaWVudHNoYXBlb2s9InQiIG86Y29u bmVjdHR5cGU9InJlY3QiLz4NCiAgIDxvOmxvY2sgdjpleHQ9ImVkaXQiIGFzcGVjdHJhdGlvPSJ0 Ii8+DQogIDwvdjpzaGFwZXR5cGU+PHY6c2hhcGUgaWQ9Il94MDAwMF9zMTAyOSIgdHlwZT0iI194 MDAwMF90NzUiIHN0eWxlPSdwb3NpdGlvbjphYnNvbHV0ZTsNCiAgIGxlZnQ6MDt0ZXh0LWFsaWdu OmxlZnQ7bWFyZ2luLWxlZnQ6NWluO21hcmdpbi10b3A6MDt3aWR0aDo1NHB0O2hlaWdodDo0NXB0 Ow0KICAgei1pbmRleDoxJyBvOmFsbG93aW5jZWxsPSJmIj4NCiAgIDx2OmltYWdlZGF0YSBzcmM9 ImNpZDouL61erNOq97/EtrC5zqfruOrBv655LmZpbGVzL2ltYWdlMDAxLnBuZyIgbzp0aXRsZT0i Ii8+DQogICA8dzp3cmFwIGFuY2hvcng9InBhZ2UiLz4NCiAgPC92OnNoYXBlPjwhW2VuZGlmXS0t PjwhW2lmICF2bWxdPjxzcGFuIHN0eWxlPSdtc28taWdub3JlOnZnbGF5b3V0Ow0KICBwb3NpdGlv bjphYnNvbHV0ZTt6LWluZGV4OjA7bGVmdDowcHg7bWFyZ2luLWxlZnQ6NDgwcHg7bWFyZ2luLXRv cDowcHg7DQogIHdpZHRoOjcycHg7aGVpZ2h0OjYwcHgnPjxpbWcgd2lkdGg9NzIgaGVpZ2h0PTYw DQogIHNyYz0iY2lkOi4vrV6s06r3v8S2sLnOp+u46sG/rnkuZmlsZXMvaW1hZ2UwMDIuanBnIiB2 OnNoYXBlcz0iX3gwMDAwX3MxMDI5Ij48L3NwYW4+PCFbZW5kaWZdPjxzcGFuDQogIGxhbmc9Wkgt VFcgc3R5bGU9J2ZvbnQtc2l6ZTozMC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseToNCiAgpf6vda9TqfrF6Sc+tmekQKV+ttc8L3NwYW4+PHNwYW4gbGFuZz1aSC1UVyBz dHlsZT0nZm9udC1zaXplOjMwLjBwdDttc28tYmlkaS1mb250LXNpemU6DQogIDEyLjBwdDtmb250 LWZhbWlseTql/q91r1Op+sXpO21zby1hc2NpaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iic+oUK2wKr3oUKq0bK8PC9zcGFuPjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MzAuMHB0O21z by1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6pf6vda9TqfrF6Sc+PG86cD48L286 cD48L3NwYW4+PC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9MjUyIHJvd3NwYW49MyB2YWxpZ249 dG9wIHN0eWxlPSd3aWR0aDoxODkuM3B0O3BhZGRpbmc6MGNtIDEuNHB0IDBjbSAxLjRwdDsNCiAg aGVpZ2h0OjQ0Ljc1cHQnPg0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxl PSd0ZXh0LWFsaWduOmNlbnRlcjttc28tbGluZS1oZWlnaHQtYWx0Og0KICAwcHQnPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseTql/q91r1Op+sXpJz48IVtpZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZu YnNwOzwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQogIDxwIGNsYXNzPU1zb05vcm1h bCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyO21zby1saW5lLWhlaWdodC1h bHQ6DQogIDBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OqX+r3WvU6n6xeknPjwhW2lmICFz dXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CiAgPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50 ZXI7bXNvLWxpbmUtaGVpZ2h0LWFsdDoNCiAgMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 pf6vda9TqfrF6Sc+PCFbaWYgIXN1cHBvcnRFbXB0eVBhcmFzXT4mbmJzcDs8IVtlbmRpZl0+PG86 cD48L286cD48L3NwYW4+PC9wPg0KICA8cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0 eWxlPSd0ZXh0LWFsaWduOmNlbnRlcjttc28tbGluZS1oZWlnaHQtYWx0Og0KICAwcHQnPjxzcGFu IGxhbmc9WkgtVFcgc3R5bGU9J2ZvbnQtZmFtaWx5OqX+r3WvU6n6xeknPq1erNOq97/EtrC5zjwv c3Bhbj48c3Bhbg0KICBzdHlsZT0nZm9udC1mYW1pbHk6pf6vda9TqfrF6Sc+KDxzcGFuIGxhbmc9 WkgtVFc+rbu05Dwvc3Bhbj4pPHNwYW4gbGFuZz1aSC1UVz6ms62tpL2lcTwvc3Bhbj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQogIDxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9 J3RleHQtYWxpZ246Y2VudGVyO21zby1saW5lLWhlaWdodC1hbHQ6DQogIDBwdCc+PHNwYW4gbGFu Zz1aSC1UVyBzdHlsZT0nZm9udC1zaXplOjguMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7 DQogIGZvbnQtZmFtaWx5OqX+r3WvU6n6xek7bXNvLWFzY2lpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iJz6lfrbXpeap9rDTtVC306FHPC9zcGFuPjxiDQogIHN0eWxlPSdtc28tYmlkaS1m b250LXdlaWdodDpub3JtYWwnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC4wcHQ7bXNvLWJpZGkt Zm9udC1zaXplOg0KICAxMi4wcHQ7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6pf6vda9TqfrF6Sc+ RlhUUjAwMDA0MDwvc3Bhbj48L2I+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZTo4LjBwdDttc28t YmlkaS1mb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5Og0KICCl/q91r1Op +sXpJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQogIDxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1j ZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyO21zby1saW5lLWhlaWdodC1hbHQ6DQogIDBw dCc+PHNwYW4gbGFuZz1aSC1UVyBzdHlsZT0nZm9udC1mYW1pbHk6pf6vda9TqfrF6Sc+rV6s06r3 t36n67jqprOtraS9pXE8L3NwYW4+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtZmFtaWx5OqX+r3WvU6n6 xeknPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNl bnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXI7bXNvLWxpbmUtaGVpZ2h0LWFsdDoNCiAgMHB0 Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7 bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6DQogIKX+r3WvU6n6xeknPig8L3NwYW4+PHNwYW4gbGFu Zz1aSC1UVyBzdHlsZT0nZm9udC1zaXplOjguMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNCiAgMTIu MHB0O2ZvbnQtZmFtaWx5OqX+r3WvU6n6xek7bXNvLWFzY2lpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iJz6tXqzTtrC5zqaorfs8L3NwYW4+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZTo4 LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5Og0K ICCl/q91r1Op+sXpJz4pPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MzYuMHB0O21zby1i aWRpLWZvbnQtc2l6ZToxMi4wcHQ7DQogIGZvbnQtZmFtaWx5OqX+r3WvU6n6xeknPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCiAgPC90ZD4NCiA8L3RyPg0KIDx0ciBzdHlsZT0naGVpZ2h0OjM1LjI1 cHQnPg0KICA8dGQgd2lkdGg9Mzk0IHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjI5NS40cHQ7cGFk ZGluZzowY20gMS40cHQgMGNtIDEuNHB0Ow0KICBoZWlnaHQ6MzUuMjVwdCc+DQogIDxwIGNsYXNz PU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyO21zby1saW5l LWhlaWdodC1hbHQ6DQogIDBwdCc+PHNwYW4gbGFuZz1aSC1UVyBzdHlsZT0nZm9udC1zaXplOjMw LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0Ow0KICBmb250LWZhbWlseTql/q91r1Op+sXp O21zby1hc2NpaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+qve/xKfes06oq7bVPC9z cGFuPjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6MzAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6pf6vda9TqfrF6Sc+PG86cD48L286cD48L3NwYW4+PC9wPg0KICA8 L3RkPg0KIDwvdHI+DQogPHRyIHN0eWxlPSdoZWlnaHQ6MTcuMjVwdCc+DQogIDx0ZCB3aWR0aD0z OTQgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6Mjk1LjRwdDtwYWRkaW5nOjBjbSAxLjRwdCAwY20g MS40cHQ7DQogIGhlaWdodDoxNy4yNXB0Jz4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNl bnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXI7bXNvLWxpbmUtaGVpZ2h0LWFsdDoNCiAgMHB0 Jz48c3BhbiBsYW5nPVpILVRXIHN0eWxlPSdmb250LXNpemU6MzAuMHB0O21zby1iaWRpLWZvbnQt c2l6ZToxMi4wcHQ7DQogIGZvbnQtZmFtaWx5OqX+r3WvU6n6xek7bXNvLWFzY2lpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz656r7Upf6n8LKkPC9zcGFuPjxzcGFuDQogIHN0eWxlPSdm b250LXNpemU6MzAuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6DQogIKX+r3WvU6n6xeknPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgPC90ZD4N CiA8L3RyPg0KIDx0cj4NCiAgPHRkIHdpZHRoPTY0NiBjb2xzcGFuPTIgdmFsaWduPXRvcCBzdHls ZT0nd2lkdGg6NDg0LjdwdDtwYWRkaW5nOjBjbSAxLjRwdCAwY20gMS40cHQnPg0KICA8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6aW50ZXIt aWRlb2dyYXBoOw0KICBtc28tbGluZS1oZWlnaHQtYWx0OjBwdCc+PHNwYW4gbGFuZz1aSC1UVyBz dHlsZT0nZm9udC1zaXplOjMwLjBwdDttc28tYmlkaS1mb250LXNpemU6DQogIDEyLjBwdDtmb250 LWZhbWlseTql/q91r1Op+sXpO21zby1hc2NpaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iic+rsmoxrFNv+i4Z8DZp+u46sG/rnk8L3NwYW4+PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToz MC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTql/q91r1Op+sXpJz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQogIDwvdGQ+DQogPC90cj4NCjwvdGFibGU+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVzdGlmeTppbnRl ci1pZGVvZ3JhcGg7DQptc28tbGluZS1oZWlnaHQtYWx0OjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxNC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdCc+PCFbaWYgIXN1cHBvcnRFbXB0 eVBhcmFzXT4mbmJzcDs8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0OjIxLjI1cHQ7dGV4dC1hbGlnbjpqdXN0aWZ5 O3RleHQtanVzdGlmeToNCmludGVyLWlkZW9ncmFwaDt0ZXh0LWluZGVudDotMjEuMjVwdDttc28t bGluZS1oZWlnaHQtYWx0OjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMzsNCnRhYi1zdG9wczps aXN0IDIxLjI1cHQnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTQuMHB0Ow0KbXNvLWJpZGktZm9udC1zaXplOjEyLjBwdCc+MS48c3BhbiBzdHlsZT0nZm9udDo3 LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPVpILVRXIHN0eWxlPSdmb250 LXNpemU6MTQuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNCjEyLjBwdDtmb250LWZhbWlseTq3c7LT qfrF6Tttc28tYXNjaWktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPqywp0G3asO5rbu0 5LPMt3On67jqsFSup6FBpV2sQaV+tteoq7bVoUK2wKr3pdW7yLDKukGhQq27tOSnUbJ2qKu21aFB pUikzq27tOS4Z8DZvMa+2rnvvNOlq6TOqtGlq6q6vHbFVKFDPC9zcGFuPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjE0LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0Jz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MjEuMjVw dDt0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5Og0KaW50ZXItaWRlb2dyYXBoO3RleHQt aW5kZW50Oi0yMS4yNXB0O21zby1saW5lLWhlaWdodC1hbHQ6MHB0O21zby1saXN0OmwwIGxldmVs MSBsZm8zOw0KdGFiLXN0b3BzOmxpc3QgMjEuMjVwdCc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7DQptc28tYmlkaS1mb250LXNpemU6MTIuMHB0Jz4y LjxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxh bmc9WkgtVFcgc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7bXNvLWJpZGktZm9udC1zaXplOg0KMTIu MHB0O2ZvbnQtZmFtaWx5OrdzstOp+sXpO21zby1hc2NpaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIic+sdCnQadRpc6q97/Ep96zTqTAqlKhQaVouXe0+qRAtmew6rvapUStbrNmufShXbza w7mhQqTptuqhQq1ewumhQrfnpGiqa62moUK/RKS4oUKlW6S4oV6kzrbAqvehQqXVu8iqurV1oUKk pL11qKu21aFDPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjE0LjBwdDttc28tYmlkaS1m b250LXNpemU6MTIuMHB0Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MjEuMjVwdDt0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1q dXN0aWZ5Og0KaW50ZXItaWRlb2dyYXBoO3RleHQtaW5kZW50Oi0yMS4yNXB0O21zby1saW5lLWhl aWdodC1hbHQ6MHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8zOw0KdGFiLXN0b3BzOmxpc3QgMGNt IDIxLjI1cHQnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTQu MHB0Ow0KbXNvLWJpZGktZm9udC1zaXplOjEyLjBwdCc+My48c3BhbiBzdHlsZT0nZm9udDo3LjBw dCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPVpILVRXIHN0eWxlPSdmb250LXNp emU6MTQuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNCjEyLjBwdDtmb250LWZhbWlseTq3c7LTqfrF 6Tttc28tYXNjaWktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPrHQp0HF3r/oscCyeqFC r2S3Tqz8sOqhQrzarHehQqjIrHehQq27tOSsRqp2pM64Z8DZxdykxqFBpUio7ql3pKSq+L11p+u4 6rWmsqShQzwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7bXNvLWJpZGktZm9u dC1zaXplOjEyLjBwdCc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1sZWZ0OjIxLjI1cHQ7dGV4dC1hbGlnbjpqdXN0aWZ5O3RleHQtanVz dGlmeToNCmludGVyLWlkZW9ncmFwaDt0ZXh0LWluZGVudDotMjEuMjVwdDttc28tbGluZS1oZWln aHQtYWx0OjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMzsNCnRhYi1zdG9wczpsaXN0IDIxLjI1 cHQnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTQuMHB0Ow0K bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdCc+NC48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPVpILVRXIHN0eWxlPSdmb250LXNpemU6MTQu MHB0O21zby1iaWRpLWZvbnQtc2l6ZToNCjEyLjBwdDtmb250LWZhbWlseTq3c7LTqfrF6Tttc28t YXNjaWktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPqTAqlKs/LDqpGq/76vhrPykuLd8 p1+rT6v5sWq21aFCrPyq0aTJtl6576X+snm4Z8DZoUKzZrn0pM6q0aWrqrq8dsVUoUM8L3NwYW4+ PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTQuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQn PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJn aW4tbGVmdDoyMS4yNXB0O3RleHQtYWxpZ246anVzdGlmeTt0ZXh0LWp1c3RpZnk6DQppbnRlci1p ZGVvZ3JhcGg7dGV4dC1pbmRlbnQ6LTIxLjI1cHQ7bXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzM7DQp0YWItc3RvcHM6bGlzdCAyMS4yNXB0Jz48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDsNCm1zby1iaWRpLWZvbnQt c2l6ZToxMi4wcHQnPjUuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBSb21hbiIn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gbGFuZz1aSC1UVyBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDttc28tYmlkaS1m b250LXNpemU6DQoxMi4wcHQ7Zm9udC1mYW1pbHk6t3Oy06n6xek7bXNvLWFzY2lpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz605KRIwLOmcKbzrbG576SksOq4Z8DZp++tsqTOtb2lzqWr s/W2sLjqPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjE0LjBwdDttc28tYmlkaS1mb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OrdzstOp+sXpJz4/PC9zcGFuPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjE0LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0Jz4gPC9zcGFuPjxzcGFu IGxhbmc9WkgtVFcNCnN0eWxlPSdmb250LXNpemU6MTQuMHB0O21zby1iaWRpLWZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6t3Oy06n6xek7bXNvLWFzY2lpLWZvbnQtZmFtaWx5Og0KIlRpbWVz IE5ldyBSb21hbiInPqz1xHehQrDqpfiq0aRTr+CnX6r4pMmq+KazPC9zcGFuPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTQuMHB0Ow0KbXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTq3c7LTqfrF6Sc+PyA8c3BhbiBsYW5nPVpILVRXPrFNrmGxTrd8rLCnQaRApECxtLBRPC9zcGFu Pjwvc3Bhbj48c3Bhbg0KbGFuZz1aSC1UVyBzdHlsZT0nZm9udC1zaXplOjE0LjBwdDttc28tYmlk aS1mb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OrdzstOp+sXpOw0KbXNvLWFzY2lpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz6hQzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjE0LjBwdDsNCm1zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuMHB0O21z by1iaWRpLWZvbnQtc2l6ZToxMi4wcHQnPjwhW2lmICFzdXBwb3J0RW1wdHlQYXJhc10+Jm5ic3A7 PCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdtc28tbGluZS1oZWlnaHQtYWx0OjBwdCc+PHNwYW4gbGFuZz1aSC1UVw0Kc3R5bGU9J2Zv bnQtc2l6ZToxNi4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTql/q91 r1Op+sXpO21zby1hc2NpaS1mb250LWZhbWlseToNCiJUaW1lcyBOZXcgUm9tYW4iJz7Bv6rMPC9z cGFuPjxzcGFuIGxhbmc9WkgtVFcgc3R5bGU9J2ZvbnQtc2l6ZToxNi4wcHQ7DQptc28tYmlkaS1m b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OrdzstOp+sXpO21zby1hc2NpaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIic+oUc8L3NwYW4+PHNwYW4NCmxhbmc9WkgtVFcgc3R5bGU9J2Zv bnQtc2l6ZToxNi4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTql/q91 r1Op+sXpOw0KbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz6xabfYrHWl /aXNPC9zcGFuPjxzcGFuIGxhbmc9WkgtVFcNCnN0eWxlPSdmb250LXNpemU6MTQuMHB0O21zby1i aWRpLWZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6pf6vda9TqfrF6Tttc28tYXNjaWktZm9u dC1mYW1pbHk6DQoiVGltZXMgTmV3IFJvbWFuIic+oWmtXqzTqve/xLawuc6hXa27tOShXqazra2k vaVxwWC19KFqPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTQuMHB0Ow0KbXNvLWJpZGkt Zm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1mb250LWZhbWlseTql/q91r1Op+sXpJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxl ZnQ6MjQuMHB0O3RleHQtaW5kZW50OjI0LjBwdDttc28tbGluZS1oZWlnaHQtYWx0Og0KMHB0Jz48 c3BhbiBsYW5nPVpILVRXIHN0eWxlPSdmb250LXNpemU6MTQuMHB0O21zby1iaWRpLWZvbnQtc2l6 ZToxMi4wcHQ7DQpmb250LWZhbWlseTql/q91r1Op+sXpO21zby1hc2NpaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIic+rd246rJgp+u46rX7vdet+zwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2Zv bnQtc2l6ZToxNi4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdCc+PG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1saW5lLWhlaWdodC1hbHQ6 MHB0Jz48c3BhbiBsYW5nPVpILVRXDQpzdHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlkaS1m b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OqX+r3WvU6n6xek7bXNvLWFzY2lpLWZvbnQtZmFt aWx5Og0KIlRpbWVzIE5ldyBSb21hbiInPqTptME8L3NwYW4+PHNwYW4gbGFuZz1aSC1UVyBzdHls ZT0nZm9udC1zaXplOjE2LjBwdDsNCm1zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6t3Oy06n6xek7bXNvLWFzY2lpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz6hRzwv c3Bhbj48c3Bhbg0KbGFuZz1aSC1UVyBzdHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlkaS1m b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OrdzstOp+sXpJz6isaKvoq88L3NwYW4+PHNwYW4N CnN0eWxlPSdmb250LXNpemU6MTYuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6t3Oy06n6xeknPjE8c3Bhbg0KbGFuZz1aSC1UVz6mfjwvc3Bhbj40PHNwYW4gbGFuZz1a SC1UVz6k6zwvc3Bhbj45PHNwYW4gbGFuZz1aSC1UVz6k6abcPC9zcGFuPjY8c3Bhbg0KbGFuZz1a SC1UVz6k6zwvc3Bhbj4xODxzcGFuIGxhbmc9WkgtVFc+pOk8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6DQoxNi4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdCc+IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDoyNC4wcHQ7dGV4dC1pbmRlbnQ6MjQuMHB0O21zby1saW5lLWhlaWdodC1hbHQ6DQowcHQnPjxz cGFuIGxhbmc9WkgtVFcgc3R5bGU9J2ZvbnQtc2l6ZToxNi4wcHQ7bXNvLWJpZGktZm9udC1zaXpl OjEyLjBwdDsNCmZvbnQtZmFtaWx5OrdzstOp+sXpO21zby1hc2NpaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIic+s3usULTBpECx36RXPC9zcGFuPjxiDQpzdHlsZT0nbXNvLWJpZGktZm9u dC13ZWlnaHQ6bm9ybWFsJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlkaS1m b250LXNpemU6DQoxMi4wcHQnPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQnPjxzcGFuIGxhbmc9Wkgt VFcNCnN0eWxlPSdmb250LXNpemU6MTYuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6pf6vda9TqfrF6Tttc28tYXNjaWktZm9udC1mYW1pbHk6DQoiVGltZXMgTmV3IFJv bWFuIic+rsm2oTwvc3Bhbj48c3BhbiBsYW5nPVpILVRXIHN0eWxlPSdmb250LXNpemU6MTYuMHB0 Ow0KbXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTq3c7LTqfrF6Tttc28tYXNj aWktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPqFHsd+kV6RDrsmkVKRRpMCm3KRFrsmk VKRRpMA8L3NwYW4+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTYuMHB0O21zby1iaWRpLWZvbnQt c2l6ZToxMi4wcHQnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbGluZS1oZWlnaHQtYWx0OjBwdCc+PHNwYW4gbGFuZz1aSC1UVw0Kc3R5bGU9 J2ZvbnQtc2l6ZToxNi4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTql /q91r1Op+sXpO21zby1hc2NpaS1mb250LWZhbWlseToNCiJUaW1lcyBOZXcgUm9tYW4iJz6mYcJJ PC9zcGFuPjxzcGFuIGxhbmc9WkgtVFcgc3R5bGU9J2ZvbnQtc2l6ZToxNi4wcHQ7DQptc28tYmlk aS1mb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OrdzstOp+sXpO21zby1hc2NpaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIic+oUetu7TkxlelSrBhpae41rlEorGit6K3uLmtXqzTtrC5 zqSkpN+isaKyvNM8L3NwYW4+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTYuMHB0O21zby1iaWRp LWZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSd0ZXh0LWFsaWduOmp1c3RpZnk7dGV4dC1qdXN0aWZ5OmludGVyLWlkZW9n cmFwaDsNCm1zby1saW5lLWhlaWdodC1hbHQ6MHB0Jz48c3BhbiBsYW5nPVpILVRXIHN0eWxlPSdm b250LXNpemU6MTYuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNCjEyLjBwdDtmb250LWZhbWlseTql /q91r1Op+sXpO21zby1hc2NpaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+tk+lzjwv c3Bhbj48c3Bhbg0KbGFuZz1aSC1UVyBzdHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlkaS1m b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OrdzstOp+sXpOw0KbXNvLWFzY2lpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iJz6hRzxzcGFuIHN0eWxlPSdtc28tYmlkaS1mb250LXdlaWdo dDoNCmJvbGQnPqhDsPO05Ln0PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE2 LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0Ow0KbXNvLWJpZGktZm9udC13ZWlnaHQ6Ym9s ZCc+NjA8L3NwYW4+PHNwYW4gbGFuZz1aSC1UVyBzdHlsZT0nZm9udC1zaXplOjE2LjBwdDsNCm1z by1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6t3Oy06n6xek7bXNvLWFzY2lpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KbXNvLWJpZGktZm9udC13ZWlnaHQ6Ym9sZCc+ pLilvzwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlkaS1mb250LXNp emU6DQoxMi4wcHQ7bXNvLWJpZGktZm9udC13ZWlnaHQ6Ym9sZCc+KDwvc3Bhbj48c3BhbiBsYW5n PVpILVRXIHN0eWxlPSdmb250LXNpemU6DQoxNi4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTq3c7LTqfrF6Tttc28tYXNjaWktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7DQptc28tYmlkaS1mb250LXdlaWdodDpib2xkJz6q/rBlwb/Eszwvc3Bhbj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlkaS1mb250LXNpemU6DQoxMi4wcHQ7bXNvLWJp ZGktZm9udC13ZWlnaHQ6Ym9sZCc+KTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE2LjBw dDsNCm1zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGluZS1oZWlnaHQtYWx0OjBwdCc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxNC4wcHQ7DQptc28tYmlkaS1mb250LXNpemU6MTIuMHB0Jz48IVtp ZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQn PjxzcGFuIGxhbmc9WkgtVFcNCnN0eWxlPSdmb250LXNpemU6MTYuMHB0O21zby1iaWRpLWZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6pf6vda9TqfrF6Tttc28tYXNjaWktZm9udC1mYW1pbHk6 DQoiVGltZXMgTmV3IFJvbWFuIic+r2SueblxuNw8L3NwYW4+PHNwYW4gbGFuZz1aSC1UVyBzdHls ZT0nZm9udC1zaXplOjE2LjBwdDsNCm1zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6t3Oy06n6xek7bXNvLWFzY2lpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iJz6hRzwv c3Bhbj48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxNi4wcHQ7bXNvLWJpZGktZm9udC1zaXplOjEy LjBwdCc+MjU3NCAyMjU3PHNwYW4NCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PGI+PHNwYW4gbGFuZz1aSC1UVw0Kc3R5bGU9J2ZvbnQtc2l6ZToxNi4wcHQ7 bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTq3c7LTqfrF6Tttc28tYXNjaWkt Zm9udC1mYW1pbHk6DQoiVGltZXMgTmV3IFJvbWFuIic+pP2l/aXNPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlkaS1mb250LXNpemU6DQoxMi4wcHQnPiAoPC9z cGFuPjxiPjxzcGFuIGxhbmc9WkgtVFcgc3R5bGU9J2ZvbnQtc2l6ZToxNi4wcHQ7bXNvLWJpZGkt Zm9udC1zaXplOg0KMTIuMHB0O2ZvbnQtZmFtaWx5OrdzstOp+sXpO21zby1hc2NpaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIic+sKqvxbDGwWC19Dwvc3Bhbj48L2I+PGI+PHNwYW4NCnN0 eWxlPSdmb250LXNpemU6MTYuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQnPik8L3NwYW4+ PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIu MHB0Jz48c3BhbiBzdHlsZT0nbXNvLXRhYi1jb3VudDoNCjEnPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1saW5lLWhlaWdodC1hbHQ6MHB0Jz48c3BhbiBsYW5nPVpILVRXDQpz dHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OqX+r3WvU6n6xek7bXNvLWFzY2lpLWZvbnQtZmFtaWx5Og0KIlRpbWVzIE5ldyBSb21hbiIn PrbHr3W4ub1YPC9zcGFuPjxzcGFuIGxhbmc9WkgtVFcgc3R5bGU9J2ZvbnQtc2l6ZToxNi4wcHQ7 DQptc28tYmlkaS1mb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OrdzstOp+sXpO21zby1hc2Np aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIic+oUc8L3NwYW4+PHNwYW4NCnN0eWxlPSdm b250LXNpemU6MTYuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQnPjI1NzQgMjc0MDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGluZS1o ZWlnaHQtYWx0OjBwdCc+PHNwYW4gbGFuZz1aSC1UVw0Kc3R5bGU9J2ZvbnQtc2l6ZToxNi4wcHQ7 bXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTql/q91r1Op+sXpO21zby1hc2Np aS1mb250LWZhbWlseToNCiJUaW1lcyBOZXcgUm9tYW4iJz65caRstmyl8zwvc3Bhbj48c3BhbiBs YW5nPVpILVRXIHN0eWxlPSdmb250LXNpemU6MTYuMHB0Ow0KbXNvLWJpZGktZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTq3c7LTqfrF6Tttc28tYXNjaWktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiInPqFHPC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlk aS1mb250LXNpemU6MTIuMHB0Jz48YQ0KaHJlZj0ibWFpbHRvOm1hbndvbmdAZW1wZXJvcmdyb3Vw LmNvbS5oayI+bWFud29uZ0BlbXBlcm9yZ3JvdXAuY29tLmhrPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbGluZS1oZWlnaHQtYWx0OjBw dCc+PHNwYW4gbGFuZz1aSC1UVw0Kc3R5bGU9J2ZvbnQtc2l6ZToxNi4wcHQ7bXNvLWJpZGktZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTql/q91r1Op+sXpO21zby1hc2NpaS1mb250LWZhbWls eToNCiJUaW1lcyBOZXcgUm9tYW4iJz62sLnOuvSnfTwvc3Bhbj48c3BhbiBsYW5nPVpILVRXIHN0 eWxlPSdmb250LXNpemU6MTYuMHB0Ow0KbXNvLWJpZGktZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTq3c7LTqfrF6Tttc28tYXNjaWktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPqFH PC9zcGFuPjxpDQpzdHlsZT0nbXNvLWJpZGktZm9udC1zdHlsZTpub3JtYWwnPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTYuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToNCjEyLjBwdCc+PGEgaHJlZj0i aHR0cDovL3d3dy5lbXBlcm9yZm9yZXguY29tLyI+d3d3LmVtcGVyb3Jmb3JleC5jb208L2E+PG86 cD48L286cD48L3NwYW4+PC9pPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28t bGluZS1oZWlnaHQtYWx0OjBwdCc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjE2LjBwdDtt c28tYmlkaS1mb250LXNpemU6MTIuMHB0O21zby1iaWRpLWZvbnQtc3R5bGU6aXRhbGljJz48IVtp ZiAhc3VwcG9ydEVtcHR5UGFyYXNdPiZuYnNwOzwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48 L2I+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1saW5lLWhlaWdodC1hbHQ6 MHB0Jz48Yj48c3BhbiBsYW5nPVpILVRXDQpzdHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlk aS1mb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OrdzstOp+sXpO21zby1hc2NpaS1mb250LWZh bWlseToNCiJUaW1lcyBOZXcgUm9tYW4iO21zby1iaWRpLWZvbnQtc3R5bGU6aXRhbGljJz6mcLZR pL2lcaSjsf2mQaasqOytXqzTqve/xLawuc6qurZspfOhQTwvc3Bhbj48L2I+PGI+PHNwYW4NCnN0 eWxlPSdmb250LXNpemU6MTYuMHB0O21zby1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7bXNvLWJpZGkt Zm9udC1zdHlsZTppdGFsaWMnPjxhDQpocmVmPSJtYWlsdG86vdC5cbZsptxtYW53b25nQGVtcGVy b3Jncm91cC5jb20uaGsiPjxzcGFuIGxhbmc9WkgtVFcNCnN0eWxlPSdmb250LWZhbWlseTq3c7LT qfrF6Tttc28tYXNjaWktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiInPr3QuXG2bKbcPC9z cGFuPm1hbndvbmdAZW1wZXJvcmdyb3VwLmNvbS5oazwvYT4NCjwvc3Bhbj48L2I+PGI+PHNwYW4g bGFuZz1aSC1UVyBzdHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlkaS1mb250LXNpemU6MTIu MHB0Ow0KZm9udC1mYW1pbHk6t3Oy06n6xek7bXNvLWFzY2lpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO21zby1iaWRpLWZvbnQtc3R5bGU6DQppdGFsaWMnPqnOtsevdabcPC9zcGFuPjwv Yj48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjE2LjBwdDttc28tYmlkaS1mb250LXNpemU6DQox Mi4wcHQ7bXNvLWJpZGktZm9udC1zdHlsZTppdGFsaWMnPjI1NzQgMjc0MDwvc3Bhbj48L2I+PGI+ PHNwYW4gbGFuZz1aSC1UVw0Kc3R5bGU9J2ZvbnQtc2l6ZToxNi4wcHQ7bXNvLWJpZGktZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTq3c7LTqfrF6Tttc28tYXNjaWktZm9udC1mYW1pbHk6DQoi VGltZXMgTmV3IFJvbWFuIjttc28tYmlkaS1mb250LXN0eWxlOml0YWxpYyc+oUGko6tLpKezQqFB wtSmua1QunChQzwvc3Bhbj48L2I+PGI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTYuMHB0O21z by1iaWRpLWZvbnQtc2l6ZToxMi4wcHQ7bXNvLWJpZGktZm9udC1zdHlsZTppdGFsaWMnPjxvOnA+ PC9vOnA+PC9zcGFuPjwvYj48L3A+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4g ------=_NextPart_ALo8WsHoAiZAMoje5IriauMAA-- ------=_NextPart_ALo8WsHoAiZAMoje5IriauM Content-Type: application/octet-stream; name="./­^¬Óª÷¿Ä¶°¹Î§ë¸êÁ¿®y.files/image001.png" Content-Disposition: attachment; filename="image001.png" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAPUAAADTCAIAAADWJsIZAAAABGdBTUEAALGIlZj0pgAAAAlwSFlz AAAhfgAAJRYBkJl54QAAIABJREFUeJzsnEuQncdVx/+nH9/jPmekmdHIkvWwheRYxDg4cUGomLgM xYYqVizYsGHFBliQYsEiBTvDgg0QQlFFscBAQaqwqwj2IgQ7KZsothK/ZY3keUij0Z25r7mv79Hd 57C4V7KIZc2GKjul+1vdmfqqp6e/33du9zndH4kI5nwyDHjvI2Occ1ZbCAAUWRmnkS+DiXVZ+Cg2 wQcdaQacQAhKAJq1QLcaUupWowHMAEAECJQGMwTQBgAUI88liQkABKMR0gq0RmAoDaKPWr4rIkI0 uyKEoLX+fx2PnzJo7ve9YSCEYLVmZiVqao8EkL7lmQAKEIGSwrGyBgIQRCAAERQwdZKZmVkEGtro jyRlggJKLsU7Y4zWFqLKAsEjTQHABwDI8lG9UfukfnrvtdZTs+9U/D5n7vfBTIeIiMTPPoAQnHeu NMaE4OJKLMykIULeEQBSIBIiATGRAEK347iIggZmYTXLRsogjgwQAGFxIkqrGIi8V0YbAD54YyBw BA0YQH28k957Y8ztDouIUne57H5j7vcBTGMhMyulwADgnTeRgQBgEEMCSJwvrDUQAWmAMb0UDAjg mb33bK0lmmqtIBK8ANDWAhxCrvTtkKsAC8QhkNaxiDhXRJECWCCE+K5+f7zbmD6K9zfm0+7AZx1m 1lrPYiEBACkAyLJBWk1cntnEgD0kByyI4TMRZvEAlAIZBSilZLe1Wa1Wa7WatbEIiYi2EWDLSaGU MdZMpzAAXMnC7IoiTqogkJBRiXdiDDEHre8ut4gURcHMURQZY4hoGsXvc8Xnfh/A7e+3Xq+3uLAo EG0MwHFiATaWAA8VlBQAl1lvPNodjvrtzu7u7m6/382yzAsT0Wg0iuM4sgmAIFBkqtVqmjQePvn5 lcNHDi0fstb4UIK0tSlIRXEMUXmWWxtrS8EF54O19pP66b3P8zyEoJS6PVGZMx+IA9CkpuvFVqu1 uLjoShdFEcBKExDeevsiSbmxvrZ7c7t0k932xrHjFc/DsiydcwxRSllrtdZkpPAycQieRURrOyiM pfS9dy6kUc37cjDsK6OPrBxdWjkWRY3jxx7+4pNf1VHIy2E1qtmIAQ94IL7rXTPGTP/Qnc/AfR68 Mff7QOjWKq3b7WKaK4yMiBAhn4zWPngvm/Q/vPJ+p91yPmvtbr36WksbttYqrQGEEJwLIQRlIu99 ENFaRzZRSpWBQ+5RUC2tAb7wRZpWk/Ty7l7/6odto+Pnn3/pZx9/UlHwziujFRnBJwpLRNVq9faE hHn6FN3XyUHM15cHI5xnmTGRiSyAIMLig8usIQnlG69//3uvfOfq5Xde/u/vDvYxHCOEWVoQAu/B hGnKnO7MGCoACAEaiIBailGGNIXWOP3QUq+fd3uT3pCHgzxK41k3bqe9CQK5864R0TxOfxLz+H0w SZpCBIBzTlurSes4UQjQfOjQofWra9vXNwd9eIdQQhloDa2hFKyJ4jgVobJwRJpIE7SITIMrkdZU TPZH9RSTDBHhS186q226s/2uKzg1kdURBK4AA8aAARsB/1fo6SJyugj+FIfoM8vc73vDHBwBpO20 PqNEiOB8iA0APPDAaru9OxoNalVIQJbDM37vD37ja1/7o+byUYSQD/MkqSKuIHcwBspCBEEgAmMA B0x+/ctfUKp/+DB+8RfOH15a/uHrb4ogTkqKJlCxrRgAIGhiBkiI7ihgTvMkn9Lg/BQw9/ueCJS+ nc9WcRwzAAgROe+sQbXRrNfrw150bLW6tzterGNxBf3u+vPf+vvl5dUjK0dPnnwoTCq9zuD4iVMI EYyBtlDT2nsJePjxO2/1m02cO/tQJTFXr6z1ugjAkdU6XIHYZpP9tFIH8SQbRUkFAdMkOt1iXse5 B3O/D4RdUQhUlKTM7Jm1MUYbggAeUEeWV/e2N3WlMtgfg9DbRTFu7+1svP7aKx+ubWgV1SpNLsUV nkRZZaMoiW0kIq7IsqJ4/4PtokC/g+XF45FqfPuFf401soBf/qVfgW2AjQSBKIiKTF2RVga4tXyc 9m8++b4Hc78PQEIIwcVxCrBSyigjQBBY0oDnwjWbi436QjHhWCOKUG2gEVExbO9sXL56SRJbLC0O jUACgoMSxDaKogjBj8f5cILxAMeXcPrMA587d7bT63e7EEElxurqCvIJ0kYSze4RKThfxCYGMI3Z 85nJgcz9PgCRkFQq05L4cDis1psAFCkWr4iUttVq9fTp0zvXw9GjKp9wxSC1XItpeaF2YmUYaVRT HXIWghAQyCqxEgjQhkwqBWN/iKe+8kQch1e+91KWwQNPf/nM6YdXS9+PSKtYQSQr8jSJCcq5jMhO t1Ldjtyz7QNzPsbc73vDPmSRteUku3jxYqu1d+7cuTNnzwoCaVGaYIqo4o8+2Oy0fa2JfheaMdgb 6sLubw+zXUiEKAm+QDUFCSAwYM2eiGKj00j1J+Ujj6/09/Zf/cGF998fVhrIHZ7+ta+My70333lF m2j7Zqu332fiR8+fX1hYOrRwzJpaElfjqAroW3lDnvVX7rB89vv72vv56vve5EG63g/+6z9ffO3l l91kfPPmjdK7QyuHz37+XONwPfdZJSGXtS+988aNza3+DXTWgRyPPBTLxA07XNHwOQ4fjphZoAJE RIhFRMASyNjmkbevXj/5yMm1a5ubXeTA7/zuM6cePl5vxEpLEqvJZFSt19q9bpqm3c6wXl39t395 8W+/8c8P/cwX2Bsh6EjyYhTFCaAAA8G04KqIb/l9/yo+j9/3RjTJ2salt378Wm9vq797s9dpj/NS sPLKy1cOP7DUOFxfXWku1PTxE4uNZBKO0dv5XnsTWa+QDLFDI9I5gnU0KTwDQggCEoBBAhYniUsU ht3haB8A6jWsrKysHF2BjPf3W3lWClyFmd1gd3/3+rUWu7XWzvo3v/GXz/753yhtp1vPkzjiqcoy Kyfd4n6P33O/D0S9efHNV199bdzp7u+NqwkCMB4VOXll+9bqNjy5pBZVTfNI43BzsBVNWtujESRD 0yCKIl9kzKy1UgQhkAiJTBVXROPB3pGlar8cTAIMcOKBaGmhWY5G2rBGlMRJlo1vXNu/fGWjtdvp 9fZd7r3Hc8899+xf/B0YRR5KN6w14wNO9dyvzP0+AEa4cuXDa1s7O5u+nGB5EWkVncv7qyfj7Ws7 nfZeo2GjR8+sPnzcM1mfNGvNJNmGgBWUmtZfwMxEJLOdWlBEYCEFImRjPn2qhq5f2PN2EV/8uUeX FxobW1eXlpva0XiSbWzd2Njcfvvd7a3rsCkaFQSPdjtABAFxouO0AZTzWeZdmft9ECI3ru8UhXcl BCgdIo/hADYtCg8Wf2TJlw96yrVkpt3uZ4Ms0rrSsA65dgghhABmzp0Emi0DFWbzExCqCRCGGsXp E0gXa2eOH6U8C+NJx5U7OzvvXrp0eW00ytAfgYEHT5ivPvXEiy/+AMBkMEjiJWUJQOBAal6fvwtz vw9AkS4mWZ5BW4iHjeFKEGHzKk6dghA4w+Uff9DZ2F5aaHAmO9vd4EJtsTnOnS8DESk1PQQ021bF AAlIzfxeOYTW9cmgxNIJOy6y1tbWbmun9G59a2OvPb50BQEIgAIWD9Gf/smzj37uyIULP+zs8vr6 +vnHll0pxnJRFkla+bSH6rPI3O8DcEW+uLiY58gzAHjmmac5uCwfTka9EyePvv2j1zudsLbDH8rg 5x/zXIT2TgEHrgdXBg6IoshFhWNRBtONI4pgABJoBgixjUb9Mq4jUerKpkuSjd3u2CbY2IRnGOD0 MayePP3u5a36odXf/K3fXnvvu95z6fDGG2+cf+xJGxFIVdIKH/SP3J/M/T6AtcuXatUUQJxioa7/ 6q+/Sc0mQgEd0Ln5x3/4+xcvXEAMeKSovr+2FxyMoJhkxQR65ndUZkVZIExLPEC45TcBLneRxvHV KIrq+bio23SvGGcTLNcxyVFP8atPP3Xm/BODf/rW5a0diFzb2m4268BwfX09FAyrtIUPXun5rbwL 80GZcbsEyMzT14YopcC+32n3ux1rsd+HUYHqC4D+j3/8h4qV1o31cadPBaoWSWxbm3vLDeUca8Fk VCYRtGB3p60UiGBjaMz81vKR38OBNBvod8rQa589Rt2dbjOCEHoDVDXOP36qHsffeenb169teQeQ BHZZlgF44YUXvv71P4OBMIcQ5n7flfmg/CREND2fO/1hNOhJKKbJN1GAshAMB+PnX/x35cY761fy HhoLMGQ4TM/OMBEUQRM0oAhEs1M3ctcM3ixjrUhI3zoNLIrrBv0xeq0WK3Pz+s5gH2wAcJZlznkA 3W6XgyhLRBRH8Xx+clfmfs9QSk3fv3PnW0RIQq/TCr4QAQNQs3M47Xb7f77/5tFFmAIVhVRFNug8 LwJznCgCT2uGt18BRISf8I8EBEDApCAEKMWaiTULSCHwQoXGQxn1M4+bvc6YedZWnufTFjqdDhFB MNttO+d/2Tu3H7vuq45/1/r9fvtyrjO+J06cpLXTNoqbBBMCKNwERkUgUQl4ROIdxAMgFR5APPDK W/PAP4CoQEI8lLZpREpKipTm0jTFdZzEsRPbc/HczpzLvvx+v7V42PvMjO0xr0Hy+ehoa49mztlz 9v6eddZet99hLPS9DzMfrFhSVWN4Mt42HPbmUTX1HttbWwYY5nk3Fymq3DjxkEpFQRkIIAUA1Xlb 2nxcmzSj2w6gRAqGMgisTKrQSEAvyzvJzAEUJGF0DCQBgLqunbNAqGohBxFw+1lZcAgLfd/BwVpq ZgYkhCpxRAolyLwJcjweZSk6SZKEsvQIoUC0CVmyBlK3+hY0Rlex/8SDsEIAJY0kBw6tRgUEJ5QS DBAjIcIxlFOInc1mAJyFD4CCGSBS6CJ/eSgPdHHCQURaD6IpOGttefCGorXUugcMkELDdDq1DKMi dVVNUc1EYjRqnDF75rmpWxOd2+9DIQhJ5CgUhQRtiEVYUJe1BqiHn9XFBLWHBobYqqhDCDGCCLNx 0X4tyML9PpyFvlv2JBJjbHa896urq8QwLCJt1zBihPfT6cQy2MARLJBZZMaxwlfBEPPcUacDN5eH 0gwmVIKSKAWhZsgJGChnHoLUOmcyEjCAmEDa2RKiIML6+nrzOosWnvux0HfLXv/5XsFwURSrq6sA lBho9G00eoRpqMa+hoaaibIEeW6yTkpOolZgkGkqT9qHcitxObA9uNP4zwQYqFEYBYC6hjHI+73+ YNjrZSlZay2U+/1hlnYAMGO0uykRUIYm+3M3aW+YxMKoL/Q9J4SAAwOzY4yDweDZ535mNCkGgxNs UJcw4sgmUo19sUkRBtXKDR3vojtcKkKxMatri4AQ5sGWffvNUGojgTqfuqkAwFoZlI5K4hJcQWuE gBBw7JStgK3p9rieTaqy1KCxQl06m3mvABR4+vyXiKARDAu1AN8j7gf9+j7o73+PlZWVpsqvyfK0 Kg9+uNSfltPpFAQgGgRMRpNe3n30Ye7nA4koAmZFVWndXcbpxzM9zFTfhc4TmVAKddSgpJww5ykG PSwPsHQEYKoDvJJJ0zR3sXGcssS5NMbIBiHAJLYpQtz/6ADzbv89fT/Ql/iBfvMH2dra8t7f3cVI wqZW2e1kMITUZUBnc63Y3dbxDo1GRAZHj/BgaZkMfEBVt8HpuXE+5ECk+w+QZplNUrARESlLjMbY 3MbtDRDloojBMGXWdCJQ1wHKnU7mfZUkTbBSgf3g4z0sLu4iPjiHiJIkwXwiVNO9axI7me7Wvkiz JhKiAMcAMtlkGscclZBkg0hmWmAyg9mFozb43b4swAptPGzCnc01IJUss1FEIkJAs40RXrGszQTZ tKxCiGJa50OWhwPv5/cIJNgLDS7uMA9joe9DODAcnh85fWZj9dMsg2NkCU9XPrm9sbq8PLxtEUmn Nda2dqsYplNkCbod1DPca7VJwbQfJeR5sFEI3tdKYEKSgFImMgoWtjvjKqitSynr7dmscAAnBIrd bk4MH3DypEHwsAkRtyb8Dok/6J5Jw0LfLUTkvU+ShIj2YikxSH944tbqzsotRMEnn2587a/+9MNL b//43bUUMDR1HbBNKOn0hkpmVpcqmNdR3SPzPbu+t8MKZYAgAhWoSDNcJZJs7E6nNQqEGVA1t6Ra IU6qesoMVbz4S7/Y+NnEjD2HfhEzuZOFvluOHj3qnGvmwzdD/YgIap7+0s9/79hrx45+PBmDFP/5 2reqAhEY9nHmCz3rB+VOEHGJXRLNNrY2h33WudsAAAqi1kU5aF9b00pgRlSIwAfUAT5ILVLDq0Xt USnIopNh5lELYMubtz4JAcy4ePHX2zV87vZMDvQUP/BpzYW+Wx566KFmnR0Rcc6FEJxzxqXG5sR5 WWC0i26Kssb555KOlQvnn3n01BNXfnTr9f94e2u9PDbsHT826HRTQWjWGTGAUBvMbuB72tkFmE3b ALkybOasSVLmwIzU+a1NCdpZMknP3d4uxwVgi5s3r9c1iHD+/HkAqoHIiigM3Wm8+RA/6cFjoe+W JnLinKuqau9HjfH4qZM+RiIM+hj28Ht/8MsPn+72co5eXn/zh2++fn1zDb0E66PJzmQyHODMIyeu X10/3neW7c5a4RipAxhpzwaJqgppI+KNZV1aTsjY4ZETN1fWP7k58+RHgqUhdjeQ9fHE2ROua0bT rWfOnXzuuS//4z/8/Wh359zZU7durT755BchQparokyzbOGXHMpC3/scXPygSfeoiqE4KXYGR+zH H4avfOXCU0992SbVlQ/+5+0331m5UazcRhExKtABHlnCkYfs9mRrawQHP8wjCGmKNG29+XZJNQLN M/Oi2N6uA+oybm3vzoJBFeGBj0Y4MsDqCONr60dPYvl459jJZU5ka3TbRzscHoWu5lk/BjWG0yyZ TKadfvc+7+qBdlEW+t4nxhhjTNMUQLMFCNDOUvLwIyePH9NHT5/95je//96ld73HJzegCqPoGBxZ wuce5TOnk+ODpY+v7CadYFKYxHFacWLIGhFpOyTQlhPSPIvZ7aWloI6ysosp4IHPnT26tr25MYYH EFBt4ubmbG3r8ur6Sm/p+Cefji9fXoMi6QygSVXWaWp7ve7Cfh/KQt8t7733HjMbY86dO9dkMcuy zDIUfvr8Cz/32itvr97cfe+dbziL7QnIIBBOnEwuPPv8L/zssymPTgxr9ddGm6O11dgdzrq9riNb jCofYzMFhQAlbTTdtDs0Vnw0rTqDftLpApMIJAl+83d/Jxv0Prj+0ftXr1x6/+qtdTCj9NgZjwij z587u3F7LXEALNSaRXPD/8lC3y11XTdrnYUQmLnROmATNxwsnb70/m4vMZMyAkgSPPb5x773g/92 ad7N88n2yr/+00tV+VEnN72lzvbk6swjQGuJ0xoxwBlJ88yL3zuWAESIgAJFjWGSDI4sHzm+GcZ+ IhBjjz582iwvPf7U009fuPn+5Z9cufzT1bUwGSPP8fJ3PlTgT/74jyDWF8F1cgCzqc9691068EFm oe+WCxcu3NWf5pwDImH4a7/61Rdf/OdXvvNfCcxf/Pmf/eVff81100qJXRpg+8snkaQcO6NJee3K 1a2RHxcIS5KyEYUPCKJOQ9Me0RaJULvmvAJpillVhu2tovZesVnjB2+88TTp3/zt3yHN2srD2n/3 W99+6etff/mVNxQY9HDx4m8BxmWpRoig03ECzCM0d/Jg2/eFvlvuWhm1KApjTISWte11HvqXb7y8 fvP2mYcfEqrtwAStLKcVag+UvqqCWeqfKKc3bq3tjsaYlQhRTWpdBhMRFEXlXWqBtoqwaeoBIMDm NqrtKSfTiYBzcIWPrl1/8sLzSHNQKhES1Nqli7/9h7/xK79Pqbl86YevvvrqsaMn/ax2uSXGfRY0 XgB81vo+9KboYGHnPUFcnU83mz9XYHGwkun+dc/SmrcaUAYJwGABMxjAu+++OxgMHjn9aIyx2+2k NmXDICRJXhZ1t5+fOHWce47JRV/YJK2hBtGiMk5qP13Z3bp65fZbb2k5QhWxW1SDTmZzOAEItcCQ 6N5NZTNIliCAWqjCdLCUk7eOxvWH13Y31rd8IS53qixNZpIgLjcJvvjsC48/cTYbHgd4ujPr9Dtk oQrea/G8b2Ze2hO4B2HvbN4FH/xL3fvj/dMr8yfx4cf6//KZ+0z0Lffs7P9K4AEwDGChBwb+atNL 2xRaBCACQWAVFgpRKBB9JBZnCe3o6yaNyAIQjECBmjAdFRv9vM9IK1FRm5q8quMzzz1nQN6LMykE zIzQnp4kJaFZ5whDAyIbk0OQUJB6J0krYGrcji/9B9fGK5swEV+9eCoBr9+4lQ05AVs1vqp2x5Jl YHAVxBrj8qwsy/WdWCQIjLUdvPCFx2y3c2P9kiN8+9/+3b2UINrpeNZb6kTCrPJp13mNKUw2PAEB NHYGGXGTKdXGFmikZg3YJoevCq/BOWbA+4pJjbGAhLpmtsQWbAQMIjkgYwJiFFY25mDZ7fySURCI IkrrDzkJAsBaq6ohBGMM856uPmOhf4b2+6DK+cAWd+63aJynRebUoa5DnaU5ACIYwCQGoFDPynLW 6+UgIRZADZqWswjEt975/nQ2fvSRxx5/7Jwhk3IHqPLEFuVunvad4+g1BFJVX0eQdHqJ4SbUEUEA ZxDUFayVLHXAxhtvfjdx9XYxufTTT4Og63D0xOnl3lJZ0Y2Pbu5sSD8Lwy55aPAskatSRIUmZenj qMQMQILBEZQqtq4Gy7wzlm4nQ8KQkGd2d2fcXe5zytMwyW0mUCIQg9i09rppn48BzGSkDbaTkKpI ndoYtZwVpUhI2JgkgXU2ZSA0DUNQimLUWIUB4BqX3zArIIhRScFMuGN8Z+teCdhAQAJlQIjYWisi qrFZ5O0z5zPUN9+zz4BlAPvnMoDab1tyAKCiEpXYMieJza0NXmbMUJgool4tG2uzXs+CPFCXO+tr t6/dWv1ode365s5aUVSnjj22vrbz4Y/fPXrkZJ71z5x54tyTT7nuMHcEGkN4Vpfd3lDBLmOGDV6t tYJQljOCS/MMgM2af08AXL70k2I22Vi7ubHSVlZd/bTSeuXa1a2tdZT4X+beNNbWKz0Tetb4jXs8 w52n8jwkLperyhWnKpVUZywq1RDSSSNAYhICgVD40eJHAwnQ6nQ3EopaDR0kaGhA0B0hIRLSZCBd U+KabV+X7Xuvfcdz7hn3/M1r5sc+13aVXdWdH06ydH5sfefT3tp7Pd+rZz3v+z4vpIJYnXQbr61R CMBAARmYB7Nz7XQJenB06szmcGtwMFsU0+K1b3/p6Y98XMTZME4ASwHJpbK1R5BcUlAPplvrXYiE 5IIDHkSDGKBxoda6tK6F777+4pcW80lVVZQySQQCzbL+cLD5I5/4MRH3EfUYEQzSewRwRnlA8DYE TyiXoIxRggDvPCXr5jfqwdcDmelJDpZzhgfNq5QQ/IWaNPvnMp/ku8sk3udfb0+TwXfdSQBQa5z3 YJQxBk8B1CZUTps0StYHt9n9u4f7u9/++h+H0FpXa7syprSu9kEhCKd75aLjnCdxBtAoSfv9caDs yaefeeixJ7cvXQGEBzcIjXUxz5KQwAPUgngbqDGEM0YZCDrrj1eLN37vd//Rjddee+3l17/25c5p bG2SQX9r//5xpcEASSAZaoucwvuTZKID9BoagAEUMO7hI8898egTHzqeHrx09dXjiX3iyYf+4Cvf MI0R6aBr9HrGlfYdmCdgADFGwZM0igEPOMAA7Xy6s7/31u7em4dH94pyarrmzHhcV1XbtiSAeOI9 GJUyThmNq1oRkTzy6JMffvb5M1ceAjg8A80R1uQQRlsQJqLYfzchf7BHnpzwb7oumgdASCCEvWuL /5z5yZ8Bvn9gI+B7P/yd04x/QKM9EDqlZJSuu2iDRwgIHi4YsCJmBjDWlle/9eJb16929TyWONi9 Z9qqqcumrFSrjTHOBe9YsTTEsTzL8jxlTPgQvPetNWcuXppVTZDJM8//yI//zM9euPIoQUSRkFbC gCeUCOJBLaixEBxAFTD94y/81v3br7/6zRe/9qWbtsbGOH34iWeYTI6Pj+u6BSWEsKzXs9Y75zih aZoNev00TSMRJ0mSJAkI29reSHvyuY8+XTTzf/gP/8GLX/v6mzfrusRKHcHKrnFxvgGPpmjSUeoo LIL3StJAoCi6sj0+Pr730jf/2Jmqa1ZNtWibQuuOBE896eaKB6F117QVvOeCBkBrHWjoDfpZ3m+t ni8LJvjDjzz6yKMf+ckf/1cIG0Cm4BzgINR4OE8Zj97eIvpgi2iA1kYIsZYxnfMBnoASiveb5/bn 0BL658dPfvBjFQDy9g/hAcIjCXjAOh8IBGUUDAIOqA6m19549aX93dtNMWuL+fRgd3F8kEqhyrpa el3DGXgHY2ANGIU1WOqaESQJsgxZliRpurj71qprC2V37lz//f/3/966cOknfvqz/+LP/1UpN+BJ V1c8ETSKCUA58XAEVkBcv/5mMzuOeEosLmyxD3/kmf/0N/87EAJnISRCgDaIYsAB78q/hADvEQJs gMhBgGKGYTqcibQX9Ya9LK+Nwf/w3/73/86//9fiWK6BkSap1/AcynVZRAjazky+/dIXd+++TkK5 XB7aruqKoirLtmjqomwq5RrXLRFRrrWtahCCLAPjaBX6I+y8eWwsRAwRARSTe3df+sq3v/A7X/3R T/7sT/7Mz0WnToG4rlU86QvKPGwAx9s6SjjRrIJnb5tTMHZCJr3/i+I49OcRv79fzP6e1w8aUvyJ JuUBb702RieRoIC2erG6+dJL/3i5ujk7mlWLQpVtPavmB7PVxJIWbQldgwNpDMlgLVSHbADGqNfe WQgKa9ApWIAlsAKOASmcTKwQ5648+uFnnv+Vf/c/ofkmmAf1NnhHqQez0BH8rTsv/eP/+e/PD+6y rv7WV268z8KNAAAgAElEQVQ8fL6/vTnise9sq50db5+iglddx2JZ1TWlnFLqjNVaS0qSOKYhqM5u bZ6vK7U/Odg6fYoKfvU71+4fVMsljiZ44YXnvvBH3yCEBgsigIBOIc4B2gLtorz3xmt/8vIrX17M 7sTCelU3xaqYLMu5blYo5yhn6Cr0IxAP57C2cOERKEUAqgqBIk6QZvAEnQIYopgl+cgQdub8pc98 9uc+9wu/lGxsA+JgNt/cOBfACeh6L4k/kaXWznVae+eNEEKI72lg/YFI+ODXX4z8zkkz+XdffHvO XYCn1HtQ6iUlMgJQt3r1nVdffu21P7L2utWTelEvDlfzg7KegbRIHBghnARDEVFkkkjGW2OCQ3mE LPOMImXoxUCEjsEDe8dIBuA5qIf1YTIpXr3zrdf/+Ft3v/H6v/RX/upPfO5nkSfMO0qFA6VwgP3S P/1CXavlrGmOD6sCNOBPvnBvOIR1CMD41LI1WFXIBrAEnGFtMlHXiDlGA1CgaXALO8aBRTi8v+8I WVRhMYFI2GDA/41/8z8gnHYt4hjBw7k1uJdWHb/x+rdfeeXF+Xw3kjYn/Ghnp1zOmoWrZnANhMcA GORwEaiH6cAiJDk4R6fgHZhkWxltWqMMUMJ5wCJJZJ70yvmq6Mzk4Oh4cnDn1u1P/dTPfPj5F85s jB3W9QUS7wre6y3rlD46nDRtlef59vZ2HIu18eJfhPVncb5cO2qvfYffvkIf0A/n/NoySkrxbrUb eBC/PXwAFwDRPpSUdNZNvvGtL169+nUWCt8d7O3c3LlVrqagGtwiJUhJUs/bVKTMka5srfZxLGIZ BUYK1VJOgjFeI43Qz5hq3GSKJAOLAIlFhcoiHwueJPOqmiz86SvjR5566vJjj25futg/tcnTGITc uP7G9PDom1/+46tfvWMbbMU4NcRmjlGEroIN4DG0w7KAo8hyWAvKwejJsYISRBxM4niBZYlHHo+I zL709XltMdhg96fus5/9/P/6v/+fWU9Ulcl7IsAQooHClDe+/c0/unPrdlmW08mkXK7qxep476Be hK5A6JAyxBTEQhCkEbIsOTpqVYfeEHEc1Y2yFlEsrfUePHhirbPW+kAYY0TASV1baA/EyEajR3/o 2c//0i9/5rOfd+CMZ4BQykUiesfGhZ9sUwgIIdAH9V7ehwC/1lKUUpPJZLFYaK2fe+65Dxpv717s 137t1z7QD1j7xp/YxT9YhBClFQDKKKWEccY4A4F3hlAH2JO2RAAEhIAyqE4pXUTSIiy++IX/680b 3whusTzeKw+r/ZvTyb1AFcYxMop6isMdC42U+0HaT0RCPXRru9q0jemMoxSxEIlkMWcRk4ngwx5h 8P0syqKcemPbAO25tcR7yuFcWxTT5WqhdAUY7xvVVoJRp/VqUhTTfaJBAaPQlYgtfAXmkTLIQJkN KUFfxEzbyJHIgCmQDmhBFIjGaCAeffjMSy8tbtxu8xSlhjHhYx97/rd/9/ejTBRlmQ0YIaUlk7LZ +cbXfvuVr/7Orde/uZwc6rospvNysmrmbbPoBjJLCU0RIheEgXRIGY15LGhiui5J+KnNU3GUq0Y5 57OkZ5RhJwK4FxQJD6mkSUTzNGpq4x0GPckpLYtCtZ1T6qEnn4L31WKVZhkCq1eVjKUxnq05y9rJ iBIfvPPOecc5I4SsI5cQotfrnTp16uzZsx8o2N67PnB+4l1YJx29923beu/jWAohokgAcM445yg9 8bOkzAP2gZcCP5k2TQAgSkJEWLna/fY3/+DurVdXs7ur1YFZ+b3XVXUsXOWYgDPMOWcbwELGMJ2r MJUsJSQ4G5rG24B0zCilQkSc0KaulnMdUfSyeD41QigRKR9I7NFW6CrnI5y7QPZXYe+t5vjwLatr waxqx56Src2z28P+R5/9yIXNU91yVsz3jg521OxEE2YO3DECEYImgac2op2nlIJ454y1YZ1WpcBq zyRCpkANFBWeunL213/j773w2X8BFKCdTBqKQoXjr37t944mN+d7dzdAfVUXx4vjo/ndO3o+wVrW MVktCRGWu5YwGwSR1AljqHfUaOYNVktlvVktlZCIJe1as/bhBwcj4BRcaCJAZV8EwKPHRKfM/t5B Mfndg3v3chk//9M/mw/TarqXj09lw1jVZZRl1qpA/INyS0rfUU48EBhjb3sjqk5775M0/qAh9+71 geObcwYgeDRNU9c1AMaIEOsUgGdsfeg+Sad7r71uGSWESVAOyh6USWsEZdX86ktfufrtF4NbtKvV 3s3DdoajaxjI/kaUGt3O77fEYdDHxSsJI2Q2aY6PQhLVeRanfcmkM87GiXDBWePAiQ+07lwHeOZk xo2xzqDXy0cbad02TVOFKKRS+L6WBI3FfGf/JtTGdBz1sm653Ny6dHpr8/zWFnFqMbu7u5eo6VSs aHVYlEvVOce8Cw7EaxcI044xUAaAee7BICQjMi267uVX73hgnPOe4P/qv/ZLL3z20647YnHUNMs0 l0D5u7/9P92++fKlyyO1PCpUsjio9u4e7u9jPkUIGOQYZDi+j34SJCGcCE45p5EzaOqKmkZ7C4qi nhsHTwGGuquEAAioBwJoAAtgDiBwTuUMloA0HQsh8aiP9BvlS79Z/u3nP/osts7kowxUN8U8HWx0 ahnH6XqPnFdr25gQQvCEUkoIe5uu1HU9ny3Ksnzq6Sc/aMi9e33w/PvB2yuljdWEkCgSnFOl2/Uo DwCUgT946J1uGAfoOkcQHLSzXYD+4h/93uxolwZVLY7eePWbs6ODpgj7byJtcCqned632tXLJtgw 7A1Ho5Gzdjo9qpsuydHrR1wEB0MI61qrOgCIk1TK2FliPShlhBDTqU61WRL387QqF0p1g3GqWcsj qZ2YrKpZA5ZifBb5Rh73xmfOPDQaX0jTPImg3bRVOwJWVHL32u6t67vlFNxBeDALHk5iJGEnPuKB g0sQ2Xd0642bO0fWNMAnPnHpF//1X0Im7k/2lVHnL5yuyqm11Tjny8XefHKfduT2S4dq5Vel8R5x CiEQAhjhy4nNBJUhCh3hTkSQtkPRTvgQyQBRBO8AQinlqtVFgY1RBOdhnbf+ZB4QQSBQHnGaGe+K sgsUaV+2xh4tvCK49NjZv/kbv3HpEy+AUjAG0ADqfMBa5yfi3co4TvI+a25OAFjrjVFplnywePvu 9YHHb63XdackimQUrzVsH+AiKR54Ta7/nIMLznIpABt8dTTbv793e3f/1mx60DUrTlxblaFT7aqs 5/VkNzQFooCNHpj1qlgmMh5tbxLIoqju3LobQohiMRj2WBRarXRtiEAiLacgEq1CUTexJzLp1Z1d zldKKUqhWnCietmqayAY8nEQYMVUzVfKAlsbyDalI3p5WJ0SwraF0zViETgh3ERJiCNBsyQcizZB QRF5ZByUwltIBkIJIcEEaA9rAQChEmlfM5NLxAJbF2Rp7y0Pl4889VhVkdn0Jg/oS7HYO5zsHezt 7Ny9jsiCerQKIoJgue700ZFuGptFUNQL0jIL7iEJeKA8wXCLsSRY4+sWhPokpuA8wPpA4GiwnniE AAZCffCA7tDPhaS8Nh1hGEeZT0kwcyfIfH//7/6dX//P/tbfHD78cFs2yXCj7boo7rOTegq7xrR1 3jkfyXVd0DvFjEJQIZI/Y138A8f3Wjl593fy3vvgKA0BjhBHQQLcfDnf3b13fHR07dVXo4jwyHva ulC4UDLaycTyQBj0Gzeu33/rKA4R1XAlzm/xVFvU0BrOdyQiUkaClR6us0iEFnHSaTOdm0aDEkQS ZzaQZwLMriah7Ooe4WXndgplgQjQQI9gYxTTvNMtOljWOV3DNWAx+iLNRVR7vaqxPF4g7GhDO10P WeLlzJDjjvCqSo9sV3GoCIRCAiKAUFjCGOGBeAtrQzAERIJwGJQHClvb+PBH+2cfjkhyzLC6tTNl RMDR6XE92ZmpeVtNSlXhkVPD3XtLJgCgqUGApqOrJRyw0ugBowx5BO+hPKj0cYo4G89XzWRSlyUI QZp2vZTFWdIpF6whLggCyRCJwAlA+KK0dVHHkeinPDirVhUTdByLpTa2wjdffPk//Pf+7ed/8jOn HroybxsX+HCw1ctHGxtbo9Go1xv08n6/P+ZMNm2TJvm7Nj1Y663VafoXKn6HBwT4fRf57jsfXPTA g6hMk0QCAPGAtrYJ0IwHDqzKyZ07N9+8/sbx8SElQQgWQrBKp4zwAGKNQRVcgVAHbignXd0d3D3Q q4p22LmtYoorWwNuPLeVjAMnqGu0bZumbZbTS5flaqXjNNEO81Uz1dAACRAaqHFxaDgXYW4QkKdZ nPNKtQeF6wjagMEI249ueFPde2t1MDNS4fRYXDi3Xbbd4WR2/6DhOWQft94AjyYsngw3k/OXN3qb kPkqybPlvCmXTXAQAtTDB1jPwHlruGQClBAaJNERDzwiNBKK4dJZkAg06HI+876BCMtlUS6ayWEb Q1THZrqDM2Pak/1bry2vXMrjLC0KvSi0h3TKOoARiIB8gNPn4o1hZJpVuYRk6PVQtnoya6YFLBAC ygqKudM9Xq/aNX0SHJyzKBJSMAJh3XK2MMO+G48GuqtnM00kxttRO0cSgQtkkh7fvxuoOX358uH0 eGVWzUocH0jjg3cQQg57/X4+eP6jH5NhwKMUnnhPqYhlJGVEEfR62NC64ehdqKHvU3SO9/rOvQuT 73v9/fH9A0j4dycXPYH3YOv0uYcxmlFOGfUOgYCxtSrqa10KQTkRILFVJpCa8brVx7s7r1279tL+ 3k0pwCicUs18FkeRCW4+m4zyvunCbDIlJPSGqYPVVsmISx6Vs2py7+joHkyJMYXvUJUrQdAFnN2O DxfdeNRL82S5moDy6VQTgumkGW6NKltAhmMNB3zyheiHH79y9WvX66kZjSC8FNY4p33jAlAGXP4Q /tJPPXb+7HD35rXGgtWgCwRrl4tp6zwhkBQ0gOno4e14Uawm+1CHrT28n2QQEfJ+BZa88Z3m9AYu jbN62bAQq4bsHzXW6Zilp7c3YwJdz3pp6DEyma2aCJsZwLC8183uHgQCwsCoXM11sCiDsR36BLHv Uyt6DGZRmWnVWoz6Y5kNqmLeATTg7Bl86tPbD185e+/u3bdegwowCtM5NrZ8a8NiXX4FXLqIx555 2FVqea0MARmXw6w/O5rq2J+7eO6Na/d7wzzL+2nKO1UUSlsJKVEbdfFKsnvUNi10sRoKtiFoff+W q+cdFlEeRWnPE95qUxpTL+hSiJ3XfwvWxDLd3r5w5srjZy48Mj59kceb8BloBBATAiHCrYtDQdm6 VMsF+HAiN+IBk/8e4IZ1o8b35kHXbtTfc/VPw0/W9QbrmUYB3gdKg5AcoF3TxUkMQGtDqGXCZ9J5 FI1uhEvv3b391vVvHx6+WdUHSs28LeBVVZQswCiznCyEiCjIbFbnETF16CpIiTSH8VgbK3gDYrGY op1DAL2IiCy2yhulN7bzeDDodZUBna7qpgu9Id0+nUwnba8nlbHW+jqAAecfxvknzspxdP6JzXbY 1kdteaBp0gTBncU4w6lNPP3c1iOPX+bBaG2KBWgJN8MwDvmA5SzWoVkuTFMiMCUjlaZ8s2dJQE5I ZDlzLlguE342QY+wZtquFkFGqqrD0oGDVq5pjw5j5mSwkrNUEOqRUtiA4OAtnKcuMEASIrbj0WQy aWtPApSFqpdZhoSgFydO6aZylV0K7RiwKTE+jWefHz/25IVBP10u0/HG0sQUOqul4yzuD2pSeQ2c vogPf/L8Iw+dP7y5p8u4uN+tCi1RGKDxYdGoymI1q/iyEhHiCFmP9lNOCDFOt40KDtRjdVS++crL +zu3iIAlLY3tsl7VBp6dQK4Xs3GacK0kJbHIjm7duPqtbzrRE/koTrc+/OQnnv6hj40unCXBeyYJ kQ7EWW9rnfA0kSkY/a4c3/uG2rdv+GdRef6ncPFaPx/rIgLiQMyDd5dcnhQPSSFAFFBW3c7LV7/8 ystfpRb1ctnVS2db55qmWJaLoq2gagQPr8lyGjhrKY9nU0ge4EECZARCYAwiuR6khHEfpoFtwBlI xKMkDUGVrXrtdklFiQDOQRkijqXq+ixyAcNB/3CyWj/Bl07h2Q8/+uEnnoxiPz+c7q+mq2PQBnnM JRV5hHQbG5eGj118tC/G0/vzci+1kzZySAQCQauVY7a1pgtoAe8wa/DQ0A7ypKlaG4KEcR661EGH rTyTMt7bnxUrsMgvO1SAgmNAkIrEoBRN5BBQOwwJhCMWxHmCQBGoDd7BtLarO99ZAGAUIoLmUB0u pxEJ1KGuSs9dZTVSgX5CL55+JCa9atotJ6EuhO+EU7IuW44gCDKBzS08+4mNZ597uJ9Gem5WcSdi mBaGa8VRaNTLyTJAMhhAGzgK6WlMpXWu6QIXvJ96LtC2uH2jsLSQMWQKIjArUFvwBGBwGgl3w7Tq c/Qi5LEErStTtoHGg43eYHbnpTd+P/2tEEVbF85/4lOf/vDzP5JFA3COfobAAAvPTKcdIXEaf+84 xRO8vaeChZyonO+65218/ykXYT4EB4ASGhC01pGkXKBrizjhsMWbN1565eqX9/auG7+UzC6Ojtty VZUr11mt0KxQLaAaMA9nwEjQJVRglIt60VZAnCDLwRhVysOi34/yJK1RxEIig6ad1cF0aIPquq7q oDmmBgLgFmmCUYzDFfaPVT/GtmDWdf0edIuLp0eXT1+MkVXV6t69yVu3kVmMYijTWaL7fTgH17QH 93aLo/liryz22gEdDvOckrrTq8a6zrjGovPogEAwGmD74khSuipb3SGWkBTOwhgzGPUpUphZCKg7 lECaYnsb2TAaDlNJrKtLKLQdSIJgAUOJByGEUwpKfYAL5uhY2wAVYIDtIT70+ADwO2+Wq2Ypg+Ac MkISR1za1mqiyK1r947uR0q1uzvH00N4a4K2qrXEs8b6LMJjj/R/+PFHE+LmR7uuKxZTRBKDU/CW qsrPWhgFE8AdMo5YogHM0hZNJTgQkAakcZ7nrFLlvPTKIgZSjvsH0A4hQCkEAgJAwFnQGG1JWtt0 ulo1UIDM5/1hNurHJk0go6OdN7/8h7/refzccz/yUz/zuU+88GloWE95lIosFYQaoG6afpp+d3Pt 9+HS3yeQ/ynxTTzQEgIgCl4EAiEj51utZ8ocv3z1T17/zovF7IAFHzrdLOtZuSSqmU/nk31UK0BD BMQSPYkANBpxmomUVLVRnXaABaoWPEXOOZSGhUCWs36gRDgaSwkRmqbRWretqltbOWiJDvAMHWAC 8giRhC2hA1rbUYZ+zhW1zIXpzvTgYHF3cvDWm7rpkCbwFJVRzINGKFboglqtdogFGiQBwyjuCVp2 TkRZLwO17ayzlUcgyIf4sb/00NbW5uTgcGdn5gMigZSDazBDSQdHDPGcwy4BClx6avhTf/nHrWha NW+XC1Wk7XRZHStCYSdgynsXCBc8YkTQAO8QBEen4YBeD5ceix975kNd17TNjaP72EgNk8gkGY+H oGTVLInwt18/zAdgnLYraAWrAU+BdD7TTAgRGarF8c5i9+68qxZdYUyFQR+SpbNSl9ovgZVHDHDA eTiCRIAAjUfmkMZ8sTC9XsjzPBepHDSO+CgFjwf3766MJrUNDuj3cWoLOSdBhYQMTGd0bbz10oEQ 0AY21HVT3znGssXWOZy+MDJWv/rlP7xz9ZX/kf43P/1zn//8L/wV3ssAUzYdSZM4jcN7xrx8t6PR e5umvyu6/3Pj+0RF8dYqzgUClFJxFIH46WLn5at/cOfOV3V7H2aV8FBNu/3bs/mRItrfutESB0mQ xsgFYgbBSMRiJqPDapkyHqdctc2y9RZgwNkzuHCRbw425gez2b429bJUppyVERU0y5M0T+MMnpRa KwMLHGgMR/jQIyPOm8VCZRnODMbtpC6O1bJeRSmiGHGH6dHyaPqdSeUOanQBEjA18i1cPBNZrY5n SBJEEtRCt4g9sgjULefTuSEs6mUyiWtvtLUMuPgInnrm8seef9ZbUy8nUgAxYoaIMsadoNJ0rfGW eRZgHZD2ceGhM+ce3Wz9fLEq8lEv8ePl/fyt5lZ5DOZBNZwHIU6EiIL6EIx3vQytw8YGnv34hSd+ 6HGRkHs7d0WCpQc4SIBTwbpG0IgjBO84QB244JEwlIZOw4eOIXbQqeGdxfVrszt7szhFP0E1x0YO CTSFOTq2tYMBDHDm9NbTT/Xa4j6cHeY9GXg9L9qlsc6pDixYr1aMg/FAObTC0q2MQutCAE6P8OTT m6c2hqvZ/PD2vDMtNSLivVEmWew9VZ61lJnJUTg9wCCFVehmCxFJGKxWddP6f7R/8OKXvviJH//M T3zu89uXL2uEVbsYJ6PvISTfpzXo/ZvCvj++3+sqTShAGU0RKAKPI+JDO5/ffe3aP33r5hesvluv dpfH02YGPUc9QTORunabAoFBEiRUxl5SRxmljFERcdsgpHWcp1x4UKTA8DQ+/bkzZ86Oc57eesO9 ZY/R+IjWSKBKo1Gy4FkUAzDGaYcA9CU+9eMff+bj54WoX3vtG6puLm6eue/261LN5jh/BpQHHmF6 jLlyK6BZfzmG8SYe/0j0yOVzx4eT+lrZtcjTlPgodEtGQhKDWq8rMOZ04zvfdLbjFBsbuHx564nH H7WmXS2WxXzG1rkbA9M414EzZbpAZV9KwbTiHjyCJ/re7g2Wd97XScT6vNdKEQy8gZQMGkQ7QgIh IcAHr5313iGPcfFc8uiHHhoPhkfTg+P9o9kU4BApgoKqsFwtpRTOGSFJPwXhJFjjfLAOJsADXJiM Jko3KoB6uBoEIBy6QH/ATU1U5YNb+2T4TOQf/9RzP/qp7f29q6ZWG/nI1ubN79wsF0ujwnjMYYhX xrWQEYSEsSibk+GGZ0d44ZNXfujDV2xXv6nnZYbprk65ySX3zrTFoum8ARjH2W1EEV9WdrJAN4OP NGXg3PWy3mRy8LXbe2+8+sqNG6//7C/+4tMff36c9AksBffvgmx4B5FvX/2+7ovfB9/vU5YOwCNQ EmLTdEJ2kMaqw1df/SdvvfknNEwWx7u2Xa4OsXsd1T6SgIyTnGa9HgvOwDEeOHXCa+sBIxCCK1vI zkZ9u2aTeY4LV3DmdDbaJMxoEhaqAVr0E59HyECN9lo1LDhlTddBAxYgFMOh6PchE5IPSRLLSw+d VUV3fLAoGvCEA4iSdZIOCbACts/hyYfxkR+68PSjZ71W83rW28C9VxACFUGuFjSmbmMgsqEBQVWw pu1UZ0mE0QBewrTd3t0dLmgxnx3trGyNlMF66ArWwMtgLPo9ZEJITWXn4bGYH1UrMYg4o9a3uujC 6mCOhowzIUCstYTA0wBmAojzxhsEjX6OlEaT+0ezybRqi+J4Vc7BLDxLhGQelTagzEsR5VlcNyvT BgMoDUoRx0gyMhwOhWC37jWM4+GnMi6ca7ucU5/70DnfhpjwQQIghBaDoX/+hcdk/1DWLu2JrXFe TtpAlQ6QHJtbY1f5pqyC0Xka9XvC+SZObbuCUtg+jYce2trelPd3DijVp07n+3erPCZRnnIWujI4 j1gi7wEe+/ftosJwhHMXN6y1e/dXy9Ll2XKUS9nze/fn/+S3/o9VMaXEfvTHPrMus6PEP7BqoeRd 8okHpe+4Lfj3Hj3fD9/vSjW+89AER9Ym7B6CxxClbe9+4cv/27VrX+maSb2a79+Z33kNowh9Dy4h PFynZGr7ea+qusXCnjt1hnu5O51JKaGD0s3GBhERn86bVmEwwKlzW6dP5YLzplxMdhd7O6aXYWOE UOPoAMH48YiJJDYBnvEkVU2NiCHOcPPGN8H6/THZ2og2hhdVuQJz2YD3N+zdfTvsgVA4ghbY2GBP P5ddfnLwoYvjYc4atdo/OD5YVCqkEF3dDH3Hjd5iUbt7XEUCmUAc9YdSqKBaXwM2AMe75d696xTg gAgYxIgdhAEVIBzzCheu0PmyaAxNUjaQ/uzDG9sbvc18kIjAIJfT6eFbx4udihXUlMbYQBlICgLo oIMHY8gzyAhpT7Sr5qUXr2mLKAbj2IhBGVssqe1000FyyCjR2t3dXdUNRAyRYHwq7o24siHtj1pd 5iP7+CkSpeJDD509f/rU4b37175+t6lw7yA8/WjWNrZobCJD2sGa5sVv/NaHnuwFXo/7IydaR0qR hSSHr7BcLqimsPAe9bLtqlYIIMLWNiOdO3UmiRI7Od6dzw6UqpdFOHuR2S5WwS2LSnB26oxXyjsP 44TxhhI4j6ZykrNxL45pRzxme3owxo88de7Wwf7/87/8YTE5oFp/5DM/740hTBDGAO6ddQFC8H9O 2e/78hPv7bsKHfFgZMe67dvbev/lV//o8P536vne7Hhfl3Z+F76Al8xYnnOWRbywRdO6nftLAtQd 5qtpIvpxP8+yrLONoJyKYJjj1qfMERE5xaaHlXircH65PHCLI9AaWYooYNhDsQCCb5uqUoHE6A8k SXShYAhSZnqRHKRcCEq9b5q6KOc3b9qY49I5isC6DnluOI8++sIzlz4RpZuKBjObr+pld3+ve+uu mx005RKd1F47h66zVrYOHjGDcIvxQObDTHhWtVbVoBGiGMSDAXGACOABNJz0a8U9tNY3BixCxnlR mHqxWE2sXg6CchEHq7kvUN73zRF4QDI4aYx59yGJEnCgW5lOwzkkMVIIp5xq/bx1lBrvvVagQKMq BCiLJIEBmhrmqNMBlIMm0pGudWq0zc5dOH3+/DYPtOu6ENDLQDxMo5vCBAMRoZ9CDiF5m+UjlvRT GXddM11Ml0XXKRADLywJ6wYUiuDhETy8g2AAQblqb924pdVqMUPXoi7gtHPG9DLO4swaV3aWAhsj cXxoKYn6A8YEPThcNjVGPZw/Pbador52Fu1sMuD08obbf+O13/gv/4tf8cnTH3tBDoYIvm1KQnmc ZrK8lskAACAASURBVFXTpmnywOPufTqZ/9n4flBX+I4TWoAPoaXcwsxeffUPv/PSV6rVZH5/uXPd MgOyQu6pmpGuUlvjKM4Tk8EDbYs4QgA6a5SvA6FK2WVVMg4RgzDYAErBwFSrqkqVi6ZTMDWoRkZg gYhn/VwI0jHBVVO1HQRDf8CJDJ0zly9HF89uX9o+lQy4dnXXuMV0fnxcCIFegpgnBwe1dUgkB+jG KOsJhE4f7lVv3Tg83GuWkzCbQDWIaKyD7bDSUBoQHgRQDgzwlW6pBkWn4DwSjgggYe2dBQEwcrIc c3GKykA5DCLK4ihrW1P7+nj1xjeuB6iYU+5Ycd8s9hEbDDfihnSOYe0fdTIXk4AG9JJIayvgKOVM cG/Q1ka1aB3sidsQAkAMGECBaXvSSaMAG9b+b4uqQ9wH5W5723W1MU23mDRtichjkPG2Ck5j0EPo Q1LwTQgC3fosjoJlxaKazRbWIs8hY5giAI4QQgkBIQHBB3gPax0s6iXu6VVVwGgwgbZBp9F1urV1 sMZpJSkSiX4vscF0NnBGezJJGNGuNBZlUzNrexnvOlvPNEtxYSSO5+ZrX7n5X/9Xv/rX/8bfefqT Pwpw6k2UZkbpNIrxbp6x7kY/ydvTd7Nr9mu/+mvfC20CwBNCCAk4cT4DWdsmkcaqu1ev/n+vfOvL y8lRs2h2r+8d3Qq0xVCMBtEQyqtOc+pa29YduEQkwdiaKpHWhlWjj1d6anCsEAJEBOtgNDg1ggjq qW2JKZ3wGGVpT6RBU6cDpzKKImW19g40UA4Rc8KIsXY4TKI4olyUVXd4MD3cn+7cme3cxpkxOAEM 2d91vRSb4/H0qPB+ce/e9eWsON7tbl4r7tzA0QKdAQOaYLVvA5wgSHsQCSyBI+AMhcW0g+6Q5cgz xAI0gAcIQIAwIiihICwAjngk6CwCIGMS8ZhQDzg4HO+71QzNKpjK2xLMYhDx3qDX+tYRrM8H67Pa OlPttOOM9bJBlqROu8WiLVuoAFBhgtdwFDgxsoogM+Q5uISycAQ2gElECZoa/QTEoliUk4PZ8f58 elCZAjHhwkVt7YSIRxsbIo2C9CxmKgRHqFZYTevbN3bvXm+Xx7A1TI0TSyHC6BrjPBACx2A5QkAm QANcA8mRSK6Mr1vMFIpW1cpIhqwHa9E1atDfcBatapXpCCdxwgBX187a0O+JSLC6crpDFpNeLhLh rt+ZHBzv//znPgfveJIDoOCUUvL2BK+16L4GKSHvye+8X9YHWE9/DAHBe8/e4fTqjTe/cPU7f3h0 NDVLf++1o8MbPumQykhQN+gHMQxSoG6xcwQHnLLoJShWAIFIhQVdda4EBEEqcfFhbG3yxcTO9xEM 0qiTcoDQb4kRBGkSeaWKrvbaOmul5Mui5TEGg7S1uq0Vi2QSsf371WxZ7x+UjtpKNYTCGXCPtkBC IWU8jvV2Ohpn+URMy73VQYGtcyVlPayixFkN54FE4qEL+Zlzvc3taDTOB4OBtm4yLXRT37l+r5jC K5zawplxBuvLedsWyCIQQiihAHEASHDwDqCeEuazlFjtal3FUnjv69IKQArEPBKB8gRUgLR2tpqR GMydRGO6xjcFAao6MGacrRhjdas6jbXn4sobAmxvk4sPXbh45dzG6a3esJem8bVrr8/m09tv3awr SI6tTWxtDpeTpegSb8LqoFvojlJ4hSQg6Q+baWM0jZMshKQszNy6rnTdRN/ZbfJhTJxdTayrME7R 70MYamtPGCWEEkYIfAjEkeAJsigCdEZjFhglXSQyTyXczHuvAQb0+3j80TPntsc7N988uGdGmR7m sVmWd+feze2ZMbZGlAYfFDqrOIiMAQXbuVTGF7aHBZ3/yRe/+Hd//W/8R3/9V9FWSHvkgQBOAzx5 pw/9nRc/iJ+853BJHkxrVFotV/dfvvq1g4M7TRGO7yxuXJ2jwuXNPAZMUViqtFbOoWrQAWc3cPHi UNjQlCtPwJjwwStAA1vbePqZ3hOPnU8Frr1ybXUEasC0IabrVAtHHEKnW2ta5ywYAjWdM63GsEfS Xl5NFrOFF1FHBFYaZhHIYWEAbdEbYNBHnqA+xmjMUpYNmK6Pl0zXF8ZgEZiHK1E0pVXoxVHGZdxn 41PxI49vjbdklDnKA48ar32PkeDSM5ceN22bi3SYjW2p7ly/N5+2dl1NCwTCQEgg3lLviLcOMYnh jUySelm0rcnzYLVtKkDAKJQL5T2yGMNUcBm0R+QJdQg+UI8H3pgghGxv97qua1pjgwkM+QhCoTJ4 6gqNR9FoezTczuJeV4e7x0ddq1Xez7f6cbZ1KRWil4o8Fla3N682t77aDuOkH2e9NFjo2ljboWmX IEhySSRd1uX+cjY1UBIdQdUhTTsWECzGGbJxPEh7TId5PfOgnBMKAkIB5xwCAQeYDk4Z62xXWh9r L11beWVAgK0tPPnk1seefXKYxKo+WB7Op0eL4UCuJ33mDOcv5RvjfrVczI/aWQHmQhphmHFCWNeo pjbdyo6H8m//rd985oef/fS//MsIIaiGRPn3KiXf57z5g/g3IYSAEEKBUDf1rdtv3b71rclBtTju dt/cm98JEcdgjJjW3IMQOK1UjVZDWZwd4/lPPnnm1On68LAuirILOijnbZSAMZy7Ev/ws0+e3u7V i6mxoA4JA9NctVVRI80hIziHAGR9cA4EaAuRIs4TQnndmjbAdmg7KKAB3AO50BjEDEKAU1DP9UrH QSzLrjP60kNYNTjXw7xB59GLQTMVYgxP0cuPDC5cjpKUtqZd1SvTEkdo4FHaTy9dOBusSWlCDdu7 sbdq5toizh604RDvKfHEG+8shQvIRF6Vq0QwQrgzVrW2bmAMag0NAIgYKAe3JokQ9Sgqwiz33oZ1 AQoFCYSwEAlJGHW0scowQWQSc2usspvn/NYFtn0uZqlVmFdGhbY2aJaGnd46ffFcb2PQj6g3VbF/ f3d6rNsVem3LR1IKRmNGva0tWm2pRzbwhLHlqlzbfLYKCiAepuIKlgKtxZx1He1sg15CKUIgCCSA BB+CJfAeulWuA6GWe9kZOGIpJ7GEJOgRXH4Uzzx37uz5aHF0qOx8vIFiD6bVxOFcD1ee6D/5zJNd 11xfTeYlUolYwASwgEjE1JuuaigQMxoBf+0//pVvfPYvw3RkuPHONNHvcc55b32spyeh/uSOE7pC HxjlOUB7367m927f+OrVl78y6svySN14KUQGzz2SxobM7tecIJKIUpbCuQh5hLOXswsPXeIelUMw wXZolHUMG31kQ/L0ww9t9AbckmrW1DNQi34fcYibsuIR+huinydKtc4aKWlwvmqwHmpKGdPOagsG CEEqE7gEX1svEDigN8ZgG0MZ7067plSmw+nxZiS8lI1IcPdaGI7AOM6cZtEoaak6Kox13vqV95mU eZz2klyCMEcALpJ0UKzauux8NzeV3r95f+/IUY/NEW+XlgQSCKHhZHawI3CAkKFrlIkjzmLOKufR GViAExCO4SbOntuSnK2W86bSPvg4cOIDcX59ovcehITgyc3bs/4QPJaEwdrAnOOcJ9SulhidbRl3 jBPO/XiUbsqBBUIgWZx1q+7o6KBZrWyrmmVXV3jyscwWcloulg3yIYRAP4ekuHcHed8T0rQWjoEE +AAXIAACG1EkEqMRNjZ6KWVeq2reUuIdPKUE8DbABbgAokCBNM0S2WO0AWdRP5aOkrLSHFfObF45 e0oEd7C7s1xg2Eca4DSIQppiPBwlUaxVy0B0g8unMEx6RwflYmL7wzLLeqNeev6h8c50tp1jetT+ W7/8C//gd34P8KAceEBO3k093kuzbVAA2LpZ/V1pIOfBhLd+wWkHFH//N/7zRGji7O039l558er8 Pi5tYSNii33XVRj1wSLMK2gKnoOlPOqnIEQXdVZTtDbNM56IeTnvLPqbfDTunz9/WnfNYrac7C+L KVwHYuGBVpDAMR6kEQtGNf1U3L1pNjeRZ2Jn1zzyxCn//zP2ZjGXpvl90O9Z3/Xs51vrq+qqrqru nurume6e8cx4Jl7B4yR2ErxFNlhxuAiBi0RIucGAUARCKAghbpCCkBAXsYKCWBJMRCRsK2Pk2GN7 erbeqqtr/9azv/uzc3G+qu7pGRvey+9cnPd73//5P//ltzD53btPVh0aII/AcpAEqw69CW5/Bi/d ikfJ7uph/eEfLkQdp24Yc6HMsupqlqM3wvwMk93JuitntSY5Wg9LcXgFIBAMN14cjsZ52ZR5P4t7 ydlp05Xj5VzV1er8fEE0Rhkii56Iq/OOOVCHELb7XHgGUDgDb5AIkaWjVtnT2XJhYIGO4K0v4/U3 j7yjx/fm508a10hpeeKNIIEEGGO1hvcQAiKiReFH4wiCnc+bvEeHw+GmrFhMXKqcACR6e5gcDRCD xbQ/Hq3XG9VYWwdVmvVZW84gAwZxgpKvZ2XXIoowGUWT0dC03dOnmyjCeKd//1GxbOEkNgrJACxC FMMH9Ps4PIy+/MUvsED+4Pf+H1OjmoEZ9FP00vjuve7116eLdZkkSVOVXed2RzvOkpOTC0Iw3dvO 3WNI2x/Eo/HAOTc7m12cK9uAOkynE8KZ8soTv1qXRmF3jNU5IoKIglMQAsK24odUwV8U4D360bkn ffLPfvfr1155Azz2hD/P358QHvnB/A1HQXAp5k6ft5uMbX8hAVCP7/9JLGrqVuW81Ks2dnwobAxQ 61lAxMAYqgZMoNcXnvNN066bQkTgCr5E7FD5Ui2hHQZjRC4sj5cffGt588V02B8LoqxphcB4dyyy fkmjk4vzJ/N10OgnmEzS4XQz3el1nXEw66KC5EkGmmAicOMzey9+ZjcZu9Kfk7hlieOUU6N5CiZg vWlUCZ8ERmgCRRBaOKBqQq1Z08F5tBbKwDQYDWE0iFovevViaVi0yXpYrjC7mC2X1gVYg2EfqYSq oV0XB8K9IA4ECEF7cgkDmkywXqGtjLMFF9lglEI3FfCZl/G5H5nefml/drp++H5TrsGNyeMcUNsG dZt+tnxFQsjB4cBa6wKJBbrGn9bLVQUmsfKI+iAS/ALp4w2R8AQiXrUd8hReY3aGYg7qETOchvbl 6xPWI4kIDGgrNTdr5qmgkEIIkSVZEQV4icEOXn3j5rWbe4GuXGiSLBORHPbF/HTRGtQFJiOoDZwH 5zxJcHy6mK8DY2o45KdznFzMRgM63p8O+3lVFU+PbbqquEDZ74re2nm0DQTFcNLfrLuTs8WmQb+P yd4ojXirLSzJRRBb+sjWxeWyX/SqwK1reQtx98lqNQ+/8eu/9jt/8KeUi8vS+jmikFxaSnzKT+LP w1cp3UoJwH/7m29HUVTMm4uzi4uTymubSvBAXBeYB2eQBBGF40SSWHkPDeJBABYwGuURqDZNubKg SBPhvT85BoBvf6dBaPIcvZ5E4Mfz1erJsibotogOB19jWRWthaNexKLX63ywuukiySQLFmFntHvl 4GY85i09orHVoV4vV23t66Z0BNo7pesAHXEKCufR1GCkr9vYaqiqXXkEIN427BUtFp53UDk9P0dn EaXYNNCwsxoAIoK9HeRpv2tL2wZGYuI594wEBDAP74MONIggE649ges08UxGrJ+AAS9d39sdHjCX 6mplKgQF7gKNLLbs8kADLj0yt/NlSrAp6iSLBoO0qJuqggWcw8JhnyOW6ErYGlEE4qE8uhYug7FY zFB6ECCLkEsQFijC1oRFtVC16sXIE9l0WncmSaLd2Mk8zXdG1194+eq1Xe3OLNqsl1vtqk21XlSS wFEQC9tCG0wHYjxOj2dN1aED7tc2BXoClfXl6XxerrOIXr0urdOcgXM0LaoCWmHQRzRIp9P0+Ows 1HAEWndNY60DJTxOLCeUB0JCsN4HH4JHANoWgjJH+MEUWcC3vvP07Pjk8HafBu+fQQX9D6Tt/x/x HUARCHy1ns3OLzKJ5XyzXqzPnhph0KMIGlqBeHAGAtnvpcuqWi9LT8EJsoRzAdPadBB7rShofwhK IYTojGYMn7kzvZivLmZu02LT6QCtLTqPNaCAxCFjGA/R3xlvisXFqs5ino8YZ3KzUDKhgZDlwp88 Pumc0sKXrsrGicx5Uxam7FZPN9CgFFTAeuMNPIUj8A4Rl7ozSrWdhwHGMV68tT8eDVXVkOZxj+aT ZEJ6q7rtAqGadIRdwhomOzg6muyNRgtrtW2gPSN+62sQAvHuUhhgca6TBKNB1ja+7jpnA4mRJmjW 9v47J/fZ0/VsrUsMYsSeca9B8Gw79Dy4QQip67ptMR5LmSZV2/gABlhgZ4obr+4M4tHs6YUtbC6y mMRwpPZtUZS6ayKPFrBAPsXt6/sJ8eUMXY1UgBOAgTMqheg6vV4uW+tpKhmNvCEf3r3/0aMPexPn 0KZp7oxdz1btpqYaMYGuECxUA21YlI4703iB1iCNkKZYbxBqBGDMbdmhl2F/N6OwBN60hlHQAGfQ 1IpIGqfRiCtCsF63bYU0gZCJ95qChIDgvPPOOWdDADDsY73cOJnsjnvVrBTAf/mf/xf/9X/7D2kq KfmzcVXP4/uZDhr9ZHECAue0kAxwH7z/LiOoivr86Wm5MtUaIwEaw9tAzVbWg8NHlMReV9qAcAgB YRGMb0vcW82VQp5jOgaltKoawsTuDruYb5J8shfh8fHFRXHZyZbAsC9fPNp76eZRHgd0ZS7x6Mmi 6NC0dncqOWddCyF8msTEuGK2mq2byrvzQvMMPENwkAR6id0IPY4ohdfoFDwFEZQzEcW+aVedCgy4 0sOrnzt4+ZXbWZK++63vnHp0RWUk5dakgZAg29CtajDg6hFevTN+6eZVau3qtOksEqbgFWWUegT4 rd8HCagaJBJS8iCt1ggInEWM09OHG0utcwgGwiITkJYGZz2BB6WXY0EAoGSrJ0KzDEkSKafLErWG AzzHZ7+Y33j1IDYp6VbLTUXKQLxjgWcmBO2VQQkkBMNruP3G7p3b1+nZpp5dNAsEhiwBD6DOd2U9 HgwX643RaDo9L2ckmrUeyuPKi5d3wgNUAaKQE/ga/QhJylfadq3X3JYGCiiBO5+9ffXqUVe3m/Xq 7nsfNAGmBYnx3oOaBSQMaYyYQfYY9XFb65OntQUoA2NgBP0+0lgo5YInPmz13WAtcRbOgwBpjraD Vq0cDnSFscD//j//k//mv/8ftmg/+ucm7+/P398/XqEiAMbo8v69e/BhcTZfnGlbIubgBPAInoJy wognUntqlaUyHmSUMKiuUa01Gk2NFRABOYUDqtprhSwzcZYv5tXDk4vGogtYARrYHfR+9NU7r37h c3sH44PdnimXq/NHvt3w3juVgiPwLHDJCEHwiBhNJRhIV2rPIl3pVQEDCIn9CaSAc+AxJIcy8Fuv NBIxypIkNCqQFuMUd94av/UjrwwGPd00aawEhalRbwrTQXDEUmYcOUG/j7e+sPvmm69Phr2Thw+N Q6cQMoSArV0ZeeYmFoBeDqNR6oIynqZxzLljxJCwWbUQYBwcIA7BI3jDyLYooYFuZ7EAQCkIpVu0 T921repcQCQQp5i8KN784u3+btZeqCzVBbWqsLqtBSAY2532ue3KBdIx3vrS6NUvvTTOh5XDqJ8U UcsYIgHmqdG+rjAe8ziOs3G6apqni7ap0XgQgUePkKS4pL0JSI+EwxGkNPecCFopHRblpgUqYDBO vvYLvzwY9duqjjh79NG94Lp3vvPHF8ePwaArlC0owWAYxyLXlV9X61UHDaQEwwGGAzYejI3SZ8eb fi4IYSRQOOIdgg/BE0KCs+AETYecsJdv7DxdlWdl9/6ffvOVL37p/wt78n3x/WnZZgIP2OOnj5ar C71aLOcLp+AV+hmYgbEggRJIT6izQQfDCbWECM6YoNQwWEs8AjDluH4T+3uHy/lqvmg5A6FyvWnT /nDRrNcWGogkf/mVz/zKr/36L/7qL0+vHTx99P673/3Gw8VTZNHB4fWD6zsP9Yy0aK1JYp/3IBiC txFBzqNF17GIMgt4xDGmE1w7zLjWem7Etm12iChElAQaaVvVbZXkGATQGMMJwNbL9blu6jgqRwOE CL0ESiCOSJ4J0lDvvRzh2u6kH8u2LObnF12HtIcAeArHL2Ga3l/Oy2LJNqXzNiSZi2Kqg6ta27Wu aEAkYikSSQOxgAuABTwNlAaE8Jwzvq1XvPddB7OumcBwRFob4kzcuHU9kmazerg62xhb9odQCp4i JtDW9UeeEb50lk2wM6WRrIpVNT/fdK2hW5VuhZSRREYkU3VdG6XHuztOgBctNALAJaTEYIDlOYJB km07K8kTIgmvGmNt4KCrutv6obzy5lt7N26+9sbrR/sHnNF/+r/8E1Wt++Ne0OX5k4/OHj08ebiG QgChRHqnu84nAqM+XrzWnwzH5aquilp11jg02hFKGEHYal5RykApsUkiXXDKORZ8P8pCM3MdfvPv /b3/7etf33o8fmL//kOCnT8L7k98RABYwLbd+uT0oTPdarHUtYopWkAmUA5aIcB7SnwgyurO6Dgm VVsTjSiCCIQLBAfS4uAK3vj8mzvj6Tf+6JvWtcMRT7LB7GR2cb7e2i9k/fyv/41/++/+B7852D8o q7WDP7rx4tGNg3e+Of3un359uZ51xE8O5JMPtV0hlV2WUR4IcZ4DuYyFbVXojAcFdoa4cbV3uDdq F6u6MMzBKwQDKWgep8r7urXnNfauIk7QOMyXK3PXWNUkQjx9qlcb5AzOwSjQEBpSNRtPBWyJ+dON ax9tNqsnT06bCnsjmOIS/uE9CIHd+m0HNNppC0JAONPBrYpm0UAHNA62RszMqA/RE7GkRBujAHbp ZeyBQLBdFgeCvN9b1StlkKciSpLlRbGZm6OqVR9cLIvN6gRcYSQQTeBjJDI+PekqU3XUMYngcPZo UbWNqd36ni5mMAYgUBYypoO8NxgML+bLzcaJfL7qmk0LcwkTxZ1XRuPJ4AP7sCvAPGwLBU0Dz4ZJ WagQQCOhbLAMxuHo1s07X/j8wdE1GUeA7013hzujNI/q9UUU867rTp6uNysItDRPrA+BgFBcvRb/ xE/+WBblX/+/f//RoyaSGI2zom4IPOWEUoAEFigLgQCd1QBGoyxQdn4+y0S0k+Nbf/THCM/Fz+gP y9CXF/tP/v5/TLb2es/X92QrslVJ4X/7n/3jYOrZ00enDx/XC0xy+vRxyDM6Hk9k1Curbl1X685W LjypjSPwAsqBMKRZlESRFObV11/sdLdcrTplnO/K2p0tmqLBOkB5WEr+/j/4r37x3/z16QsveEAk ca0V58wHrU39zjvffvjg7v7u9FtvP2wKXNkHBWGBMND5ue0aDPrU6NB0VnuMB3j9rfSLX/zM/qQf ETx+fxUDOU8lqGpsVbWUmuGwn+bZYtNxGdXaFTWq2pyf+bKwLGCQo59xwaNICOdYWTvtguSceLY8 b06erNcrixAzkGJjvcbOZG8+q3v9yWKtqMiH06NN3TFB+sNYWdN5r7wpOqiAJqAJcACVCBQUvteX SYRGeSaw9UDwDsGDUFDGGOMPnpQ3Xzp0zK0btWnUtVtXgnBnF4uuNl0RuNtWGsx46ShXgebTfkhi EidJj1NmV8tw9sSuzhx13Gi/u9P3RjEgTZLZ2UYbvVybJAeY0yE0Gtrj8Aivf3bnK1/5EW+0bjbN xpoSOUdM4bRfzqvDKwetcx3IRdOuPW597uZXfvonv/rT/xqRklEB0JsvvXxweHh45eCFG1fPL06z LBOCtvX8+CS8cHUSR3Gtyt0X5GDYM8o8uHt/cbbcmeR5L39yutEOJ6Wvale0rqi3A5QgJGREAGw2 Zrluu9Zmvfx8WQeOX/nlX8l3dkCoQ9iefOTP5s//gE0wHKN+szkTPNjgGAIMeICg0fXrpNro84tl VXoCrDUqXK5alACVGPUwTCPmRLduO4V79+7v7Y8Xq6IsLBeis37TwFEIioXHv/e3/91f/Y2/iSgG gaOo2k6IyMNTEkVZX8QxS5Isi3aOYtt0nYMzJiUkkWkvM4KCE5px1nJzrY8XP5e/8eXXJjvDp4+P l4sLGiAZF4it7RggJAh1VVWtatZYaWhaK0e851GvM6VWvt0gociETQWXLKGxSGIuA5GSd9at22o5 L2qrCEfEwQEaScg06vdYnAbRNCaw1nXaxwljER9N+/NVsWlRdFgGOCDJQAUoA2EICWrTKYdA0SpQ 4rcANsLAKaSUXEY7+6Fs2rN5s53ziHVRNB1A64eeAoyBMc8YYcxTSinF5mxBGCglLoRLtz5KKIXr J8u65KyVUZTmcR5nqtVpmo2nstbtqiuVRZxidw9vfflzb37hDTjTrpcJE3nUsQBGQAAREavDslxx KVbFqvFQwGAyvH7rxTTpBVCH7TCDRNkgjgTc+NrNV85PTgc7O55Tkfrz9bmpHIvJbK5AbUSialGe nTbBNzyGtlh5eMAAnEJy0ARRirIGSGAEcUpSEi3WnQhBEiiHf/F//fPfePmW3fLtnl8/EOKcfOqz j+sT9+G9dxFM15aqbuo1aAubhFikG6sBWrSeC2yA8Qg7fbz5o688ePzB7CIYjjoo0ioG5AN+cmIH /e70qdUW+1djFUwdEDxWAT/90z/1t/7O30GWgZDtJolyvjWbpOD93ijOByKK037/6vUbxfl7SsF0 kFEgnCUZl9QyBE5tsCAeMQcNdrk4f3T/wYOPKmuAiDtHdKtBkGaxQbdYu1rxKshq5TbalkC/2DgD a5EyRFtKDukYOoTLeoN6eKADHAGNSWCk6HyjMIx0nF9oXZMudK61BqRljpjOeDRdrz/pNMoaliAA h1fpz/3iXyEyVOXKNIWwbnVyvDxeyQxdiedj7608mEOgCAH85Hx1XoJQVB7zR6UOyGOwGiyQQIKj cNQ56rZImG1MExeCu8TZCgRK8PikbAIIMSKgYyraiaM04ZE8n89aE2oPy5GmyDJpvVuvV/ViG8vO hQAAIABJREFUefzgUTEvYwqZAgokIIoTa1TVNvFwpzgP22HXS5955c0vbM0YaMDWfpwLQiEoBHv5 tTe+/a1vjjnLx0Pr5qvClBtcvyFd5c7PXXFxTBS8BWfQGo1HC/zI53euXL/SqM29dx90Ja7tQdco 51sQYhpHvXVxRoCYo7L4x7/1j37j3/+7xiguedgqU7jww/Cxnwpu4FlZY+999L51qtysNsvVZoU8 wNT2YrkgFPv7V8vqSWdhgDtv3njrq6/lU5Hu2uX8vBdlrghP3jvfLKBhsxjBAR5JCsalCXBAGzAc 9n7h13517/btti4953GWASERnABKeyF5EuX9/pDLyLqQ9XtJn1bnngGUU6WU1XbrZJSkMtN2qXH3 bjVv/4TFZH0RigLjFHHaox018IRASKlNt+5QQi2gnEZCpfZ62QKABGqH7nKF+/FSjAIxBYDGow7Q bWBtEAycIx0h8E4TlE1F2HYF2aRJEBzrDRivtIYFmEAu8Nobd268fMBTVGVM9EQG8iE1m/mKBxob v+UVWgvnYDWcV50Lq1LNSnTPKAu1gQGaCrsihSUGVjutXNCAAjyQpQgOASABDBAAReSZ3VjXS7B/ c9TMV6tz5M2K6dC2datDYOjllPdjH1FD/L37j0+eHvuyXJ1Zp7AzQSp4o6x1IIxr35pATKc6f6ma 9sabb109fMEjBDgCTomggAuBkkC8GFx54frtV44ffrB7/ZBFuHg6Jy0s08MxrddelYiAUUZA2aq2 HuDA9ZdvXLt9xGN/+EJumtWVyeS9b79bt0ZXcAiUkmBBvJOCUBu++a13AVBKA7wLISbiz9Uf/PQV ALdZL0gw2rSq7SjQSxGzuC2qNEVChKREkcCA/jjeuzqyoti5kk32r4zSUXXcbE6WzYURAbt92hZN LJEOkrLVZQcIWIu/9iu/9Nrn3wBF0s+s88Z0QnAPTgHqtnq7fDyexlG6LtYuhCjLNqSUAkzKctWp EsMU1lowMt2JobvTFU7WkHlIBSiDTHtMRt4axz0h0PCtQwtEMZFdGO9PfvJrX5sX66Kp21ZFXFyc nsEaZ5RRyhhjnLbB+2AdwcHBcOfKEYsTFQKhLo5oJpEx5ZvNyUdP6gXyFKpCzI2UpJ+Jcm1MqxKJ 1KEy8AR5T6zrs4QGgzJNpfSRh95UIK0fJN8v0QRYD+ovCfABkCnu3LrJkqQ2SrVm/nDGOCFMMiYS 7mNOQEOgYbVqRYw8jof90XS0Mx1OR/1RnAbRK8rq7Pru0dlHjz/403cbo22NiODK0bRVpnVGqaCt aeFM1W3gZQVTIY4gKAuWqg7KQURuVYUoE+cXawMEgukovfOZz1LQraHQ8+oXhPgQUTgC98rrbx6f PNi5dqBdZXxtQzsvcWXKx0NOI0cNIQpF3XUaDOgNkI0y1qNEmnjM8mE+2Un6J0lyYboWZddQCGMQ A5xQwV0wWF2c9Q+vuOcPjpAfRMn+Wfxi35mKMg8KRkBJGPYw7eexT/ZGnVZYXMzaKgSBlONi9uRP 3laTq5FyRZ4mhHUm1Iz7LEePiETK4yc1EXDWL4qyMvACu0e7P/G1r730uTdAnPPgnFDQAMNA4Skn W4g/3ds9HI+n92en1iPP+qe+BAUXojKd1kAK7ex8YXs7Ior6IEWxQWiRSFAHW5WNbCLnrIcQ6Jwx nkgWzroAjre+9Ln/9B/8Z3y6C8rhAcIQAGXQNW1TN03VmloZ7V3nVZnnaW+yk/aHluL8/OT9d775 5N73IlctHt7dnDwpNdIYlIFZZAmlwQoCGPSzlHDSrGoQtF1BULlgudSUO9toT62UMC26DpKAPhN2 9BSMCyKiKA6k09Zif+/gr//637j12quV1ut18cXX32JgjFMuBeVcCEE5IYz2ptPve4k+wAPYdPre //lPf2t9Op+fE8ugaiQRppNB3aqybuYbtzEwFCQFT5FxpEASgTLo2rXOWQdOoWwwDoLywmoGME6/ /KW/cOPGrWeEMA9Q6575yhAQGgP2ygvXs8Ewr4d52efCdO7Jg3fQq3QWPGmcsLQX90MgpWpJgA1Y lDPZoi1Xy9n9fozpJAz3svBh4TlqBYmOczBGQ3CMIaf4+te//vO/+msBgRLqvac/pI384fnbA5jP L6TkTam898ZAcHDCy02VslRwr1orCXzAoIeurc7Omo6JwVQmacKJo3AgTndYVGZyJTIKlKEolDGw gDL4iS/8yOH1F0Bhnbv/8OFLN1+kCNbrbRsut7NFRq4cHB0dXX380fs8TfWgb+2x8iCMcokkQxTH 2nSBoqxMFVjd8DY4o0ilAkMwQEvcKEY/BZdonVGexZnzRWACngaepaAUYGDSacsYh5QQWdLbSYgD DaBbxoyF6tZV07E8zfKr+S6Lkl7We/zdb1gXeU27wpMYpAMsZMptowYJEMBpZDlJeJ334W1XVXPm GxkH5Uhzrtq6GPYiS32zNpep5xkbJQQSAmmVtgEeGEymP/5T//qNNz4HSp339JJwsjWH+hhDBwPA gxFQB+pBt27gAA9OdLUr5uX5qkGPQ0p4Sk7PS2OhLNwWlGvhDLUekUQivbEoNwhAmlDOpdJexExp Hy5NXPlf+rm/OhnuwlFQBwDO00BDQGAggCc0eMpk+sLNG/PVw93DqR6LWi/mp01ZgMD6EincpCei KNrotuxgGT64915BF4Mdvnd1cnVvgK4s2+W6fkYBZjTrR1JKq8EFrMdv/U+/9fO/+msuOEGYtVZS +TEu/BPx/QNT8QAQLJYzRtCpjdFFWwMdKt/OT1XC2vFgGOXUyvaihswxHES7e/0X7xzIJMD55fH6 +NGs3iAWiHJIRpMIjmLdQCRMwDXAndde39s//O3f/uc//TNfu/7iTQ/StVWaJMa2gvZA4IxngUfp 3nRyXSS5iFlbbjrAGTgaRCQTiiTJVKtv37z6eLYuL8rGEEAAhMAK4bIeZECSYTgQxIvNotGdp4zl zAWGuiqW83NpXD7a9wQQn9IZZcC2MbfeesisNx0CwgIEbDQ5zO7Q4w/eozxhURZYSRlgYTXgOIQa T2lZEg/jnecEo54ULlydHhi6DlCL1frxh8fnH1m9hGswyMAJCQHWBmtgHbxT3odFjZbAUbAkigc5 KFVac5l40GdS2fRj8ws8y6QAwD28Ck2rS23Ov/57/+v5xdPBMMvyWEYYZvAl3r273qKXLqnKDKAI 1KsAmjHJYld3roJkyKLUO7quCiLTVd1owCA01rzx1puEEG8slRz4GLbnt+bMFoyn3tujF1751rf/ eLp3xSi5WPX2rjZP/hQHk0hG1NSq1cp4Zz3SDCLD7jB/8zO3szG3at2V5fH9jx7fR7NGbCEYYskJ 5YEy4xEomhb/8nd/zwcHTymDdu6HDsD55Y2Rj+fk2/i++977bbNOEjdfnBiH/RGaC52lSVe3XWgY 0Y4h6mE4xe5OfzoapSKyqjt/sqlndvawXTzG4QgioFwXtkUc4cbR5HuPFhrYHY3ydDQZH/z8z113 BJ0xTLAo6a+K1f0HH77+6m3JU0oTbzNGsLf36o3bn92s752vPtp7Cccf4L3HxUvTnBN2cba4cfXF umKp2GPeKDQd3P5B/Bf/6s9kmfvgu/+K2ioP5MldY9bm1Zu7+8PkwwePpxEWHZrF6sHdu5//2g1L dAC1gSTPq7fnZD4PUE65AHyjTBRFDFDaZckgS3ilbT7d7SjTBJVFPoq6pTKezjegic+SjDM+zjDY lTQNbl29/bvfDNwSQlRry3Nq15BWZL20bjbahzTmw15mY7+uKiukGPR9PWstlgqvfulNOUgBSwUj 25R0afLuwTwYhafb3YU2kBw2XNYJeRT9/tvfPHv8OCZsfnI2OzunDpTIJB9qf0EpaXxYA5+7M/2Z v/Lls9VH733w3pXDPA3DP/ydp3qBr3524jb27HjTHwyIIb396UfrxwXB2oXf+Jv/1suvvQJBqAU8 B8Glids20sEpEECd7+3s3rl560sffPAvtbYH1/cf3T3Pe4iiiDBYbToZeoP+eBB8We+OcZjFZLGE k7Dd2cnZ6ROQFi/tYPkExECO0CpVde3VWzt3T2e9BPPKC0IZYwFBCAG63X1+On9vLwtCL887AKA7 k+l66Z3tEKAVOg/iafD86NotbTatnxEB4bBZ4d4Hi7Ol/fY7D0DRrkxkc1tlw7yRLGwKxBmkhHPo Or397xnjo9GE8QiXFGjqQSmolPFoNOA8eBjKM+9hO6TJ7rUXXvrG7P18POzvROVShQWqTonamxZd 295/ONdU1q6JARrh+s3h9Zv9uOeS3m3hlNRgePfpe2iaQnoyyvPHq9IBxXJ1cnz8RteFmIF4xtjl qveH9OAUgGRb0A1iGQHt6ZOHgfvAfZAhRPAMnngIOOLTfhwYrPemLdrWdwaBwUuks8J6BAJOQDXQ whvf6ZZTAgTmQSyC9wQIIVjnrIdycEA+HEVxiq3dG5NbmPMWV0RhAYByBL4VBvIE3oIyQgHndVNs YsmECwSOwzECYr31lgCND1zyF3fT1956Zf/aSAl61eLq1YFthns3nhYErapN2bEAyTkYn29WHUEV sLM//NKPfZVKDoSty9Rl/MA92yZSD0oDOGPBZleObr9/9w8Gw9Gmmmd9rCjKsohEJLPIgKyr2gXP KBanCOF8frLmEQUlq02zWoEqDC1EQBwD3tVt03rwJAHQtCDAxfHJaG+fMBoI9QGE0D9jPvgDb3Q6 3X3vHWeUlQKcI5boT8dUj7xNFrNy1SFwGNC59c1Dz8TGci9ThBYxqonIr44PBdNazUifpz1bdKjL MgQQQEpx5coBGEDgPegzGaEoSnZ3DwLQaZ1xUIb10oyno5u37rz9nd+Jk37eGw/6p3WFTplgQRks UY4Y5cw2LEWEOA1M6EiS/iBOaZQGMdsbnd5fLasuYy4bDP2qJMBqtb579+6PLhajo8zC0kuL0mdu AXj2mi7Pfs45N85rq5OIerTf/PYfgisiNI+tSOAFAjGI4akKxgZHiCfU+AhgEhBABKOhFZxDLJBx RFJ4G4LWIgIIaPDBKuII86AueOVh4Sz6CQ53ruXRCCGBvUSDbpdBdKuZ8gwi6izlnCKAOHBPQGXR uPWsQnDatG29McrDoeus8IVkaB2MtmmM0Sjh3Pby6Oq13aPD/cUJm4wG9mJT1Z1pEcWI0jjR+rwo bYAFfvSrX/naX/xZMHZJxwifCiSyrXiDA2GgFNeODmlAr583SvQHUZKqZg5GVRZFq0Vd1ZYw2lks DE5mCFAekBGzhhofMgQbY2cAGaNRTV3DCchLEggkRVs3U3BKuGewyknJPhXK/OO7+j6qJjncO2QQ 1gRB4Q1UgCeWOl+3Va10BworLKSDUrDesM74WPPgbAl4VFfGfRDhARalqQyLrixrGA8CxGly/fp1 YIu/A2fP6P6Ep3EeoMKzPMCoAMV0cnjjhTtvf/vMWE5oRLjyBjxBxCFSenitd74pVY1GwWjodr1Z XgRw3dUgHpCBWhmhqQFj0szlGaxF2YaHH92fz+fToxcCgg2GEXGJAiG4HHnBe8DrS1txRukWMKh0 e3r2VHDvhIkzxhM4Ake3CxXblOA0SBoizjMZMclJzIIg63YjmPUenCDaloUczlu2NWjeClIFxkCo I0ZZOHjgYLRzsHsVJIEHHMXz10c+edQEwFOC7R6aer8tzXXZlcsN475tis16oRpQAurBiR0PkHs8 WaPaFOv5yWphwGw/z4LzXdV1TeMMtIOQSOOIcMLjSK/LDgjAz/7lv7RzcOiMY5xfcr8u5XW2ufMZ 5+By1osQXAhOd4qBcM6lVJ2D93DOVZUtDSh8ATAgELQBBuAqBDCKSMSI86o3AjyaEh5IEppEESVI KLTHZDimjIWt3z39dHAD4M8UCrdPzW8tBED4eLwXR73CcqvRlpgpdHbFfOGFsET5EAyUgaJADCji eYCDjQSYw+4edq9xX1SdhvWGi8QFdNuDlaDXy64cHWy/cBvbBHDOMxAw7mEimcMjBAwGQAAh8euv ffG99972NtKObDWjSKCBeOVbkVHeoi9gFZzEuCci7lPJesmwKTbFqqjblm/1Tito20WpiJRd1+Hx 44fHjx+/8sabFJQEFwjb3h7IM7NZBEAwwp3G1rKMIAJcJKODo4PZ8ZIIGvdSkRZtDQ5wBkvACFgA cSAheOesDrpqNbGN8ywG54CH1pY4G3kSceJC4Ft9HxdCsIwwFmA7uyVAHe4d7U0Pt+X11ov14+XT 5ZmzzaCe8ssWmVILUKiuXC1t17HY1GW1mW+sRh4jo0jAh1nWGd+ZMk3BiQ1GJZEIQqpGNUXVFgYe UiKVDIHNN6uNchawwNHVyY//xE+BUE8II9x5y9jzto5/UrCSMjgPxuz52VNKwmaz4oxu19SUIgQY Y5yHAHgEqkAlPIfXsBYOnsAPEjPaS1+5tR9TfX681AFJjt6gB0pgLwl4+WQCoK7rNM8Zg/EQ3x/k HB+LcH4yf9PgGCUSnlLP08RmDKlFLxk8ni87DwUEgAuIHgQDDxhlaBR2htif0M/eOHpx/+D+t+6B o9ZtBEb4s6aDIooF0nhbQH5CjJyG4BGI8xBMbrM7oUCAs/TK0e3r1+88/PCjMt1wFbxVdeu5Am/q raPVeIQccBx7g2HkwQxYYNWyPn10fPrUWgPB4Qh8sB4mEFCKs6dP3v/ed7/8Yz+WjXb5c830ZxnI X2ZySiiog9NgEsRvP6ZvvPHGvzj+HmMsSTMRo16BE8QAs5cDOhCEEFhgHsxar3wIDIxSISis3QIG GQ+cMm/cNttZC0JBBYWDtToAErj2wtXdvek2cC81DZ6zxMknQio8m14QT5gB8cfHH5ydfshIWxfl 8nx1fgpTY8whPIL3iWSz2SaNMB3GkeQkUAruNFOVadYNDehlkIQES+tWH1/YtUcHSIYf+/GfvHbj ltaebHFhlH+SAflJDB+lWyF69/jJA85J06g4pwiUcyQJGCHeeLrFnBFkKWgPToJapEAUIZE42OEv v3Bw63C/mC9Pz5aBIEkp57xWymkE4Ee/+PlLUKB/RjP+AT4PD3hG89km78uLeUfSZMBZSiB6Pdt3 yE1vb3eio+XxHL7FziEObiVy7FquOwIWydVaH+2l+5PetZHMQsuScrQDbcGYl4nMoKsaxkLrzhRr MZyCYDs0BSAo4KlznrHoMtKelUyMxYC98+rn773/TrspW8YLdapq2ABH4TRg0Itk53Sj0ZyvnjoX 9yIX3Gw2O3vSLc8wipBxgIFT4j0YR5ZivWy/+/afPH3w4OX+mDHhgQD+iefjAdBAt7CnreuQ5ID3 oJiOpsGBERFHfcHRaiCACsE8ImrI9nGCMiEpE84K5zmYBiXGWQRIgSRi1AatnQvbmTeMBRVgFCEE G7wDIokrV3cnuz1QA8I/7hCehdAlMO5j4JAHDIQK3fLuh/9qdvFQiHZ2VqzO69U5hAIfwhuo2gvS WY0ogWq7pw+edKaI+7RVy2JVFyc+KCSJVButW+MDKo8W6IC9g92/9m/8EgijnIJQj2cu089buk90 5z6AwsJ3y/nH/o+EUEqo4IyBRYL38qorEMW4+iIOX961sulIzaPQS0TE6Kg/uLG7Y1a0WIZWwQaE EMqyLJpgLRjwt//Wv7M9x5Ikef6j+nR8f/oPz54dS/uT8f553Ot06FqEDk1Zcs77A/F4YQjFwZXR G2/eSPd8wxZGOCpHi+X6YHcovHFFMZsv6kaPxihnCJQkSWIoR9NooK6rxexsfzjcPgznAiGEMQoC AkIJD9v5M0VTIk0BQowyV69en+wczCdPWOia5UXLnQDSnBUzZxR8a3SD9RJO1YvjWvRAOK1a364B hThFLmQtdMQ4ZypiYDGbbdzT+/cXJyd45VUkgpLL8x/PwfJhe3qA8cvo4sL70ABt126C14QEIQRh xLlgLDzlLiDthaCs7qCDM0pb2MbY0rWawAA+IOKYZoiS4KyvOkgBEPgAs/WBpyHAWwIL8AiD3YT2 AtAAlFC2XQ960I/FDp5nLgdKLZgC6qp9+vjk7bI8SYVwnbO1sLWNCRKamqB1Zzvpjo4mrVOny+pk XkxnRT7EYo3FGXoUmURvyDeFVg3SHmPCSQqrsHew/5WvfCV4UEadh3aQ/JlbyPf1AyCA0R2PoVTV tpVzJpbCak8C1dp7GwRjg7wXc+H8arIv3vryG9MXh52oFClE5CUjqlgTbbWulIrquq5raANlQ1Xp qr0sdL/2C7+klutouss49y4QRpzzn6iXPh3f/nIKHoDAYcjtW6++/93fpyxqu26rHuacO35keMCV awOOwelxfZj1Q97zMJ2mkg3mF3UuOG/ok4fr5RxUsTQRs0V9XuLLX33lyeL9CFgvzt9/97v7168j IgC3RsVxdlliUuIB741zBD4I7kAjwIhICKSf/exnV7OHq9lDGkHmcAWenrmRwLX9zCmllzb1iBWC xfk5tPP5EDvD3EW6nGtP9EDyuqyNBkmQcowznD54+D/+w//u5u1X9m7d2SbHy7J2a8blAQQWV0AH F4xzdb1ZLo5nswdVdYJQ1816PMoO9qbrR7MYiEiETsV5WnRF2YHQECXEBlROb1qwFBc1JMULVwGG J+deAkd70tpQV4YziATaAoLEMnZt0wI/9RdeeuHmdDG7N9k5AHggnkB4yABuPack2TZ03sECnEOZ NmLdk6ff/cY3/g+ZruOweXj3+MN3LsySSoeII2IDT1rv18ax+bxIx1mas83czU9hOsQRru+hmmGc pptls7PTD+AfPV6qgKUCJfjN/+g/HO7tgYIAylhGOfGwFpxfBnXbWBt8lksAZIs4qzdlsWyb1XgE wbnVJgRoHfo9WKMWs1Um0c/HH777eK47JZTo0eEozaUMTWSLumra5dlptarzHBclRqP+wcH4j771 0AFdAECi8RQE1hguRPDg5NMJnGPLlP/URQCWTnavtJ3vDaaH1zaJoqSIiOA70+j4XK0WXVmtlhU7 X1dre7ZWrrUIFJygHyH3aGfwK4ykJIEIimGCcrP2DpzA6e7s5LGuN1IKIMSR2EZW1+kokVo1Ucy2 mwMmARgEV22WZTXngh4e7W/mu65ZcFdqD7fZNl6CBJLQygM5pAs0D93OCweLsrw4qboGvoWPkQTr CHYmNMRyueoSglbj0QfvffD2twVPxtdvEioJgVI2eJIIRghA1Ecf/v5sef/sdL7ZlF3XqLZs26XW 65hqYlswaW1lLTwBk1YmtFWKSvTHFIg7G8q6KTvfBRQ1JMfuIQaTxNStl5ACUZ5Wy8YCjPFtQ9pZ 0zpTVog5tCk/uv89+3tqtLOb9fuT6XR//yiNRgw5o8x/zOS6bDUjieOzD967+42qPl6t7xfFU2N8 eaHdkg7TpC/Ss5PNZtU4j9o0liDnax6xvSkopc74oMGjKIFqyraX9QmVdad0wNKin+Mv/9IvXrt2 Ba4FjQGfRJcxs22rqrLK+3mS8i3bV7VtElNAzeYnICaSnBFXlI33nnEIAW+MCzpm1Dl/8XQ+t848 OV9qWIbRCDs9knguDYlBLk4VHKxCucF6VREJEDjgZ3/2ZxBnIAGgjBIAVhvxzKfyz6hPyDM3qgBQ Fg2mPMopj1kUVRtFTLtet5PdRBAgyK6i68acXOjTwi07NB69AQY9bAQyBxToAWwi4DTz2BnLpthI ipTBWpw+ebBeXewkMfl/OXvTGF3z9Lzr+q/P9u61nq3P6T59eu+e7lk8jBcm2DgJwRAlXhLbicdW PESGCPgSESBgHBQJJUGKnMg4EQQLAiiKECLLGLyC7bHHM+PZuqeXs2+1vvv7rP/15kPV6dm8AI/q Q5WqpKp6667/cz/3fV2/K++DibNwH6kV4xCSgq8lN029nJ+eNE1Tlu3p/PR0fpgkYVNNm265aUrT wVmYBmkCw0lHpgXnDCmlLrIUFIwq13a1gY9IAaHABChCgZRUNesmOSqL6YPpb/zSp4y137u7gzzn QmYJBxHgY90eHr355lu/OF/dWcxL5yG54iAprE5sIqyMGCjZT5/QWmLlAzwTBICLCLLkuxA7ggFa 4JnrePmVZyXD0d0HMnHgaKx1PjiCEkwL6UIAQwjwATyBVITQnZ4+PJk/JsZTnfSK8VNXbuzsXN2/ cL1X7MWYBQ9wKA5CRdh8+rc+dff+Z69cShi69XxdHqJZIszjZK+X6/5svVhHpAy1BTiYQaZDkigF 3bUds6R5ZoPtWpqMs8qbVV02Hg546vrepad23nr7c3cOb4929nf3LugsG413lEqjJy51lusnh5Th nGWZAkxbzR/evwVyWSKAMJ1Oo/POQWnAB0Zxb7zjKR6u56sV5gusIjyHbYCCpHGqRc7RH4AAUSB2 yPJ+ZcAT3XT2xz75SQhBITABJhgI3lmlv1klK/G1D79BgdE2NivkS6998NZbX6g7t1ojc2AeTdMm GpPxuLbqaLZZzNvaIQIC2Jvg+rXtBNbONlULHaE576yniFGvN92sBznIoyEs5yd3b76TFPkwKxCt dZ1Oe1LyEJyS/ODgwaMHby0Xj2fTg7KsraGmNR6uP9CIC53xnd2+TzvXiyYL1QES2DN1vwBDiGCC ET88PN60tomIQJZgsIVBIeoqTGc0COVWntWtSwQLxn35dz5dDIpv/9e+vSguAixSmM9ms6Ojezff u3v3swbvBr5WMu/3Biyqtm5M00qy2TAV0edS9rN01Gu5hYxwBjqTjQnWusg8gasMmUCMeGEPH/ro ay+8eGNxclLO5t1miQ7LVcPOBtZ09hACIXmh4qgPl2F/MtmZjEWWrKry+OT44NHhelVpXtx4/gMf euPbn33uA1vblwfDSd7LwDzDBtggrvsZLxJ9UNlygcN7yBmiYrFzpd8YTx4wADR2L/PeMG3bZjF3 KdxAaa1S5khF6Fz4YDeb1ekSVcR4iItXtnXqbt/9MgmZD0ZpViR5MZ5sJzq/+vQLV6/lHeHHAAAg AElEQVQ9L5QAYgDbbNZZnqQ6AdxidfL44D5YEII5a+fTuTGuqTAWQES0Lkm4gOAECfiIROLaNTx/ Y3ck883Dk+aoFRZXd0bL5UrJNLquV4yWbVkbXwPf8d3fA8EDA2dAIM6ZAPvW9bNk9GSj8fXNCaB0 BtAbH/rY//wLP29AqkBPiJxpX7cCkKJSQgkYeCOAFBgN8OrLl1558RlfbQ7efYD1SnRgoWXRS0AS ScZ6OcoVKGI+Pf7ql78oUv1GbyT7Q0mcomdCCwbA3nznC1/64q+GsOLMeu+FHAyGPWKaC8cFu/r0 /rULY7Oy5UnbzvznDm+1wTCQ4iSAELsACU7Be8dhIgjo7eL6q1eGSXh07/DoFLbCzn6xPp0xjqd2 iseHR8uTh29/5bcvNNfUILv74Na777y1mc2YtSGu+tsqsh5i2m7s0aPHjx4cdFWTKTx1YUtEu9cb baalBgY9MKdrY10XOEQiWeCcYlRAlkNpvPbBZ65dv5im0tjWB5sk4BHGQCfCsYgQSDAWIImpJJn0 TLIlUqYWj2e1M5u6ni3mR48O5/M6GDTT9frR8Rd3Pp32hkmWypTA2sacXL40evz4Zpbi9leP7r93 lJAep9ZwDLcndWXm09UZa1cTrlzFBz76Uq+f3Ltz6/h4Qx5PTdI85qvpUjLa3t2al8vOITKkKV59 Y/vS1UnaRzA2TYSj+fHxAy7UctlXyYBxunjxotI9Y43SxWDYI3IudEKY2ey4rtapJoqhWm/qTR07 hADGwCJs61bd3FKoyxgJDNjfxRuvT159+VnVuHtmPl+BIsqT1XKG0cREi+Wims6Ws44uX9hjgwE4 j5wHIsSQcKml+NaIqW+an8SzZ3kAXAmCGIzGXCedIy5gEVV0PKJawbuFI1iLPBXOIyR45SPF6x+4 cOXi4OhuLeJ5Hk0wlnn0UjR1zSikUmgRZMTBo3tb+/tJv3/56vUL/T5X+nw0yene7Xfv33tnPn84 HqPXV94TKAjlqqYOsROi7ueq18+kF/XMt65jCRxFFyEAMHjmiYMr6Xz0Ekpj/yI+8m3Pf/D16+3y 8dHx4XAIDRHb0K7BOHZ2UoW6q2a/97u/lt7tIRebduVNmaey1xeMhO6Ppovl4ePFwYPZ3Vsn0wPk GrtbWDycc4cL49JuYFbobwnhZehsaXyWsTTvkWBdXXYGUUFLCB6mp4eHB/fv37wzP3QZIWci0UFy xgEeiQVPDrCBC6EimMXR3aN7dx/PqyoSC5HaxqBDIRHLcvrw7mr2uD8e7V+aTPb7eY/y1AjML+3l gvitR9PloRdRrg6QlOjtKErcIuJspr53FW987JXrL17hwi/LbDDaJAZFKlQbWbQc0BLOuyTFhSGS CV55/cbO5a119diH0OttB+ejX8Qo2qZKE3733js3Xnhtfy9LtIzwaaIBTtTNZqen0xPGA0BlWZ6c nBgDW6HIwDykEFLFYC0Dejk6QtLDtVeS1155/tL+9vrRYcJMrsA1TInQYHhpxASdbNq6pQj82E9+ kgATIzgHg+AcFCE5ggeXX1/iv/988Az4GwEI/aGPfGz24M6qbMhScH4izmNiuECWIU1iwsEHePpp NdxqOnMwmz5Yr1bMQQOI3NuwvV0czmtKoDXbHjNu6OTx4v7WnWw4vHf/jkoLVQwHw+0Y6fDg/mc/ +9vLxWm/J/p9MNTlZnly2qxWnQdTmgnRJCwOkl5KvdXUHJ0sRA7v4Cwk4AmMgZiH5r5FkBjv47nX r1196SJ6dnpwMG+gBXpiUC42kz4iA/M2Ezh6eMsXRkxlvp2NtvLxKBGo17PpfLZpTHr/3uL+vdVq hmYDOCRDxszIrJcwKB1sCV/DakFRuhqJQjRkqGFKKoZCo5MIhNu3HmTHiBGrE9gKnCNVQQsZnGUB QiKVAsLzCPgAh1CHuZ0v6rCuwTggQB6KY7ybpGC2XJXLplozznbSfEtKnffYZr4pV025sqcPW7dC XQvllQhtW80VF/0BvEFviOsv7exdHVlRTmeHs9VJ3kcvQbVeypoNUlV7u1ycRoLS6G0xvV0s1seU meVmud6sHh8UxtqqqoxzLoTLT70y3n7pra9+ybkw2drnMlEykYxc9I8PHhwePpSSG9uenh4/vP+g a7FeYn+A7gQ5hUHRh4wQPFHBmWb3srh88WqRDTbL6vTgtF5YGZApDLS0pe+n/Sjiw9kJF4wR/egn ftwRILgHJJgQDN6D8IQg83Xn95NSP1v+fG3B0TSmyDkX2b/xp/70u1/+vG2+LC3LSCVeTFCNJ2kE zVfGErxGbyzbdbk4nJkm3L+z3MyRRmgpFGTpQlb06od1wpFxtT8cq66a3m3v3Xx379LWg9tfevj4 3f5k+yMf+3YI9btf+KX3bv5fQqwnI6YVlvPq8NH01nvru3fhAgYjMAZTY5h2F7bm6NKTAzMYcAqx YwBDZBARTIBxmgw4s3FUZOO0Xy6qkwfHj+/N51OoGsNRbKpw/fqlQHFRrQTD/bvde4c3L72sXv7g i3o7rTdmPZ/W65U1/ItfunvvHuYzMKBfIM1BRM1mtdXLPWt6Kq3QEYFRDqG57rb3hov5dLkOSR5G k2SYqSpWpcXxffRGKAr0OaJCEqEiNOeVATmoHFprCpEYInEewygfNCFWrhIdAocPYAw6w8Fjk/fA BUxA0lB/sDS7ecyFZyI2op67h+8ulgfYzCCMefHpZ6x73JZW575IURoMe5gUxXo6FxW9987dg7sY SjDg8BSppWevDbxvj5Y1y2E8ohHlvH3r5r2t/XsQePAQAkvBoQWMgTHw65vZaxc+/1u/fu+9d597 /qVL157a2tlOEvn48Z3T6c354kE/5a6t1tPl7CAkAt0cgytp3XQdQJknHhjnFGO7QtChOSjnYtpU q+PbD+sT5AFKQiq9cP7wdFqROKlcx1ES9q5dDUKGcw0FA9B1NtUS3zIfZBTd17XkMuL8OZNiEMIB DdzyR37w3y5XJ9Vifnmyvbg56wP7474Emx9tfERMcNqAD3Dlerquuke3MOK4Osn7UfAAYvz4dA2O wVZGileuqRyVHh3D9deGL3/41cmlbSNCaZrWWaD03eOrl7eLZPzgzvHbbx48umdPDzCfIhCGQ6Qa xpzFiylOedOWRS8iQHlkHH2Jgp+NMnAO4AI8P89aAEMScXEgmaWuDG0DnfBsOOw4TU31uPTZLgbb I1VknIuus6eHp0fH6CyMB3FcvIyPfNvk5eeecevN0c0HsqLVgW1nSBS0Tl0gx6Al66UUjJEcvSKP zi6XvjHgGlv7iGe9X4TwYBbMIQaEM3ghQBz0/nqS2HC8/fBwergBAVs76G/ngbtV4xYbOI9wnp4G nWA0xnCiUq0EgwwsNsFMO7NCD2zUK7ytGafIEQU8g2NwHJ6hcWAcgkELJAIJSzXTnGtPsrFhY9vS uZZ8R8EQLME5JArMIXboaeyMkUtZe98KXH7u6Rdfe2H/6gWRCwcTpRcykHOKwa2q++/eeff37iwf o6dweYjuBCngPdoOnKPoQyfcRpRVjAy7+2PnzOFRs7ON8SR7eK9NJdoOF5+59MX3DkIub6383/sH P/vnfvIvB67f1+NKPNlXsIhvlMgyovYJv+rJ4U3nik1nyhjqpJCf//Qv/7W/+u9710jrBlY1p922 Zru9oVlvjInQ2ATMHK7cGJGQi9NZEUUPMiyNbXD52k5Zt5xDamVc41kUKfcilORZgWSEYq83ubQ9 3h/xTEZqxwNKddpt1Htvn3z+d+7fegdNff4D9xSkRNchEpSA4IgBWkMK9BRGObbztFCJDoAL9aoC EBkLDMQFSR45kwjM+GGGRKbecR+4B1uabta6fC+dd92qAwlwAWtQlnARAK5fx3d8/LWrz25TLGdH D9dHp3FBNIOZAw3SRHGVVsF20UJSIeEaMI9MIxHgBCEg06RsTGvQtEA8qyeQhXPojxE56EyByBEZ BADi/WKwWm/KJvIMw90iG6UN2rLzdx5af5axxsAiIkEp6Axay0zps1/fr6qwdBmhl6rIPDEiDnAE Bs/gGSLg6Px+HgjOwXRwHawHV/CAJbQRZ45s875K+MnbnsL+JFHApjIzh9FFPHXjwlM3rmxdGiTD RKSR8YBI3aYpTzbLR7Pp3dPNcZAOYy1SG4pEMC1qY6sOxp1Lx4okM7VTUoJTaU3SQ2+S+BCKbPfe g8NZCcpwawMLzHxDxKNM3tebCZwLKICv0+f8If33WcfCmJBSA/jwd/yxvd1Lx8cPdKIFyJiuNDTS nRAiURFa9ChYBfIuhqCEIIJxjnMkBQ5Pp0qpLMuapilLoxL0ZMZjlAHzNdoj7NTV1mR3qLeIs1Ut Fp1smzg/rm6/W96+ibIGAy7v4YUXdrVygrsQ2roOZYmuhnc4k5IpAjzaqguxg0W0KNIzGAZJzkgw CE6SC8as8SbARRs8Z1BRSijGI2rbNRbGwXRou/OXZm+MD72+/dwLV65c229M/fD+wenjE7eE6uCm UAaZULnOo4iemTOgRJ5py1w400hEaM2Y0hGCKxFsOHsOlhpZCuGZc8TOvGHsXJ4kzhUCEYh5kaks MMWlFMFZxqLm7JlLw6aNtmusDZ2Ds+ha8AZQPk/9sGh6OlUp4yPGIiMponECLDI685kzBskQGNoG XEJISCkkIx4jD2AMlUOQYAqZgOLIOEiAOBAwGSFTaNcILTw3RYG9sXKnLnaYPz5KJCXyUipGzPNI zrTd9PHh9OG0W7S2BAyCReMCgySSimmZpZl2sW69OZNIkZCsbTudYmucrU07n5udC4Nb9w5bh3So 7s6cAr7y7pcQiUmFb5pn/wHX71/fnAAiqRIwgdjC+R/+0R//J//LP148frDeLLiAlGitER31MyXT pKuqfgLfGs855+Cck6BslBVZfvfetKdDxsl77x2kgNm0mwZ6gDwiSTHRaZ/1lU2c97ESt+6fnpyu H9w9PXgAZzHK8cbrV1579fqrL19p25m3C8ZMcG1Zll3TUsjJbJka7aYxZe2rNrYmdhY64Fzrd6Z2 jRQJTkQe04IZS20ZrYtae5GoNrjW4HCF7kmg/c4WnrkmP/DKa88/fS2TLYXuzs23v/zlB6enGKQY CrgKvkLChNIaPsTYCUALQCJEp3VCzLvGGwfbEXXGR4y2hynvZOIYUSqUEFJr0pFq250Lp8/8cU9U ZdZ1kViMwbTeVLAcTIIELuwPcx68hA+2y2zdUuXgCOsOrUVj0NfdMEGuIQAbHeMMkWJEZIj83IB7 dr/mZ4oXguRSpZRLcvB7Ax5UlFql/aw3GvRGA10kXMpUy36/79ru1ns3H9w8di2CgFBuMkbTolth fnCcJ+CuUykPwdmmmR8er45saBBKmAqaQerE+XS5rv2q60/SrKdVwRg3LGC96MbDJEboRPUHxeq0 nS+Q9pvTFbIB32xcDQz6evvpG2B8U1bZYPD/ory/sb6/ljLF4Kw/43+DBET+fT/wF5ra/o//8Oc2 5WK7h2GW2nUXaowLkUntGxgL1/l8lAyGo9CFZlOuTdt4m4xYkmcQgjleFGHYKwSh2dRxgzQFC6iO u69279y5+VBkiRV4OF/ef2wOHoITrlzGv/rtb3zg5ee3trKjg1unR3fXi0Mt0cu1lipVaSrz+bIl w5lzIgTGQIJDJ1yQNYaIYiACkT/Ll/TEwTJOingKEKoOXe3KgBoYFBj3kPWxv4+XXnzh+tPPShLl 9PDo8F5brk8WXVyiHyAaRI4MOlVIoRkxWzeWBVLgGhFYrilLu4SLSPABkQCBwLAoW5kpnWfR27Jp qbOKICVEcj6twvsMEQKAqrFn57r1MB42gCSEwOroVABZkfaGfa5k7Uzpujb6k6WrDNoOIQAMLEEk 6rowYBDxPNH4TKrJAAgMBiKE4Cw6E4ILMYJFBIF8whmPUsQiEZNhMhgmXHGCc75eTxfL5XqzPNYp 8gzeYrWBBGKHtkM0YOa4OZ1pLSJ5ssEZ9CMgWSsIHEXCBv2dqhZtjapbN6su90YKkkDCWCBkuRYM jTFN14IgBQLxa8/tvH176jkI+PxX3vJ1K4fj3iA9vx19M1bzj5h/f90npAKD7bxOE4AD4Yd+5CcW Ryf/9L/9bxJBxGQghAgfQwyOBygOb8GCZyFWTbVcB28QfJQapatzgdghIWgtezr11qxWPhVgUla1 P1rYJlov4DSmFhuDNMWN6/hj3/HRV198wbXV7XdvvvnFLyxnaNZIBfqZ5bDB1DHMOwMJKAHNoSJ4 BPNgEb1MxLOtIH3dsRhBLCqdKMl9aFc1HGHYx94Er3/0peHuoBgmYEEz0Symt956950vrq/u4Pgx XMDFy0j7WEwRa+QDLftKRe5a09oQzkJZHZxBpsHOqN5ckvAhMCa0TPThrCx86A8EZyJwQdJrDpUw T0/AOAR60kSe1SLjkFokPT4AAoUQYowwNYjQdh11nUoTaD3I8mGeDCe+Mu26Kr1BJlAozn0EEDrQ WdZZBDFwhjPWDAeLxBHjWeeaKCiGqHm59o6D89DVy/V8GRiaBlUDKZGmYAxnsJC0L3kiExF8xxRc KilE2CVmlWfkEWFaDAoM+tAiJe6i9gyiMfZoaSrrDaHp0ERKNAoNrmgwAZcUWawbNL4WCcY74Elx 5950FdFGvPXml4uLV8EEwKfTxWRn8g31yvC1l+8b6/v3E1fh3FsgeAJiiKEp63zU/9Ef++RXP/s7 D97+ynRZjRTTPWo6Bwp5Bq0QOsCHrm6WS7+qwSMMYDoMGdCDVKAOVVcmkmVporakzlMkMuNe+25j u0UL0yI6XN7DC8/h1Zde3pvkhw/fun/7ztGjVcYxVOj3oCJ0ROhQb9A16G1BqjNxHOfgPBLzQKTg AgACMQbNERkYY1EQ4xwUgg+coyigE2xd3B7vT/Z29lXGmvX60cO708MFGWjg8gjaI/GAA9UggiJ4 grFVmvfhuXfWCwiBNNVEobNhvFXUxnpPTEgmtXVt11hyYWPRlKF0myKVvYTnWZZLqQSZssITqyed BSQBESQT6ck7HyB4lqScc2+Dt52UPngEg8YickPSqIHSwx5pUegi387Je0lREcH6CGuNDUCICGc1 cO6u503jOYEDSkMLrZTSUkHKWVsGBrBAna9rGIPOwDrsXEY/B+N6s7FtC0ssSVPFWG+gKQ/Bd9Fa 56xvYQ3IIYlAi87D8BZcJjq1Jp7MF4eNtwADehq9LQz7HCY2G4xGYl1WFKBTbAyyhGlVTFddQywt 8s/81m/t3HgeXLrOVrbe3pn8kckk31TfZ5ytbyAAeecZGCBDCPlwO3Rtf//KjZdevf3Wm6dzDC7p TPNm3lKIg6FeVJYiFDgXUgojJSLBOBRDTPZwebvHGr856myMdVeSi0qkVbmpF9EryEE6yHIfm87h wy/i8tPjl156oV8U773z7u995vFqgXEfaQZuERt4A8kwTPP9vQETcWWmxAmE6COFeIbB4OD+7F7M wDnjinHOmRDgVFtrYmQBeabH455IUiZltW4+95nPu9h1xrYlbI2UMMqQZVjPcWFHZ72i69qm7iQA iU2FNLUEZliICmmaZr2ht4GbhTWxqlxwyDJJTDQOC0Nd6znDxsJb9Cq/M8SkgPMgByHP2xJGnJEg YsQQiJSUbe3KBky4fuYSJeDgu0ABWYJBDzJJjI/r1lVL58vlosFoh4+2RqkUIhCPAdYzT4wQOc5g P2d/WwHOzrz2HIJxxhgi2c7Y2AXARc6l4pxFijLGTCEbsCzXxlq7otXSLjaQEnziQ2varptsDYVg WiZSKnLK8fpsCrm9lXSdXW+o9cgHrNcbbHjbViVj5wSLdIinnt3dmRSnDx/cO4l+FGZLDPoYbo3N cuOgui7ePmyngOR2/6XXwDh8UHk6LNL4+6EGf99L/Cf/2V/3MTIC50885BEAgvNSSQZQjEIpEONS gdFHv/M7fuVT/9y0i7ZyieRZwpXiaZ4MhnlVdsTJele3aFo0EYM+PvLxC9/7pz62u7t9ePjItDEG OEtZytvOgRHT4AqegvWOC+Q5xr0x68TJ/dlXPvfVW1/ZdGv0Eww0qhmYgQqQEcyCrCPTOFOrBFpL Z2JbnR9ObY22JTCs1khSJIlerT1RzDO5Ke1gwBLFe3kePFWbTuvMh/jurcOd7dHp6SZYlHMkAdcv yL6QCSnnfJb2lc6JeIycGOOSi4TJJF1UTdUR04jgddOFyPqDoaWuaf2VK/tSZw8ezy0hMCwJBBgg 1eASniAkyg1CBON45plLvsNqbkaDrRjFel1v7e123q06lw0w2c4ZMcV1nvQZRcFDVWF7Z9C27vTU PfXU5U3d7O1foGjb2i9P2+1+sTyeD1Xy+Hbd13R4iCyH1kJK3uvl1ru6JpUI56IzoEhSShZD04Su oxhpUIx3t/YUV9PDTVlilGMyGHFi9doqJnqp1CKSQ7ToJfnu7m5Zl51p27rums53Dh4iQjFYEwQX QnGhOJPaEc3Xm+MKHdACF/fx8e9++fU3nkNspyenXYPlFNefLbZ3Lk4XtSE5K5vjpauAFvjy2zcH W1vkHNPS2Cgke19JxZ80HIwBoPff+9r5LYXG+YYBAEIIFCJjTCgJgIknzkTGQAxM2ar9hU/96p/5 yEfWhwcPpnaSYqhQTavJJPUe3IIktMDWGPsZ23t658WXbvRHvYPFojGudeAB2iOL0Z39B54lcxCd GY1F5GERrOBCxiwkW9p4gTRBkcq05xWgoETkPHIJphgHD9OylZmngDxHPy+UTOIYUqiTk5Mkg041 E5wxcIU0TXvk6jISkdYtIyW56lprWWTAzfdOWoedLWwNMUzYIB+387KsO3C0rjPrYF0gLrjo1W2z KJ3KynUFRAx6yJVFgIuBmbBpuqJgdd0ena6riBrogMv726988AOVKfcvjj/z6V/zrVt3eOE5njJx /NjNFktrQ5HnadILvgtUzlarddctG+iAzjemgop2t49UpHk/jbQuq46ikMJZQ23jHz04bZyLAGM4 ejiNBhts9kbIk3TQa6WS1noXIXRQiZYK4/Ho9GSa5DyRSkkZnc0yxxmTKrG2Wy8XgsXtSep95w0e 3l+1LXZ34ZrAeRhl2d4o85HVVXt4/1EyTkDE6NxWxHF+m4gRLpAPZAMx7pXW/WF/T5Utx2RPfeCN F1595UZ01XJ12rTQGtduyPv3amvqp559ulzW066KnCVp/hu/9CuXnr1+7vZliDECfLWqR6MCT4r7 D8ngkda6ELzkXCnFWRQMkOcW5OV8Pt7eAiH4IJTwgaSUerKHev2//fpv/rk/8a+3s9PydC0EhgX3 gE6RZDxyITWJJOkNR1euXu7lRbXenB6f1O1ZEwzHYOj8QfdsLnZOd2dgUdQnZQxcaeiMKQ5B4BbE hWu8i+DRSeKSgVMUhMghJQTOuc/GuarpnKcsK6AUOdc6J0nIFHmREGddF5sSWsMjgsUQ2XpTNt53 DoEjAI2BjEhBdWOd8dbDMSDtGMXWxOgVk3LTsnkHdHBArwDrIQCdBbchUF03GG9lZdnMmvOH993J +Ec+8eN/8S//RFJI2WN/62/8x5/9zV/S1D79zOWD2/d1jum8EQajfBw9vItEWCy7VmBDSCxkAaZg WlRtgyRLeZ4UqelCVvSYovm6cU6sG3dGUpZA1WBLw3XY3++vl+VgrLlQVeWrFpx3QnIi1hlrHHGO yNAZE7xTAlIrKVlEKMt5CBgMZFakXddFhkEKcLQtvEWWtVog0xpJtB4IIeAMlg5iILAzbzWXnHEZ g+0cbGeZsVwxIcEJw2EyHqTk2+Ojx8cHs7aEkoiRGY/+KJNZ/6237+3tXXr75ODX/vkvvvrRfwWA MTbJNRiSVIJh/KS4v+H6luU8AKm1AhSnJ0+gjCHEs0nhfD4db4/BufUu0cLHM7e9Ip6yfv+f/Mtf /vPf98fLslx08eLWNqwZjFiWZdZabp3pzNpO057Y2NM2lNPDGQvI83N0OziYOF81cQJFMAIL4OSV p+gDiwADCTgPx+GsKdKB6bxzMTIORoKDmBMi6JQ4h3WwAaaxZYXOIu+VW1vjxi5rQykL/X7eG/a7 rlltAI/hEGBqU/vKuFWDJUCAA5hEtwJFOA3m1xlBJljXKBRyndnOburORtcRBaACJkNcujYYD5Jm OW+bGAWYRNFDBBnvGCASlkT+yusf+MS/85ey7RF6HKx9/aMfuHvvc5d3r+70VPQ1i8sHc68dUNB6 va7qlhi1AVWEA4oBdp+SfZnX08bOfGvauDJFUQRGRa8/33SLxdpzGREEQ+TwEZJDZGA5DLkHx7h4 0UcS5+t8zsFF1zq/2oSAQDDWmS4gIs+hOHnygTmPs02nZ5zHhGe5KIri9HRFGlLAR8wXbaraNMHW QC2NE4T3t0cExs7s0i5y4YkLIcLZDkIKJKlo1mF2WH3Rff52obvGLE/hLQRDw0kn2Ll47bNfejtL em+fHLx3++H21SvOWetC0csAtK1NU80IxvtEyj88GfC8vj/7uS9IxQe9/tZ41C9yrSUEOwcjvU8C YSCAGAIDkZDZCMFisv3X/sbf/KlP/GiW2/unp+NE5xzOmKqsvUNjsKkR6GE8RBsBh1QjFXBnK+II JZ80TwQKZ10KEGl/knFC4N4z3wWCQCSAqyAyE30XvACzCoLFRKpUk7FlosEYpOAsTaFcQSLr9V0I gQvrAjlSzvOmNV0NjkAoeoPGxnXlGo+zDq/I4Qi9EayBiBj0ISTIwkfIM2MKMcaJQI78GZNSAFee LV5540bC/eNbTVfWwmGcw3uUZWsclERtqGNhsr+fXb4C6YAa8PtX9y5fvxjNnBK68uxeuewYL3WC NNXLZdW5FimiRwWM9/H8K+qF528kQT9659FJM6cOxkcdgvGOJPegdYgs2gpoCQpIcqQZFgaTIbcp qRHmmzgorNZQGqPxlqfY2YVxkQAXgmOwAWfhnTYGolh3SPpIUh2FWDVdWZELUVyGSXUAACAASURB VCxWwWHUw3CQcfK2clUD10EoJ9QTUQ1wFnJIABGqklQSZYZ+IVOK4EwXSdrLIs1ri0e3icNohVQg 5YAHhZSL+PkvvTMFNqF6eDBtRIwSSmiVAkDXGSUEA5xxXJwRvM6L+OtnKd90hssPfeiDAMS5+joC MXoLRC71ZHsMFiMgtYwAzpJ8JbMeWujQda9/13f9Vz/7s3/rp//T2cN5He1AIOW2azAaYJRDAVv5 4LTckIPgUBIsMFhiEcEj0YoTEIkhshAjnfPregOttQzc17aKMQguLKnG4Gi2KCtvQOKMDcyQpRjm 6HFknIPxEIkJrtOsc9Q6f3y8tB6ISBSaztKp1RJFhs6B68xWTeUQAAtohmsvXP3wd35QF7h/9+1u Mx+nyq02zaxulsgLWAPf1OSRZzza6AMEwwsv4fWPXH3uxYub2XT6GEUB7SA5r+tY14gA5+fKjcaa 5eHjYqdned3L8NbNNx0zUvi9Kxeq4xXjlkukClmu6oQrB1KAw84Er35b/wMffWV7a7x4OLOouohc IxHcBd+0sWlbG4MHDKEGfuD7/7jqy95Q37n91be/ciu/MFCaTYI5fg8TqYRMAkXGmLOuqslahIg0 hdYAEICqQWsjY9ApVJFEmSw39cmcqgYOAJBydAGtbQvNNCAVogeZc0VKDGdADGJPgE1pCmJgEYwi fGwM6qqR66YYaMms9LAGCaGfQDLlLD8+qjx0AxDw7ls3i71tZ+s6+pxLQbDWEZFUEgyRQiJT4JvT dr6ejvq1+ub8PLrlSRMTuWBnnsjJ1vj8i4SMgBCMAE/gCp1DmvdA4uM/8P2u2fzTf/QPb/3ebSYQ PBDRz3VRFBxlIdMe21CEZEijJmKKB6UJART5mZuCR84jExQRCYRmXVOReu6qNngF3ddNF+drUxvU QDhL3hAAQAq5gvPgUgDCNZY57yOfr5tNjTqCgAwY9pBnutrYGKBTTjGGKDZNZwGh0DkUPbz0xqt/ /id+uHbL3/j1OD+5v5Ulm+Pjw1gvl5BgtlMSTCnFeGOBTCLr4dqzYucyh1xM5/eWy5oROKEt42qB 4QSRqfLEacAl8s79e//i//jF7/6+79m6kANuupoKzXa2J8Tc/Ue3O2dChPPwoRUypqn0iZcel2/g 6o1LvYnetIvp+qhqjScwBSGoLi0xtNY0XReByDDsi7/z3/+DECoxSv7+3/6Zhi2uPHfNt+vj6VJm SNPU+dhUpbPLsnHr7hyGKSJGfZGnSWeapoKPSBKkvaJxYbXYzNbYnEWscGgtjfOuRWcw0DRJ+UBz rQML5D0QwOl9sj0DEIn6/bzp2hiIQowBvoP3cAaKO6mSnnSWopZIRI88t7VdG0iwBvjMp7+4feNG 2ZS634+AoyCY0EpCKxDqzZoxBq2eRO38UfmujCA4QoiSs0iRfOQMTLDgnNBJiCFQFIKz93VZZ+41 hda4LBHg6uN/8t8q8vy//un/fMgRyqpdWZlo59x86qvNaTbkzEahoSC54BCaEYxx5InAOAlQZCwC jHEQ0bzyuagCYdNA5lA9Zpyf1mBnxkFAZCCOQBAKRsPW6EcvhZCcS6lSrquq8RGZQBugBrh048Ll i7vL6XR6fJSqRAoKMbatE0CiJDkvNa5e32vDogmzdTgJqRntbwtqFofcuWgjSUKapWmqy6pxDlmG rV2gZc2sbk6r22+enDzEOEVKsmu8c7hy6Upj4oPDA50gwN9870v/5y9lb937TVmQzkyzORxoPxxu L2ZHvXx41DXeog5YJxsXAjSUFokLfZVRHU/unCzni3pWRgstoSTakqJBT0kRpbMAUBS4+Pwl9CP5 DuhOu0f5Nrv6/J6v8/tv3+4EGNfBm6YmD9dZREApRI90m29fe2o86pfr6fT0BDEOev22ptWiO12h BQIQGKLi0ExnXPCYcGjFOeeBmPeME52hGgmI7Cw+ntjZGR7IW0JElrLBMBn3nRAszYuTo7UA2ciC B+fSB7ku7dG8I4gN8MFXP7b3xuvRdEW/f1yvRsVIMQHAOae0BkLR7wPomibN86/1JPQHpnSLn/np /4IBgjPGGGOcC86YBAQXGoxzJgU/F2PyJ1pb30WhmDFW6YRBiV7/yo0X/+wP/fD/+s/+xZtvn/QG cM5qRaM+k5KIcQIVPb016lP005OqXts8ZSenVnHf1l5IlhY5cRIZdyrwEY7W2L+ayywaS0Kqo6kl oIngGq9/9MW/9Fc++Rc/+ReeefHKF978/KWru8/e2Oq6uiktc1E6iEBwru7QEPQYz39o+OGPv375 mR0bNqfz+empV8p7HwSERnRdtIQsQVSzaXvvSzd/q2yPegUbpGlOyfJgM71vbIPLl3JCWKxXg9Fk OOzVZVPN0S5p9chP75SrQ886ZByJklkqsiRa61erSqgoU26J0iGSYQU979xjwmwyZLujPuvc6nA1 vb8yc7YzKPKMNa1tDGwElzQayIN79sE78+PbM74JokuZgYxBhKSbB9GpUbqTyl7oXB2tA0qsf/et T/32V3/5N770zwydXN7r5dKZ0xO/ateHwdToDyZMKia1F3TSBV7gh37yB//2z//9w83pf/Tzf/d/ +sf/3aZrxjs9xmVo+Pyk00W+ss4Cf+Wv/gc/9z/83L/5Q9+T70ZZlBevJpeeGmzKTVtFpajaoEhh LAaTYrZ2KmX9ra3Do3pvf1KuN97g2pWtIkkPHperJbVdFNFoj4TC7mSyXLSBsY1nK4+HrTsFzRF+ 78EDKBYFY4JnOq3KdZ6kDBBSgD1B1DEmtcZZnvkTutD7lKFv7r+/ZQ/0zQTlb7gHEBAoSTgIRZET UBmTpwnXQu6qP/2jnwjhH937ys0LPRRE1Sz0CzQmWAdylseZUnLUR/BgiL0Mk8mk6QxRaHxXG0sG tcXuRYgUkUnvnXPBWU4eZ6RwneKv/5c/8+qH30A/u/bCjX/5q7/8wsvPbqf+3W41Pd6ICjnZhFsf oRnGQ+w8g+svPjXeLqrVcjY/DB7jETRjMsKzqBnlAr0IDcCsV7MgR+hN0kJqU1fLo6qcbnyLS3vI C2XMxjpUdU1MgWSu03rR+qqN0QeHLEOulVQ8WJclWqvESfKeJ5rrPGZ7yTNPbV16YTfpM50QWWOW m8XJZvZwujmyt97EJLfjsd7ZGQNwwYcQiOipXcUYIyK7cMt61VooiX4SilwxQ72M93rKh9yuy1WC JuLho9smzUYsLyTLkmHKQt007cIEB8W8953pmrozJoRUYrw9/OS/91PF7uSZF58Ho8DQBRydVEnE 8iFcwKZqOCAF//Gf/MTk6vbkqvjff2W5fTXZH0xE5xfHR8sNVCqyPTl7ZJSCTJOkqJ1A4y1PoIus sMX6cX1wMM8yZBnGWwgCIIwHydGBeXA6H+/J49IfNw0fppGDS72sGnB2Opvu7u501imlJv3htxhy /oBG5A/oVP4Q/fcfdBHA1st1fzL8hu/KxQ9+4icmefp3/+bPHN9bptKrPiIHNyg0XES5prxwRaGc C+tNcASWChDmq66zCAy9AbgAozxlTezS0EbmKBhNgRGIAVtbF1/9ru8Fj4Af7178E9/3Z777Oz84 vf+F00e3Hr6ziQKMI0Qwhn4fyTZ2J7vjdBBquzyYro4q1CgSTGeUqpYcEoGiL1njoaGcL6Kc9IbD nZ6v7fJ4NTucm5p6OSjAda2QGI2R5Kl1XgTiyudK+mDJQCRIM4CFtnbVBqM8CKULAUhEBnLglfGL UlUTcq4lU1eb8mS1OKpXh6hnKBIwhqaxzlmcxUJF4DwKXkUwG7ync36LJd/rwwEdHWhaJZnbUehl qDKM+vzK1s6F/T3NKenILu3mqC7n8AbQhtxaxE5zMIGk4Be2x+OL+8jFn/z+Pwtrq9P56T3sj3D9 2liWS2uFsrFiQC/butRHLCMvTbcSMvT6SVYU+xcGWG9g0dWGFHgKxxAEmoY23aZpcLI4yTg/mzNC QQmm+1nnnWldGaKVyBOkw3GznkLh0boD8Luf/V1wdvfOnWduPEuEVCkwWGv12SPw/9/r/3t9c44Y Hz169PJoCI4szQiw1mvJkGXf8wM/VC5mv/Bzf282W1/Yyjh4GrpRr+dDN18a2yJNnQtYl5ApLHOr pj4q4YHRGL09LcHsyovITdW5zimhtVKJEq31HNjb33r7M//3pWefGo4H2Sj7d//DnwI6u74ptCSJ bIhhkoTOqxgSifL/4e7NY2zN0/Kw57d+29lrr7p7377TtzdmmAUMCYIxBONgBzNWhGyCHchiO1Jk HFmgOI5xQuI42EaB2EQKTgQkRBGQhZhAMOAZAmOGZiY93dPr7dt3rfWs3/799vxx6jZ3WOwZcPdE eVU6OlWqUtX56vne8/7e93mfp8Xs6Mx5NehnXV7ZElzDeQSLKEOWyIT3ExkP61Un27FINmS/TxJW k/nx6vDWw9ldZXIQ4OwUXdsSBsIB05Vtl7fgxm1t9a0jxNmI0YgRb3TbQLcoLRKhYh4xkniKrjD1 Cc7ImS7mtXPagARIAmpAOgiHK1dFlZvVEsUSYOACjCEQbA4TrXVeuqJCFGFjK+71egzKd6UxqBS6 RW0tWIphzHt9jNLNHbm7Sbe6tl09OMsfLpb3la8Rc0Qc3naRAJdoLSz1ts7/yrd9rOpaYzQlrp3h I89k6JqHt5ZZSs6mzkvMFGxdf+93/wU+cLJvT8/uJNJ52yMkFoIRjrZ0dY3tnQygVdeWHVYVFECB 46k52EI2wM7+QAi+WK2Kpu1s8B4np+bZZy4smu6to+mqwxmwvz3+uV/5xN77bjZFde36dQBt26ZZ Yq39Q4IbAPu+7/u+L/JHPIKfTqdbu9vvzPqdd5wzrzSJ5FPPPz9Ikjdvv3l8tjDaUB02B4M44k3b KgMuAIJWY3svooLfP1Wlw/Yunri5OdmbKN22i06GAK+Dt/1MJJlQvlUhLC1MOPvkb/3S2w9emy3u PXljj3F3fOelW698+qXPvHB8XycCvTjilFPOZZLMV7ooMZ+pfFbaUpEWQoN4UI7+kEaEExeI921T qc4TZpVpl8vl0d2j26+dHr7lyjOYCrbDzqYUMrLOV11YVHZWodJoPcpON8pSHrI0E1x4Eyh1/R5t qpDGYb2REjEGp3lAL8HsNORTVDPYCkxDevQo+hGF4apz1iJNsLEZDYcJ4zDWnZzZZRkWBZYWdYdG 2UXenE71eBg7ZxlHcOg6BAfKYmd5nuti1p3cy++9enL8xnJ1v1VTuNaOehACXQsCRBLewTqornvh s7OU1fOT/MHb9TiCKYyvEFEMR6m2JulDd9jZw3RxR7nlYvWgl2JzlO1sjE2t7916MH0YqEUSESFS JqJGq87askMALh9g7yCajEdat5SH1uhKWSKEJaG16G/0NYvun81njZ95fPVXf+iX/ulv9vf38+Wq P5kAMNYKzpq6juMEwf2eU8kvPL74/O09KL148SIhJABt10VxLESsbBvFKVSNtPfH//y/ZUB/7B/+ t69/9t5FYBCv4kScuydTRBGdTHyaxo3SSmGc4rnnrly/ea1oi+nhkdboxwguMAcRecZUGrk+8OwB SI9GkZ6fvHnrtfL4zpUA/+Du7Vde+uz8rIKDc9BaC0RSJkTw7W3bWaWMDw5KQTpQBziIHgJQVJ0u kAhoDQXwpbl1Lw8JLIWxiIFeCiET23gZb7ngg6trnU8bNOtRiEWiQRzqLvhQ95j0nU1Ekg0GbXNq CIpSmQa9pPNAxJAirlwnBUIEF6AKaIt+jH6atp1TRoBYJmPK+jagrNUsR6dBBGiE+JHjMzQQcPu0 6zFMsl4URYR0hBB4pkrlNe6dnjQKDOhLpDQKtVMVRn0SfNAacYxYMhAfM6aA3czuTDZX0+OBxJOX d6aHp7bEwaXhnYc5AkyHy/uIJvH+jf2NSwNDy/29ASWmK6rZw5mqfCIhOaE2nk5Xk41NwvhokijX Mo4PfPB921sb1Xx5eDR/+4H2DtkA490NZkypV7Q3fuG1+1HGHxr8F9//1//8X/0eOBSr1XBzu6xK a9x4PAre97IUwZd50R+Nv0Cq4L8gfAOAH4wGnyf2DFhHBKeEx7CaJL0/8W3fjjj9ib//w8Wrd/LW VMZYCy5AOSgncUKqIgfnox56YwyT2Hddm+eqNtpAjInTQRto1QXbEY9UomnRG/gP3LzSG/dYhN/6 +P/14OG9crG6f+uwXSCTiCi0doQEEG90l/QGVBjKWq0tDYFSRgLVvhsNMsKJDaUjiLNBf8Bb2zHB fFs6D0tBKWRMo2iTUGmUefPtM1CqYBceFdCLMdkUnvgsy6anxbJAWLoebaHRk5ZQ2wLwtDHeWkSB At52KHMbcx4ogWAueN/pTqF0CJ5S2vfetrotWusWS+tcZXwNEKA2cECPozcCl8IYoxUeLDCI4YnK BBjxSSxFxIVRoF54RAFRhF4K7pXq4DmKJmQZE7GLUkpZpttailhQOhrWSZQN+4SD2M4LyorKcdCY QbXYHIH34851++N+LHg62org59PF8b0Hswfe5Ig5QkPLVasVjDHaqP6kN+i3DohiUZfFYjFX6tyl xwUo41uNxtKHdx4sLOrc/tc/9APf9hf/va6o4tF4EGed0eveX1XWkRRC8DrP+8PhPwOFX0h8sfWJ ByFOdZSLpqm4jDjnATDeSSGV0oGCSxmso1nvqeff34uSz73wSXjT6OAoZAwRIfjgDMoSo36UxMgi 4a2dHR/PTk9WU7QNNjaS4ELbBK3RNlg7gzUddAenF16blPI3X3xpeXx6dm9xeCuEFn2JmHGnibOk 0X6RV6ummRdtXlljfZxkaTZmPOm8R8SUt3lujMVwMKQizuumqLv9i9v9QcwEnPfWiKbFfNEcr5YB 0MFXwRWAoHjuK576mm/86Ie++isgWdmuFitlLHyA1nDOB0ZWnSERDZSkmdzc3ouiTBlrA4NIlWUm CC4GcToQccJoHEi0qlxrg3ZorGm0aXwwAAg0QBmefHL8x77l67/5W//E1fddnVfLt+8XTMIDxvqy 0k1rmbAyEp644xPlPdIMoxFLYuG9IxQyQdWgP5pQJqJk1Gl3dNzmrS4qlTch6UWc8eB8XZYb40md N/2+HA17p6fttevbeZ5Pz9Cp0/nsKJbs+O7DxfF8fujnh6hmcBVMHWyLLIs556tlk/aY80YpREK/ +vL90+PaG1y+nA6GcdXoou1WdVsZ3Cs968n/8K//te/6K/8BKONJOp0v4zRlnLddJzgnBFJyq3Wc JiDhd+g9fLFBwqP9qC8o1q6ga/IfAQh1j6b/DoGBUEDrlgYfRQIB0OoXfuSH/tFP/thnXrh1sIdB yl1nncJ4QLKkZ5S9d7c1DhcuE4dQVBhMqEVGSVTOcljDQTglSZKs6prEMECtoQ2SBOMhOFBXoAKc wbWoCziLNItFGntKHpwtNeACPAEHOIUkjNJAEj8cxKNsTC26vG2r1hPPOO9tjOb56mzVtgaUg1Gp OxhoDhSAB/b26Nd840ef+9DzNKZ5uRoMBrPp2Rsvv/ryb332+G1HDVKORKLowCnGMcZZFIOZzjjj CeOtMRbEUwLGGWPee6u0MY6AOw/Q4OBrH1oAQBbjmfdfet9z169dvypiLmLKBDs+O75z6/4nfuWF xQm6FkNgI4GkoB6EYHOTyUQyxqqmynMgYDzEeDQMGBlNijxfTJfGQAgEitbAAlGK0UAOellfMOYc lIYyTpk4TWjEal0tm9A4kAg8gdUQAsyDenADVSGm2N3cvX33JEqwtTuKMrkozlqNSCLiCBbTM+xs U+NYoQONssOzPHeYBvy9/+ZH/o3v/E4QqrQRURKAzhgpBH2ngb2GWVgb2//uFva7iO/1lttv4/sd jzofAiHkMcq5DwjMKJwd/8B//L2f+rV/MjudJwSTPq7sbd363FQQ7G3HJFClWkJQlMF6bBxER6Wt W+c7THpxUMYbt7U1AfEilQ6u6Zqua6XAqNdjIF3X5bUBhdFwnveyIY+zw+np7UIlQAdogBFIDsZg DYyDlJAciQDzCBrBgRBQDuMADkegPZQ+955cx5WrePrLntm/ckH0hCLOEeeIHw2HaRRLyk3VTR+e vv36rVdePHx4ikEfbQtYxED2SFkGBIHChHO/YLIWCwtY60p2gHnE2drcwP6V4fbu5rX3XYky0Zpm vpryiFy4cDDZmrAQH99vju5Pb7/66p03zpYLcCABRjHKDqlAmoByaI1WwzkQnFsuCc6JdwjBOTQe HbDWopQc4yH2J9kwSZixrtForTPWwNMIUSZExjxxxhsA3kI1EAGDtE8tN20QTDZtVVQNBGQG4wGG foo4iiIR33ozT3s4uHztcFa8cXeGCA86/Jc//F9908f+9M7uLghtjeZCGu8opex87/kxfJ/D7D3N 349tcT7CNx5RW4y1Sqm1m561JoqimBFYNXvtpR/5ob/zmd/41Xuvz25cpqH2GUWzwt5mlIi4a1pt dNvCBcgxHrY4XKJP8eTlXptXbYmDvQxA1dRgxLmgNSKGQcoiyrXz05UZTHqURdNlnleWSmJoqBVy B8bAYhCOAFgHtwaXhXPnZwcBcAJBQQgKe34ZNWAACiQSSYannk72Lg53D/bA2axcrOqcCh6lyXgw FEKkUdyPe5mIXGenJ6cnp/lvvfj2Yu7KOYJCQrF27HEBHeCxpkkDAAckwDkqi5hjtIHNbWxvDze2 x3EmCQ+EBxdM2azmq9x6jMZ8c3OSJZv7m88TF7dVcfLw8MHtOycPzlZn6ErQAOvXfq/nVIrw6LW4 c7f68y9SgDJcv7lVVKsiN6ZFRDBMMErR59FI9HWtGtVQHuJMEk463dYddrd63vq6aLzFKBvRIIpl 0TZKRliW8EA6gIyRZCSOYwSyWjRth82dLRXoG/dPFSErFf7Tv/sDf/Yv/qWQpE3TJGnaKSWjqGzq XpqtL/7n43v9Yt5LfOPzt5Qf690Y5wih9BFnca3YQr1ltgPD9NYr/+AH//bJnTc/+cuvjiWePJAJ i9pV3eTeO/R6yHpMKXdc4Vhj7nF5iGdvbC5OZvUKO9txWXaEgktOCLHWssBiLgSo88GLqOzMsqzz KrRAALpHH++7jq/7+q+5fuOJqlOvv/nW66/dmp4sqYNq0TRQ+nySEtbDUXpOzBiNsL2bbe7ujEZD mdrRxAbSuOCN8w6BRzLJenEcc87zPF8tcqdNP03Gg2EsIyDtbLqY1fOTo3w+q/K8ylHkqBrw5Jzh EAIoEHHEAjLG3gWR9EQURYSEKI0Hwx6XxFrtSYhiESUS8EVVLFfzutbOgvnh9sb+9vbWoJdKwrpG nzyYHj9Y5tNmOWtOTuqiPV8lBoMnCBzWIhHYnNDtrc3d3d2Lly/sHxwY2LqrDw8PX//cy7dfK7oG Wyn2JiA1JKEyFlLyQIlzJoTAmJCMx3Gqa1WXFSM8OJcvlQrogD4w3oJMAUriNAuBLFdVvgrXrl8+ mi5PF8WxQg3cu/tWSJJksus5bZo2TpM1Tsqq6vd6eGff5ZzH+g498D3GNx67tx4Lo7WQMQi6rkMg MokAaK2Js1FMoUpfLX/k7/7nr7zwqTdffJ20uHZhePYw1y2yBGlKRuO+MerWsXqgsLmFDz03ubi9 ++bnXl/O/e5ONpvVcU8yLkCZ0c4oG7Rz1joLS9mqco1BYGgscocApD1853d9QzaU/UFKOdHO+kCi OMvi7I0XXzaqq9uqaKu6LlvdGGO8w8HevmBMSpklsYyFp16prjMrGXX9QTwebyRpj4BbC+9CCKRp OudcCI5SSkgwWrVt3SkfJ1vB02DbYJS3BqABzBFhQ0SZZDwmsNRrTkzMHOPekFakHEDXdYyxwWDQ 7/cZY5xLay0A51xZ1Kt84bThnJd5QTnxQSmro1iM+5NY9ryW1KaqpV3lOm0D8Z4FUO8oeqOJ0paB ZDKOeEQIidIkHfRlksgkVsq8/catz/zmC2+9uuoKREASkAr0+0jTJISgtWWEJzKmQaRp6rXp2jri LHiTF2XbgHg8/Uy8f+nyfJUfT+dR0neeHB7NxxtbaX/jU595vQUK4LOvvLR99TLiVBvPpQRQ1nUv y6yzhDy2BQngcR0efEnw/c7vfvwJAKAu64dHhwhk/8JBv99bL0aU5WrUi2Ar6Pof/8//w6/9/M// yv/5yZShLnGwJTY2xqvVgjIkWXSW1yuLL//I5oef/yBM+OSv/trpcbO91VsW1ckMgSEA1sMpOIPg 4IAO52achEADyQDPvv/g/R98+sKFSdXMy3zWtnWgRMhYRLEgfDMbCQLHvPK6ta22ygbPQOZn814S j3r9OOGEeEIdFURIUlYrQRmj0lvaVjZfVfm8bpq2KmomeNJLRqNhf5RGCY8iyaMIgUpO4VVT5k1b OBAmYiJSFxJCBaWcwFPXUtfy0ACutCob9fr9oWQ8eOo9vA3OYjZbLGf5fJ43pbUGQmBjPJpsDEdD IRLvmCnrVdmULiAWseRD5lPqIwThHSy0pwbcec6UpdYEFiB5JKgIgbgAENbZMJ5sbm/vRSJeni1u vfrGGy+/cnzfQaFrACDikBzeYC1JMOlJToVVnRR0c6MvuF8uV22LL3umf+PG9Www/Nzrb73x1sMo yzjvHZ3MQxCzvG0d5sDp7IyMh57SWutMpmv4vn7rzRs3bijTSSGts5ydW4nQd3AV8IhT9QePL7r/ 7UEBUPJ4FvcAoA2kyPrZjWtXESiRAgHOWEie9UdlMev3JUj4hm//czyEKIp+9R9/vClDR4nmYtbZ AGz1o5BgLBCJydlJ1RZNUxGjscoxL8hZEdbV5KOrQAQYpY7HoVPQwHADN5+68r6nnzi4vD3oiVde +RQhihNNiINDUS7aqXadbYZbUjCa0BBTIoPnPhDi4Z/5wEXmAqwxurKuDcQQ4kOId7d2FtPq6OHZ 6qxqCq0q3xS2beEt6tZ2pmRR2RtitIWtnclks58kYZDRWJJIdpwbESVRgFxn5gAAIABJREFUFhOZ NIr6EBAcgZXBsWCZMTb4zeFuZ3xbV3mry7LJF3VXWe9IVZhyidUcqgUC0gh1ls/SNum58Wayd3lj b/eJ/T2nrTIOnEiraLDMKlt3ddstG1t44jwDFdIHBus6zWKecB4bh6azZWuW9bRs80v7Vw4u7m5v bTxx+crx4clrn3vz5GQ1P0PjsF4QYYAgWFSaQxOgR0NtVVBN7UAkWMpm+cnxcnZ4epS3SIgijBWt PWpsAgQZ3frcSyGKA6UdqOXEOUcJU6qD91Zrztkjaeu1+MsjNH8B3O4vJL7o/L2uvuk7WTw8+vJa ZWztBL4uMwkNBJrA+5CwANfW8+NsMkBwv/bTP/0Pf/RH/+mvvsSBrU02n7teioODuCg6p9HPiKkD dVhv8oGy44UzArVGA5j1UYkh5mAcbYebzw5uvv/mzoWd4UYq4jBfHh0dveVNtbMx2t2cpHHinPeB RVGSxml+ckZJgKREkiCJI2vJACep7Mpa1Q2CkZxY1xTlsizM4hgwsB3aGl0Br0A8GMMwi+uu6xwI O5cb7gwC8OSTGA8xGDAhCBdEJLGQiaeCip71wbvAaIipl8TQ0Nrgp7laFqqrHQ1Md265CFUBa7E9 gdGwDbyh8BTGWR20gSdoLESMzQvY2kd/0sv6aZb1OReRTNI0jWIO6SzpPNGOGG2cEEKAU7CIxwRi tWxPpqvPfu7NtoML2NjYfOLKExcPLvXSjHiCIO68fe/NN944evBwemqLFRjQj2A1BinSOIolhXdl oeGxOQbtYDQ6h9ZCATITreGHszYAVIhf/Pgnrn/4wyCogoGIKKhwXhAKgrqqsn4KwAZPH6H58xC9 tvT4QxQnfxB8/854B9+/z93mcS7oiGABs+4lAj503c/81E99/9/4j+7fzW8ckPwsXN1HnWNvA7sb e6+9dNyLMB4mddtFg96rb5eKw0lEE+xe7h1cOdjd3xmNBnGcCpoAQftV3Z4V3ZH1KymMjMj2ZENy aRVdnOSzs9qqEEf9NE4YFOeECg5KrQve0RBAIOqysdrpVjVV3daqbaEUoEBbyHDe5gtuvXAFAjAC H+AICIen54c5FxAsKAXn50wpwhAoAsB5HIAQQoCDdwSBrIXJKbyDbyOrqDfOWb2+QEwCAcxK4gT3 oEFxWE9g3HmfERQQ4CmiBEQi7REiaZREIhY8ITQiYCDUxsIzagW4oCJY1tQ2X3VlaYra8zjulFlW Lurj0pXN0WbPe1zaeyISqRCMMlhrrems1fD2tZdfGqQD01ho+varJ4tTXNwfNNNiwmk+86xPxHD7 qNQvHS1jIRbGRFz++qd+4/rzz6m6igYD5T0YJ7+3YNo/Cz9/yPiDzecfi/Pb6/f5496Z4ft1ISXW FoQeCEnyrd/xXZqRn/6JH33tt16M++gMrl0Tp3fNQORZhO2NdNQfU7J0wbOAYHDtBnnujzx/+eaV uC9LtVosH54cNcHFjBPGDWOVEO0wjfq9LEtSq31X2Plx8fDecnEM3YGShgFxDMpAKbyDe9Q0pBRG IziseSzrfWfmwSxYCwkwgrDe8/egACEQnPhAHKFOBxec8rBrX78AwuAoDAUhv71XwlgXCLyH9wjh /G3QExCG4ECtYo5REMkYlw4S1iAAxIN6yz1EsGvp5DTKlKVKt6qzxqFdoeUAx0oGCMfihkZgEcDg KRjBekJBvaIEzMNZdC20Ao/RG7lURiRtREo51V07b5oun804j9M0HQx6UcxaVS/mJ6uimfTpxt44 IQNoUS5X1bJz2qkG25e3TXUyXYbTk9McyER0ZtTGZPeXP/FPrt68AYKon+G8j42263gc/15AeVfA jX8B+P4igj72iADng/8zf/Y7/qUPP/eX/+3vYCaXrknjBMjbthUCQgjvfbDOWhdx8BjjwTAWspwv p2dNZxsfDIehUYhilmVpmvQ5Dc5YXdj5mZ8eLqtlMz1czk6ga9AAWBiD0eD8xBI8vF8LuIExeIcQ AI8QHp3fgeAhgyRgQKDBrOVo15LqZWkpE4xzwplgYAyBGcA7qx+9QASPEM7RLOn5pw6PFv0IAkGc suCcV/DGEQcSQDWIA+M0EB+gKQUP4AEsAAFeB+aD9JwQRAKBBiYoYaha4xRCA03hABfgAkLAeAhr sW6MSwpKQR2Eh1OwwYdYU4os5VvpaGO7D0rK3KvOdl23OltQCsJ8RORmDxf2difDEemIsTThieQd PNEdTo7P8gJpX/a5n9e2NOrq/uX/8Wd+5urNpwBXLJaDjVHwXmsTJ0nye4P7XYx3Gd/vFE/0kff1 o51nAprnq41BfOnGUx/9hq9r5g+lq6vZrDgufecBFEVR2Fx1IBKjDIoji+KURimL05gzOYoE8dwG bgK1JFBnSZt387NyfpyXi7YrrG+DLmms/ETyTMYI3nQKdH2DeVBQAc6pEIIxZoxZ1w7OOe/h14rZ lFHD2aO/3nuKEBihhDCEAE/gCfEEBIxQwjllQcYSsOFRuODXT+o6rOWN1ncUZaAEhCBjiYcOUnsC pwALb+GAOBWWatBAAEoeWRQEeCgSGCeBM0K54Jyv77FJRh31PgQH54P18DZYH6juKHE+WM2I44xQ SogPzoWklxBLq3m9KLE81Sq/v9rLuBQXLlybjHtpmoIGY5QNJopJnAhnVFs0d27dNUU4PcyJRcwk JxiPN2aL6TLXpcPmaLhc5X/yW77lmQ9+0DQNE3QwHgPBe79eytTGROJ3Wgy/uwD8w9bf/7x4dB59 /DAKT9BpH0fU6lXoZvnpW5/+9V+8f/vFo1t37r9yVJ7pmIE5mAZCgAriOY6WYfequPDkpc2DreEk jVJJgmtsUepV2eb5vMxXXVc63cDUCB18A+El91QGknLZiyJBiXNusax8ID7YECwlYV2rEIrHLwMB CKMUFIQQYL0nFpzz3hMPQgilVMrYg1rvtDXKmDX7lzJQfy7T6nGevNfqTlEE4PzsTSkYo5TSQFhR KE4RMQgKHkA84LgNknLmqPJME4AFMAtmARCaBgc4B+fhH1EIAiGBgBACQigjjBHGCaXwVMyXxhEi SBAckaAIzhuvjGNUiihW1izLtnPgCZiE8ti+gOE43tjayvo9JrmUPO1HaRbNp2fzs+mbr8xcg2IG 6nB5f+vs4fTi1rDT5qzUL6/seDR8sCpeePn1/SuXSRKd22HDgTBP6JpNncbxu1WL/F7x7uZv/87D OnO/U44HdK2Jo0jKGHK0PbjefuJnXbBFlZe1LipsHmTMBYVuPBw1XWtgE27mR2a+up28frvXpzyi wdnOwEt0Ck0Dq0A8BAEPEB7EQBItPaPG+a61WkgZxzze29ixLjhnfDDBax+Udco5tC2Ac4Y6pYD3 ga61Z0Mgfu10gwBPQWnwzJnQgDAwEOL4WkdOcMlYmiRrMs46ba9XQAihIQSHEPx5QjmHI5BmYDTE TAtCuCPBMqsjWG5d8EEEGI9wXuR4DmKJQ6AIDIRBSFBCCWGEsCLvgEACHGAJ+PqMQXXCRWAsEiSO eCwpvDfKaO0Xc8UCjbkcyWDgeEQoJyqoxV1M73W3+YM4QdpHnFLCfQigBN6iWSKmIBZBAyZQ4Nbt fP9Curm7M64PV0Upo/jgxg1QdG0Tp7FqW8Ig4ySEoIz5/1198rvjUZocDqPprNwYCc6pLkob/GAy 7o2HYEvvEUWRKmutveSi8Y1VZnczLlRnCWSAr/1y6tsK1kImIBQpB+egAiTAWwSPYR+pQEwdFIgG h42Yo8QeTx86wgk8oQaAD7AaxmBnHwB8WNfADIGCMsBr3+FRq2Tt77HO90UduLRCYP29CAAjnrPD 2crj/BC5jrUwiJTSIaytuL33gSB4gISNjTFBcD4jjjoXvHXGBuMcEcwHYV0PxNMAeMcoBXHBB1Aw As5BGGdcMCoY2CSKg/PemWANgmUEhMBTsmqM82btaW8MCOA0vEG/h0gSH2BpCCYQDRqIJGQjDR4g AiIGJ6LLzbJAXmIyRiQQOqR98BSWQZAoWGxsYFU1Vdk5gsb7j33sT8Pazqg4S0AQpck6wa2Xpt9r sL37+PaPHh97UwoAQfAYDfuUe61WctD/4Ee+4uO/+L+czmeDUVZPaxfCYqXKHJNB3TWd0pjsZF3X qbWCAgO12OpjMoyrwqxfhQvOWbseZAYBZxA4KAcFrEPXhapqtGksA6FBSBZHiZSUUG+MMsYXzTkL 0iK44MNakAU+yc7FPdaHtvAOJTACEXAc1qJu0DYwxlgYKs93hNdJN1CQtbFOrbGuW8IjnxACEBzm C06QEKQUMaGSCEopKKGUOkJ8oJ5QCgRGWbAgLEop4LVHZ4PrvHOtcy0cBEdwoB4UEBSCQnCAwwZo C+fRtmAUjCB4OIt+iojZOIp4nFhrAyUe3nknhNM2NB3yHNYbGWPSJ/tbUV11xkBXCBFSGTEpsyj2 FkzIKGaNhm87j/BXv/d7IHkccZA1ZYMbrZWxaa/HOW+VytaF2nsV73n+fhSEgHAYZ6MocTrfPbjE 015g8uR0QRjyPN/czIZxp7Ue9nsoK9fpfhIT2mmLSGCwEQlGg0JiuKp1ZwMTlHK+3jYHQ28ALnA6 x/QEkz72NgGOxQLZhCntitZH3tgSIaDfR1HCOown0fGJskCvx2cLC+opMLTYnMizhT7Y33GOvXr7 qCcABmPhPS5fTnf29o+PzhZ5QYAg6D3lJQHnaNYtiwDO0RlIfk64DWtG4TlDFolEo3FtAgssK3/9 wiCOstPT6bLMS41sgJMCkxS9lI4n4yzurXKllJvPlkJy732tfBYxToHOkYAnLh/U+aJq2u3NcVPV QTOZjIvFwrru6pWtrM/funXc1Lh5I2pq1XpTVKsQEEXgkigTqhrX9tPZrNE1EokoE1RwSrkkrPUd 8xhlaGvklbJaNVl39dLBvdPD4d6W7YpGBwMcXLvulaUJByAiieCFlCKK13kufm/BjXcf32tpIfp5 KZycf3gP64NglMleNtlyEHE6oHLhGhjnm641jZfUkRCcwXJeegZHwQhgoWtjEYgFmsAdepxTnjnK JQeNqMiwLKb9YTra1ERYAdSeN8p2QJW7WoEETFKAQgoie+OuXCwqHFZqMmZ14e4t7FYqtbM0eF3i 0rXBIDT3jk9D4FygCZh3GACjDSjgrQf3FnPTBhig0n44yKyglNKdNG2axlprg+8nyTJfrQ+mlFLK GKeUUk6Y3t5K8uXcczQdGHBST1m1THqDrqpLoCzRAWSAZAOrZnl4nPuu1+mwcjZpCWOhAbxz8BAE EYeRUBxG0JAkQVtt6XRW2iCc03ePl2MVDbbToXdt4EiYNca0Rjm0CiIED1CB5bJxBoKCBBBP4Xlb dbOZGQ4lpXqdlbiDJRCSEUICxbIoHQgoPvDs82CEisc2EsgXZuP3rsV7kL/p+TTj0clyHZ6AMjDK O9umXIAmMhlR0aOceuaNB7VedYCA5MYGUA8wJJJxTp1zbeWDAwOERRohTuPAenlL80J3zgSBvMas aCgDJ4gkU40tV9CApWg8Jn3wQaoaHaJeiMdFu2AxbTr/xtJt99K2au41epwmy6b9l29KlhrWOZ7A WLuoYICNFJtbuHhl3xl9//7MSzAgJtgYbn78zVtIItc2LMvgHBiDMSAEggEAWU93/HntQpXz+Xf/ 5W+vFq9+4OkrZ3ceHN5aLg9x93ARCFoABPtXcPU6drbGb7yyaFeW86CUawELwxxaoLHwQAyMerBJ q+q202hQ57YsS1QKDhAUznnSYpKMCAkny8IYZ4z3BmAQAtxDSCQxtAIhYAzGwwUSUUEJgjeMxoQS As8IFWlwzArOjDd1h1Z3PhYm4F/72J8CaAioW5WmER7tdrx748l/brw39Qk9H8uHR1xHAudAGRhh 4JHxigX+zDMffuHjv7FWZT53XY09p6CCUe02NnqenbtK1HVtjPYGkiOOEARUcG3TzkrMG13DmNYK QlcrH4CtMeJ44E3TQjmg8qAEG7uYbE8O75921qVgtYGHZ4I54xwjG4NIZMnJdPWxb/2Knax07ZJH wjh15w4U8JXvH/+9H/zbP/E//XejcXbv3p3pclZUWCkMBJ65eW0xPZ1ceYL1hgAWi8VkexsRBTy8 D1iX9YE8chAAOEEEyeWADLaErmQxZc0y4txajxjYuICv+SguXNyTbHN24mDZ/KRlwnCDXgqRQhoI CW2QxNjbwsG1AVgxtVaRqtRYKChAAXs9XH5iF94WRdU2qixC28ICHEhj5jkzLhgDAtdP4RofPBgH oTyApb24Nxp2bamshXWS04hxFongTNNUk41UR/Ior03AH//mPwnBCUWcROs89hiuvzQQf8/q77V/ lX1n40gbHTOpvIkpA40oyPMf+KpV8Xe08YRARCKViUQjQCMulK4pFz54ZZwxRncmeHAGLoAYpcaq aPO6rQENScAIZaXXARiNsHt5s58Nmq5tAQL0Emzt4ambl7N0dHJ0rJra2o4xNAaSuY88d+mnX/gk mEG9xDD5B//J92zx5P6t6Z3bs1WO7T1sBLRq+d//2A9ff+oi5e7u3aW2GAzXlizixvWL9+/fH1+4 Qji3St25c4dzziTL+tkv/8ovad1VTVnVRV3XTVMro50z+wfbH/vWb0vlV93+3K8LKrx2h/fqhEfe 2yh277uODz17U8Ti+LCxTTdMJ4f1nHPsbeDq9Xj7YAjWiQTa1FkSTUYbF3YvBrIq8lUgbm2MoQMS huvPps8/f2U2XS0/N1vMUHfnPksOcNpVxoGAC3QcW3u8td4Bo2EfiPO6ZcaONkadMm3nvIaVnsaW B2K0a42OtsbJcPzinZUD9g72gfNNv/ClytifH+/l+dI/0synAI1iDkBrHcURQwSAyV7VGBeIIIEy JiIJbfl6XsFwMl36AOVhDBhBGiHiPNBQaFcrLBqsAA14aAcoDw/sbuL60+mNq3u6tvfvdR7IJD74 ldHlq9tXLz1RFrqXQNXe2oJz7PTwwa/8smyS/eQP/bXGl1FPEOknO86drViwCCABXY3BCDffd/3S pQvFamFde3y0XC2xt4UL26kgw3y1ev+HPwIuEAKP5DM3n44H2ZrX8ke//msfuwK/ra0RAIJKFZ/5 7Cd+9ZUXHy7uIw7Y6m3WbUWjfCvt6RVWavHWa0fT+z4W05RjMMJkiz377NWL1zaI1DIl2tSMMeJp xFmwSncAgTWQElsJbjyDj/yRZ8bjUd0teQIDFAEREAkAKAwMEAHDGCRBEE5ZEAIWSefYMq/qBsuq CN4FgBOEAGu99bAancH0aNlzvgG+8Y99NBpvgKCpu3TwXve5f794b/sna/bdekgCGoA0TjunEkYo eNfUX/u1/8r/ce8OVGeD74w2WnlQcGE95isQCu1hgB7HcCAYlWXXtTQqg2+JMQGEIOuDpnAEV5/E 7j65cWVzayRP7zVpH+M+drbx1FPbFy5uJFIvpmeMOsFAySqJYQP2dnk6IYQcM14s8qXnenV8NmqT t19fnj3A3i41RpycqTtvHN97+8ETT+5WXX56CGoRNM4eNtPjxr54/LNPXJ9WbdnUg14qJWeC1XXp g+WShuBBzuf67/SCpYxWU3XzKvYGsHOMGLu4uaOrEFlOiOzO6Kc//jaom555ruGU2RvSOOUyBF1W q1PrWRsPuAsmhFCuFEc2O25NgzRGTCAExhfw9DNPbO9sFkVR1KvOgggMepAC+3tx1ksXy8UqR7+P CxexO+z3bey66XSO+XIekLQGFaByx4FhH/0+lRxOe6vhHShD16Ga5gOBv/E3/+baUWFtLvzOCfNL VnoD+FLMd861bJ0zlEkGWnddlvUCkKTjf+cv/Ps/95M/blnXBU2U042LqQuSKgcLUAYDKI8kBu8F 51RVuGQ4pL7T3ihgMMQTT4+uPbU32RGbO5yxlgfj21XTzIwCsWAOurJN3qza6vjeYVdBMsSc91Ib ZeQ3fvPTT73/+m+8dLs2YfsCljV2+rj9et2eIXgM09Fy3rgaxLCjw7ot71U1jMKlHYwGm29OZwsg CeTwbOYJejGrqsavt5gFtIWr18U3yCNwB4AEJFINU3Cw1cL5AoK5NHJPHlx647VXg3LVoT6aqfEm 4oReGGR13ZIAXenZDHn1gPdgGMYbEBEEk/lSj+KyLTCMsD3cSJ3VQafScx9Xs3o5X7WrytfoRbh6 ETJNnnnu6d29rdOz+0cnt9IeuXJ5d29jrzn0dWFOzlYnx+C8JUDE4BmWGkmMaENIyupFoxoEiiBh gbsNBMPlD3zQ1q3lQmTx79IppusT2B+Oy/0HifeQf/LO4iYBgJdffaXfG45GoyzLGCMkBEICgvrE //bj3/3v/qXQIAMuDOEaDLL+YlVWHg9aSGCyheeekwd7+2+/evf4AbIoAiHzppMj7D0RffRf/Sgk ap1nfXp2/DZ1yuT27kt5M5Wk2Dk8PN44sIMJYi6bUqsOUsQQWedwOF+tGocUZQsq0XSYbGCQwazA NW5eGoe2OXmoBn0gGuWVappWMEiCra3e6aKa1zjSIAxtwHNf/uRwNCGEjDc2A0FZNTKJtdbr3iCn j2QbfWCwmxnPUqFCfXT/3tntO2QZtn00oX21aAghVnrHvSXGew8L54EU2XbqI/9g0T2Yo/MQEQRH KiCAjGF7AFNC5dgd91iS3V+eKoJEII3hLFoFmWC4IZNhPxlHz37gKRaZppulKazJUzF+88Xi7kun i7v6YDM9PGxOa5wA4Hj2I/i6r/vqz37qhVc/rbczjLP+3bfKluOuQgGcnh0NNrbqss2GfQ9obaQU v/1//9Jl8Hc9f9PHnz52/968cXOtJLEO66z3ngb3zAc/9M3/+jf937/w8xsRfA1L4BnvLEoFAVx6 Etfel924fjkS8v59MAnBrFKOBQwyRIIvZrkhxDN/fDSbT+e+UasT3HsZstO7qenLIVRpak8IsS2B CwHMhaAMKXLXeMwrcIIuYHO8pjrBASEADhwkIYgIPBQNemdjHLS3bcWs4A4M4EC2iR/8W//Z5Seu 94cjykTWHxAmAli/35dxSilds7Ye84xp4cv//cd++B/98s8mm+HZ7SfOXnuobnfW0zhmCIQJOB6E kJLzmAjC6LxtVO1Xq26Wo1jrIbagwHaGzQzegXiMUrQGpm3LomUCESA8hKXMem/AOYgih2/PFcVi uYwymg3p/v7I6NJ0zdGpqbUWDF5rVYMDF3dw4Vl++blr/d30wvWD+fROfQylyhZYKtBe76XPfCbI FJRnw37XdXEcx/JxkuCX8pz5JZtfcs6ttfP5fLlcGmOSJNnY2BiP4s1LV//Mn/vO6eGdzUSc3r5T kIrKYAhAsTnGk0/uPPv8k7s749V0znnMeYfgjILVgM3K2eD/+eS8so5J0rTzrlES8BWowbCH8YAY Q/NWtwVUsM6BUVDSaWM6Q+KEGB2IgQ3Y34bzuHptN2Lh7PDUeQTXERcEICi60FqD0ajzhipQ4nxX ofaQHJcuZ3/q3/y2tUfQI72DtecF/LkL3TvqGuuZgIEv7i3emNt7z928uDtIF8fdgxrOt2MhPXTn YQLg13qzsfD9Rd41HrlFZeGAiGPcRy/DzWsX+4Ke3r6Xz8HjiDnvnQjBcjhCIAioD/BgAUQTVUvm RD6vptO2segNcf26j6XXql5MPe8wSSGEZMSmHBeupu//0AfGFzfarkp43I9RelQFOocK+P7v//4n n3yy6zoA3vs4jtfEMkr/v9A++dLhGwDnfGdnZ2tra305CCGABsRTX/blX/VHP2pWZ1nEH4j7be5o hMkQvbFIothbuzybHz08VrWVHEFDMlCgXtF62p7m08paE9DvIY6wO8YwwsYFTGTGbFfmS2+hFWDX C4lw1BnnrMHZCjXQkzi4uvnT/+tP/cIv/lxdL2+98ukoVHNbwxqnPAU4PSe0FEU7SGkcRQmPsyTf 9Bg/ia/7pq/58b//t+6ezKq6kUmaZn2ZpMGTsq6zLAPWtHLvvYdfv1911sxvvf2bvU1M9llEdTZB f4JQIEQsBGaZ0wSWoDNoVceCrbvgKHC++IbeEP9ve28aY1t2nYd9a+29z3inujW8V6/e0BN7INmU 1E2KFKlIkSVFEcxIlh1LiROZlv0jP6QEMBAjDpAfhpDASWDEgCLLgJEoNjLAke0oFh0JFiFGSqyB IUVKrR7Inl6/qapeVd35jHvMj3OrXr3X3aQUh90PCRcuLu6959x7zzn72+usvda31nrig6PHH7vw 1COXZet+d3F4424bmTajKJJikMlZq5mgAtgFOCjAOmEKOpqvGgcn0dQoC5i2lAJ1iTRBX2CrJwTJ XoYWiLysZxUp7O/fPrqxvzhBL0NTogbGvf5f+ZmfPjo62tnZAdaMSCJq2zZ5z6mC7yjvG76NMaIj QTMD8N5ba703IpYyGnz3D/zg737+V7fd3nQ2mc0Poxwbm30h/dHhYbE69kav5hYtYil1bfv9TIdQ LGlW6gW6hl6wGvkQaaSCMU2NOZWsy+UMcQ8wgAXHEIRgETyYsDfG7SnSHv3WH/7hz//nf/Nn/urP NMVCVyf/2X/80+3dEq2DgSTEKrHUrNt3BTRVDckyIJZgj2CaGze+cjg51tomaV6tsihJSXDVtFWh OuYgvPPeB2dDCAiuLhe9fjLaVVbXx4tJAIZDBI3+YBDYxNG8Fd54uAZcSNhoc0c0gK19WBlByPrY vKAvXjG98TTSsjc0SdY1MNWBjHMQAQxEXf9sTwRyluvW6AYtsDLo6GnBYTBSWWzaFsagqV2JOhFw BvOD5QvNH8gBW++Ob0FXuLw7ms/ntsYP/+s/BHAH7uVyORgMyrLM81y9t0kMX0feN3yfXYIucUYI oZTyEA6w0I8+/exv/sZnKSGvfOt1nAHBWGMnR9Z7BAsK2BmyZLksbC9hCa7LxiEQ8NjFvNTl3hV5 eXecern/xv70GFpiZ4Arl7FYwTOEQhJBMoyDIKQRT2ZeSnz3v/Lf6WihAAAgAElEQVS9aN2P/dkf h0hl4pOdTe/iYHHagcuAJHOsVBvHIoRoNqtjWcoYscDhbXz59154/Nv2HtsbKxVbH7R1zrciirc3 +gQRQsCaSO55XV5AZMkTKgkhW5ark5t3Zie3gBqDJC5XBSS0Zx95EBSxUkkg9graW1cZMEYjXHs0 vnRl0Bt6lpVtvYx8mgEazkFS0KZLsYMAB+sJIBZkvWn1oKeqwgC4uiP3rm1ubvVGo2Q2O767f9Qc w1pUjckEe3hrcHQzVME98gikRZZCStVaOODH/8K/Y+ta9nIAvV4PQLemEkK868C/t/K+4bssSyll FEVnQHfOtcaoJAESQBp4H4wlrRKAsJw2vQyhgQiQApFAykmxrL2BNcZoOGgJ5MDTz0Yybbd20t3t vD0JxQnMHH2BPFFJklVV6VWIRMjSyHvtnFeCk7x/OYuGAZ/5i38FaX/vmWfR1HJ4AV4f7rfFCoM8 Eco11swWpmJRVLBebOSx9nWsMNreDFFSTZe67M8PV1cf20xk3GozyHMPJiGHw+FyuQQQgoMAUxAg ZhDU7LgCsxMollzcStxM5wYDld+6PXWERsEqCImM0Q9WCJpXNfdElsu+tOkYOxe2xhsbaYymLJZ3 F2UJqcAOTIhiFAXIgbxkZuc1EYQghnEO09YE4PIOfuDTH3n6w1fLdjKfHcyKIxlBCHCA1hjmiZSe +5HF0q+QC6WFGQ6z2aIqKxDh+U98l8zSk5OTra0tZq6qKsuyoijyPCd6752B7yDvG747e7SjvROR EEIIkQihHaSQxlupVA1HMmS5NM4ezzFUGEj0EiQJkVeCk7vzKo4gAHjLQJzAEi7tYXixF0V61Lfz 0mY5wgaUiacn7WK52N7tR+RjJeJIGsvUVkLIVOV3p4uTqjk+niAItO18svjFf/CLX/itz8+Ol6ZE 6HMQVGksdFuBFga584NRonJYwqJcFPPizUk71+b/+EJz9ZHr2mBRoD+AD5jMIRSSGAHrFGY+dYQT Ie3yjwwUYSvGloJr+Wg2FQLao9ZoDSRDRL4XOSFivcLWha1elmBx3JJuS6oXkQx8cP3W8mgxmyCJ kUiIICUl7bQQAQjsQR4kiZgBgvOIJEzXNlIsPU2CmAzGzeVr+ZuvlK7GkOEcvIdk2Uv6xmklm8Qr tCaV6VuTSQ145mQ0QqCtra1uTDubu1PkD4m8n+tLvNONLCIAijlyzjHT5tZoduP47h0MU0QOwqOe wUdBax3C9Nql8Y1bUx6Fza2BaKv9Zdsbompnu70eCS1jW5uVcRgMN1Fm3DQbo9jFlGRRs1w6+ACh DeJUQUjJioL92b/xsz/9V/8aIjkaDyfzSS4wEu7ShfxksdwZ9McXsxdvVSVCAIyx7a3DiwNcvrr1 1vWT12Z2kMZHs0YDr74FCwhgWaEy8EAW4e4MBIhzdFE+9ZxlEUQMH1B7eJmmvX6U0os37m4N81uL MgbGfVDEVWs2R9s70cbkuH1resMp2BjXb93+v37vNhwGKaIAZRB79BP046xppA/xxd3NXq4Wk5Or V6+8+MLrMtGeceky3555G/DEB2g4Slq97PWoLNuqKPd2gTyPV4gl+9pXVVMd6rQfweD29So4sOe6 xoVh9tVFhSi+zwH8cPhMzsv7jO8HhMO6qHkXAgnk0ZmrHonCMMs5ciZu4jiuG7MqfFVVV66kkGJ6 NF/qkGe48AiuXLu6sZnkPVkv28n86PpN2MlkwMUwGqosffG11zbGzM6nitM4GmwOHMnXX7u5MFg5 TFYtM4Ixx4taMaqARuDyZssprt9eSYGNPuBxVGJziL3dbBzxvJwboK9Q6LYAklj0xuMkTkmwA1V1 6wP1hoPVakUUGD4ERwhEQUmpmLwzvUz1x9EgUZFuzcnq9p3jZhkA3FiUGsi3kGxi0Mv6ml6/vt/U sZUxAGthPGyAIakba5bIJBJCEMgTiDixJtG2ee3GvlJoS0T5xBDihJwPi5WPEmRAkmzE0UAg1KvF dFbNJ3jzNWzIcmjINRyFKOv1DdvVqogiiKgjhZM2KKvKff2xfDjk4cJ3R2PqOEfEgQRIrEvSeQ+B CEGbuqt+yK3xZdNsSZKIA0IUIe4lWTxcTLPZqiRpykV5dOC6Ok+Nha/ak3q/Be7MPAKGkc/jZjQM pGjaIEoQuhEjWAcCpMJ4hOc/xJmzGohSWIf9JebAeAff9tHBtb1LtDB/9KU3KoOO1HX5En7q3//r lx55emf3UpbnSZbLOEribLgxKssyzuJBL2PAunY+ny2ms6osZeC6PtH+tq6Obr788lc+/6UbhRFk DheaU7gY/8Ov/xf/8H/675699oF/+POfXRnUrpXOeMAFtA4N0JS2K/U97mNnBLLwhFIXTWsWbRUk dAkLzKpZYZGxSJJ8uVgJVla3i4m8c0PLSLdmWRZmdoREYJAhblS90t63UZZ6hMUq9PpQAqmSFCgA jUEsJcL7yy75xvKQ4ftMKJCAiIRIpEwkR9YZGEvNqj2ZIG9NlMMytMVyGbYviPF4pJwvrL91c3Uw LxZVWRtojUxipJBvpKhlOW2PbBPHWLQYSAwvwpQ4mrV5r1XAcYNEIbPIN6CBqsUHnozHA3zkIxcn b90xPvFVdWffN8BHvwP/9S/+rX/+678SgSdvTqQCM4zBzgX81E9/5if+8r/d29wjIVwIRCKAbbDW u+18AHigbUMLuPFmtr3Z427yoQQuA0dfwOKF3/mdZVk2Na5e3fj9m7NP/an4c7/zz64+uf2P/vFn rzw6yH1594YzzguHrQ3IHlYtwKhKjPv49g8/tnchP7rz1o03VnenlS6reUAwiGKMcuQ7fbFcFdbG 0rcGVWuPK8zLo4OjBcuWCUqBHHa3eSQHgG9ZN9pzWyNikaCokMTIY+mciwgiYLgxst5J8S18//Hl NHUNIEjBaaTyVPV6UT4PJUglnmsL6yVkP80SG2mTE8VRXtW6bfTJsplrIMWsAinUGjFjbxMDVQsP IxAsDluMBvjwh9VT1564/frNG9dLQ4DASGDjUvrCi18BaYgaMf7Tv/4fXL00Svy8OTy6NSvKFXYv xGMys7n/uZ/7uec++tTyZLpcTChgkMEDe1fSj337s/1EQ8wBCG8BQEgmxEKcRi6DIg/RUa8NQgSM EGpwuTy8dXzz+uroIBHY2hneOp5978e3n/7g3uZ4VM2PHrs2Ll8t68KNR1iVEALPPLe19+TV2rWO uNWlovCBx64kTHV9x15HadBatEAJPHYBH/rQ6NFLjxftHx7ctNNydVIiVh0/GSdHLQEywqCHfoxq 4RHmqZN5nhhFNvhA1Bum81ltLLQ17XyJACEw3tl5CA3uB+QhwzfWIW0P50VgKVWex/1eOixNYXWg ICKZ1DJXnMWwJCKhl3pyMj2Y25VD5VAAvkQDeA0Agy1cvIpRks0Oq9UKkEgzfOx7o08+99EkxJPp 3WxaCqa0Do7x1NOP/rf/5c/m48RQ6UV5aTduqiPbaOGUCLVtMC3aZIyrlzd6ydarL9+sF7PJzaOm ghTY6CG04vO/+vk4yl96/ZU33njj0t6VH/70n958/InFrZuvvPJKlmWr1fJkcjSZHDd1KaUY9PMs HV69+MxyNZ2cvHLz+h++9DtffusFpAYbPbmKkEG88UfXZycHwrWLt+bVG9AzDLcAwjDHtStXH3n8 WsuVFVWrOYtEIvTJndl0MXcecQZitBUeuYqPfXL7mSeeUT7Kxr3VG/OmgQeWxipmlkI7gwDh4DQM UDs4gyi1W6OxdeJoPi91k0gR53ANjHaTmWsB77G9ucUPjZ/73eThwzfgAQNrGVIwJ5FMs6jXP66m mapNUS0buMYUy3kNKBCXAa2fGzggEESAipngW+Dqo3j6mdFTj+9GQbzwxZeO7oZY4YMfw4c++oHB Vm9+MG3cqnbIZdjYQjLo714aT2cH8WjL0erg7uv9vji8sW/uhlsvFst9bA1hPS+0XxyHL/zWa8MN 6dqZmyFPEAyMgy2zz/2T//PF3/0yS+Oc+xrL3/7lf2asb62JEqW1ZoaUTAx4F+A4eCJFIQNAvvRt KQs8OULUCtTVlbw3vXV89y1X7pc9Jap9DCoMFVyNNItdELevT6dNGdJVNChbs9gYxq6mo1v2+K63 FlIqToUWzXOfuPTUdzyRiOTo5pGhRhMCo5diViIfKOPNcgkAucJggGGGzUi0U4cWdV0bJ4qqnhtI 7QcZQgAJ1tZ3js5+P3+/2d3fWB46fFuAoT188J5lEDLImDnmpUNc10VpFkC2hAzQAoMoXNyIfanl NJAAe0SE3StqcGGM1F57Ynv3YrQ5SMy8lhSGCXb26MJ4AwYnB8dm2cJTtQAibG5Hi8nqtz/3L5Ih xO9BpGCJ1iIjpDUyQraBzY3R0fGcWuRQN2/PfQFnkBF2rqi2sMuC+oNRsyhvv3QYS0AgSSAVliUa jSxD00AISAkWoK7+CYMAwRNr0dYQDjs5tvtJgJlOazVUGfNAu/aObY29PBRPPLo5O5rePLG9hIpl 89KX3yoZyQa2r8AFxFGrCK6AqcAG8C4m7kWADq5yk3JytH9EAYlC2YAIH//YzmA0mi0nb1yfkMBj j+GJJy5dHl+YvjW7Gyb7N1bHs1XrUTg0ABM0EAHDhH3k2YIISUwILSg+D3H/tgE9B3//4AfffHkf 8N1RTaIoeodt5KXwQO1bnXjZzmdpFDY21HwY+QS3V3XrUQEnBh/YwfYGH1z3eWSiPEiDYoXNMb7n eXH5mcvcV3KciYQFqJoXxeFsW2XDC01TenOn/erd68IiNM5W5uoW4CFqs6mE9d6VoV2i8rAe2qO0 GBB6AkkEU9bDNFbCrGbHm8BmpBA7Qb6aGyLuZcq3d6/uxGVUirPysxZxBC8RAjhd56WzAE5LE3qP WKkgAyeg4AWxC4h6+e5Q7B/NBGMnglBS5kIR7k7nQoqLF2VtbOx9HiAd/BKrV8ERGoADyEMFZAqJ 4lgpxGr15uSL+xPyoVyaco7NBI/vYjRO9h7pb17si3TwfJFrXw63+/2NNLZyflfOSiOHmybUk1XV EuYB4xgf/nZlKnvrtj3Q0MAKeO47noCeQQ4hcud8CIGVCMBqVfX72b3hvsf+Pyuj8N5B/D3Ct/e+ S6ToCFXvDG4AQIAhhDzOZVAQMoJOFPp5TAIrgwZgxtUn8Mxzgyy7lEWH5a1FHEf9oc5zXLmCZ5+8 unN1q460zVUbwmJeHd05Ovrq0ewN8Am8g52WTkERyAEWZMGA5GC1EwJSIU6QRiSUBEuJ4OZNFECW jLdEFAtWGVwWVjMTCEJAKEgZWBohEIgHWQZH3jnrnHcO3rOHDzANQHCnrfucR/BwHg2bLhEYBCYP soQmAP2e6vh4IYBcsCHYEADUhc1z3ru4lfbTJrj5ank8LRYnyHNIiaS7RXiY0tZV0Tg0EjJDogAH NiCGr9EumtXJYRqZ/k6+NUg4S6J+1LjmZHq30d7Aa2Ch62lALLHZxxNP4vJjF53l2h0vTYUGocLt m68jCjAd4wAkhF/bLZkNXaraaeHd90/eI3x3C23nnPf+65NvfNeQjBQFEoisblzjvPGZ4hm8BB67 jI9+bPyhZ59u2gir8OVX5mkiIrBgn4YMdbY6dtN2+cbJQRtCWZjlXdvcQVhgyMgS2BhBQhJEAOw6 5VcAUY+IyLPwBIdgrTeuZe97kp3xTR2McyEADCEARhyta9cHD92GoAPQAlCkuixTj8AkEElJDKZB FAcCdwVQnLfeeetc8LrVLEgKQcwIwXnvrPMebacOuppAtK7GyQHDjUSbZv/gpL6FIBDnGA3z3d24 bVtmKEgE57WRriXZ1RdnxHEiFCtv2VjT2gLLEu2qPNkvVU/EfTHc6Q82Bwa6nNWzo1XdGBIr6wOA 8SYefzL92Cc+OBr0Z9Pq+qvTLGUbQlSHL33pyzf/6OWrz34SwdqmVWnOgNVGxsobJ6O3jfL7QUj5 puN7Pp+naRrHMQAhRMcRJaJ34d+wEMraWko2xsG6Yr48OTw53l8Ms0znhYzw7JObH3ny8VEvuzVd hKp2FQIHgiiX/kZRrRYviRwTg9tzOAECZEDfY7SBTe4ncXxSTUAQzOs6Fd7DhxACeRm6uCIRWCjB KmYByiCDsVprMto5B2JmhuAkTV3w1nptrXVWW9cRNgQZoCvyzVJKJZRSipkbFuj6k4SuDQQ5ogCn WTDBkiQEkHAwFuzhW+2IghBKCM8smUEk1sEVkhyFWLogOFKxECpACvbGmLouXOvIQTKSBJlKrMgd CQ4I3grHzoSgtbGwNeYTaO+8dEl/0h9PohwSKKbQDfoj08/ACo9dGz79gb2nH3+8LFY3Z3emR6uu DvDmBr/4wuHf/Tt/92/+3PNQIjgLWARG8BygJJ8VrqJ7Jsp9DQ7eG/mm43s6nfZ6veFw2EH83ZG9 Fg8OgaYnR85YXbUnByfTu7PJgclYbfejNLXjLOFSnyxvHVy/W53o3U25PdjOCHM6KJe2OIYoIRQu 9VBZaAPB6CmklHqHuq5NFcAI7CIhmCWz6vrgOOet98Z7hxAEKCLJTEKczMrT3owKUgWwJYSA+aRw CMHDBd91KO5Mahlxl8AQggc0s2YmZrbWAaeZxeHeg0VHtHJE9zYBkDIAIGuI0PXvDgEiILbopyrr D4ZZahGKqjw4nlcVLm7H3jnfOgQoRqSiNE5ElLx+88gHogAKQQYIJkEUCwzyzJMxMDqEusbsJoRC nEAQFCFPedR3scewF5u63L95q67Km29c1xUGw6iq9NbOzv708J/8z7/8qe/5oU//mz8R5Qm8AYtI MeAl8wPZxO+Xn+Wbju+trS2lVEcL7kzwb8Sc9CGY1197yZlmMZsf3DpoFt5XsKGSNrgyHN+4g+a4 qPTJBJIhwa4tnBBZpLyywSEBVKo0O7LeGQQPp2DYsPfBheGgH0IgHwAIkkTkERCCSJS1xrbNSuvW Oe3brn2XWUEw+DR31HoYt66OifufAQRAau8A79blMwEQAuDebol2b8W50vpnpEIiuBoAmLu36z2k x1ChXBq3nIUwW9dKkiCFeaUjKfK8l6k4EpLhvfPGuv4wDwRvvdUmaMtMcRQlscqyxNg2oigVEFWx 1BCMnKEUJNCP4oorY9Eulm/Oju68eSONuDzxA4WdwaheTUZZttvH/hI/91/9ra3tC5/4gR8ECE2N JAV8cJ6FvN+Xwu/kXPmmyzcd34PB4PzbbwRxD2hw+9obL2qzOjncv/OWHwqkApFBQKgLnNyEXupa Q2uMNzBd+eXxLAnoxxAepsFKQzUGKYJH5E4LUghLEStE1pIz0NpYa7tkMetD17ndBJgA7WECDK8b HrKAAIKHC+u6r/acNjrXk2L9ukP2aRU6EAMBxHDuwf3X3zo/6OE0eot1j2326zYm3UMF2KYz7kEA dwsJgiRMJyFStpcUadRKMDnnrdUOFy6PpCIRuG2atnDeeRmHNFPa1quisB5pykpQGgVmJBKxAAA2 ZEvYBmbZLpddb1M/HEA6kKkGsQh1Mc5U25o//Mrrf/+/+XtPPfnExpVr3lkOHh4kJN6G6PfBO/je rC8fcJ58/X2BloU5PnoLZjU9OTo5RD5GQtgajpy2M7v0DtJCOXBAKvLHr6rJ8RwaOxt5P05Xi8Wy MF6g38+HUlhJ1jljnHOu8UFSmC9Wug1tew9wHWTNKXC7LrLarXsZ5mfABQS6zkEgAedBxMSyKwjL zEQicHDBBL43h88a8SRShvsFAMgzU6eez/b33gMg6ztbxXg4B3c6bfqA7HwwDN8162nggT6j0lho MIwEFBAJsMDdN+a9HgY9sIMxkICSIU+ErakGiJD08zhNabFYFe1ijq2BQONc5U0BbyCdSIIlh2aJ rI/jCVahyBJZL+bcmH4Mw/inv/JrP/Zjf/aHrlzjWAHwVrPge7Um31f5ptc/+RNKAxTXb/7+L/2P f/vg+gtH1w+KfUQ1dvLcLJ2CsKasS3ggTpEmA1Ly5t2p94iAnkIsSAnBUslIVVav2rYwoStNrw20 RghozJqHTVh3rOzArU+LplmCI1CEJJVJll7Y3hkMRuPxOMt7kVQqTvKsH2f5YDBI4rTfH/b7wzTr pWkax6mUbF3jve3EGGOt7bxGq9XKe9/5/p1z1lrvvQ+uqgrAd7A+a3LQ5cJ0u2mtm6ap67osS6Ob 0Oq6XN26eadqK+e8tehlqm0NOXh7ynw8bTNJDOOhJJIIsYQEOIADRMCwjzxLemnGzG3d1nVtjBUO bok8QpSlURI79tZqZ7R3PhhcuKj29834AnSQJ3O7dWnvS1+7c9fApfi2jzz7v/2L3wZxaAylGYgB CXrAIrm/Q/F7Ig9d/BKwN958pa1mq/nR9AiyhQKEF4tlKQMEI085jvsBcjYvjhfLfCQcO8ks00yp xBlbNG1bVHGWz8t2WsEATGgDNKCBnGADbAfoAAIShoxx5dLeYLyxs7e7e+nS5sUL462t0Xgj6+U7 2xfTNM3zvlKKWTKzjOIoSqI4AwCWIAEAPtim1abNhv31rfgshNNpkHdOufUIDsHBueDX0mn3tm0B hBDOUN5NjLauENx0OtVaL5fLg4M7dVmenJw0VV0ul9PJ5OToeD6ZFqtlVcF4xAqNxaxCABQQA6lE LEAOi1ljDxvTAkAvw3jcG2ej0cWsXqxmxayoV0KQUooQC9cOB/HyuN4ZQTcw1m4OosXkZHsjWxVV EWC6bqJSUpLABQcvHo4M44cQ3/jaKy8ZXbWNW80xYsCjLU0vVd4YY9DU3nlPgjwnKvLb21eXZVHX 9aLCkkzbtkXVtEC7XDRnhnJgDwJxJGhidRZjZ2tr+8KF3b1Ll68+cuXKlY3tzYuXLmfD/sZ4PNwY JVlPxRGUBNDUTZc7t3ZAh8Akuz5owcM5R0AIodFmtVgWxfKJfg8I1DWqIkCcXmHfRe8I9609umZW AiIQIIgE0DVqE2kuhCDmcKrXO1e491Z20TEKCCgXC6vNcjVfzRd1Wc3n89n0ZDGdzefz1WLZtm1R VJPJZP/2zaPDg2JVGgdiGODgGAroC2Qx4oickPPWt7pwEYlAKk0lR0QUHGxrghFJ3D+8XV+8mN65 W9cGFzfjuyerjYt75VE1A7Yu7tnGyF4CYhecUDHetpz8/6b/5E8uPD1ekKdYQhESBapQFPXFzWGI tda6KN18WQRhkjTfvrC7KJvlql2WhfHenTYAD+dWaTVg4TM12Lty7eKV3e/81HPj7Y3Lly9fvLQ7 3Njs9/v94YCzdA3HTujeWERpv3txasbx6bAxBFisq1FlsYyzdNgMSAmEdwpgvTtPOnjvXNcUUwKe hBTsQB2llkl4QSoEx0KBPCMC0LatECJ4K+I0H42H2xfug5Nztm2bpmlbXS7asqyn05Oju3du33jz 1a++9NrXXjm8c0u2ZTC+aVBU8FUQMAomp+okzHcGarzTj+Kobdu2NMwqStWyaOIc2hjrYT1abbI8 a43f3B4sp8t/9yf/kuz1u0WvdVZE/DZfyfvgPMHDh29GiAf5ztGtr5gGMSNmSMos9Gy2yHNK81TG ZBdusWoXbYNiEqAqbeoADTSnbgcVo2wxHuCpRz/w2BPPXHn0ictXH79y7fGtixd29sb5II/yfL1G AxA8iKxdD0AIIRCY+VRnw3oXvEe3PiZCV6YHjojEqTIOHpJIpum9tePp4rJ7fb4Y3flNIQRrnXOB GRErZu4gAnhmEJG1TmvrvZXSK6VmsxmYZ7OZcw7eMvPu7m6soiiSdHZzkCyl6uW91GDzQgQgeG91 vVpOjw5v3b715uxk/6svvrCaz44Obx8fHEwnx+UKtkVrAAvXmMndaVfqNmGMM5Gn+d07h1evDCer hUjAhOmy2b745B9c3z9pSg984lPfC5K60VEax8naM3iu2uT7RjJ8yPDtJUL8wSe/7X//1b9fzoAA b1iKPMnT1WwCDkFUJGNS1PowcagdYpj6dHUYpdi+iCuP7V28tHth52Kvv3Ht6hMf/PDzjz/+QTnc AhQCjDUsRSDhvXfOEpFSMQC5ZsScDsS5bp3ybV6f02pb6zH0zgGgjjn1jQJYnZyPcwmRPhDTFUKd vVYqZpZdiRgiGvSHcRz10r5SAoD3PlKq43k4b6xxITgiYgaz9NzdYECClVLjfDze7T/14ctWl/80 qmFbb55qqnI5nRzu375989b8ZLJ/vZ2tUKwggHEPUQYt9bwpGkLUy8rpIu2DgGWFDRYnq2qJ8O0f /1hvMLTad6mznmAdzkgYofM7AedU+HuH9ofMf+KB1q5OXvvBf/WDocVWhFiLXtgcqHi5uBXF4Bja YTLHtIQTSHI4h9bBKCQb2LzMe09ceeypxy9d3iMorZ2gdHN8aW/vAxcvXRtvX4rjERD7tXcBzrvO nmZmay0DBBZnhsoZDbDzoIdTpUtdp/Hu0nl0rr31DGDvXTiF93mgO+fOypedQfkBH+L5b72zIzXc d2AAmlorIeu26vV7Z17307a6HOBD8EwecN5X09nd/f03D26/MZsdrGZHui1MUwbTsHfeGa1b25qv vvRaUdatQZxglIFtujxwq0O900sjYa01JFA0qA2c67+xLEx/9I9+/de+8+MfB04rLHqUjc6zCKdA 7hbgp/xB/v83vssGiXtmtxcBj2xldm4T1x+kUbk6GI6Q5mpVm9sHWNXYuoC9RzeffOaRxjWGjYvQ ClPZprW1CT5N8yzLh4Ptfm+cxP0s2xhvXRiPL8fJdhpvDIfD0WiUZn0h5LlCmIzAwTmCAMtTMHm8 u8/eO898bz4YY1TyoOPg64e0uoXj264C8A6xEXgP8oqYrPFSMYDgHMkAeHgL9iDq/PiNaeu6bNu6 barlYnp49/bNW28c7r81mx2YtgihlsJW5awqF3C6l6Ybw36ep1Im25uXnQvelyGEduWPbi2uv3x8 9Nb8kd0rr3/11tWryWLVrCqIWL12bDzEEVztQ9O0SRI7wGLo9rAAAA8PSURBVFgvxH1z87QW+PuD 74fMPoFHBBB/+Ssvffy5Zw9ObDHVo3R2XPq9iwMtXAhMkdzYrIcBF/d2rjy62xtH/SSK0kjFypAu 66KoC2110zS6nk+Xx8fBd/EX64LRrHgrkoOsPxgNxxvj7eHG9mAwjpN8MNxM4n7WGw36G3lvoOIM zAjsbBBQ69XhqcWy7i1P8JJxpk8JFCvfpdedwvqc+qDzGvoU00xd/B5ndA0PeMCug6HBeW+JAneE MFZgiUAyZgQLsiCzXE6Kcjqf3a3q2WI5WRXTopytFvPZfFIXK9u2bVlUVWFdIyRUBCUcyCSJlL1y axxtjDcG/R4LTxQiltVqokQeiagq2tlJeXgwXSyLNmBa63hr+LU7SwcmqRbHrQYEy8/85GdASNLY WiulJMUAjLFKraF1iuWz5ft7aoo/ZPo7eHgPoyHYnUwuXbp8ebO/mKw2B0LCsUeeUb+XOG/q2sYx RtsZ9azKKc/zNI3jNO4P8tHmaDjsHx0dRmkkI+G9rapivlosFouqagfptm5DUTdtY3xglkkU5ypK k2wYxXlvsLEx3tncuri5uTUcbERJb2tzV4hYRZFSkYiUkrGKE0D4dRYOe3AAd7VbCD66R075Omfp T6M5FMfZvUg2nYHbB1i6Fzn1AByM0X65aJqmLYtFUcxXxXw+PTo6vrVYnmi9CmjgW2Orpl4V5aJY LXRd7Yw30jjp9XpZnsRxFEUyTkQUqbpZJWkkJbW6LstV01TGGGv45LC2jWgrVy7a4wM9OQI5pHHa VGG1bBZ2HR2zwO6FS09/x7d/37/xp3/iJ3+SmZMk6SD+8BQfxMOHb8B5MBB8KAuS8r//hV/4D//a fzRQEAHaIgLGIxBjtYJSGG9jvJNUuqlrWAsVI02RJCCJy1d20zTOemkUKyKKIpnnedqLjo9uOW+M MVrrpnWtMcYGG0AQxnndWm2t6yrGKSkoidRQqjzP835/OBgNR8NxfzhI8l7e65MUkUpUnKgoiqJE SikQZ/GIEHful26wu8XoWUpHh+wuuum9r+vGO3SHZK0xtnXOeG9bXXvvtG7qplytFrPZdDabVcVc KWdd440BeWYfvGt12bZlmqgA47wOwamIer18PBr086yqi0hIKSMARrum0W2jjXGz2SJLe87h5Hg6 ny+NMdb6qnH7d6A1YCEIpkZTAA6RwqJGBCgln/nQhz/zU3/pz//Ej4uNDVi7bPSqrpfL5SOPPJKm KYDu1LrX77s8ZPgGEHD37smFnS0EIHi0LUSA93/7b/wnv/n53/jS77/ogEEMH6A1WEBJKLlObVQK rOAtWgtmJCl6PeQ5pWmc5/loPByM4jx3KkYcqyRJpJQkuAsYFnWlta7ruqyrpmmMMcaF4IV1knBG M+TAxFIJIVwglkJI2el1IQSTJMSRHBMiKSMpWcpICBJCEQWtLeCJBOBDoBBcCAQgjtJ1kNJpa621 2jkT4JMkcc4Y01qnnVsH/L2trJn60AqiOFZ5nidJIgQByLNESqmUIMEIa4aAc8Y5U9ZVUVTWhOCF 1n61bIpV3dQeQek2rJZtWdimRtOg1ugPUbcol7AasUAkYVtY4Mf/zI/8+L/1F77/+7+feymkAAUQ fKs56a+KMo7jKIq893VdHx4ePv744+83jNbycOG7C80YgxBCxOStU0ogoJlPk1EP1kC3t95681d+ 5X/9pV/6pZdfeU0CMiBVAKA1vEecII0hFYwBM9IMaSoAX1WhaRCAZ5+NQIYoqEgkSZLkSZbFUSyj SErJUayiREWRVEqxABEtVytPcM5preu6bdq2tcY5JyPlgrfeG+Nao9vWag1nIZUikkySBQgC1HW1 9d4hwAVPIM8kpWLBipmdc0SCmYUgZhayy9fp+h8EZo5imaZplmVRJCOJPCHrWqd9CIFZMMsADoHq qjHGaW0bo21jq6paLouirqJErap6tURdddcPVYmmhtEwLQhgQlXCBgBIU57XPjDII43wPd/9PZ/5 iz/16R/+dD7egnMggrdQARzapnJBZ9kwBEl0b0ndtu3Xvva1j3zkI+8Tgh6Uhw7fJiAAglCXtpfJ YlEPBinQGaIWwUEIkO/uglKK6vDwi7/ze//LL//jz3/+83cnq+5Kt8BOH0UBHZAw0hRKIY5FksrF vCUGMZjRJVx2Ob+bW0gj0eunvV6WZkopycyeda8fq4Q7/SSkFEKQFEKI1ujOynbBW2uNs1Yb692y qLpz6Vx+zrmOX9Xv98/oJUQkpVRKCSFCoC7w3pEAOoolcUiTPMDh1PHivbfWBOu8ddYY3RqtrbXe 2GCNt46qqp3PislJXdQgII4RqYgEv/pmA0YI0C2aGrqF7zhYAm2zZuTaAIA+/NRHnv/Oj33m3/vL jz/5xPb2tjfB2xBFDKAurZSsIoYAYEHewzm0AjFDAXK1WoUQOi70wcHB7u7uew2dd5GHDt9l6+JY WAsl1ytto12ihDGWQSyoo2R474WS8B4esB5NC6UgGca89MUvfPGLX/iFv/Pzs9mkKGoGQlgHgCS6 DFyOlVBKEgUftHfeeQiBSK31fRorpQQLeDIy0jJGFCmllIyUlBxFEUmRJLFQMoqkSmKlFEvBoEC2 P4y6uOMZLs8wfcadAtbxUWY2zoQQvA/dNDjd389m845U2NnrbdvWdW0ar2u2hprWNQ2aGlWDtkFr oCSMhbNwDtbDWRgDbRCA1sI74JT80hFhtsb5889/9M/9uT//Q//aD+/uXQkuEBEiNZ+X/XHeFYJ0 DhzWkRptEEUAYbaaRZFMEgUE551tkGXrgshd/W+t9dfJH3+P5aHDd+cv6NR00xhmjiLhQ+BTD7L3 YZ2kTBABtnFSidOvnVYgNgZKwHt4a4vij/7gK5/97Gf/+a//2tdefZ0hfZd0CQhAAUkkpOq8dF4Q iCAYRGABEEQESEhC6FS+Qqy6VC7BUqq1JSOYOcABViknJKRQKpKCJQsiMCgYbUEBgUBdnvH62Z+q +TPebFdroW2tc9AaxsAYaA2tYfRa6XbXyntYB2dhPYyG87AWxq23EqAktCUHbAxHn/zkJ3/0R3/0 +77v+65duyaU8NaywIOu/UCAMA5ahzim8xudg5DwAd5bKRnwzhvBgiGt9d1tpyiKrvh3XdffWl++ m3jcc7D9MXylnZcuPPjJ/fuc/h75zpr/ype/9LnPfe43f+PzL7/yUtk4ASQS3q59e128RwIkEMcA g0+jFIEAj65ssxBQCh2bsEtBCBZMUAJxDCmhNeoaIUApEMEYEK2NJWPQNLAWQoEEhMDp7IWza1Lt A4/ustT12vvuu8fpJevo7D4AoAtbu9/1qU/+yI/8me/6xKeefPKR03PH216c9Qs/I4wQkFgTmKkr 8NAtY4RACCACCFobUIiiqKOtEz1E3sC3y8OG7y7KdS4b9TSecvbJ+XrqXZnKM7Zgt4kCQOcQf7Y5 APBNPY+VJKXWoeQQwAyEoxs3ptPpW2+8+fLLL7/84kuvvvrqnTt3FovSeBAgxPo27YDg4IB+htZC 67W+ZEIUQTHIwFrYc6ckTidM59k+kwiQEYjQWrTuvv0loz0957NEuO66dDMwjtXOzsVnnv7Qcx/7 6HPPPX/l6iN7Vy7nWT/txUTQLZwLMiIlgHC/kjiPcsLpr56LmAaJwOtwTLi3/xrfuF99nCOXPJzy kOE7eITT/MazHMa1nGM+nX1CrN8lN5vu7XT2STeQhu8n+jhjjLZJlq3phDZgXZqHAiDyBACcacty uVxO5pPVfFG19Ysv/MHJbHrr1o233nrr9u3b0+m0rl137HJt4yCJszhWTaNXegWgH+VpmmvdNI0O wQHsYANCAMVxPBwOd3d3r1199PLlyxsbG88//3yaZqPRaGNjYzQap3mOSIIR4AMT82m08wx/5879 PEP4TwQ/hrdtJZWAQ6NbpWKhYoCbuk6S1FnXtkYJCcBbG8cxJJ3F3x9OeZjxfQ7lD+52dkXZELtv dIVPf8MDnmFdcM5aIlIyJlCXMWWtZwgCExHoHl502wrB4qyrNnmEc88AvIf3a0gHAX1Wgq1rYtLu 7+/fvHmTiK5cubK3tyeSBFLcO7Luv7riKUSQ78KYcPDatl4ng8yfL+nn4bz13oM5hEAMZhb3bAbP 64l974q90/U8t60L+6+zJ08rllB3dESB7s2kTkuIb+H7jy/hnH1yDt/36dvzhgfYM4dvFBA//Yan t+X/OQdnrfc+TSI+LU5C50xelueZIV3GmPdwRmtilkIIQfdWaQHtqorTFEROayFlh1fftsy8TlFz zhkjogjeN3WdDPrn5vC6+2u3gD5PSzy7S3lig65XqCcipc78TOcOsju14Ly3kVD3p67zOavnvquD s2VMcOvJzFiWBTNnaWaMU0ox0DaaA1QcIcBZKyL5MOQRv5s8bPg+vxY8o3o+wJT3CIz1871cG08P /tL683ufeYCd8VIyEwJAYe0se5DefY8TBWPs2SUSTMxMD9IJT4+nQyGd/qH31lrZLS39PRKi1VoI QedJGufnz73jDyG4s3T6tYeRIEQUzhkdDFhvg1vnT3SpzXBeShlFyWlW3H0nd+75bdsCEGAay8wi 5rJpjk6OmWm8vZVECYCqLPZv3xEBe3t7ed5bH/y38P0nkLMBIbgHE7C7hZrnwAj+nJWy3v/tb99u nq4nSYDxnsKpmjy3wPLeO3TuYs9eCo7fuTAPOm2LEDwHJrFmgpZlLQR1zBPidxn50ClxY73L+rk/ Vxbi7NelkG+7LXWepTXcu/0lCybJYOecEOK+bzhY76Vi/+BK5vwPPsDFlex57X8kBMaibIlDnibW W8myqxQkAiIhEbyzVqiHog/3u8nDim9ak+Vx/yCfMbXvVco5f/hvH8L7UY4HFdcZr9oyn1OZp2Y4 QzgrGUynWiqsMQ3Jp3kPD/wvAQR3msDiPbwPXbpPp8TPk709PTh37m1a88LvkWxDWM86IuJ79VlB gbz3nc3tnYcnZrpvWf3A4d13+uf9JwBkMPIscQ/iXhWuU3ECgcBhXd0RD1o7D5k8fPjuJNwzTh4Q Pr/Pu8mf+I759r86s1n5nf8onC4N/+X+2v8/PdRzFSvfcfu7H8yDEL9fzt0V3+XYPN9XmurhBTce Xnx/S74l/2/IQz35viXfkn9J+b8BiAvlN3wH5YoAAAAASUVORK5CYII= ------=_NextPart_ALo8WsHoAiZAMoje5IriauM Content-Type: image/jpeg; name="./­^¬Óª÷¿Ä¶°¹Î§ë¸êÁ¿®y.files/image002.jpg" Content-ID: <./­^¬Óª÷¿Ä¶°¹Î§ë¸êÁ¿®y.files/image002.jpg> Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD//gAcU29mdHdhcmU6IE1pY3Jvc29mdCBPZmZpY2X/2wBDAAoH BwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8 SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAA8AEgDASIAAhEBAxEB/8QAHAAAAQQDAQAAAAAAAAAAAAAA AAMFBgcBBAgC/8QAOhAAAQMCAwUFBAcJAAAAAAAAAQIDBAARBQYSEyExQVEHImFxgTJSkaEUFSOx ssHRJDNTcpTS4fDx/8QAGQEAAwEBAQAAAAAAAAAAAAAAAQMEAgAF/8QAIREBAAICAwEAAgMAAAAA AAAAAQACAxESITFBBBMiUfH/3QAEACj/2gAMAwEAAhEDEQA/ALmooorp0KYM2Zlby5BbWpl1xcjW lJbt9nZJJUb8hW/iWO4VhABxCexGvwC12J9ONRPN0aNnfDGlYPi8Ioilan1ly5Sgp42AJ4jnbzpd rGkHuaqd7fJX6u0TMQOzTjD5cvbbWRo89OjhVv5UzNHzPh65DDbiA0rTddrr5arDhvB49K55VBkg qKGHlNjeHNkQNPX4eNXVk6DHyLgriMZxOEgOqBbcS7uWjeoGxAPFR68qTis/XqU56YwOHsnNFN+H Y9hOLkjD8RjyVJFyltwFQHlxrfqkR8kmtTNFFFGdGDNubImVMNEh5O1fcNmWQfaPj0FVVN7Vsyyn Cpt5iG0TbS22FHhuFyb+tOHa+HTmqAlwBTJYBSlRUAe8bjugn/tZ7LYeDLbxmViBj7RsBtBWP3bZ BuU36n13CpLWta6b1LKVpXHyTcgkyXKxR1yfPfdedW6AStJsR/N+Qrw0pyNpkMuhI394OJ1KHim5 3V7xCI1GnzI7bu0AUdippIIWATY34gW31N5OD5GOUm8QamONzpEUaGlySbOAC6SPAjn0pIbF3KLX AP6ZAw6ATKsdsHQUgNgNjn8b8uFKzJc3FVrlzZRfc3J1vPDUDzsm/wAq1rpEdSQ0NWu+0J38OFun OrAZwbIrOUUz1T3JM9mOA42iSRZ0p3gDpcmuDqHJYprruQmDLfw6T9YwH3WXWHBs1JSbW8VcPTxq VQu1jMscpU4uLLQLAhxsJ87WN/WothsFidOhxHntgh90bdxxISEN7t9+Ps39fOpz2tQcJbGHycPD KHXEaTsrAKRbcd3GtV2GxmLtGxWxuWLlHNUXNmFGUygtPNHQ+yTcoV+YPI+fSioF2PoeTj+K7JKU xgwgOJSVEBeo6Rv38NdFWY7cqiyHLUrdCTfOmUWM2YUGSoNS2SVR3rcDzB8D+lUNOhzsEnPQpTao zzfccQT7X6g8eldO1De0rLyMWy09KYioXOiALbcAsoIB7wv0tc28KXlxibjcGbj/ABfGUdIaQgs/ tTbqnGtooNoN0G3sny6jdQ00p5tDcXaPKIJeS03w38L893WlGJchpotsFpgJQCShFlK6XKR95r0+ uWuIiQ/LfLS3FISSDY2HLf4jl8aj7lvfkSAiiEpstyPp+1Nvd0WFhpte97/GhUdLKnPpO1Ysj7PW 3crPS/KnlUJAwZMlGMyi6WgotEtgXtvG50m3p6UzMvyUNrU1LcSBpva4Fz6+dF2QF+XjMNMoUqxf Sg7LUStHP3f81t4PhOJ5jnswITan16TYKUdDafeJ5Af6DWuuVIWzd1TbyVatJdRqKbcbFQ+4mr47 P8vDL+V46HmQiZIG1kK4qJJukE+AsPjTMdOb3MZcrSu/s3cq5ZiZWwhMKN33FHW88RvcX18ugop7 oq4NTzlV2wptzC461l3EFssKfcEdeltAuVbjutzpyooJs1BOYIkN2VIVGQhptSu6ovu6Ak+Iv+Rq WQuzyTKbSVZhwNk3KrNruq59B1q6peHQp6dMyGxJT0eaSsfMU1LyTllRJGDRmyf4Sdn+G1T/AKdS l/IXzqQJWQ8ZMP6KM5YdsNGjRpsNNrW40yTOzuXFSVDHcEdO6+pwgm3AeyenCrUGQ8tA3GHq/qXf 7qXRkzLSFavqWI4errYc/Fei4l+EyZrH+E59kYc+26ImyQ+4LgCO4VlZPRPH5CukMGfkycGhPzGN hIcYQp1r3FFIJHpS0eHGiN7OLHaYR7rSAkfKlq3jx8Pszkytw2TNFFFNip//2Q== ------=_NextPart_ALo8WsHoAiZAMoje5IriauM-- From list@netscape.com Sat Apr 7 11:52:34 2001 Received: from netscape.com ([205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15391 for ; Sat, 7 Apr 2001 11:52:33 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f2REqt619260; Tue, 27 Mar 2001 06:52:55 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f2REqt217346; Tue, 27 Mar 2001 06:52:55 -0800 (PST) Resent-Date: Tue, 27 Mar 2001 06:52:55 -0800 (PST) Content-return: allowed Date: Tue, 27 Mar 2001 09:51:54 -0500 From: "Slone, Skip" Subject: RE: LDAP/X.500 location proposal (was: DN -> DNS: X.500 group's p roposal for using DNS to locate LDAP servers) To: "'Kurt D. Zeilenga'" Cc: "'Bruce Greenblatt'" , ietf-ldapext@netscape.com Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Content-transfer-encoding: 7BIT Resent-Message-ID: <"i_7naD.A.qOE.FlKw6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Kurt, A couple comments related to your most recent response... First, if we back up and look at the requirements (which haven't yet been fully articulated), we see a need to do lossless (or at least nearly lossless) mapping between RDNs and FQDNs. Even if we limit the set of RDNs we consider to, say, the subset that PKIX requires (not even the larger subset permitted by PKIX), we find that the currently defined RR types (namely A and CNAME) are insufficient, since those RRs are limited to the character set specified by RFC 1123. (For reference, that set includes "A" through "Z", "a" through "z", "0" through "9" and the hyphen. Periods are permitted, but are treated as label separators.) Looking at what we might choose to call "reasonably well-constructed RDNs," I think it's reasonable to assume we will need, at a minimum, a character set that also permits apostrophes, periods, commas, and spaces. In order to do lossless mapping, it is necessary to EITHER define an RR type with a compatible character set OR define an escaping mechanism. Since I'm hard pressed to even find a reasonable escape character in the RFC 1123 set, I'm led to the conclusion that it would be simpler to define a new RR type for this purpose. Second, regarding where this thing gets rooted, I again look at the requirements. One such requirement is the availability of a suitable (i.e., scalable, distributable) registration infrastructure. By this I mean a (mostly non-technical) set of supporting structures including registration authorities, processes, rules, administrators, and so on. Given that we need such an infrastructure, we have a choice between (1) defining a new infrastructure and (2) using an existing one. If we define a new one, we can either define a new one rooted somewhere under the DNS structure (as you've suggested), or we can define one external to DNS (as X.500 suggested back in 1988). Since the X.500 suggestion never took root (pardon the pun!) in the past thirteen years, I'm led to the conclusion that we're not likely to succeed if we go down that path. That leaves option 2 (using an existing infrastructure) as the most viable. The only existing registration infrastructure that I know of is the TLD-rooted DNS registration infrastructure. I know that getting the TLD administrators to take on the task will be a steep uphill climb, but I also recognize that much of the global TLD infrastructure has already been commercialized. This means that if there's a suitable business case (such as one founded on increasing opportunities for TLD registration authorities to charge new fees), there is a reasonable chance of pursuading them to give it due consideration. Having said that, I'll say that I don't think LDAPext is the appropriate forum for discussing whether the TLD operators are likely to take on the task. That's why I'd like to focus on the technical issues in this forum. That is, what are LDAPext's requirements in this space, and does this approach provide a satisfactory technical solution to those requirements. The administrative and operational issues discussion should really be held in a forum populated by DNS experts. Having said all that, I'll fade into the background and continue to develop the I-D so we can really formalize this discussion. -- Skip -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Monday, March 26, 2001 10:54 AM To: Slone, Skip Cc: 'Bruce Greenblatt'; ietf-ldapext@netscape.com Subject: RE: LDAP/X.500 location proposal (was: DN -> DNS: X.500 group's p roposal for using DNS to locate LDAP servers) My suggestion would be to use some approach which didn't rely on information at the root and TLDs. One approach would be to place mapping information under some other domain. You likely can avoid having to introduce new RRs. Off the cuff, one could have a domain like "o-example.c-us.x.itu.int" hold location information for "o=example,c=us". I think you need to look at technical, operational, and administrative issues concurrently. It's pointless to spend time on a technical approach which cannot be deployed for operational and administrative reasons. -- Kurt At 08:33 AM 3/26/01 -0500, Slone, Skip wrote: >I expect to have an I-D on this ready to go in a few days (depending on the >number of outside interrupts). In the meantime, I'll try to address the >"what happened to the discussion on SRV records?" question: > >If you already know the applicable domain name (as is the case when there >are dc RDNs sprinkled throughout the DN), you can do a SRV record look-up >directly. However, if you have a DN with no clues regarding the applicable >domain name (as is the case with "traditional" X.521-style names), where do >you go to query for SRV records? The concept of the AVA record is to be >applied BEFORE doing the SRV record lookup -- it provides a mechanism for >determining the domain name. Once you have the domain name, then the SRV >record approach works just fine. Until then, you're dead in the water with >an unresolvable DN. > >As for Kurt's comment regarding "insurmountable technical, operational, and >administrative issues," can we take these one at a time? That is, let's >look at the technical issues first. What are they? Can they be adequately >adequately addressed or are they truly "insurmountable?" I believe that the >technical issues can be dealt with. If we can get past that hurdle, we can >THEN look at administrative and operational issues. Remember, there was a >time when today's concept of how we manage .com would be considered utterly >absurd. Let's not discount things too quickly -- there is a real world >requirement for this... > > -- Skip > >-----Original Message----- >From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com] >Sent: Sunday, March 25, 2001 12:57 AM >To: ietf-ldapext@netscape.com >Subject: Re: LDAP/X.500 location proposal (was: DN -> DNS: X.500 group's >proposal for using DNS to locate LDAP servers) > > >At 04:08 PM 3/24/2001 -0800, you wrote: >>Frankly, I believe the approach is not viable due to numerous >>insurmountable technical, operational, and administrative >>issues of adding such RRs to the "." and TLDs. > >I concur with Kurt. I don't see the AVA resource record being added to the >root or all top level domains. I note that early in the document, it says: >"We believe name resolution is a critical enabler to the ability to build >cooperative directory systems. We see benefit in alignment work that >addresses the following: ... > -* allowing distributed name resolution to extend through X.500, LDAP, >and DNS (most notably the SRV record) namespaces without the user having to >know or care" > >Yet later on, in Annex B where it talks about name resolution using DNS, >the SRV record is not used or mentioned. What happened? > >>Kurt >> >>At 01:36 PM 3/22/01 -0500, Slone, Skip wrote: >> >As promised in the LDAPext meeting earlier this week, I am sending a set >of >> >links to the X.500 group's working document that outlines the group's >> >proposal for extending DNS to facilitate the location of LDAP servers >based >> >on the DN. The document is the LDAP/X.500 alignment draft. The >background >> >concepts are presented in Annex A, and the proposal itself is found in >Annex >> >B. The links below are to the Word and PDF versions of this WD, >> >respectively: >> > >> >>ftp://ftp.bull.com/pub/OSIdirectory/Geneva2001/TD%20Output/TD3044R1LDAPali g >n >> >ment2ndWD.doc >> > >> >>ftp://ftp.bull.com/pub/OSIdirectory/Geneva2001/TD%20Output/TD3044R1LDAPali g >n >> >ment2ndWD.pdf >> > >> > -- Skip Slone > >============================================== >Bruce Greenblatt, Ph. D. >Directory Tools and Application Services, Inc. >http://www.directory-applications.com From list@netscape.com Sun Apr 8 09:09:57 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08896 for ; Sun, 8 Apr 2001 09:09:56 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f38D7lS18848; Sun, 8 Apr 2001 06:07:47 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f38D7og23397; Sun, 8 Apr 2001 06:07:50 -0700 (PDT) Resent-Date: Sun, 8 Apr 2001 06:07:50 -0700 (PDT) X-Authentication-Warning: bt-gw.bohemiatel.cz: Host [204.138.56.39] claimed to be 62.168.105.27 Message-ID: <0000077a72ef$00007d99$000013c0@62.168.12.193 > To: From: jazzgrl@hotmail.com Subject: About The Other Night Date: Fri, 06 Apr 2001 19:19:49 -0800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Reply-To: elsie@polbox.com Resent-Message-ID: <"primOD.A.NtF.kKG06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: quoted-printable

I Miss You SOOOOOOOO Bad!!!!

I am sitting here at work thinking = about how good it would feel to have your hands sliding up my skirt.(I don't hav= e any panties on!) I'm so horny right now!

I just remembered. I have my d= igital camera with me. I'll take some pictures for you to look at. Hehe. I'm so b= ad today.

Click here to see the pics I took for you bad boy.

Click here if you don't want any more naughty letters from me.

Do ya soon!

Misty

From list@netscape.com Sun Apr 8 13:56:51 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11368 for ; Sun, 8 Apr 2001 13:56:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f38Hshv27774; Sun, 8 Apr 2001 10:54:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f38HsiE13323; Sun, 8 Apr 2001 10:54:44 -0700 (PDT) Resent-Date: Sun, 8 Apr 2001 10:54:44 -0700 (PDT) X-pair-Authenticated: 144.132.70.18 Reply-To: From: "Albert Langer" To: "'Ed Reed'" , Cc: , , , , , Subject: RE: draft-ietf-ldup-subentry-08.txt (with attachment, this time) Date: Mon, 9 Apr 2001 03:59:21 +1000 Message-ID: <001101c0c055$a4510460$6628a8c0@nowhere.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Resent-Message-ID: <"AzjXYC.A.zPD.jXK06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit I am opposed to adoption of an administrative model for LDAP via what was originally supposed to be a subentry specification for LDUP. The administrative model has already been standardized by X.500 and any "simplification" of it should be undertaken very carefully based on a thorough understanding. Such work should be done in LDAP-EXT or a new WG and only after close liaison with relevant X.500 WGs has been established (LUDP should also be involved in liaison but it clearly affects both X.500 and LDAP without regard to replication). The overview of the X.500 model within the subentry draft is itself sufficient demonstration that LDUP lacks the expertize to do this work, as it is clearly wrong and has remained so after errors were pointed out. Current discussions indicate complete confusion about elementary matters like the purpose and function of Naming Context which must be understood for namespace management and name resolution in a distributed directory, even without regard to further complications in relation to replicated areas. Since LDUP has not been chartered to do this work I formally request that it be withdrawn from the sub-entry draft and submitted separately as an individual submission. Recently Ed responded re UUIDs: "Tim - it's within the proper scope of draft-ietf-ldup-infomod. ;-)" There is currently no such document. I drew Ed's attention to this privately prior to the recent IETF. In my view he should fix that before undertaking to redesign the X.500 administrative model. (BTW That is also a response to Kurt's correct suggestion that I should refresh MDCR to solicit discussion. After careful consideration I do not wish to solicit discussion of MDCR while the WG remains in its current state, but am simply making the text available for anyone who wants to look by having placed it in the list archives.) Ed should publish a revised architecture draft with whatever the conclusions are from his recent discussions with Steve, so that if we get a final call on requirements as has been formally requested by the editors, it will be possible to figure out what they are talking about concerning their objections (or conclude that they do not know themselves) rather than being delayed. PS I am in broad agreement with many of Ed's comments in recent messages concerning the need for (floating or failover) single masters for various aspects such as schema management and namespace management. I again recommend study of the method used in Active Directory. Also agree with substance of Kurt's comments: vvvvvvvvvvvvv It seems many of the concepts of which LDUP is based upon just cannot be described using LDAP/X.500 terminology. That is, it seems quite difficult to describe a system supporting multiple-master replication using models designed for single-master. >So - what does LDUP need to do or say? Well, I think the group needs to slash a few requirements. First, I'd eliminate multiple-master fractional replication. Then, I'd start examining the question "who is authoritative over an entry?" because until you answer this, you cannot design the administrative model. ^^^^^^^^^^^^^^ However my conclusion would be, as perhaps Kurt was hinting, that LDUP needs to understand and then fit in with LDAP/X.500 concepts rather than adopting an indescribable architecture. Do not agree with earlier remark in same message that: "Naming contexts are just one part of the administrative model [...]" (though I agree broadly with the omitted point actually being made). Naming Contexts are part of the distribution model, which LDUP still has no real understanding of, despite it's importance for understanding replication issues. My view on what LDUP needs to do is start by publishing tutorial material and working it's way towards a glossary to get some common understanding of basic concepts. First however it needs to do some summing up of how we got where we are and have people assigned to perform essential functions for Facilitator, Secretary, and Consultant familiar with IETF architecture and standards process as the WG co-chairs are still plainly AWOL and have still not been replaced. Meanwhile I don't see much point in discussing issues on which there are no I-Ds as well no point in publishing WG I-Ds (as opposed to individual submissions) on subjects for which we have no charter. Either somebody actually does something to get LDUP functional as an IETF WG or it will continue just drifting aimlessly. At this stage I do not feel any obligation to respond to bits and pieces of the drifting and will simply, follow the discussions without participating (except at final calls) until something is done. I do believe there is some obligation to speak up during discussions on the list rather than wait until final call, but at present this seems to me a waste of time and effort. So I am just generically putting on record that I *have* spoken up and did not agree with whatever was being discussed prior to whatever it is that may or may not be submitted as an I-D to a final call and will just review whatever documents somebody claims are "final" each time I see yet another "final" version. -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Ed Reed Sent: Saturday, April 07, 2001 1:42 AM To: internet-drafts@ietf.org Cc: roland@catalogix.se; jstrassn@cisco.com; capple@ecal.com; ietf-ldup@imc.org; ietf-ldapext@netscape.com; Ed Reed; Mark.Wahl@Sun.COM Subject: draft-ietf-ldup-subentry-08.txt (with attachment, this time) Please publish the attached (really!) revised draft. Abstract: This document describes an administrative model for LDAP, and an object class called ldapSubEntry and a control ldapSubentriesControl (to control the visibility of entries of type ldapSubEntry) that are to be used by directory servers claiming support for the administrative model defined here. ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.Reed-Matthews.COM From list@netscape.com Sun Apr 8 16:20:59 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12157 for ; Sun, 8 Apr 2001 16:20:59 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f38KHTv05285; Sun, 8 Apr 2001 13:17:30 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f38KHVQ08177; Sun, 8 Apr 2001 13:17:31 -0700 (PDT) Resent-Date: Sun, 8 Apr 2001 13:17:31 -0700 (PDT) Date: Sun, 8 Apr 2001 13:15:40 -0700 (PDT) Message-Id: <200104082015.f38KFeI02400@xwing.aoltw.net> From: homejob@EXNV.vdirect.com To: ietf-ldapext@netscape.com Subject: WORK AT HOME X-Reply-To: homejob@vdirect.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FxH8gD.A.O_B.ZdM06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit URGENT! We currently hiring SERIOUS HOMEWORKERS Position: Home Typist, Clerk, Secretary, Mail Processing, Supervisor, Manager. Earn $3,500-$5,000 per month! Part/full time. ANYWHERE in the world! YOU WILL BE PAID WORKING FOR US BY : 1.Typing the company`s sales and administrative letters, memos, payrolls, agendas, etc. 2. Control and checking of administrative data entry, 3. Clerically handling classified ads for us, 4. Sending out our e-mails, 5. Developing our marketing`s campaign. We offer you REAL job which you can do at home and increase your income. WE ISSUE PAY CHEQUES PROMPTLY ON THE FIRST OF THE EACH MONTH AND MAIL IT TO YOU. You don`t have to sell ANYTHING! You don`t have to recruit ANYBODY! You will only type for us (90%) and we will pay you. Job is simple and easy once you know how. There is no limit how much you can to do and how much you can to earn. You can work part/full time. For full time position Home Typist, US$ 3,500 each month is very possible. Request more info sending an email to : homejob@vdirect.com _________________________________________________ This message is sent in compliance of the new email bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, For remove click reply and type remove in subject line, your wishes will be honored. _________________________________________________ From list@netscape.com Sun Apr 8 20:05:40 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13138 for ; Sun, 8 Apr 2001 20:05:39 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3903XS19171; Sun, 8 Apr 2001 17:03:33 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3903Yo16735; Sun, 8 Apr 2001 17:03:34 -0700 (PDT) Resent-Date: Sun, 8 Apr 2001 17:03:34 -0700 (PDT) Date: Sun, 8 Apr 2001 17:03:17 -0700 (PDT) Message-Id: <200104090003.f3903GV26069@ywing.netscape.com> From: jmjessy1@themail.com To: Fellow@ywing.aoltw.net, Moneymaker.HOFC@netscape.com Subject: ARE YOU TIRED OF ALL THOSE GET RICH QUICK PROMISES?U X-Reply-To: jmjessy1@themail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lqCOQC.A.FFE.UxP06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit We don't promise quick riches but we do offer you a chance to make money with NO OUT OF POCKET expenses, NO Obligation, NO risk NOW is your opportunity to join a group that can help you make money without any financial investment EVER - just your time NOW is the time for you to join a winning group that wants to show you how to make money NOT spend money. For More Information: http://www.getpaid5times.com/?id=33005 Promote ONE site and cash in! Do you have multiple programs you promote? Do you want to make your advertising efforts more effective? Read on, I have the solution for you! Imagine advertising moneymaking programs of YOUR CHOICE, FOR FREE! Just 1 URL to promote! Yes 1 URL! So what are you waiting for? It's FREE and It's HOT! http://www.getpaid5times.com/?id=33005 Your email address is on a mailing list we purchased online. If you want your address removed from this list please hit reply and put the word "Remove" in the subject line. Your address will be removed from this purchased list, thank you. **************************************************************** Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. **************************************************************** From list@netscape.com Sun Apr 8 21:18:11 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13322 for ; Sun, 8 Apr 2001 21:18:11 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f391G5v20435; Sun, 8 Apr 2001 18:16:05 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f391G6k01870; Sun, 8 Apr 2001 18:16:06 -0700 (PDT) Resent-Date: Sun, 8 Apr 2001 18:16:06 -0700 (PDT) To: travel992@msn.com Reply-To: travel992@msn.com MIME-Version: 1.0 X-Encoding: MIME Content-Type: multipart/alternative; boundary="----=_NextPart_2383478537356347508630081223" From: travel992@msn.com Message-Id: <748kjh42623j0dj58t.0baf5lejx@VTRIPINFO> Date: Sun, 08 Apr 2001 18:18:57 -0800 X-Mailer: travel992@msn.com Subject: Congratulations you won Resent-Message-ID: <"ABTIHD.A.0c.V1Q06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. ------=_NextPart_2383478537356347508630081223 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT ------=_NextPart_2383478537356347508630081223 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You signed up back in May for our free cruise tickets for two

You signed up back in May for our free Vacation Packages for two. Congratulations you won,
one of our free Vacation Packages. Your tickets will be delivered to you within 7-10 days via US Mail. You must click on the link below and fill out = the information exactly as it will appear on your tickets. You may leave the = second party blank if you are not sure who will be going with you but you must = contact us via telephone at least 10 days prior to departure with the second = passenger's name. This will all be explained to you in the brochures coming out to you. = If you have any questions contact me via e-mail at cuisewinner@hotmail.com. = Please keep in mind
that there are 50 winners of this trip and it might take me a little while to get back to you.


Thanks Pete

Please Click Here

 

 

 

To Be Removed Please Respond With A Blank Email.

------=_NextPart_2383478537356347508630081223-- From list@netscape.com Mon Apr 9 03:23:18 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01342 for ; Mon, 9 Apr 2001 03:23:18 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f397L9S15579; Mon, 9 Apr 2001 00:21:09 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f397LBo26369; Mon, 9 Apr 2001 00:21:11 -0700 (PDT) Resent-Date: Mon, 9 Apr 2001 00:21:11 -0700 (PDT) Date: Mon, 9 Apr 2001 00:20:50 -0700 (PDT) Message-Id: <200104090720.f397KnV23083@ywing.netscape.com> From: mailcoaust@optusnet.com.au To: ietf-ldapext@netscape.com Subject: ietf-ldapext, thank you for your time X-Reply-To: moneyonline02@prontomail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"1Tw_P.A.lbG.mLW06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit THE MASSIVE GERMAN LOTTERY ! You've heard of it, NOW GET IN IT TO WIN !! WARNING: Listening to our FREE 7 Minute Online Message Could Make You RICH!!Become More Wealthy Than You Can Imagine! Everyone knows about and wants to play the German Lotto. We will show you how to OWN Your own AGENCY... FREE ! Now, YOU will get credit for all the sales and earn HUGE co mmissions. YOU can earn a HUGE amount per month beginning Your very FIRST MONTH and can also qualify for a gigantic BONUS!.. Plus full 24 hour support! Do we have your attention yet? Want the facts? http://www.lottoteam21.com/21011295 Go and LISTEN NOW ! >>> U.S.A. (918)222-7393 pin# 119... to hear the message Under Bill S.1618 TITLE III passed by the 105th U.S. Congress this message can't be considered Spam as long as I include a way to be removed. To be removed from future mailings, simply reply to this email with the word "REMOVE" in the subject line. Not following these instructions exactly will not get you removed automatically. Do Not incriminate your self by reporting a faulty Spam complaint if you have not attempted to get removed first. From list@netscape.com Mon Apr 9 05:00:19 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01812 for ; Mon, 9 Apr 2001 05:00:14 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f398uJS22757; Mon, 9 Apr 2001 01:56:20 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f398uMs21683; Mon, 9 Apr 2001 01:56:22 -0700 (PDT) Resent-Date: Mon, 9 Apr 2001 01:56:22 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3AD17909.4E414D8E@Sun.COM> Date: Mon, 09 Apr 2001 10:55:37 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: Paul Leach , ietf-ldapext@netscape.com Subject: Re: IP Address in the ACM (Was: Comments onAccessControlModel- BNF) References: <5.0.2.1.0.20010404130816.00b02a10@127.0.0.1> <5.0.2.1.0.20010405074208.01f6e7a0@127.0.0.1> <5.0.2.1.0.20010405083950.01f6a670@127.0.0.1> <5.0.2.1.0.20010406170456.01e667f0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"3pwcPD.A.ZSF.0kX06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt, True. The difference to me though is that "ipaddress" is a perfectly well defined thing and so there is no a priori reason to make it optional. This is not true of all subjects. For example a "role" is still undefined, so it is natural that some servers might not support it. Similarly for the case of SASL mechanisms--some implementations might not have gotten around to implementing some of the mechanisms. In these cases there is nothing we can do. However, by not making ipaddress optional we are ensuring that we do not add, unecessarily, to these kind of grey areas of the model. Rob. "Kurt D. Zeilenga" wrote: > > Robert, > > Given that the document allows additional subjects, there are > already interoperability issues of the nature you seem to be > concerned with. If someone specified a "foo" subject to a > server that doesn't support the "foo" subject, an error should > be returned. That ensures the client understands this server > doesn't support the "foo" subject. How is that different for > the server returning a error for the IP-Address subject? > > Kurt From list@netscape.com Mon Apr 9 09:50:13 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06815 for ; Mon, 9 Apr 2001 09:50:12 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f39Dm0v19906; Mon, 9 Apr 2001 06:48:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f39Dm1c03489; Mon, 9 Apr 2001 06:48:01 -0700 (PDT) Resent-Date: Mon, 9 Apr 2001 06:48:01 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3AD1BD67.4DF8D55D@Sun.COM> Date: Mon, 09 Apr 2001 15:47:19 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: Authentication Levels for ACMs References: <5.0.2.1.0.20010405131842.01f4fec0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"4yoyK.A.H2.P2b06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt, I quite like this approach. First, as you say it's easier to understand and goes to the heart of what authentication is about, namely, how strong is my belief that this requestor is who he claims to be. In addition, without an ordering on authentication mechanisms you are obliged to manage the the authnlevel keyword in a "pointlike" way. In other words, an aci that granted rights to subjects with an authnlevel of "sasl: digest-md5", for example, would not automatically grant rights to requestors authenticated with stronger technologies like, say ssl, when in fact that would seem to be the right thing. I suspect that as the number of authentication methods supported by your implementation grows, the more important it would become to be able to take advantage of this kind of relation between mechanisms. The disadvantage, mitigated by your recommendation proposal, is that the ordering is somewhat arbitrary. I think we need to help further by advertising the mechanisms which belong to the different categories somewhere--say in the same place where we advertise the suppported accessControlSchemes in the naming context. I think this would be important for replication where one server might well wish to verify consistency of categories with another server before concluding a replication agreement. I would like to see your recommended categorisation. Is your plan that this would be a seperate document ? Rob. "Kurt D. Zeilenga" wrote: > > Here is how I suggest authentication levels be described: > > LDAP supports numerous authentication methods and which offer > a wide range of security protections. Some methods support > multiple mechanisms. > > The strength of each mechanism can depend on many variables. > While it is possible to develop an access control factor which > is a parameterization of the methods, mechanisms, and other > variables; practical use of such a factor would be limited. > > The average directory administrator (or user) has no clue as > to what strength (or level) of authentication of a > parameterazation like: 'SASL/EXTERNAL/TLS/GSSAPI' or > 'SIMPLE/TLS/X.509' implied. The average directory administrator > (and user) can understand simple terms like "weak" and "strong". > > It is possible to define a small set of terms in a general > manner allowing for uses of particular mechanisms to be > categorized. > > The following authentication levels (in increasing order > of strength) "unauthenticated", "weak", "limited", and "strong" > based using terminology defined in [RFC 2828]. > > The "unauthenticated" level implies an anonymous authentication > association. > > The "weak" level implies that the authentication mechanism > is prone to both passive and active attacks. > > The "limited" level implies that the authentication is > protects against passive attacks but may be prone to > active attacks. > > The "strong" level implies the authentication mechanism > protects against both passive and active attacks. > > A RECOMMENDED categorization is offered separately. For > each mechanism categorized in the recommendation, > implementations SHOULD NOT assign a higher authentication > level but MAY assign a lower authentication level. For > mechanisms not covered by the recommendation, the implementation > SHOULD a conservative level. Implementations SHOULD provide > a means for the directory administrator for disabling mechanisms > and/or lowering the authentication level associated with a > mechanism. > > ---- > > I would be willing to provide the RECOMMENDED categorization > if the consensus of this WG is to pursue this. > > Kurt From list@netscape.com Mon Apr 9 13:14:40 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12066 for ; Mon, 9 Apr 2001 13:14:39 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f39HBOS20062; Mon, 9 Apr 2001 10:11:25 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f39HBP606661; Mon, 9 Apr 2001 10:11:25 -0700 (PDT) Resent-Date: Mon, 9 Apr 2001 10:11:25 -0700 (PDT) Message-Id: <5.0.2.1.0.20010409101036.00a9f170@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 09 Apr 2001 10:13:43 -0700 To: robert byrne From: "Kurt D. Zeilenga" Subject: Re: Authentication Levels for ACMs Cc: ietf-ldapext@netscape.com In-Reply-To: <3AD1BD67.4DF8D55D@Sun.COM> References: <5.0.2.1.0.20010405131842.01f4fec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"9gPY3C.A.nnB.70e06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 03:47 PM 4/9/01 +0200, robert byrne wrote: >I would like to see your recommended categorisation. Is your plan that >this would be a seperate document ? My suggestion, if the consensus is to adopt this proposal, would be to include the categorization in the ACM I-D itself. Kurt From list@netscape.com Mon Apr 9 13:21:23 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12235 for ; Mon, 9 Apr 2001 13:21:22 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f39HJGS21851; Mon, 9 Apr 2001 10:19:17 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f39HJGg11254; Mon, 9 Apr 2001 10:19:16 -0700 (PDT) Resent-Date: Mon, 9 Apr 2001 10:19:16 -0700 (PDT) Message-Id: <5.0.2.1.0.20010409094802.00a9c360@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 09 Apr 2001 10:21:41 -0700 To: robert byrne From: "Kurt D. Zeilenga" Subject: Re: IP Address in the ACM (Was: Comments onAccessControlModel- BNF) Cc: ietf-ldapext@netscape.com In-Reply-To: <3AD17909.4E414D8E@Sun.COM> References: <5.0.2.1.0.20010404130816.00b02a10@127.0.0.1> <5.0.2.1.0.20010405074208.01f6e7a0@127.0.0.1> <5.0.2.1.0.20010405083950.01f6a670@127.0.0.1> <5.0.2.1.0.20010406170456.01e667f0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"vlqkJD.A.RvC.T8e06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Robert, I think we're going to have to agree to disagree on this one. To ensure that is no confusion as to my position, I'll reiterate it. I object to a MUST (or SHOULD) for the ipAddress and DNS name based subjects as I believe it inappropriate to mandate (or recommend) the implementation of easily spoofed subjects. It my opinion that these subjects should either be completely removed (my preference) or made OPTIONAL. If made OPTIONAL, the document should contain a detailed explanation of the security considerations associated with the use of these subject. Kurt From list@netscape.com Mon Apr 9 13:47:30 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12968 for ; Mon, 9 Apr 2001 13:47:29 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f39Hi7v25802; Mon, 9 Apr 2001 10:44:07 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f39Hi7U21805; Mon, 9 Apr 2001 10:44:07 -0700 (PDT) Resent-Date: Mon, 9 Apr 2001 10:44:07 -0700 (PDT) Importance: Normal Subject: Re: anonymous & none in the ACM (Was: Comments Access Control Model - authentication levels 2) To: ietf-ldapext@netscape.com From: George_Robert_Blakley_III@tivoli.com Date: Mon, 9 Apr 2001 12:47:35 -0500 Message-ID: X-MIMETrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at 04/09/2001 12:43:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"qcvkNC.A.wSF.hTf06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Just to add fuel to the fire, >I think we need to decide first whether we are distinguishing >authentication methods (none, simple, sasl), authentication >mechanisms (none, simple/anonymous, simple/unauthenticated, >simple/authenticated,sasl/digest-md5,sasl/external) or >authentication levels? >"simple" and "sasl" are not authentication levels, but >authentication methods. Each has multiple mechanisms. >Each mechanism offers different level of authentication >which may depend on other factors (such as transport >layer security). >I see little value in supporting authentication methods >in the ACM, however an argument could be made for specific >authentication mechanisms. >Personally, I see much more value in adding authentication >level support. I think one can define simple levels like: >"unauthenticated", "weak", "protected", "strong" in a >useful and a fairly unambiguous manner. Frankly I really don't know what "authentication level" means. It *might* mean something like "strength of authentication mechanism", though of course we don't really know how strong they are until they get broken. Another possibility, and one I hear frequently from customers, might be called "authentication mechanism types" -- that is none shared secret over unprotected session shared secret over protected session token cryptographic smartcard biometric Customers often want to base policies on which (or which combinations) of these is used. In general authentication based on either strength or mechanism of authentication is a frequently encountered requirement but can be very complicated to implement depending on the level of assurance required and the customer's specific policy. --bob Bob Blakley Chief Scientist Enterprise Solutions Unit Tivoli Systems, Inc. (an IBM Company) From list@netscape.com Mon Apr 9 13:51:25 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13075 for ; Mon, 9 Apr 2001 13:51:25 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f39HmZS27592; Mon, 9 Apr 2001 10:48:36 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f39HmaY25898; Mon, 9 Apr 2001 10:48:36 -0700 (PDT) Resent-Date: Mon, 9 Apr 2001 10:48:36 -0700 (PDT) Importance: Normal Subject: Re: anonymous & none in the ACM (Was: Comments Access Control Model - authentication levels 2) To: ietf-ldapext@netscape.com From: George_Robert_Blakley_III@tivoli.com Date: Mon, 9 Apr 2001 12:52:16 -0500 Message-ID: X-MIMETrack: Serialize by Router on SCHub/Tivoli Systems(Release 5.0.4a |July 24, 2000) at 04/09/2001 12:47:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"7f-QfC.A.EUG.yXf06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com All, >Just to try to close this one item, is there anyone who thinks we need >to differentiate in the ACM between, in the terms of Ellen's very last >BNF, "anonymous" and "none" ? >> authnLevel = "none" / ; from X.500: name but no password, >> same as LDAPBIS unauthenticated >> "anonymous" / ; from LDAP: no name and no password >Rick says he doesn't care, Kurt says X.500 says they are the same thing >(from an access control point of view). >They seem pretty similar to me. >If we do collapse them both then I would suggest "unauthenticated" as a >good name for this kind of authentication level--looks like that's >consistent with ldapbis teminology. X.500 was designed before privacy became an issue as big as it is today. Certainly "anonymous" and "unauthenticated" DO NOT mean the same thing in all cases -- for example if I use a debit (ATM) card at my grocery store, from the viewpoint of the store I am anonymous (they don't learn my identity, it isn't printed on the card, etc....), and yet I certainly am authenticated, as the holder of checking account number XXXXXXXXXXXXX before that account is debited (that's why I supply the PIN). In lots of cases it will be desirable to authenticate the user, or some attribute of the user, and then throw away the identity in order to preserve privacy. --bob Bob Blakley Chief Scientist Enterprise Solutions Unit Tivoli Systems, Inc. (an IBM Company) From list@netscape.com Mon Apr 9 14:21:46 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13554 for ; Mon, 9 Apr 2001 14:21:46 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f39IJeS04399; Mon, 9 Apr 2001 11:19:40 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f39IJes15586; Mon, 9 Apr 2001 11:19:40 -0700 (PDT) Resent-Date: Mon, 9 Apr 2001 11:19:40 -0700 (PDT) Message-Id: <5.0.2.1.0.20010409111552.00aa1690@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 09 Apr 2001 11:21:29 -0700 To: George_Robert_Blakley_III@tivoli.com From: "Kurt D. Zeilenga" Subject: Re: anonymous & none in the ACM (Was: Comments Access Control Model - authentication levels 2) Cc: ietf-ldapext@netscape.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"q7HdnB.A.CzD.60f06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:52 PM 4/9/01 -0500, George_Robert_Blakley_III@tivoli.com wrote: >X.500 was designed before privacy became an issue as big as it is today. >Certainly "anonymous" and "unauthenticated" DO NOT mean the same thing >in all cases -- for example if I use a debit (ATM) card at my grocery >store, from >the viewpoint of the store I am anonymous (they don't learn my identity, Actually, the store does know your name... it might even be printed on your receipt... my local store actually makes a point in thanking customers by name after they use their bank card. Kurt From list@netscape.com Mon Apr 9 14:53:28 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14153 for ; Mon, 9 Apr 2001 14:53:27 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f39InJv08699; Mon, 9 Apr 2001 11:49:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f39InKs02617; Mon, 9 Apr 2001 11:49:20 -0700 (PDT) Resent-Date: Mon, 9 Apr 2001 11:49:20 -0700 (PDT) Message-Id: <5.0.2.1.0.20010409114144.00aa6ec0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 09 Apr 2001 11:51:42 -0700 To: robert byrne From: "Kurt D. Zeilenga" Subject: Re: Authentication Levels for ACMs Cc: ietf-ldapext@netscape.com In-Reply-To: <5.0.2.1.0.20010409101036.00a9f170@127.0.0.1> References: <3AD1BD67.4DF8D55D@Sun.COM> <5.0.2.1.0.20010405131842.01f4fec0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"MV8p-D.A.Vo.uQg06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 10:13 AM 4/9/01 -0700, Kurt D. Zeilenga wrote: >At 03:47 PM 4/9/01 +0200, robert byrne wrote: >>I would like to see your recommended categorisation. Is your plan that >>this would be a seperate document ? > >My suggestion, if the consensus is to adopt this proposal, would >be to include the categorization in the ACM I-D itself. On second thought, if there is consensus to adopt such a proposal, I might be inclined to write an LDAP-neutral document (BCP?) categorizing authentication levels which could be referenced by the LDAP (and other) ACMs. Kurt From list@netscape.com Mon Apr 9 21:58:21 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22111 for ; Mon, 9 Apr 2001 21:58:21 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3A1rsS25782; Mon, 9 Apr 2001 18:53:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3A1ruI05866; Mon, 9 Apr 2001 18:53:56 -0700 (PDT) Resent-Date: Mon, 9 Apr 2001 18:53:56 -0700 (PDT) Message-ID: From: "Ramsay, Ron" To: "Kurt D. Zeilenga" , George_Robert_Blakley_III@tivoli.com Cc: ietf-ldapext@netscape.com Subject: RE: anonymous & none in the ACM (Was: Comments Access Control Mod el - authentication levels 2) Date: Tue, 10 Apr 2001 11:53:36 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"grY8z.A.QbB.yem06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Isn't the store knowing your name actually a red herring? Who have you authenticated to? The store? No, the bank. And you authenticated with name AND password. Ron. -----Original Message----- From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] Sent: Tuesday, 10 April 2001 4:21 To: George_Robert_Blakley_III@tivoli.com Cc: ietf-ldapext@netscape.com Subject: Re: anonymous & none in the ACM (Was: Comments Access Control Model - authentication levels 2) At 12:52 PM 4/9/01 -0500, George_Robert_Blakley_III@tivoli.com wrote: >X.500 was designed before privacy became an issue as big as it is today. >Certainly "anonymous" and "unauthenticated" DO NOT mean the same thing >in all cases -- for example if I use a debit (ATM) card at my grocery >store, from >the viewpoint of the store I am anonymous (they don't learn my identity, Actually, the store does know your name... it might even be printed on your receipt... my local store actually makes a point in thanking customers by name after they use their bank card. Kurt From list@netscape.com Tue Apr 10 01:29:22 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27702 for ; Tue, 10 Apr 2001 01:29:22 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3A5RFS12624; Mon, 9 Apr 2001 22:27:15 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3A5RH603568; Mon, 9 Apr 2001 22:27:17 -0700 (PDT) Resent-Date: Mon, 9 Apr 2001 22:27:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IP Address in the ACM (Was: Comments onAccessControlModel- BNF) Date: Mon, 9 Apr 2001 22:27:06 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C0762657406005CFC@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: IP Address in the ACM (Was: Comments onAccessControlModel- BNF) Thread-Index: AcDBGlCdAOHVw1jISZCgGJrLEsKezQAXEFJg From: "Paul Leach" To: "Kurt D. Zeilenga" , "robert byrne" Cc: X-OriginalArrivalTime: 10 Apr 2001 05:27:07.0572 (UTC) FILETIME=[E274CF40:01C0C17E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id f3A5RDf03538 Resent-Message-ID: <"DKV9VC.A.Y3.ymp06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit I agree with Kurt. There is no reason why such a feature needs to be promulgated today -- many stronger mechanisms are readily available. > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Monday, April 09, 2001 10:22 AM > To: robert byrne > Cc: ietf-ldapext@netscape.com > Subject: Re: IP Address in the ACM (Was: Comments > onAccessControlModel- BNF) > > > Robert, > > I think we're going to have to agree to disagree on this one. > > To ensure that is no confusion as to my position, I'll reiterate it. > > I object to a MUST (or SHOULD) for the ipAddress and DNS name > based subjects as I believe it inappropriate to mandate (or > recommend) the implementation of easily spoofed subjects. It > my opinion that these subjects should either be completely > removed (my preference) or made OPTIONAL. If made OPTIONAL, > the document should contain a detailed explanation of the > security considerations associated with the use of these subject. > > Kurt > > From list@netscape.com Tue Apr 10 02:59:54 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09008 for ; Tue, 10 Apr 2001 02:59:53 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3A5d2S13680; Mon, 9 Apr 2001 22:39:02 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3A5d4A06337; Mon, 9 Apr 2001 22:39:04 -0700 (PDT) Resent-Date: Mon, 9 Apr 2001 22:39:04 -0700 (PDT) X-Lotus-FromDomain: POLAR BEAR TECH From: mrklp@hotmail.com Reply-To: t3m1@bigfoot.com To: ebjtg.Onlinefriends@pbsc.ca Message-ID: <85256A28.000BEEE6.00@r4.pbsc.ca> Date: Sat, 7 Apr 2001 22:31:05 -0400 Subject: Computer Training Simplified for EveryOne! [uqith] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"fIUWzC.A.PiB.1xp06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Why you need this??? (The Left Team is the Power Leg) (half your efforts are done) -------------------------------------------- It is definately apparent that it is already a huge success. Thousands of leaders have flocked to the business, many of them entering our organization. ---------------------------------------------- Why is it attracting so many leaders? The obvious answers have to do with timing, track record, and positioning. There is a far bigger reason, however, and it may not be as obvious to everyone........ ----------------------------------------------- "The single most important factor in a network business is NOT how many people you can recruit. It's how easily the people you recruit can recruit others." ----------------------------------------------- Many of the people you recruit will NOT have your experience and marketing skills. With THIS, they don't need your skills to be successful! ------------------------------------------------ This is the secret : We're marketing an EDUCATIONAL product that's needed and only costs $100 ~ for an entire year !!! Live, interactive computer and Internet courses! In 7 languages...... to start. More to come! (LIKE A FLIGHT SIMULATOR) ------------------------------------------------ Everybody knows at least two people that have fear and no knowledge about the computer. Is it hard to qualify for commissions? NO ! Sponsor two (one in each leg) and you are qualified for life! ----------------------------------------------- Practically anyone can sell a $100 deal! If a person can't sell this to others, what can they sell? Just mention this to a few people and you will immediatly get a response to the educational training. There is no program out there with an easier product to market. I would suggest that the people you put into this program have a far better chance of success than in any other program they might join. ------------------------------------------------- What does this mean for you? ~ Duplication and Momentum. Now is the time for leaders to get in, get qualified, and get going !!! ------------------------------------------------- Why not consider joining our team.... we are right at the beginning of our launch... This is the one and only program out there that will "Teach the World" how to use the computer! For detailed info, just put "Computer Training Info" in the subject. mailto:sam20u2@n2mail.com?subject=Computer_Training_Info Waiting to hear from you soon! Lee From list@netscape.com Tue Apr 10 03:52:18 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09466 for ; Tue, 10 Apr 2001 03:52:17 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3A7gqS22809; Tue, 10 Apr 2001 00:42:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3A7gsQ02461; Tue, 10 Apr 2001 00:42:54 -0700 (PDT) Resent-Date: Tue, 10 Apr 2001 00:42:54 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3AD2B956.2F358310@Sun.COM> Date: Tue, 10 Apr 2001 09:42:14 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paul Leach CC: "Kurt D. Zeilenga" , ietf-ldapext@netscape.com Subject: Re: IP Address in the ACM (Was: Comments onAccessControlModel- BNF) References: <5B90AD65A9E8934987DB0C8C0762657406005CFC@DF-BOWWOW.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"kFiYWC.A.Dm.9lr06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt/Paul, Fair enough... To restate my own position: "security" depends on the environment--there will be environments where things like public access, simple authentication and ip address based access controls will be both acceptable and desirable. Removing such things from the ACM is a disservice to users in those environments and making them optional introduces an unecessary "point of non-interoperability" to the model. Rob. Paul Leach wrote: > > I agree with Kurt. There is no reason why such a feature needs to be > promulgated today -- many stronger mechanisms are readily available. > > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > Sent: Monday, April 09, 2001 10:22 AM > > To: robert byrne > > Cc: ietf-ldapext@netscape.com > > Subject: Re: IP Address in the ACM (Was: Comments > > onAccessControlModel- BNF) > > > > > > Robert, > > > > I think we're going to have to agree to disagree on this one. > > > > To ensure that is no confusion as to my position, I'll reiterate it. > > > > I object to a MUST (or SHOULD) for the ipAddress and DNS name > > based subjects as I believe it inappropriate to mandate (or > > recommend) the implementation of easily spoofed subjects. It > > my opinion that these subjects should either be completely > > removed (my preference) or made OPTIONAL. If made OPTIONAL, > > the document should contain a detailed explanation of the > > security considerations associated with the use of these subject. > > > > Kurt > > > > From list@netscape.com Tue Apr 10 04:02:53 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09553 for ; Tue, 10 Apr 2001 04:02:52 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3A80mS24395; Tue, 10 Apr 2001 01:00:49 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3A80ok07083; Tue, 10 Apr 2001 01:00:50 -0700 (PDT) Resent-Date: Tue, 10 Apr 2001 01:00:50 -0700 (PDT) Date: Tue, 10 Apr 01 12:11:46 EST From: skym@hotmail.com To: Friend@public.com Subject: Make Over $100,000 Per Month!!!!!!!!!!! Message-ID: <> Resent-Message-ID: <"Coi7o.A.TuB.w2r06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Finally... make money at home and a Web~Site Opportunity that everyone can afford! will allow Families and Businesses to Communicate through the Unlimited Possibilities offered by the Internet. For the Low Cost of $100.00 (US) plus a $25.00 processing fee, your Family or Business can have a Personalized Web Site that you Create and Edit at your leisure, from the Comfort of your own Mouse (I mean House). SkyBiz 2000 has also created a Home Based Business Program (driven by the Retail Package, the 35 Meg (Unlimited Pages) Web~Site, that you can offer your Family, Friends and Businesses, where everyone can potentially profit from the Internet. Now is your chance to participate in this Global Explosion , utilizing the Internet. Never again will anyone have to miss another Important Event! If you would like to put your "Family or Business on The Web" Now is the time to do it! For the Low, Low price of $100.00 (US) plus a $25.00 processing fee, you will receive a 35 Meg (Unlimited Pages) Web~Site, Plenty of Web Site and Windows Education and Much Much More. and it will be a money machine too ,can make mony on line Please send me an email if you need more information, to skybiz0@mailcity.com regards webmaster From list@netscape.com Tue Apr 10 05:41:48 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10111 for ; Tue, 10 Apr 2001 05:41:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3A9dfS01272; Tue, 10 Apr 2001 02:39:41 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3A9dik00142; Tue, 10 Apr 2001 02:39:44 -0700 (PDT) Resent-Date: Tue, 10 Apr 2001 02:39:44 -0700 (PDT) Sender: michael@ms.inka.de Message-ID: <3AD2D4DF.C8DFFFD2@stroeder.com> Date: Tue, 10 Apr 2001 11:39:43 +0200 From: Michael =?iso-8859-1?Q?Str=F6der?= Reply-To: michael@stroeder.com Organization: stroeder.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: de-DE, de, en MIME-Version: 1.0 Cc: ietf-ldapext@netscape.com Subject: Re: IP Address in the ACM (Was: Comments onAccessControlModel- BNF) References: <5B90AD65A9E8934987DB0C8C0762657406005CFC@DF-BOWWOW.platinum.corp.microsoft.com> <3AD2B956.2F358310@Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"L3ORxC.A.zB.eTt06"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit robert byrne wrote: > > To restate my own position: "security" depends on the environment--there > will be environments where things like public access, simple > authentication and ip address based access controls will be both > acceptable and desirable. Removing such things from the ACM is a > disservice to users in those environments and making them optional > introduces an unecessary "point of non-interoperability" to the model. Yepp. Ciao, Michael. From list@netscape.com Tue Apr 10 05:42:48 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10126 for ; Tue, 10 Apr 2001 05:42:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3A9ejv26792; Tue, 10 Apr 2001 02:40:45 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3A9ej201042; Tue, 10 Apr 2001 02:40:45 -0700 (PDT) Resent-Date: Tue, 10 Apr 2001 02:40:45 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3AD2CEC2.CBE5120E@Sun.COM> Date: Tue, 10 Apr 2001 11:13:38 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: George_Robert_Blakley_III@tivoli.com CC: ietf-ldapext@netscape.com Subject: Re: anonymous & none in the ACM (Was: Comments Access Control Model -authentication levels 2) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"qLAzDC.A.1P.aUt06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Bob, I understand your use of the word "anonymous". However, that's not the way Ellen was using it in her BNF--it seems clear that by "anonymous" she means a requestor who is not authenticated at all, not that the requestor did authenticate but then had his identity thrown away. I guess the LDAP version of your store customer would be a requestor who authenticated using say SASL CRAM-MD5, but attached a proxy authorization control with an authorization identity of "". I think the ACM could probably accomodate such requestors with a subject like this: subject = authnlevel: sasl: DIGEST-MD5 : public In other words, for the purpose of evaluating this aci we do require the requestor to have authenticated using SASL DIGEST-MD5, but we do not require him to be authenticated with any _particular_ identity. Rob. George_Robert_Blakley_III@tivoli.com wrote: > > All, > > >Just to try to close this one item, is there anyone who thinks we need > >to differentiate in the ACM between, in the terms of Ellen's very last > >BNF, "anonymous" and "none" ? > > >> authnLevel = "none" / ; from X.500: name but no password, > >> same as LDAPBIS unauthenticated > >> "anonymous" / ; from LDAP: no name and no > password > > >Rick says he doesn't care, Kurt says X.500 says they are the same thing > >(from an access control point of view). > >They seem pretty similar to me. > > >If we do collapse them both then I would suggest "unauthenticated" as a > >good name for this kind of authentication level--looks like that's > >consistent with ldapbis teminology. > > X.500 was designed before privacy became an issue as big as it is today. > Certainly "anonymous" and "unauthenticated" DO NOT mean the same thing > in all cases -- for example if I use a debit (ATM) card at my grocery > store, from > the viewpoint of the store I am anonymous (they don't learn my identity, it > isn't printed > on the card, etc....), and yet I certainly am authenticated, as the holder > of checking account > number XXXXXXXXXXXXX before that account is debited (that's why I supply > the PIN). > > In lots of cases it will be desirable to authenticate the user, or some > attribute of the user, > and then throw away the identity in order to preserve privacy. > > --bob > > Bob Blakley > Chief Scientist > Enterprise Solutions Unit > Tivoli Systems, Inc. (an IBM Company) From list@netscape.com Tue Apr 10 06:36:11 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10477 for ; Tue, 10 Apr 2001 06:36:10 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3AAU3S05190; Tue, 10 Apr 2001 03:30:03 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3AAU6Q14652; Tue, 10 Apr 2001 03:30:06 -0700 (PDT) Resent-Date: Tue, 10 Apr 2001 03:30:06 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3AD2E085.EB36F8B9@Sun.COM> Date: Tue, 10 Apr 2001 12:29:25 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: Authentication Levels for ACMs References: <3AD1BD67.4DF8D55D@Sun.COM> <5.0.2.1.0.20010405131842.01f4fec0@127.0.0.1> <5.0.2.1.0.20010409114144.00aa6ec0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BlMZL.A.fkD.sCu06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt, That sounds better as it would be easier to update. Rob. "Kurt D. Zeilenga" wrote: > > At 10:13 AM 4/9/01 -0700, Kurt D. Zeilenga wrote: > >At 03:47 PM 4/9/01 +0200, robert byrne wrote: > >>I would like to see your recommended categorisation. Is your plan that > >>this would be a seperate document ? > > > >My suggestion, if the consensus is to adopt this proposal, would > >be to include the categorization in the ACM I-D itself. > > On second thought, if there is consensus to adopt such a proposal, > I might be inclined to write an LDAP-neutral document (BCP?) > categorizing authentication levels which could be referenced by > the LDAP (and other) ACMs. > > Kurt From list@netscape.com Tue Apr 10 09:36:59 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14670 for ; Tue, 10 Apr 2001 09:36:59 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3ADXRS18211; Tue, 10 Apr 2001 06:33:28 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3ADXSQ00679; Tue, 10 Apr 2001 06:33:28 -0700 (PDT) Resent-Date: Tue, 10 Apr 2001 06:33:28 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3AD30B81.BAFF93CD@Sun.COM> Date: Tue, 10 Apr 2001 15:32:49 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com Subject: browse permission in the ACM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"loQLy.A.NK.nuw06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit All, The following is a proposal to tweak the current browse permission in the ACM. The current usage of the "b" permission in the ACM is really just a read level permission on candidate entries. From section 5.2: " 1. permission "b" to the entry candidateDN If this permission is not granted then the dn candidateDN MUST NOT be returned nor any attribute type nor attribute value from this entry. If this permission is granted then the dn candidateDN MAY be returned. " Some people felt that it would be better to have it behave more like it's name suggests...which is that you would require this permission to be able to have a search request return __non-base__ entries to you during a search. The spirit of this idea is something like "Hang on, subtree and onelevel searches are really powerful, there should be a way continue to grant read access to entries, but to limit the power of these search options". One way to do this is to refine "b" into two permissions 'new "b"' and "v". The 'new "b"' still stands for browse and you will need this to see non-base entries. At a stretch the "v" stands for "vertex" as you need this to see the base entry (the vertex) of a search. (From now on "b" means 'new "b"'.) To minimize the number of combinations we also allow the base element to be seen if "b" permission is assigned to it. So, the new text I am proposing for this would be: " 1. permission "v" or "b" to the entry candidateDN, if the entry is the base of the search operation. permission "b" to the entry if the entry is not the base of the search. If these conditions are not satisfied then the dn candidateDN MUST NOT be returned nor any attribute type nor attribute value from this entry. If this permission is granted then the dn candidateDN MAY be returned." Note that the absence of a "v" or "b" permission at any point does not abort the search operation as a whole or even on a particular subtree. We could specify such behaviour but I believe most LDAP implementations have an "optimistic" approach to searching for entries ie. I may be denied access to this entry, but there may be other entries to which I do have access, so keep searching. Note also that if you only ever use "b", it will behave just like a read level permission on the entry--we provide the "v" refinement for those users that might want to limit "browsability" of their DIT. An example. Suppose that some given user has all rights on all these subtrees, the only difference being in allocation of the "b" and "v" rights which are shown in brackets, after the RDN of the entry. ou=sun.com(b) | |------------------------------------------------ | | | ou=sortOfBrowsable() ou=notBrowsable(v) ou=Browsable(b) | | | ou=level1(v) ou=level1(v) ou=level1(b) | | | ou=level2(b) ou=level2(v) ou=level2(b) Eg 1: If he does a search like this: baseEntry: ou=sortOfBrowsable,o=sun.com filter: ou=* scope: subtree He will get back the following entry: ou=level2,ou=sortOfBrowsable,ou=sun.com (has "b" on this) ----- Eg 2: Then, if he does a search like this: baseEntry: ou=sortOfBrowsable,o=sun.com filter: ou=* scope: base He will get back no entries (neither "v" nor "b" on the base). ----- Eg 3: If he does a search like this: baseEntry: ou=notBrowsable,ou=sun.com filter: ou=* scope: subtree He will get back the following entry: ou=notBrowsable,ou=sun.com (has "v" and it's the base) ----- Eg 4: If he does a search like this: baseEntry: ou=notBrowsable,ou=sun.com filter: ou=* scope: base He will get back the following entry: ou=notBrowsable,ou=sun.com (has "v" and it's the base) ----- Eg 5: Then, if he does a search like this: baseEntry: ou=Browsable,ou=sun.com filter: ou=* scope: subtree He will get back the following entries: ou=Browsable,ou=sun.com (has "b") ou=level1,ou=Browsable,ou=sun.com (has "b") ou=level2,ou=Browsable,ou=sun.com (has "b") ----- Eg 6: Then, if he does a search like this: baseEntry: ou=Browsable,ou=sun.com filter: ou=* scope: base He will get back the following entries: ou=Browsable,ou=sun.com (has "b") ----- Eg 7: Then, if he does a search like this: baseEntry: ou=sun.com filter: ou=* scope: onelevel He will get back the following entries: ou=Browsable,ou=sun.com (has "b") ----- Any comments on this modification ? Rob. From list@netscape.com Tue Apr 10 11:56:50 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19160 for ; Tue, 10 Apr 2001 11:56:49 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3AFADv25214; Tue, 10 Apr 2001 08:10:14 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3AFADE07378; Tue, 10 Apr 2001 08:10:13 -0700 (PDT) Resent-Date: Tue, 10 Apr 2001 08:10:13 -0700 (PDT) Date: Tue, 10 Apr 2001 11:10:03 -0400 Message-Id: <200104101510.LAA24387@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldapext@netscape.com, robert.byrne@Sun.COM Subject: Re: browse permission in the ACM Resent-Message-ID: <"7PRms.A.0yB.TJy06"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Since Rob says `To minimize the number of combinations we also allow the base element to be seen if "b" permission is assigned to it', it seems that the new "b" includes the new "v" and is identical to the old "b". So the real change here is the addition of the separate "v" permission. So I assume new the definitions of "b" and "v" in section 4.2.1 would be something like (trying to stay reasonably close to the current wording): b BrowseDN If granted, permits entries to be accessed using search operations regardless of whether they explicitly provide the name of the entry. v VertexDN If granted, permits entries to be accessed using search operations only if the name of the entry is explicitly supplied. I guess my main question is whether the change is worth it. The model is already rather complicated. Does this change provide value that is worth the additional complexity? I'm not sure that it does. And one other vaguely related question that came to mind after reading Rob's email. He notes that "... the absence of a "v" or "b" permission at any point does not abort the search operation as a whole or even on a particular subtree." I have been assuming (and this seemed like a good time to check) that absence of a "t" permission DOES abort the search operation on a particular subtree, since returning the DN of any object further down in the tree would require that the DN of the object without "t" permission be returned. Is that the generally accepted view? Rick Huber : Sender: Robert.Byrne@Sun.COM : From: robert byrne : To: ietf-ldapext@netscape.com : Subject: browse permission in the ACM : : : All, : : The following is a proposal to tweak the current browse permission in : the ACM. : The current usage of the "b" permission in the ACM is really just a read : level permission on candidate entries. From section 5.2: : : " 1. permission "b" to the entry candidateDN : : If this permission is not granted then the dn : candidateDN MUST NOT be returned nor any attribute : type nor attribute value from this entry. : : If this permission is granted then the dn candidateDN : MAY be returned. : " : : Some people felt that it would be better to have it behave more like : it's name suggests...which is that you would require this permission to : be able to have a search request return __non-base__ entries to you : during a search. The spirit of this idea is something like "Hang on, : subtree and onelevel searches are really powerful, there should be a : way continue to grant read access to entries, but to limit the power of : these search options". : : One way to do this is to refine "b" into two permissions 'new "b"' and : "v". : The 'new "b"' still stands for browse and you will need this to see : non-base entries. At a stretch the "v" stands for "vertex" as you need : this to see the base entry (the vertex) of a search. (From now on "b" : means 'new "b"'.) To minimize the : number of combinations we also allow the base element to be seen if "b" : permission is assigned to it. So, the new text I am proposing for this : would be: : : : " 1. permission "v" or "b" to the entry candidateDN, if the entry is : the : base of the search operation. : permission "b" to the entry if the entry is not the base of the : search. : : If these conditions are not satisfied then the dn : candidateDN MUST NOT be returned nor any attribute : type nor attribute value from this entry. : : If this permission is granted then the dn candidateDN : MAY be returned." : : Note that the absence of a "v" or "b" permission at any point does not : abort the search operation as a whole or even on a particular subtree. : We could specify such behaviour but I believe most LDAP implementations : have an "optimistic" approach to searching for entries ie. I may be : denied access to this entry, but there may be other entries to which I : do have access, so keep searching. : : Note also that if you only ever use "b", it will behave just like a read : level permission on the entry--we provide the "v" refinement for those : users that might want to limit "browsability" of their DIT. : : An example. Suppose that some given user has all rights on all : these subtrees, the only difference being in allocation of the "b" and : "v" rights which are shown in brackets, after the RDN of the entry. : : ou=sun.com(b) : | : |------------------------------------------------ : | | | : ou=sortOfBrowsable() ou=notBrowsable(v) ou=Browsable(b) : | | | : ou=level1(v) ou=level1(v) ou=level1(b) : | | | : ou=level2(b) ou=level2(v) ou=level2(b) : : : Eg 1: If he does a search like this: : : baseEntry: ou=sortOfBrowsable,o=sun.com : filter: ou=* : scope: subtree : : He will get back the following entry: : : ou=level2,ou=sortOfBrowsable,ou=sun.com (has "b" on this) : : ----- : : Eg 2: Then, if he does a search like this: : : baseEntry: ou=sortOfBrowsable,o=sun.com : filter: ou=* : scope: base : : He will get back no entries (neither "v" nor "b" on the base). : : ----- : : Eg 3: If he does a search like this: : : baseEntry: ou=notBrowsable,ou=sun.com : filter: ou=* : scope: subtree : : He will get back the following entry: : : ou=notBrowsable,ou=sun.com (has "v" and it's the base) : : ----- : : : Eg 4: If he does a search like this: : : baseEntry: ou=notBrowsable,ou=sun.com : filter: ou=* : scope: base : : He will get back the following entry: : : ou=notBrowsable,ou=sun.com (has "v" and it's the base) : : ----- : : : Eg 5: Then, if he does a search like this: : : baseEntry: ou=Browsable,ou=sun.com : filter: ou=* : scope: subtree : : He will get back the following entries: : ou=Browsable,ou=sun.com (has "b") : ou=level1,ou=Browsable,ou=sun.com (has "b") : ou=level2,ou=Browsable,ou=sun.com (has "b") : : ----- : : : Eg 6: Then, if he does a search like this: : : baseEntry: ou=Browsable,ou=sun.com : filter: ou=* : scope: base : : He will get back the following entries: : ou=Browsable,ou=sun.com (has "b") : : ----- : : : Eg 7: Then, if he does a search like this: : : baseEntry: ou=sun.com : filter: ou=* : scope: onelevel : : He will get back the following entries: : ou=Browsable,ou=sun.com (has "b") : : ----- : : Any comments on this modification ? : : Rob. From list@netscape.com Tue Apr 10 22:01:42 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01126 for ; Tue, 10 Apr 2001 22:01:41 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3B1xVv18911; Tue, 10 Apr 2001 18:59:31 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3B1xXg01600; Tue, 10 Apr 2001 18:59:33 -0700 (PDT) Resent-Date: Tue, 10 Apr 2001 18:59:33 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IP Address in the ACM (Was: Comments onAccessControlModel- BNF) Date: Tue, 10 Apr 2001 18:59:24 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C0762657406005D13@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: IP Address in the ACM (Was: Comments onAccessControlModel- BNF) Thread-Index: AcDBkn+/8r2InuEcSM+e39qpYELTIwAltRoA From: "Paul Leach" To: "robert byrne" Cc: "Kurt D. Zeilenga" , X-OriginalArrivalTime: 11 Apr 2001 01:59:25.0280 (UTC) FILETIME=[08C3B600:01C0C22B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id f3B1xVf01539 Resent-Message-ID: <"TwmxCD.A.JY.Dq706"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit I accept that there are environments where ip address and DNS name are acceptable. However: 1. they aren't even close to the majority of environments 2. there are more cases where it isn't appropriate and it will get used thinking it is secure, leading to a false sense of security 3. better alternatives are easily available If there was no good alternative is some cases, then I could see leaving the features in. But good security is quite readily available, so there is no reason to settle for semi-security. Before I could acquiesce, I would want to see the security considerations that are proposed to go with the feature. I think they should include very dire warnings about how easy it is to defeat them, and descriptions of the environments where they can be safely used. Absent these, it would be irresponsible to bless such features with the words "RFC compliant" and the endorsement of the IETF. Also, I think it is entirely reasonable that some vendors decide that they don't want to serve the market where such features might be adequate, or wish to serve it by offering stronger mechanisms. In any case, interoperability is better ensured by having smaller feature sets, not by trying to use "mandatory to implement" to force implementation of large feature sets. > -----Original Message----- > From: robert byrne [mailto:robert.byrne@Sun.COM] > Sent: Tuesday, April 10, 2001 12:42 AM > To: Paul Leach > Cc: Kurt D. Zeilenga; ietf-ldapext@netscape.com > Subject: Re: IP Address in the ACM (Was: Comments > onAccessControlModel- BNF) > > > > Kurt/Paul, > > Fair enough... > > To restate my own position: "security" depends on the > environment--there will be environments where things like > public access, simple authentication and ip address based > access controls will be both acceptable and desirable. > Removing such things from the ACM is a disservice to users in > those environments and making them optional introduces an > unecessary "point of non-interoperability" to the model. > > Rob. > > Paul Leach wrote: > > > > I agree with Kurt. There is no reason why such a feature > needs to be > > promulgated today -- many stronger mechanisms are readily available. > > > > > -----Original Message----- > > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > > Sent: Monday, April 09, 2001 10:22 AM > > > To: robert byrne > > > Cc: ietf-ldapext@netscape.com > > > Subject: Re: IP Address in the ACM (Was: Comments > > > onAccessControlModel- BNF) > > > > > > > > > Robert, > > > > > > I think we're going to have to agree to disagree on this one. > > > > > > To ensure that is no confusion as to my position, I'll > reiterate it. > > > > > > I object to a MUST (or SHOULD) for the ipAddress and DNS > name based > > > subjects as I believe it inappropriate to mandate (or > > > recommend) the implementation of easily spoofed subjects. It my > > > opinion that these subjects should either be completely > removed (my > > > preference) or made OPTIONAL. If made OPTIONAL, the > document should > > > contain a detailed explanation of the security considerations > > > associated with the use of these subject. > > > > > > Kurt > > > > > > > > From list@netscape.com Wed Apr 11 06:31:13 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19603 for ; Wed, 11 Apr 2001 06:31:13 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3BARMS29398; Wed, 11 Apr 2001 03:27:22 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3BARP228952; Wed, 11 Apr 2001 03:27:25 -0700 (PDT) Resent-Date: Wed, 11 Apr 2001 03:27:25 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3AD43163.78E8FA8F@Sun.COM> Date: Wed, 11 Apr 2001 12:26:43 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Richard V Huber CC: ietf-ldapext@netscape.com Subject: Re: browse permission in the ACM References: <200104101510.LAA24387@qsun.mt.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lYM28.A.AEH.LGD16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Rick, Maybe now is a good time to list the options (that I can think of) open to us for this browsing concept: 1. Keep it as is in section 5.2, so that "b" is just an entry-level permission you need on all entries when you search. 2. Drop it entirely, so that we have no dedicated entry-level permission on search. For example, we don't have an entry-level Modify permission. In this model, we would be relying on the returnDn permission for entry-level protection. I guess "entry-level protection" of an entry in the context of search means protecting the dn so this seems to make sense. 3. Keep "b" but only require it on non-base entries. This means that you can control the power of the subtree and onelevel search options on your DIT. 4. Keep "b" but only require it on non-base entries AND introduce a "v" which you are now required to see base entries of searches. This means that you can control the power of the subtree and onelevel search options on your DIT AND allows you to explicitly protect bases of searches at the entry level. 5. As 4. but have "b"=>"v", so that if you want you can forget about "v" and just use "b" as in 1. This is what I proposed in my earlier mail. I agree that it is not worth complicating things for this browsing capability. Given this, if people like the ability to put a brake on the subtree and onelevel options (I guess the use of these options is what we mean by "browsing" in LDAP), I'm tempted to propose 3. as the simplest option. After that if we consider that controling browsing is not important, I'm tempted by 2., namely dropping "b" entirely...though we'd need to check that this doesn't leave some holes. Any votes/opinions on these options ? Rick, for your other point on aborting searches re the returnDn permission, I would prefer to discuss that in a different thread called something like "protecting dns in the ACM", as I think it desreves a discussion itself. Rob. Richard V Huber wrote: > > Since Rob says `To minimize the number of combinations we also allow > the base element to be seen if "b" permission is assigned to it', it > seems that the new "b" includes the new "v" and is identical to the old > "b". So the real change here is the addition of the separate "v" > permission. > > So I assume new the definitions of "b" and "v" in section 4.2.1 would > be something like (trying to stay reasonably close to the current > wording): > > b BrowseDN > > If granted, permits entries to be accessed using search operations > regardless of whether they explicitly provide the name of the entry. > > v VertexDN > > If granted, permits entries to be accessed using search operations > only if the name of the entry is explicitly supplied. > > I guess my main question is whether the change is worth it. The model > is already rather complicated. Does this change provide value that is > worth the additional complexity? I'm not sure that it does. > > And one other vaguely related question that came to mind after reading > Rob's email. He notes that "... the absence of a "v" or "b" permission > at any point does not abort the search operation as a whole or even on > a particular subtree." > > I have been assuming (and this seemed like a good time to check) that > absence of a "t" permission DOES abort the search operation on a > particular subtree, since returning the DN of any object further down > in the tree would require that the DN of the object without "t" > permission be returned. Is that the generally accepted view? > > Rick Huber > > : Sender: Robert.Byrne@Sun.COM > : From: robert byrne > : To: ietf-ldapext@netscape.com > : Subject: browse permission in the ACM > : > : > : All, > : > : The following is a proposal to tweak the current browse permission in > : the ACM. > : The current usage of the "b" permission in the ACM is really just a read > : level permission on candidate entries. From section 5.2: > : > : " 1. permission "b" to the entry candidateDN > : > : If this permission is not granted then the dn > : candidateDN MUST NOT be returned nor any attribute > : type nor attribute value from this entry. > : > : If this permission is granted then the dn candidateDN > : MAY be returned. > : " > : > : Some people felt that it would be better to have it behave more like > : it's name suggests...which is that you would require this permission to > : be able to have a search request return __non-base__ entries to you > : during a search. The spirit of this idea is something like "Hang on, > : subtree and onelevel searches are really powerful, there should be a > : way continue to grant read access to entries, but to limit the power of > : these search options". > : > : One way to do this is to refine "b" into two permissions 'new "b"' and > : "v". > : The 'new "b"' still stands for browse and you will need this to see > : non-base entries. At a stretch the "v" stands for "vertex" as you need > : this to see the base entry (the vertex) of a search. (From now on "b" > : means 'new "b"'.) To minimize the > : number of combinations we also allow the base element to be seen if "b" > : permission is assigned to it. So, the new text I am proposing for this > : would be: > : > : > : " 1. permission "v" or "b" to the entry candidateDN, if the entry is > : the > : base of the search operation. > : permission "b" to the entry if the entry is not the base of the > : search. > : > : If these conditions are not satisfied then the dn > : candidateDN MUST NOT be returned nor any attribute > : type nor attribute value from this entry. > : > : If this permission is granted then the dn candidateDN > : MAY be returned." > : > : Note that the absence of a "v" or "b" permission at any point does not > : abort the search operation as a whole or even on a particular subtree. > : We could specify such behaviour but I believe most LDAP implementations > : have an "optimistic" approach to searching for entries ie. I may be > : denied access to this entry, but there may be other entries to which I > : do have access, so keep searching. > : > : Note also that if you only ever use "b", it will behave just like a read > : level permission on the entry--we provide the "v" refinement for those > : users that might want to limit "browsability" of their DIT. > : > : An example. Suppose that some given user has all rights on all > : these subtrees, the only difference being in allocation of the "b" and > : "v" rights which are shown in brackets, after the RDN of the entry. > : > : ou=sun.com(b) > : | > : |------------------------------------------------ > : | | | > : ou=sortOfBrowsable() ou=notBrowsable(v) ou=Browsable(b) > : | | | > : ou=level1(v) ou=level1(v) ou=level1(b) > : | | | > : ou=level2(b) ou=level2(v) ou=level2(b) > : > : > : Eg 1: If he does a search like this: > : > : baseEntry: ou=sortOfBrowsable,o=sun.com > : filter: ou=* > : scope: subtree > : > : He will get back the following entry: > : > : ou=level2,ou=sortOfBrowsable,ou=sun.com (has "b" on this) > : > : ----- > : > : Eg 2: Then, if he does a search like this: > : > : baseEntry: ou=sortOfBrowsable,o=sun.com > : filter: ou=* > : scope: base > : > : He will get back no entries (neither "v" nor "b" on the base). > : > : ----- > : > : Eg 3: If he does a search like this: > : > : baseEntry: ou=notBrowsable,ou=sun.com > : filter: ou=* > : scope: subtree > : > : He will get back the following entry: > : > : ou=notBrowsable,ou=sun.com (has "v" and it's the base) > : > : ----- > : > : > : Eg 4: If he does a search like this: > : > : baseEntry: ou=notBrowsable,ou=sun.com > : filter: ou=* > : scope: base > : > : He will get back the following entry: > : > : ou=notBrowsable,ou=sun.com (has "v" and it's the base) > : > : ----- > : > : > : Eg 5: Then, if he does a search like this: > : > : baseEntry: ou=Browsable,ou=sun.com > : filter: ou=* > : scope: subtree > : > : He will get back the following entries: > : ou=Browsable,ou=sun.com (has "b") > : ou=level1,ou=Browsable,ou=sun.com (has "b") > : ou=level2,ou=Browsable,ou=sun.com (has "b") > : > : ----- > : > : > : Eg 6: Then, if he does a search like this: > : > : baseEntry: ou=Browsable,ou=sun.com > : filter: ou=* > : scope: base > : > : He will get back the following entries: > : ou=Browsable,ou=sun.com (has "b") > : > : ----- > : > : > : Eg 7: Then, if he does a search like this: > : > : baseEntry: ou=sun.com > : filter: ou=* > : scope: onelevel > : > : He will get back the following entries: > : ou=Browsable,ou=sun.com (has "b") > : > : ----- > : > : Any comments on this modification ? > : > : Rob. From list@netscape.com Wed Apr 11 11:43:19 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26589 for ; Wed, 11 Apr 2001 11:43:18 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3BFdWS27070; Wed, 11 Apr 2001 08:39:32 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3BFdXE28237; Wed, 11 Apr 2001 08:39:33 -0700 (PDT) Resent-Date: Wed, 11 Apr 2001 08:39:33 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3AD47A89.7FD6CBFD@Sun.COM> Date: Wed, 11 Apr 2001 17:38:49 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com Subject: protecting dns in the ACM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BT7tTB.A.z3G.wqH16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Rick raised a point about protecting dns in a recent mail: > And one other vaguely related question that came to mind after reading > Rob's email. He notes that "... the absence of a "v" or "b" permission > at any point does not abort the search operation as a whole or even on > a particular subtree." > > I have been assuming (and this seemed like a good time to check) that > absence of a "t" permission DOES abort the search operation on a > particular subtree, since returning the DN of any object further down > in the tree would require that the DN of the object without "t" > permission be returned. Is that the generally accepted view? > To show this problem here's a little tree where (all) means I have all rights, (none) means I have no rights on that entry: o=sun.com (all) | ou=eng (none) | cn=rob (all) Now, currently, if I do a subtree search with base o=sun.com then I will get two entries: o=sun.com and cn=rob,ou=eng,o=sun.com. The problem is I am returned information about the ou=eng,o=sun.com entry, via the entry cn=rob,ou=eng,o=sun.com, although in fact I have zero rights on the ou=eng,o=sun.com entry. I guess the consistent way to fix this would be to require that before returning the dn of an entry, A say, I also need the rights to see the naming attribute of each entry in the tree above A. So, in the example, before returning cn=rob,ou=eng,o=sun.com I should check I have rights to see ou in ou=eng,o=sun.com and o in o=sun.com. This has the advantage of being really consistent, it has the disadvantage that when I want to see a given entry, I need to evaluate not just my rights on _that_ entry, but on on all the ancestors of that entry. My suspision is that most implementors would prefer this inconsistency to the cost of checking this extra dependency. For example, alot of directory implementaions use indexing based loosely on the search filter to generate candidate lists of entries to return--in such a scheme you will not "naturally" visit all the ancestors of an entry, so I think the "abort subtree" approach would not naturally fit those implementations. So I think we have a consistency/performance trade off and this is why I am currently not in favour of specifying an "abort subtree" type behaviour...but if anyone else can see an efficient way of fixing the consistency problem... Rob. From list@netscape.com Wed Apr 11 12:18:37 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27464 for ; Wed, 11 Apr 2001 12:18:37 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3BGFtS02578; Wed, 11 Apr 2001 09:15:55 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3BGFtQ18769; Wed, 11 Apr 2001 09:15:55 -0700 (PDT) Resent-Date: Wed, 11 Apr 2001 09:15:55 -0700 (PDT) From: George_Robert_Blakley_III/Tivoli_Systems%TIVOLI_SYSTEMS@us.ibm.com X-Lotus-FromDomain: TIVOLI SYSTEMS@IBMUS To: "Kurt D. Zeilenga" cc: ietf-ldapext@netscape.com Message-ID: <85256A2B.00593817.00@D51MTA03.pok.ibm.com> Date: Wed, 11 Apr 2001 11:18:23 -0500 Subject: Re: IP Address in the ACM (Was: Comments on Access Control Model - BNF) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"uQXPS.A.JkE.4MI16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I agree with everything you say here, Kurt. I think non-ACI mechanisms are better than ACI mechanisms for restricting topology, and I also agree that only IP address ranges or wildcarded expressions scale if you want to use an ACI-based mechanism to do this. I was originally and still am personally opposed to the inclusion of IP address as a subject attribute in access control systems. In terms of precedence, let's try to reason through this: (1) If an ACL says to grant on the basis of IP address but deny on the basis of some other attribute (username, group, etc....), then the behavior we want is (in my opinion) "deny". Rationale: the user is prohibited from access, regardless of where he's sitting. (2) If an ACL says to deny on the basis of IP address but grant on the basis of some other attribute (username, group, etc....), then the behavior we want is *also* (in my opinion) "deny". Rationale: the user is allowed access, but not from where he's sitting. Is there a way to achieve this with our current resolution algorithm? I'd have to check more carefully than I have time to do right now. --bob Bob Blakley Chief Scientist Enterprise Solutions Unit Tivoli Systems, Inc. (an IBM Company) "Kurt D. Zeilenga" on 04/04/2001 12:33:53 PM To: ietf-ldapext@netscape.com cc: Subject: Re: IP Address in the ACM (Was: Comments on Access Control Model - BNF) Bob said: >I agree in general that IP addresses shouldn't be used >as identities and that RFC2820 is correct on this count. >However the goal at the time the original model draft was >written was to support (or at least not exclude) things >which existing implementations were already doing, however >misguided they might be from a "pure security" point of >view. Several implementations supported and still >support IP addresses as subject attributes. I note that most implementations actually support IP address with some form of wildcard support. Requiring an ACI value per IP address just doesn't scale. >To your second point, the precedence assignment was based >on the observation that it's usually not a single IP >address which is included in a policy, but a range of IP >addresses. Normally everything within (or everything >except) a specific IP address range is excluded from access >-- REGARDLESS of other attributes. Hence IP address became >the highest precedence -- because the mechanism is essentially >enforcing topology control & hence to be effective has >to be enforced first. Since you did note "IP address range", my general comment is that this subject is less specific than varous other subjects and hence should be lower. Also, as far as implementing "topology controls", non-ACM mechanisms are often far more effective. For example, our server implements "TCP wrappers" (an internal "firewalling" mechanism) to enforce topology controls. We also do support IP addresses in our ACM (only in ACLs, not ACIs), but normally their use is in combination with other factors. Kurt From list@netscape.com Wed Apr 11 13:00:51 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28848 for ; Wed, 11 Apr 2001 13:00:19 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f367Egv10016; Fri, 6 Apr 2001 00:14:43 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f367Eic21866; Fri, 6 Apr 2001 00:14:44 -0700 (PDT) Resent-Date: Fri, 6 Apr 2001 00:14:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0 content-class: urn:content-classes:message Subject: RE: IP Address in the ACM (Was: Comments on Access ControlModel - BNF) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C0BE69.52E19AE7" Date: Fri, 6 Apr 2001 00:15:13 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C07626574077FF8A9@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-TNEF-Correlator: <5B90AD65A9E8934987DB0C8C07626574077FF8A9@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: IP Address in the ACM (Was: Comments on Access ControlModel - BNF) Thread-Index: AcC93HK6dqk61hZ4SjyageXGPIIydAAjDhIL From: "Paul Leach" To: "robert byrne" , "Kurt D. Zeilenga" Cc: "Paul Leach" , X-OriginalArrivalTime: 06 Apr 2001 07:15:14.0313 (UTC) FILETIME=[5333EF90:01C0BE69] Resent-Message-ID: <"avEce.A.2UF.gzWz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. ------_=_NextPart_001_01C0BE69.52E19AE7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogcm9iZXJ0IGJ5cm5lIA0K CVNlbnQ6IFRodSA0LzUvMjAwMSA3OjE3IEFNIA0KCVRvOiBLdXJ0IEQuIFplaWxlbmdhIA0KCUNj OiBQYXVsIExlYWNoOyBpZXRmLWxkYXBleHRAbmV0c2NhcGUuY29tIA0KCVN1YmplY3Q6IFJlOiBJ UCBBZGRyZXNzIGluIHRoZSBBQ00gKFdhczogQ29tbWVudHMgb24gQWNjZXNzDQpDb250cm9sTW9k ZWwgLSBCTkYpDQoJDQoJDQoNCg0KCUkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHB1dCBvcHRpb25h bCB0aGluZ3MgaW4gdGhlIHNwZWMtLWl0IHdpbGwNCmNyZWF0ZQ0KCWludGVyb3BlcmFiaWxpdHkg cHJvYmxlbXMuDQoNCklmIHNvbWVvbmUgaW1wbGVtZW50cyBhIHByb2R1Y3QgdGhhdCBpcyBub3Qg aW50ZW5kZWQgdG8gYmUgdXNlZCBpbg0KZW52aXJvbm1lbnRzIHdoZXJlIElQIGFkZHJlc3NlcyBh cyBzdWJqZWN0cyBpcyBzZWN1cmUsIHRoZW4gd2h5IHNob3VsZA0Kd2UgbWFrZSB0aGVtIGltcGxl bWVudCBpdD8NCg0KCQlJIGRvbid0IHNlZSB3aHkgeW91IGFyZSBwYXJ0aWN1bGFybHkgZG93biBv biBpcCBhZGRyZXNzDQpzdWJqZWN0cywgYnV0IGENCgkJc3ViamVjdCB3aXRoIHNpbXBsZSBhdXRo ZW50aWNhdGlvbiBkb2Vzbid0IHNlZW0gdG8NCmJvdGhlciB5b3UuICBJIG1lYW4sDQoJCWluIHBy YWN0aWNlIEkgd291bGQgc2F5IHRoZXJlIGlzIG5vdCBtdWNoIGRpZmZlcmVuY2UgaW4NCnRoZSBy aXNrDQoJCWludm9sdmVkIGluIGdyYW50aW5nIHJpZ2h0cyBiYXNlZCBvbiBpcCBhZGRyZXNzZXMg YW5kDQpncmFudGluZyByaWdodHMgdG8NCgkJYSBzdWJqZWN0IHdpdGggYW4gYXV0aGVudGljYXRp b24gbGV2ZWwgb2YgInNpbXBsZSIuDQoNCkknbSBxdWl0ZSB3aWxsaW5nIHRvIG91dGxhdyBzaW1w bGUgdW5sZXNzIGl0cyBvdmVyIFNTTCwgaWYgZXZlcnlvbmUNCndvdWxkIGdvIGFsb25nIHdpdGgg aXQuIEFueSB0YWtlcnM/IFNpbGVuY2UgbWF5IG1lYW4gYXNzZW50IHRvDQppbmV2aXRhYmxpbHR5 LCBidXQgbm90IG5lY2Vzc2FyaWx5IGFncmVlbWVudC4NCg0KQW5kIHllcywgdGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb24gYWJvdXQgdXNlIG9mIHNpbXBsZSBvdmVyIHVuZW5jcnlwdGVkDQpsaW5r cyBvdWdodCB0byBiZSBjb3VjaGVkIGluIGFwb2NvbHlwdGljIGxhbmd1YWdlLg0KDQogDQoNClBh dWwNCg0K ------_=_NextPart_001_01C0BE69.52E19AE7 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ig8HAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADRBwQABgAAAA8ADQAFAAMBASCAAwAOAAAA0QcEAAYAAAAPAA0ABQADAQEJgAEAIQAAADVF M0M0OTA3QTQzNzE3NEE5NzVFQjY5RTI0QjIwNDAwAP4GAQOQBgCYEgAAOQAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAAI4AAABSAEUAOgAgAEkAUAAgAEEA ZABkAHIAZQBzAHMAIABpAG4AIAB0AGgAZQAgAEEAQwBNACAAKABXAGEAcwA6ACAAQwBvAG0AbQBl AG4AdABzACAAbwBuACAAQQBjAGMAZQBzAHMAIABDAG8AbgB0AHIAbwBsAE0AbwBkAGUAbAAgAC0A IABCAE4ARgApAAAAAABAADkA55rhUmm+wAEfAD0AAQAAAAoAAABSAEUAOgAgAAAAAAACAUcAAQAA ADMAAABjPVVTO2E9IDtwPU1pY3Jvc29mdDtsPURGLUJPV1dPVy0wMTA0MDYwNzE1MTNaLTE2OQAA HwBJAAEAAACOAAAAUgBlADoAIABJAFAAIABBAGQAZAByAGUAcwBzACAAaQBuACAAdABoAGUAIABB AEMATQAgACgAVwBhAHMAOgAgAEMAbwBtAG0AZQBuAHQAcwAgAG8AbgAgAEEAYwBjAGUAcwBzACAA QwBvAG4AdAByAG8AbABNAG8AZABlAGwAIAAtACAAQgBOAEYAKQAAAAAAQABOAIAYITbbvcABHwBa AAEAAAAaAAAAcgBvAGIAZQByAHQAIABiAHkAcgBuAGUAAAAAAAIBWwABAAAAPwAAAAAAAACBKx+k vqMQGZ1uAN0BD1QCAAAAAHJvYmVydCBieXJuZQBTTVRQAHJvYmVydC5ieXJuZUBTdW4uQ09NAAAC AVwAAQAAABoAAABTTVRQOlJPQkVSVC5CWVJORUBTVU4uQ09NAAAAHwBdAAEAAAAaAAAAcgBvAGIA ZQByAHQAIABiAHkAcgBuAGUAAAAAAAIBXgABAAAAPwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAA AHJvYmVydCBieXJuZQBTTVRQAHJvYmVydC5ieXJuZUBTdW4uQ09NAAACAV8AAQAAABoAAABTTVRQ OlJPQkVSVC5CWVJORUBTVU4uQ09NAAAAHwBmAAEAAAAKAAAAUwBNAFQAUAAAAAAAHwBnAAEAAAAq AAAAcgBvAGIAZQByAHQALgBiAHkAcgBuAGUAQABTAHUAbgAuAEMATwBNAAAAAAAfAGgAAQAAAAoA AABTAE0AVABQAAAAAAAfAGkAAQAAACoAAAByAG8AYgBlAHIAdAAuAGIAeQByAG4AZQBAAFMAdQBu AC4AQwBPAE0AAAAAAB8AcAABAAAAhgAAAEkAUAAgAEEAZABkAHIAZQBzAHMAIABpAG4AIAB0AGgA ZQAgAEEAQwBNACAAKABXAGEAcwA6ACAAQwBvAG0AbQBlAG4AdABzACAAbwBuACAAQQBjAGMAZQBz AHMAIABDAG8AbgB0AHIAbwBsAE0AbwBkAGUAbAAgAC0AIABCAE4ARgApAAAAAAACAXEAAQAAABsA AAABwL3ccrp2qTrWFnhKPJqB5cY8gjJ0ACMOEgsAHwBzAAEAAABMAAAAUABhAHUAbAAgAEwAZQBh AGMAaAA7ACAAaQBlAHQAZgAtAGwAZABhAHAAZQB4AHQAQABuAGUAdABzAGMAYQBwAGUALgBjAG8A bQAAAB8AdAABAAAAIgAAAEsAdQByAHQAIABEAC4AIABaAGUAaQBsAGUAbgBnAGEAAAAAAB8AGgwB AAAAFgAAAFAAYQB1AGwAIABMAGUAYQBjAGgAAAAAAB8AHQ4BAAAAhgAAAEkAUAAgAEEAZABkAHIA ZQBzAHMAIABpAG4AIAB0AGgAZQAgAEEAQwBNACAAKABXAGEAcwA6ACAAQwBvAG0AbQBlAG4AdABz ACAAbwBuACAAQQBjAGMAZQBzAHMAIABDAG8AbgB0AHIAbwBsAE0AbwBkAGUAbAAgAC0AIABCAE4A RgApAAAAAAACAQkQAQAAAEAIAAA8CAAABRoAAExaRnVx7XuAAwAKAHJjcGcxMjWCMgNDaHRtbDED MD8BAwH3CoACpAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYIVQeyEdUOUQMB3RDXMgYABsMR1TME RhDZbxLrEeMI7wn3OxjPDjA1OxHSDGBjAFALCQFkMzaTEWALpTQgEAIqXA6yvQGQZxTwCqMR4x3o NBTwADwhRE9DVFlQAEUgSFRNTCBQAFVCTElDICItIC8vVzNDIYBEVCJEIJQzLjIhgEVOnCI+Hu0e jyPBMTgf8G8goiMPJB8mkDMdgCVwRXxBRCXNDvEm7ylvJPQ2QQ7wPE1FVEEHsEExLGA9IkcJ8ASQ YXRFBbAiEtBPTlQi0FQTLPAF4UV4EPFuZ2U9BlJ2EzEvQQCQAiAgNkAuMC40NjgigDAnIv4qzyUD Nzcf8FRJKFRMRSXONA7wUmWQOiBJUBFwZGQY0CMEEQuAIHRoLvBBQ8BNIChXYXM04AhQHm0HgAIw BCAv0UFjY881cghQAjADYGxNBHEDIEAtIEJORikkbjX9H/AvM08xfyZFNJE6QChPCyafPhQ1EWA8 Qk9EQFkgZGlyPT4wcp89gD3zACEDMECRZG8A4PNAkQqxXHEYsECREPADMB9A9RFgPasc8T6vZzk2 8R/wRElWQMkAAEMHPcksNjRGP0NfOB2AJm6YYnNwAoBA6CdhAUD/Rv8+QQHAQNcKokDXCnEkfP4w KBEh4EYLTihDj0SfRaPDIRAgMEtRVU8t8EBGQCBzdHlsZS4xQQBSR0lOLVJJR+MgoDTgMHB4IvFA 6Aqx/xACQfVCk0JRQu9SDx8bEWB/W+BS70XvS/9ID1kHQXBpaxzSJHw0JVFGLdFVIGm6elVwMl1r C+JY6S1k4vpPBRBnC4AHQAXQNXE+UN5lZONhTSwQP+FSQMsLgL5lCoFZD0omP/Bda2JY6dpGA2E6 XCwf4S9qqlD5miADYGIEkAVAYnkEoP8u8DwsWn9KRFv+Z29of2mPf2qfdOgGYAIwbI9tn26nVIBo dSA0LzUvAdDyMA7wNzoy8BFwNkByj59zn3Svdb92z38UVG94fxt5j26nSwhwBUBELiDMWmUDEAnw Z2Fv/3EPP3IffR9+L38/gE9re0NjR4JPg19up1BhdQMgTDJlANBoOzWgEUBmLQBsZGFwZXh0QKst MDcgY5IxLgWgbXxvH4mPip+Lr4y/d8Z1Ymr/BZB4b49fbpg0woYPhx+IJP81DzYfNy84OZx/nY+I JDjif5NvlH+Vj6XPpt+n7yTWNf1dAS9icprPTD9NT05fT2//rT+ofx/hqbxXg7LvWg9bH/c9q19w H/BQtM9gSV+/YM+3Yd9i72P9SUBAAiAnBUAjn9ALgGsgdy7wc2ijCGCSECBwdQVAbwUw9y/BZZHB kmefh0rQBZBk4L5pBUCi37ePiCQD8GwDIPsFAJFgdKrBqL+pz7W6C4Bvx+ADYJJALVBiAxDEoHnH woBvMVVgbXMuq5+sr/+y2a9PsFW6T7X/rtQ6MboR/7DPmpFUF84f0j+3P7mIQE//vExA+lgv1q++ P79PwFtBUPpzA3BlAiAu8AdwC1DMYPeg84XgzBFkG4DBci1gn5DZBCBub+NRyxFuAQDCcM8tcMTP 2ANvUCB1ETDCcLufoQnwdtmQAiCg5Hef4PsY0DTyYZ80B5GgcFUgmSTPn4HosQWQCHBlLJ/CA6B/ 53DL8OSv2BLCJcHxAMBrny7wn9GTQOHXn5B0P8yv/82/zs/P39Dv3Q/TD9dPXC//VA9VH1YvXdTb //Nf9b+4D//2n/ev+L/5z/rf++xez9pP/70RrxDdf96P35/8T8Vvh6v//yGubNhcJVHZb9u/+/vB FvfpkC7w6mJ5FzDicOehDLFnwvDpsBwgcmzqgEGwd/PmgC/RaXDn9ujH6fALv+sMzw3WYsKhYcgP yR+qvP/o1cHgxKBC0C+w7ULicMKg/+ohFOEtYC/CQbDocBN1k0D95HFi47DngRdPGF8NxxQxv8yc Sn9LjhMh7YAuwCwaT/8bX8ouzAGRcBTh57HB4MJD32Xw6oAgkuGx44Rt4uBC0OkBEGZm55FuKrEg 7yH/5w3Wn6VlQHNrJy8oP8ou6naiMHbmRGfLgB7Rw5DtMHFnJUDiYGKgcORBFdv/6HLkIC1vLn8N xzSO5HAwz/8x36q8heAdSybwHn4BwDQQvfwAbxFgNy84Pw3WIh4U/iLMn+8P8B/xL/I/Cx/0X//U D9Uf1i9LH0wvTT/8/9hP/xA/2m8RHxIvCC8JPwpPwLXyJ5NAcXXEoBPRx2E00ivkccJAdBUgdx4G dW4fAcCfcqESNBABcFNTTP8XP1I0LNDmkF5RFDBv0SsE/mfkgGWQoUA08B3DxKCFUIxBbiuB7KFy cz94IP+Fkiqx7JDqgCbS6JHpkO2h/+R/X8aSkObAUeDMQIWQy+D/6fAZ8uOikpChklJQhZDqgP/+ wJ9Q4hNDrTvPPN9pD2of92ssYnDCcHnocOnz6YTL0vdk71JSkyBuWUCicMuAHyP/y5BcseYSQEIe FV5DXZAtIa9gkMLg5EFrAWuhIXU1Mf8gMx5gkyAsgeZEcG9SUpLgbm+TIBVQwuFjP+Am8Gf+df7A kwBDv0TPRd9G70f//2t/Sh9Rj1KfU69Uv1XPVt//V+9Y/1oPhs96H1BPI98k7/8l+XwvfT9+T39f gG+Bf4KPf4OfhK+Fv5Mfh9+I75qZUP0egGyMP5AvkT+ST5NflG9//tEQEYvFlL+Vz6cf/qI14aWi Qk9EWaSeqH/+sqY3TxECoE1MbUB9rUAfADUQAQAAAKIAAAA8ADUAQgA5ADAAQQBEADYANQBBADkA RQA4ADkAMwA0ADkAOAA3AEQAQgAwAEMAOABDADAANwA2ADIANgA1ADcANAAwADcANwBGAEYAOABB ADkAQABEAEYALQBCAE8AVwBXAE8AVwAuAHAAbABhAHQAaQBuAHUAbQAuAGMAbwByAHAALgBtAGkA YwByAG8AcwBvAGYAdAAuAGMAbwBtAD4AAAAAAB8ARxABAAAAHgAAAG0AZQBzAHMAYQBnAGUALwBy AGYAYwA4ADIAMgAAAAAACwDyEAEAAAAfAPMQAQAAAJ4AAABSAEUAJQAzAEEAIABJAFAAIABBAGQA ZAByAGUAcwBzACAAaQBuACAAdABoAGUAIABBAEMATQAgACgAVwBhAHMAJQAzAEEAIABDAG8AbQBt AGUAbgB0AHMAIABvAG4AIABBAGMAYwBlAHMAcwAgAEMAbwBuAHQAcgBvAGwATQBvAGQAZQBsACAA LQAgAEIATgBGACkALgBFAE0ATAAAAAAACwD2EAAAAABAAAcw/acCq2i+wAFAAAgwt630Umm+wAED AN4/6f0AAAMA8T8JBAAAHwD4PwEAAAAWAAAAUABhAHUAbAAgAEwAZQBhAGMAaAAAAAAAAgH5PwEA AABNAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPU1JQ1JPU09GVC9PVT1BUFBTLVdH QS9DTj1SRUNJUElFTlRTL0NOPVBBVUxMRQAAAAAfAPo/AQAAACoAAABTAHkAcwB0AGUAbQAgAEEA ZABtAGkAbgBpAHMAdAByAGEAdABvAHIAAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAAr L+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB8A MEABAAAADgAAAFAAQQBVAEwATABFAAAAAAAfADFAAQAAAA4AAABQAEEAVQBMAEwARQAAAAAAHwAy QAEAAAAqAAAAcgBvAGIAZQByAHQALgBiAHkAcgBuAGUAQABTAHUAbgAuAEMATwBNAAAAAAAfADNA AQAAACoAAAByAG8AYgBlAHIAdAAuAGIAeQByAG4AZQBAAFMAdQBuAC4AQwBPAE0AAAAAAB8AOEAB AAAADgAAAFAAQQBVAEwATABFAAAAAAAfADlAAQAAAAQAAAAuAAAACwApAAAAAAALACMAAAAAAAMA BhB5Os8rAwAHEJwDAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAALS0tLS1PUklHSU5BTE1F U1NBR0UtLS0tLUZST006Uk9CRVJUQllSTkVTRU5UOlRIVTQvNS8yMDAxNzoxN0FNVE86S1VSVERa RUlMRU5HQUNDOlBBVUxMRUFDSDtJRVRGLUxEQQAAAAACAX8AAQAAAFEAAAA8NUI5MEFENjVBOUU4 OTM0OTg3REIwQzhDMDc2MjY1NzQwNzdGRjhBOUBERi1CT1dXT1cucGxhdGludW0uY29ycC5taWNy b3NvZnQuY29tPgAAAABzUg== ------_=_NextPart_001_01C0BE69.52E19AE7-- From list@netscape.com Wed Apr 11 15:56:55 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01970 for ; Wed, 11 Apr 2001 15:56:54 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3BJp1v10787; Wed, 11 Apr 2001 12:51:01 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3BJp1E06371; Wed, 11 Apr 2001 12:51:01 -0700 (PDT) Resent-Date: Wed, 11 Apr 2001 12:51:01 -0700 (PDT) Date: Wed, 11 Apr 2001 15:50:09 -0400 Message-Id: <200104111950.PAA21762@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: ietf-ldapext@netscape.com, robert.byrne@Sun.COM Subject: Re: protecting dns in the ACM Resent-Message-ID: <"O0CmvB.A.OiB.iWL16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com The reason I thought that "abort subtree" was the expected behavior is the wording of the definition of the "t" permission in Section 4.2.1: t returnDN If granted, allows the distinguished name of the entry to be disclosed in the operation result. So if the requester does not have "t" permission for ou=eng in Rob's example, I expected that neither "ou=eng, o=sun.com" nor "cn=rob, ou=eng, o=sun.com" would be returned since both of them disclose the DN "ou=eng, o=sun.com" in the result. If the interpretation in Rob's email is the desired result, then I think the definition of "t" permission needs to be clarified. And is "t" permission really useful if it is so easy to get around it? It would seem that "t" only protects the DN of a leaf node, not any interior node. I have a few other comments embedded in Rob's email below. Rick Huber : Sender: Robert.Byrne@Sun.COM : From: robert byrne : To: ietf-ldapext@netscape.com : Subject: protecting dns in the ACM : : : Rick raised a point about protecting dns in a recent mail: : : > And one other vaguely related question that came to mind after reading : > Rob's email. He notes that "... the absence of a "v" or "b" permission : > at any point does not abort the search operation as a whole or even on : > a particular subtree." : > : > I have been assuming (and this seemed like a good time to check) that : > absence of a "t" permission DOES abort the search operation on a : > particular subtree, since returning the DN of any object further down : > in the tree would require that the DN of the object without "t" : > permission be returned. Is that the generally accepted view? : > : : To show this problem here's a little tree where (all) means I have all : rights, (none) means I have no rights on that entry: : : o=sun.com (all) : | : ou=eng (none) : | : cn=rob (all) : : Now, currently, if I do a subtree search with base o=sun.com then I will : get two entries: o=sun.com and cn=rob,ou=eng,o=sun.com. The problem is : I am returned information about the ou=eng,o=sun.com entry, via the : entry cn=rob,ou=eng,o=sun.com, although in fact I have zero rights on : the ou=eng,o=sun.com entry. : : I guess the consistent way to fix this would be to require that before : returning the dn of an entry, A say, I also need the rights to see the : naming attribute of each entry in the tree above A. So, in the example, : before returning cn=rob,ou=eng,o=sun.com I should check I have rights to : see ou in ou=eng,o=sun.com and o in o=sun.com. This has the advantage : of being really consistent, it has the disadvantage that when I want to : see a given entry, I need to evaluate not just my rights on _that_ : entry, but on on all the ancestors of that entry. My suspision is that : most implementors would prefer this inconsistency to the cost of : checking this extra dependency. For example, alot of directory : implementaions use indexing based loosely on the search filter to : generate candidate lists of entries to return--in such a scheme you will : not "naturally" visit all the ancestors of an entry, so I think the : "abort subtree" approach would not naturally fit those implementations. The draft currently says (Section 5.2, note following discussion of the "b" permission in search operations) that the "b" permission allows the DN to be returned even if the requester does not have "r" permission for the naming attributes. Would this suggestion mean that the "DN" entry-level permissions ("b", "t", etc.) go away and that we just depend on the permissions that apply to the naming attributes of the entry? Or would "b" and "t" still have some purpose? : So I think we have a consistency/performance trade off and this is why I : am currently not in favour of specifying an "abort subtree" type : behaviour...but if anyone else can see an efficient way of fixing the : consistency problem... One cause of the inconsistency seems to be that we have entry-level permissions that sometimes override attribute-level permissions for naming attributes. This may be a useful shorthand that makes implementations easier. But if we decide it is useful to have these permissions we need to carefully define the interactions. : Rob. From list@netscape.com Wed Apr 11 17:17:48 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03488 for ; Wed, 11 Apr 2001 17:17:48 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3BLEDv25015; Wed, 11 Apr 2001 14:14:14 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3BLEDY20525; Wed, 11 Apr 2001 14:14:13 -0700 (PDT) Resent-Date: Wed, 11 Apr 2001 14:14:13 -0700 (PDT) Date: Wed, 11 Apr 2001 17:11:46 -0400 Message-Id: <200104112111.RAA03761@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: George_Robert_Blakley_III/Tivoli_Systems%TIVOLI_SYSTEMS@us.ibm.com, Kurt@openldap.org Subject: Re: IP Address in the ACM (Was: Comments on Access Control Model - BNF) Cc: ietf-ldapext@netscape.com Resent-Message-ID: <"SQu8wC.A.k6E.YkM16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com In terms of the resolution algorithm, it seems farily easy to change it to do what Bob is talking about. Just change it so that ipAddress has no explicit precedence of its own. The algorithm should go in precedence order through the list of Subjects within a Scope (excluding ipAddress). At the completion of the processing of Subjects within a Scope, any applicable ACI with ipAddress as subject should be added to the list that is passed on to the next step. Since deny has precedence over grant, this means that ACI with ipAddress subject can only deny access; it cannot grant. In my version of the Access Decision Algorithm, you would remove ipAddress (and DNS name?) from the list of Subjects within a Scope and add a step 2a after step 2: 2a. If there are any applicable ACI values with subject of type ipAddress (or DNS name?), add them to the list at this point. Note that adding this as a separate step means that the part of step 2 that says "If no ACI values remain after processing all Subject Types, access is denied" is processed before the new step. Thus access is denied and the ipAddress has no effect if there is no applicable ACI other than the one(s) based on ipAddress. If we are going to use ipAddress as a subject I prefer this to the original scheme. With the original scheme a "grant" associated with an ipAddress subject was a very dangerous thing. Rick Huber : From: George_Robert_Blakley_III/Tivoli_Systems%TIVOLI_SYSTEMS@us.ibm.com : To: "Kurt D. Zeilenga" : cc: ietf-ldapext@netscape.com : Subject: Re: IP Address in the ACM (Was: Comments on Access Control Model : - BNF) : : I agree with everything you say here, Kurt. : : I think non-ACI mechanisms are better than ACI mechanisms for restricting : topology, and : I also agree that only IP address ranges or wildcarded expressions scale if : you want to : use an ACI-based mechanism to do this. : : I was originally and still am personally opposed to the inclusion of IP : address as a subject : attribute in access control systems. : : In terms of precedence, let's try to reason through this: : : (1) If an ACL says to grant on the basis of IP address but deny on the : basis of : some other attribute (username, group, etc....), then the : behavior we : want is (in my opinion) "deny". Rationale: the user is : prohibited from : access, regardless of where he's sitting. : : (2) If an ACL says to deny on the basis of IP address but grant on the : basis of : some other attribute (username, group, etc....), then the : behavior we want : is *also* (in my opinion) "deny". Rationale: the user is allowed : access, : but not from where he's sitting. : : Is there a way to achieve this with our current resolution algorithm? I'd : have to check more : carefully than I have time to do right now. : : --bob : : Bob Blakley : Chief Scientist : Enterprise Solutions Unit : Tivoli Systems, Inc. (an IBM Company) : : : "Kurt D. Zeilenga" on 04/04/2001 12:33:53 PM : : To: ietf-ldapext@netscape.com : cc: : Subject: Re: IP Address in the ACM (Was: Comments on Access Control Model : - BNF) : : : : Bob said: : >I agree in general that IP addresses shouldn't be used : >as identities and that RFC2820 is correct on this count. : >However the goal at the time the original model draft was : >written was to support (or at least not exclude) things : >which existing implementations were already doing, however : >misguided they might be from a "pure security" point of : >view. Several implementations supported and still : >support IP addresses as subject attributes. : : I note that most implementations actually support IP address : with some form of wildcard support. Requiring an ACI : value per IP address just doesn't scale. : : >To your second point, the precedence assignment was based : >on the observation that it's usually not a single IP : >address which is included in a policy, but a range of IP : >addresses. Normally everything within (or everything : >except) a specific IP address range is excluded from access : >-- REGARDLESS of other attributes. Hence IP address became : >the highest precedence -- because the mechanism is essentially : >enforcing topology control & hence to be effective has : >to be enforced first. : : Since you did note "IP address range", my general comment : is that this subject is less specific than varous other : subjects and hence should be lower. : : Also, as far as implementing "topology controls", non-ACM : mechanisms are often far more effective. For example, our : server implements "TCP wrappers" (an internal "firewalling" : mechanism) to enforce topology controls. We also do support : IP addresses in our ACM (only in ACLs, not ACIs), but normally : their use is in combination with other factors. : : Kurt From list@netscape.com Wed Apr 11 20:59:59 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05721 for ; Wed, 11 Apr 2001 20:59:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3C0v4v10227; Wed, 11 Apr 2001 17:57:04 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3C0v3604356; Wed, 11 Apr 2001 17:57:03 -0700 (PDT) Resent-Date: Wed, 11 Apr 2001 17:57:03 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0 content-class: urn:content-classes:message Subject: RE: IP Address in the ACM (Was: Comments on Access Control Model - BNF) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Apr 2001 17:55:39 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C0762657406005D3A@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: IP Address in the ACM (Was: Comments on Access Control Model - BNF) Thread-Index: AcDCzlZnUBIJULv5TEKI7iNa581gbwAEvX/A From: "Paul Leach" To: "Richard V Huber" , , Cc: X-OriginalArrivalTime: 12 Apr 2001 00:55:40.0537 (UTC) FILETIME=[4B73FE90:01C0C2EB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id f3C0uff04123 Resent-Message-ID: <"iQAgMD.A.BBB.U1P16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit Gee, this seems pretty complicated -- all for a mechanism known to be of only limited secure applicability. Again, I object to making it mandatory for compliance. > -----Original Message----- > From: Richard V Huber [mailto:rvh@qsun.mt.att.com] > Sent: Wednesday, April 11, 2001 2:12 PM > > In terms of the resolution algorithm, it seems farily easy to > change it to do what Bob is talking about. > > Just change it so that ipAddress has no explicit precedence > of its own. The algorithm should go in precedence order > through the list of Subjects within a Scope (excluding > ipAddress). At the completion of the processing of Subjects > within a Scope, any applicable ACI with ipAddress as subject > should be added to the list that is passed on to the next > step. Since deny has precedence over grant, this means that > ACI with ipAddress subject can only deny access; it cannot grant. > > In my version of the Access Decision Algorithm, you would > remove ipAddress (and DNS name?) from the list of Subjects > within a Scope and add a step 2a after step 2: > > 2a. If there are any applicable ACI values with subject of type > ipAddress (or DNS name?), add them to the list at this point. > > Note that adding this as a separate step means that the part > of step 2 that says "If no ACI values remain after processing > all Subject Types, access is denied" is processed before the > new step. Thus access is denied and the ipAddress has no > effect if there is no applicable ACI other than the one(s) > based on ipAddress. > > If we are going to use ipAddress as a subject I prefer this > to the original scheme. With the original scheme a "grant" > associated with an ipAddress subject was a very dangerous thing. > From list@netscape.com Wed Apr 11 22:15:32 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07196 for ; Wed, 11 Apr 2001 22:15:31 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3C2CuS22079; Wed, 11 Apr 2001 19:12:56 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3C2Cwg00826; Wed, 11 Apr 2001 19:12:58 -0700 (PDT) Resent-Date: Wed, 11 Apr 2001 19:12:58 -0700 (PDT) Message-Id: <5.0.2.1.0.20010411183522.00aa51f0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 11 Apr 2001 19:15:07 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: subjects in LDAP ACMs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"SfCPpC.A.WM.m8Q16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I note that the LDAP ACI syntax only allows a single subject per value though it is likely quite desirable to treat certain kinds of subjects as orthogonal factors in the ACM. For example, it might be useful to say "authzId X via Y method gets Z permission". However, adding additional, independent factors to the ACM adds to the complexity of specification so we must tread lightly. My first suggestion would be remove subjects based upon orthogonal factors from the ACM, then to discuss support for orthogonal factors such as authnLevel. I suggest Subjects be based solely upon presence, absence, or value of the authorization identity. Hence, I suggest (provided in suggested precedence order): subject = this ; self subject /= "authzID-" authzID) subject /= ("role:" dn) subject /= ("group:" dn) subject /= ("subtree:" dn) subject /= authorized ; authenticated and authorized subject /= anonymous ; unauthenticated subject /= public ; any user Kurt From list@netscape.com Wed Apr 11 23:24:26 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08677 for ; Wed, 11 Apr 2001 23:24:25 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3C3LOv24746; Wed, 11 Apr 2001 20:21:24 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3C3LPY21987; Wed, 11 Apr 2001 20:21:25 -0700 (PDT) Resent-Date: Wed, 11 Apr 2001 20:21:25 -0700 (PDT) Reply-To: From: "John Liang" To: Subject: Encoding for server side sorting and virtual list view Date: Wed, 11 Apr 2001 23:20:43 -0400 Message-ID: <000401c0c2ff$8ee95800$07a75b18@ne.mediaone.net> 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 V5.00.2314.1300 Importance: Normal Resent-Message-ID: <"ETBgO.A.LXF.08R16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit HI there, For RFC2891(server side sorting) and the draft of Virutal List View, Do both client requests of these two controls require DER encoding(Distinguished Encoding Rules)? Is a BER encoded request also acceptable at this case? If only DER is allowed, then for SortKeyList in Server Side Sorting, the tag of "orderingRule [0] MatchingRuleId OPTIONAL" should be 0x80 or 0xA0? Same question for VirtualListViewRequest, the tag of CHOICE { byoffset [0] SEQUENCE { offset INTEGER (0 .. maxInt) contentCount INTEGER (0 .. maxInt) should be 0x80 or 0xA0? The Netscape Java API uses 0x80 for Server Side Sorting and 0xA0 for Virtual List View? Any reson for the difference? Thanks, -- John Liang From list@netscape.com Wed Apr 11 23:39:52 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09172 for ; Wed, 11 Apr 2001 23:39:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3C3aTv26099; Wed, 11 Apr 2001 20:36:29 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3C3aUY25339; Wed, 11 Apr 2001 20:36:30 -0700 (PDT) Resent-Date: Wed, 11 Apr 2001 20:36:30 -0700 (PDT) Message-Id: <5.0.2.1.0.20010411203141.00a99780@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 11 Apr 2001 20:38:36 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: Encoding for server side sorting and virtual list view Cc: In-Reply-To: <000401c0c2ff$8ee95800$07a75b18@ne.mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"RUktYC.A.hLG.9KS16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:20 PM 4/11/01 -0400, John Liang wrote: >For RFC2891(server side sorting) and the draft of Virutal >List View, Do both client requests of these two controls >require DER encoding(Distinguished Encoding Rules)? >Is a BER encoded request also acceptable at this case? Actually, I would suggest they be BER encoded per RFC 2251, 5.1. Kurt From list@netscape.com Thu Apr 12 09:36:53 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29763 for ; Thu, 12 Apr 2001 09:36:52 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3CDW5v08940; Thu, 12 Apr 2001 06:32:15 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3CDW4211683; Thu, 12 Apr 2001 06:32:05 -0700 (PDT) Resent-Date: Thu, 12 Apr 2001 06:32:05 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3AD5AE2A.177EFE7B@Sun.COM> Date: Thu, 12 Apr 2001 15:31:22 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Richard V Huber CC: ietf-ldapext@netscape.com Subject: Re: protecting dns in the ACM References: <200104111950.PAA21762@qsun.mt.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_NqofB.A.H2C.S5a16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Rick, I've tried to develop some of your points a bit further inline, but I don't particulaly have the impression of having reached a conclusion. I think we are simply faced with a choice between adding to the overhead of access control for the search operation and living with some inconsistencies therein. My impression at the moment is that such inconsistencies certainly deserve a note in the draft, but are not fatal to the model, while the performance and simplification gains are considerable. Anyone got a counter example in the form of a scenario and access control policy that would shatter my illusion ? Rob. Richard V Huber wrote: > > The reason I thought that "abort subtree" was the expected behavior is > the wording of the definition of the "t" permission in Section 4.2.1: > > t returnDN > > If granted, allows the distinguished name of the entry to be > disclosed in the operation result. > > So if the requester does not have "t" permission for ou=eng in Rob's > example, I expected that neither "ou=eng, o=sun.com" nor "cn=rob, > ou=eng, o=sun.com" would be returned since both of them disclose the DN > "ou=eng, o=sun.com" in the result. > > If the interpretation in Rob's email is the desired result, then I > think the definition of "t" permission needs to be clarified. And is > "t" permission really useful if it is so easy to get around it? It I would say rather it's easy to make a configuration, such as the one in my example, that doesn't make sense form a "protecting your dns point of view". > would seem that "t" only protects the DN of a leaf node, not any > interior node. > Well, a subtree with no "t" on any entry is protecting all the entries in the subtree. This sounds like a trivial case but in fact if some of the leaves had aliases defined for them then you could see them, while still protecting the ancestor nodes' dns. Although it's not part of the ACM it's probably worth recalling that aliasing is an additional mechanism for ptotecting dns. Now, this could still suffer from the same problem that a descendant node to which I had full rights might reveal the existence of ancestors which are aliased...but we could consider that a poor configuration. > I have a few other comments embedded in Rob's email below. > > Rick Huber > > : Sender: Robert.Byrne@Sun.COM > : From: robert byrne > : To: ietf-ldapext@netscape.com > : Subject: protecting dns in the ACM > : > : > : Rick raised a point about protecting dns in a recent mail: > : > : > And one other vaguely related question that came to mind after reading > : > Rob's email. He notes that "... the absence of a "v" or "b" permission > : > at any point does not abort the search operation as a whole or even on > : > a particular subtree." > : > > : > I have been assuming (and this seemed like a good time to check) that > : > absence of a "t" permission DOES abort the search operation on a > : > particular subtree, since returning the DN of any object further down > : > in the tree would require that the DN of the object without "t" > : > permission be returned. Is that the generally accepted view? > : > > : > : To show this problem here's a little tree where (all) means I have all > : rights, (none) means I have no rights on that entry: > : > : o=sun.com (all) > : | > : ou=eng (none) > : | > : cn=rob (all) > : > : Now, currently, if I do a subtree search with base o=sun.com then I will > : get two entries: o=sun.com and cn=rob,ou=eng,o=sun.com. The problem is > : I am returned information about the ou=eng,o=sun.com entry, via the > : entry cn=rob,ou=eng,o=sun.com, although in fact I have zero rights on > : the ou=eng,o=sun.com entry. > : > : I guess the consistent way to fix this would be to require that before > : returning the dn of an entry, A say, I also need the rights to see the > : naming attribute of each entry in the tree above A. So, in the example, > : before returning cn=rob,ou=eng,o=sun.com I should check I have rights to > : see ou in ou=eng,o=sun.com and o in o=sun.com. This has the advantage > : of being really consistent, it has the disadvantage that when I want to > : see a given entry, I need to evaluate not just my rights on _that_ > : entry, but on on all the ancestors of that entry. My suspision is that > : most implementors would prefer this inconsistency to the cost of > : checking this extra dependency. For example, alot of directory > : implementaions use indexing based loosely on the search filter to > : generate candidate lists of entries to return--in such a scheme you will > : not "naturally" visit all the ancestors of an entry, so I think the > : "abort subtree" approach would not naturally fit those implementations. > > The draft currently says (Section 5.2, note following discussion of the > "b" permission in search operations) that the "b" permission allows the > DN to be returned even if the requester does not have "r" permission > for the naming attributes. Would this suggestion mean that the "DN" > entry-level permissions ("b", "t", etc.) go away and that we just > depend on the permissions that apply to the naming attributes of the > entry? Or would "b" and "t" still have some purpose? Actually this note is meant to highlight precisely the point you raised about descendants giving away info about ancestors. Maybe it was confusing to put it with "b" and should have been placed with the "t" permission description. If we think of "b" as just a way to control browsing then I think we can leave it aside for the purposes of thinking about protecting dns. Dropping "t" entirely...well what is "t" doing ? "t" implies the right to see the naming attribute of a given entry and the right to see the naming attributes of all ancestors. I guess we could drop it and replace the current "t" requirement by requiring "r" on the naming attribute of the entry. In addition, we would specify that having "r" on the naming atribute on an entry would imply "r" on all the naming attributes of the entry's ancestors. However, in so far as the distinct "t" permission helps roll up these two requirements I think I prefer to keep it. > > : So I think we have a consistency/performance trade off and this is why I > : am currently not in favour of specifying an "abort subtree" type > : behaviour...but if anyone else can see an efficient way of fixing the > : consistency problem... > > One cause of the inconsistency seems to be that we have entry-level > permissions that sometimes override attribute-level permissions for > naming attributes. This may be a useful shorthand that makes > implementations easier. But if we decide it is useful to have these > permissions we need to carefully define the interactions. I agree with you--even if we don't explain every design descision in the draft we should be as clear as possible about any "implied permissions" and oddities in the way things behave. > > : Rob. From list@netscape.com Thu Apr 12 10:39:40 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01644 for ; Thu, 12 Apr 2001 10:39:40 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3CEasv15652; Thu, 12 Apr 2001 07:36:54 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3CEasc05113; Thu, 12 Apr 2001 07:36:54 -0700 (PDT) Resent-Date: Thu, 12 Apr 2001 07:36:54 -0700 (PDT) Message-Id: <5.0.2.1.0.20010412072102.02be1da0@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 12 Apr 2001 07:38:39 -0700 To: From: "Kurt D. Zeilenga" Subject: Re: Encoding for server side sorting and virtual list view Cc: In-Reply-To: <000401c0c2ff$8ee95800$07a75b18@ne.mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"9xIxAC.A.fPB.F2b16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:20 PM 4/11/01 -0400, John Liang wrote: >If only DER is allowed, then for SortKeyList in Server Side >Sorting, the tag of "orderingRule [0] MatchingRuleId OPTIONAL" >should be 0x80 or 0xA0? They 0x80 and 0xA0 difference indices the kind of data type being encoded. 0x80 indicates a PRIMITIVE data type encoding while 0xA0 indicates a CONSTRUCTED data type encoding. Both are context specific, zero valued tags. MatchingRuleId is an OCTET STRING which is a PRIMITIVE data type while byoffset is a SEQUENCE which is a CONSTRUCTED data type. The following page provide a number of good links to ASN.1 resources: http://www.cs.columbia.edu/~hgs/internet/asn.1.html Kurt >Same question for VirtualListViewRequest, the tag of > CHOICE { > byoffset [0] SEQUENCE { > offset INTEGER (0 .. maxInt) > contentCount INTEGER (0 .. maxInt) >should be 0x80 or 0xA0? > >The Netscape Java API uses 0x80 for Server Side Sorting >and 0xA0 for Virtual List View? Any reson for the difference? > >Thanks, >-- >John Liang From list@netscape.com Thu Apr 12 11:18:52 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02545 for ; Thu, 12 Apr 2001 11:18:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3CFGJS23915; Thu, 12 Apr 2001 08:16:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3CFGJY22072; Thu, 12 Apr 2001 08:16:19 -0700 (PDT) Resent-Date: Thu, 12 Apr 2001 08:16:19 -0700 (PDT) Sender: Robert.Byrne@Sun.COM Message-ID: <3AD5C68A.E9D5C0B0@Sun.COM> Date: Thu, 12 Apr 2001 17:15:22 +0200 From: robert byrne Organization: Sun Microsystems X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Kurt D. Zeilenga" CC: ietf-ldapext@netscape.com Subject: Re: subjects in LDAP ACMs References: <5.0.2.1.0.20010411183522.00aa51f0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"PHB0gD.A.oXF.Abc16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Kurt, Conceptually it's certainly helpful to seperate the authzid type subjects from factors like authnLevel, ipaddress/dns name etc. However, in so far as a factor is typically an extra refinement on authzID's (eg. grant the access if it's cn=rob,o=sun.com AND he's authenticated using SASL-DIGEST-MD5) I think factors are still very "subjecty" things. Is the trend of your thought to move factors into a say "factor" keyword and then require that the subject AND factor keywords are satisfied ? What do you mean by "authorized" below ? BTW, do you think it would be interesting to allow boolean combinations of subjects in the same aci ? Rob. "Kurt D. Zeilenga" wrote: > > I note that the LDAP ACI syntax only allows a single > subject per value though it is likely quite desirable > to treat certain kinds of subjects as orthogonal factors > in the ACM. For example, it might be useful to say > "authzId X via Y method gets Z permission". > > However, adding additional, independent factors to > the ACM adds to the complexity of specification so > we must tread lightly. > > My first suggestion would be remove subjects based > upon orthogonal factors from the ACM, then to discuss > support for orthogonal factors such as authnLevel. > > I suggest Subjects be based solely upon presence, absence, > or value of the authorization identity. Hence, I suggest > (provided in suggested precedence order): > > subject = this ; self > subject /= "authzID-" authzID) > subject /= ("role:" dn) > subject /= ("group:" dn) > subject /= ("subtree:" dn) > subject /= authorized ; authenticated and authorized > subject /= anonymous ; unauthenticated > subject /= public ; any user > > Kurt From list@netscape.com Thu Apr 12 11:48:26 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03137 for ; Thu, 12 Apr 2001 11:48:26 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3CFjGS29280; Thu, 12 Apr 2001 08:45:26 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3CFjGQ07133; Thu, 12 Apr 2001 08:45:16 -0700 (PDT) Resent-Date: Thu, 12 Apr 2001 08:45:16 -0700 (PDT) From: 1978@n2mail.com To: millbiz@aol.com Message-ID: <199912112040.MAA94626@addr6.addr.com> Date: Wed, 11 Apr 01 13:51:54 EST Subject: "The Hottest business opportunity of the Century!" Resent-Message-ID: <"ufnx_C.A._uB.K2c16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Dear Friend, Perhaps this might be of interest to you. If not, please disregard. I thought I'd drop this one time quick note to let you know about an EXCELLENT e-Commerce business which has enjoyed rapid and consistent growth in the last 4 years. It may fit very well into your business portfolio. This is the EASIEST and the BEST on-line business today, virtually a SELF-RUN ONLINE BUSINESS. It's TWICE voted as the #1 on-line business. *Christian, of Marion, OH. writes: "I'm having 10 times the success with this business as I did with my other MLMs that I tried. I have a personal closure rate of about 80%. And I attribute that totally to the system that you have created. It truly is the best company out there. Since joining in August of this year, I have been approached by 3 distributors of other companies, including 1 co-founder, but after explaining what I do in my business and how I work the opportunity, I guess they've given up knowing that their program is much harder to achieve success in." If your current program demands that you sell products and sponsor others you will fail 90% of the time! Put yourself in the power position; win 90% of the time offering a program that everyone wants to be involved with! Simply click below to examine our award-winning web site: http://www.pcpages.com/mike4/ You will be glad you did! With My Warmest Regards, Mike Click Here I received your e-mail as someone interested in Internet Business Opportunities. If I received your e-mail in error, or you are no longer interested, click here to be removed. Be sure REMOVE is in the Subject Title and you will not be contacted again: mailto:1965@n2mail.com subject=Remove From list@netscape.com Thu Apr 12 14:05:47 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06317 for ; Thu, 12 Apr 2001 14:05:43 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3CI2pv19400; Thu, 12 Apr 2001 11:02:52 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3CI2oc09204; Thu, 12 Apr 2001 11:02:50 -0700 (PDT) Resent-Date: Thu, 12 Apr 2001 11:02:50 -0700 (PDT) Content-return: allowed Date: Thu, 12 Apr 2001 14:00:34 -0400 From: "Slone, Skip" Subject: Using DNS to locate LDAP servers To: "LDAPExt Mailing List (ietf-ldapext@netscape.com)" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_sYvJnBB1qPmYoQWGFyicSg)" Resent-Message-ID: <"DoubsC.A.hOC.G3e16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com 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. --Boundary_(ID_sYvJnBB1qPmYoQWGFyicSg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT As discussed at and subsequent to IETF-50, I have put together an I-D on using DNS to locate LDAP servers, regardless of whether the DN includes "dc" attributes. The I-D has been published as an individual submission at: http://www.ietf.org/internet-drafts/draft-slone-dn2fqdn-00.txt The abstract reads: A Lightweight Directory Access Protocol (LDAP) request must be directed to an appropriate server for processing. This document specifies an extension to the Domain Name System (DNS) and specifies a method for discovering such servers using information in DNS. This document complements and enhances previously specified methods of locating an appropriate server in that it works for distinguished names constructed with or without the "dc" attribute type. The DNS extension is specified as an AVA Resource Record. The method of discovering servers queries DNS for AVA records to resolve a DN to a fully qualified domain name, then queries DNS for SRV records to complete the location process. Feedback is welcome! -- Skip Slone --Boundary_(ID_sYvJnBB1qPmYoQWGFyicSg) Content-type: application/octet-stream; name="Skip Slone.vcf" Content-disposition: attachment; filename="Skip Slone.vcf" Comments: Conversion error: (No formatted text for errno = 0) Content-Transfer-Encoding: BASE64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOlNsb25lO1NraXANCkZOOlNraXAg U2xvbmUNCk9SRzpMb2NraGVlZCBNYXJ0aW47Q2hpZWYgVGVjaG5vbG9neSBPZmZp Y2UNClRJVExFOkNoaWVmIEFyY2hpdGVjdCwgRGlyZWN0b3J5IGFuZCBOYW1pbmcg U2VydmljZXMNCk5PVEU7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo9MEQ9MEEN ClRFTDtXT1JLO1ZPSUNFOisxICg0MDcpIDMwNi03MTAyDQpURUw7Q0VMTDtWT0lD RTorMSAoNDA3KSAyNTctMjQ1Mg0KVEVMO1dPUks7RkFYOisxICg0MDcpIDMwNi0x MzkyDQpURUw7SE9NRTtGQVg6KzEgKDIwOCkgNTQ1LTk2NzUNCkFEUjtXT1JLOjs7 MTI1MDYgTGFrZSBVbmRlcmhpbGwgUmQuICwgTVAgODQ1O09ybGFuZG87Rkw7MzI4 MjU7VVNBDQpMQUJFTDtXT1JLO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6MTI1 MDYgTGFrZSBVbmRlcmhpbGwgUmQuICwgTVAgODQ1PTBEPTBBT3JsYW5kbywgRkwg MzI4MjU9MEQ9MEFVU0ENCkVNQUlMO1BSRUY7SU5URVJORVQ6c2tpcC5zbG9uZUBs bWNvLmNvbQ0KUkVWOjIwMDEwNDA1VDE5MDkzM1oNCkVORDpWQ0FSRA0K --Boundary_(ID_sYvJnBB1qPmYoQWGFyicSg)-- From list@netscape.com Thu Apr 12 14:16:52 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06696 for ; Thu, 12 Apr 2001 14:16:51 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3CID2v21324; Thu, 12 Apr 2001 11:13:03 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3CID2E14010; Thu, 12 Apr 2001 11:13:02 -0700 (PDT) Resent-Date: Thu, 12 Apr 2001 11:13:02 -0700 (PDT) Message-Id: <5.0.2.1.0.20010412110700.00b10c60@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 12 Apr 2001 11:14:34 -0700 To: robert byrne From: "Kurt D. Zeilenga" Subject: Re: subjects in LDAP ACMs Cc: ietf-ldapext@netscape.com In-Reply-To: <3AD5C68A.E9D5C0B0@Sun.COM> References: <5.0.2.1.0.20010411183522.00aa51f0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"eRxS1C.A.iYD.nAf16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 05:15 PM 4/12/01 +0200, robert byrne wrote: >Kurt, > >Conceptually it's certainly helpful to seperate the authzid type >subjects from factors like authnLevel, ipaddress/dns name etc. However, >in so far as a factor is typically an extra refinement on authzID's (eg. >grant the access if it's cn=rob,o=sun.com AND he's authenticated using >SASL-DIGEST-MD5) I think factors are still very "subjecty" things. Is >the trend of your thought to move factors into a say "factor" keyword >and then require that the subject AND factor keywords are satisfied ? No. My thought is to come up with an extensible set of orthogonal factors which then are expressed in the syntax as such. What authorization identity some user has independent of the mechanism used to authenticate the user. What host that user appears to on is orthogonal to the mechanism used. >What do you mean by "authorized" below ? Meaning that the user was "authorized" to assume an identity. That is, the user has been authenticated and some authorization identity has been associated with the session (this might be an authorization identity derived from the user's authentication identity or another authorization identity which the user is allowed to assert). >BTW, do you think it would be interesting to allow boolean combinations >of subjects in the same aci ? Interesting, yes, but too complex. I suggest that factors be AND'ed together and or's created by multiple values. We use this logic in our ACM, it's simple and effective. >Rob. > >"Kurt D. Zeilenga" wrote: >> >> I note that the LDAP ACI syntax only allows a single >> subject per value though it is likely quite desirable >> to treat certain kinds of subjects as orthogonal factors >> in the ACM. For example, it might be useful to say >> "authzId X via Y method gets Z permission". >> >> However, adding additional, independent factors to >> the ACM adds to the complexity of specification so >> we must tread lightly. >> >> My first suggestion would be remove subjects based >> upon orthogonal factors from the ACM, then to discuss >> support for orthogonal factors such as authnLevel. >> >> I suggest Subjects be based solely upon presence, absence, >> or value of the authorization identity. Hence, I suggest >> (provided in suggested precedence order): >> >> subject = this ; self >> subject /= "authzID-" authzID) >> subject /= ("role:" dn) >> subject /= ("group:" dn) >> subject /= ("subtree:" dn) >> subject /= authorized ; authenticated and authorized >> subject /= anonymous ; unauthenticated >> subject /= public ; any user >> >> Kurt From list@netscape.com Fri Apr 13 01:15:46 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19540 for ; Fri, 13 Apr 2001 01:15:46 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3D5DRv06987; Thu, 12 Apr 2001 22:13:27 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3D5DRI14423; Thu, 12 Apr 2001 22:13:27 -0700 (PDT) Resent-Date: Thu, 12 Apr 2001 22:13:27 -0700 (PDT) Date: Thu, 12 Apr 2001 22:13:01 -0700 (PDT) Message-Id: <200104130513.f3D5CpI06414@xwing.aoltw.net> From: gscmr@aol.com To: ujawz@Myrealfriends.netscape.com Reply-To: t3m1@bigfoot.com Subject: Making Serious Money Has Never Been This Easy! [rezwl] Resent-Message-ID: <"NI8rQD.A.JgD.wro16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com NEW CD ROM is helping to Create HUGE FORTUNES!! Free Info directly from a self-Made $40,000/Mo. earner * What if you could make a full time income handing/sending out a $1.25 CD ROM? * What if the company paid you EVERY DAY? * What if it was a New York Stock Exchange Company? * What if there was no "real" competition, and everybody needs our service? * What if you got paid when somebody goes to your website and views the hottest video presentation ever and signs up? If you are the least bit curious about why this CD ROM is making us Fortunes!! All you need to do is simply: 1.Send an email to: mailto:tim22a@n2mail.com?subject=CD_ROM 2. Put " CD ROM " in the subject heading We will email you all you need to know to get signed up and making money TODAY!!! Waiting to hear from you soon! Greg Please Note... Should this email address be down. Please "Fax" your response instead, with your email address___, and the words "CD-ROM" to: 305-425-3217. From list@netscape.com Fri Apr 13 01:18:46 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19845 for ; Fri, 13 Apr 2001 01:18:46 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3D5CXv06601; Thu, 12 Apr 2001 22:12:33 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3D5CZY13875; Thu, 12 Apr 2001 22:12:35 -0700 (PDT) Resent-Date: Thu, 12 Apr 2001 22:12:35 -0700 (PDT) Date: Thu, 12 Apr 2001 22:12:18 -0700 (PDT) Message-Id: <200104130512.f3D5C8I06157@xwing.aoltw.net> From: xuwug@aol.com To: csrpf@Myrealfriends.netscape.com Reply-To: t3m1@bigfoot.com Subject: EARN $1000 EVERY TIME SOMEONE SPENDS $89! [jyyqd] Resent-Message-ID: <"XJ2eD.A.PYD.Bro16"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com EARN $1000 EVERY TIME SOMEONE SPENDS $89! If YOU did not make at least $2,000 last week. then you'd be FOOLISH not to check this out! "I sent out a 1000 piece fax blast, got 25 calls, had 14 messages, and signed up 11 people! That's $11,000 in one week! Thank you God!" Derrick Alexander. - Atlanta,GA "WOW! I needed to make ALOT of MONEY immediately when I started, for some BILLS! Did I ever! My first DAY I made $6,000! Thanks to all the FREE tools and help from my sponsor, my life will never be the same!" David Webster. - Newport Beach,CA This is the most explosive income opportunity I've ever seen! It's NOT an MLM! There are NO MEETINGS, INVENTORY, or STRESS! You simply operate a wholesale/ retail business. You market a fabulous travel package that earns you $1000 PER SALE! With $89 down we approve 98% FINANCING making this EASY TO SELL! AND EACH CUSTOMER BRINGS YOU 2 SALES WORTH ANOTHER $2000 IN YOUR POCKET! Eventually you'll MAKE $5000 A WEEK IN YOUR UNDERWEAR.. ANSWERING THE PHONE! SEE FOR YOURSELF. CHECK US OUT! For detailed info, reply with "Yes Send $1000 Info" as the subject. mailto:tim23@n2mail.com?subject=Yes_Send_$1000_Info DON'T WAIT ANOTHER DAY. DO IT NOW! Have a Great Day! Malika From list@netscape.com Fri Apr 13 17:08:37 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18484 for ; Fri, 13 Apr 2001 17:08:36 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3DL3aS23574; Fri, 13 Apr 2001 14:03:56 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3DL3AU02593; Fri, 13 Apr 2001 14:03:10 -0700 (PDT) Resent-Date: Fri, 13 Apr 2001 14:03:10 -0700 (PDT) Message-Id: <5.0.2.1.0.20010413135618.02bf5010@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 13 Apr 2001 13:58:26 -0700 To: robert byrne From: "Kurt D. Zeilenga" Subject: Re: protecting dns in the ACM Cc: Richard V Huber , ietf-ldapext@netscape.com In-Reply-To: <3AD5AE2A.177EFE7B@Sun.COM> References: <200104111950.PAA21762@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"1p6Z1C.A.rh.pl216"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 03:31 PM 4/12/01 +0200, robert byrne wrote: >Although it's not part of the ACM it's probably worth recalling that >aliasing is an additional mechanism for ptotecting dns. I don't understand this statement. How does aliasing protect DNs? From list@netscape.com Fri Apr 13 17:47:27 2001 Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19138 for ; Fri, 13 Apr 2001 17:47:27 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3DLiLS06210; Fri, 13 Apr 2001 14:44:21 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3DLiLE23590; Fri, 13 Apr 2001 14:44:21 -0700 (PDT) Resent-Date: Fri, 13 Apr 2001 14:44:21 -0700 (PDT) Date: Fri, 13 Apr 2001 14:43:30 -0700 (PDT) Message-Id: <200104132143.f3DLhEV11331@ywing.netscape.com> From: freeleads@vdirect.com To: ietf-ldapext@netscape.com Subject: Free Leads Daily - Spam FREE! No Cost to you! X-Reply-To: freeleads@vdirect.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"E7879.A.8vF.zM316"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Free Leads Daily - Spam FREE! No Cost to you! If you want...Fresh Hot Leads Daily Traffic To Your Website Automated Follow-Up Systems That Create Sales For You A Lead Management System With A Spam Free Email Blaster Your Ads Exposed To Thousands Of Eager Buyers! http://freeleads.vdirect.com _________________________________________________ This message is in full compliance with U.S. Federal requirements for commercial email under bill S.1618 Title 111, Section 301, Paragraph (a) (2) (C), passed by the 105th U.S. Congress and cannot be considered SPAM since it includes a removal mechanism. To unsubscribe, simply send a message to freeleads@vdirect.com with the word "REMOVE" in the subject line. _________________________________________________ From list@netscape.com Sat Apr 14 11:07:41 2001 Received: from netscape.com ([205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13043 for ; Sat, 14 Apr 2001 11:07:36 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f35IfnS12823; Thu, 5 Apr 2001 11:41:49 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f35Ifn615803; Thu, 5 Apr 2001 11:41:49 -0700 (PDT) Resent-Date: Thu, 5 Apr 2001 11:41:49 -0700 (PDT) Message-Id: <5.0.2.1.0.20010405133107.00b13d70@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 05 Apr 2001 13:41:28 -0500 To: "Kurt D. Zeilenga" , robert byrne From: Ellen Stokes Subject: Re: anonymous & none in the ACM (Was: Comments Access Control Model - authentication levels 2) Cc: ietf-ldapext@netscape.com In-Reply-To: <5.0.2.1.0.20010405110227.01f455b0@127.0.0.1> References: <3ACC8FBD.B351B701@Sun.COM> <200103291942.OAA09782@qsun.mt.att.com> <3AC51A2A.D54CE884@openwave.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"_sUxQ.A.f2D.rxLz6"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Kurt, We actually had this debate a long time ago both within the small community working on this draft and also at a ldapext meeting. The smaller group was content to define levels like unauthenticated, weak, strong, etc as you suggest. Our thinking here was based on a simplification of what X.500 defined. The push back (big time) was what constituted a weak authentication level vs a strong authentication level. What some folks thought was 'strong', others thought was weak, so the view was it would be difficult to get consensus and hence expected behavior across vendor implementations. So we decided to (as you would probably say) mix authn levels with methods and mechanisms, the result being what you see in the spec. This was consensus. Has consensus changed? I'd like to hear from others on this topic - but I don't want a long drawn out debate because we've had that already. So the question is do we (1) use somewhat ambiguous terms as Kurt suggests? (2) agree that the set posted to the mailing list last week is sufficient? (3) make some small change? Ellen At 11:21 AM 4/5/2001 -0700, Kurt D. Zeilenga wrote: >I think we need to decide first whether we are distinguishing >authentication methods (none, simple, sasl), authentication >mechanisms (none, simple/anonymous, simple/unauthenticated, >simple/authenticated,sasl/digest-md5,sasl/external) or >authentication levels? > >"simple" and "sasl" are not authentication levels, but >authentication methods. Each has multiple mechanisms. >Each mechanism offers different level of authentication >which may depend on other factors (such as transport >layer security). > >I see little value in supporting authentication methods >in the ACM, however an argument could be made for specific >authentication mechanisms. > >Personally, I see much more value in adding authentication >level support. I think one can define simple levels like: >"unauthenticated", "weak", "protected", "strong" in a >useful and a fairly unambiguous manner. > >I note that "sasl" and "sasl/external" are quite ambiguous >as to the level of authentication provided. > >Kurt > >At 05:31 PM 4/5/01 +0200, robert byrne wrote: > > >Just to try to close this one item, is there anyone who thinks we need > >to differentiate in the ACM between, in the terms of Ellen's very last > >BNF, "anonymous" and "none" ? > > > >> authnLevel = "none" / ; from X.500: name but no password, > >> same as LDAPBIS unauthenticated > >> "anonymous" / ; from LDAP: no name and no > password > > > >Rick says he doesn't care, Kurt says X.500 says they are the same thing > >(from an access control point of view). > >They seem pretty similar to me. > > > >If we do collapse them both then I would suggest "unauthenticated" as a > >good name for this kind of authentication level--looks like that's > >consistent with ldapbis teminology. > > > >Rob. > > > >Sanjay Panwar wrote: > >> > >> I am also not very clear on the differences and meaning of following > >> subject options. My list is little longer that Richard's. > >> > >> 1. null or no authnLevel vs "any" vs "none" vs "anonymous" > >> (same as the points made in the attached mail) > >> > >> 2. null or no subject vs "public:" vs anonymous > >> Is it legal to define a ACI without a subject ? How should it be > >> interpreted. How is public different from anonymous or no subject ? > >> > >> 3. "group:" vs "role:" > >> group is defined as the distinguished name of a groupOfNames or > >> groupOfUniqueNames entry. role is not defined that clearly. Is it the > >> distinguished name of a organizationalRole entry ? > >> > >> - Panwar > >> > >> Richard V Huber wrote: > >> > >> > The more I read Section 4.2.3, the less I understand the difference > >> > between "any" as an authnLevel and an omitted authnLevel. > >> > > >> > There are three statements in 4.2.3 that I am trying to figure out. > >> > I'm rephrasing them here: > >> > > >> > 1. No authnLevel -> no specific type of authentication is required > >> > > >> > 2. LDAP simple auth with no password is 'anonymous' > >> > > >> > 3. 'any' -> any mechanism except "no authentication" > >> > > >> > So here are my questions: > >> > > >> > A. Is an omitted authnLevel equivalent to 'any'? > >> > > >> > B. Is an omitted authnLevel equivalent to the union of 'any' and > >> > 'anonymous'? [This would be a fairly dangerous situation.] > >> > > >> > C. Does an omitted authnLevel mean "anyone bound with a non-null user > >> > ID"? [This seems just about as dangerous as B.] > >> > > >> > D. Is there a difference between a BIND with a non-null user ID and > >> > BIND with a null user ID if the password is null (anonymous and > >> > more anonymous)? [This is the anonymous vs. unauthenticated issue > >> > discussed at the LDAPBIS session last week.] > >> > > >> > E. If so, does 'anonymous' mean "any or no user ID as long as the > >> > password is null"? > >> > > >> > I think I lean towards YES on A and E, NO on B and C. I could live > >> > with either answer to D, but if it is YES, we need an explicit > >> > authnLevel to recognize 'unauthenticated'; it should not be included > >> > when the ACI omits the authnLevel. > >> > > >> > Rick Huber From list@netscape.com Sat Apr 14 12:28:58 2001 Received: from netscape.com ([205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13569 for ; Sat, 14 Apr 2001 12:28:58 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3EGPJv01133; Sat, 14 Apr 2001 09:25:19 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3EGPJc08345; Sat, 14 Apr 2001 09:25:19 -0700 (PDT) Resent-Date: Sat, 14 Apr 2001 09:25:19 -0700 (PDT) Message-Id: <5.0.2.1.0.20010414091617.00a8cb00@127.0.0.1> X-Sender: guru@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 14 Apr 2001 09:22:39 -0700 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: VLV & BER Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"6uq6AD.A.2BC.unH26"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I suggest that I-D clarify that values which are BER encoded are BER encoded per RFC 2251, 5.1. Section 5.2 says: The criticality is FALSE (MAY be absent). If FALSE, it MUST be absent per RFC 2251, 5.1(4). Kurt From list@netscape.com Sat Apr 14 13:39:42 2001 Received: from netscape.com ([205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13902 for ; Sat, 14 Apr 2001 13:39:42 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3EHaQS06415; Sat, 14 Apr 2001 10:36:27 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3EHaR223544; Sat, 14 Apr 2001 10:36:27 -0700 (PDT) Resent-Date: Sat, 14 Apr 2001 10:36:27 -0700 (PDT) Message-Id: <197304141743.MAA24287@cap1.CapAccess.org> From: "Henry Sandler" Subject: My Site To: <#field0#@cap1.CapAccess.org> Date: Sat, 14 Apr 2001 10:26:11 -0700 X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE Vdiffondi.1712.3 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"PATdXB.A.gvF.ZqI26"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We will help you get the mortgage loan you want!  Whether a new home loan is what you seek orto refinance your current home loan at a lower interest rate and payment, we can help! Mortgage rates haven't been this low in the last 12 months, take action now! Refinance your home with us and include all of those pesky credit card bills oruse the extra cash for that pool you've always wanted=2E=2E=2E = ; Where others says NO, we say YES!!! Even if you have been turned down elsewhere, we can help!  Easy terms! Our mortgage referral service combines thehighest quality loans with most economical rates and the easiest qualification! Take just 2 minutes to complete our form=2E There is no obligation, all information is kept strictly confidential, and you must be at least 18 years of age=2E Service available within the United States only=2E This service is fast and= free=2E   CLICK HERE TO FILL OUT FORM                                                                                             List Removal/OPT-OUT Option Click Here ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We will help you= get the mortgage loan you want! 

Whether a new home loan is what you seek or
to refinance your current h= ome loan at a lower interest rate and payment, we can help!

Mortgage rates haven't been this low in the last 12 months, take action no= w!
 Refinance your home with us and include all of those pesky credit card bil= ls or
use the extra cash for that pool you've always wanted=2E=2E=2E&nbs= p;

 Where others says NO, we say YES!!!
 Even if you have been turned down elsewhere, we can help! 

 Easy terms! Our mortgage referral service combines the
highest quality loans wi= th most economical rates and the easiest qualification!

 Take just 2 minutes to complete our form=2E
 There is no obligation, all information is kept stri= ctly confidential, and you must be at least 18 years of age=2E
Service available within the United States only=2E This service is fast an= d free=2E

 

CLICK HERE TO FILL OUT FORM

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           

=

List Removal/OPT-OUT Option
Clic= k Here ------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From list@netscape.com Sun Apr 15 19:56:06 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12848 for ; Sun, 15 Apr 2001 19:56:05 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3FNqZv11567; Sun, 15 Apr 2001 16:52:35 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3FMoYQ07204; Sun, 15 Apr 2001 15:50:34 -0700 (PDT) Resent-Date: Sun, 15 Apr 2001 15:50:34 -0700 (PDT) Date: Thu, 22 Mar 2001 01:55:18 +0800 Message-Id: <200103211755.BAA21822@atmedu.com.cn> Reply-To: From: "segegob.cl" To: "4313@segegob.cl" <4313@segegob.cl> Subject: 30 Day Free Trial Content-Type: text/plain; charset="us-ascii";format=flowed Content-Transfer-Encoding: 7bit Resent-Message-ID: <"tdF2uB.A.blB.tUi26"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit So let me be very direct:No matter what type of sex, what type of partner,what time of day,how well you know your partner, or how often you have sex,there are times that you either NEED more desire or just WANT an improvement. I'm going to tell you how to achieve your sexual goals, Our formula will allow you to control the effect and does not require a prescription. What do you have to loose???? ABSOLUTELY NOTHING!!! We're so confident you'll be amazed with what our products will do for your sex life, we are going to give you a 30 day supply for free. Womens and Mens formula Available! Please visit http://1062453129/sexy/index.htm ========================================================================== Removal mailto:no-more-mail-please@excite.com?subject=remove Errors and exceptions excluded. From list@netscape.com Sun Apr 15 20:09:01 2001 Received: from netscape.com (c3po.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12965 for ; Sun, 15 Apr 2001 20:09:01 -0400 (EDT) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.10.0/8.10.0) with ESMTP id f3EFf1v24270; Sat, 14 Apr 2001 08:41:02 -0700 (PDT) Received: (from list@localhost) by aka.mcom.com (8.10.0/8.10.0) id f3EFf1M29215; Sat, 14 Apr 2001 08:41:01 -0700 (PDT) Resent-Date: Sat, 14 Apr 2001 08:41:01 -0700 (PDT) Message-ID: <000079eb7bf9$0000089b$000056d3@btts.net> To: From: Sabrina_B@btts.net Subject: Customer Care Center 22227 Date: Fri, 13 Apr 2001 06:05:59 -0800 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 1 X-MSMail-Priority: High Resent-Message-ID: <"AW81ZD.A.wHH.M-G26"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: quoted-printable = Take Control Of Your Conference Calls

Why Pay=
 More For Your Confere=
nce Calls?
Onl=
y .18 Cents per minute (Including long distance!)
=

          • =
No setup fees
          • No contracts or monthly fees
          • Call=
 anytime, from anywhere, to anywhere
          • International Dial In 18 cents per minut=
e
          • C=
onnects up to 100 participants
          • Operator Help available 24/7
            <=
/LI>
=
Get the best quality, the easiest to use,=
 and lowest rate in the industry.
<=
TR>
<=
FONT color=3D#ff0000 size=3D2>Required Input Field*
If you like saving money, fill out the form below and one of=
 our consultants will contact you.
<=
TBODY>
Web Address*
<=
/TR> <=
TD width=3D"51%"> <=
TR>
Name*
 
 
Company Name*
State
 
Business Phone*
 <=
/TD>
Home Phone
E-mail*
 
Type of Business
 =


       =
;            &=
nbsp;           &nb=
sp;  


This c=
ould be your ad!
Click here to e-mail us your contact info.
This email is to those persons that have contacted Con=
ference Calls for Less regarding available services or product information=
.  If this email is reaching you in error and you feel that you have not c=
ontacted us, click here. We apologize and will gladly remove you from our mail=
ing list.









From list@netscape.com  Sun Apr 15 22:45:16 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16016
	for ; Sun, 15 Apr 2001 22:45:15 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3G2h8v05453;
	Sun, 15 Apr 2001 19:43:09 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3G2h9M06082;
	Sun, 15 Apr 2001 19:43:09 -0700 (PDT)
Resent-Date: Sun, 15 Apr 2001 19:43:09 -0700 (PDT)
From: jerryrice@myplace.com
Content-Type: text/plain;
	 charset=us-ascii
Content-Transfer-Encoding: 7BIT
To: bobbyb@check.com
Reply-To: jerryrice@mauimail.com
Subject: ADV: Prospects and Internet Sales Leads!
X-Mailer: ALPHA_XMR75_00001SLBL
Date: Sun, 15 Apr 2001 22:47:28 -0500
Message-Id: <47gn2r4e0w3r85ap4.5vcmwhj6@prontomail.com>
Resent-Message-ID: <"KJXQID.A.ceB.7wl26"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7BIT


As a dot.com professional you know that it is essential to your teams' 
success to advertise your web site, business, product, service, or your 
organizations' cause to the masses. You also know that your marketing and 
advertising budget limits your options.

If you are a Fortune 500 corporation, you have the advantage of being able to 
book 30 second TV spots during the SuperBowl. Most of us are not in that 
position though. Besides, did you know that something on the order of 92% of 
TV viewers run to the washroom at commercial breaks during the program, 
thereby missing the expensive commercial spot.


Q: Of all the various advertising mediums which do you feel is most effective,
 in cases when you require your prospect to remember your telephone number or 
web address?


Let's outline and agree on a list of the main advertising and marketing 
mediums first:


- Television Commercial
- Television Infomercial
- Internet Banner Ads (paid for on a click-through basis)
- Internet Banner Ads (paid for on an impression basis)
- So-Called opted-in email list rental and broadcast
- Radio Commercial
- Print Media (Newspapers, Magazines)
- Print Media (Hand-Outs)
- Trade Shows
- News or Media organization story or profile on your project
- Affiliate Links
- Signage
- Telemarketing
- Direct Mail 
- Broadcast Fax (not personalized to its recipients)
- Broadcast Fax (personalized and to the Attention of its recipients)
- Targeted Broadcast Email (personalized or not)


Now consider the effectiveness of each advertising choice, remembering that 
in many cases your audience must still remember a telephone number in order to 
contact you.


Q: Which is the least costly and most effective?


E-mail marketing works! Why? There are many reasons, but primarily because 
people are focused on their monitors while checking their e-mail. Totally 
focused. In addition, they have a hard copy of your ad on their hard drive, 
and it is simple for them to forward the ad to their friends and
associates as well.


You can tell your story with more words and target your list to particular 
types of recipients or geographical areas. We offer some of the best delivery 
and bulk e-mail prices on the Internet. Bulk e-mail can get you the best 
exposure on the net. What makes this kind of advertising so effective is the 
fact that you go to the potential customer. Not like search engines or print 
ads that the potential customer has to do all the searching.  Dollar for 
dollar bulk e-mailing is also the most economical.  We do all the mailing for 
you. You just provide us with the ad!  It's that simple!


What we offer is simple:

*General Lists or other ISPs
 
#100,000	Emails		$495.00
#250,000	Emails		$995.00
#500,000	Emails		$1,495.00
#1,000,000	Emails		$2,495.00
#2,500,000	Emails		$4,995.00
#5,000,000+	Emails		(Call for Quote)

WE ALSO HAVE LARGER PACKAGES!

*Targeted Lists (Starting @): 

#100,000	Emails		$995.00
#250,000	Emails		$1,495.00
#500,000	Emails		$2,995.00
#1,000,000	Emails		 (Call for Quote)

METHOD OF PAYMENT, CASHIERS CHECK MONEY ORDER OR BANK WIRE.

$$$GET AN ADDITIONAL FREE 25% ON TOP OF EVERY ORDER...
IF YOU ORDER WITHIN 5 DAYS OF RECIEVING THIS MESSAGE!

Call for bigger packages!  ORDER NOW!!!	AND GET THE RIGHT EXPOSURE!

For more details on Email Services, please call:

#954.340.1628 (US & International)


IF YOU ARE THE DO IT YOURSLF TYPE OR ARE STILL USING TRADITONAL MARKETING 
TECHNICS, YOU MUST TAKE A LOOK AT THE 8 1/2 MILLION BUSINESS TO BUSINESS 
DATABASE!!

Our 3.0 Version B2B Database Will Go Online and Sell For 2.5 to 25 Cents Per 
Record in early July! (Extended Due to Delays From The 1st)

You can now access contact data for over 8.5 Million Records. All of them 
have their own .com .org or .net domain name, making them serious prospects 
for Internet business. 

Our data base readily accessible on CD-Rom, list the Names, Contact 
Information, Physical Address, Phone #, Fax #, SIC Industry Code, URL (Domain 
Name), and Contact Email Address which you can use to efficiently target 
companies worldwide.

Over 8.5 Million Physical Addresses let you target businesses by Country, 
State, City, Province, Zip Code, Area Code or by using the SIC Industry Code.  
The data comes in a Comma-Delimited ASCII format which makes it easy to 
manipulate and Import/Export records to your Contact-Management, Spreadsheet, 
analysis and Broadcasting Applications.

We’d be happy to give you rough counts for your industry target market. We 
also build databases to order and carry more than a dozen other data bases 
both Domestic and International ( B2B and B2C).



Please send me more info about:

[ ] Master Disc 2000 8.5 Million Records, Cost US$799.00
[ ] Online Updates & Download Access Cost US$199.00 (Annually)
[ ] Commercial Email Services & Products

Note: Not all records contain complete data, call for breakdowns.

For more details on Database, please call:

#954.340.1628 (US & International)

or fax form below to:
#954.753.2846

(Make Sure To Mention Reseller Id #1789 When Calling)


Company name: ___________________________________________


Web Site Url: ___________________________________________


Contact name: ___________________________________________


Email: __________________________________________________


Phone: __________________________________________________


Fax:  ___________________________________________________
 

Street address: _________________________________________


City, Zip, State: _______________________________________


Country: ________________________________________________


Check the following that apply: 
  
_____	Please Notify Me Of Online Web Site & Register Me For Access Using The 
Information Above.


Also Please, Send Additional Information on:

_____	Online Adult & Gaming Owner/Operaters
_____	Online Adult Subscribers & Online Gamers Databases
_____	Online Billing/Credit Card Processing
_____	Emailing Services and Databases
_____	Search Engine Positioning
_____	International Contact Lists
_____	Buying / Selling Traffic
_____	Web Site Hosting Services
_____	Internet Bandwidth Services (T-1's Starting at $999.00)
_____	Other:_______________________________


##############################################################################
#############################################
THIS MESSAGE IS BEING SENT IN COMPLIANCE OF THE EMAIL BILL: SECTION 301. PER 
SECTION, PARAGRAPH (a) (2) (c) of S. 1618.

To discontinue receipt of further notice at not cost and to be removed from 
our database, please reply with the word "Remove" in subject. Or call us at 
#954.340.1628 leave your email address for removal from the database and 
future mailings.

Any attempts to disrupt the removal email address etc., will not allow us to 
be able to retrieve and process the remove requests.
##############################################################################
#############################################


.0401601



From list@netscape.com  Mon Apr 16 00:41:53 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17058
	for ; Mon, 16 Apr 2001 00:41:52 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3G4dlv22453;
	Sun, 15 Apr 2001 21:39:48 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3G4dmo29046;
	Sun, 15 Apr 2001 21:39:48 -0700 (PDT)
Resent-Date: Sun, 15 Apr 2001 21:39:48 -0700 (PDT)
Message-ID: <0000308c0ed9$000019a6$00002a81@ecis.com>
To: 
From: sweetrunny@ecis.com
Subject: The Millionaire Mind                         10881
Date: Mon, 16 Apr 2001 00:14:21 -1600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-OriginalArrivalTime: 16 Apr 2001 04:26:19.0953 (UTC) FILETIME=[62C8D210:01C0C62D]
Resent-Message-ID: <"KCdmv.A.eFH.Sen26"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit



                 FOLLOW ME TO FINANCIAL FREEDOM!!



I Am looking for people with good work ethic and extrordinary desire

 to earn at least $10,000 per month working from home!



NO SPECIAL SKILLS OR EXPERIENCE REQUIRED We will give you all the 

training and personal support you will need to ensure your success!



This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in

               control of your time,your finances,and your life!



If you've tried other opportunities in the past that have failed to 

               live up their promises,



     THIS IS DIFFERENT THEN ANYTHING ELSE YOU'VE SEEN!



       THIS IS NOT A GET RICH QUICK SCHEME!



YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE!



               CALL ONLY IF YOU ARE SERIOUS!



                 1-800-345-9708 



    DONT GO TO SLEEP WITHOUT LISTENING TO THIS!



"ALL our dreams can come true- if we have the courage to persue them"

                   -Walt Disney



Please Leave Your Name And Number And Best Time To Call



               DO NOT RESPOND BY EMAIL



This is not a SPAM. You are receiving this because

you are on a list of email addresses that I have bought.

And you have opted to receive information about

business opportunities. If you did not opt in to receive

information on business opportunities then please accept 

our apology. To be REMOVED from this list simply reply 

with REMOVE as the subject. And you will NEVER receive 

another email from me.

 
 



From list@netscape.com  Mon Apr 16 02:27:19 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01090
	for ; Mon, 16 Apr 2001 02:27:18 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3G6NmS28207;
	Sun, 15 Apr 2001 23:23:48 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3G6Npk18770;
	Sun, 15 Apr 2001 23:23:51 -0700 (PDT)
Resent-Date: Sun, 15 Apr 2001 23:23:51 -0700 (PDT)
Date: Thu, 22 Mar 2001 01:43:46 +0800
Message-Id: <200103211743.BAA21774@atmedu.com.cn>
Reply-To: 
From: "senado.gov.br" 
To: "0754@senado.gov.br" <0754@senado.gov.br>
Subject: Jumpstart sexual desire in both Men and Women
Content-Type: text/plain; charset="us-ascii";format=flowed
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"hpHy6B.A.3kE.1_o26"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

So let me be very direct:No matter what type of sex, what
type of partner,what time of day,how well you know your
partner, or how often you have sex,there are times that you
either NEED more desire or just WANT an improvement.

I'm going to tell you how to achieve your sexual goals,
Our formula will allow you to control the effect
and does not require a prescription.

                  What do you have to loose????

                     ABSOLUTELY NOTHING!!!

We're so confident you'll be amazed with what our products will do for your 
sex life, we are going to give you a 30 day supply for free.

              Womens and Mens formula Available!

Please visit
http://1062453129/sexy/index.htm
==========================================================================
Removal
mailto:no-more-mail-please@excite.com?subject=remove
Errors and exceptions excluded.




From list@netscape.com  Mon Apr 16 19:36:15 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15253
	for ; Mon, 16 Apr 2001 19:36:14 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3GNXjv05643;
	Mon, 16 Apr 2001 16:33:45 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3GNXkw29280;
	Mon, 16 Apr 2001 16:33:46 -0700 (PDT)
Resent-Date: Mon, 16 Apr 2001 16:33:46 -0700 (PDT)
Sender: Mark.Wahl@sun.com
Message-ID: <3ADB8188.D0E5AE59@sun.com>
Date: Mon, 16 Apr 2001 18:34:32 -0500
From: Mark Wahl 
Organization: Sun Microsystems Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" 
CC: robert byrne , Richard V Huber ,
        ietf-ldapext@netscape.com
Subject: Re: protecting dns in the ACM
References: <200104111950.PAA21762@qsun.mt.att.com> <5.0.2.1.0.20010413135618.02bf5010@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"8J5RBC.A.IJH.ZF426"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> 
> At 03:31 PM 4/12/01 +0200, robert byrne wrote:
> >Although it's not part of the ACM it's probably worth recalling that
> >aliasing is an additional mechanism for ptotecting dns.
> 
> I don't understand this statement.  How does aliasing protect DNs?

If aliases were dereferenced while performing a search, and the resulting
object entry does not allow its DN to be revealed, X.500 directory servers can
return the entry but with the alias name to the client.

Mark Wahl
Sun Microsystems Inc.



From list@netscape.com  Mon Apr 16 23:41:13 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18942
	for ; Mon, 16 Apr 2001 23:41:12 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3H3cvS25104;
	Mon, 16 Apr 2001 20:38:57 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3H3cwI23508;
	Mon, 16 Apr 2001 20:38:58 -0700 (PDT)
Resent-Date: Mon, 16 Apr 2001 20:38:58 -0700 (PDT)
DATE: Mon, 16 Apr 2001 23:00:55 -0500
Message-ID: 
Subject: TVLN up over 100% since debut last week at Small Cap Times.com!!!!!
From: info@smallcaptimes.com
To: $user@netscape.com
X-Reply-To:  info@smallcaptimes.com
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"2hdXaC.A.muF.Pr726"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

TVLN up over 100% since debut last week at http://www.smallcaptimes.com

read the entire story at http://www.smallcaptimes.com


You are receiving this email as a subscriber to smallcaptimes.com. If you are receiving this in error or wish to unsubscribe reply to this email with unsubscribe in the subject line. We will remove you at once.



From list@netscape.com  Tue Apr 17 13:57:23 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12442
	for ; Tue, 17 Apr 2001 13:57:20 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3HHtLS05903;
	Tue, 17 Apr 2001 10:55:21 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3HHtLA07993;
	Tue, 17 Apr 2001 10:55:21 -0700 (PDT)
Resent-Date: Tue, 17 Apr 2001 10:55:21 -0700 (PDT)
Sender: Mark.Wahl@sun.com
Message-ID: <3ADC83B2.D25E2ECB@sun.com>
Date: Tue, 17 Apr 2001 12:56:02 -0500
From: Mark Wahl 
Reply-To: Mark.Wahl@sun.com
Organization: Sun Microsystems Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ldapext@netscape.com
Subject: LDAPEXT Minutes
Content-Type: multipart/mixed;
 boundary="------------F25D8A5AD31CDA5B715971AA"
Resent-Message-ID: <"d_5Xu.A.f8B.HOI36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a multi-part message in MIME format.
--------------F25D8A5AD31CDA5B715971AA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Mark Wahl
Sun Microsystems Inc.
--------------F25D8A5AD31CDA5B715971AA
Content-Type: text/plain; charset=us-ascii;
 name="minutes.txt"
Content-Disposition: inline;
 filename="minutes.txt"
Content-Transfer-Encoding: 7bit


LDAPEXT: LDAP Extensions Working Group
Minutes recorded by Mark Wahl 

Agenda:
 - preliminaries
 - extensions
 - server discovery
 - access control
 - subentries
 - schema updates

Preliminaries
=============

Agenda discussion: where should the interaction of replication and Access
control be discussed? John Strassner said: Replication issues for acls are 
part of the scope of the acl document.

Draft status:

 cldap: there is a new draft -01.

 C API: no progress since last meeting.

 duplicate entries: last call will be done after meeting.

 java API: in WG last call.

 matched valued: last call will be done after meeting.

 referrals: last call on Kurt's document will be done after meeting.
 no progress for other referral types.

 server discovery: would like to last call the locate document after the
 meeting.  The taxonomy document is waiting on locate. 

 subentries: there is a new draft -07.

 X.509 SASL mechanism: no WG activity, would like to push out of WG and 
 make an individual work item.

 VLV: pending on the resolution of result codes, but otherwise done.

There was a brief charter discussion: What is LDAPEXT heading for??
Many possible future work items were discussed at the last meeting, but
other than those around schema update (to be discussed at the end of this
meeting), there was not a sign of significant interest from many different
people in working on them, only a few people seemed interested in these 
work items.

Charter and futures discussion taken to the mailing list.

Extension guide
===============

Topics discussed: result codes, meaning of multiple controls, 
border between defining new extensions and controls, extension to the ASN.1.

Result codes: How to extend result codes? A result code for controls? 

Kurt Zeilenga proposed having an IANA registry and a review process.  He
will write a BCP for last calling in both LDAPBIS and LDAPEXT.  

Bob Morgan suggested also a directorate to review other uses of LDAP.  Those 
discussions would then not need to occur on the working group mailing lists.
Ed Reed emphasised the need for review, to differentiate the use of 
extensions to the directory for using the directory, versus using LDAP as 
an arbitrary RPC.  Kurt Zeilenga recommended that this group would not itself
have enforcement power to restrict what implementors would do, but could
prevent conflicts through the use of a registry of known extensions.  

Multiple controls: what happens when this interaction is not defined?  There
could be a mismatch between this and the extensions handling behavior in 
X.500 and in PKIX for certificate extensions.  Kurt Zeilenga recommended not 
specifying the behavior for LDAP in order to avoid constraining controls: if
clients want particular semantics they should mark the controls as critical.
As there has been discussion for existing controls and their interaction,
Mark Wahl added that when an existing control RFC goes to Draft Standard
status, then textual clarifications could be added to resolve ambiguities.

When to define an extension versus when to define a control: should be in 
the extensions guide.

How much to change in the ASN.1 when extending?  Kurt Zeilenga proposed that
the type or scope of an extension could change the PDU if the peer advertised
support for it; others that the extension should not contradict the 
underlying specification. 

Server discovery through DNS (Bob Morgan)
=========================================

The document contains an algorithm to map some distinguished names to domain 
names.  Tim Polk, co-chair of PKIX, said he would like to use this general 
approach to locate directory servers, but the locate draft is too rigid.
PKI today has no global directory infrastructure, so a PKI user needs to find 
information from directory servers in other organizations.  One solution is 
to embed information into certificates and CRLs, such as the name of the 
repository, but this is not elegant. The PKI repository locator service uses 
DNS to find it: it will become an experimental RFC as it covers any possible 
protocol.  There is a need to find directories, and for that they need to
find out what the domain name is of the end-cert organization.

PKIX's specifications are agnostic about names: DN might be composed of any 
attributes.   Early adopters of PKI have used X.520 attributes: their 
certificates have had names rooted in C=US etc.  Tim Polk proposed that 
locate would be more useful with this change: process all RDN components, 
ignoring those which are not domain components.  While future deployments
might move to DC components entirely, this change would provide a 
migration strategy.

Some of the issues discussed:
 - The locate draft is based on RFC 2247, which is a bidirectional mapping.
   Would it be necessary to update 2247 as well?  (Mark Wahl)

 - This change may also imply a change in multivalued attributes processing.
   (Bob Morgan)

 - End users could add DC components 'below' their name, this might have 
   a security consideration.  (Kurt Zeilenga)

 - Also need to consider internationalized domain components. (Kurt Zeilenga)

 - Is the specification the only way to map from distinguished names to 
   domain names?  If this specification were to be a Proposed Standard,
   could there be others, for example to consider the problem where there
   are domain components elsewhere in the DN?  (Paul Leach)

 - There is a different approach from ITU-T/ISO X.500 for more general 
   mapping of distinguished names, based on a new DNS resource record.
   Skip Slone will publish an internet draft. (Skip Slone)

 - A variant which allows for any domain components (not just those on the
   right) to be used only if the certificate can be validated, by
   'canonicalizing' the DN. (Paul Leach)

 - Domain entries below organizations may not be supported by the 
   current DIT containment rules in X.500. (Ed Reed)

 - When using TLS, there are rules for matching names in server certificates.
   (Bob Morgan)

The document authors will get input and review possible changes.  If there
are changes and a new internet draft, it might need to go back through WG 
last call.
 
ACL
===

Issues:
 - application defined permission and extensibility
 - extensible operation permission
 - replication requirements

Ellen Stokes said that it was resolved at a prior meeting that application
defined permission would be out of scope.  Kurt Zeilenga added that a new
attribute type could be defined. 

As John Strassner, co-chair of LDUP, requested that replication requirements 
of a document should be addressed in the working group where the document is 
authored, Rick Huber will incorporate replication requirements into the 
access control drafts.  This will be completed by the next meeting, with 
a draft in June suitable for last call.

Subentry-07 (Ed Reed)
====================

Changes in subentry -07:
 - applied changes requested at last IETF,
 - removed inheritance propigation discussion to draft-reed-,
 - removed search filter mechanism, to avoid the complexity of search filters,
   use control only or base object search.

Kurt Zeilenga added that he would like to allow for any scope search to
match subentries if the base of the search is a subentry.

Ed Reed will separate inheritableLDAPSubentry to a different document, and
issue revision -08.

LDAP Schema update procedures (Tim Hahn)
========================================

Follow on from a Bar BOF at San Diego.

Topic areas of interest:

 - procedures for merging and updating schema in server.

 - extensions to attributeTypes and objectClasses BNF for flags, such as 
   uniqueness, referential integrity etc.

 - determine allowable changes to existing schema entries,  e.g. changing 
   matching rules of an attribute might do harm (cause inconsistency in the 
   DIT).

 - define procedures for partitioning schema.

 - Define how to ensure that unique attribute and object class names are used.

 - Allow clients to discover attribute type options e.g. ;binary.

There is some interest in this work area.  There was discussion of whether  
this belongs in LDAPEXT, or might be a new follow-on working group. 

End of Meeting
==============

--------------F25D8A5AD31CDA5B715971AA--



From list@netscape.com  Tue Apr 17 15:47:21 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15014
	for ; Tue, 17 Apr 2001 15:47:20 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3HJjAS26655;
	Tue, 17 Apr 2001 12:45:10 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3HJi5M04867;
	Tue, 17 Apr 2001 12:44:05 -0700 (PDT)
Resent-Date: Tue, 17 Apr 2001 12:44:05 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010417112532.00aa1750@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 17 Apr 2001 12:41:19 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" 
Subject: ACM & Replication (Was: LDAPEXT Minutes)
Cc: ietf-ldup@imc.org
In-Reply-To: <3ADC83B2.D25E2ECB@sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"VVttM.A.qJB.2zJ36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 10:56 AM 4/17/01, Mark Wahl wrote:
>ACL
> - replication requirements
>
>As John Strassner, co-chair of LDUP, requested that replication requirements 
>of a document should be addressed in the working group where the document is 
>authored, Rick Huber will incorporate replication requirements into the 
>access control drafts.

Is there a description of what "replication requirements" which
need to be addressed?  I can find no discussion of replication
requirements upon the LDAP ACM in RFC 2820 nor the LDUP requirements
document (though the latter details requirements upon LDUP to
replicate access control information).

Thanks, Kurt



From list@netscape.com  Tue Apr 17 17:03:25 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16571
	for ; Tue, 17 Apr 2001 17:03:23 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3HL1BS10491;
	Tue, 17 Apr 2001 14:01:11 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3HL1C215246;
	Tue, 17 Apr 2001 14:01:12 -0700 (PDT)
Resent-Date: Tue, 17 Apr 2001 14:01:12 -0700 (PDT)
Date: Tue, 17 Apr 2001 17:00:14 -0400
Message-Id: <200104172100.RAA17101@qsun.mt.att.com>
From: rvh@qsun.mt.att.com (Richard V Huber)
To: Kurt@openldap.org, ietf-ldapext@netscape.com
Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
Cc: ietf-ldup@imc.org
Resent-Message-ID: <"L1r5a.A.ysD.T8K36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

The main replication-related change to the ACM draft is to make it
clear that the ACM applies to wire-line flows of data being
replicated.

Ellen Stokes agreed to add that to the ACM draft.  I'll propose
specific wording if needed.

Rick Huber

: To: ietf-ldapext@netscape.com
: From: "Kurt D. Zeilenga" 
: Subject: ACM & Replication (Was: LDAPEXT Minutes)
: Cc: ietf-ldup@imc.org
: 
: At 10:56 AM 4/17/01, Mark Wahl wrote:
: >ACL
: > - replication requirements
: >
: >As John Strassner, co-chair of LDUP, requested that replication requirements 
: >of a document should be addressed in the working group where the document is 
: >authored, Rick Huber will incorporate replication requirements into the 
: >access control drafts.
: 
: Is there a description of what "replication requirements" which
: need to be addressed?  I can find no discussion of replication
: requirements upon the LDAP ACM in RFC 2820 nor the LDUP requirements
: document (though the latter details requirements upon LDUP to
: replicate access control information).
: 
: Thanks, Kurt



From list@netscape.com  Tue Apr 17 18:54:29 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17600
	for ; Tue, 17 Apr 2001 18:54:28 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3HMoxv29606;
	Tue, 17 Apr 2001 15:50:59 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3HMp0Y08885;
	Tue, 17 Apr 2001 15:51:00 -0700 (PDT)
Resent-Date: Tue, 17 Apr 2001 15:51:00 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010417142830.00a7d970@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 17 Apr 2001 15:48:33 -0700
To: rvh@qsun.mt.att.com (Richard V Huber)
From: "Kurt D. Zeilenga" 
Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
Cc: ietf-ldapext@netscape.com, ietf-ldup@imc.org
In-Reply-To: <200104172100.RAA17101@qsun.mt.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"sTVoa.A.TKC.SjM36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 02:00 PM 4/17/01, Richard V Huber wrote:
>The main replication-related change to the ACM draft is to make it
>clear that the ACM applies to wire-line flows of data being
>replicated.

Are you saying here that LDAP ACM would be used to control what
was replicated between servers?  That seems presumptive.

>Ellen Stokes agreed to add that to the ACM draft.  I'll propose
>specific wording if needed.

Please do. That would allow some WG discussion of the specifics.
I certainly not sure what type of clarification you trying to
make.

I note I belief that the section paragraph of the Introduction and
the second paragraph of the Security Considerations were pretty
clear as how LDAP replication issues related to the LDAP ACM
are to be addressed.  That is, such issues are "out of scope".
I would certainly question any attempt to bring them into scope.

Kurt



From list@netscape.com  Tue Apr 17 19:19:45 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17957
	for ; Tue, 17 Apr 2001 19:19:45 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3HNHZS04882;
	Tue, 17 Apr 2001 16:17:36 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3HNHaQ22387;
	Tue, 17 Apr 2001 16:17:36 -0700 (PDT)
Resent-Date: Tue, 17 Apr 2001 16:17:36 -0700 (PDT)
Date: Tue, 17 Apr 2001 19:16:59 -0400
Message-Id: <200104172316.TAA01088@qsun.mt.att.com>
From: rvh@qsun.mt.att.com (Richard V Huber)
To: Kurt@openldap.org
Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
Cc: ietf-ldapext@netscape.com, ietf-ldup@imc.org
Resent-Message-ID: <"5JJdzC.A.HdF.O8M36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

: Are you saying here that LDAP ACM would be used to control what
: was replicated between servers?  That seems presumptive.

No, replication agreements control what is replicated among servers.

All I'm saying is that the format specified by the ACM for representing
access control information on the wire is also the format LDUP should
use to transport access control information during replication.  So
there should be a few additions to the ACM draft to clarify this
additional intended use.

Rick Huber

: From Kurt@OpenLDAP.org Tue Apr 17 18:50:59 2001
: Return-Path: 
: X-Sender: guru@127.0.0.1
: To: rvh@qsun.mt.att.com (Richard V Huber)
: From: "Kurt D. Zeilenga" 
: Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
: Cc: ietf-ldapext@netscape.com, ietf-ldup@imc.org
: Mime-Version: 1.0
: 
: At 02:00 PM 4/17/01, Richard V Huber wrote:
: >The main replication-related change to the ACM draft is to make it
: >clear that the ACM applies to wire-line flows of data being
: >replicated.
: 
: Are you saying here that LDAP ACM would be used to control what
: was replicated between servers?  That seems presumptive.
: 
: >Ellen Stokes agreed to add that to the ACM draft.  I'll propose
: >specific wording if needed.
: 
: Please do. That would allow some WG discussion of the specifics.
: I certainly not sure what type of clarification you trying to
: make.
: 
: I note I belief that the section paragraph of the Introduction and
: the second paragraph of the Security Considerations were pretty
: clear as how LDAP replication issues related to the LDAP ACM
: are to be addressed.  That is, such issues are "out of scope".
: I would certainly question any attempt to bring them into scope.
: 
: Kurt



From list@netscape.com  Tue Apr 17 19:31:57 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18194
	for ; Tue, 17 Apr 2001 19:31:56 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3HNTmv06147;
	Tue, 17 Apr 2001 16:29:48 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3HNTnU29258;
	Tue, 17 Apr 2001 16:29:49 -0700 (PDT)
Resent-Date: Tue, 17 Apr 2001 16:29:49 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010417161749.00a9e620@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 17 Apr 2001 16:27:24 -0700
To: rvh@qsun.mt.att.com (Richard V Huber)
From: "Kurt D. Zeilenga" 
Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
Cc: ietf-ldapext@netscape.com, ietf-ldup@imc.org
In-Reply-To: <200104172316.TAA01088@qsun.mt.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"lwhjRB.A.XIH.rHN36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 04:16 PM 4/17/01, Richard V Huber wrote:
>: Are you saying here that LDAP ACM would be used to control what
>: was replicated between servers?  That seems presumptive.
>
>No, replication agreements control what is replicated among servers.
>
>All I'm saying is that the format specified by the ACM for representing
>access control information on the wire is also the format LDUP should
>use to transport access control information during replication.  So
>there should be a few additions to the ACM draft to clarify this
>additional intended use.

It seems to me that the need for this clarification is this
statement in Section 2:
  No mechanism is defined in this document for storage of
  access control information at the server beyond indicating
  that the attribute holding access control information is an
  operational attribute.

This statement I find odd as LDAP doesn't define any mechanism
for storage of any information beyond that of the data model.
Like any other attribute, the server is free to store it as it
pleases.

I think it unwise to add a replication specific clarification.
What's needed is an data model clarification... that is, servers
MUST implement ldapACI and other attributes in accordance to
the X.500 data and service model per RFC 2251, 3.3.

Kurt



From list@netscape.com  Tue Apr 17 21:56:15 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20605
	for ; Tue, 17 Apr 2001 21:56:14 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3I1s9S29752;
	Tue, 17 Apr 2001 18:54:09 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3I1sAk10121;
	Tue, 17 Apr 2001 18:54:10 -0700 (PDT)
Resent-Date: Tue, 17 Apr 2001 18:54:10 -0700 (PDT)
Message-Id: <5.0.2.1.0.20010417204927.00a78ce0@popmail2.austin.ibm.com>
X-Sender: stokes@popmail2.austin.ibm.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 17 Apr 2001 20:53:59 -0500
To: "Kurt D. Zeilenga" ,
        rvh@qsun.mt.att.com (Richard V Huber)
From: Ellen Stokes 
Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
Cc: ietf-ldapext@netscape.com, ietf-ldup@imc.org
In-Reply-To: <5.1.0.14.0.20010417142830.00a7d970@127.0.0.1>
References: <200104172100.RAA17101@qsun.mt.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Resent-Message-ID: <"HonWRB.A.xdC.APP36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

 From discussion with Rick Huber in Minneapolis, the following paragraphs
of the model draft have been modified and now read as follows (excerpted
from their sections with section headers):

2.  The LDAPv3 Access Control Model
    - What flows on the wire for interoperability

      The existing LDAP protocol flows for ldap operations
      are used to manipulate access control information.
      These same flows on the wire apply when ACI is
      transmitted during replication.  A set of permissions
      and their semantics with respect to ldap operations is
      defined.  The permissions parallel the defined set of
      ldap operations.  What is transmitted is exactly what
      is read back.  Encoding of access control information
      on the wire is per the LDAPv3 specifications.

4.  The Access Control Information Attributes and Syntax
The attributes are defined so access control information
(ACI) can be addressed in a server independent of server
implementation.  These attributes are used in typical LDAP
APIs, in LDIF output of ACI and in transfer of ACI during
replication. These attributes may be queried or set on all
directory objects.  The BNF and definitions are given below.

Ellen


At 03:48 PM 4/17/2001 -0700, Kurt D. Zeilenga wrote:
>At 02:00 PM 4/17/01, Richard V Huber wrote:
> >The main replication-related change to the ACM draft is to make it
> >clear that the ACM applies to wire-line flows of data being
> >replicated.
>
>Are you saying here that LDAP ACM would be used to control what
>was replicated between servers?  That seems presumptive.
>
> >Ellen Stokes agreed to add that to the ACM draft.  I'll propose
> >specific wording if needed.
>
>Please do. That would allow some WG discussion of the specifics.
>I certainly not sure what type of clarification you trying to
>make.
>
>I note I belief that the section paragraph of the Introduction and
>the second paragraph of the Security Considerations were pretty
>clear as how LDAP replication issues related to the LDAP ACM
>are to be addressed.  That is, such issues are "out of scope".
>I would certainly question any attempt to bring them into scope.
>
>Kurt



From list@netscape.com  Tue Apr 17 22:46:18 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22021
	for ; Tue, 17 Apr 2001 22:46:17 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3I2gcS04261;
	Tue, 17 Apr 2001 19:42:38 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3I2gdY25149;
	Tue, 17 Apr 2001 19:42:39 -0700 (PDT)
Resent-Date: Tue, 17 Apr 2001 19:42:39 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010417190437.00a952b0@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 17 Apr 2001 19:39:54 -0700
To: Ellen Stokes 
From: "Kurt D. Zeilenga" 
Subject: Re: ACM & Replication (Was: LDAPEXT Minutes)
Cc: rvh@qsun.mt.att.com (Richard V Huber), ietf-ldapext@netscape.com,
        ietf-ldup@imc.org
In-Reply-To: <5.0.2.1.0.20010417204927.00a78ce0@popmail2.austin.ibm.com>
References: <5.1.0.14.0.20010417142830.00a7d970@127.0.0.1>
 <200104172100.RAA17101@qsun.mt.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"rG68uB.A.dIG.d8P36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 06:53 PM 4/17/01, Ellen Stokes wrote:
>From discussion with Rick Huber in Minneapolis, the following paragraphs
>of the model draft have been modified and now read as follows (excerpted
>from their sections with section headers):
>
>2.  The LDAPv3 Access Control Model
>   - What flows on the wire for interoperability
>
>     The existing LDAP protocol flows for ldap operations
>     are used to manipulate access control information.
>     These same flows on the wire apply when ACI is
>     transmitted during replication.  A set of permissions
>     and their semantics with respect to ldap operations is
>     defined.  The permissions parallel the defined set of
>     ldap operations.  What is transmitted is exactly what
>     is read back.  Encoding of access control information
>     on the wire is per the LDAPv3 specifications.

This basically says:
        Access control information is represented as elements
        of the LDAP data model and can be manipulated using
       normal LDAP operations.  A set of permissions and their
       semantics with respect to LDAP operations is defined.  The
       permissions parallel the defined set of LDAP operations.

That is, LDAP defines the wire format of LDAP operations
including data elements.  All this "on the wire" stuff just
muddies the waters and is completely unnecessary. 

I note that statement:
      "What is transmitted is exactly what is read back."

implies that the server is not free to store the values as it
pleases (which is contrary to other statements in the ACM as
well as rfc2251).  The data and service model only requires,
in general, that information can be read back in an equivalent
form.  This is needed to support multiple transfer modes
(string v. ;binary) and to give the server to store the data
in alternative forms, such as needed to support other
protocols/services.

>4.  The Access Control Information Attributes and Syntax
>The attributes are defined so access control information
>(ACI) can be addressed in a server independent of server
>implementation.

Suggest replacing "can be... " with:
    can be represented in an implementation independent
    manner.

>These attributes are used in typical LDAP
>APIs, in LDIF output of ACI and in transfer of ACI during
>replication.

s/are used/may be used/

>These attributes may be queried or set on all
>directory objects.  The BNF and definitions are given below.



From list@netscape.com  Wed Apr 18 03:43:20 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07730
	for ; Wed, 18 Apr 2001 03:43:19 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3I7f1v29663;
	Wed, 18 Apr 2001 00:41:02 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3I7f2w12179;
	Wed, 18 Apr 2001 00:41:02 -0700 (PDT)
Resent-Date: Wed, 18 Apr 2001 00:41:02 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010418002939.00ac8b70@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 18 Apr 2001 00:38:37 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" 
Subject: IANA Considerations for LDAP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"9vuIOC.A.39C.MUU36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

As indicated at IETF#50, I put together an I-D detailing
IANA Considerations for LDAP .
Please post technical comments to 
and editorial comments directly to me.  As noted in the
LDAPext minutes, this I-D will eventually be last called in
both WG so please review early and often.

Kurt



From list@netscape.com  Wed Apr 18 11:25:48 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12841
	for ; Wed, 18 Apr 2001 11:25:47 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3IFN3v15578;
	Wed, 18 Apr 2001 08:23:03 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3IFN3s27400;
	Wed, 18 Apr 2001 08:23:03 -0700 (PDT)
Resent-Date: Wed, 18 Apr 2001 08:23:03 -0700 (PDT)
Message-Id: <200104181441.f3IEfD621780@relay.fujitsu.es>
From: PenisGrowth@hotmail.com
Subject: Enlarge your penis in 2 weeks, guaranteed!
Date: Tue, 17 Apr 2001 13:45:55 -0800
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_5882_0000258A.00006FA8"
X-Priority: 3
X-MSMail-Priority: Normal
Resent-Message-ID: <"ivlhLC.A.xqG.UFb36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

------=_NextPart_000_5882_0000258A.00006FA8
Content-Type: text/html;











Guys, add 2-4 inches to your penis within a few short weeks, Guaranteed!  Our program provides time tested methods, proven to work by top medical professionals. Our program has an over 98% success rate, and results are a promise. You have nothing to lose! CLICK HERE TO SEE!!





------=_NextPart_000_5882_0000258A.00006FA8--


From list@netscape.com  Wed Apr 18 11:54:00 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13310
	for ; Wed, 18 Apr 2001 11:53:59 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3IFppv20196;
	Wed, 18 Apr 2001 08:51:51 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3IFppo12656;
	Wed, 18 Apr 2001 08:51:51 -0700 (PDT)
Resent-Date: Wed, 18 Apr 2001 08:51:51 -0700 (PDT)
Date: Wed, 18 Apr 2001 11:51:44 -0400
Message-Id: <200104181551.LAA12275@qsun.mt.att.com>
From: rvh@qsun.mt.att.com (Richard V Huber)
To: Kurt@openldap.org, ietf-ldapext@netscape.com
Subject: Re: IANA Considerations for LDAP
Resent-Message-ID: <"p9rGgB.A.YFD.Vgb36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Should the use of "e-" be restricted only to experimental attribute
result codes and authentication mechanisms?  If someone wants to
register "e-commerce-auth" as an authentication mechanism in a
Standards Action, it is allowed?

The draft is clear that e- is reserved solely for experimental use for
OID names and attribute options, but it not is clear for result codes
or authentication methods (it is clear that experimental codes and
methods MUST start with e-, but not whether non-experimental names MAY
start with e-).

I think we should have consistency.  Either e- may only be used for
experimental OID names, attribute options, result codes, and
authentication methods or all experimental names, etc. MUST start with
e- but other names MAY also start with e-.

Rick Huber



From list@netscape.com  Thu Apr 19 12:14:33 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13763
	for ; Thu, 19 Apr 2001 12:14:33 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3JGCOS08213;
	Thu, 19 Apr 2001 09:12:25 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3JGCPA19029;
	Thu, 19 Apr 2001 09:12:25 -0700 (PDT)
Resent-Date: Thu, 19 Apr 2001 09:12:25 -0700 (PDT)
From: bill4h56@china.com
Message-ID: <000012b66310$000075e7$00002510@mail.aisco.com>
To: 
Subject: PAGING AMERICA...
Date: Thu, 19 Apr 2001 10:44:17 -0600
X-Priority: 1
X-MSMail-Priority: High
Reply-To: will349j@china.com
X-Mailer:  Mozilla 4.72 [en] (Win98; U)
Resent-Message-ID: <"FpmnzC.A.soE.n5w36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

NO long term contract
NO big prepayment of airtime
NO credit check

PUT FREE PAGERS ON YOUR KIDS - Give one to your loved ones - For FREE

Here at Paging America we are excited to be offering you this
exclusive, top of the line, full featured pager in your choice
of color for FREE. This side viewable display pager is one of
the smallest and lightest pagers on the market today.


Call Toll Free 1-800-443-3122  to be Guaranteed Your FREE Pager Today


Your pager will hold up to 20 numeric messages. It has 9 music
alerts and silent vibration. New FLEX technology provides three
times the battery life. Also, message time and date stamping and
smart alarm so you can set a daily or weekly reminder.
This pager comes in black, teal and blue. 

To receive your free pager ALL WE ASK is that you allow us to
provide you with the monthly airtime cancelable at any time.
There is NO long term contract.
Just call the toll free number and we'll ship your Free pager to
you immediately in your choice of color already programmed with
a local telephone number for your town. 

Make this easy phone call and we will deliver your pager immediately.
CALL Toll free 1-800-443-3122  to get in on this exciting offer today

Under Bill s. 1618 TITLE III passed by the 105th Congress this letter cannot be considered spam as long
as the sender includes contact information and removal instructions.
This is a one-time e-mail transmissiom. No removal is necessary.   



From list@netscape.com  Thu Apr 19 13:03:02 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14424
	for ; Thu, 19 Apr 2001 13:03:02 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3JH0qS18547;
	Thu, 19 Apr 2001 10:00:53 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3JGpNY18245;
	Thu, 19 Apr 2001 09:51:23 -0700 (PDT)
Resent-Date: Thu, 19 Apr 2001 09:51:23 -0700 (PDT)
Date: Thu, 19 Apr 2001 09:47:22 -0700
To: ietf-ldapext@qnmieqxv.netscape.com
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7BIT
From: TheInternetSpy_Pkg18@fnmxtm.excite.com.netscape.com
Message-Id: 
Subject: Are You Being Investigated? -swqmhy
Resent-Message-ID: <"ybjqKD.A.XaE.Eex36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7BIT

READY TO KNOW?

 CONFIDENTIAL!

 The KIT They Want BANNED In all 50 STATES.
 Why?  Because these secrets were never intended to reach your eyes...
 Get the facts on anyone!

 Locate Missing Persons, find Lost Relatives, obtain Addresses
 and Phone Numbers of old school friends, even Skip Trace Dead
 Beat Spouses.  This is not a Private Investigator, but a
 sophisticated KIT DESIGNED to automatically
 CRACK YOUR CASE with links to thousands of Public Record databases.

 Find out SECRETS about your relatives, friends, enemies,
 and everyone else!  Even your spouse!  With the New,

               INTERNET SPY KIT AND YOU!

 It's absolutely astounding!  Here's what you can learn.

 License plate number!
 Get anyone's name and address with just a license plate number!
 (Find that Person you met in traffic!)

 Driving record!
 Get anyone's driving record!

 Social security number!
 Trace anyone by social security number!

 Address!
 Get anyone's address with just a name!

 Unlisted phone numbers!
 Get anyone's phone number with just a name even unlisted numbers!

 Locate!
 Long lost friends, relatives, a past lover who broke your heart!

 E-mail!
 Send anonymous e-mail completely untraceable!

 Dirty secrets!
 Discover dirty secrets your in-laws don't want you to know!

 Investigate anyone!
 Use the sources that private investigators use (all on the Internet)
 Secretly!

 Ex-spouse!
 Learn how to get information on an ex-spouse that will help you
 win in court! (Dig up old skeletons)!

 Criminal search Background check!
 Find out about your daughter's boyfriend!

 Find out!
 If you are being investigated!

 Neighbors!
 Learn all about your mysterious neighbors!  Find out what they
 have to hide!

 People you work with!
 Be astonished by what you'll learn about people you work with!

 Education verification!
 Did he really graduate college?  Find out!

 Internet Spy and You!
 THIS KIT will help you discover ANYTHING about anyone, with
 Click-able hyperlinks and no typing in internet addresses!  Just
Open the page and Go!

 You will be shocked and amazed by the secrets that can be
 discovered about absolutely everyone!  Find out the secrets
 they don't want you to know!  About others, about yourself!

 It's INCREDIBLE what you can find out using Internet Spy Kit!
 You'll be riveted to your computer screen!
 Get the KIT they're trying to ban!  Before it's too late!

 LIMITED TIME OFFER ORDER TODAY!

 Only $25.00

 We will RUSH YOU our Internet Spy Kit and You can
 begin discovering all the secrets you ever wanted to know!

 You can Know EVERYTHING about ANYONE with our Internet Spy and
 Your Software.  Works with all browsers and all versions of AOL!

 ORDER TODAY.


 DON'T WAIT TO GET STARTED...It's fast and easy

               CREDIT CARD ORDERS ONLY

 Call or Fax your order in today!

 Phone Orders Call:   1-(480)-990-4463    ASK FOR EXT. 7

 Fax Orders To:         1-(413) 714-9380

 Name:  ________________________________________

 Address: ________________________________________

 City/State/Zip: ______________________________________

 Email Address to Ship Orders to: _____________________________________

 FOR CREDIT CARD ORDERS ONLY!

 Account Number: ____________________________________

 Exp. Date: ________________________


 DISCLAIMER:  The seller of this powerful resource kit will not be
 held responsible for how the purchaser chooses to use it's resources.

 Thank you

****************Remove Instructions********************
********************************************************
To be removed from future mailings!!!!
All REMOVE requests AUTOMATICALLY honored upon receipt.
consumer-removal30@excite.com?subject=REMOVESPY
PLEASE understand that any effort to disrupt,
close or block this REMOVE account can only result
in difficulties for others wanting to be removed from
our mailing list as it will be impossible to take anyone
off the list if the remove instruction is not received.
*******************************************************




From list@netscape.com  Thu Apr 19 17:37:53 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18793
	for ; Thu, 19 Apr 2001 17:37:52 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3JLZYv26542;
	Thu, 19 Apr 2001 14:35:35 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3JLZZQ17606;
	Thu, 19 Apr 2001 14:35:35 -0700 (PDT)
Resent-Date: Thu, 19 Apr 2001 14:35:35 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010419142538.00a8d550@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 19 Apr 2001 14:33:16 -0700
To: robert byrne 
From: "Kurt D. Zeilenga" 
Subject: Re: browse permission in the ACM
Cc: ietf-ldapext@netscape.com
In-Reply-To: <3ADF0221.A6D2875A@Sun.COM>
References: <200104101510.LAA24387@qsun.mt.att.com>
 <3AD43163.78E8FA8F@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"JPZn8D.A.sSE.mo136"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com


>Maybe now is a good time to list the options (that I can think of) open
>to us for this browsing concept:

It might be more appropriate to discuss "browsing" in terms
of "finding" vs the "searching".   I would rather the
scope of search not matter to the evaluation of search
in respect to a particular entry.

Kurt



From list@netscape.com  Fri Apr 20 05:13:59 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09245
	for ; Fri, 20 Apr 2001 05:13:59 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3K914v11764;
	Fri, 20 Apr 2001 02:01:04 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3K915603535;
	Fri, 20 Apr 2001 02:01:05 -0700 (PDT)
Resent-Date: Fri, 20 Apr 2001 02:01:05 -0700 (PDT)
Sender: Robert.Byrne@Sun.COM
Message-ID: <3ADFFA8E.8C0423DD@Sun.COM>
Date: Fri, 20 Apr 2001 10:59:58 +0200
From: robert byrne 
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Richard V Huber 
CC: ietf-ldapext@netscape.com
Subject: Re: browse permission in the ACM
References: <200104192007.QAA24666@qsun.mt.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"KgXHNC.A.N1.Kr_36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Richard V Huber wrote:
> 
> As I understand Option 3, it says that the "b" permission is not
> checked on the base object of a search.
> 
> I'm trying to figure out what permissions would be checked for the base
> object under option 3.  For example, item 1 in section 5.2 would not
> seem to apply when the candidateDN is the base object.  How about the
> part of item 2 that discusses extensibleMatch?

The idea is that "b" gives you the right to find an entry using the
subtree and onlevel options of search.  For a base entry, we do not
require "b" because you have named it.  We would still require the other
permissions (filter, returnDn, readOnAttribute) for a base entry.  Where
we refer to "b" in those sections we should say something like "as per
item 1."--ie. we never require "b" on base entries.

> 
> One of the reasons I had not responded to your previous email is that
> I'm still trying to figure out whether these questions really matter in
> practical directories.

Good question--I agree the effect is a bit subtle and not obviously a
mandatory feature.  It's another level of granularity of control on
search.  I think you can see a similar effect in the Unix file system
where you can be in a directory and type "ls" and see nothing but if you
do, say, "cd public_html" you will find yourself in that directory, if
you have the appropriate rights.  In LDAP, you might want to have a
subtree with resources users can query if they know about them, but not
be able to discover resources "easily".

At Pittsburg people seemed to like the browsing idea and I agreed to
propose something.

Rob.

> 
> Rick Huber
> 
> : Sender: Robert.Byrne@Sun.COM
> : From: robert byrne 
> : To: ietf-ldapext@netscape.com
> : Subject: Re: browse permission in the ACM
> :
> :
> : All,
> :
> : By way of a partial conclusion of this thread, for the next draft I
> : intend to propose 3. below.
> :
> : Rob.
> :
> : robert byrne wrote:
> : >
> : > Rick,
> : >
> : > Maybe now is a good time to list the options (that I can think of) open
> : > to us for this browsing concept:
> : >
> : > 1. Keep it as is in section 5.2, so that "b" is just an entry-level
> : > permission you need on all entries when you search.
> : >
> : > 2. Drop it entirely, so that we have no dedicated entry-level permission
> : > on search.  For example, we don't have an entry-level Modify
> : > permission.  In this model, we would be relying on the returnDn
> : > permission for entry-level protection.  I guess "entry-level protection"
> : > of an entry in the context of search means protecting the dn so this
> : > seems to make sense.
> : >
> : > 3. Keep "b" but only require it on non-base entries.  This means that
> : > you can control the power of the subtree and onelevel search options on
> : > your DIT.
> : >
> : > 4. Keep "b" but only require it on non-base entries AND introduce a "v"
> : > which you are now required to see base entries of searches.  This means
> : > that you can control the power of the subtree and onelevel search
> : > options on your DIT AND allows you to explicitly protect bases of
> : > searches at the entry level.
> : >
> : > 5. As 4. but have "b"=>"v", so that if you want you can forget about "v"
> : > and just use "b" as in 1.  This is what I proposed in my earlier mail.
> : >
> : > I agree that it is not worth complicating things for this browsing
> : > capability.  Given this, if people like the ability to put a brake on
> : > the subtree and onelevel options (I guess the use of these options is
> : > what we mean by "browsing" in LDAP), I'm tempted to propose 3. as the
> : > simplest option.  After that if we consider that controling browsing is
> : > not important, I'm tempted by 2., namely dropping "b" entirely...though
> : > we'd need to check that this doesn't leave some holes.
> : >
> : > Any votes/opinions on these options ?
> : >
> : > Rick, for your other point on aborting searches re the returnDn
> : > permission, I would prefer to discuss that in a different thread called
> : > something like "protecting dns in the ACM", as I think it desreves a
> : > discussion itself.
> : >
> : > Rob.
> : >
> : > Richard V Huber wrote:
> : > >
> : > > Since Rob says `To minimize the number of combinations we also allow
> : > > the base element to be seen if "b" permission is assigned to it', it
> : > > seems that the new "b" includes the new "v" and is identical to the old
> : > > "b".  So the real change here is the addition of the separate "v"
> : > > permission.
> : > >
> : > > So I assume new the definitions of "b" and "v" in section 4.2.1 would
> : > > be something like (trying to stay reasonably close to the current
> : > > wording):
> : > >
> : > >   b BrowseDN
> : > >
> : > >   If granted, permits entries to be accessed using search operations
> : > >   regardless of whether they explicitly provide the name of the entry.
> : > >
> : > >   v VertexDN
> : > >
> : > >   If granted, permits entries to be accessed using search operations
> : > >   only if the name of the entry is explicitly supplied.
> : > >
> : > > I guess my main question is whether the change is worth it.  The model
> : > > is already rather complicated.  Does this change provide value that is
> : > > worth the additional complexity?  I'm not sure that it does.
> : > >
> : > > And one other vaguely related question that came to mind after reading
> : > > Rob's email.  He notes that "... the absence of a "v" or "b" permission
> : > > at any point does not abort the search operation as a whole or even on
> : > > a particular subtree."
> : > >
> : > > I have been assuming (and this seemed like a good time to check) that
> : > > absence of a "t" permission DOES abort the search operation on a
> : > > particular subtree, since returning the DN of any object further down
> : > > in the tree would require that the DN of the object without "t"
> : > > permission be returned.  Is that the generally accepted view?
> : > >
> : > > Rick Huber
> : > >
> : > > : Sender: Robert.Byrne@Sun.COM
> : > > : From: robert byrne 
> : > > : To: ietf-ldapext@netscape.com
> : > > : Subject: browse permission in the ACM
> : > > :
> : > > :
> : > > : All,
> : > > :
> : > > : The following is a proposal to tweak the current browse permission in
> : > > : the ACM.
> : > > : The current usage of the "b" permission in the ACM is really just a read
> : > > : level permission on candidate entries. From section 5.2:
> : > > :
> : > > : " 1.  permission "b" to the entry candidateDN
> : > > :
> : > > :       If this permission is not granted then the dn
> : > > :       candidateDN MUST NOT be returned nor any attribute
> : > > :       type nor attribute value from this entry.
> : > > :
> : > > :       If this permission is granted then the dn candidateDN
> : > > :       MAY be returned.
> : > > : "
> : > > :
> : > > : Some people felt that it would be better to have it behave more like
> : > > : it's name suggests...which is that you would require this permission to
> : > > : be able to have a search request return __non-base__ entries to you
> : > > : during a search.  The spirit of this idea is something like "Hang on,
> : > > : subtree and onelevel searches are really powerful, there should be a
> : > > : way continue to grant read access to entries, but to limit the power of
> : > > : these search options".
> : > > :
> : > > : One way to do this is to refine "b" into two permissions 'new "b"' and
> : > > : "v".
> : > > : The 'new "b"' still stands for browse and you will need this to see
> : > > : non-base entries.   At a stretch the "v" stands for "vertex" as you need
> : > > : this to see the base entry (the vertex) of a search.  (From now on "b"
> : > > : means 'new "b"'.) To minimize the
> : > > : number of combinations we also allow the base element to be seen if "b"
> : > > : permission is assigned to it.  So, the new text I am proposing for this
> : > > : would be:
> : > > :
> : > > :
> : > > : " 1.  permission "v" or "b" to the entry candidateDN, if the entry is
> : > > : the
> : > > :      base of the search operation.
> : > > :      permission "b" to the entry if the entry is not the base of the
> : > > : search.
> : > > :
> : > > :      If these conditions are not satisfied then the dn
> : > > :      candidateDN MUST NOT be returned nor any attribute
> : > > :      type nor attribute value from this entry.
> : > > :
> : > > :      If this permission is granted then the dn candidateDN
> : > > :      MAY be returned."
> : > > :
> : > > : Note that the absence of a "v" or "b" permission at any point does not
> : > > : abort the search operation as a whole or even on a particular subtree.
> : > > : We could specify such behaviour but I believe most LDAP implementations
> : > > : have an "optimistic" approach to searching for entries ie. I may be
> : > > : denied access to this entry, but there may be other entries to which I
> : > > : do have access, so keep searching.
> : > > :
> : > > : Note also that if you only ever use "b", it will behave just like a read
> : > > : level permission on the entry--we provide the "v" refinement for those
> : > > : users that might want to limit "browsability" of their DIT.
> : > > :
> : > > : An example.  Suppose that some given user has all rights on all
> : > > : these subtrees, the only difference being in allocation of the "b" and
> : > > : "v" rights which are shown in brackets, after the RDN of the entry.
> : > > :
> : > > :         ou=sun.com(b)
> : > > :         |
> : > > :         |------------------------------------------------
> : > > :         |                       |                       |
> : > > :         ou=sortOfBrowsable()    ou=notBrowsable(v)      ou=Browsable(b)
> : > > :         |                       |                       |
> : > > :         ou=level1(v)            ou=level1(v)            ou=level1(b)
> : > > :         |                       |                       |
> : > > :         ou=level2(b)            ou=level2(v)            ou=level2(b)
> : > > :
> : > > :
> : > > : Eg 1: If he does a search like this:
> : > > :
> : > > :         baseEntry: ou=sortOfBrowsable,o=sun.com
> : > > :         filter: ou=*
> : > > :         scope: subtree
> : > > :
> : > > : He will get back the following entry:
> : > > :
> : > > :         ou=level2,ou=sortOfBrowsable,ou=sun.com (has "b" on this)
> : > > :
> : > > : -----
> : > > :
> : > > : Eg 2: Then, if he does a search like this:
> : > > :
> : > > :         baseEntry: ou=sortOfBrowsable,o=sun.com
> : > > :         filter: ou=*
> : > > :         scope: base
> : > > :
> : > > : He will get back no entries (neither "v" nor "b" on the base).
> : > > :
> : > > : -----
> : > > :
> : > > : Eg 3: If he does a search like this:
> : > > :
> : > > :         baseEntry: ou=notBrowsable,ou=sun.com
> : > > :         filter: ou=*
> : > > :         scope: subtree
> : > > :
> : > > : He will get back the following entry:
> : > > :
> : > > :         ou=notBrowsable,ou=sun.com (has "v" and it's the base)
> : > > :
> : > > : -----
> : > > :
> : > > :
> : > > : Eg 4: If he does a search like this:
> : > > :
> : > > :         baseEntry: ou=notBrowsable,ou=sun.com
> : > > :         filter: ou=*
> : > > :         scope: base
> : > > :
> : > > : He will get back the following entry:
> : > > :
> : > > :         ou=notBrowsable,ou=sun.com (has "v" and it's the base)
> : > > :
> : > > : -----
> : > > :
> : > > :
> : > > : Eg 5: Then, if he does a search like this:
> : > > :
> : > > :         baseEntry: ou=Browsable,ou=sun.com
> : > > :         filter: ou=*
> : > > :         scope: subtree
> : > > :
> : > > : He will get back the following entries:
> : > > :         ou=Browsable,ou=sun.com       (has "b")
> : > > :         ou=level1,ou=Browsable,ou=sun.com (has "b")
> : > > :         ou=level2,ou=Browsable,ou=sun.com (has "b")
> : > > :
> : > > : -----
> : > > :
> : > > :
> : > > : Eg 6: Then, if he does a search like this:
> : > > :
> : > > :         baseEntry: ou=Browsable,ou=sun.com
> : > > :         filter: ou=*
> : > > :         scope: base
> : > > :
> : > > : He will get back the following entries:
> : > > :         ou=Browsable,ou=sun.com       (has "b")
> : > > :
> : > > : -----
> : > > :
> : > > :
> : > > : Eg 7: Then, if he does a search like this:
> : > > :
> : > > :         baseEntry: ou=sun.com
> : > > :         filter: ou=*
> : > > :         scope: onelevel
> : > > :
> : > > : He will get back the following entries:
> : > > :         ou=Browsable,ou=sun.com       (has "b")
> : > > :
> : > > : -----
> : > > :
> : > > : Any comments on this modification ?
> : > > :
> : > > : Rob.



From list@netscape.com  Fri Apr 20 15:15:23 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16665
	for ; Fri, 20 Apr 2001 15:15:22 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3KJDWS00710;
	Fri, 20 Apr 2001 12:13:32 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3KJDWs22824;
	Fri, 20 Apr 2001 12:13:32 -0700 (PDT)
Resent-Date: Fri, 20 Apr 2001 12:13:32 -0700 (PDT)
Message-ID: <3AE08A2C.186549CE@oracle.com>
Date: Fri, 20 Apr 2001 12:12:44 -0700
From: Himanshu Chatterjee 
Organization: Server Technologies
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ldapext@netscape.com, ietf-ldapext-request@netscape.com
Subject: piece wise retrieval of multivalued attrib.
X-Priority: 2 (High)
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"2-mvBB.A.bjF.ZpI46"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit



 

Hi,  Do we have any plans for a control which can retrieve the
attribute values of a multivalued attribute, piece wise and asyncronously.
This would be immensely helpful to retrieve values of a huge multivalued
attribute  ( like rfc822mailMembers or a mailGroup class, which can
potentially have a million values ). or there is a work around for this
fundamental problem.

Thanks

Himanshu Chatterjee

Oracle Corp,



From list@netscape.com  Fri Apr 20 17:35:51 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18391
	for ; Fri, 20 Apr 2001 17:35:50 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3KLXgS00369;
	Fri, 20 Apr 2001 14:33:42 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3KLXhQ15664;
	Fri, 20 Apr 2001 14:33:43 -0700 (PDT)
Resent-Date: Fri, 20 Apr 2001 14:33:43 -0700 (PDT)
Importance: Normal
Subject: Re: piece wise retrieval of multivalued attrib.
To: Himanshu Chatterjee 
Cc: ietf-ldapext@netscape.com
X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
Message-ID: 
From: "John McGarvey" 
Date: Fri, 20 Apr 2001 17:33:29 -0400
X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.6 |December 14, 2000) at
 04/20/2001 05:33:35 PM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id f3KLXfv15631
Resent-Message-ID: <"NWP1pB.A.V0D.1sK46"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id f3KLXgS00369
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA18391

I believe the duplicate entry draft, in combination with the scrolling view
browsing draft, would serve this purpose.

-- John McGarvey

Himanshu Chatterjee  on 04/20/2001 03:12:44
PM

To:   ietf-ldapext@netscape.com, ietf-ldapext-request@netscape.com
cc:
Subject:  piece wise retrieval of multivalued attrib.




Hi,  Do we have any plans for a control which can retrieve the attribute
values of a multivalued attribute, piece wise and asyncronously. This would
be immensely helpful to retrieve values of a huge multivalued attribute  (
like rfc822mailMembers or a mailGroup class, which can potentially have a
million values ). or there is a work around for this fundamental problem.

Thanks
Himanshu Chatterjee
Oracle Corp,




From list@netscape.com  Fri Apr 20 17:42:06 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18459
	for ; Fri, 20 Apr 2001 17:42:06 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3KLe1S01974;
	Fri, 20 Apr 2001 14:40:02 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3KLe2U18812;
	Fri, 20 Apr 2001 14:40:02 -0700 (PDT)
Resent-Date: Fri, 20 Apr 2001 14:40:02 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010420143540.00acfb30@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 20 Apr 2001 14:37:08 -0700
To: "John McGarvey" 
From: "Kurt D. Zeilenga" 
Subject: Re: piece wise retrieval of multivalued attrib.
Cc: Himanshu Chatterjee ,
        ietf-ldapext@netscape.com
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"a9zGDD.A.TlE.wyK46"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 02:33 PM 4/20/01, John McGarvey wrote:
>I believe the duplicate entry draft, in combination with the scrolling view
>browsing draft, would serve this purpose.

Don't be surprised if the server returns unwillingToPerform
when asked to duplicate an entry millions of times.

Kurt



From list@netscape.com  Fri Apr 20 17:56:12 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18586
	for ; Fri, 20 Apr 2001 17:56:11 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3KLs2S04619;
	Fri, 20 Apr 2001 14:54:03 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3KLs4g26853;
	Fri, 20 Apr 2001 14:54:04 -0700 (PDT)
Resent-Date: Fri, 20 Apr 2001 14:54:04 -0700 (PDT)
Message-ID: <3AE0AFFE.59F7E95A@netscape.com>
Date: Fri, 20 Apr 2001 17:54:06 -0400
From: mcs@netscape.com (Mark C Smith)
Organization: iPlanet E-Commerce Solutions
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" 
CC: John McGarvey ,
        Himanshu Chatterjee ,
        ietf-ldapext@netscape.com
Subject: Re: piece wise retrieval of multivalued attrib.
References: <5.1.0.14.0.20010420143540.00acfb30@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"wXFQPC.A.6iG.5_K46"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> 
> At 02:33 PM 4/20/01, John McGarvey wrote:
> >I believe the duplicate entry draft, in combination with the scrolling view
> >browsing draft, would serve this purpose.
> 
> Don't be surprised if the server returns unwillingToPerform
> when asked to duplicate an entry millions of times.

I think it would be better to spend some time designing the directory
service and the associated applications to avoid the need to store
millions of values.

-- 
Mark Smith
Directory Product Development / Netscape



From list@netscape.com  Fri Apr 20 19:14:55 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19706
	for ; Fri, 20 Apr 2001 19:14:55 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3KNCmv02059;
	Fri, 20 Apr 2001 16:12:48 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3KNCn606398;
	Fri, 20 Apr 2001 16:12:49 -0700 (PDT)
Resent-Date: Fri, 20 Apr 2001 16:12:49 -0700 (PDT)
Message-Id: <5.0.2.1.2.20010420160614.00a6c860@pop.walltech.com>
X-Sender: bgreenblatt@pop.walltech.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Fri, 20 Apr 2001 16:12:19 -0700
To: ietf-ldapext@netscape.com
From: Bruce Greenblatt 
Subject: Re: piece wise retrieval of multivalued attrib.
In-Reply-To: <3AE0AFFE.59F7E95A@netscape.com>
References: <5.1.0.14.0.20010420143540.00acfb30@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Resent-Message-ID: <"tnne0C.A.kjB.vJM46"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 05:54 PM 4/20/2001 -0400, Mark C Smith wrote:

>I think it would be better to spend some time designing the directory
>service and the associated applications to avoid the need to store
>millions of values.

I strongly agree.  This points out a flaw in the schema/DIT structure, and 
not a missing feature of the LDAP protocol.  Also note that if you need to 
check if a user is a member of the mailing list, you can use the Compare 
operation.  You could implement the proposed matched values only control, 
which I believe is a bad thing that only encourages poor schema/DIT 
structure design.  The best thing to do is to restructure the information 
in the DIT.


>--
>Mark Smith
>Directory Product Development / Netscape

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com



From list@netscape.com  Sat Apr 21 00:19:15 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24227
	for ; Sat, 21 Apr 2001 00:19:14 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3JFM4S29418;
	Thu, 19 Apr 2001 08:22:04 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3JFM3s06066;
	Thu, 19 Apr 2001 08:22:03 -0700 (PDT)
Resent-Date: Thu, 19 Apr 2001 08:22:03 -0700 (PDT)
Sender: Robert.Byrne@Sun.COM
Message-ID: <3ADF0221.A6D2875A@Sun.COM>
Date: Thu, 19 Apr 2001 17:20:01 +0200
From: robert byrne 
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ldapext@netscape.com
Subject: Re: browse permission in the ACM
References: <200104101510.LAA24387@qsun.mt.att.com> <3AD43163.78E8FA8F@Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"Gujho.A.ocB.TKw36"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit


All,

By way of a partial conclusion of this thread, for the next draft I
intend to propose 3. below.

Rob.

robert byrne wrote:
> 
> Rick,
> 
> Maybe now is a good time to list the options (that I can think of) open
> to us for this browsing concept:
> 
> 1. Keep it as is in section 5.2, so that "b" is just an entry-level
> permission you need on all entries when you search.
> 
> 2. Drop it entirely, so that we have no dedicated entry-level permission
> on search.  For example, we don't have an entry-level Modify
> permission.  In this model, we would be relying on the returnDn
> permission for entry-level protection.  I guess "entry-level protection"
> of an entry in the context of search means protecting the dn so this
> seems to make sense.
> 
> 3. Keep "b" but only require it on non-base entries.  This means that
> you can control the power of the subtree and onelevel search options on
> your DIT.
> 
> 4. Keep "b" but only require it on non-base entries AND introduce a "v"
> which you are now required to see base entries of searches.  This means
> that you can control the power of the subtree and onelevel search
> options on your DIT AND allows you to explicitly protect bases of
> searches at the entry level.
> 
> 5. As 4. but have "b"=>"v", so that if you want you can forget about "v"
> and just use "b" as in 1.  This is what I proposed in my earlier mail.
> 
> I agree that it is not worth complicating things for this browsing
> capability.  Given this, if people like the ability to put a brake on
> the subtree and onelevel options (I guess the use of these options is
> what we mean by "browsing" in LDAP), I'm tempted to propose 3. as the
> simplest option.  After that if we consider that controling browsing is
> not important, I'm tempted by 2., namely dropping "b" entirely...though
> we'd need to check that this doesn't leave some holes.
> 
> Any votes/opinions on these options ?
> 
> Rick, for your other point on aborting searches re the returnDn
> permission, I would prefer to discuss that in a different thread called
> something like "protecting dns in the ACM", as I think it desreves a
> discussion itself.
> 
> Rob.
> 
> Richard V Huber wrote:
> >
> > Since Rob says `To minimize the number of combinations we also allow
> > the base element to be seen if "b" permission is assigned to it', it
> > seems that the new "b" includes the new "v" and is identical to the old
> > "b".  So the real change here is the addition of the separate "v"
> > permission.
> >
> > So I assume new the definitions of "b" and "v" in section 4.2.1 would
> > be something like (trying to stay reasonably close to the current
> > wording):
> >
> >   b BrowseDN
> >
> >   If granted, permits entries to be accessed using search operations
> >   regardless of whether they explicitly provide the name of the entry.
> >
> >   v VertexDN
> >
> >   If granted, permits entries to be accessed using search operations
> >   only if the name of the entry is explicitly supplied.
> >
> > I guess my main question is whether the change is worth it.  The model
> > is already rather complicated.  Does this change provide value that is
> > worth the additional complexity?  I'm not sure that it does.
> >
> > And one other vaguely related question that came to mind after reading
> > Rob's email.  He notes that "... the absence of a "v" or "b" permission
> > at any point does not abort the search operation as a whole or even on
> > a particular subtree."
> >
> > I have been assuming (and this seemed like a good time to check) that
> > absence of a "t" permission DOES abort the search operation on a
> > particular subtree, since returning the DN of any object further down
> > in the tree would require that the DN of the object without "t"
> > permission be returned.  Is that the generally accepted view?
> >
> > Rick Huber
> >
> > : Sender: Robert.Byrne@Sun.COM
> > : From: robert byrne 
> > : To: ietf-ldapext@netscape.com
> > : Subject: browse permission in the ACM
> > :
> > :
> > : All,
> > :
> > : The following is a proposal to tweak the current browse permission in
> > : the ACM.
> > : The current usage of the "b" permission in the ACM is really just a read
> > : level permission on candidate entries. From section 5.2:
> > :
> > : " 1.  permission "b" to the entry candidateDN
> > :
> > :       If this permission is not granted then the dn
> > :       candidateDN MUST NOT be returned nor any attribute
> > :       type nor attribute value from this entry.
> > :
> > :       If this permission is granted then the dn candidateDN
> > :       MAY be returned.
> > : "
> > :
> > : Some people felt that it would be better to have it behave more like
> > : it's name suggests...which is that you would require this permission to
> > : be able to have a search request return __non-base__ entries to you
> > : during a search.  The spirit of this idea is something like "Hang on,
> > : subtree and onelevel searches are really powerful, there should be a
> > : way continue to grant read access to entries, but to limit the power of
> > : these search options".
> > :
> > : One way to do this is to refine "b" into two permissions 'new "b"' and
> > : "v".
> > : The 'new "b"' still stands for browse and you will need this to see
> > : non-base entries.   At a stretch the "v" stands for "vertex" as you need
> > : this to see the base entry (the vertex) of a search.  (From now on "b"
> > : means 'new "b"'.) To minimize the
> > : number of combinations we also allow the base element to be seen if "b"
> > : permission is assigned to it.  So, the new text I am proposing for this
> > : would be:
> > :
> > :
> > : " 1.  permission "v" or "b" to the entry candidateDN, if the entry is
> > : the
> > :      base of the search operation.
> > :      permission "b" to the entry if the entry is not the base of the
> > : search.
> > :
> > :      If these conditions are not satisfied then the dn
> > :      candidateDN MUST NOT be returned nor any attribute
> > :      type nor attribute value from this entry.
> > :
> > :      If this permission is granted then the dn candidateDN
> > :      MAY be returned."
> > :
> > : Note that the absence of a "v" or "b" permission at any point does not
> > : abort the search operation as a whole or even on a particular subtree.
> > : We could specify such behaviour but I believe most LDAP implementations
> > : have an "optimistic" approach to searching for entries ie. I may be
> > : denied access to this entry, but there may be other entries to which I
> > : do have access, so keep searching.
> > :
> > : Note also that if you only ever use "b", it will behave just like a read
> > : level permission on the entry--we provide the "v" refinement for those
> > : users that might want to limit "browsability" of their DIT.
> > :
> > : An example.  Suppose that some given user has all rights on all
> > : these subtrees, the only difference being in allocation of the "b" and
> > : "v" rights which are shown in brackets, after the RDN of the entry.
> > :
> > :         ou=sun.com(b)
> > :         |
> > :         |------------------------------------------------
> > :         |                       |                       |
> > :         ou=sortOfBrowsable()    ou=notBrowsable(v)      ou=Browsable(b)
> > :         |                       |                       |
> > :         ou=level1(v)            ou=level1(v)            ou=level1(b)
> > :         |                       |                       |
> > :         ou=level2(b)            ou=level2(v)            ou=level2(b)
> > :
> > :
> > : Eg 1: If he does a search like this:
> > :
> > :         baseEntry: ou=sortOfBrowsable,o=sun.com
> > :         filter: ou=*
> > :         scope: subtree
> > :
> > : He will get back the following entry:
> > :
> > :         ou=level2,ou=sortOfBrowsable,ou=sun.com (has "b" on this)
> > :
> > : -----
> > :
> > : Eg 2: Then, if he does a search like this:
> > :
> > :         baseEntry: ou=sortOfBrowsable,o=sun.com
> > :         filter: ou=*
> > :         scope: base
> > :
> > : He will get back no entries (neither "v" nor "b" on the base).
> > :
> > : -----
> > :
> > : Eg 3: If he does a search like this:
> > :
> > :         baseEntry: ou=notBrowsable,ou=sun.com
> > :         filter: ou=*
> > :         scope: subtree
> > :
> > : He will get back the following entry:
> > :
> > :         ou=notBrowsable,ou=sun.com (has "v" and it's the base)
> > :
> > : -----
> > :
> > :
> > : Eg 4: If he does a search like this:
> > :
> > :         baseEntry: ou=notBrowsable,ou=sun.com
> > :         filter: ou=*
> > :         scope: base
> > :
> > : He will get back the following entry:
> > :
> > :         ou=notBrowsable,ou=sun.com (has "v" and it's the base)
> > :
> > : -----
> > :
> > :
> > : Eg 5: Then, if he does a search like this:
> > :
> > :         baseEntry: ou=Browsable,ou=sun.com
> > :         filter: ou=*
> > :         scope: subtree
> > :
> > : He will get back the following entries:
> > :         ou=Browsable,ou=sun.com       (has "b")
> > :         ou=level1,ou=Browsable,ou=sun.com (has "b")
> > :         ou=level2,ou=Browsable,ou=sun.com (has "b")
> > :
> > : -----
> > :
> > :
> > : Eg 6: Then, if he does a search like this:
> > :
> > :         baseEntry: ou=Browsable,ou=sun.com
> > :         filter: ou=*
> > :         scope: base
> > :
> > : He will get back the following entries:
> > :         ou=Browsable,ou=sun.com       (has "b")
> > :
> > : -----
> > :
> > :
> > : Eg 7: Then, if he does a search like this:
> > :
> > :         baseEntry: ou=sun.com
> > :         filter: ou=*
> > :         scope: onelevel
> > :
> > : He will get back the following entries:
> > :         ou=Browsable,ou=sun.com       (has "b")
> > :
> > : -----
> > :
> > : Any comments on this modification ?
> > :
> > : Rob.



From list@netscape.com  Mon Apr 23 03:27:15 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02359
	for ; Mon, 23 Apr 2001 03:27:14 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3N7P7S24200;
	Mon, 23 Apr 2001 00:25:07 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3N7P8c29568;
	Mon, 23 Apr 2001 00:25:09 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 00:25:09 -0700 (PDT)
From: "David Sutton" 
To: 
Subject: RE: piece wise retrieval of multivalued attrib.
Date: Mon, 23 Apr 2001 08:22:17 +0100
Message-ID: <003801c0cbc6$209f5550$4202290a@eng.cpth.ie>
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
In-Reply-To: <5.0.2.1.2.20010420160614.00a6c860@pop.walltech.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Resent-Message-ID: <"5CFbwD.A.mNH.Sj946"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

This is a real requirement - and its one we've been discussing at CP for
some time. The conclusion here is that we can support it using dup entry in
conjunction with simple paged.

Most customers understand that groupOfNames is the object class used to hold
a group - and they build out their infrastructures based on that assumption.
When we arrive they are already dealing with groupOfNames objects with 10s
of 1000s of member values. Its kinda too late to tell them to rebuild their
infrastructure using an alternative schema/DIT structure!

For applications that simply need to check if a user is a member of a group
it is true that the compare operation can be used. However there are other
applications (e.g. meta-directory) that may need to examine every member
value of a group in order to transform the member values of the group before
replicating it into another directory name space for example.

- David

> -----Original Message-----
> From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com]
> Sent: 21 April 2001 00:12
> To: ietf-ldapext@netscape.com
> Subject: Re: piece wise retrieval of multivalued attrib.
>
>
> At 05:54 PM 4/20/2001 -0400, Mark C Smith wrote:
>
> >I think it would be better to spend some time designing the directory
> >service and the associated applications to avoid the need to store
> >millions of values.
>
> I strongly agree.  This points out a flaw in the schema/DIT
> structure, and
> not a missing feature of the LDAP protocol.  Also note that if
> you need to
> check if a user is a member of the mailing list, you can use the Compare
> operation.  You could implement the proposed matched values only control,
> which I believe is a bad thing that only encourages poor schema/DIT
> structure design.  The best thing to do is to restructure the information
> in the DIT.
>
>
> >--
> >Mark Smith
> >Directory Product Development / Netscape
>
> ==============================================
> Bruce Greenblatt, Ph. D.
> Directory Tools and Application Services, Inc.
> http://www.directory-applications.com
>
>



From list@netscape.com  Mon Apr 23 04:58:49 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02737
	for ; Mon, 23 Apr 2001 04:58:49 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3N8ufv22328;
	Mon, 23 Apr 2001 01:56:41 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3N8uhY23578;
	Mon, 23 Apr 2001 01:56:43 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 01:56:43 -0700 (PDT)
Message-ID: <000035c65a65$00005447$00007ecb@>
To: 
From: bestleads@arabia.com
Subject: GREAT MORTGAGE RATES!
Date: Sun, 22 Apr 2001 19:31:28 -0700
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Server: VPOP3 V1.4.0 - Registered to: Adam House
Resent-Message-ID: <"LdIHCC.A.TvF.I5-46"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: quoted-printable





 



=
Are You in Debt? If So, We've Got Some Extremely Good News For You...


We Have Lenders That =
Will


Loan You up to 125% of the Value of Your H=
ome... 


Refinancing, Secon=
d Mortgage, Home Improvement, Home Equity Line of Credit, Refinancing with=
 Cash out are also available





Cli=
ck Here









To be removed:  darrine202@looksmart.com.au






Are You in Debt? If So, We've Got S=
ome Extremely Good News For You...<=
BR>
We Have Len=
ders That Will

Loan You up to 125% of the Value of Your Home... 

Refinancing, Second Mortgage, Home Improvement, Home Equity Line of Cr=
edit, Refinancing with Cash out are also available



Click Here






From list@netscape.com  Mon Apr 23 08:31:27 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03868
	for ; Mon, 23 Apr 2001 08:31:27 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3NCTKS20843;
	Mon, 23 Apr 2001 05:29:20 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3NCTMY18061;
	Mon, 23 Apr 2001 05:29:22 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 05:29:22 -0700 (PDT)
Message-Id: <200104231229.IAA02474@stingray.missi.ncsc.mil>
From: "Miklos A. Sue" 
To: "'mcs@netscape.com'" ,
        "Kurt D. Zeilenga"
	 
Cc: John McGarvey ,
        Himanshu Chatterjee
	 ,
        ietf-ldapext@netscape.com
Subject: RE: piece wise retrieval of multivalued attrib.
Date: Mon, 23 Apr 2001 08:32:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;    
	boundary="------------InterScan_NT_MIME_Boundary"
Resent-Message-ID: <"PlBdmD.A.zZE.fAC56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

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.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0CBF1.746F9340"

------_=_NextPart_001_01C0CBF1.746F9340
Content-Type: text/plain;
	charset="ISO-8859-1"

I have an operational requirement to use mail (distribution) lists that may
contain up to 3.5 - 4 million entries (All MIL, for example).  The use of
nested lists is currently how we're doing it, with very labor intensive
alias management.  

I'd welcome a directory service that supported this in a more efficient
manner, for email at a minimum.

Are there any standardized schema elements for this capability proposed (in
the email context) or should I ask the S/MIME WG?

regards,
Sandi

-----Original Message-----
From: mcs@netscape.com [mailto:mcs@netscape.com]
Sent: Friday, April 20, 2001 5:54 PM
To: Kurt D. Zeilenga
Cc: John McGarvey; Himanshu Chatterjee; ietf-ldapext@netscape.com
Subject: Re: piece wise retrieval of multivalued attrib.


"Kurt D. Zeilenga" wrote:
> 
> At 02:33 PM 4/20/01, John McGarvey wrote:
> >I believe the duplicate entry draft, in combination with the scrolling
view
> >browsing draft, would serve this purpose.
> 
> Don't be surprised if the server returns unwillingToPerform
> when asked to duplicate an entry millions of times.

I think it would be better to spend some time designing the directory
service and the associated applications to avoid the need to store
millions of values.

-- 
Mark Smith
Directory Product Development / Netscape

------_=_NextPart_001_01C0CBF1.746F9340
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: piece wise retrieval of multivalued attrib.




I have an operational requirement to use mail =
(distribution) lists that may contain up to 3.5 - 4 million entries =
(All MIL, for example).  The use of nested lists is currently how =
we're doing it, with very labor intensive alias management.  =




I'd welcome a directory service that supported this =
in a more efficient manner, for email at a minimum.




Are there any standardized schema elements for this =
capability proposed (in the email context) or should I ask the S/MIME =
WG?



regards,

Sandi




-----Original Message-----

From: mcs@netscape.com [mailto:mcs@netscape.com]

Sent: Friday, April 20, 2001 5:54 PM

To: Kurt D. Zeilenga

Cc: John McGarvey; Himanshu Chatterjee; =
ietf-ldapext@netscape.com

Subject: Re: piece wise retrieval of multivalued =
attrib.






"Kurt D. Zeilenga" wrote:

> 

> At 02:33 PM 4/20/01, John McGarvey =
wrote:

> >I believe the duplicate entry draft, in =
combination with the scrolling view

> >browsing draft, would serve this =
purpose.

> 

> Don't be surprised if the server returns =
unwillingToPerform

> when asked to duplicate an entry millions of =
times.




I think it would be better to spend some time =
designing the directory

service and the associated applications to avoid the =
need to store

millions of values.




-- 

Mark Smith

Directory Product Development / Netscape





------_=_NextPart_001_01C0CBF1.746F9340--

--------------InterScan_NT_MIME_Boundary--



From list@netscape.com  Mon Apr 23 10:57:45 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05155
	for ; Mon, 23 Apr 2001 10:57:45 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3NEtav01711;
	Mon, 23 Apr 2001 07:55:36 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3NEtZI06134;
	Mon, 23 Apr 2001 07:55:35 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 07:55:35 -0700 (PDT)
Sender: Robert.Byrne@Sun.COM
Message-ID: <3AE44238.513AE7E9@Sun.COM>
Date: Mon, 23 Apr 2001 16:54:48 +0200
From: robert byrne 
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" 
CC: ietf-ldapext@netscape.com
Subject: Re: subjects in LDAP ACMs
References: <5.0.2.1.0.20010411183522.00aa51f0@127.0.0.1> <5.0.2.1.0.20010412110700.00b10c60@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"A6gyeB.A.XfB.lJE56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit


Kurt,

Your list of proposed non-factor subjects seems fine to me and I take
your point that you may want to specify a factor or factors as well as
any one of these subjects.

If we jiggle the current BNF in 4.1.1 a bit in order to group the
factors together (authnLevel, ipaddress and dns) and add your
"authorized" and "anonymous" labels then I think it does give something
that's better structured:

subject =               [factor] simpleSubject       
            		
simpleSubject = 	( "authzID-" authzID ) /
                         ( "role:" dn ) /
                         ( "group:" dn ) /
                         ( "subtree:" dn ) /
                       "this:" /
			"public:" /
			"authorized:" / ; authenticated and authorized
			"anonymous:"	; unauthenticated
	
factor = [ "authnLevel:" authnLevel ":" ]
	[ "ipAddress:" ipAddress ]
        [ "dns:" [ "*." ] domainname ) ]

I think using "authorized" is confusing as it's often used to refer to
the end result of access control the user is authorized to do the
LDAP operation.  How about rather "identified" ?

As for making the factors extensible...that sounds fine but it might be
more pragmatic to focus on the factors we have already identified
(authnLevel, ipaddress/dns names) to try to get agreement on how to
handle those.

Rob.

"Kurt D. Zeilenga" wrote:
> 
> At 05:15 PM 4/12/01 +0200, robert byrne wrote:
> 
> >Kurt,
> >
> >Conceptually it's certainly helpful to seperate the authzid type
> >subjects from factors like authnLevel, ipaddress/dns name etc.  However,
> >in so far as a factor is typically an extra refinement on authzID's (eg.
> >grant the access if it's cn=rob,o=sun.com AND he's authenticated using
> >SASL-DIGEST-MD5) I think factors are still very "subjecty" things.  Is
> >the trend of your thought to move factors into a say "factor" keyword
> >and then require that the subject AND factor keywords are satisfied ?
> 
> No.  My thought is to come up with an extensible set of orthogonal
> factors which then are expressed in the syntax as such.  What
> authorization identity some user has independent of the mechanism
> used to authenticate the user.  What host that user appears to
> on is orthogonal to the mechanism used.
> 
> >What do you mean by "authorized" below ?
> 
> Meaning that the user was "authorized" to assume an identity.
> That is, the user has been authenticated and some authorization
> identity has been associated with the session (this might be
> an authorization identity derived from the user's authentication
> identity or another authorization identity which the user is
> allowed to assert).
> 
> >BTW, do you think it would be interesting to allow boolean combinations
> >of subjects in the same aci ?
> 
> Interesting, yes, but too complex.  I suggest that factors be
> AND'ed together and or's created by multiple values.  We use
> this logic in our ACM, it's simple and effective.
> 
> >Rob.
> >
> >"Kurt D. Zeilenga" wrote:
> >>
> >> I note that the LDAP ACI syntax only allows a single
> >> subject per value though it is likely quite desirable
> >> to treat certain kinds of subjects as orthogonal factors
> >> in the ACM.  For example, it might be useful to say
> >> "authzId X via Y method gets Z permission".
> >>
> >> However, adding additional, independent factors to
> >> the ACM adds to the complexity of specification so
> >> we must tread lightly.
> >>
> >> My first suggestion would be remove subjects based
> >> upon orthogonal factors from the ACM, then to discuss
> >> support for orthogonal factors such as authnLevel.
> >>
> >> I suggest Subjects be based solely upon presence, absence,
> >> or value of the authorization identity.  Hence, I suggest
> >> (provided in suggested precedence order):
> >>
> >>   subject = this          ; self
> >>   subject /= "authzID-" authzID)
> >>   subject /= ("role:" dn)
> >>   subject /= ("group:" dn)
> >>   subject /= ("subtree:" dn)
> >>   subject /= authorized   ; authenticated and authorized
> >>   subject /= anonymous    ; unauthenticated
> >>   subject /= public       ; any user
> >>
> >> Kurt



From list@netscape.com  Mon Apr 23 11:35:36 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05654
	for ; Mon, 23 Apr 2001 11:35:35 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3NFWSS15683;
	Mon, 23 Apr 2001 08:32:29 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3NFWSs27505;
	Mon, 23 Apr 2001 08:32:28 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 08:32:28 -0700 (PDT)
Message-ID: <4E6A7BDC24CDD311B11400508BDF0A3836C335@usahm009.exmi01.exch.eds.com>
From: "Cutler, James R" 
To: "'robert byrne'" ,
        "Kurt D. Zeilenga"
	 
Cc: ietf-ldapext@netscape.com
Subject: RE: subjects in LDAP ACMs
Date: Mon, 23 Apr 2001 11:32:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.52)
Content-Type: text/plain;
	charset="iso-8859-1"
Resent-Message-ID: <"T6Rlq.A._rG.HsE56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Kurt,

Rather than "identified", it should be "authenticated", since this is, in
fact, what is indicated.  Authorization happens outside of the simpleSubject
definition.
-
James R. Cutler - EDS
800 Tower Drive, Troy, MI 48098
1 248 265 7514
james.cutler@eds.com
-----Original Message-----
From: robert byrne [mailto:robert.byrne@Sun.COM]
Sent: Monday, April 23, 2001 10:55 AM
To: Kurt D. Zeilenga
Cc: ietf-ldapext@netscape.com
Subject: Re: subjects in LDAP ACMs



Kurt,

Your list of proposed non-factor subjects seems fine to me and I take
your point that you may want to specify a factor or factors as well as
any one of these subjects.

If we jiggle the current BNF in 4.1.1 a bit in order to group the
factors together (authnLevel, ipaddress and dns) and add your
"authorized" and "anonymous" labels then I think it does give something
that's better structured:

subject =               [factor] simpleSubject       
            		
simpleSubject = 	( "authzID-" authzID ) /
                         ( "role:" dn ) /
                         ( "group:" dn ) /
                         ( "subtree:" dn ) /
                       "this:" /
			"public:" /
			"authorized:" / ; authenticated and authorized
			"anonymous:"	; unauthenticated
	
factor = [ "authnLevel:" authnLevel ":" ]
	[ "ipAddress:" ipAddress ]
        [ "dns:" [ "*." ] domainname ) ]

I think using "authorized" is confusing as it's often used to refer to
the end result of access control the user is authorized to do the
LDAP operation.  How about rather "identified" ?

As for making the factors extensible...that sounds fine but it might be
more pragmatic to focus on the factors we have already identified
(authnLevel, ipaddress/dns names) to try to get agreement on how to
handle those.

Rob.

"Kurt D. Zeilenga" wrote:
> 
> At 05:15 PM 4/12/01 +0200, robert byrne wrote:
> 
> >Kurt,
> >
> >Conceptually it's certainly helpful to seperate the authzid type
> >subjects from factors like authnLevel, ipaddress/dns name etc.  However,
> >in so far as a factor is typically an extra refinement on authzID's (eg.
> >grant the access if it's cn=rob,o=sun.com AND he's authenticated using
> >SASL-DIGEST-MD5) I think factors are still very "subjecty" things.  Is
> >the trend of your thought to move factors into a say "factor" keyword
> >and then require that the subject AND factor keywords are satisfied ?
> 
> No.  My thought is to come up with an extensible set of orthogonal
> factors which then are expressed in the syntax as such.  What
> authorization identity some user has independent of the mechanism
> used to authenticate the user.  What host that user appears to
> on is orthogonal to the mechanism used.
> 
> >What do you mean by "authorized" below ?
> 
> Meaning that the user was "authorized" to assume an identity.
> That is, the user has been authenticated and some authorization
> identity has been associated with the session (this might be
> an authorization identity derived from the user's authentication
> identity or another authorization identity which the user is
> allowed to assert).
> 
> >BTW, do you think it would be interesting to allow boolean combinations
> >of subjects in the same aci ?
> 
> Interesting, yes, but too complex.  I suggest that factors be
> AND'ed together and or's created by multiple values.  We use
> this logic in our ACM, it's simple and effective.
> 
> >Rob.
> >
> >"Kurt D. Zeilenga" wrote:
> >>
> >> I note that the LDAP ACI syntax only allows a single
> >> subject per value though it is likely quite desirable
> >> to treat certain kinds of subjects as orthogonal factors
> >> in the ACM.  For example, it might be useful to say
> >> "authzId X via Y method gets Z permission".
> >>
> >> However, adding additional, independent factors to
> >> the ACM adds to the complexity of specification so
> >> we must tread lightly.
> >>
> >> My first suggestion would be remove subjects based
> >> upon orthogonal factors from the ACM, then to discuss
> >> support for orthogonal factors such as authnLevel.
> >>
> >> I suggest Subjects be based solely upon presence, absence,
> >> or value of the authorization identity.  Hence, I suggest
> >> (provided in suggested precedence order):
> >>
> >>   subject = this          ; self
> >>   subject /= "authzID-" authzID)
> >>   subject /= ("role:" dn)
> >>   subject /= ("group:" dn)
> >>   subject /= ("subtree:" dn)
> >>   subject /= authorized   ; authenticated and authorized
> >>   subject /= anonymous    ; unauthenticated
> >>   subject /= public       ; any user
> >>
> >> Kurt



From list@netscape.com  Mon Apr 23 11:36:54 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05671
	for ; Mon, 23 Apr 2001 11:36:53 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3NFYkv09259;
	Mon, 23 Apr 2001 08:34:46 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3NFYk228927;
	Mon, 23 Apr 2001 08:34:46 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 08:34:46 -0700 (PDT)
Sender: Robert.Byrne@Sun.COM
Message-ID: <3AE44B60.17FA0166@Sun.COM>
Date: Mon, 23 Apr 2001 17:33:52 +0200
From: robert byrne 
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ldapext@netscape.com
Subject: search permission in the ACM
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"-bEj0.A.iDH.UuE56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit


All,

The permission you require on an attribute in order to use it in a
search filter currently is quoted below from section 5.2.  I would like
to change these requirements as follows:

1. change "s" so that if you have "s" on an attribute you have the right
to use it in _any_ search filter.
2. drop the "r" requirement entirely.
3. add a new permission "p" to cover the case where you just want to
grant presence test ability to an attribute.

My idea is just to avoid overloading "r"--ie. with this approach only
the "s" and "p" permissions would be involved in checking access control
to filters and "r" would be just for testing for read permission on the
attribute.  Apart from that the idea is similar: "s" grants the right to
use the attribute in any search filter while "p" is reserved for those
attributes to which you just want to grant presence test rights.  The
motivation for the "p" permisison is that if you have full filter rights
on an attribute then in some cases that could be operationally the same
as having read permissiion ie. you could quickly determine the attribute
value, and this may not be desirable.  For example, if the type of the
attribute was integer then with full filter permissions you could
quickly determine the value by doing a sequence of binary chop style
searches using ">" and "<".  Whereas, with just the presence test
ability, you would not have right to do those kind of searches, but you
would be able to test for the presence of the attribute.

Rob.

"2.  permission "s" to each attribute appearing in a search
      filter presence test during the evaluation of the
      search filter.  permission "r" and "s" to each
      attribute appearing in non-presence tests (see
      rfc1960, section 3: equalityMatch, substrings,
      greaterOrEquial, lessOrEqual, present, approxMatch,
      extensibleMatch) during the evaluation of the search
      filter.

      The above statement covers the case where the
      attributes are being evaluated as part of an
      extensibleMatch (RFC 2251 section 4.5.1) which appears
      in the filter.  In the case where the dnAttributes
      field of the extensibleMatch is true then we do not
      require any access checks to the attributes of the dn
      candidateDN as access to these is taken to be granted
      by the "b" permission, which has already been required
      above.

      If there is an attribute in a filter element to which
      the required permission is not granted then that
      filter element evaluates to "Undefined" of the three-
      valued-logic of X.511(93)."



From list@netscape.com  Mon Apr 23 13:54:38 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08245
	for ; Mon, 23 Apr 2001 13:54:38 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3NHqin12069;
	Mon, 23 Apr 2001 10:52:44 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3NHqjU08176;
	Mon, 23 Apr 2001 10:52:45 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 10:52:45 -0700 (PDT)
Date: Mon, 23 Apr 2001 13:52:36 -0400
Message-Id: <200104231752.NAA03713@qsun.mt.att.com>
From: rvh@qsun.mt.att.com (Richard V Huber)
To: robert.byrne@Sun.COM
Subject: Re: browse permission in the ACM
Cc: ietf-ldapext@netscape.com
Resent-Message-ID: <"AjXkbC.A.Y_B.rvG56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This email is carrying around a lot of history.  I've clipped off some
of the earlier messages in the chain.

My concern about extensibleMatch and option 3 was based on this
paragraph from the draft (from Section 5.2, item 2):

      The above statement covers the case where the
      attributes are being evaluated as part of an
      extensibleMatch (RFC 2251 section 4.5.1) which appears
      in the filter.  In the case where the dnAttributes
      field of the extensibleMatch is true then we do not
      require any access checks to the attributes of the dn
      candidateDN as access to these is taken to be granted
      by the "b" permission, which has already been required
      above. 

Since Option 3 implies that the "b" permission is NOT required for the
base object to be searched, you might want to change 5.2 item 2 to
say that "r" and "s" permissions ARE required for extensibleMatches on
the DN of the base object.  But given that the "t" permission exists,
this may not really matter in real-life situations.

Rick Huber

: From: robert byrne 
: To: Richard V Huber 
: CC: ietf-ldapext@netscape.com
: Subject: Re: browse permission in the ACM
: 
: Richard V Huber wrote:
: > 
: > As I understand Option 3, it says that the "b" permission is not
: > checked on the base object of a search.
: > 
: > I'm trying to figure out what permissions would be checked for the base
: > object under option 3.  For example, item 1 in section 5.2 would not
: > seem to apply when the candidateDN is the base object.  How about the
: > part of item 2 that discusses extensibleMatch?
: 
: The idea is that "b" gives you the right to find an entry using the
: subtree and onlevel options of search.  For a base entry, we do not
: require "b" because you have named it.  We would still require the other
: permissions (filter, returnDn, readOnAttribute) for a base entry.  Where
: we refer to "b" in those sections we should say something like "as per
: item 1."--ie. we never require "b" on base entries.
: 
: > 
: > One of the reasons I had not responded to your previous email is that
: > I'm still trying to figure out whether these questions really matter in
: > practical directories.
: 
: Good question--I agree the effect is a bit subtle and not obviously a
: mandatory feature.  It's another level of granularity of control on
: search.  I think you can see a similar effect in the Unix file system
: where you can be in a directory and type "ls" and see nothing but if you
: do, say, "cd public_html" you will find yourself in that directory, if
: you have the appropriate rights.  In LDAP, you might want to have a
: subtree with resources users can query if they know about them, but not
: be able to discover resources "easily".
: 
: At Pittsburg people seemed to like the browsing idea and I agreed to
: propose something.
: 
: Rob.
: 
: > 
: > Rick Huber
: > 
: > : Sender: Robert.Byrne@Sun.COM
: > : From: robert byrne 
: > : To: ietf-ldapext@netscape.com
: > : Subject: Re: browse permission in the ACM
: > :
: > :
: > : All,
: > :
: > : By way of a partial conclusion of this thread, for the next draft I
: > : intend to propose 3. below.
: > :
: > : Rob.



From list@netscape.com  Mon Apr 23 13:58:24 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08346
	for ; Mon, 23 Apr 2001 13:58:23 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3NHuYv21657;
	Mon, 23 Apr 2001 10:56:34 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3NHuXk11973;
	Mon, 23 Apr 2001 10:56:34 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 10:56:34 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010423104632.00aab050@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 23 Apr 2001 10:54:20 -0700
To: "Cutler, James R" 
From: "Kurt D. Zeilenga" 
Subject: RE: subjects in LDAP ACMs
Cc: "'robert byrne'" , ietf-ldapext@netscape.com
In-Reply-To: <4E6A7BDC24CDD311B11400508BDF0A3836C335@usahm009.exmi01.exc
 h.eds.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"ek42PB.A.d5C.NzG56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 08:32 AM 4/23/01, Cutler, James R wrote:
>Rather than "identified", it should be "authenticated", since this is, in
>fact, what is indicated.  Authorization happens outside of the simpleSubject
>definition.

The authorized identity is not necessarily the same as the authentication identity and is not authenticated, per say, but asserted and approved
by some means as part of the authentication/authorization process.

I agree "authorization" happens outside of access control.  It happens
prior.  At least in RFC 2829 terminology.



From list@netscape.com  Mon Apr 23 14:11:00 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09032
	for ; Mon, 23 Apr 2001 14:10:59 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3NI8en16554;
	Mon, 23 Apr 2001 11:08:40 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3NI8e619963;
	Mon, 23 Apr 2001 11:08:40 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 11:08:40 -0700 (PDT)
From: Roland Hedberg 
Reply-To: roland@catalogix.se
Organization: Catalogix
To: ietf-ldapext@netscape.com
Subject: Last call on 'Named Subordinate References in LDAP Directories'
Date: Mon, 23 Apr 2001 19:56:56 +0200
X-Mailer: KMail [version 1.1.99]
Content-Type: text/plain;
  charset="iso-8859-1"
MIME-Version: 1.0
Message-Id: <0104231956560D.00916@t20>
Content-Transfer-Encoding: 8bit
Resent-Message-ID: <"kaI74D.A.j3E.n-G56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

Hi !

LDAPEXTers,

The purpose of this message is to initiate the LDAPEXT
working group last call on the "Named Subordinate References in LDAP 
Directories" document.

WHAT DOCUMENT?

The document in last call is:

http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-namedref-03.txt

WHAT IS A LAST CALL FOR?

The purpose of the working group last call is to ensure
that the working group has reached consensus on the
document, believes that all the known outstanding issues
have been addressed, and is ready to put the document
forward for proposed standard status.

During the last call, any comments on the documents are
collected and discussed on the mailing list.

HOW LONG DOES IT LAST?

The last call starts today and will last approximately two
weeks. It will end on May 7th 2001

WHAT'S THE NEXT STEP?

After the last call completes, there are three possible
outcomes:

1) No changes are required and we request our ADs to put
   forward the documents to the IESG for informational
   status.

2) Minor changes agreed to on the list are required, and
   the documents are revised. We then ask our ADs to put
   forward the revised documents to the IESG for
   informational status.

3) Major issues are raised and no consensus is reached on
   the list. In this case, we slink back and discuss
   things until consensus is reached, at which time another
   working group last call will be issued.

Assuming we achieve outcome 1) or 2), and that the ADs
agree with our assessment, the next stop for the documents
is with the IESG. The IESG reads them and may approve the
documents (with or without changes), or send the documents
back to the working group to have major issues addressed.

If the first outcome happens, the documents are put forward
for a two-week last call to the entire IETF, and after
successful completion the documents are published as RFCs
with proposed standard status.

If the second outcome happens, we go back and address
the issues, putting the documents forward again when we
believe they're ready.

WHAT SHOULD YOU DO?

You should read the documents, making sure that 1) there
are no problems or deficiencies or outstanding issues that
need to be resolved; and 2) that there are no typos,
formatting problems, grammatical errors, etc.

Any substantive problems you find, you should send to the
list. Any minor problems (typos, etc.) you may send to the
list or just to the authors. If, for some reason, you have
comments you don't want to send to the entire list, you may
send them to me or my co-chair Mark Wahl.

Silence means consent.

Read, enjoy, and send your comments in!

regards,
Roland Hedberg and Mark Wahl



From list@netscape.com  Mon Apr 23 15:36:57 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11290
	for ; Mon, 23 Apr 2001 15:36:56 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3NJYev17628;
	Mon, 23 Apr 2001 12:34:40 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3NJYfE10449;
	Mon, 23 Apr 2001 12:34:41 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 12:34:41 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010423120707.00a93c60@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 23 Apr 2001 12:32:40 -0700
To: robert byrne 
From: "Kurt D. Zeilenga" 
Subject: Re: subjects in LDAP ACMs
Cc: ietf-ldapext@netscape.com
In-Reply-To: <3AE44238.513AE7E9@Sun.COM>
References: <5.0.2.1.0.20010411183522.00aa51f0@127.0.0.1>
 <5.0.2.1.0.20010412110700.00b10c60@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"nbDas.A.5iC.PPI56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

It's my personal opinion that ACMs should be based upon
authorization identities and that controls based upon
other factors (authentication method (or level), IP
address, DNS name, etc) should be left to other administrative
mechanisms (such as those upon within the authentication
subsystem and those external to LDAP (topology enforcement
systems)).

The primary reason is simplicity.  While an extensible
ACM which supports multiple orthogonal access control factors
would be more flexible, it is also quite complex (to design,
implement, and use).

Hence, I think we should do as RFC 2820 suggests [with clarification]:
   U1.  When in doubt, simpler is better, both at the interface and in
   the implementation.

   U2.  Subjects MUST be drawn from the "natural" LDAP namespace; they
   should be DNs [or RFC2829 authzIds].

The suggested "non-factor subjects" are not drawn from the "natural"
LDAP name space.  They add unnecessary complexity to the interface
and its implementations.

Kurt



From list@netscape.com  Mon Apr 23 16:19:03 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12089
	for ; Mon, 23 Apr 2001 16:19:02 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3NKGun18286;
	Mon, 23 Apr 2001 13:16:56 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3NKGvw03480;
	Mon, 23 Apr 2001 13:16:57 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 13:16:57 -0700 (PDT)
Date: Mon, 23 Apr 2001 13:16:48 -0700 (PDT)
Message-Id: <200104232016.f3NKGlW29420@ywing.netscape.com>
From: workone@zwallet.com
To: ietf-ldapext@netscape.com
Subject:  Make Money Selling a Monthly Newsletter! 
X-Reply-To:  workone@zwallet.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"II6Ft.A.A2.32I56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Make Money Selling a Monthly Newsletter! 

E-zine Editors... Authors... Information Publishers...** NEVER BEFORE SEEN ** Techniques For 
Turning an Electronic Newsletter Into a $20,000+ a Month Profit Stream! 
 
http://www.point2me.com/homejob	
 
_________________________________________________
This message is sent in compliance of the new email bill: SECTION 
301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, 
For remove click reply and type remove in subject line, your wishes will be 
honored. 
_________________________________________________





From list@netscape.com  Mon Apr 23 16:35:18 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12405
	for ; Mon, 23 Apr 2001 16:35:18 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3NKXEn21364;
	Mon, 23 Apr 2001 13:33:14 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3NKXFY10468;
	Mon, 23 Apr 2001 13:33:15 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 13:33:15 -0700 (PDT)
Date: Mon, 23 Apr 2001 16:32:41 -0400
Message-Id: <200104232032.QAA24293@qsun.mt.att.com>
From: rvh@qsun.mt.att.com (Richard V Huber)
To: ietf-ldapext@netscape.com
Subject: Comments on namedref draft
Cc: kurt@openldap.org
Resent-Message-ID: <"Y4JxXD.A.viC.HGJ56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

A few comments on draft-zeilenga-ldap-namedref-03.txt.

Section 4.2 says:

   If the URI contained in a ref attribute value refers to a LDAP
   [RFC2251] server, it MUST be a in the form of a LDAP URL [RFC2255].
   In general, the LDAP URL should not contain an explicit scope
   specifier, filter, attribute description list, or any extensions.  If
   the DN part is absent (or empty), the LDAP URL refers to entry of the
   same DN as the referral object in which the value is held.

   Other URI schemes MAY be used but MUST refer to services which are
   capable of completing operations referred to the services.  All URIs
   contained in a ref attribute MUST point to services which are equally
   capable of handling operations referring to these services.

I'm not clear what it means to return something other than an LDAP URL
here.  What if, for example, I built a referral where the URI was an
HTTP URL:

  http://www.anywho.com/cgi-bin/htwpq?qtype=rfull&name=john_smith&tel=212+555+1212&state=ny

It seems to satisfy the criteria - it is a valid URI, and given this
URL the service will indeed complete a lookup operation and give
address information for the (mythical) John Smith of New York, NY.  But
in practice, what could the client do with this or any other URI that
does not point to an LDAP server?

What would we break if we required referrals to be LDAP URLs?

In the same section:

   The referential integrity of the URI SHALL NOT be validated by the
   server holding or returning the URI (whether as part of the value of
   the attribute or as part of a referral result or search reference
   response).

I'm not clear why we need to be so emphatic here.  I believe that the
client MUST NOT expect the server to do referential integrity checks,
but why make it "illegal" for the server to do them if it wishes?

In Section 7.6.1:

   7.6.1 Bind

   A server SHOULD process a bind request as if it held no referral
   objects.  That is, if the bind name is a referral object or is
   subordinate to a referral object, the server SHOULD process the
   request normally as appropriate for a non-existent bind name (e.g.
   return invalidCredentials).

I think this needs some discussion on the list.  As this text stands,
it would make it very difficult to split a large directory into several
pieces on different servers.  Other current drafts (e.g.
draft-reed-ldup-inheritance-00.txt) seem to be working towards
supporting a more distributed environment.  I would prefer a MAY here
(or remove section 7.6.1 entirely) so we can address this issue in more
detail in future work.

Rick Huber



From list@netscape.com  Mon Apr 23 17:10:04 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12935
	for ; Mon, 23 Apr 2001 17:10:04 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3NL7vv07978;
	Mon, 23 Apr 2001 14:07:58 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3NL7wQ29453;
	Mon, 23 Apr 2001 14:07:58 -0700 (PDT)
Resent-Date: Mon, 23 Apr 2001 14:07:58 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010423134537.00ab7870@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 23 Apr 2001 14:05:56 -0700
To: rvh@qsun.mt.att.com (Richard V Huber)
From: "Kurt D. Zeilenga" 
Subject: Re: Comments on namedref draft
Cc: ietf-ldapext@netscape.com
In-Reply-To: <200104232032.QAA24293@qsun.mt.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"p5X6vB.A.eLH.rmJ56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 01:32 PM 4/23/01, Richard V Huber wrote:
>What would we break if we required referrals to be LDAP URLs?

We would lose the flexibility provided by RFC 2251:
   Other kinds of URLs may be returned, so long as the operation
   could be performed using that protocol.

While RFC 2251 could use some clarification in this area, I believe
that it's generally accepted that clients should ignore URLs they
cannot process (either because they are not of a scheme the client
recognizes, or have unrecognized critical extension, or other
reason).

>In the same section:
>   The referential integrity of the URI SHALL NOT be validated by the
>   server holding or returning the URI (whether as part of the value of
>   the attribute or as part of a referral result or search reference
>   response).
>
>I'm not clear why we need to be so emphatic here.  I believe that the
>client MUST NOT expect the server to do referential integrity checks,
>but why make it "illegal" for the server to do them if it wishes?

I believe a SHOULD would be fine.  This recommends a practice
consistent with the data model but would allows behaviors
which do not violate the interface.


>In Section 7.6.1:
>
>   7.6.1 Bind
>
>   A server SHOULD process a bind request as if it held no referral
>   objects.  That is, if the bind name is a referral object or is
>   subordinate to a referral object, the server SHOULD process the
>   request normally as appropriate for a non-existent bind name (e.g.
>   return invalidCredentials).
>
>I think this needs some discussion on the list.

I should reword this a bit.  The intent was not to disallow the
server from chaining the request, but was to recommend the server
not return a referral to the bind operation (as the semantics of
such are ill defined).

> As this text stands,
>it would make it very difficult to split a large directory into several
>pieces on different servers.  Other current drafts (e.g.
>draft-reed-ldup-inheritance-00.txt) seem to be working towards
>supporting a more distributed environment.  I would prefer a MAY here
>(or remove section 7.6.1 entirely) so we can address this issue in more
>detail in future work.



From list@netscape.com  Tue Apr 24 04:10:56 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04804
	for ; Tue, 24 Apr 2001 04:10:56 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3O88on13256;
	Tue, 24 Apr 2001 01:08:50 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3O88p629109;
	Tue, 24 Apr 2001 01:08:51 -0700 (PDT)
Resent-Date: Tue, 24 Apr 2001 01:08:51 -0700 (PDT)
Message-ID: <0000299b6d19$000061fc$0000113c@admin.mplik.ru>
To: 
From: fastpicks@citec.co.za
Subject: OUR NEXT STOCK PICK:  MLMS $.08
Date: Mon, 23 Apr 2001 18:26:24 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
Resent-Message-ID: <"w8Ao6.A.2FH.QST56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id f3O88on13256
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA04804

OUR NEXT STOCK PICK IS

OTCBB: MLMS
Price: $ .08
Target Price: $.65 - $.75
Float: 1.1mil 

We consider MLMS a STRONG BUY!

Tier II Expected to Create Over $29 Million in Revenues
SAN DIEGO--(Business Wire)--April 23, 2001--MLM World News Today, Inc.
announced that the company has signed a Letter of Intent with a team of top
network marketing professionals to promote the company's "Business Too
 Box'' world-wide. "We have known these individuals for many years. Their
reputation and proven successes have built a huge following in our industry.
We are extremely excited that they see the value in our ''Business Tool Box,
"and that they are confident in forecasting sales in excess of 100,000 units
during the first 6 to 12 months,'' stated James C. Frans, president/CEO of MLM
World News Today, Inc. 

for details go to:
http://quote.yahoo.com/q?s=mlms.ob&d=v1




DISCLAIMER: pennypicks cautions that small and micro-cap stocks
are high-risk investments and that some or all investment dollars
can be lost. We suggest you consult a professional investment advisor
before purchasing any stock. All opinions expressed on the featured
company are the opinions of pennypicks. All information concerning
the companies is received directly from company press releases.
pennypicks recommends you use the information found here as an initial
starting point for conducting your own research and conduct your own
due diligence on the featured company in order to determine your own
personal opinion of the company before investing. pennypicks assumes
all information to be truthful and reliable; however, we cannot and do not
warrant or guarantee the accuracy of this information. All statements
contained herein are deemed to be factual as of the date of this report
and as such are subject to change without notice. pennypicks is not an
Investment Advisor, Financial Planning Service or a Stock Brokerage
Firm and in accordance with such pennypicks is not offering investment
advice or promoting any investment strategies. pennypicksis not offering
securities for sale or solicitation of any offer to buy or sell securities.
Any reference in the newsletter to past performance(s) of companies
previously profiled in the newsletter are specially selected to be referenced
based on the favorable performance of said companies and the companies
referenced may not be representative of all past profiles as not all past
profiles have performed as well. Please remember that past performance
does not predict future results which is why it's called past performance”.
pennypicks holds sixty thousand shares of this company profile. pennypicks,
its affiliates, associates, relatives and anyone associated with pennypicks
in any manner reserves the right to either buy or sell shares in the profiled
company's stock, either before the date of the profile, during the date of the
profile or at any time after the date of the profile. We have an inherent conflict
of interest by sending the newsletter at the same time we may own stock in
the same company. We reserve the right to sell shares at anytime, even
during the time periodin which we are profiling a company. pennypicks may
profile companies trading in fast moving, volatile markets, and any reader
of this newsletter should observe the trading behavior of any profiled
company prior to investing.



unsubscribe at outanna020@excite.com




From list@netscape.com  Tue Apr 24 06:20:27 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05617
	for ; Tue, 24 Apr 2001 06:20:26 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3JK8Av10450;
	Thu, 19 Apr 2001 13:08:10 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3JK8As27769;
	Thu, 19 Apr 2001 13:08:10 -0700 (PDT)
Resent-Date: Thu, 19 Apr 2001 13:08:10 -0700 (PDT)
Date: Thu, 19 Apr 2001 16:07:32 -0400
Message-Id: <200104192007.QAA24666@qsun.mt.att.com>
From: rvh@qsun.mt.att.com (Richard V Huber)
To: ietf-ldapext@netscape.com, robert.byrne@Sun.COM
Subject: Re: browse permission in the ACM
Resent-Message-ID: <"PG2X.A.RxG.lW036"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

As I understand Option 3, it says that the "b" permission is not
checked on the base object of a search.

I'm trying to figure out what permissions would be checked for the base
object under option 3.  For example, item 1 in section 5.2 would not
seem to apply when the candidateDN is the base object.  How about the
part of item 2 that discusses extensibleMatch?

One of the reasons I had not responded to your previous email is that
I'm still trying to figure out whether these questions really matter in
practical directories.

Rick Huber

: Sender: Robert.Byrne@Sun.COM
: From: robert byrne 
: To: ietf-ldapext@netscape.com
: Subject: Re: browse permission in the ACM
: 
: 
: All,
: 
: By way of a partial conclusion of this thread, for the next draft I
: intend to propose 3. below.
: 
: Rob.
: 
: robert byrne wrote:
: > 
: > Rick,
: > 
: > Maybe now is a good time to list the options (that I can think of) open
: > to us for this browsing concept:
: > 
: > 1. Keep it as is in section 5.2, so that "b" is just an entry-level
: > permission you need on all entries when you search.
: > 
: > 2. Drop it entirely, so that we have no dedicated entry-level permission
: > on search.  For example, we don't have an entry-level Modify
: > permission.  In this model, we would be relying on the returnDn
: > permission for entry-level protection.  I guess "entry-level protection"
: > of an entry in the context of search means protecting the dn so this
: > seems to make sense.
: > 
: > 3. Keep "b" but only require it on non-base entries.  This means that
: > you can control the power of the subtree and onelevel search options on
: > your DIT.
: > 
: > 4. Keep "b" but only require it on non-base entries AND introduce a "v"
: > which you are now required to see base entries of searches.  This means
: > that you can control the power of the subtree and onelevel search
: > options on your DIT AND allows you to explicitly protect bases of
: > searches at the entry level.
: > 
: > 5. As 4. but have "b"=>"v", so that if you want you can forget about "v"
: > and just use "b" as in 1.  This is what I proposed in my earlier mail.
: > 
: > I agree that it is not worth complicating things for this browsing
: > capability.  Given this, if people like the ability to put a brake on
: > the subtree and onelevel options (I guess the use of these options is
: > what we mean by "browsing" in LDAP), I'm tempted to propose 3. as the
: > simplest option.  After that if we consider that controling browsing is
: > not important, I'm tempted by 2., namely dropping "b" entirely...though
: > we'd need to check that this doesn't leave some holes.
: > 
: > Any votes/opinions on these options ?
: > 
: > Rick, for your other point on aborting searches re the returnDn
: > permission, I would prefer to discuss that in a different thread called
: > something like "protecting dns in the ACM", as I think it desreves a
: > discussion itself.
: > 
: > Rob.
: > 
: > Richard V Huber wrote:
: > >
: > > Since Rob says `To minimize the number of combinations we also allow
: > > the base element to be seen if "b" permission is assigned to it', it
: > > seems that the new "b" includes the new "v" and is identical to the old
: > > "b".  So the real change here is the addition of the separate "v"
: > > permission.
: > >
: > > So I assume new the definitions of "b" and "v" in section 4.2.1 would
: > > be something like (trying to stay reasonably close to the current
: > > wording):
: > >
: > >   b BrowseDN
: > >
: > >   If granted, permits entries to be accessed using search operations
: > >   regardless of whether they explicitly provide the name of the entry.
: > >
: > >   v VertexDN
: > >
: > >   If granted, permits entries to be accessed using search operations
: > >   only if the name of the entry is explicitly supplied.
: > >
: > > I guess my main question is whether the change is worth it.  The model
: > > is already rather complicated.  Does this change provide value that is
: > > worth the additional complexity?  I'm not sure that it does.
: > >
: > > And one other vaguely related question that came to mind after reading
: > > Rob's email.  He notes that "... the absence of a "v" or "b" permission
: > > at any point does not abort the search operation as a whole or even on
: > > a particular subtree."
: > >
: > > I have been assuming (and this seemed like a good time to check) that
: > > absence of a "t" permission DOES abort the search operation on a
: > > particular subtree, since returning the DN of any object further down
: > > in the tree would require that the DN of the object without "t"
: > > permission be returned.  Is that the generally accepted view?
: > >
: > > Rick Huber
: > >
: > > : Sender: Robert.Byrne@Sun.COM
: > > : From: robert byrne 
: > > : To: ietf-ldapext@netscape.com
: > > : Subject: browse permission in the ACM
: > > :
: > > :
: > > : All,
: > > :
: > > : The following is a proposal to tweak the current browse permission in
: > > : the ACM.
: > > : The current usage of the "b" permission in the ACM is really just a read
: > > : level permission on candidate entries. From section 5.2:
: > > :
: > > : " 1.  permission "b" to the entry candidateDN
: > > :
: > > :       If this permission is not granted then the dn
: > > :       candidateDN MUST NOT be returned nor any attribute
: > > :       type nor attribute value from this entry.
: > > :
: > > :       If this permission is granted then the dn candidateDN
: > > :       MAY be returned.
: > > : "
: > > :
: > > : Some people felt that it would be better to have it behave more like
: > > : it's name suggests...which is that you would require this permission to
: > > : be able to have a search request return __non-base__ entries to you
: > > : during a search.  The spirit of this idea is something like "Hang on,
: > > : subtree and onelevel searches are really powerful, there should be a
: > > : way continue to grant read access to entries, but to limit the power of
: > > : these search options".
: > > :
: > > : One way to do this is to refine "b" into two permissions 'new "b"' and
: > > : "v".
: > > : The 'new "b"' still stands for browse and you will need this to see
: > > : non-base entries.   At a stretch the "v" stands for "vertex" as you need
: > > : this to see the base entry (the vertex) of a search.  (From now on "b"
: > > : means 'new "b"'.) To minimize the
: > > : number of combinations we also allow the base element to be seen if "b"
: > > : permission is assigned to it.  So, the new text I am proposing for this
: > > : would be:
: > > :
: > > :
: > > : " 1.  permission "v" or "b" to the entry candidateDN, if the entry is
: > > : the
: > > :      base of the search operation.
: > > :      permission "b" to the entry if the entry is not the base of the
: > > : search.
: > > :
: > > :      If these conditions are not satisfied then the dn
: > > :      candidateDN MUST NOT be returned nor any attribute
: > > :      type nor attribute value from this entry.
: > > :
: > > :      If this permission is granted then the dn candidateDN
: > > :      MAY be returned."
: > > :
: > > : Note that the absence of a "v" or "b" permission at any point does not
: > > : abort the search operation as a whole or even on a particular subtree.
: > > : We could specify such behaviour but I believe most LDAP implementations
: > > : have an "optimistic" approach to searching for entries ie. I may be
: > > : denied access to this entry, but there may be other entries to which I
: > > : do have access, so keep searching.
: > > :
: > > : Note also that if you only ever use "b", it will behave just like a read
: > > : level permission on the entry--we provide the "v" refinement for those
: > > : users that might want to limit "browsability" of their DIT.
: > > :
: > > : An example.  Suppose that some given user has all rights on all
: > > : these subtrees, the only difference being in allocation of the "b" and
: > > : "v" rights which are shown in brackets, after the RDN of the entry.
: > > :
: > > :         ou=sun.com(b)
: > > :         |
: > > :         |------------------------------------------------
: > > :         |                       |                       |
: > > :         ou=sortOfBrowsable()    ou=notBrowsable(v)      ou=Browsable(b)
: > > :         |                       |                       |
: > > :         ou=level1(v)            ou=level1(v)            ou=level1(b)
: > > :         |                       |                       |
: > > :         ou=level2(b)            ou=level2(v)            ou=level2(b)
: > > :
: > > :
: > > : Eg 1: If he does a search like this:
: > > :
: > > :         baseEntry: ou=sortOfBrowsable,o=sun.com
: > > :         filter: ou=*
: > > :         scope: subtree
: > > :
: > > : He will get back the following entry:
: > > :
: > > :         ou=level2,ou=sortOfBrowsable,ou=sun.com (has "b" on this)
: > > :
: > > : -----
: > > :
: > > : Eg 2: Then, if he does a search like this:
: > > :
: > > :         baseEntry: ou=sortOfBrowsable,o=sun.com
: > > :         filter: ou=*
: > > :         scope: base
: > > :
: > > : He will get back no entries (neither "v" nor "b" on the base).
: > > :
: > > : -----
: > > :
: > > : Eg 3: If he does a search like this:
: > > :
: > > :         baseEntry: ou=notBrowsable,ou=sun.com
: > > :         filter: ou=*
: > > :         scope: subtree
: > > :
: > > : He will get back the following entry:
: > > :
: > > :         ou=notBrowsable,ou=sun.com (has "v" and it's the base)
: > > :
: > > : -----
: > > :
: > > :
: > > : Eg 4: If he does a search like this:
: > > :
: > > :         baseEntry: ou=notBrowsable,ou=sun.com
: > > :         filter: ou=*
: > > :         scope: base
: > > :
: > > : He will get back the following entry:
: > > :
: > > :         ou=notBrowsable,ou=sun.com (has "v" and it's the base)
: > > :
: > > : -----
: > > :
: > > :
: > > : Eg 5: Then, if he does a search like this:
: > > :
: > > :         baseEntry: ou=Browsable,ou=sun.com
: > > :         filter: ou=*
: > > :         scope: subtree
: > > :
: > > : He will get back the following entries:
: > > :         ou=Browsable,ou=sun.com       (has "b")
: > > :         ou=level1,ou=Browsable,ou=sun.com (has "b")
: > > :         ou=level2,ou=Browsable,ou=sun.com (has "b")
: > > :
: > > : -----
: > > :
: > > :
: > > : Eg 6: Then, if he does a search like this:
: > > :
: > > :         baseEntry: ou=Browsable,ou=sun.com
: > > :         filter: ou=*
: > > :         scope: base
: > > :
: > > : He will get back the following entries:
: > > :         ou=Browsable,ou=sun.com       (has "b")
: > > :
: > > : -----
: > > :
: > > :
: > > : Eg 7: Then, if he does a search like this:
: > > :
: > > :         baseEntry: ou=sun.com
: > > :         filter: ou=*
: > > :         scope: onelevel
: > > :
: > > : He will get back the following entries:
: > > :         ou=Browsable,ou=sun.com       (has "b")
: > > :
: > > : -----
: > > :
: > > : Any comments on this modification ?
: > > :
: > > : Rob.



From list@netscape.com  Tue Apr 24 11:44:55 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09598
	for ; Tue, 24 Apr 2001 11:44:54 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3OFgRv10814;
	Tue, 24 Apr 2001 08:42:28 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3OFgRI01247;
	Tue, 24 Apr 2001 08:42:27 -0700 (PDT)
Resent-Date: Tue, 24 Apr 2001 08:42:27 -0700 (PDT)
Sender: Robert.Byrne@Sun.COM
Message-ID: <3AE59E43.B399AF4@Sun.COM>
Date: Tue, 24 Apr 2001 17:39:47 +0200
From: robert byrne 
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" 
CC: ietf-ldapext@netscape.com
Subject: Re: subjects in LDAP ACMs
References: <5.0.2.1.0.20010411183522.00aa51f0@127.0.0.1>
	 <5.0.2.1.0.20010412110700.00b10c60@127.0.0.1> <5.1.0.14.0.20010423120707.00a93c60@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"Xxev6B.A.qO.X7Z56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit


Kurt,

I would say that those policy things that belong in the authentication
subsystem are those things which are likely to be required to be a
function of the authorization id only.  For example, policy like "three
consecutive failed binds by the same requestor then lock the account" or
"time of day restriction on class X of users".  Policy which is likely
to be required to be a function of dn, attribute and permissions
naturally belongs in the ACM.  I think the factors we have identified
are in this class.  For example, there may be particular sensitive
subtrees, entries and attributes the modification of which requires
strong authentication.

Anyone else care to cast a vote for or against factors in the ACM--to
recall they currently look something like this:

factor = [ "authnLevel:" authnLevel ":" ]
        [ "ipAddress:" ipAddress ]
        [ "dns:" [ "*." ] domainname ) ]

Finally what we are discussing here are "factors" not "subjects" and so
I don't think they are ruled out by U2.

Rob.

"Kurt D. Zeilenga" wrote:
> 
> It's my personal opinion that ACMs should be based upon
> authorization identities and that controls based upon
> other factors (authentication method (or level), IP
> address, DNS name, etc) should be left to other administrative
> mechanisms (such as those upon within the authentication
> subsystem and those external to LDAP (topology enforcement
> systems)).
> 
> The primary reason is simplicity.  While an extensible
> ACM which supports multiple orthogonal access control factors
> would be more flexible, it is also quite complex (to design,
> implement, and use).
> 
> Hence, I think we should do as RFC 2820 suggests [with clarification]:
>    U1.  When in doubt, simpler is better, both at the interface and in
>    the implementation.
> 
>    U2.  Subjects MUST be drawn from the "natural" LDAP namespace; they
>    should be DNs [or RFC2829 authzIds].
> 
> The suggested "non-factor subjects" are not drawn from the "natural"
> LDAP name space.  They add unnecessary complexity to the interface
> and its implementations.
> 
> Kurt



From list@netscape.com  Tue Apr 24 13:12:16 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10811
	for ; Tue, 24 Apr 2001 13:12:15 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3OHA3v00071;
	Tue, 24 Apr 2001 10:10:03 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3OHA4M11992;
	Tue, 24 Apr 2001 10:10:04 -0700 (PDT)
Resent-Date: Tue, 24 Apr 2001 10:10:04 -0700 (PDT)
Date: Tue, 24 Apr 2001 13:09:54 -0400
Message-Id: <200104241709.NAA12207@qsun.mt.att.com>
From: rvh@qsun.mt.att.com (Richard V Huber)
To: Kurt@openldap.org
Subject: Re: Comments on namedref draft
Cc: ietf-ldapext@netscape.com
Resent-Message-ID: <"68tBmD.A.66C.pNb56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

My concern is that flexibility in URIs will work against
interoperability.  A fully conforming server can return referrals that
a fully conforming client has no idea how to deal with.

Could we say that the URI SHOULD be in the form of an LDAP URL, but it
MAY be in some other form?  That would at least point implementers in
the right direction.

: To: rvh@qsun.mt.att.com (Richard V Huber)
: From: "Kurt D. Zeilenga" 
: Subject: Re: Comments on namedref draft
: Cc: ietf-ldapext@netscape.com
: 
: At 01:32 PM 4/23/01, Richard V Huber wrote:
: >What would we break if we required referrals to be LDAP URLs?
: 
: We would lose the flexibility provided by RFC 2251:
:    Other kinds of URLs may be returned, so long as the operation
:    could be performed using that protocol.
: 
: While RFC 2251 could use some clarification in this area, I believe
: that it's generally accepted that clients should ignore URLs they
: cannot process (either because they are not of a scheme the client
: recognizes, or have unrecognized critical extension, or other
: reason).
: 
: >In the same section:
: >   The referential integrity of the URI SHALL NOT be validated by the
: >   server holding or returning the URI (whether as part of the value of
: >   the attribute or as part of a referral result or search reference
: >   response).
: >
: >I'm not clear why we need to be so emphatic here.  I believe that the
: >client MUST NOT expect the server to do referential integrity checks,
: >but why make it "illegal" for the server to do them if it wishes?
: 
: I believe a SHOULD would be fine.  This recommends a practice
: consistent with the data model but would allows behaviors
: which do not violate the interface.
: 
: 
: >In Section 7.6.1:
: >
: >   7.6.1 Bind
: >
: >   A server SHOULD process a bind request as if it held no referral
: >   objects.  That is, if the bind name is a referral object or is
: >   subordinate to a referral object, the server SHOULD process the
: >   request normally as appropriate for a non-existent bind name (e.g.
: >   return invalidCredentials).
: >
: >I think this needs some discussion on the list.
: 
: I should reword this a bit.  The intent was not to disallow the
: server from chaining the request, but was to recommend the server
: not return a referral to the bind operation (as the semantics of
: such are ill defined).
: 
: > As this text stands,
: >it would make it very difficult to split a large directory into several
: >pieces on different servers.  Other current drafts (e.g.
: >draft-reed-ldup-inheritance-00.txt) seem to be working towards
: >supporting a more distributed environment.  I would prefer a MAY here
: >(or remove section 7.6.1 entirely) so we can address this issue in more
: >detail in future work.



From list@netscape.com  Tue Apr 24 14:12:10 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11778
	for ; Tue, 24 Apr 2001 14:12:09 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3OI9qv14892;
	Tue, 24 Apr 2001 11:09:52 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3OI9rw20702;
	Tue, 24 Apr 2001 11:09:53 -0700 (PDT)
Resent-Date: Tue, 24 Apr 2001 11:09:53 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010424103403.00ac0d40@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 24 Apr 2001 11:07:53 -0700
To: rvh@qsun.mt.att.com (Richard V Huber)
From: "Kurt D. Zeilenga" 
Subject: Re: Comments on namedref draft
Cc: ietf-ldapext@netscape.com
In-Reply-To: <200104241709.NAA12207@qsun.mt.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"7D5gC.A.1CF.vFc56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 10:09 AM 4/24/01, Richard V Huber wrote:
>My concern is that flexibility in URIs will work against
>interoperability.  A fully conforming server can return referrals that
>a fully conforming client has no idea how to deal with.

That's primarily an protocol issue which LDAPbis should address.

However, I note that this I-D should say that it does not address
use of non-LDAP URIs and hence the paragraph in question should
be rewritten.  I suggest:

  Other URI schemes MAY be used so long as all operations returning
  referrals based upon the value could be performed.  This document
  does not detail use of non-LDAP URIs.  This is left to future
  specifications.

  All values of a ref attribute MUST point to services which are 
  equally capable of handling operations referred to these services.

Kurt



From list@netscape.com  Tue Apr 24 14:37:00 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12092
	for ; Tue, 24 Apr 2001 14:37:00 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3OIYnv20316;
	Tue, 24 Apr 2001 11:34:49 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3OIYnI05664;
	Tue, 24 Apr 2001 11:34:49 -0700 (PDT)
Resent-Date: Tue, 24 Apr 2001 11:34:49 -0700 (PDT)
From: 
Date: Tue, 24 Apr 2001 14:31:10 -0400
Subject: PricewaterhouseCoopers is looking for a LDAP Practice Leader for it's
 E-biz practice
To: ietf-ldapext@netscape.com
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
X-MIMETrack: Serialize by Router on US-AMSMTA005/US/INTL(Release 5.0.6
 |December 14, 2000) at 04/24/2001 02:31:36 PM
Resent-Message-ID: <"I-bTNB.A.rXB.Hdc56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com






PricewaterhouseCoopers is  looking for a Sr. Level LDAP/Directory Practice
leader for our growing e-Biz practice.  Our practice is fairly new  ( about
a year old) and roughly we have 120 consultants. We need someone who has
designed and implemented LDAP multiple times, can manage projects and
people.  Being in charge of knowledge transfer with the staff is extremely
important.

The position could reside out of any major city and would involve at least
80% travel.  The compensation would range from 140k to 200k plus an
excellent benefits package.


If anyone would happen to know of someone that would be a good fit and like
to hear more , please have them contact me either through e-mail or phone.
Thanks



Elizabeth Deschenes
678-419-4104








----------------------------------------------------------------
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.



From list@netscape.com  Tue Apr 24 17:22:13 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15567
	for ; Tue, 24 Apr 2001 17:22:13 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3OLK8n03298;
	Tue, 24 Apr 2001 14:20:08 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3OLK8616514;
	Tue, 24 Apr 2001 14:20:08 -0700 (PDT)
Resent-Date: Tue, 24 Apr 2001 14:20:08 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010424123427.00ab8680@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 24 Apr 2001 13:29:07 -0700
To: robert byrne 
From: "Kurt D. Zeilenga" 
Subject: Re: subjects in LDAP ACMs
Cc: ietf-ldapext@netscape.com
In-Reply-To: <3AE59E43.B399AF4@Sun.COM>
References: <5.0.2.1.0.20010411183522.00aa51f0@127.0.0.1>
 <5.0.2.1.0.20010412110700.00b10c60@127.0.0.1>
 <5.1.0.14.0.20010423120707.00a93c60@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"C88yw.A.nAE.E4e56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 08:39 AM 4/24/01, robert byrne wrote:
>I would say that those policy things that belong in the authentication
>subsystem are those things which are likely to be required to be a
>function of the authorization id only.

No.  The authentication subsystem is a function of credentials
and other information which results in the establishment of an
authorization identity.  This authorization identity is then
granted access to information by the ACM. While the ACM could
base access upon information by other factors, such as which
mechanism was used and/or the presence of security layers, there
are numerous security considerations the user must be made aware
of.

I see a few major considerations.  In particular, an attack upon
a weak mechanism could be used to gain access requiring strong
authentication.  That is, a password exposed by use of simple bind
could be used to gain access via DIGEST-MD5.

I also note that the ACM does nothing to prevent a client to
prevent a client from exposing data to attackers.  It only prevents
the server from exposing data.  Policy meant to protect the
exposure of sensitive information must encompass the client as
well.  While the authentication/authorization system cannot prevent
clients which access the directory anonymously from exposing such
information, the authentication/authorization can and SHOULD
prevent authorized clients from accessing the directory (as a whole)
without appropriate authorization.

>Finally what we are discussing here are "factors" not "subjects" and so
>I don't think they are ruled out by U2.

Authorization identities are one type of factors.  There are
numerous types of factors which could be used to make access
control decisions.  I believe RFC 2820 and this I-D uses the
term subject to refer to any kind of factor derived from or
provided from the client's LDAP association.
  "Security subject - An entity in an active role to which a
  security policy applies." [RFC2820]

  "This policy data describes security-relevant characteristics
  of the requesting subject and the rules which govern the use
  of the target object." [I-D]

I assume U2 applies not only to authorization identities but
all factors associated with the subject.  All of the factors
you suggest relate directly to the entity which the security
policy applies and hence are "subject factors" or "subjects".

Kurt



From list@netscape.com  Wed Apr 25 09:07:06 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14014
	for ; Wed, 25 Apr 2001 09:07:06 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3PD0tv01500;
	Wed, 25 Apr 2001 06:00:55 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3PD0tI22847;
	Wed, 25 Apr 2001 06:00:55 -0700 (PDT)
Resent-Date: Wed, 25 Apr 2001 06:00:55 -0700 (PDT)
Sender: Robert.Byrne@Sun.COM
Message-ID: <3AE6CA56.66DDDA6A@Sun.COM>
Date: Wed, 25 Apr 2001 15:00:07 +0200
From: robert byrne 
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" 
CC: ietf-ldapext@netscape.com
Subject: Re: subjects in LDAP ACMs
References: <5.0.2.1.0.20010411183522.00aa51f0@127.0.0.1>
	 <5.0.2.1.0.20010412110700.00b10c60@127.0.0.1>
	 <5.1.0.14.0.20010423120707.00a93c60@127.0.0.1> <5.1.0.14.0.20010424123427.00ab8680@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"fYidb.A.jkF.Fqs56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> 
> 
> I see a few major considerations.  In particular, an attack upon
> a weak mechanism could be used to gain access requiring strong
> authentication.  That is, a password exposed by use of simple bind
> could be used to gain access via DIGEST-MD5.
> 

This is certainly a deployment consideration.  At the same time the
point is somehow trivial--in security terms, all bets are off for a
client who exposes his authentication credentials.

> >Finally what we are discussing here are "factors" not "subjects" and so
> >I don't think they are ruled out by U2.
> 
> Authorization identities are one type of factors.  There are
> numerous types of factors which could be used to make access
> control decisions.  I believe RFC 2820 and this I-D uses the
> term subject to refer to any kind of factor derived from or
> provided from the client's LDAP association.
>   "Security subject - An entity in an active role to which a
>   security policy applies." [RFC2820]
> 
>   "This policy data describes security-relevant characteristics
>   of the requesting subject and the rules which govern the use
>   of the target object." [I-D]
> 
> I assume U2 applies not only to authorization identities but
> all factors associated with the subject.  All of the factors
> you suggest relate directly to the entity which the security
> policy applies and hence are "subject factors" or "subjects".
> 

The only explicit reference to these "things" I can find in 2820
actually refers to them as the "Access context" and doesn't have
anything else to say about them:

   "Access context - The context, in terms of such variables as
location,
   time of day, level of security of the underlying associations, etc.,
   in which an access to a security object is made."

Rob.

> Kurt



From list@netscape.com  Wed Apr 25 10:09:43 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16521
	for ; Wed, 25 Apr 2001 10:09:42 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3PE7Zv08205;
	Wed, 25 Apr 2001 07:07:35 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3PE7Zg12032;
	Wed, 25 Apr 2001 07:07:35 -0700 (PDT)
Resent-Date: Wed, 25 Apr 2001 07:07:35 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010425070146.00ad6310@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 25 Apr 2001 07:05:44 -0700
To: ietf-ldapext@netscape.com
From: "Kurt D. Zeilenga" 
Subject: Fwd: I-D ACTION:draft-zeilenga-auth-lvl-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"Gv1RRD.A.o7C.mot56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This I-D describes upon one possible method for classifying
authentication mechanisms by level which may be useful in
specification and/or implementation of authentication,
authorization, and access control systems.

Enjoy!  Kurt

>To: IETF-Announce: ;
>From: Internet-Drafts@ietf.org
>Reply-to: Internet-Drafts@ietf.org
>Subject: I-D ACTION:draft-zeilenga-auth-lvl-00.txt
>Date: Wed, 25 Apr 2001 07:15:03 -0400
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>        Title           : Authentication Mechanisms Levels
>        Author(s)       : K. Zeilenga
>        Filename        : draft-zeilenga-auth-lvl-00.txt
>        Pages           : 9
>        Date            : 24-Apr-01
>        
>Numerous authentication mechanisms are in use today on the Internet.
>It is desirable to give administrators the choice of which mechanisms
>to support in their deployments and to give users the choice which
>mechanisms to use.  This document offers terminology designed to be
>easily understandable by users and administrators of Internet
>services, while being meaningful to designers and developers of these
>services and associated Internet protocols.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-zeilenga-auth-lvl-00.txt
>
>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-zeilenga-auth-lvl-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-zeilenga-auth-lvl-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:     <20010424133326.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-zeilenga-auth-lvl-00.txt
>
>



From list@netscape.com  Wed Apr 25 11:04:18 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18870
	for ; Wed, 25 Apr 2001 11:04:18 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3PF2Gv16422;
	Wed, 25 Apr 2001 08:02:16 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3PF2HM07744;
	Wed, 25 Apr 2001 08:02:17 -0700 (PDT)
Resent-Date: Wed, 25 Apr 2001 08:02:17 -0700 (PDT)
From: Mark 
To: 
Date: Wed, 25 Apr 2001 16:30:37 -0800
Subject: To Submit and Check Ranking
Reply-To: mark@nuelectrics.com.netscape.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Priority: 3
Message-ID: 
Resent-Message-ID: <"4KgVmC.A.s3B.0bu56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Hi!

If you need to submit your site to search engines and to check the ranking of 
your site with search engines, here are two new, and completely FREE and NO-PROFIT 
web sites:

http://www.submitpilot.com/
http://www.rankpilot.com/


They don't sell anything (not advertising, even): they just offer a free service 
to the Internet community.

Bye!

Mark E.




From list@netscape.com  Wed Apr 25 11:35:03 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20016
	for ; Wed, 25 Apr 2001 11:35:03 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3PFWvv23206;
	Wed, 25 Apr 2001 08:32:57 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3PFR1w19947;
	Wed, 25 Apr 2001 08:27:02 -0700 (PDT)
Resent-Date: Wed, 25 Apr 2001 08:27:02 -0700 (PDT)
Sender: Robert.Byrne@Sun.COM
Message-ID: <3AE6EC74.AD21C46C@Sun.COM>
Date: Wed, 25 Apr 2001 17:25:40 +0200
From: robert byrne 
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Richard V Huber 
CC: ietf-ldapext@netscape.com
Subject: Re: browse permission in the ACM
References: <200104231752.NAA03713@qsun.mt.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"N-nnz.A.z0E.8yu56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit


Rick,

I agree that this needs clarification.  To be on the safe side my
suggestion would be to require a filter permisison check on the dn
attributes being matched.  For simplicity I would make it independent of
the scope.  So, for non-base entries we would test "b" _and_ the
required filter permissions, while for base entries we would just test
the filter permissions.

Rob.

Richard V Huber wrote:
> 
> This email is carrying around a lot of history.  I've clipped off some
> of the earlier messages in the chain.
> 
> My concern about extensibleMatch and option 3 was based on this
> paragraph from the draft (from Section 5.2, item 2):
> 
>       The above statement covers the case where the
>       attributes are being evaluated as part of an
>       extensibleMatch (RFC 2251 section 4.5.1) which appears
>       in the filter.  In the case where the dnAttributes
>       field of the extensibleMatch is true then we do not
>       require any access checks to the attributes of the dn
>       candidateDN as access to these is taken to be granted
>       by the "b" permission, which has already been required
>       above.
> 
> Since Option 3 implies that the "b" permission is NOT required for the
> base object to be searched, you might want to change 5.2 item 2 to
> say that "r" and "s" permissions ARE required for extensibleMatches on
> the DN of the base object.  But given that the "t" permission exists,
> this may not really matter in real-life situations.
> 
> Rick Huber
> 
> : From: robert byrne 
> : To: Richard V Huber 
> : CC: ietf-ldapext@netscape.com
> : Subject: Re: browse permission in the ACM
> :
> : Richard V Huber wrote:
> : >
> : > As I understand Option 3, it says that the "b" permission is not
> : > checked on the base object of a search.
> : >
> : > I'm trying to figure out what permissions would be checked for the base
> : > object under option 3.  For example, item 1 in section 5.2 would not
> : > seem to apply when the candidateDN is the base object.  How about the
> : > part of item 2 that discusses extensibleMatch?
> :
> : The idea is that "b" gives you the right to find an entry using the
> : subtree and onlevel options of search.  For a base entry, we do not
> : require "b" because you have named it.  We would still require the other
> : permissions (filter, returnDn, readOnAttribute) for a base entry.  Where
> : we refer to "b" in those sections we should say something like "as per
> : item 1."--ie. we never require "b" on base entries.
> :
> : >
> : > One of the reasons I had not responded to your previous email is that
> : > I'm still trying to figure out whether these questions really matter in
> : > practical directories.
> :
> : Good question--I agree the effect is a bit subtle and not obviously a
> : mandatory feature.  It's another level of granularity of control on
> : search.  I think you can see a similar effect in the Unix file system
> : where you can be in a directory and type "ls" and see nothing but if you
> : do, say, "cd public_html" you will find yourself in that directory, if
> : you have the appropriate rights.  In LDAP, you might want to have a
> : subtree with resources users can query if they know about them, but not
> : be able to discover resources "easily".
> :
> : At Pittsburg people seemed to like the browsing idea and I agreed to
> : propose something.
> :
> : Rob.
> :
> : >
> : > Rick Huber
> : >
> : > : Sender: Robert.Byrne@Sun.COM
> : > : From: robert byrne 
> : > : To: ietf-ldapext@netscape.com
> : > : Subject: Re: browse permission in the ACM
> : > :
> : > :
> : > : All,
> : > :
> : > : By way of a partial conclusion of this thread, for the next draft I
> : > : intend to propose 3. below.
> : > :
> : > : Rob.



From list@netscape.com  Wed Apr 25 11:35:45 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20051
	for ; Wed, 25 Apr 2001 11:35:44 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3PFV0n29840;
	Wed, 25 Apr 2001 08:31:00 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3PFV0k22839;
	Wed, 25 Apr 2001 08:31:00 -0700 (PDT)
Resent-Date: Wed, 25 Apr 2001 08:31:00 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010425071355.00ad5d00@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 25 Apr 2001 08:29:01 -0700
To: robert byrne 
From: "Kurt D. Zeilenga" 
Subject: Re: subjects in LDAP ACMs
Cc: ietf-ldapext@netscape.com
In-Reply-To: <3AE6CA56.66DDDA6A@Sun.COM>
References: <5.0.2.1.0.20010411183522.00aa51f0@127.0.0.1>
 <5.0.2.1.0.20010412110700.00b10c60@127.0.0.1>
 <5.1.0.14.0.20010423120707.00a93c60@127.0.0.1>
 <5.1.0.14.0.20010424123427.00ab8680@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"k1P-AD.A.dkF.y2u56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 06:00 AM 4/25/01, robert byrne wrote:
>The only explicit reference to these "things" I can find in 2820
>actually refers to them as the "Access context" and doesn't have
>anything else to say about them:

As I noted previously, RFC 2820's use of the terminology is a bit
inexact.  However, I believe the intent of the stated requirements is
clear enough.  I won't hair split over them.

I just reiterate my basic position:

Support for multiple orthogonal subject factors is a rat hole
  (consider precedence and "effective rights" issues).

Support for a single subject factor which includes elements
  not drawn from the "natural" LDAP name space has limited use
  subject to significant security considerations.

The need for non-"natural" subject factors could be addressed
via other means.

For these and other reasons, I believe it best for the LDAP ACM
not support multiple orthogonal subject factors nor support
a single subject factor which includes factors not drawn from
the "natural" LDAP name space.

Lastly, I believe we need to keep the LDAP ACM simple.  Not
just for security ask, but for sake of timely completion of this
work.

Kurt





From list@netscape.com  Wed Apr 25 16:47:43 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00686
	for ; Wed, 25 Apr 2001 16:47:42 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3PKjWn03384;
	Wed, 25 Apr 2001 13:45:32 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3PKjWU04201;
	Wed, 25 Apr 2001 13:45:32 -0700 (PDT)
Resent-Date: Wed, 25 Apr 2001 13:45:32 -0700 (PDT)
Date: Wed, 25 Apr 2001 16:45:19 -0400
Message-Id: <200104252045.QAA15453@qsun.mt.att.com>
From: rvh@qsun.mt.att.com (Richard V Huber)
To: robert.byrne@Sun.COM
Subject: Re: browse permission in the ACM
Cc: ietf-ldapext@netscape.com
Resent-Message-ID: <"JCeyf.A.DAB.ldz56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Do you mean this as a general statement or specifically for
extensibleMatch?  If it is a general statement, is there really any
remaining use for the "b" permission?

Rick Huber

: From: robert byrne 
: To: Richard V Huber 
: CC: ietf-ldapext@netscape.com
: Subject: Re: browse permission in the ACM
: 
: Rick,
: 
: I agree that this needs clarification.  To be on the safe side my
: suggestion would be to require a filter permisison check on the dn
: attributes being matched.  For simplicity I would make it independent of
: the scope.  So, for non-base entries we would test "b" _and_ the
: required filter permissions, while for base entries we would just test
: the filter permissions.
: 
: Rob.
: 
: Richard V Huber wrote:
: > 
: > This email is carrying around a lot of history.  I've clipped off some
: > of the earlier messages in the chain.
: > 
: > My concern about extensibleMatch and option 3 was based on this
: > paragraph from the draft (from Section 5.2, item 2):
: > 
: >       The above statement covers the case where the
: >       attributes are being evaluated as part of an
: >       extensibleMatch (RFC 2251 section 4.5.1) which appears
: >       in the filter.  In the case where the dnAttributes
: >       field of the extensibleMatch is true then we do not
: >       require any access checks to the attributes of the dn
: >       candidateDN as access to these is taken to be granted
: >       by the "b" permission, which has already been required
: >       above.
: > 
: > Since Option 3 implies that the "b" permission is NOT required for the
: > base object to be searched, you might want to change 5.2 item 2 to
: > say that "r" and "s" permissions ARE required for extensibleMatches on
: > the DN of the base object.  But given that the "t" permission exists,
: > this may not really matter in real-life situations.
: > 
: > Rick Huber
: > 
: > : From: robert byrne 
: > : To: Richard V Huber 
: > : CC: ietf-ldapext@netscape.com
: > : Subject: Re: browse permission in the ACM
: > :
: > : Richard V Huber wrote:
: > : >
: > : > As I understand Option 3, it says that the "b" permission is not
: > : > checked on the base object of a search.
: > : >
: > : > I'm trying to figure out what permissions would be checked for the base
: > : > object under option 3.  For example, item 1 in section 5.2 would not
: > : > seem to apply when the candidateDN is the base object.  How about the
: > : > part of item 2 that discusses extensibleMatch?
: > :
: > : The idea is that "b" gives you the right to find an entry using the
: > : subtree and onlevel options of search.  For a base entry, we do not
: > : require "b" because you have named it.  We would still require the other
: > : permissions (filter, returnDn, readOnAttribute) for a base entry.  Where
: > : we refer to "b" in those sections we should say something like "as per
: > : item 1."--ie. we never require "b" on base entries.
: > :
: > : >
: > : > One of the reasons I had not responded to your previous email is that
: > : > I'm still trying to figure out whether these questions really matter in
: > : > practical directories.
: > :
: > : Good question--I agree the effect is a bit subtle and not obviously a
: > : mandatory feature.  It's another level of granularity of control on
: > : search.  I think you can see a similar effect in the Unix file system
: > : where you can be in a directory and type "ls" and see nothing but if you
: > : do, say, "cd public_html" you will find yourself in that directory, if
: > : you have the appropriate rights.  In LDAP, you might want to have a
: > : subtree with resources users can query if they know about them, but not
: > : be able to discover resources "easily".
: > :
: > : At Pittsburg people seemed to like the browsing idea and I agreed to
: > : propose something.
: > :
: > : Rob.
: > :
: > : >
: > : > Rick Huber
: > : >
: > : > : Sender: Robert.Byrne@Sun.COM
: > : > : From: robert byrne 
: > : > : To: ietf-ldapext@netscape.com
: > : > : Subject: Re: browse permission in the ACM
: > : > :
: > : > :
: > : > : All,
: > : > :
: > : > : By way of a partial conclusion of this thread, for the next draft I
: > : > : intend to propose 3. below.
: > : > :
: > : > : Rob.



From list@netscape.com  Thu Apr 26 06:31:03 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27294
	for ; Thu, 26 Apr 2001 06:31:03 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3QASkn14985;
	Thu, 26 Apr 2001 03:28:46 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3QASko18964;
	Thu, 26 Apr 2001 03:28:46 -0700 (PDT)
Resent-Date: Thu, 26 Apr 2001 03:28:46 -0700 (PDT)
Sender: Robert.Byrne@Sun.COM
Message-ID: <3AE7F82E.8B6526B4@Sun.COM>
Date: Thu, 26 Apr 2001 12:27:58 +0200
From: robert byrne 
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Richard V Huber 
CC: ietf-ldapext@netscape.com
Subject: Re: browse permission in the ACM
References: <200104252045.QAA15453@qsun.mt.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"Tkb9FD.A.6nE.ch_56"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Richard V Huber wrote:
> 
> Do you mean this as a general statement or specifically for
> extensibleMatch?  If it is a general statement, is there really any
> remaining use for the "b" permission?
> 

I mean specifically for the extensible match when dnAttributes is set to
True ie. you have explicitly requested matching on the dn attributes.

I suspect you are right though that it would be hard in reality to
demonstrate the difference in requiring match permissions on the dn
attributes and just relying on the "t" permission and aliasing.  However
the following example shows the type of situation that makes me think it
might be better to require match permission testing on the dn
attributes:

	o=sun.com
	|
	ou=eng
	|
	cn=rob,ou=eng,o=sun.com  (aliased to cn=support,o=sun.com)

Then if a user with zero rights does a base search at
cn=rob,ou=eng,o=sun.com and specifies an extensible match with
dnAttributes set to true on say the ou attribute, then if that match
matches (say it was just a presence test) then from an access control
point of view the server is authorized to return the alaised dn.  So a
user with zero rights has guessed an entry and has had the server
confirm that that entry exists.  If we require match testing on the ou
attribute of the dn then as that right is absent the discloseOnError
stuff kicks in to hide the entry--he would get back "noSuchObject".

I guess you can summarize that by saying "for base objects of seaches
which are aliased we are relying on filter matching protection to
protect the entry".  Or to state it another way, "s" permission on an
attribute of an aliased entry (or on a naming attribute in the entry's
dn) is enough to enable you to confirm that entry's existence.

Rob.

> Rick Huber
> 
> : From: robert byrne 
> : To: Richard V Huber 
> : CC: ietf-ldapext@netscape.com
> : Subject: Re: browse permission in the ACM
> :
> : Rick,
> :
> : I agree that this needs clarification.  To be on the safe side my
> : suggestion would be to require a filter permisison check on the dn
> : attributes being matched.  For simplicity I would make it independent of
> : the scope.  So, for non-base entries we would test "b" _and_ the
> : required filter permissions, while for base entries we would just test
> : the filter permissions.
> :
> : Rob.
> :
> : Richard V Huber wrote:
> : >
> : > This email is carrying around a lot of history.  I've clipped off some
> : > of the earlier messages in the chain.
> : >
> : > My concern about extensibleMatch and option 3 was based on this
> : > paragraph from the draft (from Section 5.2, item 2):
> : >
> : >       The above statement covers the case where the
> : >       attributes are being evaluated as part of an
> : >       extensibleMatch (RFC 2251 section 4.5.1) which appears
> : >       in the filter.  In the case where the dnAttributes
> : >       field of the extensibleMatch is true then we do not
> : >       require any access checks to the attributes of the dn
> : >       candidateDN as access to these is taken to be granted
> : >       by the "b" permission, which has already been required
> : >       above.
> : >
> : > Since Option 3 implies that the "b" permission is NOT required for the
> : > base object to be searched, you might want to change 5.2 item 2 to
> : > say that "r" and "s" permissions ARE required for extensibleMatches on
> : > the DN of the base object.  But given that the "t" permission exists,
> : > this may not really matter in real-life situations.
> : >
> : > Rick Huber
> : >
> : > : From: robert byrne 
> : > : To: Richard V Huber 
> : > : CC: ietf-ldapext@netscape.com
> : > : Subject: Re: browse permission in the ACM
> : > :
> : > : Richard V Huber wrote:
> : > : >
> : > : > As I understand Option 3, it says that the "b" permission is not
> : > : > checked on the base object of a search.
> : > : >
> : > : > I'm trying to figure out what permissions would be checked for the base
> : > : > object under option 3.  For example, item 1 in section 5.2 would not
> : > : > seem to apply when the candidateDN is the base object.  How about the
> : > : > part of item 2 that discusses extensibleMatch?
> : > :
> : > : The idea is that "b" gives you the right to find an entry using the
> : > : subtree and onlevel options of search.  For a base entry, we do not
> : > : require "b" because you have named it.  We would still require the other
> : > : permissions (filter, returnDn, readOnAttribute) for a base entry.  Where
> : > : we refer to "b" in those sections we should say something like "as per
> : > : item 1."--ie. we never require "b" on base entries.
> : > :
> : > : >
> : > : > One of the reasons I had not responded to your previous email is that
> : > : > I'm still trying to figure out whether these questions really matter in
> : > : > practical directories.
> : > :
> : > : Good question--I agree the effect is a bit subtle and not obviously a
> : > : mandatory feature.  It's another level of granularity of control on
> : > : search.  I think you can see a similar effect in the Unix file system
> : > : where you can be in a directory and type "ls" and see nothing but if you
> : > : do, say, "cd public_html" you will find yourself in that directory, if
> : > : you have the appropriate rights.  In LDAP, you might want to have a
> : > : subtree with resources users can query if they know about them, but not
> : > : be able to discover resources "easily".
> : > :
> : > : At Pittsburg people seemed to like the browsing idea and I agreed to
> : > : propose something.
> : > :
> : > : Rob.
> : > :
> : > : >
> : > : > Rick Huber
> : > : >
> : > : > : Sender: Robert.Byrne@Sun.COM
> : > : > : From: robert byrne 
> : > : > : To: ietf-ldapext@netscape.com
> : > : > : Subject: Re: browse permission in the ACM
> : > : > :
> : > : > :
> : > : > : All,
> : > : > :
> : > : > : By way of a partial conclusion of this thread, for the next draft I
> : > : > : intend to propose 3. below.
> : > : > :
> : > : > : Rob.



From list@netscape.com  Thu Apr 26 08:11:48 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00079
	for ; Thu, 26 Apr 2001 08:11:48 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3QC87v22733;
	Thu, 26 Apr 2001 05:08:07 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3QC87U22107;
	Thu, 26 Apr 2001 05:08:07 -0700 (PDT)
Resent-Date: Thu, 26 Apr 2001 05:08:07 -0700 (PDT)
Sender: Robert.Byrne@Sun.COM
Message-ID: <3AE80F6C.CC9DF325@Sun.COM>
Date: Thu, 26 Apr 2001 14:07:08 +0200
From: robert byrne 
Organization: Sun Microsystems
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" 
CC: ietf-ldapext@netscape.com
Subject: Re: subjects in LDAP ACMs
References: <5.0.2.1.0.20010411183522.00aa51f0@127.0.0.1>
	 <5.0.2.1.0.20010412110700.00b10c60@127.0.0.1>
	 <5.1.0.14.0.20010423120707.00a93c60@127.0.0.1>
	 <5.1.0.14.0.20010424123427.00ab8680@127.0.0.1> <5.1.0.14.0.20010425071355.00ad5d00@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"gwJ-vD.A.nYF.f-A66"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

"Kurt D. Zeilenga" wrote:
> 
> At 06:00 AM 4/25/01, robert byrne wrote:
> >The only explicit reference to these "things" I can find in 2820
> >actually refers to them as the "Access context" and doesn't have
> >anything else to say about them:
> 
> As I noted previously, RFC 2820's use of the terminology is a bit
> inexact.  However, I believe the intent of the stated requirements is
> clear enough.  I won't hair split over them.
> 
> I just reiterate my basic position:
> 
> Support for multiple orthogonal subject factors is a rat hole
>   (consider precedence and "effective rights" issues).

If factors complicate or clash with other parts of the model then that
could be grounds for dropping them from the model.  I wouldn't
anticipate a problem for precedence--I think you could define away any
problems there.  The impact on getEffective rights is more serious--I'm
planning to have a look at getEffectiveRights...

Rob.

> 
> Support for a single subject factor which includes elements
>   not drawn from the "natural" LDAP name space has limited use
>   subject to significant security considerations.
> 
> The need for non-"natural" subject factors could be addressed
> via other means.
> 
> For these and other reasons, I believe it best for the LDAP ACM
> not support multiple orthogonal subject factors nor support
> a single subject factor which includes factors not drawn from
> the "natural" LDAP name space.
> 
> Lastly, I believe we need to keep the LDAP ACM simple.  Not
> just for security ask, but for sake of timely completion of this
> work.
> 
> Kurt



From list@netscape.com  Fri Apr 27 06:47:14 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21391
	for ; Fri, 27 Apr 2001 06:47:14 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3RAj3v27653;
	Fri, 27 Apr 2001 03:45:03 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3RAj4w08859;
	Fri, 27 Apr 2001 03:45:04 -0700 (PDT)
Resent-Date: Fri, 27 Apr 2001 03:45:04 -0700 (PDT)
Message-Id: <200104271044.GAA21134@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: ietf-ldapext@netscape.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-zeilenga-ldap-user-schema-00.txt
Date: Fri, 27 Apr 2001 06:44:58 -0400
Sender: nsyracus@cnri.reston.va.us
Resent-Message-ID: <"M0WZR.A.DKC.u2U66"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: LDAPv3: A Collection of User Schema
	Author(s)	: K. Zeilenga
	Filename	: draft-zeilenga-ldap-user-schema-00.txt
	Pages		: 17
	Date		: 26-Apr-01
	
This document provides a collection of user schema elements for use
with LDAP collected from numerous sources

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-user-schema-00.txt

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-zeilenga-ldap-user-schema-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-zeilenga-ldap-user-schema-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:	<20010426132522.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-zeilenga-ldap-user-schema-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-zeilenga-ldap-user-schema-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010426132522.I-D@ietf.org>

--OtherAccess--

--NextPart--




From list@netscape.com  Fri Apr 27 06:47:19 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21402
	for ; Fri, 27 Apr 2001 06:47:18 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3RAjAn22608;
	Fri, 27 Apr 2001 03:45:10 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3RAjAg08976;
	Fri, 27 Apr 2001 03:45:10 -0700 (PDT)
Resent-Date: Fri, 27 Apr 2001 03:45:10 -0700 (PDT)
Message-Id: <200104271045.GAA21150@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: ietf-ldapext@netscape.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-zeilenga-ldap-collective-00.txt
Date: Fri, 27 Apr 2001 06:45:02 -0400
Sender: nsyracus@cnri.reston.va.us
Resent-Message-ID: <"jYIbuB.A.NLC.y2U66"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: LDAPv3: Collective Attributes
	Author(s)	: K. Zeilenga
	Filename	: draft-zeilenga-ldap-collective-00.txt
	Pages		: 8
	Date		: 26-Apr-01
	
Collective attributes allow common characteristics to be shared
between collections of entries.  This document summarizes the X.500
information model for collective attributes and describes use of
collective attributes in LDAP.  This document provides LDAP schema
descriptions for X.500 collective attributes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-collective-00.txt

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-zeilenga-ldap-collective-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-zeilenga-ldap-collective-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:	<20010426132533.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-zeilenga-ldap-collective-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-zeilenga-ldap-collective-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010426132533.I-D@ietf.org>

--OtherAccess--

--NextPart--




From list@netscape.com  Fri Apr 27 06:47:28 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21417
	for ; Fri, 27 Apr 2001 06:47:27 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3RAjIv27799;
	Fri, 27 Apr 2001 03:45:18 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3RAjHU09192;
	Fri, 27 Apr 2001 03:45:17 -0700 (PDT)
Resent-Date: Fri, 27 Apr 2001 03:45:17 -0700 (PDT)
Message-Id: <200104271045.GAA21166@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: ietf-ldapext@netscape.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-zeilenga-ldap-x500-locate-00.txt
Date: Fri, 27 Apr 2001 06:45:08 -0400
Sender: nsyracus@cnri.reston.va.us
Resent-Message-ID: <"ar1GlD.A.VNC.42U66"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Location of LDAP services using Geo-Political Naming
	Author(s)	: K. Zeilenga
	Filename	: draft-zeilenga-ldap-x500-locate-00.txt
	Pages		: 6
	Date		: 26-Apr-01
	
This document describes an experimental mechanism for locating LDAP
services which use traditional geo-political naming.  The mechanism
uses DNS SRV records which supports the established ITU managed name
registration model

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-x500-locate-00.txt

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-zeilenga-ldap-x500-locate-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-zeilenga-ldap-x500-locate-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:	<20010426132548.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-zeilenga-ldap-x500-locate-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-zeilenga-ldap-x500-locate-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010426132548.I-D@ietf.org>

--OtherAccess--

--NextPart--




From list@netscape.com  Fri Apr 27 14:39:45 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10799
	for ; Fri, 27 Apr 2001 14:39:44 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3RIbPv10923;
	Fri, 27 Apr 2001 11:37:25 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3RIbQ213338;
	Fri, 27 Apr 2001 11:37:26 -0700 (PDT)
Resent-Date: Fri, 27 Apr 2001 11:37:26 -0700 (PDT)
Reply-To: 
From: "John Liang" 
To: 
Subject: JAVA SDK and error code handling for Server Side Sorting
Date: Fri, 27 Apr 2001 14:37:12 -0400
Message-ID: <000901c0cf49$1359d330$1005400a@software.com>
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 V5.00.2314.1300
Importance: Normal
Resent-Message-ID: <"EXPxIC.A.XPD.ixb66"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

HI there,

It sounds to me Netscape JAVA API expects LDAP_SUCCESS 
in SearchResultDone message when there is an error associated
with SSS control. 

I remember that we had a discussion about defining a new error 
code like ControlError for an error associated with controls 
and put detailed error code to the result control from the server.
Any new progress on this?

And what is the programming model for the client API at this
case? First check the result code for SearchResultDone; and
then check the result code in the result control if any?

Thanks,
--
John Liang





From list@netscape.com  Fri Apr 27 16:02:09 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14402
	for ; Fri, 27 Apr 2001 16:02:08 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3RJxsv29440;
	Fri, 27 Apr 2001 12:59:54 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3RJxtI01933;
	Fri, 27 Apr 2001 12:59:55 -0700 (PDT)
Resent-Date: Fri, 27 Apr 2001 12:59:55 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010427124011.00ae05b0@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 27 Apr 2001 12:58:11 -0700
To: 
From: "Kurt D. Zeilenga" 
Subject: Re: JAVA SDK and error code handling for Server Side Sorting
Cc: 
In-Reply-To: <000901c0cf49$1359d330$1005400a@software.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"4BRBSB.A.zd.6-c66"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 11:37 AM 4/27/01, John Liang wrote:
>It sounds to me Netscape JAVA API expects LDAP_SUCCESS 
>in SearchResultDone message when there is an error associated
>with SSS control. 

That appears to be the RFC 2891 described behavior (section 2,
item 4).

>I remember that we had a discussion about defining a new error 
>code like ControlError for an error associated with controls 
>and put detailed error code to the result control from the server.
>Any new progress on this?

There is an I-D available for review:
  draft-armijo-ldap-control-error-01.txt
        
I believe the current intent is to modify VLV to use this result
code.

I would like to see this result code used with SSS as well, but
that would require revising RFC 2891.

>And what is the programming model for the client API at this
>case? First check the result code for SearchResultDone; and
>then check the result code in the result control if any?

The client should first check the LDAP resultCode in the
response PDU.  If this resultCode is controlError, then the
client should behave as indicated in the request control(s)
specifications.  This may involve checking values in response
control(s).

Note that SSS does prescribe use of controlError and hence
the processing of SSS should not result in a controlError.

Kurt



From list@netscape.com  Fri Apr 27 16:26:39 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15062
	for ; Fri, 27 Apr 2001 16:26:38 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3RKOYn01075;
	Fri, 27 Apr 2001 13:24:34 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3RKOYQ15989;
	Fri, 27 Apr 2001 13:24:34 -0700 (PDT)
Resent-Date: Fri, 27 Apr 2001 13:24:34 -0700 (PDT)
Reply-To: 
From: "John Liang" 
To: "Kurt D. Zeilenga" 
Cc: 
Subject: RE: JAVA SDK and error code handling for Server Side Sorting
Date: Fri, 27 Apr 2001 16:24:20 -0400
Message-ID: <001001c0cf58$0a864fe0$1005400a@software.com>
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 V5.00.2314.1300
Importance: Normal
In-Reply-To: <5.1.0.14.0.20010427124011.00ae05b0@127.0.0.1>
Resent-Message-ID: <"_kGKFC.A.04D.-Vd66"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Friday, April 27, 2001 3:58 PM
> To: John.Liang@openwave.com
> Cc: ietf-ldapext@netscape.com
> Subject: Re: JAVA SDK and error code handling for Server Side Sorting
> 
> 
> At 11:37 AM 4/27/01, John Liang wrote:
> >It sounds to me Netscape JAVA API expects LDAP_SUCCESS 
> >in SearchResultDone message when there is an error associated
> >with SSS control. 
> 
> That appears to be the RFC 2891 described behavior (section 2,
> item 4).
> 

RFC 2891 makes use of the control's criticality field to decide to
send unsorted result or not. I remember that it only makes sense
if the LDAP server does not support this control. So was it changed
somehow? 

I thought the I-D draft for control error is going to be applied for
all controls besides VLV. 

Thanks,
--
John Liang




From list@netscape.com  Fri Apr 27 16:40:20 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15306
	for ; Fri, 27 Apr 2001 16:40:20 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3RKcGv07925;
	Fri, 27 Apr 2001 13:38:16 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3RKcHI23417;
	Fri, 27 Apr 2001 13:38:17 -0700 (PDT)
Resent-Date: Fri, 27 Apr 2001 13:38:17 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010427132753.00acfe70@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 27 Apr 2001 13:36:34 -0700
To: 
From: "Kurt D. Zeilenga" 
Subject: RE: JAVA SDK and error code handling for Server Side Sorting
Cc: 
In-Reply-To: <001001c0cf58$0a864fe0$1005400a@software.com>
References: <5.1.0.14.0.20010427124011.00ae05b0@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"70aIDC.A.UtF.4id66"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 01:24 PM 4/27/01, John Liang wrote:
>RFC 2891 makes use of the control's criticality field to decide to
>send unsorted result or not. I remember that it only makes sense
>if the LDAP server does not support this control. So was it changed
>somehow? 

Well, one could argue that RFC 2891 inappropriate overloads the
criticality field of the control by use it to imply different
semantics upon recognized and supported controls.  That's an
issue which likely should be addressed during the eventual
revision of RFC 2891.

>I thought the I-D draft for control error is going to be applied for
>all controls besides VLV. 

It can be applied by the specification of any control for use
with that control.

Kurt



From list@netscape.com  Sat Apr 28 03:26:52 2001
Received: from netscape.com ([205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11421
	for ; Sat, 28 Apr 2001 03:26:51 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3S7Ohn07830;
	Sat, 28 Apr 2001 00:24:43 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3S7OhE27038;
	Sat, 28 Apr 2001 00:24:43 -0700 (PDT)
Resent-Date: Sat, 28 Apr 2001 00:24:43 -0700 (PDT)
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 6.0
Date: Sat, 28 Apr 2001 01:24:32 -0600
From: "Jim Sermersheim" 
To: 
Subject: PSearch / LCUP moving base
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id f3S7Oev27006
Resent-Message-ID: <"o-U2X.A.EmG.5An66"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

If the search base of a persistent search (or LCUP search) is moved or deleted, what is the expected behavior? I assume the event is sent to the client, then the operation fails with a noSuchObject, as there is no longer a search base.

Jim



From list@netscape.com  Sat Apr 28 11:24:04 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14495
	for ; Sat, 28 Apr 2001 11:24:04 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3SFLmv02320;
	Sat, 28 Apr 2001 08:21:49 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3SFLnQ13094;
	Sat, 28 Apr 2001 08:21:49 -0700 (PDT)
Resent-Date: Sat, 28 Apr 2001 08:21:49 -0700 (PDT)
From: ghjzl@msn.com
To: laqdy@OnlinePartners.netscape.com
Reply-To: t3m1@bigfoot.com
Subject: The Most Unsusual Business Opportunity Pitch You Will Ever See!                                    [jcqvm]
Date: Sat, 28 Apr 2001 12:21:40 -0300
Message-ID: <77457D7F851.AAA5B8B0@nsmail1.intranet.bancorio.com.ar>
Resent-Message-ID: <"TMWnfD.A.MMD.LAu66"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Hello,

Let me ask you a simple question. How much money would
you make if you recieved just a tiny piece of the 5
largest spending trends of our lifetime?
What I'm talking about is...

* The 40 Billion Dollar a year Gaming Industry.

* Combined with the 50 Billion Dollar a year Weight-Loss
Industry

* Which is part of the 450 Billion Dollar a year
Home-Based Business Industry

* Now add the Trillion Dollar a year Health Industry and...

* Combine all of that with the largest industry of
them all....the Internet, which experts predict will
be at a 7 Trillion Dollar a year industry by 2004.

Wrap it all up into a turnkey system that delivers
the message, closes the sales, and builds your business
for you with NO selling...with an automated internet
information center that turns you into an instant expert
with NO experience required on your part.

What you have is 'your' best chance to become financially
secure in your lifetime.Making money on the internet
is not really that hard. Many of us do it all the time.

Now...for the REALLY IMPORTANT PART!

This program and these products really make a difference
in peoples' lives. Serious illnesses are being reversed.
Some are calling them 'miracles'.

Does this interest you? Let me know if you would like
to know more about this remarkable opportunity. Just reply
with "Send Miracle Info Please" as the subject.

mailto:tim33me2@n2mail.com?subject=Send_Miracle_Info_Please

Best Regards,
Charles

Please Note... Should this email address be down.
Please "Fax" your response instead, with your email
address___, and the words "Send Miracle Info Please"
to: 305-425-3217.



From list@netscape.com  Sat Apr 28 15:30:07 2001
Received: from netscape.com ([205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16350
	for ; Sat, 28 Apr 2001 15:30:06 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3SJS0v12826;
	Sat, 28 Apr 2001 12:28:00 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3SJS1s01633;
	Sat, 28 Apr 2001 12:28:01 -0700 (PDT)
Resent-Date: Sat, 28 Apr 2001 12:28:01 -0700 (PDT)
Message-Id: <200104281927.f3SJRmW20065@ywing.netscape.com>
From: "Maria Stevens" 
To: 
Subject: Five (5) Product Give Away - No Conditions!
Date: Sat, 28 Apr 2001 12:23:51 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by aka.mcom.com id f3SJRwv01601
Resent-Message-ID: <"MmBkoC.A.HZ._mx66"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 8bit

OBLIX, INC
You are subscribed as: ietf-ldapext@netscape.com

Good Afternoon! 
We are running a FREE software promotion for five (5) powerful products for our subscribers: eXpressForms ($129.99 value),  DataScan business card scanner ($149.99), Fortune contact builder and relationship manager ($149.99 value), TransForm Suite "forms scanning and designer" ($59.99), VersaClips "hand crafted cliart for checks, greeting cards and brochures.

a) "eXpressForms2000" is an ideal solution for tax preparation, business forms creation, greeting cards and invitations. Best of all, you can instantly post any of your forms and documents on the internet for everybody to view and fill out. The information entered is captured into your database or Excel. 

b) "DataScan" allows you to scan in business cards. directories and printed contact lists directly into your database without typing.

c) "Fortune" helps automate your contact information, keep track of events, send mass email, faxes, letters and build a powerful database of friends, customers and useful company information.   

d) "TransForm Suite" lets you scan pre-printed paper forms into you PC to create electronic forms with ease. Includes OCR and raster-to-vector converter.

e) "VersaClips" - images and hand crafted clipart for checks, greeting cards, web sites, documents and brochures.

Offer expires May 15. 


**********************
Click on the link below and add your FREE products to the shopping cart in the check out area.
http://www.g7ps.com

About eXpressFroms:
http://www.g7ps.com/scripts/expforms.asp

About DataScan:
http://www.g7ps.com/scripts/datascan.asp

About Fortune:
http://www.g7ps.com/scripts/fortune.asp

About TransForm Suite:
http://www.g7ps.com/scripts/trans.asp

About VersaClips:
http://www.g7ps.com/scripts/clips.asp



Not valid with any other offer. Up to 5 per customer and product.
 
********************* 

Please do not hesitate to call 800-303-2620 for any questions you may have. 

Thank you very much. 
Yours truly, 

Maria Stevens 
Customer Relations Manager 
G7 Productivity Systems, Inc. 
mariaste@g7ps.com 
800-303-2620 

To change your communication preference please click on: http://www.globalzon2k.com/scripts/mf_de.asp?e=ietf-ldapext@netscape.com
or simply reply to this Email with UNSUBSCRIBE in the subject line.



From list@netscape.com  Sun Apr 29 11:46:45 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10067
	for ; Sun, 29 Apr 2001 11:46:44 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3TFidn21259;
	Sun, 29 Apr 2001 08:44:39 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3TFicw09093;
	Sun, 29 Apr 2001 08:44:38 -0700 (PDT)
Resent-Date: Sun, 29 Apr 2001 08:44:38 -0700 (PDT)
Message-ID: <3AEC12E5.E13DE390@salford.ac.uk>
Date: Sun, 29 Apr 2001 14:11:01 +0100
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: roland@catalogix.se
CC: ietf-ldapext@netscape.com
Subject: Re: Last call on 'Named Subordinate References in LDAP Directories'
References: <0104231956560D.00916@t20>
Content-Type: multipart/mixed;
 boundary="------------A8A3C490686E94E8A5B83ECA"
Resent-Message-ID: <"N79JJC.A.iNC.kbD76"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a multi-part message in MIME format.
--------------A8A3C490686E94E8A5B83ECA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Kurt

I have spotted a small typo in the ID. In the example in section 6 it
says:

server A may contain a referral object
named "OU=sub,DC=example,DC=net" which contains a ref attribute with
value of "ldap://B/DC=sub,DC=example,DC=net".

      dn: DC=sub,DC=example,DC=net


Either the dn should be OU=sub,DC=example,DC=net, or the object should
be DC=sub,DC=example,DC=net

David

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

David Chadwick, BSc PhD
Post: IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 161 745 8169
*NEW* Mobile: +44 77 96 44 7184 *NEW*
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

*****************************************************************
--------------A8A3C490686E94E8A5B83ECA
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
adr:;;;;;;
version:2.1
email;internet:d.w.chadwick@salford.ac.uk
x-mozilla-cpt:;11160
fn:David Chadwick
end:vcard

--------------A8A3C490686E94E8A5B83ECA--




From list@netscape.com  Sun Apr 29 14:05:56 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10779
	for ; Sun, 29 Apr 2001 14:05:55 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3TI3on27469;
	Sun, 29 Apr 2001 11:03:50 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3TI3ow02572;
	Sun, 29 Apr 2001 11:03:50 -0700 (PDT)
Resent-Date: Sun, 29 Apr 2001 11:03:50 -0700 (PDT)
Message-Id: <5.1.0.14.0.20010429110147.00a9a410@127.0.0.1>
X-Sender: guru@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 29 Apr 2001 11:02:04 -0700
To: David Chadwick 
From: "Kurt D. Zeilenga" 
Subject: Re: Last call on 'Named Subordinate References in LDAP
  Directories'
Cc: roland@catalogix.se, ietf-ldapext@netscape.com
In-Reply-To: <3AEC12E5.E13DE390@salford.ac.uk>
References: <0104231956560D.00916@t20>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Resent-Message-ID: <"BGDyvB.A.Mn.EeF76"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

At 06:11 AM 4/29/01, David Chadwick wrote:
>I have spotted a small typo in the ID.

Noted, thanks.



From list@netscape.com  Sun Apr 29 20:52:37 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13121
	for ; Sun, 29 Apr 2001 20:52:36 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3U0oSn16163;
	Sun, 29 Apr 2001 17:50:28 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3U0oSw18398;
	Sun, 29 Apr 2001 17:50:28 -0700 (PDT)
Resent-Date: Sun, 29 Apr 2001 17:50:28 -0700 (PDT)
Date: Sun, 29 Apr 2001 19:55:44 +0000 (Eastern)
From: sweet_tooth@afsta.karlsruhe.de
Subject: Cure that sweet tooth
Reply-to: sweet_tooth@aadeebd.ca.netscape.com
Message-id: <0GCK00BKWXTWM7@jhb-imta.mweb.co.za>
MIME-version: 1.0
Content-type: multipart/mixed;
 boundary="----=_NextPart_000_018C_01BD9940.715D52A0"
Importance: High
X-MSMailPriority: High
X-Priority: 1
Resent-Message-ID: <"6o74lB.A.9eE.SbL76"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is a multi-part message in MIME format.

------=_NextPart_000_018C_01BD9940.715D52A0
Content-Type: text/html;




Bcc:
Return-Path: sweet_tooth@afsta.karlsruhe.de
Message-ID: <00b6e2232001e41INTERVISION@intavision.com>
Date: 30 Apr 2001 02:32:27 +0200





CHESTNUT COOKIE RECIPE

CHESTNUT COOKIE RECIPE






  
INTERESTED
    IN A FABULOUS CHESTNUT COOKIE RECIPE? 
    

    

    SEND $5.00 WITH SELF-ADDRESSED STAMPED ENVELOPE OR YOUR E-MAIL 

    ADDRESS (TO WHICH YOU WOULD LIKE THE RECIPE SENT) TO:                   
    

                  
    

    R.
  Colbert

  1604
  Davie Blvd.

  Suite # 1503

  Fort Lauderdale, FL  33312
 

    
    

    
    FOR A 3-GENERATION-OLD AUTHENTIC CHESTNUT COOKIE RECIPE.  ADDITIONAL
    

    GASTRONOMICAL RECIPES AVAILABLE UPON REQUEST. 

    

    THERE
    IS NO NEED TO RESPOND TO THIS E-MAIL IF YOU DO NOT WISH TO RECEIVE 

    FURTHER CORRESPONDENCE. THIS IS A ONE-TIME EMAIL TRANSMISSION.
     





  
INTERESTED
    IN A FABULOUS CHESTNUT COOKIE RECIPE? 
    






































CHESTNUT COOKIE RECIPE








------=_NextPart_000_018C_01BD9940.715D52A0--


From list@netscape.com  Mon Apr 30 03:52:21 2001
Received: from netscape.com (r2d2.netscape.com [205.217.237.47])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02471
	for ; Mon, 30 Apr 2001 03:52:20 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3U7oEn13322;
	Mon, 30 Apr 2001 00:50:14 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3U7oEw07221;
	Mon, 30 Apr 2001 00:50:14 -0700 (PDT)
Resent-Date: Mon, 30 Apr 2001 00:50:14 -0700 (PDT)
From: Professional.Traders@xwing.aoltw.net
Date: Mon, 30 Apr 2001 03:45:45
To: ietf-ldapext@netscape.com
Subject: FREE Trading Software and System
MIME-Version: 1.0
Content-Type: multipart/related;
  boundary="----=_NextPart_GSWFJDDRCV"
Message-ID: PM20003:45:45 AM
Resent-Message-ID: <"Ym6vrB.A.bwB.0kR76"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

This is an HTML email message.  If you see this, your mail client does not support HTML messages.

------=_NextPart_GSWFJDDRCV
Content-Type: text/html;charset="iso-8859-1"
X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id f3U7oEn13322
Content-Transfer-Encoding: quoted-printable










  

    

      
    

    

      
        

          

          

          

            

              Do=
n't just look at=20
                  charts of yesterday. PatternsOnline=99 gives you charts that plot=20
                  future prices using a proprietary version of our award =
winning=20
                  Patterns=99 software.=20
                
                  

                    
How can this he=
lp your next=20
                    trade?=20
                    
1. Yo=
u'll see=20
                    future price projections with outstanding=20
                    accuracy.  

                  
2.=20
                  =
You'll get=20
                  the best stop price that has historically held for the =
highest=20
                  percentage on each signal. These stops vary to meet the=
 best=20
                  probable price that has achieved maximum success.
                  
3.=20
                  You'll =
get the=20
                  greatest Draw Down (worst negative) for each signal bef=
ore you=20
                  trade. Draw Downs are generated from the performance of=
 all=20
                  successful buy/sell signals.=20
                  

                    
He=
re's how it=20
                    works...=20
                    
The p=
rojections=20
                    are supported by the very best patterns found with ou=
r=20
                    proprietary pattern automation software. The software=
 runs=20
                    on a network of computers 24 hours a day. This system=
 allows=20
                    us to maintain the highest probable projections on to=
day's=20
                    pattern using the most current marke=
t=20
                    conditions. 

                  
The S=
&P e-Mini is=20
                  the first market to start this unmatched service.=20
                

                

                  
  
                    

                  

                    

                      

                        
                

                  
CLIC=
K
                    HERE
                    and
                    simply send us your e-mail address and
                    we will send you a link to download our SystemTrader=99=
 
                    stock and commodity trading software absolutely FREE.=
 Forbes
                    magazine calls it "...the ultimate program"=
.

                  
 

                  
We
                    will also send you a username and password form to tr=
y
                    PatternsOnline Risk Free for 30-days.

                

                          
Good
                          trading!

                      

                    

                  

                  
 

                

              		
            

          

          

        

      		
    

    

      
        

          
<=
font size=3D"2" face=3D"Arial">This
            email is being sent in full compliance with U.S. Senate Bill =
1618,
            Title #3,
            
            

        

        

          
 Section
            301. To be removed from future mailings, CLICK
            HERE
            and enter
            
            

        

        

          
 "REMOVE".
            We apologize for any inconvenience

        

      		
    

  








------=_NextPart_GSWFJDDRCV--



From list@netscape.com  Mon Apr 30 13:16:01 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19461
	for ; Mon, 30 Apr 2001 13:16:00 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3UHDpv22919;
	Mon, 30 Apr 2001 10:13:51 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3UHDpI15041;
	Mon, 30 Apr 2001 10:13:51 -0700 (PDT)
Resent-Date: Mon, 30 Apr 2001 10:13:51 -0700 (PDT)
Message-Id: <200104301713.f3UHDl216853@xwing.aoltw.net>
Reply-To: "Opportunity"
From: "Opportunity"
To: "" 
X-Priority: 3
X-MSMail-Priority: Normal
Subject: Your commission check.
Sender: "Opportunity"
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Wed, 18 Oct 2000 13:47:29 -0400
Resent-Message-ID: <"RPoi5D.A.nqD.N1Z76"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com



It is Amazing ... and FREE!
During the last March we sponsored 198,847 new distributors in 131
countries worldwide. Today, we have over 1,400,000 affiliates in
193 countries.(And
we have only scratched the surface! - According The New York Times 
there are
332 millions people conected worldwide.)
EVEN MORE AMAZING:
These unprecedented numbers came without mailing a single brochure, 
audio, or
videotape. Not a single long-distance phone call was made...or fax sent. 
We
did it 100% via the Internet . Network Marketing on the Web has arrived! 
Want
to know more? You can earn YOUR COMMISSION CHECK and  test 
drive the system FREE!
Just click on this link then watch the magic. 


http://income.hk.st



**************************************************************************************
**************************************************************
This message is sent in compliance of the proposed bill: SECTION 301. 
Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to 
you by the sender of this email may be stopped at no cost to you by 
sending a Reply to this email address with the word Remove in the 
subject line. 
**************************************************************************************
**************************************************************




From list@netscape.com  Mon Apr 30 15:18:23 2001
Received: from netscape.com (c3po.netscape.com [205.217.237.46])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23028
	for ; Mon, 30 Apr 2001 15:18:22 -0400 (EDT)
Received: from aka.mcom.com (aka.mcom.com [205.217.237.180])
	by netscape.com (8.10.0/8.10.0) with ESMTP id f3UJGFv20267;
	Mon, 30 Apr 2001 12:16:16 -0700 (PDT)
Received: (from list@localhost)
	by aka.mcom.com (8.10.0/8.10.0) id f3UJ9L214677;
	Mon, 30 Apr 2001 12:09:21 -0700 (PDT)
Resent-Date: Mon, 30 Apr 2001 12:09:21 -0700 (PDT)
Message-ID: <3AEDB815.93E0FBE@netscape.com>
Date: Mon, 30 Apr 2001 15:08:05 -0400
From: mcs@netscape.com (Mark C Smith)
Organization: iPlanet E-Commerce Solutions
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jim Sermersheim 
CC: ietf-ldapext@netscape.com
Subject: Re: PSearch / LCUP moving base
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"DpENED.A.ceD.Ohb76"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List:  
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com
Content-Transfer-Encoding: 7bit

Jim Sermersheim wrote:
> 
> If the search base of a persistent search (or LCUP search) is moved or deleted,
> what is the expected behavior? I assume the event is sent to the client, then
> the operation fails with a noSuchObject, as there is no longer a search base.

As far as I know the behavior in this situation is undefined (which is
to say it is implementation dependent).  We should address this in the
LCUP specification.  Note that we also need to consider what happens if
an ancestor of the LCUP search base is renamed (I believe you or someone
else raised that issue earlier).

-- 
Mark Smith
Netscape