From madmin@tandem.com Thu Nov 11 14:56:45 1993 Received: by suntan.Tandem.com (4.1/suntan5.930818) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA06441; Thu, 11 Nov 93 14:56:47 PST Received: from blinky.ccmail.com by suntan.Tandem.com (4.1/suntan5.930818) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA06437; Thu, 11 Nov 93 14:56:45 PST Received: from smtpgate.ccmail.com by blinky.ccmail.com (4.1/SMI-4.1) id AA22759; Thu, 11 Nov 93 14:57:54 PST Received: from ccMail by smtpgate.ccmail.com id AA753058591 Thu, 11 Nov 93 14:56:31 pst Date: Thu, 11 Nov 93 14:56:31 pst From: russf@ccmail.com Message-Id: <9310117530.AA753058591@smtpgate.ccmail.com> To: xapia-dirsynch@tandem.com Subject: XAPIA DirSynch Technical Committee Meeting, Mountain View. -------------------------------------------------------------------------- I N V I T A T I O N TO A MEETING OF THE XAPIA DIRECTORY SYNCH TECHNICAL COMMITTEE -------------------------------------------------------------------------- Venue : Lotus/cc:Mail building, 800 El Camino Real West, Mountain View, CA 94040. (At junction with Castro street in downtown MV) Date : 18th & 19th November 1993 Starting at 8:30. Sign in and ask for directions in the lobby. Agenda : Review minutes of previous meeting Discussion of requirements and review of source documents. Define a schedule for deliverables. Sketch out the structure of the draft standard. Define a list of primitives and services required. Also... Tutorial on aspects of Dir Synch. (In planning- Kirpal) Contact : Russ Ferriday, Lotus/cc:Mail russf@ccmail.com 415 335 6524 Kirpal Khalsa, Tandem khalsa_kirpal@tandem.com 408 285 4070 Map : El Camino Real San Francisco International | 101 North | | | \ | \ | | | | | Shoreline Blvd | +---------+-----------------------------------------+ | | | | | | | | | |+======+ | Church St | ||Lotus |-+ | |+======+ | | +---------+-----------------------------------------+ | Castro St | | D o w n t o w n M o u n t a i n V i e w | | | | \ | \ | | | | 101 South | San Jose International Please : RSVP by Tuesday 16 November to russf@ccmail.com. (Comments on the agenda should be sent to the mailing list.) Many thanks. I'm looking forward to meeting everyone on Thursday. Russ Ferriday. From madmin@tandem.com Mon Nov 22 16:21:12 1993 Received: by suntan.Tandem.com (4.1/suntan5.930818) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA18308; Mon, 22 Nov 93 16:21:15 PST Received: from comm.Tandem.COM by suntan.Tandem.com (4.1/suntan5.930818) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA18301; Mon, 22 Nov 93 16:21:12 PST Received: by comm.Tandem.COM (4.7/4.5) id AA19257; 22 Nov 93 16:21:08 +1600 Date: 22 Nov 93 16:11:00 +1600 From: KHALSA_KIRPAL@tandem.com Message-Id: <199311221621.AA19257@comm.Tandem.COM> To: xapia-dirsynch@suntan.tandem.com Subject: XAPIA DirSynch mailing list update Hi All, Please reply to let me know you've received this. Regards, Kirpal From madmin@tandem.com Wed Nov 24 09:55:15 1993 Received: by suntan.Tandem.com (4.1/suntan5.930818) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA14424; Wed, 24 Nov 93 09:55:17 PST Received: from blinky.ccmail.com (ccmail.COM) by suntan.Tandem.com (4.1/suntan5.930818) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA14420; Wed, 24 Nov 93 09:55:15 PST Received: from smtpgate.ccmail.com by blinky.ccmail.com (4.1/SMI-4.1) id AA04627; Wed, 24 Nov 93 09:55:08 PST Received: from ccMail by smtpgate.ccmail.com id AA754163579 Wed, 24 Nov 93 09:52:59 pst Date: Wed, 24 Nov 93 09:52:59 pst From: russf@ccmail.com Message-Id: <9310247541.AA754163579@smtpgate.ccmail.com> To: park-street!campbell@redsox.bsw.com (Larry Campbell) Cc: Khalsa_Kirpal@tandem.com, xapia-dirsynch@tandem.com, Jane_Chang_OSWare__FAX#1_604_436_3192_at_FAXOUT@smtpgate.ccmail.com Subject: Re[2]: XAPIA DirSynch Technical Committee Meeting, Mountain Hi Larry, We'd have been glad to see you here. Sorry you didn't make it. Greg Loux of SoftSwitch took minutes of the more important items, and is taking over the position of secretary for some period. Look forward to mail from Greg. The meeting was encouraging, and the main realization was that our canonical form for representing directory related info within 'synchspace' should be X.500 compatible - even in the absence of an X.500 implementation at the site. Kirpal is anxious to hand over chairmanship, feeling that he has been unable to devote enough time to the position. Two candidates were identified for this critical role, but other issues need to be clarified before we can proceed with a decision. Some of the discussion will take place online, and Ken Rossen will be making space available for anon ftp at nist. This will serve as a repository for docs. The xapia-dirsynch mailing list is in operation now (except for adressees with X.400 addressing only). Please ensure that you are receiving mail from the list. Best regards, - Russ Ferriday Lotus cc:Mail russf@ccmail.com ______________________________ Reply Separator _________________________________ Subject: Re: XAPIA DirSynch Technical Committee Meeting, Mountain Vie Author: park-street!campbell@redsox.bsw.com (Larry Campbell) at internet-mail Date: 11/24/93 10:53 AM I either received your mail late, or missed it. In reviewing my mailbox today I just came across it. I would like to have participated in that meeting. Did anyone take minutes? Will they be distributed? Can some of this discussion take place online (I hate travelling)... Thanks! - Larry Campbell The Boston Software Works, Inc. campbell@redsox.bsw.com From madmin@tandem.com Wed Dec 22 08:19:20 1993 Received: by suntan.Tandem.com (4.1/suntan5.931220) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA17240; Wed, 22 Dec 93 08:19:26 PST Received: from hitachi.com by suntan.Tandem.com (4.1/suntan5.931220) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA17236; Wed, 22 Dec 93 08:19:20 PST Received: from spd.hitachi.com (hicom.hitachi.com) by hitachi.com (4.1/SMI-4.1) id AA15906; Wed, 22 Dec 93 08:25:07 PST Received: from old_peculiar.spd.hitachi.com by spd.hitachi.com (4.1/SMI-4.1) id AA00735; Wed, 22 Dec 93 08:20:52 PST Date: Wed, 22 Dec 93 08:20:52 PST From: cropper@spd.hitachi.com (Steve Cropper) Message-Id: <9312221620.AA00735@spd.hitachi.com> To: xapia-dirsynch@tandem.com Subject: Re: OIW Dec 93 Minutes Hi Everyone, Who attend the OIW earlier this month? Was there a date for the next meeting set? (Is it the same as we discussed during the cc:Mail meeting - i.e. At Hitachi on or around Jan. 20th)? Was a Chair identified or is this still a floating issues? Is there anymore data in the way of Minutes from this meeting? Did we ever publish minutes from the Mountainview meeting in November? I just want to try and stay on top of things dispite my inability to attend OIW this month. Any information would be greatfully received. Thanks Steve Cropper Manager, Technical Services Hitachi Computer Products (America) Inc. ________________________________________________________________________________ > From pl0135@mail.psi.net Tue Dec 21 07:37:01 1993 > Sub-Organization: Computer Systems Laboratory (CSL) > Disclaimer: Opinions expressed are those of the sender > and do not reflect NIST policy or agreement. > Date: Tue, 21 Dec 1993 09:51:42 -0500 > From: "John M. Hunt" > Subject: OIW Dec 93 Minutes > To: NIST DS SIG > Organization: Sita > X-Mailer: PSILink (2.0a) > Content-Transfer-Encoding: 7BIT > Content-Length: 2688 > > Minutes for OIW DS-SIG Dec. 1993 > > The DSSIG spent its time in two break out groups, directory synchronization > and management of directory. There were no community reports. > > Directory Synchronization > ----------------------- > This breakout group included several people from the XAPIA group working > on directory synchronization. There is an open mailing list on this topic run > by XAPIA, to join the list send a request to "khalsa_kirpal@tandem.com". > The group was able to reach a number of major conclusions: The solution to > the problem is to define a standard file format, not an API, not a new > protocol. The format chosen must be extensible from the outset, this means > a mechanism to introduce new tags for new data items. There are a number > of problems in making such tags work across many organizations. For > example, the tags must guarantee uniqueness. Rather then try to set up the > necessary mechanisms to manage this, the group hoped to adapt an existing > mechanism. It appears that OSI Object Identifiers (OIDs) are well suited for > the role. Having gotten this far the group realized that their requirements > were converging on those of the NADF. It was concluded that the group > should take a fresh look at the NADF CAN format. The work will be > continued at the next XAPIA. > > Management of Directory > ---------------------- > This breakout group included Dr. Adrian Taung from the University of > Missouri and a number of his students. The group discussed a requirements > paper (DSSIG-93-12-08) By Ella Gardner of Mitre and several architecture > papers (DSSIG-93-12-12 through DSSIG-93-12-14) from UMKC. On the > requirements paper the main changes that the group made was to remove any > aspect that did not need to be standardized. On the architecture papers the > group felt that management of the DUAs was out of scope and should be > removed. It is currently planned to submit revised versions of the papers to > ISO/IEC JTC1/SC21/WG4. > > Convergence > ------------ > The Convergence Task Group requested information from the DSSIG on use > of X.500 in the Internet. This was compiled by Ken Rossen and sent as an > informal liaison. > > Plenary Motions > --------------- > To send a liaison to ISO/IEC JTC1/SC21/WG4 with contributions on > directory management > Y:8 N:0 A:0 > To send a liaison to EWOS EGDIR and AOW DIRSIG withdrawing from our > commitment to produce ADI41 > Y:8 N:0 A:0 > To send a liaison to SC21/WG4 volunteering to contribute on 1993 directory > PICS Performa > Y:8 N:0 A:0 > > Action Items > ------------ > Ella Gardner to get changes management papers from UMKC > Ken Rossen to talk to Simon Batley, the conformance rappatour, about > existing abstract test suites > > > From madmin@tandem.com Mon Dec 27 22:07:02 1993 Received: by suntan.Tandem.com (4.1/suntan5.931220) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA28534; Mon, 27 Dec 93 22:07:05 PST Received: from comm.Tandem.COM by suntan.Tandem.com (4.1/suntan5.931220) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA28530; Mon, 27 Dec 93 22:07:02 PST Received: by comm.Tandem.COM (4.7/4.5) id AA22329; 27 Dec 93 22:07:09 +1600 Date: 27 Dec 93 22:03:00 +1600 From: KHALSA_KIRPAL@tandem.com Message-Id: <199312272207.AA22329@comm.Tandem.COM> To: xapia-dirsynch@suntan.tandem.com Subject: 12/27/93 XAPIA DirSynch mailing list update Hi all, Merry Christmas! Happy New Year! I survived India including an interesting 22 hours on the Grand Trunk Road. An experience not to be missed. Especially if you're into bumper cars or roller coasters or horror movies (the kind with the close up of the freight train bearing down on you). Unfortunately I neglected to forward my mail to my Bombay address while I was gone so couldn't read mail till my return. I've updated the list based on mail received. I've attached the current list. If you know I've left anyone off who should be on, please send me mail. Also, some of you may notice multiple entries. I added multiple entries if you're new and the address you sent in the body of your request was different than the address in the FROM part of your message header (just in case). If you receive two messages let me know. Also, if you have alternate addresses you'd prefer, send mail. Alexis or Greg or Ken, Wasn't someone going to send me a mass list of OIW names to add?? Send replies to let me know you've received this. current list: list as of 12/27/93 ed_owens@ccmail.com Eugene@beyond.com Wardb@linkage.com alex-rassey@retix.com beckhardt@iris.com campbell@redsox.bsw.com crotty@ralvm6.vnet.ibm.com gtl@softsw.ssw.com kenr@shl.com khalsa_kirpal@tandem.com mstieglitz@worldtalk.com nhs@ssw.com niraj@cup.hp.com russf@ccmail.com ryatco@vnet.ibm.com pchang@vnet.ibm.com pchang@cup.hp.com s_cropper@hitachi.com c_nguyen@hitachi.com alexisb@atc.boeing.com chang@vancouver.osiware.bc.ca yeaw@cup.hp.com mszeleny@ccmail.com chrisl@retix.com old@sunbim.be c.robbins@nexor.co.uk John.Dale@mail.Citicorp.com John.Dale@charon.citicorp.com molson@tuxedo.enet.dec.com molson@am_tuxedo.lkgmts.lkg.mts.dec.com erik@wimsey.com adrier@mason1.gmu.edu eric@isci.com nakumar@oracle.com NAKUMAR@us.oracle.com Chuck.Bann@omail.wang.com Regards, Kirpal From madmin@tandem.com Wed Feb 9 11:41:48 1994 Received: by suntan.Tandem.com (4.1/suntan5.940113) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA11969; Wed, 9 Feb 94 11:41:51 PST Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940113) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA11965; Wed, 9 Feb 94 11:41:48 PST Received: by atc.boeing.com (5.57) id AA15322; Wed, 9 Feb 94 11:42:48 -0800 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2D593CD8@ct.si.cs.boeing.com>; Wed, 09 Feb 94 11:43:20 PST From: "Bor, Alexis" To: dssig , XAPIA Dir Synch Subject: Minutes from January DIR-SYNCH Meeting Date: Wed, 09 Feb 94 10:23:00 PST Message-Id: <2D593CD8@ct.si.cs.boeing.com> Encoding: 447 TEXT X-Mailer: Microsoft Mail V3.0 I am attaching an ASCII text version of the minutes from the January DIR-SYNCH meeting. I expect to have postscript, RTF, and Word versions at nemo.ncsl.nist.gov soon and will send another message out at that time. Alexis Bor bora@ct.si.cs.boeing.com Page XAPIA Directory Synchronization SIG Meeting Minutes January 20th 1994 - January 21st 1994 DISTRIBUTION: Chair: Alexis Bor (BOEING) Minute Taker: Steve Cropper (HITACHI) Attendees: Christopher Nguyen (HITACHI) Fred Stein (HITACHI) Peter Chang (HP) Yea-Cheng Wang (HP) Eva Kuiper (OSIWare - InfoNet CSCL) Kirpal Khalsa (Tandem) Others: XAPIA Steering Committee Members ______________________________________________________ Agenda: 1. Review and approve minutes 2. Action Item Review 3. New Business and Submissions 4. Continue work from previous meeting 5. Discuss EMA Directory Synch Status presentation / panel discussion for April 1994 conference (Alexis to do this) 6. Discuss status of CAN - possibility of bringing in an expert 7. Next meeting(s) 8. Review new action Items 9. Other items (if any) - Where to get OIDs - Attributes with similar values in different environments - Vendor attribute requirements - Microsoft/Apple Agreement - Identify Where and how Data is Mastered etc. - Name Translation - Where and how to publish our findings (XAPIA, NIST, RFC? ...) - Kirpal to bring in Mailing List for Friday session - File formats - Schedule - Report to Steering Committee 10. Close meeting Goal of Meetings is to get a rough outline together so that need for meetings is reduced and work can progress via Email. ______________________________________________________ Minutes review: Errata PAGE 1 Kirpal's address should read: khalsa_kirpal@tandem.com Fourth Paragraph in 1.0 beginning "Extensibility should ..." has an incomplete sentence beginning "OIDs have been" ? Agenda will include OID discussion so strike OIDs have been from the Previous minutes. PAGE 2 Item 2. Specifies a "new requirement". This is not a new requirement it has been covered in previous meetings. Bottom of Page 2 discusses different variants of "D". Steve C asked why the name wouldn't be separate Attributes for flexibility. (New Agenda Item added to deal with this) [Alexis: We need to have a set of recommendations in the final document defining the best way to handle Dir. Synch.] PAGE 3 Point 4. Alexis: We need to solicit from vendors what attributes they support so that we can at least specify mappings in final document. Enter new Agenda Item for the meeting to discuss this. Figure No. 2 discussed and it was agreed that it is no longer applicable and the meeting at NIST agreed that Figure 5 on Page 5 was the agreed upon model. Should have statement before point 5 on page 3 that reads "We migrated from the model in figure 2 to the model in figure 5" At Point 5 discussing CAN definitions from NADF specification SD-7 Alexis handed out the SD-7 document. PAGE 4 Discussion on Figure 3 lead to the need for a discussion of Address Space as a new agenda item. PAGE 5 Figure 5 lead to a request from Peter as to what the scope of the Dir. Synch. mechanism is. Is it just the Flat file format or do we need to cover protocol also. Kirpal: The document we come up with MUST (via annexes) describe solutions outside of X.500. These annexes might be able to reference NIST OIW agreements which could refer to agreements. A publication mechanism should be discussed as a new agenda item. ______________________________________________________ Action Item Review: 1. Alexis still to do this but didn't have time - will do this by next meeting. 1/21 - OPEN 2. No progress so far, Alexis will adopt this action (due to proximity) and will try to talk next week. 1/21 - OPEN 3. Alexis has talked to Steve Kille who is putting together a Dir Synch. Paper. The ISODE are looking to using CDC solution for Dir Synch. CDC may write the paper that Steve was going to. 1/21 - OPEN 4. Alexis talked to Ken Rossen to get Al Grimstead to present the SD-7 document. This could cost $2000 (Al is a consultant). Roger Mizumori (BOEING) will ask the XAPIA Committee to fund this. Alexis wants to do this sometime in March/April timeframe. 1/21 - OPEN ______________________________________________________ New Business: All new business was added as agenda items (see above under Other Items ) ______________________________________________________ Continue Work From Previous Meeting: Major effort during the meeting in addition to the rest of the Agenda items was to define the Document structure. This will facilitate the work effort during the period between face to face meetings. The Document Outline is shown on the next page: Table Of Contents Introduction Scope Glossary Of Terms Model(s) - Functional Architecture Access Control/Security Management/Administration - Error Handling - Billing Issues Synchronization Space Service Description - Behavior - Interface File Format Schema & Object Definitions Registration Process Directory Information Ownership/Mastering Conformance Requirements For Future Study Appendices Examples Allocation Of Object Ids Recommended Practices References ______________________________________________________ Discuss EMA Directory Synch. Status and presentation (Alexis scheduled to do this in April). Intent to give out a rough draft of XAPIA Dir. Synch . document at EMA assuming it is in a reasonable state to do so. Alexis will contact Debbie Burkhart in this regard. ______________________________________________________ Discuss status of CAN - possibility of bringing in an expert: NADF documents SD-9, SD-7 and SD-4 were distributed for Review This discussion covered as previous action Item. Ken Rossen will try to persuade Al to attend NIST OIW at March. See next meetings. ______________________________________________________ Other items: - Where to get OIDs It was decided that registration of OIDs for Synchronization purposes would be carried out by the Registering Organization (Company). If the Company didn't have (or want) its own ARC from the ISO-Country-US-Organization ARC then they could register via NIST-OIW DSSIG. This would be under a ...OIW-DSSIG ARC which the nominated naming authority is the OIW DSSIG. XAPIA Dir. Synch. Spec. will define a Dir. Synch. Object Class OID which will be adopted from the OIW DSSIG ARC. Discussion of Dir. Synch. Object Class will be covered in later discussions. - Attributes with similar values in different environments Discussion evolved from agenda item related to OID specification. It was determined that XAPIA should specify an Object Class for Directory Synchronization which could be used either integral to an X.500 Database or in canonical form in a non-X.500 environment. Synch space is set up from any media, E-Mail to Carrier Pigeon. Synch. Space contains Synchronization Agreement (only need one per Mail System) so that when MSMail wants data it asks for it from Synch. Space and Synch Space applies rules and ships back data in form that Requesting system needs it. Model: - Synch Space Service defining behavior (propogation requirements, error handling etc.) - Synch Space Service Interface definition (File format, Service Operation definitions, Propogation.Access Ctrl Activities). Alexis: By using this model then prototyping (at Boeing or other places) can be achieved to validate Spec. Issues: Missing data, Duplicate data, Resolution of unknown names (Smith001), File format, Uniqueness, Access Control, Rule mapping, completeness, - Vendor/User participation liason letter A list of potentially interested parties (Vendors and Users) was compiled. Alexis will compose a liason letter for distribution in an effort to solicit contributions and participation in the Directory Synchronization effort. The list: cc:Mail Microsoft Beyond Mail DaVinci WordPerfect Oracle HP Openmail Softswitch Apple Wang Bull IBM O/V Worldtalk CDS Boston S/W ICL Works DEC Retix Marben Alprange Maxware Nexor ISODE IETF MHS-DS OSI- DS Proj. Longbud Novell EMA(all Siemens/ Sun members) Nixdorf AT&T Northern User Groups NIST CSL Telecom COS X/Open OSF XAPIA Members NADF Vendors in Banyan Lotus Notes OIW, EWOS, AOW Wollongong XAPIA OMG MadMan Calendaring - Microsoft/Apple Agreement Eva to contact Neil Koorland (Microsoft) for more information. - Identify Where and how Data is Mastered etc. It is our assumption that this will be a natural fall out of the document as the Model is evolved in the document. Example of Synch process - Name Translation Rule mapping (taking MSMail Names into cc:Mail names) is out of the scope of the Dir. Synch. SIG. The mechanism for doing this will be a local matter/implementation issue. The main goal of the Directory Synch. work will be to ensure that sufficient standardized attributes (type and value(s)) are available via the Directory Synchronization mechanism to facilitate Name Translation. This mechanism will be addressed in the document. - Where and how to publish our findings (XAPIA, NIST, RFC? ...) Discussion covered how to publish SIGs specification. The following is a proposal of where coverage is needed: Criteria - Electonically Available in: WORD PS TXT Location - OIW DSSIG, XAPIA, INFO RFC. Investigate OSF RFC Liason to X/Open It was determined that Alexis would confirm with XAPIA steering committee that these proposals would be acceptable. - Schedule - Report to Steering Committee Alexis was actioned to determine what schedule we should be working to in conjunction with the steering Committee. - Kirpal to bring in Mailing List for Friday session Kirpal brought in the current Mailing List during the Friday session. This information has been incorporated into the Table at the beginning of this document. - File formats It was determined that as part of the presentation from NADF (See Action Item #4 above) the file format used by CAN should be covered. This was the format that was agreed to by the previous meeting in Gaithersberg. ______________________________________________________ New Actions: 5. Alexis to talk to CDS to get them involved. 6. Alexis to contact Debbie Burkhart at EMA regarding EMA presentation. 7. Alexis will report SIG status to XAPIA Steering Committee. 8. Eva will contact Neil Koorland (Microsoft) and report back to the SIG the status of the recently announced Apple- Microsoft Directory Synchronization agreement. 9. Alexis to determine Steering Committee requirements for a deliverable from the SIG. Between this meeting and the meeting in March Alexis will use this to determine a Schedule. 10. Alexis to determine how to liase with the companies listed in the table above (see "Vendor/User Participation Liason Letter " 11. Kirpal to get the correct designation for use of an OIW DSSIG OID. ______________________________________________________ Next Meetings: At NIST-OIW SIG 3/15 - 3/17, at which time it is hope that Al Grimstead will present the NADF CAN. At EMA Meeting 4/18 - 4/22, at which Alexis will present status of SIG. At NIST-OIW SIG 6/14 - 6/16. Roster of Current and Previous Attendees Name Org Phone Fax Internet e-mail Sunil Bajaj Mobil 703-846- 703-846- bajaj@mcimail.com 3796 3939 Chuck Bann Wang 508-967- 508-452- chuck.bann@omail.wa 2764 0896 ng.com Sharon BNR 613-765- 613-763- boeyen@bnr.ca Boeyen 4931 8385 Alexis Bor Boeing 206-865- 206-865- bora@ct.si.cs.boein 3631 6903 g.com Peter Chang HP 408-447- 408-447- pchang@cup.hp.com 3474 3660 Ella Mitre 703-883- 703-883- epg@gateway.mitre.c Gardner 5826 7142 om John Hunt SITA 404-850- 404-850- jmhunt@atl.sita.int 5184 5890 Kirpal Tandem 408-285- 408-285- Khalsa_Kirpal@tande Khalsa 4070 4324 m.com Eva Kuiper OSIWARE 604-436- 604-436- Kuiper 2922 3192 @vancouver.osiware. bc.ca Naresh Oracle 415-506- 415-506- nakumar@oracle.com Kumar 3140 7103 Terry IBM Fed Sys 301-240- longstreth@vnet.ibm Longstreth 6216 .com Greg Loux Soft-Switch 215-640- 215-640- gtl@ssw.com 7428 7550 Ken Rossen SHL kenr@shl.com Systemhouse Rich Schilk JITC 602-538- 602-538- rschilk 5515 5495 @huachuca- jitcosi.army.mil Chun Yo Unisys 215-993- 215-993- Shen 7306 6110 Hemal McDonnell 703-883- 703-883- hemal@mdsol1.mdc.co Wadhia Douglas 3962 3889 m +... From madmin@tandem.com Tue Mar 8 09:39:14 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA11333; Tue, 8 Mar 94 09:39:16 PST Received: from atc.boeing.com by suntan (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA11328; Tue, 8 Mar 94 09:39:14 PST Received: by atc.boeing.com (5.57) id AA09193; Tue, 8 Mar 94 09:40:27 -0800 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2D7CB8A3@ct.si.cs.boeing.com>; Tue, 08 Mar 94 09:40:51 PST From: "Bor, Alexis" To: XAPIA Dir Synch Cc: dssig Subject: Reminder - Directory Synch Meeting Next Week Date: Tue, 08 Mar 94 09:35:00 PST Message-Id: <2D7CB8A3@ct.si.cs.boeing.com> Encoding: 27 TEXT X-Mailer: Microsoft Mail V3.0 Just a reminder for everyone that the XAPIA Directory Synchronization Technical Sub-Committee will be meeting next week, March 15 and 16, at NIST in Gaithersburg, Maryland, in a joint meeting with the OIW Directory Services SIG. During the meeting, we will be focused on directory synchronzation issues on Tuesday and Wednesday. I have been soliciting volunteers and contributors to step up and present their approaches at this meeting. So far, Greg Loux has agreed to discuss his company's approach. I am still hoping that we will be able to get an NADF representative to discuss the CAN technology (Ken Rossen is working this issue). I will be bringing with me a draft directory synch document with me for review during the meeting. Minutes from the January meeting are available on nemo.ncsl.nist.gov in the dssig area. When you log into the machine do the following: cd /pub/oiw/dssig/Public binary get MIN0194.DOC This will get you the Word for Windows version of the minutes. There is also an RTF formatted one for those who can't handle MS Word. -- Alexis From madmin@tandem.com Sun Mar 20 03:28:13 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA05196; Sun, 20 Mar 94 03:29:18 PST Received: from comm.Tandem.COM (comm.cpd.tandem.com) by suntan (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA05186; Sun, 20 Mar 94 03:28:13 PST Received: by comm.Tandem.COM (4.10/4.5) id AA11577; 20 Mar 94 03:26:51 -0800 Date: 18 Mar 94 16:43:00 -0800 From: KHALSA_KIRPAL@tandem.com Message-Id: <199403200326.AA11577@comm.Tandem.COM> To: xapia-dirsynch@tandem.com Subject: current mailing list Soon to be updated! ed_owens@ccmail.com eugene@beyond.com wardb@linkage.com alex-rassey@retix.com beckhardt@iris.com campbell@redsox.bsw.com crotty@ralvm6.vnet.ibm.com gtl@softsw.ssw.com kenr@shl.com khalsa_kirpal@tandem.com mstieglitz@worldtalk.com nhs@ssw.com niraj@cup.hp.com russf@ccmail.com ryatco@vnet.ibm.com /home/suntan/ftp/xapia-dirsynch/mailing-list/current pchang@vnet.ibm.com pchang@cup.hp.com s_cropper@hitachi.com c_nguyen@hitachi.com chang@vancouver.osiware.bc.ca yeaw@cup.hp.com mszeleny@ccmail.com chrisl@retix.com old@sunbim.be c.robbins@nexor.co.uk john.dale@mail.citicorp.com molson@tuxedo.enet.dec.com erik@wimsey.com adrier@mason1.gmu.edu eric@isci.com nakumar@us.oracle.com bora@ct.si.cs.boeing.com kuiper@osison.osiware.bc.ca epg@gateway.mitre.org sri@qsun.att.com markh@ospamm.ssw.dhhs.gov chuck.bann@om.wang.com vidar.sandvik@telepost.telemax.no boeyen@bnr.ca nakumar@oracle.com From madmin@tandem.com Fri Mar 25 11:22:37 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA07824; Fri, 25 Mar 94 11:22:39 PST Received: from atc.boeing.com by suntan (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA07820; Fri, 25 Mar 94 11:22:37 PST Received: by atc.boeing.com (5.57) id AA18969; Fri, 25 Mar 94 11:24:09 -0800 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2D933A6D@ct.si.cs.boeing.com>; Fri, 25 Mar 94 11:24:29 PST From: "Bor, Alexis" To: dssig , XAPIA Dir Synch Subject: Minutes of March Directory Synchronization Meeting Date: Fri, 25 Mar 94 11:18:00 PST Message-Id: <2D933A6D@ct.si.cs.boeing.com> Encoding: 17 TEXT X-Mailer: Microsoft Mail V3.0 I have moved the Directory Synchronization minutes on-line at nemo.ncsl.nist.gov. The files will be at first in /oiw/dssig/Public and will soon be moved to /oiw/dssig/xapia. The files are min0315.ww2 (Word for Windows 2.0) min0315.doc (Word for Windows 6.0) min0315.mcw (Word for Macintosh 5.1) members.xls (Excel spreadsheet with member roster) Alexis Bor bora@ct.si.cs.boeing.com From madmin@tandem.com Fri Apr 1 08:43:51 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA20071; Fri, 1 Apr 94 08:43:54 PST Received: from comm.Tandem.COM (comm.cpd.tandem.com) by suntan (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA20067; Fri, 1 Apr 94 08:43:51 PST Received: by comm.Tandem.COM (4.10/4.5) id AA25913; 1 Apr 94 08:44:33 -0800 Date: 1 Apr 94 08:34:00 -0800 From: KHALSA_KIRPAL@tandem.com Message-Id: <199404010844.AA25913@comm.Tandem.COM> To: xapia-dirsynch@tandem.com Subject: please send requests to ------------ ORIGINAL ATTACHMENT -------- SENT 03-31-94 FROM KHALSA_KIRPAL @COMM2 Hi all, For the next few weeks, please advise people wishing to have their addresses added to the XAPIA DirSynch mailing list to send their requests to the following address: srivastava_chandra@tandem.com. Regards, Kirpal From madmin@tandem.com Wed Apr 6 08:09:53 1994 Received: by suntan (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA22362; Wed, 6 Apr 94 08:09:58 PDT Received: from gateway.mitre.org ([128.29.31.10]) by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA22356; Wed, 6 Apr 94 08:09:53 PDT Return-Path: Received: from cutter.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA18831; Wed, 6 Apr 94 11:09:13 -0400 Date: Wed, 6 Apr 94 11:09:13 -0400 From: epg@gateway.mitre.org (Ella P. Gardner) Message-Id: <9404061509.AA18831@gateway.mitre.org> To: xapia-dirsynch@tandem.com Subject: File Format Cc: epg@gateway.mitre.org For the digital signature in the header, how about algorithmIdentifier for the signature? (Suggested by Elliott Ginsburg) Ella From madmin@tandem.com Wed Apr 6 14:17:00 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA00184; Wed, 6 Apr 94 14:17:11 PDT Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA00173; Wed, 6 Apr 94 14:17:00 PDT Received: by atc.boeing.com (5.57) id AA00199; Wed, 6 Apr 94 14:18:35 -0700 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2DA32710@ct.si.cs.boeing.com>; Wed, 06 Apr 94 14:18:08 PDT From: "Bor, Alexis" To: madmin , xapia-dirsynch Cc: epg Subject: RE: File Format Date: Wed, 06 Apr 94 14:11:00 PDT Message-Id: <2DA32710@ct.si.cs.boeing.com> Encoding: 28 TEXT X-Mailer: Microsoft Mail V3.0 ---------- >From: madmin >To: xapia-dirsynch >Cc: epg >Subject: File Format >Date: Wednesday, April 06, 1994 11:09AM > > >For the digital signature in the header, how about algorithmIdentifier for >the signature? (Suggested by Elliott Ginsburg) > I was disconnected from the network for a few days (since thursday or friday of last week). I didn't get any mail for a few days, so I am responding without the discussion threads. If someone could fill me in off-line I would appreciate it. But my feeling to the above message is that I think that would work great. Alexis Bor bora@ct.si.cs.boeing.com >Ella > From madmin@tandem.com Wed Apr 6 16:16:16 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA02390; Wed, 6 Apr 94 16:16:18 PDT Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA02386; Wed, 6 Apr 94 16:16:16 PDT Received: by atc.boeing.com (5.57) id AA12340; Wed, 6 Apr 94 16:17:56 -0700 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2DA3430A@ct.si.cs.boeing.com>; Wed, 06 Apr 94 16:17:30 PDT From: "Bor, Alexis" To: dssig , XAPIA Dir Synch Subject: Dir Synch Meeting at EMA Date: Wed, 06 Apr 94 16:11:00 PDT Message-Id: <2DA3430A@ct.si.cs.boeing.com> Encoding: 11 TEXT X-Mailer: Microsoft Mail V3.0 Just a quick note to let everyone know that on Friday morning of EMA (April 22) we will be having a dir synch meeting. The afternoon before is a meeting of the EMA Directory committee which I plan on attending as the DIR SYNC representative and update them on our work. The friday meeting will start at 8:30 (but check for last minute changes). It will be a joint EMA/XAPIA/OIW meeting. -- Alexis bora@ct.si.cs.boeing.com From madmin@tandem.com Fri Apr 8 09:22:06 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA08550; Fri, 8 Apr 94 09:22:07 PDT Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA08546; Fri, 8 Apr 94 09:22:06 PDT Received: by atc.boeing.com (5.57) id AA29856; Fri, 8 Apr 94 09:23:48 -0700 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2DA584F7@ct.si.cs.boeing.com>; Fri, 08 Apr 94 09:23:19 PDT From: "Bor, Alexis" To: dssig , XAPIA Dir Synch Subject: POLL- Dir Sync Meeting at EMA - or via E-Mail? Date: Fri, 08 Apr 94 09:17:00 PDT Message-Id: <2DA584F7@ct.si.cs.boeing.com> Encoding: 12 TEXT X-Mailer: Microsoft Mail V3.0 I need to get a headcount to see how many people plan to come to the friday morning, April 22 dir sync meeting at EMA. I am starting to think that we should consider doing this review electronically or via a teleconference after the EMA week. What do people think? Please respond quickly. Thanks. Alexis bora@ct.si.cs.boeing.com From madmin@tandem.com Fri Apr 8 17:23:08 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA19009; Fri, 8 Apr 94 17:23:11 PDT Received: from technet1.shl.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA19000; Fri, 8 Apr 94 17:23:08 PDT Received: from labpskjr.shl.com by technet1.shl.com (4.1/SMI-4.1.8) id AA19172; Fri, 8 Apr 94 17:20:05 PDT Date: Fri, 8 Apr 94 19:25:46 -0500 From: Ken Rossen To: "Bor, Alexis" Subject: Re: POLL- Dir Sync Meeting at EMA - or via E-Mail? Cc: dssig , XAPIA Dir Synch Message-Id: In-Reply-To: Your message <2DA584F7@ct.si.cs.boeing.com> of Fri, 08 Apr 94 09:17:00 PDT Content-Type: TEXT/plain; charset=US-ASCII To Alexis's message I add my encouragement for you all to respond with your plans for attendance of a proposed Directory Synchronization meeting colocated with the EMA in two weeks. I plan to attend. -- KENR@SHL.COM From madmin@tandem.com Fri Apr 8 18:28:34 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA20079; Fri, 8 Apr 94 18:28:37 PDT Received: from osison.osiware.bc.ca by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA20075; Fri, 8 Apr 94 18:28:34 PDT Received: by osison.osiware.bc.ca (4.1/SMI-4.1) id AA01930; Fri, 8 Apr 94 18:28:03 PDT Date: 8 Apr 94 18:27 PDT X400-Trace: ca*infonet*osiware; Arrival 8 Apr 94 18:27 PDT Action: Relayed Priority: normal Ua-Content-Id: 940408841 P1-Message-Id: ca*infonet*osiware;9404081827580041307 Original-Encoded-Information-Types: IA5-Text From: Eva Kuiper To: "Bor, Alexis" Cc: dssig , XAPIA Dir Synch In-Reply-To: <2DA584F7@ct.si.cs.boeing.com> Message-Id: <940408841*kuiper@vancouver.osiware.bc.ca> Subject: POLL- Dir Sync Meeting at EMA - or via E-Mail? Alexis, I will be at the April 22 dir sync meeting. Eva From madmin@tandem.com Mon Apr 11 12:37:53 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA17351; Mon, 11 Apr 94 12:37:55 PDT Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA17346; Mon, 11 Apr 94 12:37:53 PDT Received: by atc.boeing.com (5.57) id AA08899; Mon, 11 Apr 94 12:39:37 -0700 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2DA9A759@ct.si.cs.boeing.com>; Mon, 11 Apr 94 12:39:05 PDT From: "Bor, Alexis" To: dssig , XAPIA Dir Synch Subject: Re: POLL- Dir Sync Meeting at EMA - or via E-Mail? Date: Mon, 11 Apr 94 12:33:00 PDT Message-Id: <2DA9A759@ct.si.cs.boeing.com> Encoding: 6 TEXT X-Mailer: Microsoft Mail V3.0 I have received many positive responses. We will definitely meet on Friday, April 22. I am looking to start at 8:30 so that people can fly out later in the afternoon, if they need to. -- Alexis From madmin@tandem.com Fri Apr 15 19:56:57 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA24375; Fri, 15 Apr 94 19:56:59 PDT Received: from nic.cerf.net by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA24371; Fri, 15 Apr 94 19:56:57 PDT Received: from hpux.peerlogic.com (peerlogic.com [134.24.7.204]) by nic.cerf.net (8.6.7/8.6.6) with SMTP id TAA00901 for ; Fri, 15 Apr 1994 19:56:51 -0700 Received: from ccmail_gw.peerlogic.com by hpux.peerlogic.com with SMTP (1.37.109.4/16.2) id AA11484; Fri, 15 Apr 94 17:40:12 -0700 Received: from cc:Mail by peerlogic.com (1.30/SMTPLink) id A03356; Fri, 15 Apr 94 16:23:35 PST Date: Fri, 15 Apr 94 16:23:35 PST From: kkhalsa Message-Id: <9404151623.A03356@peerlogic.com> To: xapia-dirsynch@tandem.com Subject: New address and Phone number Hi all, My new email address is: kkhalsa@peerlogic.com My new phone number is: 415-252-2875 x414 PeerLogic really is a startup! What fun! I think you can also reach me as kirpal@peerlogic.com. Unfortunately I've got a conflict next week with the XAPIA meeting and won't be able to make it. Customers !?! Regards, Kirpal From madmin@tandem.com Sun Jun 5 16:14:47 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA06158; Sun, 5 Jun 94 16:14:49 PDT Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA06154; Sun, 5 Jun 94 16:14:47 PDT Received: by atc.boeing.com (5.57) id AA10081; Sun, 5 Jun 94 16:38:39 -0700 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2DF261ED@ct.si.cs.boeing.com>; Sun, 05 Jun 94 16:38:21 PDT From: "Bor, Alexis" To: XAPIA Dir Synch Subject: Meeting Reminder and NAG Warning Date: Sun, 05 Jun 94 16:30:00 PDT Message-Id: <2DF261ED@ct.si.cs.boeing.com> Encoding: 23 TEXT X-Mailer: Microsoft Mail V3.0 Reminder: The next XAPIA Directory Synchronization meeting will be held June 14 and 15 (Tuesday and Wednesday) in conjunction with the OIW Directory SIG (DSSIG) meeting in Gaithersburg, Maryland. The DSSIG is planning to meet from June 14 - June 16 (Tuesday through Thursday). If the Dir Sync work needs to run over, I plan to be available on Thursday to continue this work. NAG NOTICE: In the next day or two, I will contacting everyone who has action items outstanding (including me). Please stay tuned. Alexis Bor Boeing Chair, XAPIA Directory Synchronization Technical SubCommittee bora@ct.si.cs.boeing.com 206-865-3631 From madmin@tandem.com Mon Jul 11 16:11:59 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA03648; Mon, 11 Jul 94 16:12:01 PDT Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA03644; Mon, 11 Jul 94 16:11:59 PDT Received: by atc.boeing.com (5.57) id AA07538; Mon, 11 Jul 94 16:14:14 -0700 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2E21D238@ct.si.cs.boeing.com>; Mon, 11 Jul 94 16:14:00 PDT From: "Bor, Alexis" To: XAPIA Dir Synch Subject: Interim Meeting in Chicago and other Notes Date: Mon, 11 Jul 94 16:04:00 PDT Message-Id: <2E21D238@ct.si.cs.boeing.com> Encoding: 34 TEXT X-Mailer: Microsoft Mail V3.0 This is just a reminder that we will be meeting in Chicago next Monday. The primary purpose of this meeting is to try to complete as much as possible of the document and if things work out, have an NADF representative explain some of the technical details so that we can incorporate their work, as appropriate. It is still unclear whether or not we will have a representative from NADF there, but no matter what, we must move the document forward. I will be bringing a laptop to the meeting and expect to have lots of edits. Also, I plan to stay on for the week and attend the EMA Directory Committee meeting which will be held on Wednesday. Here are the meeting details for those who can make it. ---------------------------------------------------------------------------- ------------------------------------- I have a room change for the XAPIA Meeting in Chicago. It will now be held at the Hotel Inter-Continental Chicago in the Toledo Room on the Fifth Floor. The time is the same, 10:00 a.m. - 5:00 p.m., on Monday, July 18. The room is being arranged by the EMA - thanks to Paul Moniz of EMA. If you plan to stay on for the EMA meetings, please contact Paul at Paul Moniz, Project Manager Electronic Messaging Association Phone: 703/524-5550 X.400: G=paul; S=moniz; O=ema; A=mci; C=us Internet: pmoniz@ema.org Hope to see you there. Please RSVP to me so that I can make sure that we have enough facilities. -- Alexis From madmin@tandem.com Mon Jul 11 19:56:09 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA06794; Mon, 11 Jul 94 19:56:17 PDT Received: from ursa-major.spdcc.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA06788; Mon, 11 Jul 94 19:56:09 PDT Received: by ursa-major.spdcc.com with sendmail-5.65/4.7 id ; Mon, 11 Jul 94 22:55:51 -0400 Received: from park-st.bsw.com (park-street.bsw.com) by redsox.bsw.com (4.1/SMI-4.1) id AA28340; Mon, 11 Jul 94 21:19:20 EDT Received: from fenway.bsw.com by park-st.bsw.com (5.65/1.35) id AA18772; Mon, 11 Jul 94 22:17:03 -0400 Message-Id: <9407120217.AA18772@park-st.bsw.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Jul 1994 22:17:20 -0400 To: "Bor, Alexis" , XAPIA Dir Synch From: park-st!campbell@redsox.bsw.com (Larry Campbell) Subject: Re: Interim Meeting in Chicago and other Notes Do you have a draft document for review? I will not be in Chicago (I hate travelling and anyway I am too busy to tear myself away) but I do want to stay informed about this work. - Larry Campbell The Boston Software Works campbell@bsw.com From madmin@tandem.com Tue Jul 12 13:09:49 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA20976; Tue, 12 Jul 94 13:09:51 PDT Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA20972; Tue, 12 Jul 94 13:09:49 PDT Received: by atc.boeing.com (5.57) id AA13617; Tue, 12 Jul 94 13:12:04 -0700 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2E22F902@ct.si.cs.boeing.com>; Tue, 12 Jul 94 13:11:46 PDT From: "Bor, Alexis" To: XAPIA Dir Synch Subject: More Details on Directory Sync Meeting in Chicago Date: Tue, 12 Jul 94 13:02:00 PDT Message-Id: <2E22F902@ct.si.cs.boeing.com> Encoding: 7 TEXT X-Mailer: Microsoft Mail V3.0 Al Grimstad of Bellcore will be at the meeting and will present the NADF CAN approach at 10:00. I am expecting that we will take about an hour on his presentation and tutorial, with any questions being resolved by the end of Lunch. -- Alexis From madmin@tandem.com Wed Jul 13 12:32:38 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA12443; Wed, 13 Jul 94 12:32:40 PDT Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA12439; Wed, 13 Jul 94 12:32:38 PDT Received: by atc.boeing.com (5.57) id AA09089; Wed, 13 Jul 94 12:34:55 -0700 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2E2441CE@ct.si.cs.boeing.com>; Wed, 13 Jul 94 12:34:38 PDT From: "Bor, Alexis" To: xapia-dirsynch Subject: Dir Sync Meeting Location Date: Wed, 13 Jul 94 12:25:00 PDT Message-Id: <2E2441CE@ct.si.cs.boeing.com> Encoding: 14 TEXT X-Mailer: Microsoft Mail V3.0 The XAPIA Directory Synchronization meeting location is: The Inter-Continental Hotel 505 N Michigan Ave Chicago, Il 60611 (312)944-4100 We will be starting at 10:00 AM in the Toledo Room on the fifth floor. Alexis Bor Chair, XAPIA Technical Subcommittee on Directory Synchronization bora@ct.si.cs.boeing.com 206-865-3631 From madmin@tandem.com Wed Aug 17 07:10:28 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA25675; Wed, 17 Aug 94 07:10:29 PDT Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA25671; Wed, 17 Aug 94 07:10:28 PDT Received: by atc.boeing.com (5.57) id AA16922; Wed, 17 Aug 94 07:13:05 -0700 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2E521AF9@ct.si.cs.boeing.com>; Wed, 17 Aug 94 07:13:13 PDT From: "Bor, Alexis" To: dssig , XAPIA Dir Synch Subject: Dir Sync Chicago Minutes and New Draft Date: Wed, 17 Aug 94 07:07:00 PDT Message-Id: <2E521AF9@ct.si.cs.boeing.com> Encoding: 19 TEXT X-Mailer: Microsoft Mail V3.0 At our chicago meeting we were able to come up with a file format. Please take a look at this information before our next meeting - September 13-15 in Gaithersburg. I have copied the following files to nemo.ncsl.nist.gov into the oiw/dssig/xapia directory: chicago.doc Meeting minutes in Word for Windows 6.0 format chicago.w2 Meeting minutes in Word for Windows 2.0 format chicago.mac Meeting minutes in Word for Mac 5.0 format final006.doc Draft dir sync document (Word for Windows 6.0) final006.w2 Draft dir sync document (Word for Windows 2.0) final006.mac Draft dir sync document (Word for Mac 5.0) If someone needs a different format, please let me know. Alexis Bor bora@ct.si.cs.boeing.com From madmin@tandem.com Fri Aug 26 13:30:53 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA03062; Fri, 26 Aug 94 13:30:56 PDT Received: from gatekeeper.us.oracle.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA03058; Fri, 26 Aug 94 13:30:53 PDT Received: from prodpyr1.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.7/37.7) id NAA09598; Fri, 26 Aug 1994 13:30:52 -0700 Received: by prodpyr1.us.oracle.com (Oracle 1.12/37.7) id AA20454; Fri, 26 Aug 94 13:31:29 PDT Message-Id: <9408262031.AA20454@prodpyr1.us.oracle.com> Date: Fri, 26 Aug 94 13:31:29 PDT From: "Martin Cheng" To: xapia-dirsynch@tandem.com Subject: Fwd: RE: Question on sequence numbers Cc: YLIU@us.oracle.com Reply-To: MCheng@us.oracle.com X-Orcl-Application: Mailer: Oracle Documents 2.1.2.3.0m X-Orcl-Application: Phone: 415 506-3461 X-Orcl-Content-Type: multipart/mixed; boundary=Boundary-3488844-0-0 --Boundary-3488844-0-0 Comments? -- Martin ============================================================================= Martin Cheng internet: mcheng@oracle.com Document Automation usmail: 500 Oracle Parkway, Box 659504 Oracle Corporation Redwood Shores, CA 94065 phone: (415) 506-3461 --Boundary-3488844-0-0 X-Orcl-Content-Type: message/rfc822 Received: 26 Aug 1994 13:16:38 Sent: 26 Aug 1994 13:11:00 From:"Bor, Alexis" To: Martin,Cheng,MCHENG@us.oracle.com Subject: RE: Fwd: Return Message Reply-to: BORA@ct.si.cs.boeing.com X-Orcl-Application: Encoding: 78 TEXT X-Orcl-Application: X-Mailer: Microsoft Mail V3.0 Martin, Whould you post this message to xapia-dirsynch@tandem.com. I think this is a fair question for people to discuss. -- Alexis ---------- From: Martin Cheng To: bora Subject: Fwd: Return Message Date: Friday, August 26, 1994 10:31AM --Boundary-7927175-0-0 -- Martin --Boundary-7927175-0-0 X-Orcl-Content-Type: message/rfc822 Received: 25 Aug 1994 18:40:28 Sent: 25 Aug 1994 18:39:50 From:"ORAPOST" To: MCheng Subject: Return Message Cc: ORAPOST Reply-to: ORAPOST X-Orcl-Content-Type: multipart/mixed; boundary=Boundary-7927175-0-1 --Boundary-7927175-0-1 The included message could not be delivered to the following invalid mail names. Please verify these names and try them again. Bad name: alexisbor --Boundary-7927175-0-1 X-Orcl-Content-Type: message/rfc822 Received: 25 Aug 1994 18:39:50 Sent: 25 Aug 1994 18:38:15 From:"Martin Cheng" To: alexisbor Subject: Question on sequence number Reply-to: MCheng X-Orcl-Application: Mailer: Oracle Documents 2.1.2.3.0m X-Orcl-Application: Phone: 415 506-3461 Mr Bor, I have pulled and read the XAPIA recommendations document. I have a question about the definition of the XAPIA-DirSync-Info, specifically on the format of the sequence number. I noted that your group has proposed a scheme of major and minor numbers to represent TotalRefresh and IncrementalRefresh sequences. Does this mean that the group makes the assumption that a TotalRefresh will be contained in a single message? Do you assume that the transport system will take care of splitting and reassembling the message if there is a size constraint imposed by the transport system? Thanks. -- Martin --Boundary-7927175-0-1-- --Boundary-7927175-0-0-- --Boundary-3488844-0-0-- From madmin@tandem.com Tue Nov 8 09:21:45 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA14963; Tue, 8 Nov 94 09:21:47 PST Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA14959; Tue, 8 Nov 94 09:21:45 PST Received: by atc.boeing.com (5.57) id AA15125; Tue, 8 Nov 94 09:25:15 -0800 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2EBFB394@ct.si.cs.boeing.com>; Tue, 08 Nov 94 09:21:24 PST From: "Bor, Alexis" To: xapia-dirsynch Subject: Any updates to the Dir Sync draft? Date: Tue, 08 Nov 94 09:21:00 PST Message-Id: <2EBFB394@ct.si.cs.boeing.com> Encoding: 8 TEXT X-Mailer: Microsoft Mail V3.0 I have been making some edits to the Dir Sync draft and plan to put the new draft out later this week. I hope this will give people enough time to review and comment before the next meeting so I can do another draft in time for our next meeting in Gaithersburg, MD on December 13-15. Alexis bora@ct.si.cs.boeing.com From madmin@tandem.com Wed Nov 30 06:52:19 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA02756; Wed, 30 Nov 94 06:52:21 PST Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA02752; Wed, 30 Nov 94 06:52:19 PST Received: by atc.boeing.com (5.57) id AA07616; Wed, 30 Nov 94 06:56:03 -0800 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2EDC91AD@ct.si.cs.boeing.com>; Wed, 30 Nov 94 06:52:29 PST From: "Bor, Alexis" To: XAPIA Dir Synch Subject: REMINDER: Next Dir-Sync Meeting - Dec 13-15 Date: Wed, 30 Nov 94 06:48:00 PST Message-Id: <2EDC91AD@ct.si.cs.boeing.com> Encoding: 17 TEXT X-Mailer: Microsoft Mail V3.0 This is just a reminder to everyone that the next XAPIA Directory Synchronization meeting will be held on December 13-15 in Gaithersburg, Maryland at NIST. This is a joint meeting with the OIW Directory Services SIG. At the meeting I hope to finalize all edits to the document and solicit volunteers to prototype implementations to validate the specification. At this point, I hope to have this document finalized as version 1.0 and if any deficiencies are found during prototyping, they will be corrected into a version 1.1 of the document. See you there! Alexis Bor Chair, XAPIA Directory Synchronization Technical SubCommittee bora@ct.si.cs.boeing.com From madmin@tandem.com Mon Dec 19 04:04:12 1994 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA14796; Mon, 19 Dec 94 04:04:23 PST Received: from lancaster.nexor.co.uk by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA14787; Mon, 19 Dec 94 04:04:12 PST X400-Received: by /PRMD=NEXOR/ADMD= /C=GB/; Relayed; Mon, 19 Dec 1994 12:03:51 +0000 X400-Received: by mta lancaster.nexor.co.uk in /PRMD=NEXOR/ADMD= /C=GB/; Relayed; Mon, 19 Dec 1994 12:03:51 +0000 Date: Mon, 19 Dec 1994 12:03:51 +0000 X400-Originator: n.cook@nexor.co.uk X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=NEXOR/ADMD= /C=GB/;lancaster.ne:143251:941219120349] Content-Identifier: PPMS Message From: Neil Cook Message-Id: <"lancaster.ne:143250:941219120349*/I=n/S=cook/O=NEXOR/PRMD=NEXOR/ADMD= /C=GB/"@MHS> To: xapia-dirsynch Cc: "n.cook" , "c.robbins" X-Mua-Version: XT-MUA 1.3 (wellington) of Wed Jun 15 10:00:40 BST 1994 We have been looking at implementing an xapia format parser, but were unable to come to the last xapia meeting. We have come up against a few problems with the standard as proposed in 0.6. Namely: 1) SequenceNumber is defined as a PrintableString, using the separator ;. Unfortunately, semicolon is not in PrintableString, so we propose to use colon, which is. 2) The TotalRefresh sequence consists of two SET OFs, both of which are optional. This means that they need a tag to identify them. e.g. total [0] TotalRefresh incremental [1] IncrementalRefresh To avoid confusion, perhaps those elements such as TotalRefesh, which are specified differently to those in X.525 might be renamed. This is merely a cosmetic point however. 3) create and modify timestamps are not explicitly mentioned in the xapia 0.6 document. Is there a requirement for them to be present in the attributes for (non glue) entries, or is it reasonable for the parser to add them based on its knowledge of the time element? 4) An SDSEtype is needed in the DISP protocol. At the moment, a sensible default is provided, based on knowledge of the unit of replication specified in the replication agreement, but perhaps there is a need for this in the xapia file format? For example, making entries upto the replication base entry of type glue. This actually also highlights a contradiction in the standard, which specifies that SDSEs of type "root" will be ignored, but also states elsewhere that "there is an empty SDSE of type "root" for the root SDSE". --- Obviously if any of these points are rectified in the new xapia draft, then feel free to ignore them. On that point, when will the minutes/recommendations of that meeting become available? Neil From madmin@tandem.com Mon Jan 30 12:58:13 1995 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA01148; Mon, 30 Jan 95 12:58:29 PST Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA01136; Mon, 30 Jan 95 12:58:13 PST Received: by atc.boeing.com (5.57) id AA19878; Mon, 30 Jan 95 13:01:27 -0800 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2F2D52D5@ct.si.cs.boeing.com>; Mon, 30 Jan 95 12:57:57 PST From: "Bor, Alexis" To: 'xapia-dirsynch' Subject: Draft 0.12 of Dir Sync Document Attached Date: Mon, 30 Jan 95 12:55:00 PST Message-Id: <2F2D52D5@ct.si.cs.boeing.com> Encoding: 13 TEXT, 4171 UUENCODE X-Mailer: Microsoft Mail V3.0 X-Ms-Attachment: FINAL012.DOC 187392 00-00-1980 00:00 Everyone, Attached is version 0.12 of the Dir Sync document. It is in Word for Windows 6.0 format. I will try to post this to nemo.ncsl.nist.gov sometime tomorrow. Please send me your comments. The list is xapia-dirsynch@tandem.com or you can send them directly to me at bora@ct.si.cs.boeing.com. Alexis Bor bora@ct.si.cs.boeing.com [[ FINAL012.DOC : 4360 in FINAL012.DOC ]] The following binary file has been uuencoded to ensure successful transmission. Use UUDECODE to extract. begin 600 FINAL012.DOC MT,\1X*&Q&N$`````````````````````.P`#`/[_"0`&```````````````# M`````0``````````$````@````$```#^____``````````!G````]````/__ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________]____+`$``/[___\M`0``!0````8````'```` M"`````D````*````"P````P````-````#@````\````0````$0```!(````3 M````%````!4````6````%P```!@````9````&@```!L````<````'0```!X` M```?````(````"$````B````(P```"0````E````)@```"<````H````*0`` M`"H````K````+````"T````N````+P```#`````Q````,@```#,````T```` M-0```#8````W````.````#D````Z````.P```#P````]````/@```#\```!` M````00```$(```!#````1````$4```!&````1P```$@```!)````2@```$L` M``!,````30```$X```!/````4````%$```!2````4P```%0```!5````5@`` M`%<```!8````60```%H```!;````7````%T```!>````7P```&````!A```` M8@```&,```!D````90```&8```!H````_?___VD```!J````:P```&P```!M M````;@```&\```!P````<0```'(```!S````=````'4```!V````=P```'@` M``!Y````>@```'L```!\````?0```'X```!_````@````%(`;P!O`'0`(`!% M`&X`=`!R`'D````````````````````````````````````````````````` M```````````6``4`__________\#``````D"``````#`````````1@`````` M`````````(8IH%8HT+D!`P`````1`````````0!#`&\`;0!P`$\`8@!J```` M```````````````````````````````````````````````````````````` M`!(``@'_______________\````````````````````````````````````` M````````````````8@````````!7`&\`<@!D`$0`;P!C`'4`;0!E`&X`=``` M````````````````````````````````````````````````````&@`"`?__ M__\(````_____P`````````````````````````````````````````````` M``0```#SN`(``````$\`8@!J`&4`8P!T`%``;P!O`&P````````````````` M```````````````````````````````````````````6``$!`0````(````$ M``````````````````````````````"&_&Y5*-"Y`8;\;E4HT+D!`````-0- M-!1`!-0-`0```/[___\#````_O___P4````&````!P````@````)````"@`` M``L````,````#0````X````/````$````!$````2````$P```!0````5```` M%@```!<````8````&0```!H````;````'````!T````>````'P```"`````A M````(@```",````D````)0```"8````G````*````"D````J````*P```"P` M```M````+@```"\````P````,0```#(````S````-````#4````V````_O__ M__[___\Y````.@```#L````\````/0```#X````_````0````$$```!"```` M0P```/[_____________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M______________________________\!`/[_`U\``/____\`"0(``````,`` M``````!&'````$UI8W)OOC8!``D```-*!@``!P`<```````%````"P)8_/#[ M!0````P"T`90#P0````$`0T`!````"X!&``$`````@$!``4````)`@`````% M`````0+___\``P```!X`"@```"8&#P`*`/____\````````*````)@8/``H` M_____P````````@```#Z`@8`"``````````$````+0$```,````>``<````6 M!%3_7`A+__0$!0```!0"4/^8`04````3`E#_N`L$````)P'__PH````F!@\` M"@#_____`0``````"@```"8&#P`*`/____\````````#````'@`'`-RE90`S MP`D$```(`&4````````````````#``#SBP``\[@"```````````````````` M``!KB````````(<`````````````````````````````````````A@(`.@<` M``"&`@`Z!P``.HT"```````ZC0(``````#J-`@``````.HT"```````ZC0(` MU````!20`@!T"@``%)`"``````"(F@(``````(B:`@``````B)H"`!````"8 MF@(`0````-B:`@!,````%)`"``````#VMP(`30```"2;`@`F!0``2J`"`%(` M``"2!3>6YC:')O;FEZ871I;VX@4W!E8VEF:6-A=&EO;@U$871A M($9O2`S,"P@,3DY-0M%9&ET;W(Z($%L97AI M2!3>6YC:')O;FEZ871I;VX@1&%T82!&;W)M870@4W!E8VEF M:6-A=&EO;@D3($=/5$]"55143TX@7U1O8S,Q-C`Y-#$X,R`@$R!004=%4D5& M(%]4;V,S,38P.30Q.#,@%#$S%14-1&%T82!&;W)M870)$R!'3U1/0E545$]. M(%]4;V,S,38P.30Q.#0@(!,@4$%'15)%1B!?5&]C,S$V,#DT,3@T(!0Q,Q45 M#45N8V]D:6YG"1,@1T]43T)55%1/3B!?5&]C,S$V,#DT,3@U("`3(%!!1T52 M148@7U1O8S,Q-C`Y-#$X-2`4,3<5%0U296-O;6UE;F1E9"!02!-96-H M86YIF%T M:6]N($9I;&4)$R!'3U1/0E545$].(%]4;V,S,38P.30Q.3D@(!,@4$%'15)% M1B!?5&]C,S$V,#DT,3DY(!0R-A45#4UA;F%G96UE;G0O061M:6YI7!O=&AE=&EC86P@1FEL92!3=')U8W1U M6YC:')O;FEZ871I M;VX@4')O8V5S2P@;6]S="!%+6UA:6P@ M2!S97)V:6-E M7-T96TL M('1H=7,@6YC:')O;FEZ871I;VX@;V8@;75L=&EP M;&4@9&%T82!S;W5R8V5S+B`@070@=&AE('-A;64@=&EM92P@;6]S="!C;VUP M86YI97,@:&%V92!A('-T2!S97)V:6-E(&9O2!S97)V:6-E(&%S('1H:7,@<')E9F5R2!I;F9O M2!B:71M87!S+"!OF%T:6]N('!R;V-E M2!H86YD;&4@'0N("!)="!I7!E+@U4:&ES('-P96-I9FEC871I;VX@9&5F:6YE M7!E2!%;F-O9&EN9R!2 M=6QE2!U'!E8W1E9"!T:&%T M(&UO&-H86YG92P@2`H12UM86EL*2P@;W(@;F5T=V]R:R!P2#1($]P96X@4WES=&5M7-T96US($EN=&5R8V]N M;F5C=&EO;B#15&AE($1I3H@36]D96QS+@W1"4E452U4(%)E8V]M M;65N9&%T:6]N(%@N-3$Q("@Q.3DS*2!\($E33R])14,@.34Y-"TS.C$Y.3,L M($EN9F]R;6%T:6]N('1E8VAN;VQO9WD@T2!/<&5N(%-Y2#1($]P96X@4WES=&5M7-T M96US($EN=&5R8V]N;F5C=&EO;B#15&AE($1I3H@4')O=&]C;VP@ M4W!E8VEF:6-A=&EO;G,N#=$)2515+50@4F5C;VUM96YD871I;VX@6"XU,C`@ M*#$Y.3,I('P@25-/+TE%0R`Y-3DT+38Z,3DY,RP@26YF;W)M871I;VX@=&5C M:&YO;&]G>2#1($]P96X@4WES=&5M7!E7-T96US($EN M=&5R8V]N;F5C=&EO;B#15&AE($1I3H@4V5L96-T960@3V)J96-T M($-L87-S97,N#=$)2515+50@4F5C;VUM96YD871I;VX@6"XU,#D@*#$Y.3,I M('P@25-/+TE%0R`Y-3DT+3@Z,3DY,RP@26YF;W)M871I;VX@=&5C:&YO;&]G M>2#1($]P96X@4WES=&5M7-T96US($EN=&5R8V]N M;F5C=&EO;B#1(%1H92!$:7)E8W1O7-T96US($EN M=&5R8V]N;F5C=&EO;B#1($%B"!.;W1A=&EO;B!/;F4@ M*$%33BXQ*3H@4W!E8VEF:6-A=&EO;B!O9B!B87-I8R!N;W1A=&EO;BX-T0E) M5%4M5"!296-O;6UE;F1A=&EO;B!8+C8X,2`H,3DY-"D@?"!)4T\O245#(#@X M,C0M,CHQ.3DT+"!);F9O7-T M96US($EN=&5R8V]N;F5C=&EO;B#1($%B"!.;W1A=&EO M;B!/;F4@*$%33BXQ*3H@26YF;W)M871I;VX@;V)J96-T('-P96-I9FEC871I M;VXN#=$)2515+50@4F5C;VUM96YD871I;VX@6"XV.#(@*#$Y.30I('P@25-/ M+TE%0R`X.#(T+3,Z,3DY-"P@26YF;W)M871I;VX@=&5C:&YO;&]G>2#1($]P M96X@4WES=&5M6YT87@@ M3F]T871I;VX@3VYE("A!4TXN,2DZ($-O;G-T7-T96US($EN=&5R8V]N;F5C=&EO;B#1($%B"!. M;W1A=&EO;B!/;F4@*$%33BXQ*3H@4&%R86UE=&5R:7IA=&EO;B!O9B!!4TXN M,2!S<&5C:69I8V%T:6]N7-T96US($EN=&5R8V]N;F5C=&EO;B#1(%-P M96-I9FEC871I;VX@;V8@05-.+C$@96YC;V1I;F<@7-T96US M(-$@3W!E;B!3>7-T96US($EN=&5R8V]N;F5C=&EO;B#1(%-E8W5R:71Y($9R M86UE=V]R:W,@:6X@3W!E;B!3>7-T96US(-$@4&%R="`Q.B!/=F5R=FEE=RX- MT0E)5%4M5"!296-O;6UE;F1A=&EO;B!8+C@Q,B`H,3DY-"D@?"!)4T\O245# M(#$P,3@Q+3(Z(#$Y.3,L($EN9F]R;6%T:6]N(%!R;V-E2!& MF%T:6]N2!&;W)U;2!3=&%N9&EN9R!$;V-U;65N="`T+"!697)S:6]N(#@N M,"`H2F%N=6%R>2`Q.3DS*2!-87!P:6YG('1H92!.;W)T:"!!;65R:6-A;B!$ M250@;VYT;R!$:7)E8W1O2!-86YA9V5M96YT($1O;6%I;G,@+2!.86UE(&%N9"!+ M;F]W;&5D9V4@4VAA7-T96US($EN=&5R8V]N;F5C=&EO;B!0F%T:6]N.@D@($$@;65C:&%N:7-M M('1O(&5N2!A8W)O3H) M("!!(&1A=&%B87-E('1H870@<')O=FED97,@:6YF;W)M871I;VX@86)O=70@ M=7-E7!I8V%L;'D@86QL;W=S(&YA;65S('1O(&)E(&%S2!S97)V:6-E('!R;W9I9&5R2!397)V M:6-E2!B;W1H('1H92!);G1E"!.;W1A=&EO;B!/;F4@*$%33BXQ M*3H)("!4:&4@3U-)("A/<&5N(%-Y6YT87@N(%-E92!" M87-I8R!%;F-O9&EN9R!2=6QE2!T:&4@2!!4TXN,2!E;F-O9&EN9R!T>7!E(&1U7!E+@U"87-I8R!% M;F-O9&EN9R!2=6QE2!R969E2!T;R!T:&4@86)S=')A8W0@2!O M2`H6"XU,#`I+@U-87!P:6YG(%)U;&5S M.@D)1&5F:6YE7-T96US($EN=&5R8V]N;F5C=&EO;B!) M;7!L96UE;G1O7-T96US($EN=&5R M8V]N;F5C=&EO;B!);7!L96UE;G1O2!397)V:6-E2!D97-CF%T:6]N('-P96-I9FEC871I;VX@:61E;G1I9FEE&-H86YG92!F;W)M870@9F]R('1H92!E>&-H86YG92!O9B!D M:7)E8W1O2!W:&%T('1H:7,@2!$:7)E8W1OF%T:6]N($%G M96YT2!3>6YC:')O;FEZ871I;VX-#0T- M#0T-#0T-#$1I2!3>6YC:')O;FEZ871I;VX@1&%T82!&;W)M870@ M4W!E8VEF:6-A=&EO;@U4:&ES('-E8W1I;VX@9&5S8W)I8F5S('1H92!D871A M(&9O2!I;F9O"(@>&%P:6$M9&ER M+7-Y;F,M:6YF;W)M871I;VXH,2D@?0U$149)3DE424].4PDZ.CT-0D5'24X- M+2T@15A03U)44R!E=F5R>71H:6YG("TM#4E-4$]25%,+"4%T=')I8G5T92P@ M4F5L871I=F5$:7-T:6YG=6ES:&5D3F%M92P@3F%M92P@1&ES=&EN9W5IVIO:6YT+6ES;RUC M8VET="!D'106YC+4EN9F\@9FEL92X-#51H92!S97%U96YC M94YU;6)EF%T M:6]N(&9I;&4@9F]R;6%T+@T-5&AE(&-O;G1E>'102!3 M>6YC:')O;FEZ871I;VX@:6YF;W)M871I;VXN#0U$;VUA:6Y.86UE(#HZ/2!# M2$])0T4@>U!R:6YT86)L92!3=')I;F2!3>6YC:')O;FEZ M871I;VX@:6YF;W)M871I;VX@F%T:6]N(&EN9F]R;6%T:6]N(&EN8VQU9&5S(&%L;"!S>6YC:')O M;FEZ960@96YT6YC16YT2!3>6YC:')O;FEZ871I;VX@96YT2!C;VYT M86EN960@:6X@=&AE(&1I2!S>6YC:')O;FEZ871I;VX@:6YF;W)M M871I;VX@:6YD:6-A=&5S('1H96ER(&1E;&5T:6]N+@T-F%T:6]N(&5N=')I97,@ M=VAI8V@@:&%V92!N;R!S=6)OF%T:6]N(&5N=')I97,N#0UD:7)3>6YC16YT2!T:&4@8VAA M;F=EF5D(&EN9F]R;6%T:6]N(&%R92!I;F-L M=61E9"!I;B!T:&4@26YC6YC16YT5)D;@D) M4F5L871I=F5$:7-T:6YG=6ES:&5D3F%M92P+"6-H86YG97,)"4EN8W)E;65N M=&%L4W1E<%)E9G)EF5D M(&1A=&$N#0UD:7)3>6YC16YT6YC16YT6YC16YT6YC16YT6YC16YT2!A6YC16YT6YC57!D871E6YC0VAA;F=E6YC:')O;FEZ960@9&%T82!I;B!T:&4@;W)D97(@ M&%M M<&QE+"!T;R!S=7!P;W)T(&EN8W)E;65N=&%L('5P9&%T97,@:6X@=&AE(&-A M6YC16YT2!S>6YC:')O;FEZ871I;VX@:6YF;W)M871I;VX@=VEL;"!B92!R M97!R97-E;G1E9"!U6YC+4EN M9F\N(%1H:7,@=F%L=64@2!-96-H86YI2!I;F9O2!S>6YC:')O;FEZ871I M;VX@<')O8V5S7!I8V%L;'D@:6YV;VQV97,@9&ES<&%R871E('-Y2!I M;F9O&%M<&QE+"!T M:&4@;&]C86P@F%T:6]N(&%G2!O9B!T:&4@8V]N6YC:')O;FEZ871I;VX@;V8@9&ES<&%R871E M(&1I2!I;F9O2!S M;W5R8V4@871T&EB:6QI='D-16YA8FQE(&-O;F9I9W5R871I;VX@ M;V8@;6%P<&EN9R!R=6QE2!U2!3>6YC:')O;FEZ871I;VX@;V)J96-T2!A;F0@;V)T86EN(&%N(&]B:F5C="!I9&5N=&EF:65R(&9O"!' M(&]F('1H92!/25<@4W1A8FQE($%G2!A9&1I M=&EO;F%L(&]B:F5C=',@8F5L;W<@=&AE(&EN:71I86P@<&]I;G0@:6X@=&AE M('1R964N("!4:&ES(&]B:F5C="!H87,@8F5E;B!R96=I2!T:&4@4F5G:7-T2!F;W(@=&AE($]312!);7!L M96UE;G1O2!397)V:6-E M2!3>6YC:')O;FEZ871I;VX@ M5&5C:&YI8V%L(%-U8F-O;6UI='1E90=$4U-)1P<'5&%B;&4@$R!315$@5&%B M;&4@7"H@05)!0DE#(!0Q%2`M($]B:F5C="!)9&5N=&EF:65R($%S2!3>6YC:')O;FEZ871I;VX-#0U4:&4@4F5G:7-T M2!A;F0@87)E M(&YO="!A9&1R97-S960@:6X@=&AI'!E8W1E9"!T:&%T('-C:&5M82!D969I;FET:6]NF%T:6]N('=I;&P@8F4@9&5F:6YE9"!B>2!U M'!E M8W1E9"!T:&%T($1I2!3>6YC:')O;FEZ871I;VX@=VEL;"!B92!R M97%U:7)E9"!B971W965N('1W;R!OF%T:6]N M('-P96-I9FEC871I;VX@9&]E2X@($AO M=V5V97(L(&ET(&1O97,@;F]T('!R;VAI8FET(&ET7!E('1O;VP@9&5V96QO<&UE;G0@=V%S(&)E:6YG(&EN=F5S=&EG M871E9"!B>2!N=6UE2!B92!M861E(&%V M86EL86)L92!T;R!O=&AEF%T:6]N($9I;&4-26X@82!F=71U6YC:')O;FEZ871I;VX@9FEL92!W M:6QL(&)E(&EN8VQU9&5D(&%S(&%N(&%P<&5N9&EX('1O(&AE;'`@=&AE(&EM M<&QE;65N=&]R('5N9&5R6YC:')O;FEZ871I;VX@2!V96YD;W)S(&%N M9"!U2!W:6QL M(&)E('!U8FQI6YC:')O;FEZ871I;VX@87)E(&YO="!S<&5C:69I M8V%L;'D@9&ES8W5SF%T:6]N(&%C=&EV:71I97,@87)E(&YO="!A9&1R97-S960@:6X@=&AI"!I&%M<&QE6UE;G0@;V8@=&AIF%T:6]N('-P86-E+B`@270@:7,@:6UP;&5M96YT960@8GD@ M=7-I;F<@82!S:6UP;&4@9FEL92!S>7-T96T@6YC*2!P87)T:71I;VX@;V8@=&AE(&9I;&4@6YC:')O M;FEZ960@9&ER96-T;W)Y(&EN9F]R;6%T:6]N('1H870@8V%N(&)E(')E=')I M979E9"!V:6$@9G1P(&)Y(&%U=&AOF5D('5N:6]N(&]F(&%L;"!S>6YC M:')O;FEZ871I;VX@<&EL;W0@<&%R=&EC:7!A;G1SDB!D:7)E8W1O7-T96V2(&1IF%T:6]N('!I M;&]T('!A2!O9B!D M:7)E8W1OF5D(&1I2!D M871A8F%S92!F:6QE('1H870@8V%N(&)E('-TF5D(&]R('5NF5D('5P9&%T92!I;F9OF5D('-Y;F-H2!S>6YC:')O;FEZ871I;VX@8F%S960@;VX@=&AE(&9I;&4@ M7!O=&AE=&EC86P@1FEL92!3=')U8W1U2!S96%R8V@@=&AE(&EN<'5T('!A6YC('!A7,N(`U087)T:71I;VX@=7!D871E9"!S>6YC:')O;FEZ M960@9&ER96-T;W)Y(&EN9F]R;6%T:6]N#4]N8V4@=7!D871E9"P@=&AE('-Y M;F-H7-T96T@;&]C871I;VX@:6X@=&AE(&]U='!U="!P87)T M:71I;VXN(%-H;W5L9"!W92!O;FQY('!L86-E(&$@F5D('5P M9&%T92!F:6QE(&EN(&QO8V%T:6]N6YC:')O;FEZ871I;VX@F%T:6]N('!I;&]T('!A6YC:')O;FEZ M960@=7!D871E(&9I;&5S(&9R;VT@=&AE(&%P<')O<')I871E(&AI97)A6YC(%-P86-E(%-E7-T96T@9&ER96-T;'D@8V]M;75N:6-A=&5S('=I=&@@96%C:"!S>7-T96T@ M=&\@97AC:&%N9V4@:6YF;W)M871I;VXN("!4:&ES(&ES(&%C:&EE=F5D(&)Y M('5S:6YG(&$@9FEL92!S>7-T96T@9W)A;G1I;F<@87!PF%T:6]N('-P86-E M6YCF5D(&YA M;64@F%T:6]N('!I;&]T('!A M7-T96V2(&1IF%T:6]N('!I;&]T('!A2!O9B!D:7)E8W1O2!A;F0@9FEL97,@=&\@96YA8FQE M(&%C8V5S6YC:')O;FEZ871I;VX@9&%T82!B>2!U<&1A=&EN9R!D;VUA:6YS(&)A M6YC:')O;FEZ960@:6YF;W)M871I M;VX@8V%N(&)E(&QI;6ET960@=&\@875T:&]R:7IE9"!S>6YC:')O;FEZ871I M;VX@<&EL;W0@<&%R=&EC:7!A;G1S+@U3>6YC:')O;FEZ871I;VX@4')O8V5S M2!S>6YC:')O;FEZ871I;VX@6YC:')O;FEZ871I;VX@4')O8V5S2!L979E;"!P87)T:71I M;VYS(&]F('1H92!F:6QE('-T6YC:')O;FEZ871I;VX@<&EL M;W0@<&%R=&EC:7!A;G1S('=I;&P@=')A;G-F97(@=7!D871E(&9I;&5S('1O M('1H92!A<'!R;W!R:6%T92!H:65R87)C:&EC86P@;&]C871I;VX@;V8@=&AE M(&9I;&4@F%T:6]N($1A=&$@1F]R;6%T(%-P96-I9FEC M871I;VZ2(`U$:7-TF%T:6]N($1A=&$@1F]R;6%T(%-P96-I9FEC871I;VZ2(`T- M#1-S='EL97)E9B`B5&ET;&4B%$1I2!3>6YC:')O;FEZ871I;VX@ M4W!E8VEF:6-A=&EO;A4)"1-S='EL97)E9B`B:&5A9&EN9R`Q(A4@(!-364U" M3TP@,3@S(%QF(")3>6UB;VPB%2`@$U!!1T44,Q4-#0T34$%'12`@%#,5#0T- M#0W0SQ'@H;$:X0``````&`"/`:$!`)8!F0B<^`&FH`6GH`6H.`2I.`0"`)D$ M=7+N>`$`.@`(`.,QD1>6"0``````````````````2!Q<#7<"0P$````````` M`````````````````````0`)```#3+P```,`!@@`````!0````L"GO]+_P4` M```,`JL`:@$&````)@8F``(``0`%````"P(`````!0````P"JP!J`0<````; M!*L`:@$`````$````/L"$P`*``````"0`0```/\#`@$R36]D97)N`(D$```` M+0$``!0````A!1L`5&ET;&4Z("`H6$%024$N240O,6,N0FQA8VLI``D`"@`9 M````(04E`$-R96%T;W(Z("!!9&]B92!);&QUR`O<'!?9'DQ(&5X8V@@9&5F("]P<%]D>#$@97AC:"!D968-"0D@("`O M<'!?9'DR(&5X8V@@9&5F("]P<%]D>#(@97AC:"!D968@?0T)"7-T;W!P960@ M;F]T('L@+W!P7V)B;W@@=')U92!D968@?2!I9B!](&1E9@T)+T-"('L@>R`O M<'!?8WD@97AC:"!D968@+W!P7V-X(&5X8V@@9&5F#0D)("`@("]P<%]C:'0@ M97AC:"!D968@+W!P7V-W9"!E>&-H(&1E9B!]#0D)R`O M<'!?8VQI<"!T3$@+3DX(&1E9B`O<'!?8G@R(#$X,2!D968@+W!P7V)Y,B`W,R!D M968-``8````F!B8``@````,````>``<```#\`@$`````````!````"T!```( M````^@(```````#^__\`!````"T!`0`$````!`$+``<````;!*L`:@$````` M!````"R!P M<%]C>"!P<%]C>2!M;W9E=&\@<'!?8W=D(#`@3(@<'!?9'DR('!P7V1Y,2!A9&0@9&5F M#0DO<'!?9'@R('!P7V1X,B!P<%]D>#$@861D(&1E9@T)+W!P7W-X('!P7V1X M,B!P<%]D>#$@#$@2!P<%]D>3(@<'!?9'DQ('-U8B!P<%]B>3$@<'!?8GDR('-U8B!D:78@9&5F M#0DO<'!?='@@<'!?9'@Q('!P7W-X('!P7V)X,2!M=6P@2!P<%]B>3(@;75L('-U8B!D968-"7!P7W1X('!P M7W1Y('1R86YS;&%T92!P<%]S>"!P<%]S>2!S8V%L92!](&EF#65N9`T&"``` M)@8E``(0`!`E(5!3+4%D;V)E+3,N,"!%4%-&+3,N,`TE)4-R96%T;W(Z($%D M;V)E($EL;'5S=')A=&]R*%1-*2`U+C`N,0TE)49O2!W:&5R92!N;W0-"7L- M"0EU0T)"7L-"0D)87)R87D@ M87-T;W)E(')E861O;FQY#0D)?2!B:6YD(&1E9@T)"2]S971P86-K:6YG("]P M;W`@;&]A9"!D968-"0DO8W5RPT)"2]F:6YD8VUY:V-UPT)"0DU('!A8VME9&%RPT)"0D) M-"!I;F1E>"!M=6P@-"`Q(')O;&P-"0D)?2!R97!E870-"0D)-2`M,2!R;VQL M('!O<`T)"0ES971C;7EK8V]L;W(-"0E]#0D)9&5F#0E](&EF#0DO9W0S.#\@ M>W9EW1R=65]('LS."!G='T@:69E M;'-E(&1E9@T)=7-E"!D969A M=6QT;6%T&-H(&1U<"!M=6P@861D M('-QPT)"2]S971C;7EK8V]L;W(@=VAEPT)"0DO&-H("XS(&UU;"!A9&0-"0D)"3$@97AC:"!S=6(@0T)"0E] M(&1E9@T)"7T@:68-"0DO8W5R6MC;VQOPT)"0DOPT)"0DO&-H(&9I;F1F;VYT(&5X8V@-"0D)"61U<"!T>7!E("]A M71Y<&4@97$-"0D)"7L-"0D)"0EM86ME9F]N=`T)"0D)?0T)"0D)>PT) M"0D)"7-C86QE9F]N=`T)"0D)?2!I9F5LPT)"0DO8W-H M;W<-"0D)>PT)"0D)6PT)"0D),"`P(#4@+3$@4-O;&]R/PT)>PT)"6%D9"!A9&0@861D(#`@ M;F4-"7T@8FEN9"!D968-"2]T97-T0V]L;W(-"7L-"0EG6MC;VQOPT)"71E6MC;VQO6%N/R`Q(#`@,"`P('1E65L;&]W/R!B;&%C:S\@;W(@;W(@;W(@9&5F#0D)+V-UPU](&1E9@TO M7W!S9@U[#7T@9&5F#2]?<'-S#7L-?2!D968-+U]P:G-F#7L-?2!D968-+U]P M:G-S#7L-?2!D968-+U]P;VQA(#`@9&5F#2]?9&]#;&EP(#`@9&5F#2]C9B!C M=7)R96YT9FQA="!D968-+U]T;2!M871R:7@@9&5F#2]?"`P(&1E9@TO7V-Y(#`@9&5F M#2]?;&5A9&EN9PU;#3`@,`U=(&1E9@TO7V-T;2!M871R:7@@9&5F#2]?;71X M(&UA=')I>"!D968-+U]S<"`Q-B,P,C`@9&5F#2]?:'EP:&5N("@M*2!D968- M+U]F4V-L(#`@9&5F#2]?8VYT(#`@9&5F#2]?:',@,2!D968-+U]N871I=F5% M;F-O9&EN9R`P(&1E9@TO7W5S94YA=&EV945N8V]D:6YG(#`@9&5F#2]?=&5M M<$5N8V]D92`P(&1E9@TO7W!N='(@,"!D968-+U]T1&EC="`R(&1I8W0@9&5F M#2]?=W8@,"!D968-+U1X#7L-?2!D968-+U1J#7L-?2!D968-+T-296YD97(- M>PU](&1E9@TO7T%),U]S879E<&%G90U[#7T@9&5F#2]?9V8@;G5L;"!D968- M+U]C9B`T(&%RPU](&1E9@TO7V=S(&YU;&P@9&5F#2]?8W,@-"!A2!D968- M+U]I&-H M96-K(#$@:6YD97@@='EP92`O;W!E7!E(&YE(&%N9`T)"7L-"0D) M8FEN9`T)"7T@:68-"0EP;W`@<&]P#0E](&9OPT@96YD#2!E;F0-?2!D968-+U\-;G5L;"!D M968-+V1D968->PT)061O8F5?26QL=7-T'!U=`U[#0ED=7`@;&]A9"!D=7`@;&5N9W1H(&5X M8V@@;6%X;&5N9W1H(&5Q#0E[#0D)9'5P(&1U<"!L;V%D(&1U<`T)"6QE;F=T M:"`R(&UU;"!D:6-T(&-O<'D@9&5F#0E](&EF#0EL;V%D(&)E9VEN#0ED968- M(&5N9`U](&1E9@TO;G!O<`U[#0E[#0D)<&]P#0E](')E<&5A=`U](&1E9@TO MPT)9'5P(&QE;F=T:"!E>&-H('-T&-H(#4@+3$@ M"!M=6P@861D M#0DT(#$@PT)"0DO7V-N="!?8VYT(#$@861D M(&1D968-"0E](&EF#0E](&9O&-H(%]C;G0@;75L(&5X M8V@@7V-N="!M=6P@,B!I;F1E>"!A9&0@-"`Q(')O;&P@,B!I;F1E>"!A9&0@ M-"`Q(')O;&P@<&]P('!O<`U](&1E9@TOPT)-"`Q(')O;&P-"7L-"0DR M(&YP;W`-"0DH,"D@97AC:"`R(&-O<'D@,"!E>&-H('!U="!P;W`-"0EG&-H(&-S:&]W#0DS(&YP;W`-?2!D968-+VISPT)"3(@;G!O<`T)"2@P*2!E>&-H(#(@8V]P>2`P(&5X8V@@ M<'5T#0D)9W-A=F4-"0E?"`V(&EN M9&5X(#8@:6YD97@@-2`M,2!R;VQL('=I9'1HPT)"0EF86QS92!C:&%R<&%T:"!C=7)R96YT<&]I;G0-"0D) M-"!I;F1E>"!S971M871R:7@@2!R;6]V971O#0E](&5X8V@@8W-H;W<-"38@ M;G!O<`U](&1E9@TOPT)>PT)"3(@;G!O<"`H,"D@97AC:`T)"3(@8V]P M>2`P(&5X8V@@<'5T('!O<`T)"69A;'-E(&-H87)P871H#0D),B!C;W!Y(')M M;W9E=&\-"7T@97AC:"!CPT)>PT) M"3(@;G!O<`T)"2@P*2!E>&-H(#(@8V]P>2`P(&5X8V@@<'5T#0D)7W-P(&5Q M#0D)>PT)"0EE>&-H(#4@:6YD97@@-2!I;F1E>"`U(&EN9&5X(#4@+3$@PT)"0EF86QS92!C:&%R<&%T:`T)"7T@:69E M;'-E#0D),B!C;W!Y(')M;W9E=&\-"7T@97AC:"!C2!L;V%D(&1E9@T)+VP-"7L-"0EL:6YE M=&\-"7T@9&5F#0DO3`T)+VP@;&]A9"!D968-"2]M#0E[#0D);6]V971O#0E] M(&1E9@U]#7L-"2]C#0E[#0D)<&P@8W5R=F5T;PT)?2!D968-"2]##0DO8R!L M;V%D(&1E9@T)+W8-"7L-"0EC=7)R96YT<&]I;G0@-B`R(')O;&P@<&P@8W5R M=F5T;PT)?2!D968-"2]6#0DO=B!L;V%D(&1E9@T)+WD-"7L-"0EP;"`R(&-O M<'D@8W5R=F5T;PT)?2!D968-"2]9#0DO>2!L;V%D(&1E9@T)+VP-"7L-"0EP M;"!L:6YE=&\-"7T@9&5F#0DO3`T)+VP@;&]A9"!D968-"2]M#0E[#0D)<&P@ M;6]V971O#0E](&1E9@U](&EF96QS90TO9`U[#0ES971D87-H#7T@9&5F#2]C M9@U[#7T@9&5F#2]I#7L-"61U<"`P(&5Q#0E[#0D)<&]P(&-F#0E](&EF#0ES M971F;&%T#7T@9&5F#2]J#7L-"7-E=&QI;F5J;VEN#7T@9&5F#2]*#7L-"7-E M=&QI;F5C87`-?2!D968-+TT->PT)PU](&1E9@TO:`U[#0EC;&]S97!A M=&@-?2!D968-+TX->PT)7W!O;&$@,"!E<0T)>PT)"5]D;T-L:7`@,2!E<0T) M"7L-"0D)8VQI<"`O7V1O0VQI<"`P(&1D968-"0E](&EF#0D);F5W<&%T:`T) M?0T)>PT)"2]#4F5N9&5R#0D)>PT)"0E.#0D)?2!D9&5F#0E](&EF96QS90U] M(&1E9@TO;@U[#0E.#7T@9&5F#2]L-"5]P;VQA(#`@97$-"7L-"0E?9&]# M;&EP(#$@97$-"0E[#0D)"6=S879E(%]P9B!GPT)"0E?<&8-"0E](&EF96QS90T)?0T)>PT)"2]#4F5N9&5R#0D)>PT) M"0E�D)?2!D9&5F#0E](&EF96QS90U](&1E9@TO9@U[#0EC;&]S97!A=&@- M"48-?2!D968-+U,->PT)7W!O;&$@,"!E<0T)>PT)"5]D;T-L:7`@,2!E<0T) M"7L-"0D)9W-A=F4@7W!S(&=R97-T;W)E(&-L:7`@;F5W<&%T:"`O7VQP("]N M;VYE(&1D968@7W-C#0D)"2]?9&]#;&EP(#`@9&1E9@T)"7T-"0E[#0D)"5]P MPT)"0E3#0D)?2!I9F5LPT)8VQO MPU](&1E9@TO<0U[#0E? M<&]L82`P(&5Q#0E[#0D)9W-A=F4-"7T@:68-?2!D968-+U$->PT)7W!O;&$@ M,"!E<0T)>PT)"6=R97-T;W)E#0E](&EF#7T@9&5F#2\J=0U[#0E?<&]L82`Q M(&%D9"`O7W!O;&$@97AC:"!D9&5F#7T@9&5F#2\J50U[#0E?<&]L82`Q('-U M8B`O7W!O;&$@97AC:"!D9&5F#0E?<&]L82`P(&5Q#0E[#0D)0U)E;F1E<@T) M?2!I9@U](&1E9@TO1`U[#0EP;W`-?2!D968-+RIW#7L-?2!D968-+RI7#7L- M?2!D968-+V`->PT)+U]I('-A=F4@9&1E9@T)8VQI<$9OPT@ M96YD#0E?:2!R97-T;W)E#7T@9&5F#2]/#7L-"3`@;F4-"2]?;V8@97AC:"!D M9&5F#0DO7VQP("]N;VYE(&1D968-?2!D968-+U(->PT),"!N90T)+U]O&-H(&1D968-"2]?;'`@+VYO;F4@9&1E9@U](&1E9@TO9PU[#0DO7V=F(&5X M8V@@9&1E9@T)+U]F8PT)>PT)"5]L<"`O9FEL;"!N90T)"7L-"0D)7V]F('-E M=&]V97)P0T)"0DO7VQP("]F:6QL(&1D968- M"0E](&EF#0E](&1D968-"2]?<&8-"7L-"0E?9F,-"0EF:6QL#0E](&1D968- M"2]?<'-F#0E[#0D)7V9C#0D)87-H;W<-"7T@9&1E9@T)+U]P:G-F#0E[#0D) M7V9C#0D)87=I9'1HPT)+U]G&-H(&1D968-"2]?0T) M"0DO7VQP("]S=')O:V4@9&1E9@T)"7T@:68-"7T@9&1E9@T)+U]PPT) M"5]S8PT)"7-TPT)"5]S8PT)"7-S#0E] M(&1D968-"2]?<&ISPT)"5]S8PT)"6ISPT)7V-F(&%S=&]R92!P;W`-"2]?9F,-"7L- M"0E?;'`@+V9I;&P@;F4-"0E[#0D)"5]O9B!S971O=F5R<')I;G0-"0D)7V-F M(&%L;V%D('!O<"!S971C;7EK8V]L;W(-"0D)+U]L<"`O9FEL;"!D9&5F#0D) M?2!I9@T)?2!D9&5F#0DO7W!F#0E[#0D)7V9C#0D)9FEL;`T)?2!D9&5F#0DO M7W!S9@T)>PT)"5]F8PT)"6%S:&]W#0E](&1D968-"2]?<&IS9@T)>PT)"5]F M8PT)"6%W:61T:'-H;W<-"7T@9&1E9@T)+U]L<"`O;F]N92!D9&5F#7T@9&5F M#2]+#7L-"5]CPT)"5]F8PT)"6%S:&]W#0E](&1D968-"2]? M<&IS9@T)>PT)"5]F8PT)"6%W:61T:'-H;W<-"7T@9&1E9@T)+U]L<"`O;F]N M92!D9&5F#7T@9&5F#2]8#7L-"2]?9W,@97AC:"!D9&5F#0EF:6YD8VUY:V-U MPT)"5]L<"`OPT)"0E?;W,@&-H('-U8B!S971C=7-T;VUC;VQO<@T)"0DO7VQP("]S=')O:V4@9&1E9@T) M"7T@:68-"7T@9&1E9@T)+U]PPT)"5]S8PT)"7-TPT)"5]S8PT)"7-S#0E](&1D968-"2]?<&ISPT)"5]S M8PT)"6ISPT) M<&]P#7T@9&5F#2]A;FYO=&%T97!A9V4->PUU2!K;F]W;B![9V5T(&5X96-]('MP;W`@<&]P?2!I9F5LPT)PT)<')E,SA);FET:6%L:7IE#0DO8F5G:6Y3=')I;F<@97AC:"!S=&]R M90T);6%R:PT)8W5RPT)"0EN97="=69F(&)E9VEN4W1R:6YG(&5Q#0D)"7L-"0D) M"2]L87EEPT) M"0D);F5W0G5F9B!E;F13=')I;F<@97$-"0D)"7L-"0D)"0DO;&%Y97)#;W5N M="!D=7`@;&]A9"`Q('-U8B!S=&]R90T)"0D)"6QA>65R0V]U;G0@,"!E<0T) M"0D)"7L-"0D)"0D)8VQE87)T;VUAPT);6%R:PT)>PT)"6-UPT)"0EP;W`@+VQA>65R0VYT(&1U<"!L;V%D(#$@861D('-T M;W)E#0D)?0T)"7L-"0D)96YD4W1R:6YG(&5Q#0D)"7L-"0D)"6QA>65R0VYT M(#$@97$-"0D)"7L-"0D)"0EC;&5A65R0VYT(&1U<"!L;V%D(#$@PT)>PT) M"5]D;T-L:7`@,2!E<0T)"7L-"0D)+U]D;T-L:7`@,"!D9&5F(&-L:7`-"0E] M(&EF#0D);F5W<&%T:`T)?2!D968-?2!F;W)A;&P-+U1R("]P;W`@;&]A9"!D M968-+T)B('M](&1E9@TO0D(@+W!O<"!L;V%D(&1E9@TO0F<@>S$R(&YP;W!] M(&1E9@TO0FT@>S8@;G!O<'T@9&5F#2]"8R`O0FT@;&]A9"!D968-+T)H('LT M(&YP;W!](&1E9@UE;F0-+TQB#7L-"30@;G!O<`T)-B`Q(')O;&P-"7!O<`T) M-"`Q(')O;&P-"7!O<"!P;W`@<&]P#0DP(&5Q#0E[#0D),"!E<0T)"7L-"0D) M*"5!235?0F5G:6Y,87EEPT)"3`@97$-"0E[#0D)"7-A=F4@+V1IPT)"7)E&-H(&1U<"!M=6P@ M861D('-Q2!P;W`-96YD#6-U&5C#4%D;V)E7TEL;'5S=')A=&]R05]!234@+VEN M:71I86QI>F4@9V5T(&5X96,-)4%)-5]"96=I;E].;VY0&5C#24E14]�`& M````)@8F``(````6````)@8E`"$`'P`E35-%4%,@5')A:6QE<@UP<%]S879E M(')E#@``!P"P```````.````)@8/ M`!(`_____P``"````!SVY/>F")X'"@```"8&#P`*`/____\"```````7```` M)@8/`"0`_____P0`&@```%1.4%`4`$UI8W)O(_RW\ M-`,(````^@(&`!`````````"!````"T!`0`'````_`(!``````````0````M M`0(`L````"4#5@"R]XG_L/>7_[#WI?^O][/_K_?!_Z[WT/^O]][_L/?M_['W M^_^R]PD`M/<6`+?W)0"Y]S,`O/=#`+_W4`##]U\`QO=M`,OW>P#0]XD`U/>7 M`-KWI0#?][4`Y??"`.WWT`#S]]T`^O?J``'X^``(^`8!$/@3`1GX(@$@^"\! M*O@\`3/X20$]^%8!1OAC`5#X;P%;^'T!9_B)`7+XE@%]^*$!B/BN`93XN@&@ M^,8!K/C2`;CXW0'%^.D!T_CT`>'X`0+O^`L"_?@7`@OY(0(9^2P"*/DW`C?Y M0`)&^4L"5?E5`F;Y7@)U^6@"A?EP`I7Y>P*F^80"M_F,`L?YE`+9^9T"Z_FE M`OOYK0(-^K4"'_J]`C#ZPP)$^LH"5?K1`FCZV`)Z^MX"C?KF`I_Z[`*R^O$" MQOKW`MCZ_`+L^@$#`/L'`Q+[#`,F^Q`#._L4`T[[&`-A^QP#;?L=`P<```#\ M`@```````@``!````"T!`P`(````^@(%``````#___\`!````"T!!``*```` M)`,#`-#[)`-)^^8"/?LX`PH````F!@\`"@#_____`0``````#@```"8&#P`2 M`/____\```@```#^`&C^Z0/`_PX````F!@\`$@#_____```(````_@!H_ND# MP/\$````+0$!``0````M`0(`!P```!@$P/_I`VC^_@`*````)@8/``H`____ M_P$```````X````F!@\`$@#_____```(````-@)V_N<"GO\5````^P)`_P`` M`````)`!`````````!)4:6UE]@H````F!@\`"@#_____`0``````#@```"8& M#P`2`/____\```@```#&]H[^(OA6_Q4```#[`I#_````````D`$````````` M$E1I;65S($YE=R!2;VUA;@`!``0````M`0$`!````/`!!0`$````+@$8``4` M```*`@`````%````"0(````"!`````(!`0`-````,@H0_P#W!````%-Y;F,^ M`#@`.``R``0````"`0(`"@```"8&#P`*`/____\!```````*````)@8/``H` M_____P$```````X````F!@\`$@#_____```(````]/BA^-('F`4(````^@(& M`!`````````"!````"T!!0`$````\`$&`+`````E`U8`S0>B`)L'?@!I!UP` M-0/W?`6/]J@%0_78!//U"`2K]$`$8_=T`!OVK`/7\>`#E M_$8`UOP5`,C\Y/^Y_+/_K?R!_Z#\4?^3_"+_B/SR_G[\P_YS_)7^:OQE_F+\ M.?Y;_`S^5/S>_4[\LOU(_(;]1/Q;_4#\,?T\_`;].OS=_#C\M/PW_(S\-_QD M_#;\/?PX_!?\.OSP^SS\R_L__*;[1/R#^TG\8/M._#W[5/P<^UO\^_IB_-KZ M:_R[^G/\G/I__'[ZBOQ@^I3\1/JA_"?ZK?P-^KK\\OG(_-GYU_S`^>?\J?GW M_)+Y!OU]^1G]9_DK_5CY./T$````+0$#``0````M`00`"@```"0#`P#Z^*/] M>/E1_3CY&_T*````)@8/``H`_____P$```````X````F!@\`$@#_____```( M````=OM_^Z?_6_P5````^P*`_P```````)`!`````````!)4:6UE!IG^9@<'````_`(``/___P(```0````M`0,`!````/`!!@`'```` M&P1G!YK^G@8&_!4```#[`I#_````````D`$`````````$E1I;65S($YE=R!2 M;VUA;@"(T00````M`08`!````/`!`0`$````+@$8``4````*`@`````%```` M"0(````"!`````(!`0`6````,@H@!T#\"@```%1E8VAN;VQO9WE$`#(`,@`X M`#@`.``?`#@`.``X``0````"`0(`"@```"8&#P`*`/____\!```````.```` M)@8/`!(`_____P``"````.[[:`39_L`%"````/H"!@`0`````````@0````M M`0$`!````/`!!0`$````+0$"``<````8!,`%V?YH!.[["@```"8&#P`*`/__ M__\!```````.````)@8/`!(`_____P``"````.[[J`#9_@`"!P```!@$``+9 M_J@`[OL*````)@8/``H`_____P$```````X````F!@\`$@#_____```(```` M[OM(!MG^H`<'````&`2@!]G^2`;N^PH````F!@\`"@#_____`0``````#@`` M`"8&#P`2`/____\```@```#N^X@"V?[@`P<````8!.`#V?Z(`N[["@```"8& M#P`*`/____\!```````.````)@8/`!(`_____P``"````&#]^`%H_9`"!``` M`"T!!``$````+0$"``0```#P`0$`!````/`!`P`0````^P(0``<``````+P" M``````$"`B)3>7-T96T`!00````M`0$`!````/`!!@`#````'@`'````%@20 M`@C^^`'`_`@```#Z`@8`"`````````($````+0$#``4````4`F@!8/T%```` M$P(8`V#]!````"T!!``$````+0$"``0```#P`0,`!````"``<` M```6!%`&#OZX!<;\"````/H"!@`(`````````@0````M`0,`!0```!0"*`5F M_04````3`M@&9OT$````+0$$``0````M`0(`!````/`!`P`$````)P'__PH` M```F!@\`"@#_____`0``````"@```"8&#P`*`/____\!```````.````)@8/ M`!(`_____P``"````*(%G`"-")0'#@```"8&#P`2`/____\```@```!N!O(` MU@>Z`0<```#\`@``____`@``!````"T!`P`'````&P2[`=<'\@!N!A4```#[ M`I#_````````D`$`````````$E1I;65S($YE=R!2;VUA;@````0````M`04` M!````"X!&``%````"@(`````!0````D"`````@0````"`0$`#P```#(*=`&H M!@4```!);G!U=``E`#@`.``X`!\`!`````(!`@`*````)@8/``H`_____P$` M``````X````F!@\`$@#_____```(````Z@6B`GT(\`,'````_`(``/___P(` M``0````M`08`!````/`!`P`'````&P3Q`WX(H@+J!14```#[`I#_```````` MD`$`````````$E1I;65S($YE=R!2;VUA;@!M800````M`0,`!````/`!!0`$ M````+@$8``4````*`@`````%````"0(````"!`````(!`0`8````,@HD`R0& M"P```$QO8V%L(%-Y;F,@`$0`.``R`#(`'P`<`#X`.``X`#(`'``$`````@$" M`!4```#[`I#_````````D`$`````````$E1I;65S($YE=R!2;VUA;@````0` M```M`04`!````/`!`P`$````+@$8``4````*`@`````%````"0(````"!``` M``(!`0`/````,@JJ`ZH&!0```%-P86-E`#X`.``R`#(`,0`$`````@$"``H` M```F!@\`"@#_____`0``````#@```"8&#P`2`/____\```@```#J!;($SP=Z M!0<```#\`@``____`@``!````"T!`P`$````\`$&``<````;!'L%T`>R!.H% M%0```/L"D/\```````"0`0`````````25&EM97,@3F5W(%)O;6%N``$`!``` M`"T!!@`$````\`$%``0````N`1@`!0````H"``````4````)`@````($```` M`@$!`!`````R"C0%)`8&````1&]M86EN40`X`%<`,@`?`#@`!`````(!`@`* M````)@8/``H`_____P$```````X````F!@\`$@#_____```(````N@62!DT( M6@<'````_`(``/___P(```0````M`04`!````/`!`P`'````&P1;!TX(D@:Z M!14```#[`I#_````````D`$`````````$E1I;65S($YE=R!2;VUA;@````0` M```M`0,`!````/`!!@`$````+@$8``4````*`@`````%````"0(````"!``` M``(!`0`6````,@H4!_0%"@```%1E8VAN;VQO9WE$`#(`,@`X`#@`.``?`#@` M.``X``0````"`0(`"@```"8&#P`*`/____\!```````.````)@8/`!(`____ M_P``"````*(%7`2-"+0%"````/H"!@`0`````````@0````M`08`!````"T! M`@`'````&`2T!8T(7`2B!0H````F!@\`"@#_____`0``````#@```"8&#P`2 M`/____\```@```"B!9P`C0CT`0<````8!/0!C0B<`*(%"@```"8&#P`*`/__ M__\!```````.````)@8/`!(`_____P``"````*(%/`:-")0'!P```!@$E`>- M"#P&H@4*````)@8/``H`_____P$```````X````F!@\`$@#_____```(```` MH@5\`HT(U`,'````&`34`XT(?`*B!0H````F!@\`"@#_____`0``````#@`` M`"8&#P`2`/____\```@````4!^P!'`>$`@0````M`00`!````"T!`@`$```` M\`$&``0```#P`04`!````"T!`0`$````\`$#``,````>``<````6!(0"O`?L M`70&"````/H"!@`(`````````@0````M`0,`!0```!0"7`$4!P4````3`@P# M%`<$````+0$$``0````M`0(`!````/`!`P`$````)P'__PH````F!@\`"@#_ M____`0``````#@```"8&#P`2`/____\```@````4!\P#'`=J!`0````M`00` M!````"T!`@`#````'@`'````%@1J!+P'S`-T!@@```#Z`@8`"`````````($ M````+0$#``4````4`C8#%`<%````$P+X!!0'!````"T!!``$````+0$"``0` M``#P`0,`!````"L!2('1`8$````+0$$``0````M`0(``P```!X`!P```!8$ M1`;"!ZP%>@8(````^@(&``@````````"!````"T!`P`%````%`(``<````6!/C_(`G0^I@&"````/H" M!@`0`````````@0````M`0,`!0```!0"8/78!P4````3`K`%V`<$````+0$$ M``0````M`0(`!````/`!`P`$````)P'__P<```#\`@```````@``!````"T! M`P`*````)`,#`-@'00`""+3_K@>T_PH````F!@\`"@#_____`0``````#@`` M`"8&#P`2`/____\```@```#C_DH!`P/3!0@```#Z`@8`$`````````($```` M+0$%``0````M`0(`"P```!<(2@'G_F,%_@)4"@0#2@'+^@0````M`0,`!``` M`"T!!``*````)`,#`/L"SP4=`SX%R0)"!0H````F!@\`"@#_____`0`````` M#@```"8&#P`2`/____\```@```!>`,\%TP2K!A4```#[`H#_````````D`$` M````````$E1I;65S($YE=R!2;VUA;@!S(`0````M`08`!````"X!&``%```` M"@(`````!0````D"`````@0````"`0$`(@```#(*8`:8`!(```!5<&1A=&5S M('1O(&1O;6%I;G-<`$``0``Y`"0`.0`Q`"``)`!``"``0`!``&0`.``D`$`` M,@`$`````@$"``H````F!@\`"@#_____`0``````#@```"8&#P`2`/____\` M``@````@^>#^X`#H_@0````M`00`!````"T!`@`$````\`$%``0```#P`0,` M!````"T!`0`$````\`$&``,````>``<````6!(C_X`!`_B#Y"````/H"!@`( M`````````@0````M`0,`!0```!0"X/YH\04````3`N#^D`@$````+0$$``0` M```M`0(`!````/`!`P`$````)P'__PH````F!@\`"@#_____`0``````#@`` M`"8&#P`2`/____\```@```#(_I#_,`$``00````M`00`!````"T!`@`#```` M'@`'````%@0``3`!D/_(_@@```#Z`@8`"`````````($````+0$#``4````4 M`BC^B`,%````$P)@`FC\!````"T!!``$````+0$"``0```#P`0,`!````" M`!4```#[`G#_````````O`(`````````$E1I;65S($YE=R!2;VUA;@"GA00` M```M`0,`!````"X!&``%````"@(`````!0````D"`````@0````"`0$`"@`` M`#(*B/]+`@(````O("@`)``$`````@$"`!4```#[`I#_````````D`$````` M````$E1I;65S($YE=R!2;VUA;@`"``0````M`00`!````/`!`P`$````+@$8 M``4````*`@`````%````"0(````"!`````(!`0`B````,@H8`/``$@```"AF M:6QE('-Y7-T96T`!00````M`0$`!``` M`/`!!``#````'@`'````%@3<`2S^1`'D_`@```#Z`@8`"`````````($```` M+0$#``4````4`K0`A/T%````$P)D`H3]!````"T!!0`$````+0$"``0```#P M`0,`!````"``<````6!)P%#?P$!<7Z"````/H" M!@`(`````````@0````M`0,`!0```!0"=`1E^P4````3`B0&9?L$````+0$% M``0````M`0(`!````/`!`P`$````)P'__PH````F!@\`"@#_____`0`````` M"@```"8&#P`*`/____\!```````.````)@8/`!(`_____P``"````%H%)@%% M",X&#@```"8&#P`2`/____\```@```"B!=P!-0@J`P<```#\`@``____`@`` M!````"T!`P`'````&P0K`S8(W`&B!14```#[`I#_````````D`$````````` M$E1I;65S($YE=R!2;VUA;@````0````M`00`!````"X!&``%````"@(````` M!0````D"`````@0````"`0$`&````#(*7@+6YC(`!$ M`#@`,@`R`!\`'``^`#@`.``R`!P`!`````(!`@`5````^P*0_P```````)`! M`````````!)4:6UE``<````6!*0#=`<&`RP&"````/H" M!@`(`````````@0````M`0,`!0```!0"<`+,!@4````3`C($S`8$````+0$% M``0````M`0(`!````/`!`P`$````)P'__PH````F!@\`"@#_____`0`````` M#@```"8&#P`2`/____\```@```#2!N8$V@9^!00````M`04`!````"T!`@`# M````'@`'````%@1^!7H'Y@0R!@@```#Z`@8`"`````````($````+0$#``4` M```4`E8$T@8%````$P(&!M(&!````"T!!0`$````+0$"``0```#P`0,`!``` M`"``<````6!,L#A/SB`IO["````/H"!@`(`````````@0````M M`0,`!0```!0"`0)=_04````3`J0$NOH$````+0$%``0````M`0(`!````/`! M`P`$````)P'__PH````F!@\`"@#_____`0``````#@```"8&#P`2`/____\` M``@```"&_>L"RP/O!@X````F!@\`$@#_____```(````@?\'!&8!SP0'```` M_`(``/___P(```0````M`0,`!P```!L$T`1G`0<$@?\5````^P*0_P`````` M`)`!`````````!)4:6UE``<````6!&($A@!+`H_^"````/H"!@`(`````````@0````M M`0,`!0```!0"'`*@_`4````3`HD$;0($````+0$%``0````M`0(`!````/`! M`P`$````)P'__PH````F!@\`"@#_____`0``````#@```"8&#P`2`/____\` M``@```"&_9<%<0#O!@X````F!@\`$@#_____```(````GOWM!3$`M08'```` M_`(``/___P(```0````M`0,`!P```!L$M@8R`.T%GOT5````^P*0_P`````` M`)`!`````````!)4:6UE40`,@`R`#@`.``X`!\`.``X`#@`!`````(!`@`*````)@8/``H` M_____P$```````X````F!@\`$@#_____```(````AOV7!7$`[P8(````^@(& M`!`````````"!````"T!!@`$````+0$"``<````8!.\&<0"7!8;]"@```"8& M#P`*`/____\!```````*````)@8/``H`_____P$```````X````F!@\`$@#_ M____```(````<0'C!"0"E@4$````+0$%``0````M`0(`!````/`!!@`$```` M\`$#``0````M`0$`!````/`!!``#````'@`'````%@26!20"XP1Q`0@```#Z M`@8`"`````````($````+0$#``4````4`C@$Q@`%````$P(Y!L<"!````"T! M!0`$````+0$"``0```#P`0,`!````"AT``#H`"`#[-CLOY@P````` M`````````````"P?QQJ&`X@#``````````````````````````````$`"0`` M`Y,.```(`#$```````X````F!@\`$@#_____```(````,/H8_:@&S@<*```` M)@8/``H`_____P(``````!<````F!@\`)`#_____!``:````5$Y04!0`36EC M`PQ````]P```Q8``````/___P``````@`````"` M``"`@`````"``(``@```@(``P,#``,#7-T96T`!00````M`0$` M!````/`!`P`#````'@`'````%@1@_S#\L/[H^@@```#Z`@8`"`````````($ M````+0$#``4````4`@C^B/L%````$P(``(C[!````"T!!``$````+0$"``0` M``#P`0,`!````" M``<````6!'C_V`7`_I`$"````/H"!@`(`````````@0````M`0,`!0```!0" M$/XP!04````3`B``,`4$````+0$$``0````M`0(`!````/`!`P`$````)P'_ M_PH````F!@\`"@#_____`0``````#@```"8&#P`2`/____\```@````(_Z@# MZ`%8!0@```#Z`@8`"`````````($````+0$#``<````;!%@%Z`&H`PC_%0`` M`/L"G_\```````"0`0`````````25&EM97,@3F5W(%)O;6%N``<'!````"T! M!0`$````+@$8``4````*`@`````%````"0(````"!`````(!`0`5````,@HE M!+S_"0```$1I0!%`!L`(``K`"H`&P`P`"``,``$`````@$"`!4` M``#[`I__````````D`$`````````$E1I;65S($YE=R!2;VUA;@!F``0````M M`08`!````/`!!0`$````+@$8``4````*`@`````%````"0(````"!`````(! M`0`0````,@J8!/;_!@```%-E`!0!8``.`8$````+0$$``0````M M`0(`!````/`!`P`$````+0$!``0```#P`04``P```!X`!P```!8$.`8@`5`% MV/\(````^@(&``@````````"!````"T!`P`%````%`)P!'@`!0```!,"$`=X M``0````M`00`!````"T!`@`$````\`$#``0````G`?__"@```"8&#P`*`/__ M__\!```````.````)@8/`!(`_____P``"````!#],`!(_S@`!````"T!!``$ M````+0$"``,````>``<````6!-@`!/^0_TS]"````/H"!@`(`````````@0` M```M`0,`!0```!0",`#@^@4````3`C``<`$$````+0$$``0````M`0(`!``` M`/`!`P`$````)P'__P<```#\`@```````@``!````"T!`P`*````)`,#`$#_ M,`#*_@P`ROY3``H````D`P,`$?TP`(?]4P"'_0P`"@```"8&#P`*`/____\! M```````.````)@8/`!(`_____P``"````&@`:`%P`*`#!````"T!!``$```` M+0$"``0```#P`0,``P```!X`!P```!8$7`,0`:0!R/\(````^@(&``@````` M```"!````"T!`P`%````%`+(!6@`!0```!,"./]H``0````M`00`!````"T! M`@`$````\`$#``0````G`?__!P```/P"```````"```$````+0$#``H````D M`P,`:`!G`44`W0&+`-T!"@```"0#`P!H`)D#BP`B`T4`(@,*````)@8/``H` M_____P$```````X````F!@\`$@#_____```(````F`%``-`#2``$````+0$$ M``0````M`0(`!````/`!`P`#````'@`'````%@3H`(P#H/_4`0@```#Z`@8` M"`````````($````+0$#``4````4`D``:/\%````$P)``/@%!````"T!!``$ M````+0$"``0```#P`0,`!````"D&!P```/P"``#___\"```$ M````+0$&``0```#P`0,`!````"T!!``(````^@(&``@````````"!````"T! M`P`$````\`$%``<````8!.D&4`$X!L/_!0```!0"0`#X!0H````F!@\`"@#_ M____`0``````#@```"8&#P`2`/____\```@```#%_P\'2`&/!P<```#\`@`` M____`@``!````"T!!0`$````\`$&``0````M`00`!P```!L$D`=)`0\'Q?\* M````)@8/``H`_____P$```````X````F!@\`$@#_____```(````IO_+!E4! MS0<5````^P*Q_P```````)`!`````````!)4:6UE``<````6!'@' M\`&H!J@`"````/H"!@`(`````````@0````M`0,`!0```!0"X`5(`04````3 M`C@(2`$$````+0$$``0````M`0(`!````/`!`P`$````)P'__PH````F!@\` M"@#_____`0``````"@```"8&#P`*`/____\!```````.````)@8/`!(`____ M_P``"````%X$*/T-!L#^#@```"8&#P`2`/____\```@```![!`_^"`;`_@@` M``#Z`@8`"`````````($````+0$#``<````8!,#^"`9?`#@`-``X`#8`.0`R M`#(`-@`U```````````````````````````````````````````````````` M````````%@`!`?__________!@````$)`@``````P````````$8`````AOQN M52C0N0&&_&Y5*-"Y`0````````````````,`4`!)`$,````````````````` M```````````````````````````````````````````````````````````* M``(`________________```````````````````````````````````````` M`````````@```$P``````````P!-`$4`5`!!```````````````````````` M``````````````````````````````````````````````````P``@$%```` M!P```/____\````````````````````````````````````````````````$ M````N`P````````#`$\`8@!J`$D`;@!F`&\````````````````````````` M````````````````````````````````````````$@`"`/______________ M_P```````````````````````````````````````````````#<````$```` M````````%@14_UP*2__T!@4````4`E#_F`,%````$P)0_[@-!````"7-T96VI`2K\!P```"$%`0!#>?8!D/P*````)@8/``H`_____P$```````H` M```F!@\`"@#_____````````'````/L"L/\```````"\`@`````````@07)I M86P`[0$`````_____P`````<````^P(``"`7^'\$````+0$#``0```#P`0(` M"````"$%!`!07-T96UM__X)!P```"$%`0!$>;K_ M9`H*````)@8/``H`_____P$```````H````F!@\`"@#_____````````!P`` M`!@$+`%L!GS]O`(*````)@8/``H`_____P$```````H````F!@\`"@#_____ M````````'````/L"D/\```````"\`@`````````@07)I86P`[0$`````____ M_P`````<````^P(``"`7^'\$````+0$#``0```#P`0(`"````"$%!`!3>6YC M//\0!`D````A!04`4W!A8V7_M?_Q`PH````F!@\`"@#_____`0``````"@`` M`"8&#P`*`/____\````````'````&`1@``0)6/[\!@H````F!@\`"@#_____ M`0``````"@```"8&#P`*`/____\````````<````^P*P_P```````+P"```` M`````"!!6YC!VC_;P<) M````(04%`$%G96YT;K[_E`<*````)@8/``H`_____P$```````H````F!@\` M"@#_____````````!P```!@$:``X`F#^,``*````)@8/``H`_____P$````` M``H````F!@\`"@#_____````````"````"$%!`!0`('````_`(!``````````0````M`04`"````/H"!@`!```` M``````0````M`08`!````/`!`@`,````)`,$`'P"]/]E`FX`J@)F`'P"]/\$ M````+0$#``0````M`00`#````"0#!`!\`O3_90)O`*L"9P!\`O3_"@```"8& M#P`*`/____\!```````*````)@8/``H`_____P````````X````D`P4`P`-@ M`8@%8`&(!2@#P`,H`\`#8`$*````)@8/``H`_____P$```````H````F!@\` M"@#_____````````"````/H"!@`(``````````0````M`0(`"P```!<(1P#1 M!@<"Y`0(`M@&X/WP`@0````M`04`!````"T!!@`$````\`$"``P````D`P0` MTP;T_Z4&9@#J!FX`TP;T_P0````M`0,`!````"T!!``,````)`,$`-0&]/^E M!F<`ZP9O`-0&]/\*````)@8/``H`_____P$```````H````F!@\`"@#_____ M````````'````/L"L/\```````"\`@`````````@07)I86P`NG8`````____ M_V]K``"$)+IV`````$`7^'\$````+0$"``0```#P`0$`"@```"$%"`!3=&%N M9&%R9`("Y0,(````(04$`$9I;&58`DT$"0```"$%!@!&;W)M872N`@L$"@`` M`"8&#P`*`/____\!```````*````)@8/``H`_____P$```````0````G`?__ M`P``````+W!P7V)Y,B`E9"!D968*`'!P7V-L:7`-("`@(-#/$>"AL1KA`@`# M`-#/$>"AL1KA`````````````````````#L``P#^_PD`!@`````````````` M`P````$``````````!````_^>P0*````)@8/``H`_____P$```````X````F M!@\`$@#_____```(````>P0H_0@&V?T'````_`(``/___P(```0````M`04` M!````"T!!``(````^@(&``@````````"!````"T!!@`$````\`$#``<````8 M!-G]"`8H_7L$!0```!0".`A(`0H````F!@\`"@#_____`0``````#@```"8& M#P`2`/____\```@```!]!/_]``9__@<```#\`@``____`@``!````"T!`P`$ M````\`$%``0````M`00`!P```!L$@/X!!O_]?00*````)@8/``H`_____P$` M``````X````F!@\`$@#_____```(````7@2[_0T&O?X5````^P*Q_P`````` M`)`!`````````!)4:6UE``<````6!&C^J`:8_6`%"````/H"!@`( M`````````@0````M`0,`!0```!0"T/P`!@4````3`BC_``8$````+0$$``0` M```M`0(`!````/`!`P`$````)P'__PH````F!@\`"@#_____`0``````"@`` M`"8&#P`*`/____\!```````.````)@8/`!(`_____P``"````+;Z&/UE_+#^ M#@```"8&#P`2`/____\```@```#3^O_]8/RP_@@```#Z`@8`"`````````($ M````+0$#``<````8!+#^8/S__=/Z"@```"8&#P`*`/____\!```````.```` M)@8/`!(`_____P``"````-/Z&/U@_,G]!P```/P"``#___\"```$````+0$% M``0````M`00`"````/H"!@`(`````````@0````M`08`!````/`!`P`'```` M&`3)_6#\&/W3^@4````4`BC_``8*````)@8/``H`_____P$```````X````F M!@\`$@#_____```(````U?KO_5C\;_X'````_`(``/___P(```0````M`0,` M!````/`!!0`$````+0$$``<````;!'#^6?SO_=7Z"@```"8&#P`*`/____\! M```````.````)@8/`!(`_____P``"````+;ZJ_UE_*W^%0```/L"L?\````` M``"0`0`````````25&EM97,@3F5W(%)O;6%N````!````"T!!0`$````+@$8 M``4````*`@`````%````"0(````"!`````(!`0`/````,@H0_B[[!0```$QO M8V%L`#$`*``C`"0`%@`$`````@$"`!4```#[`K'_````````D`$````````` M$E1I;65S($YE=R!2;VUA;@`'!P0````M`0<`!````/`!!0`$````+@$8``4` M```*`@`````%````"0(````"!`````(!`0`5````,@IP_O#Z"0```$1I0`Z`!8`&P`C`"0`%@`H`!L`*``$`````@$"``H````F!@\`"@#_____ M`0``````#@```"8&#P`2`/____\```@```#0^G#]V/I`_@0````M`00`!``` M`"T!`@`$````\`$&``0```#P`0,`!````"T!`0`$````\`$'``,````>``<` M```6!$#^>/MP_3#Z"````/H"!@`(`````````@0````M`0,`!0```!0"J/S0 M^@4````3`@#_T/H$````+0$$``0````M`0(`!````/`!`P`$````)P'__PH` M```F!@\`"@#_____`0``````#@```"8&#P`2`/____\```@```!8_(C]8/Q8 M_@0````M`00`!````"T!`@`#````'@`'````%@18_@#]B/VX^P@```#Z`@8` M"`````````($````+0$#``4````4`L#\6/P%````$P(8_UC\!````"T!!``$ M````+0$"``0```#P`0,`!````"````,@H*`%G_#P```%-Y;F-H0`Z`!8`&P`C`"0`%@`H`!L`*``$```` M`@$"``H````F!@\`"@#_____`0``````#@```"8&#P`2`/____\```@````H M_^S^,?_U``0````M`00`!````"T!`@`$````\`$&``0```#P`0,`!````"T! M`0`$````\`$%``,````>``<````6!/4`T?_L_HC^"````/H"!@`(```````` M`@0````M`0,`!0```!0"Z_PJ_P4````3`NX")_\$````+0$$``0````M`0(` M!````/`!`P`$````)P'__PH````F!@\`"@#_____`0``````#@```"8&#P`2 M`/____\```@```">`?C^I@'C``0````M`00`!````"T!`@`#````'@`'```` M%@3C`$8"^/[^``@```#Z`@8`"`````````($````+0$#``4````4`A7]G@$% M````$P*^`IX!!````"T!!``$````+0$"``0```#P`0,`!````"%-T M`````(@7EU```"`R%#3(`2`R%#0````````````````````````````````` M````````````________________```````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``#_______________\````````````````````````````````````````` M``````````````````````#^_P```U\````````````````````````!```` MX(6?\OE/:!"KD0@`*R>SV3````"P`@``#@````<```"8`````@```-P````$ M``````$```@````D`0``#````$@!```+````;`$```T```"0`0``#P```+0! M```0````V`$```H```#\`0``$@```"`"```.````1`(```D```!H`@``$P`` M`(P"``#__________________________________________QX````J```` M0SI<35-/1D9)0T5<5TE.5T]21%Q414U03$%415Q215!35$%.1"Y$3U0````` M````````````````````'@````P```!#;VUP86YY3F%M90`````````````` M````````'@````L```!!;&5X:7,@0F]R````````````````````````'@`` M``L```!!;&5X:7,@0F]R````````````````````````0````(:ER#XHT+D! M````````````````````````````````0``````````````````````````` M````````````````````0````(:ER#XHT+D!```````````````````````` M`````````P```%X0`````````````````````````````````````````P`` M`%!=````````````````````````````````````````0`````!&PR,````` M````````````````````````````````'@```!,```!-:6-R;W-O9G0@5V]R M9"`V+C```````````````P```!\````````````````````````````````` M````````'@````(````R`````````````````````````````````````P`` M````````````````````````````````````````````T,\1X*&Q&N$````` M````````````````.P`#`/[_"0#_________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M________``,```$#```"`P``V@,``-L#``#I`P``Z@,``/P#``#]`P``&`0` M`!D$```P!```,00``#($```T!```/00``#X$``!9!```6@0``'$$``!R!``` M!P``'P<``"$'```C!P``.@<``#L' M``!6!P``5P<``&X'``!O!P``<0<``','``";!P``G`<``+<'``"X!P``SP<` M`-`'``#2!P``U`<``/4'``#V!P``$0@``!((```I"```*@@``"P(```N"``` M1`@``$4(``!@"```80@``'@(``!Y"```>P@``'T(``"H"```J0@``,0(``#% M"```W`@``-T(``#?"```X0@``/L(``#\"```%PD``!@)```O"0``,`D``#() M```T"0``0`D``$$)``!<"0``70D``'0)``!U"0``=PD``'D)``";"0``G`D` M`+<)``"X"0``SPD``-`)``#2"0``U`D``/@)``#Y"0``%`H``!4*```L"@`` M+0H``"\*```Q"@``0PH``$0*``!?"@``8`H``'<*``!X"@``>@H``'P*``"D M"@``I0H``,`*``#!"@``V`H``-D*``#;"@``W0H``/`*``#Q"@``#`L```T+ M``#Z^/H`\O#R\/+P\@#Z^/KX^OCZ`/KX^OCZ^/H`^OCZ^/KX^@#Z^/KX^OCZ M`/KX^OCZ^/H`\O#R\/+P\@#R\/+P\O#R`/KX^OCZ^/H`\O#R\/+P\@#Z^/KX M^OCZ`/KX^@`"6X$`"G4!1`0`````6X$``EJ!``IU`40$`````%J!7PT+```D M"P``)0L``"<+```I"P``2`L``$D+``!D"P``90L``'P+``!]"P``?PL``($+ M``"H"P``J0L``,0+``#%"P``W`L``-T+``#?"P``X0L``/P+``#]"P``&`P` M`!D,```P#```,0P``#,,```U#```10P``$8,``!A#```8@P``'D,``!Z#``` M?`P``'X,``".#```CPP``*H,``"K#```P@P``,,,``#%#```QPP``-\,``#@ M#```^PP``/P,```3#0``%`T``!8-```8#0``0`T``$$-``!<#0``70T``'0- M``!U#0``=PT``'D-``"6#0``EPT``+(-``"S#0``R@T``,L-``#-#0``SPT` M`/,-``#T#0``#PX``!`.```G#@``*`X``"H.```L#@``5PX``%@.``!S#@`` M=`X``(L.``",#@``C@X``)`.``"M#@``K@X``,D.``#*#@``X0X``.(.``#D M#@``Y@X```X/``#^^/[X`/C^^/[X_O@`^/[X_OC^^`#X_OC^^/[X`/,`\P#S M`/,`\P#S`/,`\P#MZ^WK[>OM`/C^^/[X_O@`\P#S`/,`\P#S`/,`\P#S`/C^ M^/[X_O@`\P#S`/,`\P```EN!``IU`40$`````%N!``AU`40$```````*=0%$ M!`````!:@0`"6H%=#@\```\/```J#P``*P\``$(/``!##P``10\``$AD``+49```E&@``8AH``*X:``#K M&@``31L``(D;``#T&P``,!P``(X<``#*'```*1T``&4=``##'0``_QT``%X> M``":'@``[!X```\?```0'P``*A\``'(?``"N'P``+"```&@@``#G(```(R$` M`)HA``#6(0``72(``)DB```K(P``:2,``-\C```>)```FB0``-DD``!5)0`` MDR4``-PE```9)@``E"8``-$F``#[`/L`^P#[`/L`^P#[`/7S]?/U\_4`]?/U M\_7S]0#U\_7S]?/U`/7S]?/U\_4`^P#P[/#L\.SP[/#L\.SP[/#L\.SPYO#L M\.SP[/#L\.SP[/#L\.SP[/#L\.SP``IC$@!E!@!)`0`!``96@4D!``$`!$D! M``$``EJ!``IU`40$`````%J!``AU`40$`````%O1)@``4"<``'4G``"[)P`` MS2<``"(H``!)*```ER@``*LH```@*0``1BD``(PI``">*0``]"D``/`-X`W@#U`/D`^0#Y`/D(=0%$!```````"G4!1`0I!)8R2P$` M#'4!1`0I!)8R=@%+`0`(=0%$!(0P``(``E6!``)6@0`$20$``0`&5H%)`0`! M6*D]``"M/0``Z#T``.D]```%/@``!CX```L^```9/@``-SX``/8^```&/P`` M$C\``!P_``!!/P``3S\``%,_``!4/P``53\``&X_````0```#$```!M````J M0```0T```$5```!&0```2$```$E```!+0```3$```$Y```!/0```5T```%A` M``!90```6D```%Q```!=0```?4```'Y```!_0```@$```)]```"A0```HD`` M`*1```"E0```Q$````Q!```.00``#T$``!1!```N00``-4$``$5!``#>00`` M_T$```%"```&0@``"4(``#I"``!(0@``2T(``$Q"``!-0@``5$(``%5"``!8 M0@``64(``'M"``"'0@``C4(``)M"``">0@``GT(``*!"``"G0@``J$(``*I" M``#,0@``^4(``/I"``#]0@``_D(``!U#```>0P``)4,``"9#```G0P``*$,` M`"U#```Y0P``&D0``!M$```Z1```.T0``/SY`/D`^?SY`/D`^0#Y`/G\^0#W M`/<`^?/Y\_GS^?/Y`/GS^?/Y`/G\^0#Q`/$`^0#Y`/D`^0#Y`/D`^?<`^0#Y M`/D`^?SY]P#Y`/D`^0#Y`/D`^0#Y`/D`^?SY`/D``````F@"``9H`DD!``$` M`E6!``1)`0`!``95@4D!``%?.T0``,=$``#(1```S40``-1$``#L1```_40` M``%%```#10``%44``!Q%```=10``-$4``#9%``!810``644``&A%``!V10`` MCT4``)!%``"110``DD4``)=%``"B10``"T8``!%&```>1@``JT8``+!&``"\ M1@``^$8``/E&```M1P``;4<``'%'``#01P``T4<``-5'``#:1P``VT<``.1' M``!$2```14@``$E(``!42```54@``%U(``!>2```U$@``-M(```%20``$$D` M`!%)``!I20``DTD``)1)```Q2@``4DH``&U*``"&2@``K4H``*Y*``"U2@`` MQ4H``.9*```!2P``(DL``"1+```Q2P``,DL``#I+``!92P``>$L``'E+``!Z M2P``CDL``(]+``"H2P``LTL``-1+``#F2P``Z$L``.E+``#\2P``_4L``$M, M``!73```;DP``'!,``!S3```A$P``)!,``"13```_0#]^?T`_0#]^??]`/T` M_0#]`/T`_?G]`/<`_?G]^?WS\?/N`/GW`/WN`/GI_0#]`/WY_0#]`/T`_0#] M[NG]`/T`_>[]`/T`_0#]`/T`_>G]\?T`_0#]`/T`_0````E5@6,2`$D!``$% M58%C$@`#70(`!UT"`$D!``$"58$`!E6!20$``0`$20$``5R13```H$P``*), M``"E3```IDP``,%,``#(3```W$P``.-,```;30``'$T``)Y-``"G30``M$T` M`+M-``#330``XDT``").```C3@``,TX``$E.``!53@``9TX``,=.``#(3@`` MR4X``,I.``#@3@``)D\``#-/```Z3P``A4\``(9/``"*3P``J$\``+1/``"W M3P``N$\``+Y/``"_3P``TT\```)0```(4```(%```"Q0``!(4```25```$I0 M``!04```DE```)Y0``#Y4```^E````!1```_40``05$``$)1``!%40``1E$` M`$I1``!]40``A%$``(E1``#]40``"5(```Q2```24@``0E(``$-2``!94@`` M95(``*E2``"P4@``O%(``,-2```"4P``#E,``!!3```84P``'U,``#A3```_ M4P``1E,```]4```15```&%0``!]4``"C5```N50``,A4``#:5```W%0``.14 M``#K5```&%4``/T`_0#]`/T`_0#]`/T`_0#]`/WX_?C]`/WU^/WU^/WU^/WS M_?7X[_T`\P#S`/WU^/WS_?7X_0#]`/T`_?7X_?/]^/T`_?/]^/WX_?/]]?C] M]?C]`/7X_?C]^/WU^/T`````!E6!20$``0`"58$`!56!8Q(`"56!8Q(`20$` M`01)`0`!7AA5```D50``)U4``+U5``#/50``ZE4``/Q5````5@``#%8``")6 M```M5@``Z%8``.E6``"79P``SF<``!UH``!':```P&@``,%H``#6:```UV@` M`-AH``#9:```0&H``()J``#C=0``Z'4``'YV``""=@``H'8``*9V```N=P`` M,G<``*UW``"R=P``MW<``+UW```<>```*'@``+)X``"X>```P'@``,UX``!@ M>0``;7D``'%Y``!Y>0``&GH``$]Z``!5>@``67H``.9Z``#K>@``\'H``/9Z M``"P>P``M'L``+A\``"Y?```P7P``,)\``#8?```V7P``-I\``#;?```"GT` M`#I]``"C?0``J'T``"I^``!'?@``A'X``(I^``!(?P``3'\``'Q_``!_?P`` MAG\``+Q_``!,@```4H```%V```!>@```#($``$*!``!K@0``=H$``#*"```Y M@@``18(``$>"``#?@P``_OL`_@#^`/X`_@#Y`/X`]@#Q`/$`\0#^`/X`_@#^ M`/X`_@#^`/X`_@#^`/X`_@#Y`/X`_@#^`/X`[`#Q`/$`\0#^`/X`_@#^`/X` M_@#^`/X`_OG^`/D`_@#^```````````````````(=0%$!!`%`@``"'4!1`0` M``````15@6((``)6@0`$20$``0`"58%;WX,``."#``#H@P``Z8,``/^#```` MA````80```*$```QA```/80``,>$``#-A```U80``.*$``!UA0``@H4``(:% M``".A0``+X8``&2&```_B```0(@``$B(``!)B```7X@``&"(``!AB```8H@` M`)J(``#AB```TXD```B*```*B@``/HH``#*+``!GBP``:XL``&R+``!\BP`` M?8L``*2+``"EBP``IXL``*B+``"\BP``O8L``+^+``#`BP``UHL``->+``#9 MBP``VHL``-Z+``#?BP``X(L``.&+``#DBP``Y8L``.N+``#LBP``[8L``.Z+ M``#OBP``\HL``/.+``#%6`(`^P#V`/8`]@#T`/0`]`#T`/0`\@#M`/8`]@#V M`/0`\@#T`/(`]@#V`/8`]@#V`/8`]@#V`/8`]@#GY>?EY^4``.,````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````````````````)U`0`#4"8`"W4!1`0````` M4"8`"'4!1`1(.P(```)6@0`"58$`"'4!1`0```````AU`40$#","`$$``P`` M`0,```,#```K`P``70,``%X#``"/`P``Q@,``,<#``#(`P``V@,``#4$``!V M!```O`0``/L$```_!0``B@4``.,%```M!@``FP8``.$&```D!P``=`<``-4' M```O"```?@@``.((```U"0``>@D``-4)```R"@``?0H``-X*```J"P``@@L` M`.(+```V#```?PP``,@,```9#0``>@T``-`-```M#@``_@```````/X``9`D M4`3\````````^0```````/<```````#U````````\P```````/$```````#Q M````````[P```````/$```````#M````````\0```````/$``<`AZ0#Q``'` M(>D`\0`!P"'I`/$``<`AZ0#M````````\0```````.T```````#M``'`(>L` M\0```````.T```````#M``'`(>L`[0`!P"'K`.T``<`AZP#M``'`(>L`\0`` M`````/$``<`AZ0#M````````\0```````.T```````#M``'`(>L`[0`!P"'K M`.T``<`AZP#M``'`(>L`ZP```````.L``<`AZP#Q````````[0```````.L` M``````#K``'`(>L```````$/```!$````0$```$1```!&P```1H```$K```" M*@`%`@`!&0```1P`*BT.``"1#@``YPX``$@/``!1#P``4@\``.`/``!0$``` MP!```#D1```[$0``2!$``#$5``!*%P``2Q<``$P7``!2%P``&!D``!D9```: M&0``)1D``"89``!Y&0``>AD``"<:``"P&@``3AL``/4;``"/'```*AT``,0= M``!?'@``[1X``',?```M(```Z"```)LA``!>(@``+",``.$C``"<)```5R4` M`/X```````#\````````_``!P"'K`/H```````#X````````]@```````/8` M`<`AZP#V``'`(>L`]@`!P"'K`/0```````#T``'`(<("[P```````.\`"<`A M%`'O````````]````````/0``<`AP@+X````````[P```````/0```````#T M``'`(<("[P```````.\``L`A%`'O``'`(10![0```````.T``L`A\`#M``+` M(?``[0`"P"'P`.T``L`A\`#M``+`(?``[0`"P"'P`.T``L`A\`#M``+`(?`` MZ@`"P"'P`.T```````#M``/`(?``[0`"P"'P`.T``\`A\`#M``/`(?``[0`" MP"'P`.T``\`A\`#H`````````````````````2\```(N``4```$N```$```4 M\````````0$```$R```!`````0(```$/```!$``I5R4``-TE``"5)@``42<` M`+TG```D*```F"@``"(I``".*0``]2D``*4J``!5*P``Z"L``"XL```O+``` M02P``((L``"#+```^BP``"4N``"%+P``%S```#8Q```\,@``*#,``#(T``"T M-```_30``&4V``#_-P``YC@``.,%T`3_P"'C!=`$_\`AXP70!/_`(;L# MT`3_P"&G`M`$_\`A$@C0!/_`(28)T`3_P"'/!/0```````#Y````````^0`" MP"'"`LX```````#,````````]````````````````````0````$"```C```- M"A$(!Q.8_A3P````##0```$(``#__P```0!H`0```````"X````````````` M```````````````````````````````$```4\````````0$```$N```"+@`% M`"1O.@``BSH``.4Z``#F.@``YSH``.@Z``#I.@``ZCH``.LZ``#L.@``[3H` M`.XZ``#O.@``(SL``'4[``"!.P``@CL``.`[``#P.P``]CL```\\``"L/``` MK3P``*0]``"E/0``Z3T```8^```'/@``$S\``%,_``!O/P``$$```%A```!^ M0```H$```$9!``#>00``_0```````/H```````#U````````]0`!P"$;`?4` M`<`A&P'U``'`(1L!]0`!P"$;`?4``<`A&P'U``'`(1L!]0`!P"$;`?4````` M``#S````````\P`"P"'"`O4```````#Q````````]0```````.\```````#O M``'`(=T`[P`!P"'=`.\``<`AW0#O``3`(=T`ZP```````.\```````#K```` M````Z0```````.D``<`A%`'K``'`(10!Z0```````,@```````#(``'`(24! MR`3_P"',`^D```````#(````````R``!P"$E`<@$_\`AQ0/I````````(``` M#0L1"`<3F/X,-/\!``@```$````!`&@!````````MP`````````````````` M`````````````````````````0````,``!`(!P```2P```$"```!`0``!``` M%/````````(Q``4#``(N``@!)-Y!```H0P``*4,``,A$``#)1```DD4``)-% M```,1@``#48``*M&``"L1@``^$8``/E&```M1P``;$<``-!'``#11P``1$@` M`$5(``#=2```WD@``&E)``!J20``U$D``"9*``"M2@``KDH``"1+```E2P`` M>4L``'I+``".2P``CTL``.A+``#I2P``)$P``/9,``"T30``(DX``"-.``#) M3@``RDX``"9/```G3P``A4\``/X```````#Z````````^@3_P"$S"OH``<`A M%`'Z!/_`(>H%^@`!P"$4`?H$_\`ANP/Z``'`(10!_@```````/H```````#^ M````````_@`!P"$;`?@```````#X``'`(=T`^``#P"'=`/H```````#^```` M````^@```````/H$_\`ASP3Z``'`(10!_@```````/X``<`A%`'X```````` M^``#P"'=`/X```````#^``'`(=@`_@`"P"$4`?X``<`AV`#^``+`(10!]@`` M`````/8``<`A&P'^````````_@`"P"$4`?@```````#X``'`(=T`^``&P"'= M`/@`!<`AW0#X``/`(=T`_@```````/X``\`A%`'^``'`(=@`_@`"P"$4`?X` M`<`AV`#^``+`(10!``````$%```!+````P``$`@'```!```LA4\``(9/``"W M3P``N$\``$E0``!*4```^5```/I0``!"4@``0U(``!!3```14P``$%0``!%4 M``#<5```W50``"95```G50``*%4``"E5```R50``=U8``'A6``!Y5@``>E8` M`'M6``"15@``P58``.A6``#I5@``#%@``$I9``"96@``FEH``+M:``#+6P`` M,%P``*%<``#:7```_@`!P"'8`/X``<`A&P'^``'`(=@`_@3_P"&[`_X``<`A MV`#^!/_`(;L#_@`!P"'8`/X$_\`A]P;^``'`(10!_@3_P"'6!/X``<`AV`#^ M``3`(10!_@`!P"$4`?X`!,`A%`'^``'`(=@`_@3_P"&G`OH``<`A%`'U```` M````]0`!P"$4`?,```````#^````````_@`!P"$4`?X``<`A%`'^```````` M\0```````/$``<`AP@+O````````\P```````/4```````#U``7`(10!]0`% MP"$4`?4`!L`A%`'^````````\P```````/4```````#U``+`(10!]0`"P"$4 M`?4``<`A%`$````````````````````````````````````````````````` M``````````````````````````$G```!`0```0(```0``!3P```````#```0 M"`<```$``";:7```_EP``#M=``!'70``=ET``*!=``#670``]%T``!]>``!` M7@``4UX``&A>```O80``,&$``#=A``!P80``F&$``*YA``#%80``U&$``-5A M``#_80``_&(``!5C```F9```)V0``#)D```S9```-&0``%5D``!D90``964` M`-P```````#<``'`(24!W``!P"$E`=P``<`A)0'<``'`(24!W``!P"$E`=P` M`<`A)0&X````````N``!P"$E`=P```````"V````````L0```````+$``<`A M%`&O````````KP`!P"$4`:\``<`A%`&O``'`(10!KP`!P"$4`:\``<`A%`&Q M``'`(10!M@```````+$```````"V````````L0```````*\```````"M```` M````L0```````+8```````"M````````L0```````+$``<`A%`$``0$```$` M```$```4\````````0(``",```T+$=@)$YC^%/`````,-/\!``@```$````! M`&@!````````MP```````````````````````````````````````````",` M``T+$0@'$YC^%/`````,-/\!``@```$````!`&@!````````MP`````````` M````````````````````````````````'V5E``#!9@``Y&8``)9G``"79P`` MSF<``,]G```<:```'6@``"AH```N:```.F@``$9H``!':```2V@``$YH``!2 M:```7F@``%]H``!E:```9V@``&UH``!Q:```^P```````/D```````#[```` M````^P`!P"$4`?,```````#[````````^P`"P"$4`?L``<`A%`'L```````` M[``!#`,;`>P``:`1&P'L``$8!AL!PP`!&`8;`>P```````#L``$,`Q0![``! MH!$4`>P``1@&%`&?``$8!A0![````````.P``0P#%`'L``&@$10![``!&`84 M`0`````````````````````````````````````````````````````````` M`````````````````````````````````````",``!@!&0&X;`"Y`<`;`+<` MOC0`!)3_X`3$"#P;+"(`````2@!)````````````20```````````$D````` M``````!)`$H``"@``!@!&0&X;`"Y`<`;`+<`OC0`!)3_X`3$"#P;+"(``$H` M2@!*``````!*````2@``````2@```$H``````$H```!*`$H`OP@!)0$E`24! M)0`&```1```4\````!@!``4```4!%/````````$"```$```4\``````6<6@` M`')H``!Z:```?&@``+-H``"Y:```NF@``!=I```8:0``&6D``#]J``!`:@`` M@FH``(-J``"$:@``A6H``(9J``"':@``B&H``(EJ``"::@``&FL``$%K``#E M;```]VP``,1M``"<;@``NFX``)UO``#J;P``$'```+MP``#5<```_W$```YR M``#<``$8!A0!U0```````-4``0P#%`'5``*@$10!U0`!&`84`=P``1@&%`'2 M````````S0```````,T``<`A%`'-``7`(10!S0`!P"$4`<<```````#-```` M````S0`!P"$4`G4``.)U``#C=0``H'8``"YW``"6=P``EW<``!MX```<>``` MLG@``&!Y``!1>@``X7H``.)Z```$?```)WP``"A\``"X?```NGP```E]```* M?0``_@```````/P```````#W````````]0```````/4``<`AP@+W```````` M\P```````/X```````#\````````_@```````/X``L`A%`'^``'`(10!T@3_ MP"'@!-($_\`AQ0/2!/_`(;$"_@```````/X$_\`AIP+^``'`(10!T@3_P"'% M`]($_\`AQ0/2!/_`(=L$_@```````/X``<`A%`'^!/_`(>H%_````````/X` M``````#^``/`(10!SP`!P"$&%LT```````#^```````````````````````` M```````````````````````````````````````````````````````````` M``````````````````````````$Q```"```(`0`@```-"Q$(!Q.8_@PT_P$` M"````0````$`:`$```````"W```````````````````````````````````` M```````!`@```0$```0``!3P```````!`P```0``'@I]```Z?0``*WX``$=^ M``"'?P``O'\```Z!``!"@0``18(``$:"``!'@@``<8(``(&#``"=@P``WH,` M`-^#``#A@P``,(0``#&$``#'A```=84``&:&``!GA@``:(8``':'``"=AP`` MWP```````+X```````#?````````O@```````-\```````"^````````WP`` M`````+H```````"X````````N``!P"$;`;8```````"X````````M``````` M`+@```````"X``'`(10!L``!P"'-#:T```````"X````````C````````(P$ M_\`AQ0.,!/_`(=L$N````````+@``<`A%`&X``7`(10!M``````````@```- M"Q$(!Q.8_@PT_P$`"````0````$`:`$```````"W```````````````````` M```````````````````````",0`%`0`#```%`0@!``$#```!`@```0````,` M`!$(!P``(```#0P1"`<3F/X,-`$``0@```&````!`&@!````````+@`````` M````````````````````````````````````(```#0H1"`<3F/X,-`$``0@` M``&````!`&@!````````+@`````````````````````````````````````` M```9G8<``)Z'```^B```/X@``$&(``"9B```FH@``.&(```*B@``/HH``&F+ M``!JBP``:XL``.*+``#CBP``Y(L``.^+``#PBP``\8L``/*+``#SBP``_@`` M`````/X``\`A%`'^``'`(10!^@```````/<```````#^``'`(10!U@`"P"$; M`;4$_\`AX076``'`(1L!M03_P"'>!?X``<`A%`'^``'`(10!K@```````*P` M``````#^````````I0```````*P```````#^````````_@```````/X``<`A M%`$````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````````````````!A0`'6`:_/\;`0`E`P`!%```!A0`#P``F"0@``P!C)```*@`#0"$``@`J``E( M96%D:6YG(#,```X``P`1H`45M``65``F```#`&,<`````#(`!4`!`'(",@`. M2&5A9&EN9R`U+#4L;#0`#0`%``@!$0``%7@`%E````@`58%=`@!K'``````` M`````"(`04#R_Z$`(@`61&5F875L="!087)A9W)A<&@@1F]N=``````````` M````'@`50`$!`@`>``543T,@,P``!0`/`!'(```$`%:!6H$B`!1`$0$"`2(` M!51/0R`R```(`!``%0``%@``!@!5@5J!6X$L`!-`$0`"`"P`!51/0R`Q```/ M`!$`%7@`%G@`#P4``<`A"@`(`%N!70``8Q0`'``*0`$``@`<``=);F1E>"`Q M```%`!(`$0``````*``A0!$``@`H``U);F1E>"!(96%D:6YG```(`!,`%;L` M%CH``P!C&```+@`@0!$`0@$N``9&;V]T97(`%0`4`!4``!8``"8)"`\(``)( M$B@C`0(``P!C%```(``?0`$`4@$@``9(96%D97(`#``5``\(``+@$,`A`0(` M`"0`)D"B`&$!)``21F]O=&YO=&4@4F5F97)E;F-E``8`8Q``908`)``=0`$` M<@$D``U&;V]T;F]T92!497AT```(`!<`$;0`$TS_```B`!Q``0""`2(`#4YO M6QI;F4`"@`;``4"%<`#%@```P!C'``` M)@#^3Q$`P@$F``M#;VUP86YY3F%M90``"``<`!4``!8```,`8QP``"8`_D^Q M`=(!)@`*5$]#2&5A9&EN9P`*`!T`!0`5H`46T`(#`&,\```D`"]``0#B`20` M!$QI`!%P"!.8_A9X``\%``$0#@```!X`_D\!`/(!'@`)5&%B;&54 M97AT```%`!\`$0``````*@`60`$``@(J``543T,@-```$@`@`!&0`14``!8` M``\%``'`(0H#`&,2```J`!=``0`2`BH`!51/0R`U```2`"$`$5@"%0``%@`` M#P4``<`A"@,`8Q(``"H`&$`!`"("*@`%5$]#(#8``!(`(@`1(`,5```6```/ M!0`!P"$*`P!C$@``*@`90`$`,@(J``543T,@-P``$@`C`!'H`Q4``!8```\% M``'`(0H#`&,2```J`!I``0!"`BH`!51/0R`X```2`"0`$;`$%0``%@``#P4` M`<`A"@,`8Q(``"H`&T`!`%("*@`%5$]#(#D``!(`)0`1>`45```6```/!0`! MP"$*`P!C$@``&@`I0/+_`0`:``M086=E($YU;6)E<@```@!5@20`0D`!`'(" M)``)0F]D>2!497AT```+`"<`$0``%0``%J``````*`#^3Y$"H@(H``M4:71L M92!#;W9E<@``"@`H``4!%=`"%J```P!C,```-@#^3P$`<@(V``Q(96%D:6YG M($)A```"P!5@5T"`&,D`&L<```X`/Y/`0!R M`C@`#E-U8G1I=&QE($-O=F5R``\`*@`%`0@!$0``%?``%J````L`5H%=`@!C M)`!K'```*@#^3Y$"`@`J``I087)T($QA8F5L``H`*P`%`158`A:@``<`58%> M`6,8``!B`/Y/`0#"`F(``V%S;@``0P`L````/+P`/ M:P*.!+(&'0F("_,-7A#*$C45H!<+&G8``) M`%T$`&$`!&,4```J`/Y/`0`"`"H``FQE`!``+P`%`Q'0`A.8_A4``!;P``D` M700`80`$8Q0``#0`_D\!``(`-``/8F]D>2!W:71H($%33BXQ```0`#``$0`` M%"3_```5\``6```&`%T$`&,4`"``(D`!``(`(``'0V%P=&EO;@``"``Q`!5X M`!9X``(`58$\`"-``0`"`#P`$%1A8FQE(&]F($9I9W5R97,`%0`R`!'@`1,@ M_A4``!8```\%``'`(0H`"`!:@5T``&,4``````#(````.PX``$P4```:%@`` M+BD``.@U``#O-P``>U,``"=A```T80``B6<``(]P``#SB```#@``C```#0#_ M____#@`:C```#0#_____#@#_____#0#_____#@#_____#0#_____#@#_____ M#0#_____#@#_____#0#_____#@#_____#0#_____#@#_____#0#_____#@#_ M____#0#_____#@#_____#0#_____#@#_____#0#_____#@#_____#0#_____ M#@#_____#0#_____(``,(?__`0``(?__`@`$(/__`P``(?__!``$(?__!0`` M(?__!@`$(?__!P``(?__"``$(?__"0``(?__"@`$(?__"P``(?__#``$(?__ M#0``(?__#@`$(?__#P``(?__$``$(?__$0``(?__$@`$(?__$P``(?__%``$ M(?__%0``(?__%@`$(?__%P``(?__&``$(?__&0``(?__&@`$(?__&P``(/__ M'``$(?__'0``(?__'@`$(?__'P``(?__(```````R````-X'```[#@``3!0` M`!H6``!S'```I2<``"XI```V+@``Z#4``&\W``#O-P``I3H``,E!```F1P`` MMTP``#)2``![4P``FU<``'!>```G80``-&$``!QE``")9P``NFL``(]P```N M=```N'D``$)^``!U@@``F84``/.(```````````!`$P````"```````#```` M```$```````%`+H````&`+`````'```````(``8!```)```````*`'8````+ M```````,`$0````-`,D````.`(<````/``$````0`$4!```1```````2`"`` M```3`"@````4```````5```````6``$````7```````8`.,````9```````: M`&@````;``(````<``,!```=`/$````>``$````?`````````````0````,` M```K````70```%X```"/````Q@```,<```#(````V@```%$,``!2#```.PX` M`$@.```Q$@``2A0``$L4``!,%```4A0``!@6```9%@``&A8``"46```F%@`` M>18``'H6```G%P``L!<``$X8``#U&```CQD``"H:``#$&@``7QL``.T;``!S M'```+1T``.@=``";'@``7A\``"P@``#A(```G"$``%/@`` M*$```"E```#(00``R4$``))"``"30@``#$,```U#``"K0P``K$,``/A#``#Y M0P``+40``&Q$``#01```T40``$1%``!%10``W44``-Y%``!I1@``:D8``-1& M```F1P``K4<``*Y'```D2```)4@``'E(``!Z2```CD@``(](``#H2```Z4@` M`"1)``#V20``M$H``")+```C2P``R4L``,I+```F3```)TP``(5,``"&3``` MMTP``+A,``!)30``2DT``/E-``#Z30``0D\``$-/```04```$5```!!1```1 M40``W%$``-U1```F4@``)U(``"A2```I4@``,E(``'=3``!X4P``>5,``'I3 M``![4P``D5,``,%3``#H4P``Z5,```Q5``!*5@``F5<``)I7``"[5P``RU@` M`#!9``"A60``VED``/Y9```[6@``1UH``'9:``"@6@``UEH``/1:```?6P`` M0%L``%-;``!H6P``+UX``#!>```W7@``<%X``)A>``"N7@``Q5X``-1>``#5 M7@``_UX``/Q?```58```)F$``"=A```R80``,V$``#1A``!580``9&(``&5B M``#!8P``Y&,``)9D``"79```SF0``,]D```<90``'64``$=E``!?90``G(``.)R``#C<@``H',``"YT``"6=```EW0` M`!MU```<=0``LG4``&!V``!1=P``X7<``.)W```$>0``)WD``"AY``"X>0`` MNGD```EZ```*>@``.GH``"M[``!'>P``AWP``+Q\```.?@``0GX``$5_``!& M?P``1W\``'%_``"!@```G8```-Z```#?@```X8```#"!```Q@0``QX$``'6" M``!F@P``9X,``&B#``!VA```G80``)Z$```^A0``/X4``$&%``"9A0``FH4` M`.&%```*AP``/H<``&F(``!LB```\X@``)@`'`"8`!P`F``9`)@`*@"8`"L` MF@`:`)@`&P"8`!$`F``1``8``0`6``(`F@````8``0`&``$`F````)@```"8 M````!``!``8``0"8````F`````8``0`&``$`F@```)H```":````F@`N`)H` M+@":`"X`F@`N`)H`+@":`"X`F@`N`)H`+@":`"X`F@`N`)H`+@":`"X`F@`N M`)H`+@":`"X`F@`N`)H`+@":`"\`F@`N`)H`+@":`"X`F@`N`)H`+@":`"X` MF@`N`)H`+@":`"X`F@`N`)H`+@":`"X`F@`N``8``0"8````F````)@```"8 M````F````)@```"8````F````)@```"8````F````)@```"8````F````)@` M``"8````!``!``8``0`6``(`F````)@```"8`"X`F@`Q`)H```"8````F``` M`)@```"8````F````)@```"8````F@````8``0":````%@`"`)@```"8`"P` MF``L`)@`+`"8`"P`F``L`)@```"8`"P`F````)@```"8````F````)@```"8 M````F````)@```"8````F````)@```"8````F````)@```"8````F````)@` M``"8````F````)@```"8````F````)@```"8````F````)@`+`"8`"P`F``L M`)@```"8````F````)@```"8````F````)@```"8`"P`F``L`)@```"8```` MF````)@```"8````0``%`$``!0"8````F````)@`+`"8`"P`F``L`)@`+`"8 M`"P`F````)@```"8````F````)@```"8````F````)@```"8````F````)@` M``"8````F````)@```"8````F````)@```"8````F````)@```"8````F``` M`)@```"8````F````!8``@"8````F````)@```"8````!``!``8``0"8`"<` M%@`"`)@```"8````F````)@```":````%@`"`)@```"8````F````)@```"8 M````F````)@```"8````F````)@```"8````F````)@```"8````%@`"`)@` M``"8````F````)@```"8````F````)@```"8````F````!8``@"8````%@`" M`)@```"8````!@`!`)@````4``(`!@`!`)@```"8````F````!8``@"8```` MF````)@```"8````F````)@```"9````F0```)D```"9````F@`Q`)@```"8 M````F````)@```"8````F````)@```"8````F````)@```"8````%``"``8` M`0"8````%@`"`)@````6``(`F````)@````6``(`F````)@````6``(`F``` M`!8``@"8````)@`#`)@````F``,`F`````0``0`&``$`F@```!8``@":```` M)@`#`)H```":````F@```)H```":````F@```)H```":````F@```)H```": M````F@```)H```":````F@```"8``P":````F@```)H```":`#$`F@```)H` M``":````F@```)H```":````F@```)H```":````F@```)H````6``(`F@`` M`"8``P":````F@```)H```":`#$`F@```)H```":````F@```)H```":```` MF@```"8``P":````F@```)H```":`"X`F@`Q`)H```":````F@```)H```": M````G@```)P`````````>0```(8```")``````,``!X'```-"P``#@\``-$F M``"I/0``.T0``)%,```850``WX,``,58`@`M`2X!+P$P`3$!,@$S`30!-0$V M`0`#```M#@``5R4``&\Z``#>00``A4\``-I<``!E90``<6@```YR```*?0`` MG8<``/.+```W`3@!.0$Z`3L!/`$]`3X!/P%``4$!0@':````Z0```/P````8 M`0``,`$``#(!```S`0``/0$``%D!``!Q`0```0``]@$``/@!``#Y`0``!@(``"("```Z`@``/`(` M`#T"``!1`@``;0(``(4"``"'`@``B`(``*D"``#%`@``W0(``.`"``#A`@`` M\P(```\#```G`P``*@,``"L#``!A`P``?0,``)4#``"8`P``F0,``*<#``## M`P``VP,``-X#``#?`P``Z@,```8$```>!```(00``"($```Z!```5@0``&X$ M``!Q!```<@0``)L$``"W!```SP0``-($``#3!```]00``!$%```I!0``+`4` M`"T%``!$!0``8`4``'@%``![!0``?`4``*@%``#$!0``W`4``-\%``#@!0`` M^P4``!<&```O!@``,@8``#,&``!`!@``7`8``'0&``!W!@``>`8``)L&``"W M!@``SP8``-(&``#3!@``^`8``!0'```L!P``+P<``#`'``!#!P``7P<``'<' M``!Z!P``>P<``*0'``#`!P``V`<``-L'``#`H``)8*``"R"@``R@H``,T*``#."@``\PH```\+```G"P``*@L` M`"L+``!7"P``0``V'D``-IY``#H@```_X````&!``!(A0`` M7X4``&&%``#SB```$PT4_Q,R$R44_Q7`%403,A,E%/\5P!5$$S(3)13_%<`5 M1!,R$R44_Q7`%403,A,E%/\5P!5$$S(3)13_%<`51!,R$R44_Q7`%403,A,E M%/\5P!5$$S(3)13_%<`51!,R$R44_Q7`%403,A,E%/\5P!5$$S(3)13_%<`5 M1!,R$R44_Q7`%403,A,E%/\5P!5$$S(3)13_%<`51!,R$R44_Q7`%403,A,E M%/\5P!5$$S(3)13_%<`51!,R$R44_Q7`%403,A,E%/\5P!5$$S(3)13_%<`5 M1!,R$R44_Q7`%403,A,E%/\5P!5$$S(3)13_%<`51!,R$R44_Q7`%403,A,E M%/\5P!5$$S(3)13_%<`51!,R$R44_Q7`%403,A,E%/\5P!5$$S(3)13_%<`5 M1!,R$R44_Q7`%403,A,E%/\5P!5$$S(3)13_%<`51!,R$R44_Q7`%403,A,E M%/\5P!5`%8P3#13_$S(3)13_%<`51!,R$R44_Q7`%403,A,E%/\5P!5$$S(3 M)13_%<`51!6,$SH4_Q6,$PP4_Q6`$PP4_Q6`$PP4_Q6`$PP4_Q6`$PP4_Q6` M`````!$````Y````/````%$```!4````:P```&X```!S````=0```'D```"` M````@@```(D````3"A3_%8`3"A4,$SD5!!,A%/\5@!,A%/\5@/.(``#2!PU? M5&]C,S`V,#E,` M`'I3``!Z4P``>U,``,%3``#!4P``P5,``,%3``#!4P``FE<``)I7``":5P`` MFU<``%-;``!36P``4UL``%-;``!36P``4UL``%-;``#57@``U5X``-5>``#5 M7@``U5X``-5>``#\7P``)F$``"9A```F80``)F$``"9A```G80``,V$``#-A M```S80``,V$``#-A```T80``P6,``(AG``"(9P``B&<``(AG``"(9P``B&<` M`(EG```::```&F@``!IH```::```&F@``.5I``#E:0``Y6D``.5I``"<:P`` MG&L``)QK``"<:P``G&L``.IL``#J;```NVT``+MM``"[;0``NVT``+MM``"[ M;0``_VX``-AO``"/<```7W$``%]Q``!?<0``7W$``%UR```$>0``NGD``$=_ M``"!@```@8```(&```"!@```X8```':$``!!A0``:8@``&F(``!IB```:8@` M`&F(``#TB`````````$````"`````P````0````%````!@````<````(```` M"0````H````+````#`````T````.````#P```!`````2````$P```!0````5 M````%@```!$````7````&````!D````:````&P```!P````=````'@```!\` M```V````(````"$````B````(P```"0````E````)@```"<````H````*0`` M`"H````P````*P```"P````M````+@```"\````Q````,@```#,````T```` M-0```#<````X````.0```#H````[````/````#T````^````/P```$T```!` M````00```$(```!#````1````$4```!&````1P```$@```!)````2@```$L` M``!,````3@```$\```!0````40```%(```!3````5````%4```!6````5P`` M`%@```!9````6@```'4```!;````7````%T```!>````7P```&````!A```` M8@```&,```!D````90```&8```!G````:````&D```!V````=P```'@```!Y M````:@```&L```!L````;0```&X```!O````<````'$```!R````P```'P```!]````?@```'\```"`````@0```((```"'````B``` M`(D```"#````A````(4```"&````B@```(L```",````C0```(X```#9```` MV0```$D,``!0#```40P``$<.``!'#@``1PX``$<.``!'#@``1PX``%$4``!1 M%```410``%$4``!1%```410``"06``!`*0``0"D``$`I``!`*0``0"D``$`I M```&-@``!C8```8V```&-@``!C8```8V```6-@``Y#<``"(X```B.```(C@` M`"(X```B.```@#@``(`X``"`.```@#@``(`X``"`.```,5(``#%2```Q4@`` M,5(``#%2``!Z4P``D%,``)!3``"04P``D%,``)!3``#<4P``W%,``-Q3``#< M4P``W%,``.=3``"Z5P``NE<``+I7``"Z5P``9UL``&=;``!G6P``9UL``&=; M``!G6P``_EX``/Y>``#^7@``_EX``/Y>``#^7@``%&```"9A```Q80``,6$` M`#%A```Q80``,6$``#%A``!480``5&$``%1A``!480``5&$``%1A``#C8P`` MF6<``)EG``"99P``F6<``)EG``"99P``-6@``$!H``!`:```0&@``$!H``#V M:0``]FD``/9I``#V:0``N6L```]M```/;0``U&T``-1M``#4;0``U&T``-1M M``#4;0``#6\``.9O``"7<```EW```*5P``"E<```I7```*5P``!G<0``9W$` M`&=Q``"%<0``>'(``"9Y```(>@``<'\``)R````O@0``G(0``)B%``!IB``` M:8@``&F(``!JB```:H@``&J(``!JB```:H@``/2(``#B`0I!;&5X:7,@0F]R M)$,Z7%@U,#!<1$E2+5-93D-<,3(Q,SDT7$Y%5T120494+D1/0PI!;&5X:7,@ M0F]R)$,Z7%@U,#!<1$E2+5-93D-<,3(Q,SDT7$Y%5T120494+D1/0PI!;&5X M:7,@0F]R)$,Z7%@U,#!<1$E2+5-93D-<,3(Q,SDT7$Y%5T120494+D1/0PI! M;&5X:7,@0F]R)$,Z7%@U,#!<1$E2+5-93D-<,3(Q,SDT7$Y%5T120494+D1/ M0PI!;&5X:7,@0F]R)$,Z7%@U,#!<1$E2+5-93D-<,3(Q,SDT7$Y%5T120494 M+D1/0PI!;&5X:7,@0F]R)$,Z7%@U,#!<1$E2+5-93D-<,3(Q,SDT7$Y%5T12 M0494+D1/0PI!;&5X:7,@0F]R)$,Z7%@U,#!<1$E2+5-93D-<,3(Q,SDT7$Y% M5T120494+D1/0PI!;&5X:7,@0F]R)$,Z7%@U,#!<1$E2+5-93D-<,3(Q,SDT M7$Y%5T120494+D1/0PI!;&5X:7,@0F]R)$,Z7%@U,#!<1$E2+5-93D-<,3(Q M,SDT7$Y%5T120494+D1/0PI!;&5X:7,@0F]R)$,Z7%@U,#!<1$E2+5-93D-< M,3(Q,SDT7$9)3D%,,#$R+D1/0_]`2%`@3&%S97)*970@-%-I+S13:4U8(%!3 M`%Q<1')A9V]N7&AS,0!04T-225!4`$A0($QA4YA;64````*06QE>&ES($)O<@I!;&5X:7,@ M0F]R`````````````-#/$>"AL1KA`````````````````````#L``P#^_PD` M!@```````````````P````$``````````!````(````!````_O___P`````` M````9P```/0```#_____________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ ,________________ ` end From madmin@tandem.com Mon Jan 30 18:48:51 1995 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA11409; Mon, 30 Jan 95 18:48:55 PST Received: from mwunix.mitre.org by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA11403; Mon, 30 Jan 95 18:48:51 PST Return-Path: epg@cutter.mitre.org Received: from gateway.mitre.org (gateway.mitre.org [128.29.31.10]) by mwunix.mitre.org (8.6.9/8.6.4) with SMTP id VAA12513; Mon, 30 Jan 1995 21:48:46 -0500 From: epg@cutter.mitre.org Received: from cutter.mitre.org by gateway.mitre.org (4.1/SMI-4.1) id AA24736; Mon, 30 Jan 95 18:14:35 EST Received: by cutter.mitre.org (4.1/SMI-4.1) id AA27823; Mon, 30 Jan 95 18:11:41 EST Message-Id: <9501302311.AA27823@cutter.mitre.org> To: "Bor, Alexis" Cc: "'xapia-dirsynch'" , epg@cutter.mitre.org Subject: Re: Draft 0.12 of Dir Sync Document Attached In-Reply-To: Your message of Mon, 30 Jan 95 12:55:00 -0800. <2F2D52D5@ct.si.cs.boeing.com> Date: Mon, 30 Jan 95 18:08:47 -0500 Hi, Alexis. Would you consider saving this as Word for Windows 2.0 and resending it. If not, Hoyt has apparently posted a program that may help. Thanks. Ella ----------------------------------------------------------------------------- Ella P. Gardner The MITRE Corporation +1 703 883 5826 +1 703 883 7142 fax epg@gateway.mitre.org ----------------------------------------------------------------------------- From madmin@tandem.com Tue Jan 31 01:55:49 1995 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA19198; Tue, 31 Jan 95 01:56:11 PST Received: from lancaster.nexor.co.uk by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA19191; Tue, 31 Jan 95 01:55:49 PST X400-Received: by /PRMD=NEXOR/ADMD= /C=GB/; Relayed; Tue, 31 Jan 1995 09:54:52 +0000 X400-Received: by mta lancaster.nexor.co.uk in /PRMD=NEXOR/ADMD= /C=GB/; Relayed; Tue, 31 Jan 1995 09:54:52 +0000 Date: Tue, 31 Jan 1995 09:54:52 +0000 X400-Originator: n.cook@nexor.co.uk X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=NEXOR/ADMD= /C=GB/;lancaster.ne:031971:950131095449] Content-Identifier: Problems with se From: Neil Cook Message-Id: <"lancaster.ne:031970:950131095445*/I=n/S=cook/O=NEXOR/PRMD=NEXOR/ADMD= /C=GB/"@MHS> To: xapia-dirsynch Cc: "nick.laszlo" , "c.robbins" , "n.cook" Subject: Problems with sequenceNumber X-Mua-Version: XT-MUA 1.3 (wellington) of Wed Jun 15 10:00:40 BST 1994 I sent a message to this list a few months ago listing a few problems with the 0.6 data format specification. Some of them have been fixed in the new 0.14 spec. However, sequenceNumber is still a PrintableString with the separator ";" (semicolon). This character is (still) not allowed in PrintableString, thus we suggest again that the separator be changed to a : (colon). Has nobody else tried decoding such a file to discover this problem? Also, if you try to load this into a 93 directory, there are access control issues to worry about. If there is no aci information, then nobody will be able to read the data. Will the attribute information contain a relevant access point and related attributes, will the subtree contain the relevant aci subentries? Also I notice a context prefix attribute has been included. We have been using an agreement file in parallel with the xapia file, in order to have enough information to be able to load the data into a directory. Assuming this does not exist, is the dir sync info presumed to be loaded directly under the context prefix? If not, then where does this information come from? Neil. From madmin@tandem.com Tue Jan 31 06:41:13 1995 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA23860; Tue, 31 Jan 95 06:41:18 PST Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA23856; Tue, 31 Jan 95 06:41:13 PST Received: by atc.boeing.com (5.57) id AA20683; Tue, 31 Jan 95 06:45:26 -0800 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2F2E4C3A@ct.si.cs.boeing.com>; Tue, 31 Jan 95 06:42:02 PST From: "Bor, Alexis" To: madmin Cc: epg , 'xapia-dirsynch' Subject: RE: Draft 0.12 of Dir Sync Document Attached Date: Tue, 31 Jan 95 06:40:00 PST Message-Id: <2F2E4C3A@ct.si.cs.boeing.com> Encoding: 37 TEXT X-Mailer: Microsoft Mail V3.0 I have saved the document in word for windows 2.0 format and mailed it to Ella. Rather than bombarding everyone's mailbox with another 166K of data (plus whatever the cost of UUENCODE is), just send me a mail message and I will immediately reply with the 2.0 copy for you. When I get it posted on the server, I will send a message out with the info. Alexis ---------- From: madmin Sent: Monday, January 30, 1995 7:59PM To: Bor, Alexis Cc: 'xapia-dirsynch'; epg Subject: Re: Draft 0.12 of Dir Sync Document Attached Hi, Alexis. Would you consider saving this as Word for Windows 2.0 and resending it. If not, Hoyt has apparently posted a program that may help. Thanks. Ella -------------------------------------------------------------------------- --- Ella P. Gardner The MITRE Corporation +1 703 883 5826 +1 703 883 7142 fax epg@gateway.mitre.org -------------------------------------------------------------------------- --- From madmin@tandem.com Tue Jan 31 07:36:43 1995 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA25159; Tue, 31 Jan 95 07:36:45 PST Received: from blinky.ccmail.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA25154; Tue, 31 Jan 95 07:36:43 PST Received: from smtpgate.ccmail.com by blinky.ccmail.com (4.1/SMI-4.1) id AA29194; Tue, 31 Jan 95 07:38:49 PST Received: from cc:Mail by smtpgate.ccmail.com id AA791566696; Tue, 31 Jan 95 07:31:02 pst Date: Tue, 31 Jan 95 07:31:02 pst From: kirpal_khalsa@ccmail.com Encoding: 31 Text Message-Id: <9500317915.AA791566696@smtpgate.ccmail.com> To: BORA@ct.si.cs.boeing.com Cc: xapia-dirsynch@tandem.com, epg@cutter.mitre.org Subject: Re[2]: Draft 0.12 of Dir Sync Document Attached Ella, Hoyt has posted a program (what program?) that may help (help do what?). And where is the program posted? Regards, Kirpal (ever curious) Khalsa ______________________________ Reply Separator _________________________________ Subject: Re: Draft 0.12 of Dir Sync Document Attached Author: epg@cutter.mitre.org at internet-mail Date: 1/30/95 6:08 PM Hi, Alexis. Would you consider saving this as Word for Windows 2.0 and resending it. If not, Hoyt has apparently posted a program that may help. Thanks. Ella ----------------------------------------------------------------------------- Ella P. Gardner The MITRE Corporation +1 703 883 5826 +1 703 883 7142 fax epg@gateway.mitre.org ----------------------------------------------------------------------------- From madmin@tandem.com Wed Feb 1 08:38:35 1995 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA01972; Wed, 1 Feb 95 08:38:38 PST Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA01966; Wed, 1 Feb 95 08:38:35 PST Received: by atc.boeing.com (5.57) id AA08566; Wed, 1 Feb 95 08:42:51 -0800 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2F2FB93E@ct.si.cs.boeing.com>; Wed, 01 Feb 95 08:39:26 PST From: "Bor, Alexis" To: 'xapia-dirsynch' Subject: Soft Copy of Dir Sync Spec On-Line Date: Wed, 01 Feb 95 08:37:00 PST Message-Id: <2F2FB93E@ct.si.cs.boeing.com> Encoding: 20 TEXT X-Mailer: Microsoft Mail V3.0 Draft 0.12 of the Directory Synchronization Specification has been posted on nemo.ncsl.nist.gov in the directory oiw/dssig/xapia I plan to make this available for comments to the EMA Directory Committee next week in San Diego. The files are: final012.doc - Word for Windows 6.0 final012.ww2 - Word for Windows 2.0 final012.rtf - RTF format If you need a different format, just send me mail and I will do my best to get you a readable copy. Alexis Bor Chair XAPIA Directory Synchronization Technical SubCommittee bora@ct.si.cs.boeing.com From madmin@tandem.com Wed Feb 1 09:26:51 1995 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA03618; Wed, 1 Feb 95 09:27:04 PST Received: from egate.citicorp.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA03601; Wed, 1 Feb 95 09:26:51 PST Received: by egate.citicorp.com id AA03003 (InterLock SMTP Gateway 1.1 for xapia-dirsynch@tandem.com); Wed, 1 Feb 1995 17:26:40 GMT Received: by egate.citicorp.com (Internal Mail Agent-1); Wed, 1 Feb 1995 17:26:40 GMT Date: Wed, 1 Feb 1995 12:26:39 -0500 From: Ray Freiwirth Message-Id: <199502011726.MAA12187@maple.cgin.us-md.citicorp.com> To: xapia-dirsynch@tandem.com Subject: Please subscribe X-Mailer: AIR Mail 3.X (SPRY, Inc.) Please subscribe ray.freiwirth@citicorp.com Please unsubscribe 5241391@mcimail.com thanks, ray From madmin@tandem.com Mon Feb 6 17:49:09 1995 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA23132; Mon, 6 Feb 95 17:49:12 PST Received: from blinky.ccmail.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA23123; Mon, 6 Feb 95 17:49:09 PST Received: from smtpgate.ccmail.com by blinky.ccmail.com (4.1/SMI-4.1) id AA12874; Mon, 6 Feb 95 17:51:17 PST Received: from cc:Mail by smtpgate.ccmail.com id AA792121811; Mon, 06 Feb 95 17:41:25 pst Date: Mon, 06 Feb 95 17:41:25 pst From: kirpal_khalsa@ccmail.com Encoding: 47 Text Message-Id: <9501067921.AA792121811@smtpgate.ccmail.com> To: xapia-dirsynch@tandem.com, Neil Cook Cc: nick.laszlo@nexor.co.uk, c.robbins@nexor.co.uk, n.cook@nexor.co.uk Subject: Re: Problems with sequenceNumber Hi Neil, Has anyone replied yet? Here's my take. Replies thusly: KSK>> Regards, Kirpal Khalsa Lotus Development Corp. ______________________________ Reply Separator _________________________________ Subject: Problems with sequenceNumber Author: Neil Cook at internet-mail Date: 1/31/95 2:01 AM I sent a message to this list a few months ago listing a few problems with the 0.6 data format specification. Some of them have been fixed in the new 0.14 spec. However, sequenceNumber is still a PrintableString with the separator ";" (semicolon). This character is (still) not allowed in PrintableString, thus we suggest again that the separator be changed to a : (colon). Has nobody else tried decoding such a file to discover this problem? KSK>> No reason not to change this that I can think of. Also, if you try to load this into a 93 directory, there are access control issues to worry about. If there is no aci information, then nobody will be able to read the data. Will the attribute information contain a relevant access point and related attributes, will the subtree contain the relevant aci subentries? KSK>> Security's always been a big hole since day one, primarily because we decided not to address it for round1 of the spec. It seems highly unreasonable to require a proprietary email system to adopt X500 access control when exporting directory info. The context prefix was meant to sort of point at an access point/subentry but I don't think we ever got around to really working out the details of how to identify an exporter. There's some wording in the text indicating that we didn't plan to handle access control specifics also. Also I notice a context prefix attribute has been included. We have been using an agreement file in parallel with the xapia file, in order to have enough information to be able to load the data into a directory. Assuming this does not exist, is the dir sync info presumed to be loaded directly under the context prefix? KSK>> Yep, meant to be loaded right under there. If not, then where does this information come from? Neil. From madmin@tandem.com Mon Mar 13 05:36:46 1995 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA13453; Mon, 13 Mar 95 05:36:49 PST Received: from mwunix.mitre.org by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA13448; Mon, 13 Mar 95 05:36:46 PST Return-Path: epg@cutter.mitre.org Received: from gateway.mitre.org (gateway.mitre.org [128.29.31.10]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id IAA22418; Mon, 13 Mar 1995 08:36:16 -0500 From: epg@cutter.mitre.org Received: from cutter.mitre.org by gateway.mitre.org (4.1/SMI-4.1) id AA28435; Mon, 13 Mar 95 08:36:15 EST Received: by cutter.mitre.org (4.1/SMI-4.1) id AA15504; Mon, 13 Mar 95 08:35:30 EST Message-Id: <9503131335.AA15504@cutter.mitre.org> To: dssig@nist.gov, xapia-dirsynch@tandem.com Cc: epg@cutter.mitre.org Subject: OIW/XAPIA Directory Synchronization Paper Date: Mon, 13 Mar 95 08:35:28 -0500 Folks: Will someone who has been participating in the directory Synchronization work please answer Nick's question? Thanks! Ella ----------------------------------------------------------------------------- Ella P. Gardner The MITRE Corporation +1 703 883 5826 +1 703 883 7142 fax epg@gateway.mitre.org ----------------------------------------------------------------------------- ------- Forwarded Message Received: from mwunix.mitre.org by cutter.mitre.org (4.1/SMI-4.1) id AA09535; Thu, 9 Mar 95 15:28:03 EST Return-Path: emery@emery.reo.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id PAA07853 for ; Thu, 9 Mar 1995 15:28:41 -0500 From: emery@emery.reo.dec.com Received: from emery.reo.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA20692; Thu, 9 Mar 95 03:03:38 -0800 Received: from localhost by emery.reo.dec.com (5.65/Ultrix3.0-C) id AA14942; Thu, 9 Mar 1995 11:02:18 GMT Message-Id: <9503091102.AA14942@emery.reo.dec.com> To: epg@cutter.mitre.org Cc: emery@emery.reo.dec.com Subject: OIW/XAPIA Directory Synchronization Paper Date: Thu, 09 Mar 95 11:02:18 +0000 X-Mts: smtp Ella, I have a quick question on the XAPIA Directory Synchronization Specification: Why were the TotalRefresh and IncrementalRefresh datatypes changed from standard DISP? This seems like a bad mistake to make because it means that implemetors have to implement yet another set of encoders/decoders. It would have been far better to use the standard datatypes and state that the components that are not required should be omitted or have standard values. For example, in TotalRefresh, SDSEContent in the standard protocol has been replaced with SET OF Attribute. It would have been better to state that a) encoders always 1) encode sDSEType with no bits set to 1 2) omit subComplete 3) omit attComplete b) decoders always i) ignore sDSEType ii) ignore subCOmplete iii) ignore attComplete - --Nick ------- End of Forwarded Message From madmin@tandem.com Mon Mar 13 07:08:25 1995 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA15366; Mon, 13 Mar 95 07:08:28 PST Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA15362; Mon, 13 Mar 95 07:08:25 PST Received: by atc.boeing.com (5.57) id AA16513; Mon, 13 Mar 95 07:13:08 -0800 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2F64602A@ct.si.cs.boeing.com>; Mon, 13 Mar 95 07:09:30 PST From: "Bor, Alexis" To: 'dssig' , 'xapia-dirsynch' Subject: Need comments on Dir Sync Spec this month Date: Mon, 13 Mar 95 07:05:00 PST Message-Id: <2F64602A@ct.si.cs.boeing.com> Encoding: 12 TEXT X-Mailer: Microsoft Mail V3.0 Everyone, The XAPIA is in the middle of balloting on the Dir Sync spec. I need feedback and/or suggested text changes before the end of the month to make sure that they make it into the spec. So far I have seen comments from Nick Emery of Digital (via Ella Gardner's message) and Nick Lazlo of Nexor. Thanks. Alexis Bor bora@ct.si.cs.boeing.com From madmin@tandem.com Mon Mar 13 08:35:28 1995 Received: by suntan.Tandem.com (4.1/suntan5.940222) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA18205; Mon, 13 Mar 95 08:35:30 PST Received: from blinky.ccmail.com by suntan.Tandem.com (4.1/suntan5.940222) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA18197; Mon, 13 Mar 95 08:35:28 PST Received: from smtpgate.ccmail.com by blinky.ccmail.com (4.1/SMI-4.1) id AA24179; Mon, 13 Mar 95 08:05:09 PST Received: from cc:Mail SMTPLINK 2.1 by smtpgate.ccmail.com id AA795112672; Mon, 13 Mar 95 08:29:48 pst Date: Mon, 13 Mar 95 08:29:48 pst From: "Kirpal Khalsa" Encoding: 27 Text Message-Id: <9502137951.AA795112672@smtpgate.ccmail.com> To: dssig@nist.gov, xapia-dirsynch@tandem.com, "Bor, Alexis" Subject: Re: Need comments on Dir Sync Spec this month Alexis, Are comments being posted somewhere? How are they getting rolled into the document? Regards, Kirpal ______________________________ Reply Separator _________________________________ Subject: Need comments on Dir Sync Spec this month Author: "Bor, Alexis" at internet-mail Date: 3/13/95 7:49 AM Everyone, The XAPIA is in the middle of balloting on the Dir Sync spec. I need feedback and/or suggested text changes before the end of the month to make sure that they make it into the spec. So far I have seen comments from Nick Emery of Digital (via Ella Gardner's message) and Nick Lazlo of Nexor. Thanks. Alexis Bor bora@ct.si.cs.boeing.com From madmin@tandem.com Tue Mar 14 04:42:57 1995 Received: by suntan.Tandem.com (4.1/suntan5.950313) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA22109; Tue, 14 Mar 95 04:43:08 PST Received: from ub-gate.UB.com by suntan.Tandem.com (4.1/suntan5.950313) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA22100; Tue, 14 Mar 95 04:42:57 PST Received: from lancaster.nexor.co.uk by ub-gate.UB.com (4.1/SMI-4.1[UB-1.9.1]) id AA03064; Tue, 14 Mar 95 04:41:02 PST X400-Received: by /PRMD=NEXOR/ADMD= /C=GB/; Relayed; Tue, 14 Mar 1995 09:51:41 +0000 X400-Received: by mta lancaster.nexor.co.uk in /PRMD=NEXOR/ADMD= /C=GB/; Relayed; Tue, 14 Mar 1995 09:51:41 +0000 Date: Tue, 14 Mar 1995 09:51:41 +0000 X400-Originator: n.cook@nexor.co.uk X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=NEXOR/ADMD= /C=GB/;lancaster.ne:108801:950314095140] Content-Identifier: Re: OIW/XAPIA Di From: Neil Cook Message-Id: <"lancaster.ne:108800:950314095140*/I=n/S=cook/O=NEXOR/PRMD=NEXOR/ADMD= /C=GB/"@MHS> To: epg Cc: xapia-dirsynch , dssig , epg In-Reply-To: <9503131335.AA15504@cutter.mitre.org> Subject: Re: OIW/XAPIA Directory Synchronization Paper X-Mua-Version: XT-MUA 1.3 (wellington) of Wed Jun 15 10:00:40 BST 1994 In your message you said: > Folks: > > Will someone who has been participating in the directory Synchronization > work please answer Nick's question? >
> Ella, I have a quick question on the XAPIA Directory Synchronization > Specification: Why were the TotalRefresh and IncrementalRefresh > datatypes changed from standard DISP? > > This seems like a bad mistake to make because it means that implemetors > have to implement yet another set of encoders/decoders. It would have I don't really think this is an issue. It took me about 1/2 a day to do this. More annoying is the fact that it *does* use some DISP data types, and thus you end up mixing and matching the two. This lead to me changing the names of the data types which had the same name as in X.525, but were different. Surely it would be better to rename them, e.g. XapiaTotalRefresh. This at least would clarify things. > been far better to use the standard datatypes and state that the > components that are not required should be omitted or have standard values. > > For example, in TotalRefresh, SDSEContent in the standard protocol > has been replaced with SET OF Attribute. It would have been better to > state that > a) encoders always > 1) encode sDSEType with no bits set to 1 > 2) omit subComplete > 3) omit attComplete > b) decoders always > i) ignore sDSEType > ii) ignore subCOmplete > iii) ignore attComplete The point is that, even though they are omitted in the XAPIA format, if you actually want to send the information over DISP, you have to perform the exact steps above, i.e. fill in sensible defaults for sDSEType, subcomplete etc. This is particularly difficult for the area prefix information. Also, I am extremely unhappy with the way that contextPrefix has been shoved into the spec, seemingly on a whim. We have implemented xapia 0.6, and we used a separate shadowing agreement file to specify all the parameters such as where the info will be loaded into the DIT, which DSA to contact etc. Using contextPrefix in this way is extremely heavy handed, and a bit of a bodge. It only allows you to load the info directly under the contextPrefix, which is unsatisfactory. What if you wanted to load the info at a point further below the contextPrefix? If you only have the contextPrefix to separate between area prefix and area information, this is not possible. Also, a question which has been bugging me is this; are mail programs such as CCMail etc. expected to produce XAPIA files? Having them know about the area prefix info, and having to fill in the xapia informaion for this seems somewhat... ambitious. The question is; should the xapia file contain area prefix info at all? This limits the file's scope to a certain place in the DIT, and places a burden on the creator of the file to have detailed knowledge about where the file is going to be placed. If I have misunderstood any of this, then feel free to correct me, but from my experience, these are important issues. If the effort of creating XAPIA files is too much, will people bother with them? We have defined a text-format file whiich we use in a similar way to xapia's intended use. We find it much more flexible, because it contains no area prefix info - this is filled in with sensible defaults by the loader. This seems to be a much more sensible and flexible approach. It really seems that XAPIA was simply copied from DISP, and only afterwards was much thought put into seeing where it was deficient. We have implemented xapia 0.6 for example, and found that the hardest part was generating files that we could use. They contain so much context specific info, that it is impossible to reuse a file containing e.g. employee telephone numbers. That is why we developed a text format, in conjunction with an agreement file. The agreement file can change, but you can reuse the information in the text file. Maybe an automatic text-xapia converter would be useful? Neil. From madmin@tandem.com Tue Mar 14 07:30:14 1995 Received: by suntan.Tandem.com (4.1/suntan5.950313) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA25614; Tue, 14 Mar 95 07:30:18 PST Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.950313) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA25610; Tue, 14 Mar 95 07:30:14 PST Received: by atc.boeing.com (5.57) id AA08805; Tue, 14 Mar 95 07:34:57 -0800 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2F65B6C6@ct.si.cs.boeing.com>; Tue, 14 Mar 95 07:31:18 PST From: "Bor, Alexis" To: dssig , Kirpal Khalsa , xapia-dirsynch Subject: RE: Need comments on Dir Sync Spec this month Date: Tue, 14 Mar 95 07:27:00 PST Message-Id: <2F65B6C6@ct.si.cs.boeing.com> Encoding: 54 TEXT X-Mailer: Microsoft Mail V3.0 I am collecting all the comments and will build a single summarized posting of the comments. At that point, I will solicit any necessary text changes to the spec and we will update it. In any of your comments to the spec, it would be extremely helpful if you could propose the wording changes to the spec as well. This will help speed the process. Thanks a lot... Alexis ---------- From: Kirpal Khalsa Sent: Monday, March 13, 1995 8:44AM To: Bor, Alexis; dssig; xapia-dirsynch Subject: Re: Need comments on Dir Sync Spec this month Alexis, Are comments being posted somewhere? How are they getting rolled into the document? Regards, Kirpal ______________________________ Reply Separator _________________________________ Subject: Need comments on Dir Sync Spec this month Author: "Bor, Alexis" at internet-mail Date: 3/13/95 7:49 AM Everyone, The XAPIA is in the middle of balloting on the Dir Sync spec. I need feedback and/or suggested text changes before the end of the month to make sure that they make it into the spec. So far I have seen comments from Nick Emery of Digital (via Ella Gardner's message) and Nick Lazlo of Nexor. Thanks. Alexis Bor bora@ct.si.cs.boeing.com From madmin@tandem.com Wed Mar 15 10:05:00 1995 Received: by suntan.Tandem.com (4.1/suntan5.950313) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA10574; Wed, 15 Mar 95 10:05:03 PST Received: from blinky.ccmail.com by suntan.Tandem.com (4.1/suntan5.950313) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA10567; Wed, 15 Mar 95 10:05:00 PST Received: from smtpgate.ccmail.com by blinky.ccmail.com (4.1/SMI-4.1) id AA18105; Wed, 15 Mar 95 10:05:28 PST Received: from ccMail SMTPLINK 2.1 by smtpgate.ccmail.com id AA795290838; Wed, 15 Mar 95 09:57:29 pst Date: Wed, 15 Mar 95 09:57:29 pst From: "Kirpal Khalsa" Encoding: 108 Text Message-Id: <9502157952.AA795290838@smtpgate.ccmail.com> To: dssig@nist.gov, xapia-dirsynch@tandem.com Cc: epg@cutter.mitre.org Subject: Re: OIW/XAPIA Directory Synchronization Paper As I recall the choice was to use terminology in the NADF documents that were based on earlier drafts of X500(93) or to use the terminolgy in the DISP documents. The other issue we were addressing related to expressed concerns on the part of non-X500 proprietary mail and dir-synch vendors regarding the overhead and complexity of extensive use of ASN.1 (in some cases, fear and loathing of ASN.1). So simplifying the ASN.1 was seen as a big win and making clear that it was different from DISP (you don't need a DSA to do XAPIA DirSynch) was also a big win in potentially motivating large proprietary email vendors (wonder who they might be?) to migrate their Directory export capabilities directly to the XAPIA format. Audience of implementors was seen to be: proprietary email vendors, X400 vendors (it is XAPIA, right?), proprietary dirSynch/email (I like the h) vendors, and X500 vendors. Ignoring the needs of the entire audience in preference for an X500-specific solution will provide a window of opportunity for gateway/dirSynch/X500 vendors but might have the nasty side-effect of making the spec irrelevant. If you look at the models, the architecture was meant to work in environments that have X500 DSAs in them and environments that don't have X500 DSAs in them. X500 was not envisioned as the center of the DirSynch universe. X500 was seen as yet another Directory. In the non-X500 environment, some directories are hierarchical and many are flat. In a flat directory space, how useful is a DSE? Also, a lot of issues addressed by X500 attributes regarding master/shadow and complete/non-complete records is irrelevant for many flat directories. The concept of an agent interfacing between Directories and the virtual DirSynch space was there to allow mappings to different directory environments. Is that useful as a backgrounder? More if you need it. Mark messages urgent (in attribute and subject line) if you need rapid response, I'm suffering from severe email/work overload. Regards, Kirpal ______________________________ Reply Separator _________________________________ Subject: OIW/XAPIA Directory Synchronization Paper Author: epg@cutter.mitre.org at internet-mail Date: 3/13/95 6:12 AM Folks: Will someone who has been participating in the directory Synchronization work please answer Nick's question? Thanks! Ella ----------------------------------------------------------------------------- Ella P. Gardner The MITRE Corporation +1 703 883 5826 +1 703 883 7142 fax epg@gateway.mitre.org ----------------------------------------------------------------------------- ------- Forwarded Message Received: from mwunix.mitre.org by cutter.mitre.org (4.1/SMI-4.1) id AA09535; Thu, 9 Mar 95 15:28:03 EST Return-Path: emery@emery.reo.dec.com Received: from inet-gw-3.pa.dec.com (inet-gw-3.pa.dec.com [16.1.0.33]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id PAA07853 for ; Thu, 9 Mar 1995 15:28:41 -0500 >From: emery@emery.reo.dec.com Received: from emery.reo.dec.com by inet-gw-3.pa.dec.com (5.65/24Feb95) id AA20692; Thu, 9 Mar 95 03:03:38 -0800 Received: from localhost by emery.reo.dec.com (5.65/Ultrix3.0-C) id AA14942; Thu, 9 Mar 1995 11:02:18 GMT Message-Id: <9503091102.AA14942@emery.reo.dec.com> To: epg@cutter.mitre.org Cc: emery@emery.reo.dec.com Subject: OIW/XAPIA Directory Synchronization Paper Date: Thu, 09 Mar 95 11:02:18 +0000 X-Mts: smtp Ella, I have a quick question on the XAPIA Directory Synchronization Specification: Why were the TotalRefresh and IncrementalRefresh datatypes changed from standard DISP? This seems like a bad mistake to make because it means that implemetors have to implement yet another set of encoders/decoders. It would have been far better to use the standard datatypes and state that the components that are not required should be omitted or have standard values. For example, in TotalRefresh, SDSEContent in the standard protocol has been replaced with SET OF Attribute. It would have been better to state that a) encoders always 1) encode sDSEType with no bits set to 1 2) omit subComplete 3) omit attComplete b) decoders always i) ignore sDSEType ii) ignore subCOmplete iii) ignore attComplete - --Nick ------- End of Forwarded Message From madmin@tandem.com Wed Mar 15 10:36:35 1995 Received: by suntan.Tandem.com (4.1/suntan5.950313) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA11942; Wed, 15 Mar 95 10:36:38 PST Received: from blinky.ccmail.com by suntan.Tandem.com (4.1/suntan5.950313) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA11936; Wed, 15 Mar 95 10:36:35 PST Received: from smtpgate.ccmail.com by blinky.ccmail.com (4.1/SMI-4.1) id AA19030; Wed, 15 Mar 95 10:35:26 PST Received: from ccMail SMTPLINK 2.1 by smtpgate.ccmail.com id AA795292639; Wed, 15 Mar 95 10:27:05 pst Date: Wed, 15 Mar 95 10:27:05 pst From: "Kirpal Khalsa" Encoding: 125 Text Message-Id: <9502157952.AA795292639@smtpgate.ccmail.com> To: epg@cutter.mitre.org, Neil Cook Cc: xapia-dirsynch@tandem.com, dssig@nist.gov Subject: Re[2]: OIW/XAPIA Directory Synchronization Paper replies KSK>> ______________________________ Reply Separator _________________________________ Subject: Re: OIW/XAPIA Directory Synchronization Paper Author: Neil Cook at internet-mail Date: 3/14/95 5:56 AM In your message you said: > Folks: > > Will someone who has been participating in the directory Synchronization > work please answer Nick's question? >
> Ella, I have a quick question on the XAPIA Directory Synchronization > Specification: Why were the TotalRefresh and IncrementalRefresh > datatypes changed from standard DISP? > > This seems like a bad mistake to make because it means that implemetors > have to implement yet another set of encoders/decoders. It would have I don't really think this is an issue. It took me about 1/2 a day to do this. More annoying is the fact that it *does* use some DISP data types, and thus you end up mixing and matching the two. This lead to me changing the names of the data types which had the same name as in X.525, but were different. Surely it would be better to rename them, e.g. XapiaTotalRefresh. This at least would clarify things. KSK>> we used the names in the NADF spec which was from an early rendition of X.525, correct? > been far better to use the standard datatypes and state that the > components that are not required should be omitted or have standard values. > > For example, in TotalRefresh, SDSEContent in the standard protocol > has been replaced with SET OF Attribute. It would have been better to > state that > a) encoders always > 1) encode sDSEType with no bits set to 1 > 2) omit subComplete > 3) omit attComplete > b) decoders always > i) ignore sDSEType > ii) ignore subCOmplete > iii) ignore attComplete The point is that, even though they are omitted in the XAPIA format, if you actually want to send the information over DISP, you have to perform the exact steps above, i.e. fill in sensible defaults for sDSEType, subcomplete etc. This is particularly difficult for the area prefix information. KSK>> X500 was treated in the model as a Directory type, in the same vein as proprietary and de facto standard directories. The pain was meant to be dealt with in the agents that sit between Directory implementations and the DirSynch space. Also, I am extremely unhappy with the way that contextPrefix has been shoved into the spec, seemingly on a whim. We have implemented xapia 0.6, and we used a separate shadowing agreement file to specify all the parameters such as where the info will be loaded into the DIT, which DSA to contact etc. Using contextPrefix in this way is extremely heavy handed, and a bit of a bodge. It only allows you to load the info directly under the contextPrefix, which is unsatisfactory. What if you wanted to load the info at a point further below the contextPrefix? If you only have the contextPrefix to separate between area prefix and area information, this is not possible. KSK>>Good point (I'm not sure about "a whim" but that probably captures the spirit, whimsical might be more apt). Couldn't this be handled in an agent? Also, a question which has been bugging me is this; are mail programs such as CCMail etc. expected to produce XAPIA files? Having them know about the area prefix info, and having to fill in the xapia informaion for this seems somewhat... ambitious. The question is; should the xapia file contain area prefix info at all? This limits the file's scope to a certain place in the DIT, and places a burden on the creator of the file to have detailed knowledge about where the file is going to be placed. KSK>> Once the file format settles then CCMail can contemplate migrating ADE (and Export) natively or via a translation (think installed base of 6.5 million users) agent to this format. Possibilites are there regarding Notes as well. If I have misunderstood any of this, then feel free to correct me, but from my experience, these are important issues. KSK>>Absolutely. If the effort of creating XAPIA files is too much, will people bother with them? KSK>> Probably not. We had to balance considerations of simple flat directories with X500 strategic directions. We have defined a text-format file whiich we use in a similar way to xapia's intended use. KSK>> We had debates about whether to go text based or use ASN.1. Every DSSIG mtg we moved to ASN.1, every non-DSSIG meeting we revisited text-based. We find it much more flexible, because it contains no area prefix info - this is filled in with sensible defaults by the loader. This seems to be a much more sensible and flexible approach. It really seems that XAPIA was simply copied from DISP, and only afterwards was much thought put into seeing where it was deficient. KSK>> We copied NADF, which copied an early version of DISP. Area prefix info was added with X500 in mind. If it doesn't work, drop it. We have implemented xapia 0.6 for example, and found that the hardest part was generating files that we could use. They contain so much context specific info, that it is impossible to reuse a file containing e.g. employee telephone numbers. That is why we developed a text format, in conjunction with an agreement file. The agreement file can change, but you can reuse the information in the text file. Maybe an automatic text-xapia converter would be useful? KSK>> very useful. Neil. Regards, Kirpal From madmin@tandem.com Thu Mar 16 06:19:11 1995 Received: by suntan.Tandem.com (4.1/suntan5.950313) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA14150; Thu, 16 Mar 95 06:19:15 PST Received: from gw1.att.com by suntan.Tandem.com (4.1/suntan5.950313) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA14145; Thu, 16 Mar 95 06:19:11 PST Received: from arch4.ho.att.com by ig1.att.att.com id AA21560; Thu, 16 Mar 95 09:19:44 EST Received: by arch4.ho.att.com (4.1/EMS-1.2 GIS) id AA08906; Thu, 16 Mar 95 09:18:54 EST Date: Thu, 16 Mar 95 09:18:54 EST Message-Id: <9503161418.AA08906@arch4.ho.att.com> From: capple@arch4.ho.att.com (Christopher Walon Apple) To: Kirpal Khalsa , epg@cutter.mitre.org, Neil Cook Cc: xapia-dirsynch@tandem.com, dssig@nist.gov Subject: Re: Re[2]: OIW/XAPIA Directory Synchronization Paper Given that the sync spec specifies only a file format and indicates that all other synchronization-related technology can be proprietary, I question its utility during the development of inter-enterprise directory synchronization tools. My belief (that you will probably disagree with me is not in question) is that directory synchronization should be treated as a service with an API defined such that a library of synchronization-related functions could be used by DSA's (and here, I mean the logical concept of a directory service agent, not necessarily the X.500 DSA). Currently, the specification reminds me of the way that we might have performed synchronization a few years ago. I suppose it is possible that the intention in writing the spec the way that it has been, is, quite specifically, to keep synchronization functionality within the very entities that require it. This seems a bit short-sighted to me, given that this synchronization spec should more likely be developed as a stepping stone to and a systems integration tool for designing synchronizable directory service systems from (currently) incompatible directory technology. I think that this spec should have a shelf-life of approximately five years (the point at which I think we may begin to see some unification of various and sundry directory schemas). Since proprietary technology is often difficult to integrate into systems for which it was not expressly designed, the thought of implemetors building synchronization technology based on proprietary concepts, really scares me. This could create an interoperability nightmare. If the intention is to eventually extend the scope of this sync spec into the areas that are currently delcared as proprietary and sacred, then I apologize for the criticism. I just felt that this extension should have been made before we moved so close to the closing date for the spec. Chris Apple AT&T Bell Laboratories capple@arch4.ho.att.com From madmin@tandem.com Thu Mar 16 08:03:31 1995 Received: by suntan.Tandem.com (4.1/suntan5.950313) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA16926; Thu, 16 Mar 95 08:03:34 PST Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.950313) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA16920; Thu, 16 Mar 95 08:03:31 PST Received: by atc.boeing.com (5.57) id AA04472; Thu, 16 Mar 95 08:08:13 -0800 Received: by ct.si.cs.boeing.com with Microsoft Mail id <2F686192@ct.si.cs.boeing.com>; Thu, 16 Mar 95 08:04:34 PST From: "Bor, Alexis" To: capple , epg , Kirpal Khalsa , Neil Cook Cc: dssig , xapia-dirsynch Subject: RE: Re[2]: OIW/XAPIA Directory Synchronization Paper Date: Thu, 16 Mar 95 08:00:00 PST Message-Id: <2F686192@ct.si.cs.boeing.com> Encoding: 85 TEXT X-Mailer: Microsoft Mail V3.0 Chris, The initial intent of the work was to provide a common format for the exchange of directory information. You may want to review the the minutes and output from the June 1993 OIW DSSIG meeting as for the perspective of the DSSIG. The DSSIG sent a liason to a joint meeting of the EMA and XAPIA that was held the following week in Atlanta. From the viewpoint of the XAPIA, we had certain requirements that we were trying to meet. Here is a brief summary of them: 1. It had to be very simple so that vendors would not have to modify their mainline products, but just be able to build an import/export facility. This would make it possible to build the import/export tools without shipping a new version of their software. 2. The development of the spec had to be done within one year. The group felt that the need was urgent and that those uses planning to go to X.500 needed an interim solution. It was felt that an API effort would have taken at least twice as long, and most companies weren't ready to commit people beyond 1994 for the development of the spec. The lifetime of the spec was anticipated to peak within 3 years of the start of the work, with certain legacy systems continuing for an indefinite amount of time. 3. The specification had to implementable in environments that are not using X.500 as well as between two or more non-connected X.500 Directories. 4. Some people were concerned that the development of an API would have made it into very few products - we had no vendor commitments or interest in this approach. If there is enough interest in an Dir Sync API and people are willing to devote a significant amount of time to developing a spec, then I think we should discuss that and see what we can do. Alexis Bor Chair, XAPIA Directory Sync Committee bora@ct.si.cs.boeing.com ---------- From: capple Sent: Thursday, March 16, 1995 6:24AM To: Kirpal Khalsa; epg; Neil Cook Cc: xapia-dirsynch; dssig Subject: Re: Re[2]: OIW/XAPIA Directory Synchronization Paper Given that the sync spec specifies only a file format and indicates that all other synchronization-related technology can be proprietary, I question its utility during the development of inter-enterprise directory synchronization tools. My belief (that you will probably disagree with me is not in question) is that directory synchronization should be treated as a service with an API defined such that a library of synchronization-related functions could be used by DSA's (and here, I mean the logical concept of a directory service agent, not necessarily the X.500 DSA). Currently, the specification reminds me of the way that we might have performed synchronization a few years ago. I suppose it is possible that the intention in writing the spec the way that it has been, is, quite specifically, to keep synchronization functionality within the very entities that require it. This seems a bit short-sighted to me, given that this synchronization spec should more likely be developed as a stepping stone to and a systems integration tool for designing synchronizable directory service systems from (currently) incompatible directory technology. I think that this spec should have a shelf-life of approximately five years (the point at which I think we may begin to see some unification of various and sundry directory schemas). Since proprietary technology is often difficult to integrate into systems for which it was not expressly designed, the thought of implemetors building synchronization technology based on proprietary concepts, really scares me. This could create an interoperability nightmare. If the intention is to eventually extend the scope of this sync spec into the areas that are currently delcared as proprietary and sacred, then I apologize for the criticism. I just felt that this extension should have been made before we moved so close to the closing date for the spec. Chris Apple AT&T Bell Laboratories capple@arch4.ho.att.com From madmin@tandem.com Wed Apr 26 14:45:06 1995 Received: by suntan.Tandem.com (4.1/suntan5.950313) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA17161; Wed, 26 Apr 95 14:45:09 PDT Received: from newsun.Novell.COM by suntan.Tandem.com (4.1/suntan5.950313) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA17157; Wed, 26 Apr 95 14:45:06 PDT Received: from ca.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA01259; Wed, 26 Apr 95 14:45:05 PDT Received: by ca.SJF.Novell.COM (4.1/SMI-4.1) id AA26603; Wed, 26 Apr 95 14:45:05 PDT Date: Wed, 26 Apr 95 14:45:05 PDT From: Bruce_Greenblatt@novell.com (Bruce Greenblatt) Message-Id: <9504262145.AA26603@ca.SJF.Novell.COM> To: xapia-dirsynch@tandem.com Subject: dirsynch recommendation status What is the current status of the Dirsynch recommendation? When does it get voted on by the executive committee? Thanks, Bruce Greenblatt ============================================== Bruce Greenblatt bgg@novell.com Messaging Products Group (408) 577-7688 Novell, Inc. Prodigy: GSWF67A ============================================== From madmin@tandem.com Fri Apr 28 14:40:11 1995 Received: by suntan.Tandem.com (4.1/suntan5.950313) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA09903; Fri, 28 Apr 95 14:40:14 PDT Received: from newsun.Novell.COM by suntan.Tandem.com (4.1/suntan5.950313) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA09899; Fri, 28 Apr 95 14:40:11 PDT Received: from ca.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA12808; Fri, 28 Apr 95 14:40:03 PDT Received: by ca.SJF.Novell.COM (4.1/SMI-4.1) id AA14954; Fri, 28 Apr 95 14:40:01 PDT Date: Fri, 28 Apr 95 14:40:01 PDT From: Bruce_Greenblatt@novell.com (Bruce Greenblatt) Message-Id: <9504282140.AA14954@ca.SJF.Novell.COM> To: xapia-dirsynch@tandem.com Subject: dirsynch recommendation statu Is there anybody out there???? > Date: Wed, 26 Apr 95 14:45:05 PDT > From: Bruce_Greenblatt@Novell.COM (Bruce Greenblatt) > Message-Id: <9504262145.AA26603@ca.SJF.Novell.COM> > To: xapia-dirsynch@tandem.com > Subject: dirsynch recommendation status > Status: RO > > > What is the current status of the Dirsynch recommendation? When does it > get voted on by the executive committee? > > Thanks, > > Bruce Greenblatt > > From madmin@tandem.com Tue May 2 11:30:06 1995 Received: by suntan.Tandem.com (4.1/suntan5.950313) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA04544; Tue, 2 May 95 11:30:12 PDT Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.950313) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA04533; Tue, 2 May 95 11:30:06 PDT Received: by atc.boeing.com (5.57) id AA17795; Tue, 2 May 95 11:35:13 -0700 Received: by ct.si.cs.boeing.com with NT SMTP Gateway ver 31 id <2FA6799E@ct.si.cs.boeing.com>; Tue, 02 May 95 11:27:42 P From: "Bor, Alexis" To: madmin , xapia-dirsynch Subject: RE: dirsynch recommendation status Date: Tue, 02 May 95 12:27:00 P Message-Id: <2FA6799E@ct.si.cs.boeing.com> Encoding: 43 TEXT X-Mailer: Microsoft Mail V3.0 I am in the process of compiling all of the review comments and plan to distribute them in New Orleans during the EMA week. We have an XAPIA executive board meeting where I will review the results. If people are going to be in New Orleans, I would be very happy to review the doc. The best time is Sunday afternoon and I have a room available for it. Please let me know if you plan to meet with me. Have people been having trouble getting mail? I only saw your mail from MADMIN and nowhere else... Alexis Bor Boeing Information & Support Services bora@bcs-rt.boeing.com (206) 865-3631 ---------- From: madmin Sent: Friday, April 28, 1995 2:40PM To: xapia-dirsynch Subject: dirsynch recommendation statu Is there anybody out there???? > Date: Wed, 26 Apr 95 14:45:05 PDT > From: Bruce_Greenblatt@Novell.COM (Bruce Greenblatt) > Message-Id: <9504262145.AA26603@ca.SJF.Novell.COM> > To: xapia-dirsynch@tandem.com > Subject: dirsynch recommendation status > Status: RO > > > What is the current status of the Dirsynch recommendation? When does it > get voted on by the executive committee? > > Thanks, > > Bruce Greenblatt > > From madmin@tandem.com Tue Jun 13 16:03:51 1995 Received: by suntan.Tandem.com (4.1/suntan5.950313) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA08265; Tue, 13 Jun 95 16:04:35 PDT Received: from newsun.Novell.COM by suntan.Tandem.com (4.1/suntan5.950313) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA08234; Tue, 13 Jun 95 16:03:51 PDT Received: from ca.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA01351; Tue, 13 Jun 95 16:03:49 PDT Received: by ca.SJF.Novell.COM (4.1/SMI-4.1) id AA08274; Tue, 13 Jun 95 16:03:41 PDT Date: Tue, 13 Jun 95 16:03:41 PDT From: Bruce_Greenblatt@novell.com (Bruce Greenblatt) Message-Id: <9506132303.AA08274@ca.SJF.Novell.COM> To: bora@ct.si.cs.boeing.com, xapia-dirsynch@tandem.com Subject: XAPIA Directory Synchronization Recommendation Cc: bgg@ca.sjf.novell.com, ed.owens@esltd.com, ed_reed@novell.com, lebeck_sue@tandem.com I've not yet seen the ballot for the directory synchronization recommendation, but I have reviewed the latest copy that is available and I have the following comments. Note that (to me at least) the comments are serious enough to warrant disapproval from Novell during the ballotting (sp?). So, here we go... Here are some comments/reactions. 1) This isn't X.500 (1993) DISP. Why not? What's the rationale that lead to the choice to develop a new protocol? This may be covered in the archives of the working group, but it should be addressed directly in the specification itself. 2) In the definition DomainName ::= CHOICE {Printable String, T61String} - it is not acceptable to Novell for the CHOICE to not include Unicode as one of the choices... can be expressed as BMPString, or UniversalString with subtype of the 16 bit characters from the Basic Multilingual Plan as described in ISO 10646. FYI - BMPString == the 16 bit BMP of ISO 10646 == Unicode. This requirement should be placed on ALL string and distinguished name types. Another way this might be addressed is by explicitly including Name and other attributes from the 1993 versions of the X.500 InformationFramework module...that should satisfy our need to have Unicode String attributes supported. 3) Novell's recommendation would be that only public readable attributes be eligable for synchronization...unless some really trusted mechanism for enforcing our ACL information (requiring that the extract file itself be encrypted, I would think, to preclude unconstrained access to controlled attributes being exchanged) is available in the foreign directory service with which the exchange is being conducted. I'd like to see the draft discuss access control issues at more length...but would simply enforce the rule that an extract process running against a directory like X.500 or NDS will only have access to attributes which are readable by the user whose identity the process is running with. Does this make sense? ============================================== Bruce Greenblatt bgg@novell.com Messaging Products Group (408) 577-7688 Novell, Inc. Prodigy: GSWF67A ============================================== From madmin@tandem.com Wed Jun 14 08:22:34 1995 Received: by suntan.Tandem.com (4.1/suntan5.950313) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA01088; Wed, 14 Jun 95 08:22:38 PDT Received: from atc.boeing.com by suntan.Tandem.com (4.1/suntan5.950313) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA01082; Wed, 14 Jun 95 08:22:34 PDT Received: by atc.boeing.com (5.57) id AA20303; Wed, 14 Jun 95 08:30:46 -0700 Received: by ct.si.cs.boeing.com with NT SMTP Gateway ver 31 id <2FDEFE14@ct.si.cs.boeing.com>; Wed, 14 Jun 95 08:19:48 P From: "Bor, Alexis" To: Bruce_Greenblatt , xapia-dirsynch Cc: bgg , "ed.owens" , ed_reed , lebeck_sue Subject: RE: XAPIA Directory Synchronization Recommendation Date: Wed, 14 Jun 95 09:18:00 P Message-Id: <2FDEFE14@ct.si.cs.boeing.com> Encoding: 107 TEXT X-Mailer: Microsoft Mail V3.0 Bruce, Here are some replies to your comments. 1. This is not DISP protocol. If fact, this is just a flat file format specification. We spent a lot of time working with the X.500 SIG at the OIW to see if DISP could be used. There were both technical and business reasons that it was rejected. The idea of the format is to allow any two disparate directory systems to exchange data. There is no requirement that you have X.500 as one of your directories - and some vendors were very insistent on this, including Tandem, Lotus and HP. Most people came to the consensus that a simple utility can be developed to handle this that would not require an update to their product. This was very important. To implement DISP is a significant technical challenge that many Email vendors did not have resources for. It is also a lot of code for something that is considered an interim solution to help people migrate to a common directory service. 2. We can easily add UNICODE support as one of the options. This is a good idea. 3. The format is flexible enough that it can support both. It is really an issue for the two synchroniztion partners to determine local sync policies. I expect that over time that these dir sync files will be sent with digital signature via an email and some message enabled application will process them. I sent the latest 'balloting' draft to Ed a few weeks ago, but in my group we had a major mail burp and this may have been one of the messages that got lost. I will add the optional UNICODE suggestion to the spec in the next day or so and resend it to Ed. If anyone has any concerns about this one, please let me know ASAP. Thanks. Alexis Bor Boeing Information & Support Services Alexis.Bor@iss-rt.boeing.com (206) 865-3631 (206) 865-6903 (FAX) ---------- From: Bruce_Greenblatt Sent: Tuesday, June 13, 1995 4:03PM To: bora; xapia-dirsynch Cc: bgg; ed.owens; ed_reed; lebeck_sue Subject: XAPIA Directory Synchronization Recommendation I've not yet seen the ballot for the directory synchronization recommendation, but I have reviewed the latest copy that is available and I have the following comments. Note that (to me at least) the comments are serious enough to warrant disapproval from Novell during the ballotting (sp?). So, here we go... Here are some comments/reactions. 1) This isn't X.500 (1993) DISP. Why not? What's the rationale that lead to the choice to develop a new protocol? This may be covered in the archives of the working group, but it should be addressed directly in the specification itself. 2) In the definition DomainName ::= CHOICE {Printable String, T61String} - it is not acceptable to Novell for the CHOICE to not include Unicode as one of the choices... can be expressed as BMPString, or UniversalString with subtype of the 16 bit characters from the Basic Multilingual Plan as described in ISO 10646. FYI - BMPString == the 16 bit BMP of ISO 10646 == Unicode. This requirement should be placed on ALL string and distinguished name types. Another way this might be addressed is by explicitly including Name and other attributes from the 1993 versions of the X.500 InformationFramework module...that should satisfy our need to have Unicode String attributes supported. 3) Novell's recommendation would be that only public readable attributes be eligable for synchronization...unless some really trusted mechanism for enforcing our ACL information (requiring that the extract file itself be encrypted, I would think, to preclude unconstrained access to controlled attributes being exchanged) is available in the foreign directory service with which the exchange is being conducted. I'd like to see the draft discuss access control issues at more length...but would simply enforce the rule that an extract process running against a directory like X.500 or NDS will only have access to attributes which are readable by the user whose identity the process is running with. Does this make sense? ============================================== Bruce Greenblatt bgg@novell.com Messaging Products Group (408) 577-7688 Novell, Inc. Prodigy: GSWF67A ============================================== From madmin@tandem.com Fri Jun 23 10:19:35 1995 Received: by suntan.Tandem.com (4.1/suntan5.950313) for /home/suntan/ftp/xapia-dirsynch/mailing-list/current id AA06708; Fri, 23 Jun 95 10:19:38 PDT Received: from newsun.Novell.COM by suntan.Tandem.com (4.1/suntan5.950313) for /usr/lib/sendmail -odb -oi -fmadmin xapia-dirsynch-relay id AA06700; Fri, 23 Jun 95 10:19:35 PDT Received: from ca.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1) id AA18271; Fri, 23 Jun 95 10:19:20 PDT Received: by ca.SJF.Novell.COM (4.1/SMI-4.1) id AA09055; Fri, 23 Jun 95 10:19:18 PDT Date: Fri, 23 Jun 95 10:19:18 PDT From: Bruce_Greenblatt@novell.com (Bruce Greenblatt) Message-Id: <9506231719.AA09055@ca.SJF.Novell.COM> To: xapia-dirsynch@tandem.com Subject: RE: XAPIA Directory Synchronization Recommendation Alexis, Thanks for your fast response to my comments of last week. I'm certainly glad to see that we will at least see Unicode as an option. I didn't really follow all of the arguments against using DISP, or a DISPish protocol in a file, as the directory synchronization standard. Since there were some business reasons for this compromise, does anyone out there wnat to announce release dates for the support of this protocol in their products, or at least semi-commit to its near term support. If not, then the business reasons for the compromise are, in a nutshell, bogus. Bruce ============================================== Bruce Greenblatt bgg@novell.com Messaging Products Group (408) 577-7688 Novell, Inc. Prodigy: GSWF67A ============================================== From chandras@loc201.tandem.com Thu Sep 12 19:14:34 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id TAA15557; Thu, 12 Sep 1996 19:14:34 -0700 Received: from nova.unix.portal.com by suntan.tandem.com (8.6.12/suntan5.960905) for id TAA15548; Thu, 12 Sep 1996 19:14:32 -0700 Received: from jobe.shell.portal.com (jobe.shell.portal.com [156.151.3.4]) by nova.unix.portal.com (8.6.11/8.6.5) with ESMTP id TAA17596; Thu, 12 Sep 1996 19:12:23 -0700 Received: from localhost (dwm@localhost) by jobe.shell.portal.com (8.6.11/8.6.5) with SMTP id TAA28452; Thu, 12 Sep 1996 19:11:58 -0700 Date: Thu, 12 Sep 1996 19:11:58 -0700 (PDT) From: "David W. Morris" To: "Hamilton, Ed @ OTT" cc: chandras , ietf-pkix Subject: Re: Off topic - DLL security In-Reply-To: <32382AD0@monsmtp.esc.lmco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 12 Sep 1996, Hamilton, Ed @ OTT wrote: > > Hi Dave, > > The fact that you have a product in existence is a good thing. It > indicates a need for this technology and it indicates a need for > standardization of this technology. The next step is to get a standard in > place so that this technology can be used in each and every circumstance > that may be applicable. Well standards are useful when interoperability is needed. In this case, what might be needed is a new API from the platform vendor. In my case, what I described is my application of an approach recommended by our secure payment technology/service vendor. My adaptation was simply to force a correlation between the DLL actually loaded by win/95 and the dll I validate using their MD5 library and verification routine. So I think this could be added to a security issues chapter of someone's book but it doesn't deserve collective effort. From chandras@loc201.tandem.com Fri Sep 13 10:09:09 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id KAA03705; Fri, 13 Sep 1996 10:09:09 -0700 Received: from rosetta.verisign.com by suntan.tandem.com (8.6.12/suntan5.960905) for id KAA03696; Fri, 13 Sep 1996 10:09:06 -0700 Received: from dustin.verisign.com (gateway-outside [204.162.64.20]) by rosetta.verisign.com (8.7.4/8.6.12) with ESMTP id KAA20549; Fri, 13 Sep 1996 10:08:22 -0700 (PDT) Received: from Peter.verisign.com (Peter.verisign.com [192.42.157.77]) by dustin.verisign.com (8.7.4/8.6.12) with SMTP id KAA17321; Fri, 13 Sep 1996 10:08:14 -0700 (PDT) Received: by Peter.verisign.com with Microsoft Mail id <01BBA15B.8703F520@Peter.verisign.com>; Fri, 13 Sep 1996 10:08:36 -0700 Message-ID: <01BBA15B.8703F520@Peter.verisign.com> From: Peter Williams To: dave horvath , "'Hamilton, Ed @ OTT'" Cc: chandras , ietf-pkix Subject: RE: FW: Off topic - DLL security Date: Fri, 13 Sep 1996 10:08:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Microsoft does indeed claim to use signatures and tamperproof loading implementation technology to control loading of a crypto DLL. However, this seems to be an exception to the design being advanced for the commercial market: The general tendency seems to be that DLL (or any other content type) is evaluated at *introduce/install* time as to whether its behaviour (upon loading) or mere existance (in the system) would negatively impact the continuing accreditation of a host system to be operating at level C2 (or other level). ---------- From: Hamilton, Ed @ OTT Sent: Thursday, September 12, 1996 8:13 AM To: dave horvath Cc: chandras; ietf-pkix Subject: Re: FW: Off topic - DLL security Hi Dave, I would love to use a trusted operating system, however, it would basically be a waste of money, in the sense that the software that I need to run on it is Commercial and not certifiable on a B2 system. For the end-user platforms, we have been mandated to find a way to implement the required security on a C2 platform (namingly Windows NT). However, at the same time we must address the issues of I&A from our applications to the user and to a PCMCIA card. We must also ensure the integrity of the label generated by our software to ensure that it gets to the PCMCIA card without modification. So, we need partially C2 certified application software. One way for us to get there is to utilize static linked libraries, but commercial vendors do not want to give these types of things away, plus it makes maintenance a real pain. I was lead to believe that the ietf (specifically the pkix) was looking at this issue and would be proposing something in the near future. I have not heard a response to this fact. I believe that they were looking at digitally signing a DLL to ensure that the DLL in use is valid. I believe that Microsoft is also implementing something like this for use with their capi DLLs. Can anyone tell me what is going on? --- Ed.Hamilton@lmco.com ---------- From: dave horvath To: chandras; ietf-pkix; ehamilt Subject: Re: FW: Off topic - DLL security Date: Thursday, September 12, 1996 10:19AM > From chandras@loc201.tandem.com Thu Sep 12 09:04:52 1996 > From: "Hamilton, Ed @ OTT" > To: chandras , ietf-pkix > Subject: FW: Off topic - DLL security > Date: Thu, 12 Sep 96 08:41:00 EDT > Encoding: 24 TEXT > X-Mailer: Microsoft Mail V3.0 > Content-Length: 993 > > > > ---------- > From: Hamilton, Ed @ OTT > To: 'Security Mail > Subject: Off topic - DLL security > Date: Wednesday, September 11, 1996 10:42AM > > Hi, > > I believe this is a little off topic, but it really should be > considered here as well. I am looking at implementing a secure product that > uses a DLL for various means including accessing a PCMCIA Card. My concern > is that someone can spoof this DLL and gain access to my password. > The relevance to www-security is the use of PC Cards or Smart Cards to > authenticate individuals to a web application which in turn uses secure http > or whatever to communicate to a location such as a bank. > Does anyone have any suggestions. implementation, ideas on how > authentication can be securely performed to PC Card via a DLL? Are there > any standards in the works? I really want to start a *BIG* discussion on > this. Does anyone know of other lists that I can send this to that will be > interested in this topic? It is true that the use of DLLs may exagerate the security risks associated with solicitation of passwords and pins, however the risk will always be there if you don't use a trusted system. There are various levels of security that are available in operating system products to help minimize the threat of someone gaining access to your information. One mechanism is trusted paths wich are implemented in higher level assurance operating systems. Trusted paths provide some level of assurance that you are communicating with a device, process, etc. They are requirement of B2 and above or CMW systems. (see TCSEC from NCSC , i think ) The trusted path is a direct and unmistakably distinct communication mechanism between the Trusted Computing Base (TCB) and the system users. The use of a trusted path ensures that a user cannot be tricked into communicating with a process that pretends to be the trusted software. It is all based on the level of threat you determine you will encounter, and how much money you want to spend to minimize the risk. On a Windows platform you may be able to provide some minimally higher level of assurance by signing the DLL, but the security will still be generally weak due to limations in Windows itself. Dave Horvath Chromatix, Inc From chandras@loc201.tandem.com Fri Sep 13 11:31:52 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id LAA12712; Fri, 13 Sep 1996 11:31:52 -0700 Received: from tide21.microsoft.com by suntan.tandem.com (8.6.12/suntan5.960905) for id LAA12625; Fri, 13 Sep 1996 11:31:10 -0700 Received: by tide21.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBA167.5A7C9C80@tide21.microsoft.com>; Fri, 13 Sep 1996 11:33:15 -0700 Message-ID: From: Tom Johnston To: "'dave horvath'" , "'Hamilton, Ed @ OTT'" , "'Peter Williams'" Cc: "'chandras'" , "'ietf-pkix'" Subject: RE: FW: Off topic - DLL security Date: Fri, 13 Sep 1996 11:30:58 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 146 TEXT >Microsoft's winverifytrust() api is directly to the purpose of providing .dll >security. You can find information on it at >http://www.microsoft.com/intdev/security/misf8_2.htm. We provide both a >signing format and a model for writing your own code verification policies. > >The signature format is the standard PKCS#7 SignedData structure with some additional published attributes. There's a a set of libraries and tools >for signing a DLL with your own key, inserting the signature directly into >the DLL along with any relevant certificates, and parsing and verifing the >signature. >The thorny problem is who calls the API. Authenticode calls it at >installation; you could certainly write an agent that would call the API at >other times, though this might require hooking system services. -TJ >---------- >From: Peter Williams[SMTP:peter@verisign.com] >Sent: Friday, September 13, 1996 10:08 AM >To: dave horvath; 'Hamilton, Ed @ OTT' >Cc: chandras; ietf-pkix >Subject: RE: FW: Off topic - DLL security > >Microsoft does indeed claim to use signatures and tamperproof >loading implementation technology to control loading of a crypto DLL. >However, >this seems to be an exception to the design being advanced >for the commercial market: > >The general tendency seems to be that DLL (or any other content type) >is evaluated at *introduce/install* time as to whether its behaviour (upon >loading) or >mere existance (in the system) would negatively impact the continuing >accreditation >of a host system to be operating at level C2 (or other level). > > >---------- >From: Hamilton, Ed @ OTT >Sent: Thursday, September 12, 1996 8:13 AM >To: dave horvath >Cc: chandras; ietf-pkix >Subject: Re: FW: Off topic - DLL security > > >Hi Dave, > > I would love to use a trusted operating system, however, it would >basically be a waste of money, in the sense that the software that I need to >run on it is Commercial and not certifiable on a B2 system. > For the end-user platforms, we have been mandated to find a way to >implement the required security on a C2 platform (namingly Windows NT). > However, at the same time we must address the issues of I&A from our >applications to the user and to a PCMCIA card. We must also ensure the >integrity of the label generated by our software to ensure that it gets to >the PCMCIA card without modification. > So, we need partially C2 certified application software. One way for >us to get there is to utilize static linked libraries, but commercial >vendors do not want to give these types of things away, plus it makes >maintenance a real pain. > I was lead to believe that the ietf (specifically the pkix) was looking >at this issue and would be proposing something in the near future. I have >not heard a response to this fact. I believe that they were looking at >digitally signing a DLL to ensure that the DLL in use is valid. I believe >that Microsoft is also implementing something like this for use with their >capi DLLs. > Can anyone tell me what is going on? > > --- Ed.Hamilton@lmco.com > ---------- >From: dave horvath >To: chandras; ietf-pkix; ehamilt >Subject: Re: FW: Off topic - DLL security >Date: Thursday, September 12, 1996 10:19AM > >> From chandras@loc201.tandem.com Thu Sep 12 09:04:52 1996 >> From: "Hamilton, Ed @ OTT" >> To: chandras , ietf-pkix > >> Subject: FW: Off topic - DLL security >> Date: Thu, 12 Sep 96 08:41:00 EDT >> Encoding: 24 TEXT >> X-Mailer: Microsoft Mail V3.0 >> Content-Length: 993 >> >> >> >> ---------- >> From: Hamilton, Ed @ OTT >> To: 'Security Mail >> Subject: Off topic - DLL security >> Date: Wednesday, September 11, 1996 10:42AM >> >> Hi, >> >> I believe this is a little off topic, but it really should be >> considered here as well. I am looking at implementing a secure product >that >> uses a DLL for various means including accessing a PCMCIA Card. My >concern >> is that someone can spoof this DLL and gain access to my password. >> The relevance to www-security is the use of PC Cards or Smart Cards >to >> authenticate individuals to a web application which in turn uses secure >http >> or whatever to communicate to a location such as a bank. >> Does anyone have any suggestions. implementation, ideas on how >> authentication can be securely performed to PC Card via a DLL? Are there >> any standards in the works? I really want to start a *BIG* discussion on >> this. Does anyone know of other lists that I can send this to that will >be >> interested in this topic? > > It is true that the use of DLLs may exagerate the security risks > associated with solicitation of passwords and pins, however the > risk will always be there if you don't use a trusted system. > > There are various levels of security that are available in > operating system products to help minimize the threat of someone > gaining access to your information. One mechanism is trusted paths > wich are implemented in higher level assurance operating systems. > Trusted paths provide some level of assurance that you are > communicating with a device, process, etc. They are requirement > of B2 and above or CMW systems. (see TCSEC from NCSC , i think ) > > The trusted path is a direct and unmistakably distinct communication > mechanism between the Trusted Computing Base (TCB) and the system > users. The use of a trusted path ensures that a user cannot be > tricked into communicating with a process that pretends to be > the trusted software. > > It is all based on the level of threat you determine you will > encounter, and how much money you want to spend to minimize the > risk. > > On a Windows platform you may be able to provide some minimally > higher level of assurance by signing the DLL, but the security > will still be generally weak due to limations in Windows itself. > > >Dave Horvath >Chromatix, Inc > > > From chandras@loc201.tandem.com Fri Sep 13 13:17:32 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id NAA22287; Fri, 13 Sep 1996 13:17:32 -0700 Received: from rosetta.verisign.com by suntan.tandem.com (8.6.12/suntan5.960905) for id NAA22281; Fri, 13 Sep 1996 13:17:30 -0700 Received: from dustin.verisign.com (gateway-outside [204.162.64.20]) by rosetta.verisign.com (8.7.4/8.6.12) with ESMTP id NAA23513; Fri, 13 Sep 1996 13:17:01 -0700 (PDT) Received: from Peter.verisign.com (Peter.verisign.com [192.42.157.77]) by dustin.verisign.com (8.7.4/8.6.12) with SMTP id NAA20694; Fri, 13 Sep 1996 13:17:05 -0700 (PDT) Received: by Peter.verisign.com with Microsoft Mail id <01BBA175.E9169F00@Peter.verisign.com>; Fri, 13 Sep 1996 13:17:27 -0700 Message-ID: <01BBA175.E9169F00@Peter.verisign.com> From: Peter Williams To: "'dave horvath'" , "'Hamilton, Ed @ OTT'" , "'Peter Williams'" , "'Tom Johnston'" Cc: "'chandras'" , "'ietf-pkix'" Subject: RE: FW: Off topic - DLL security Date: Fri, 13 Sep 1996 13:17:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom, Thanks for the clarification - that the various Windows system security services are themselves usable by third parties IN ANY manner designers/developers may wish - to provide whatever controls are desired. I have personally only the highest respect for Microsoft's development and mass deployment of the missing security infrastructure pieces, and (FURTHEREMORE) the architecting of their components such that they can be used in many different ways. We have waited for so long! To agree with something MS said recently, MS has now done the grunt work of signatures and certs programming, ASN.1 fiddling (now, fortunately, all hidden!), and provided high-level language programming of these constructs enabling access by anyone capable of programming Basic and using the web. Now the community at large can go build security conrtols of whatever nature it wishes - upon the cross-vendor/cross-O/S platform. Whilst we as a community (which clearly now integrates Microsoft's contribution) have now solved a big piece of the infrastructure bootstrap problem by agreeing the standards, and having a major vendor like MS deploy a conforming implementation widely and freely in a developers framework, we perhaps now need to concentrate on the promotion of "good ways" to use the various mechanisms. Goodness, of course, is rather subjective. "A gun is a powerful defense tool; but it often shoots the firer in the foot when used by untrained people!" Whislt MS has given the public security facilites (withCryptoAPI 1) and now (with CryptoAPI 2) solid security mechanisms, we need to give them also guidance on how to use them properly to construct valid security services, so as not to lead to many a crypto accident or false sense of security. As the S/MIMEcommunity is discovering, one can take the MS security mechanism, and bundle them together in such a manner as to enhance the opportunities of fraud! Now that we have free and open technology, the vendors who know how to design secure protocols and applications really need to take a strong leadership role in promoting assured security designs. Peter ---------- From: Tom Johnston Sent: Friday, September 13, 1996 11:30 AM To: 'dave horvath'; 'Hamilton, Ed @ OTT'; 'Peter Williams' Cc: 'chandras'; 'ietf-pkix' Subject: RE: FW: Off topic - DLL security >Microsoft's winverifytrust() api is directly to the purpose of providing .dll >security. You can find information on it at >http://www.microsoft.com/intdev/security/misf8_2.htm. We provide both a >signing format and a model for writing your own code verification policies. > >The signature format is the standard PKCS#7 SignedData structure with some additional published attributes. There's a a set of libraries and tools >for signing a DLL with your own key, inserting the signature directly into >the DLL along with any relevant certificates, and parsing and verifing the >signature. >The thorny problem is who calls the API. Authenticode calls it at >installation; you could certainly write an agent that would call the API at >other times, though this might require hooking system services. -TJ >---------- >From: Peter Williams[SMTP:peter@verisign.com] >Sent: Friday, September 13, 1996 10:08 AM >To: dave horvath; 'Hamilton, Ed @ OTT' >Cc: chandras; ietf-pkix >Subject: RE: FW: Off topic - DLL security > >Microsoft does indeed claim to use signatures and tamperproof >loading implementation technology to control loading of a crypto DLL. >However, >this seems to be an exception to the design being advanced >for the commercial market: > >The general tendency seems to be that DLL (or any other content type) >is evaluated at *introduce/install* time as to whether its behaviour (upon >loading) or >mere existance (in the system) would negatively impact the continuing >accreditation >of a host system to be operating at level C2 (or other level). > > >---------- >From: Hamilton, Ed @ OTT >Sent: Thursday, September 12, 1996 8:13 AM >To: dave horvath >Cc: chandras; ietf-pkix >Subject: Re: FW: Off topic - DLL security > > >Hi Dave, > > I would love to use a trusted operating system, however, it would >basically be a waste of money, in the sense that the software that I need to >run on it is Commercial and not certifiable on a B2 system. > For the end-user platforms, we have been mandated to find a way to >implement the required security on a C2 platform (namingly Windows NT). > However, at the same time we must address the issues of I&A from our >applications to the user and to a PCMCIA card. We must also ensure the >integrity of the label generated by our software to ensure that it gets to >the PCMCIA card without modification. > So, we need partially C2 certified application software. One way for >us to get there is to utilize static linked libraries, but commercial >vendors do not want to give these types of things away, plus it makes >maintenance a real pain. > I was lead to believe that the ietf (specifically the pkix) was looking >at this issue and would be proposing something in the near future. I have >not heard a response to this fact. I believe that they were looking at >digitally signing a DLL to ensure that the DLL in use is valid. I believe >that Microsoft is also implementing something like this for use with their >capi DLLs. > Can anyone tell me what is going on? > > --- Ed.Hamilton@lmco.com > ---------- >From: dave horvath >To: chandras; ietf-pkix; ehamilt >Subject: Re: FW: Off topic - DLL security >Date: Thursday, September 12, 1996 10:19AM > >> From chandras@loc201.tandem.com Thu Sep 12 09:04:52 1996 >> From: "Hamilton, Ed @ OTT" >> To: chandras , ietf-pkix > >> Subject: FW: Off topic - DLL security >> Date: Thu, 12 Sep 96 08:41:00 EDT >> Encoding: 24 TEXT >> X-Mailer: Microsoft Mail V3.0 >> Content-Length: 993 >> >> >> >> ---------- >> From: Hamilton, Ed @ OTT >> To: 'Security Mail >> Subject: Off topic - DLL security >> Date: Wednesday, September 11, 1996 10:42AM >> >> Hi, >> >> I believe this is a little off topic, but it really should be >> considered here as well. I am looking at implementing a secure product >that >> uses a DLL for various means including accessing a PCMCIA Card. My >concern >> is that someone can spoof this DLL and gain access to my password. >> The relevance to www-security is the use of PC Cards or Smart Cards >to >> authenticate individuals to a web application which in turn uses secure >http >> or whatever to communicate to a location such as a bank. >> Does anyone have any suggestions. implementation, ideas on how >> authentication can be securely performed to PC Card via a DLL? Are there >> any standards in the works? I really want to start a *BIG* discussion on >> this. Does anyone know of other lists that I can send this to that will >be >> interested in this topic? > > It is true that the use of DLLs may exagerate the security risks > associated with solicitation of passwords and pins, however the > risk will always be there if you don't use a trusted system. > > There are various levels of security that are available in > operating system products to help minimize the threat of someone > gaining access to your information. One mechanism is trusted paths > wich are implemented in higher level assurance operating systems. > Trusted paths provide some level of assurance that you are > communicating with a device, process, etc. They are requirement > of B2 and above or CMW systems. (see TCSEC from NCSC , i think ) > > The trusted path is a direct and unmistakably distinct communication > mechanism between the Trusted Computing Base (TCB) and the system > users. The use of a trusted path ensures that a user cannot be > tricked into communicating with a process that pretends to be > the trusted software. > > It is all based on the level of threat you determine you will > encounter, and how much money you want to spend to minimize the > risk. > > On a Windows platform you may be able to provide some minimally > higher level of assurance by signing the DLL, but the security > will still be generally weak due to limations in Windows itself. > > >Dave Horvath >Chromatix, Inc > > > From chandras@loc201.tandem.com Sun Sep 15 11:11:10 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id LAA11317; Sun, 15 Sep 1996 11:11:10 -0700 Received: from mail.intranet.ca by suntan.tandem.com (8.6.12/suntan5.960905) for id LAA11314; Sun, 15 Sep 1996 11:11:07 -0700 Received: from -ford1 (ppp58.intranet.ca [206.51.251.158]) by mail.intranet.ca (8.6.11/8.6.9) with SMTP id OAA10870 for ; Sun, 15 Sep 1996 14:13:04 -0400 Message-Id: <2.2.32.19960915180220.006e16ac@mail.intranet.ca> X-Sender: wford@mail.intranet.ca X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 15 Sep 1996 14:02:20 -0400 To: ietf-pkix@tandem.com From: Michael S Baum (by way of Warwick Ford ) Subject: meeting notice FYI... ========================================================== MEETING NOTICE ========================================================== Please correspond with: Michael S. Baum, Esq. 33 Tremont Street Cambridge, MA 02139-1227 USA V: +1 617.661.1234 F: +1 617.661.0716 E: michael@verisign.com Subject: INFORMATION SECURITY COMMITTEE MEETING NOTICE Dear Committee Member: You are cordially invited to participate in a meeting of the Information Security Committee, Section of Science & Technology, American Bar Association, on Friday/Saturday, October 18-19, 1996, in Boston. The Committee will advance its development of commercial key escrow guidelines as well as consider digital signature legislative initiatives in the several States and other jurisdictions, and continue its consideration of digital signature evidence and liability. Consistent with Section policy, ISC meeting participants MUST be members of both the ABA and the ABA Section of Science and Technology. Please contact Ann Kowalsky, Manager Section of Science & Technology, at ABA offices in Chicago by phone: +1 312.988.5599, fax: +1 312.988.5628, or email: sciencetech@attmail.com for membership information. It is possible to become a paid member of the ABA and the ISC at the meeting. Dan Greenwood, ISC member, has kindly agreed to host the meeting at the Information Technology Division of the Commonwealth of Massachusetts. Dan can be reached at 617.973.0071 or DGreenwood@state.ma.us for directions & logistical information. Meeting details appear below. I look forward to seeing you in Boston. Sincerely, Michael S. Baum Chair, Information Security Committee Section of Science & Technology, ABA --------------- INFORMATION SECURITY COMMITTEE October 18-19, 1996 Tentative Agenda (see "Meeting Details," next page) (In extended sessions, breaks will be taken as needed.) October 18, 1996 Friday 8:30-9:00 Greetings, breakfast, administrative matters. 9:00-9:30 Introductions, meeting logistics, Guidelines update, questions; PKI-relevant standards reports. 9:30-12:00 Legislative/Regulatory Update (including open conference call with digital signature leg./reg. drafting committee representatives in the US and abroad). 12:00-13:00 Joint lunch with Boston Bar Assn, Computer Law Committee. 13:00-18:00 Continuation of legislative/regulatory update with digital signature leg./reg. drafting committee representatives. 18:00-???? Watering hole discussions; possible continuation of work group meetings. October 19, 1996 Saturday 8:30-9:00 Breakfast, et cetera. 9:00-10:00 Presentation by Key Escrow work group. 10:00-12:00 Breakout sessions on work groups. 12:00-13:00 Working lunch and guest presentation on "Assuring Quality and the Accreditation of Certification Authorities" by invited representative of the Nat'l Inst. of Standards and Tech. 13:00-15:00 Presentations by Work Groups. 15:00-15:30 Path Forward; wrap-up. ISC MEETING DETAILS October 18-19, 1996 Members are urged to participate in one of the work groups that will be presenting/meeting during the ISC's meeting. "Addendum" Work Group Contact: Ruven Schwartz (rschwart@research.westlaw.com) Tom Smedinghoff (tsmed@mbc.com) Joe Wackerman (jwackerm@email.usps.gov) The Addendum Work Group will continue drafting a digital signature trading partner agreement -- integrating the principles of the Digital Signature Guidelines, and developing additional practical commentary for this model form of electronic commerce agreement. Evidentiary Work Group Contact: Stan Kurzban (qbjw99a@prodigy.com) or Serge Parisien (parisise@droit.umontreal.ca) The Evidentiary Work Group will complete and present a provisional outline for a tutorial on the evidentiary implications of digitally signed information and advance drafting of material for each section of the tutorial. Key Escrow Work Group (KEWG) Contact: Dwight Olson (73522.3542@compuserve.com) or Randy Sabett (rsabett@venable.com) The KEWG will focus on the legal and technical aspects of commercial key escrow. The group will seek to accurately explore all major issues surrounding this topic, and produce a set of draft guidelines for comment. The proposed guidelines are intended to facilitate secure electronic commerce by clarifying the rights and obligations of the parties involved in voluntary commercial key escrow. The work product may take one or more forms including: (i) a "restatement" of the relevant law and practice, (ii) a model state or federal law or international convention, (iii) a set of principles that can be incorporated by reference into agreements or used for the interpretation of legal aspects of voluntary key escrow, or (iv) a set of "gap filler" provisions. Liability Work Group Contact: Maureen Adamache (rmadama@magi.com) The liability work group will meet as necessary to discuss the apportionment of liabilities among PKI providers and users. Previously, this task was considered in the ISC's own work-product, the Digital Signature Guidelines. Future documents that will be considered include Certification Practice Statements, and digital signature legislative and regulatory work product. State Government Digital Signatures Laws & Regulations Contact: Dan Greenwood (DGreenwood@state.ma.us) The digital signature legislative and regulatory working group will compile, evaluate and compare the various emerging approaches by states and other jurisdictions. Work product will include a web-based comprehensive "one-stop shop" for jurisdictions wishing to review current approaches. First-time participants (who plan to attend the October 18-19, 1996 meeting) must request attendance and submit a brief work-product (typically 3-5 pages) relevant to the subject matter. Please contact Ruven Schwartz (v: 612.687.8095, f: 612.687.7907, or e: rschwart@research.westlaw.com) for details. Meeting Location: McCormack Building (Across Bowdoin Street from the State House) 1 Ashburton Place Room 1, 21st Floor Boston, Massachusetts USA (Contact: Dan Greenwood +1 617.973.0071) Meals: The cafeteria will be available for lunch on Friday for those ISC Members who choose to work through the joint lunch session. On Saturday we will probably order in pizza. Lodging: A very nearby hotel is the Holiday Inn, Government Center, 5 Blossom Street, Boston. The regular rate during our meeting dates is $219.95/night. However, the Reservation Supervisor (Kim) has offered a rate of $199.95 to Committee members who request the "Great Rate" plan. Call reservations at +1 617.742.7630. For a better (but more expensive) hotel near Government Center, try the Parker House at +1 617.227.8600. The Omni Parker House (nicer than Holiday Inn) quoted a rate of $169/night for a single with a king or queen bed and $119/night for a single with a double bed. The rooms are very small - but the hotel is nice. See also a Greater Boston Bed & Breakfast directory: http://www.inovatec.com/bb/resservc/GREATER/GREATER.htm. RSVP: Please confirm your intention to participate to Ann Kowalsky, Section Manager, Section of Science and Technology (sciencetech@attmail.com) as soon as possible. See you in Boston! =========================================================================== From chandras@loc201.tandem.com Sun Sep 15 13:28:28 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id NAA20540; Sun, 15 Sep 1996 13:28:28 -0700 Received: from zafu.bbn.com by suntan.tandem.com (8.6.12/suntan5.960905) for id NAA20537; Sun, 15 Sep 1996 13:28:27 -0700 Received: from [128.89.30.8] (ARA8.BBN.COM [128.89.30.8]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id QAA23095; Sun, 15 Sep 1996 16:33:22 -0400 (EDT) X-Sender: kent@po1.bbn.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 15 Sep 1996 16:28:09 -0500 To: "Hamilton, Ed @ OTT" From: kent@bbn.com (Stephen Kent) Subject: Re: FW: Off topic - DLL security Cc: dave horvath , chandras , ietf-pkix Ed, I doubt that PKIX will address any of the details of the topics you raised. We are working on certification infrastructure standards issues. The security of the interface between application software and a crypto token is a local issue, that depends on the OS, the token, etc. Digitally signing software may be of some use in this context, but it probably is not a panacea and it also is not within the scope of the WG. Steve From chandras@loc201.tandem.com Mon Sep 16 06:19:46 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id GAA08160; Mon, 16 Sep 1996 06:19:46 -0700 Received: from bbmail1.unisys.com by suntan.tandem.com (8.6.12/suntan5.960905) for id GAA08157; Mon, 16 Sep 1996 06:19:44 -0700 Received: from trsvr.tr.unisys.com (trsvr.tr.unisys.com [192.63.216.7]) by bbmail1.unisys.com (8.7.3/8.6.12) with ESMTP id NAA27759; Mon, 16 Sep 1996 13:19:12 GMT Received: from flugel by trsvr.tr.unisys.com (8.6.12/8.6.12) id NAA23504 ; Mon, 16 Sep 1996 13:14:21 GMT Message-ID: <323D53BA.1BAD@trsvr.tr.unisys.com> Date: Mon, 16 Sep 1996 09:18:50 -0400 From: Bill Buffam Reply-To: bjb@trsvr.tr.unisys.com Organization: Unisys X-Mailer: Mozilla 3.0b5aGold (WinNT; I) MIME-Version: 1.0 To: Peter Williams CC: ietf-pkix@tandem.com Subject: Re: FW: Off topic - DLL security References: <01BBA175.E9169F00@Peter.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >As the S/MIMEcommunity is discovering, one can take >the MS security mechanism, and bundle them >together in such a manner as to enhance the >opportunities of fraud! Really? I must have missed something. Can you expand on this? -- Bill Buffam Unisys, Malvern PA bjb@trsvr.tr.unisys.com From chandras@loc201.tandem.com Mon Sep 16 12:01:26 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id MAA18767; Mon, 16 Sep 1996 12:01:26 -0700 Received: from iggy.iwsc.com by suntan.tandem.com (8.6.12/suntan5.960905) for id MAA18764; Mon, 16 Sep 1996 12:01:24 -0700 Received: from bmeandzija_nt (analog_dell.gi.com [168.84.65.19]) by iggy.iwsc.com (post.office MTA v1.9.3 ID# 10-12202) with SMTP id AAA240 for ; Mon, 16 Sep 1996 12:06:15 +0100 Message-ID: <323DA37F.F5F@metacomm.com> Date: Mon, 16 Sep 1996 11:59:11 -0700 From: Branislav Meandzija Reply-To: bran@metacomm.com Organization: Meta Communications, Inc. X-Mailer: Mozilla 3.0b8Gold (WinNT; I) MIME-Version: 1.0 To: ietf-pkix@tandem.com Subject: Call for Papers - Global Internet - IEEE Communications Magazine Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CALL FOR PAPERS IEEE COMMUNICATIONS MAGAZINE SPECIAL ISSUE ON THE GLOBAL INTERNET The IEEE Communications Magazine is soliciting original tutorial-style manuscripts for a planned Special Issue on the Global Internet. From its origins as a US government research project, the Internet has grown to become a major component of the global world-wide network infrastructure, linking millions of machines and tens of millions of users around the world. If the Internet were a stock it would be considered a market phenomenon, with sustained double-digit growth and no apparent end in sight to its upward spiral. Over 70 countries have full TCP/IP Internet connectivity, and about 150 have at least e-mail services through IP or via more limited means of connectivity (e.g., UUCP or Fidonet). Given such phenomenal growth, the Global Internet is increasingly viewed as the catalyst for a communications revolution resulting in a plethora of new technological, economic, and social changes. The focus of the special issue is on the technologies of the Internet, the technological changes driven by the emergence of a truly Global Internet, and collateral economic and social issues. Papers are solicited on the following specific subjects: * Internet Applications - information retrieval, directory services, catalogs, search tools and user agents; electronic publishing; education; www; languages; collaborative work environments. * Internet Connectivity Infrastructure - service characteristics ("best effort" vs. guaranteed); reliability (utility); addressing; multicasting; routing; protocols. * Internet Administrative Infrastructure - regulation; public policy; economics; standards. * Internet Security - security technology; export controls; privacy. * Internet Management - protocols; agent technology; standards; platforms. * Internet Commerce - electronic banking; virtual retailing; payment systems. Submitted manuscripts must be no longer than 12 single-spaced pages. The cover page should include the title of the paper, a brief abstract, a list of keywords, and the full name, affiliation, postal address, telephone number, and electronic mail address of each author. Papers may be submitted in postscript format via e-mail or as hardcopy (six copies). Authors should obtain company and government clearances prior to submission of papers. Papers should be submitted by October 31, 1996 to either of the guest co-editors. All papers will go through a peer-review process. They will be judged with respect to their quality and relevance to the Special Issue and the IEEE Communications Magazine. Authors will be notified of acceptance or rejection by December 15, 1996. Final copies of accepted papers will be due by January 31, 1997. Publication is scheduled for May 1997. Please submit manuscripts by October 31 to either: Branislav Meandzija - OR- Lyman Chapin Meta Communications, Inc. BBN CORPORATION 322 North Cleveland Ave., Suite 100 10 Moulton Street Oceanside, CA 92054 USA Cambridge, MA 02138 USA Phone: +1 619 721 6033 Phone: +1 617 873 3133 Fax: +1 619 456 7472 Fax: +1 617 873 3243 e-mail: bran@metacomm.com e-mail: lyman@bbn.com From chandras@loc201.tandem.com Thu Sep 19 09:24:21 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id JAA09840; Thu, 19 Sep 1996 09:24:21 -0700 Received: from dfw-ix6.ix.netcom.com by suntan.tandem.com (8.6.12/suntan5.960905) for id JAA09837; Thu, 19 Sep 1996 09:24:20 -0700 Received: from kaye---win-95 (scz-ca5-02.ix.netcom.com [199.182.129.162]) by dfw-ix6.ix.netcom.com (8.6.13/8.6.12) with SMTP id JAA20669; Thu, 19 Sep 1996 09:08:39 -0700 Message-Id: <2.2.32.19960919161048.009373c8@popd.ix.netcom.com> X-Sender: kaye@popd.ix.netcom.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Sep 1996 09:10:48 -0700 To: KCaldwell@SoftwareIndustry.org From: Kaye Caldwell Subject: ** 9/24 Ca. Dig. Sig. Working Group Meeting ** Apologies for duplicates - some of you I'm sure are on multiple notice lists for this. California Digital Signature Regulations Working Group sponsored by the Software Industry Coalition and CommerceNet THIS MEETING IS OPEN TO ANYONE WHO WISHES TO ATTEND However, please let me know if you will be attending via e-mail to: kaye@ix.netcom.com WHEN: Tuesday September 24, 1-4 PM WHERE: Sun Microsystems, 901 San Antonio Rd, (Building PAL-1) (corner of S. A. & Charleston, just off 101), Palo Alto Cancun Conference Room, 2nd Floor AGENDA I. Report on status of Secretary of State's Task Force - request for demos of technology in Sacramento II. Review of draft of our principle 1, suggestions for additional principles III. Review of current draft of outline of regulations IV. Review of draft Digital Signature Acceptance Procedures background paper V. Draft language for additional technologies For more information, e-mail Kaye Caldwell at kaye@ix.netcom.com or call 408-479-8743. Kaye Caldwell Software Industry Coalition Policy Director CommerceNet Adovocacy and Public Policy Committee Chair ------------------------------- From chandras@loc201.tandem.com Thu Sep 19 09:48:50 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id JAA12783; Thu, 19 Sep 1996 09:48:50 -0700 Received: from mail.microsoft.com by suntan.tandem.com (8.6.12/suntan5.960905) for id JAA12777; Thu, 19 Sep 1996 09:48:49 -0700 Received: by mail.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24) id <01BBA60F.8526BF90@mail.microsoft.com>; Thu, 19 Sep 1996 09:47:07 -0700 Message-ID: From: Tom Johnston To: "'ietf-pkix@tandem.com'" Subject: announce: CryptoAPI 2 developers' release Date: Thu, 19 Sep 1996 09:46:51 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Encoding: 28 TEXT CryptoAPI 2 gives developers the ability to incorporate certificates in applications, and removes much of the work of dealing with encapsulation >and encoding. It incorporates all of the cryptography present in CryptoAPI 1 >(key generation, key management, key exchange, encryption and decryption, >hashing, signing and signature verification). CryptoAPI 2 can be called from Java, Visual Basic, VB Script, and C/C++. It supports X.509, ASN.1, and PKCS 7. > >For more information, check out http://www.microsoft.com/intdev/security. It includes presentations on topics such as CryptoAPI 2, Secure Channel Services (SSL, etc), the Microsoft Certificate Server, Personal >Information Exchange, Smart Cards and more. It also includes the CryptoAPI 2 >developers' release (.dll's, documentation, sample applications and source >code), WinInet and WinSock 2 interfaces allowing developers to use >Microsoft's implementation of SSL rather than rolling your own. > >To give us feedback, or to participate in discussions about CryptoAPI 2, >please subscribe to the CryptoAPI mailing list: > >write to LISTSERV@LISTSERV.MSN.COM >and, in the text of your message (not the subject line), write: > >SUBSCRIBE CryptoAPI John Doe > >substituting your own name of course. > >-TJ From chandras@loc201.tandem.com Thu Sep 19 14:27:00 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id OAA16290; Thu, 19 Sep 1996 14:27:00 -0700 Received: from rosetta.verisign.com by suntan.tandem.com (8.6.12/suntan5.960905) for id OAA16286; Thu, 19 Sep 1996 14:26:58 -0700 Received: from dustin.verisign.com (gateway-outside [204.162.64.20]) by rosetta.verisign.com (8.7.4/8.6.12) with ESMTP id OAA12160; Thu, 19 Sep 1996 14:21:36 -0700 (PDT) Received: from Peter.verisign.com (Peter.verisign.com [192.42.157.77]) by dustin.verisign.com (8.7.4/8.6.12) with SMTP id OAA09541; Thu, 19 Sep 1996 14:21:40 -0700 (PDT) Received: by Peter.verisign.com with Microsoft Mail id <01BBA635.F8697940@Peter.verisign.com>; Thu, 19 Sep 1996 14:22:21 -0700 Message-ID: <01BBA635.F8697940@Peter.verisign.com> From: Peter Williams To: "'ietf-pkix@tandem.com'" , "'Tom Johnston'" Subject: RE: announce: CryptoAPI 2 developers' release Date: Thu, 19 Sep 1996 14:22:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom, If I undersatnd the reviewed material correctly: as much of the high-level functionality for certs (and PKCS#10-based cert mgt) is available via a COM interface, does this mean that, with time, the same methods will be also available via Distributed COM? Whilst the MS announcement is (of course) very significant, both generally, and for windows platforms, for consumers of PKIX cert management services, its surely even more important if there is cross-platform and networked access and support built into the mgt architecture via supprot for RPC/[D]COM, which now seem to come via MS strategic support for DCOM object brokering (via CORBA) with non-Windows server platforms. It seems that MS has not only hidden the nasties of ASN.1, and cert/PKCS formats behind a nice high-level programming interface, but, with the supprot for a COM/DCOM interface negotiation, the very location of the various cert mgt services is also distributable (and being based on an object architecture) subclassable and extensible ad infinitum for each communities policy-based key distribution needs. Am I way off in my understanding of the implications of the COM interface to the cert mgt announcement? Peter. ---------- From: Tom Johnston Sent: Thursday, September 19, 1996 9:46 AM To: 'ietf-pkix@tandem.com' Subject: announce: CryptoAPI 2 developers' release CryptoAPI 2 gives developers the ability to incorporate certificates in applications, and removes much of the work of dealing with encapsulation >and encoding. It incorporates all of the cryptography present in CryptoAPI 1 >(key generation, key management, key exchange, encryption and decryption, >hashing, signing and signature verification). CryptoAPI 2 can be called from Java, Visual Basic, VB Script, and C/C++. It supports X.509, ASN.1, and PKCS 7. > >For more information, check out http://www.microsoft.com/intdev/security. It includes presentations on topics such as CryptoAPI 2, Secure Channel Services (SSL, etc), the Microsoft Certificate Server, Personal >Information Exchange, Smart Cards and more. It also includes the CryptoAPI 2 >developers' release (.dll's, documentation, sample applications and source >code), WinInet and WinSock 2 interfaces allowing developers to use >Microsoft's implementation of SSL rather than rolling your own. > >To give us feedback, or to participate in discussions about CryptoAPI 2, >please subscribe to the CryptoAPI mailing list: > >write to LISTSERV@LISTSERV.MSN.COM >and, in the text of your message (not the subject line), write: > >SUBSCRIBE CryptoAPI John Doe > >substituting your own name of course. > >-TJ From chandras@loc201.tandem.com Thu Sep 19 17:20:37 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id RAA05386; Thu, 19 Sep 1996 17:20:37 -0700 Received: from dub-mail-svc-1.compuserve.com by suntan.tandem.com (8.6.12/suntan5.960905) for id RAA05380; Thu, 19 Sep 1996 17:20:36 -0700 Received: from 199.174.161.31 (ad19-031.compuserve.com [199.174.161.31]) by dub-mail-svc-1.compuserve.com (8.6.10/8.6.9) with SMTP id UAA23274 Message-ID: <3241F186.57DF@mlksys.atl.ga.us> Date: Thu, 19 Sep 1996 20:21:17 -0500 From: anonymous-netscape-user Reply-To: anonymous-netscape-user@mlksys.atl.ga.us X-Mailer: Mozilla 3.0 (Macintosh; U; PPC) MIME-Version: 1.0 To: ietf-pkix@tandem.com Subject: interchange format for certificates? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am not a member of this list so I will not see responses that are not directed to me. I am not sure if the following is something your group would be willing to address. The use of certificates is becoming more common. In my view there appears to be a problem that has yet to be solved: Each vendor stores the X.509 and other certificates in a proprietary file format that cannot be exchanged between computer systems. For example: I have a Macintosh at home and a Windows machine at work. I reciently had to aquire *TWO* certificates from Verisign because they have defined no interchange format allowing me to convert my private keys to an interchange form, copy them to the other system, and reimport them for use in that system. It seems to me that a simple interchange format, possibly patterned after the way the PGP people ASCIIify their keys, would be useful. I do not know why Verisign did not do this for their certificates, but maybe the IETF can define an informational or experimental RFC describing an interchange format and encourage Verisign and other entities to adopt and implement it. What to you all think, mlk@mlksys.atl.ga.us From chandras@loc201.tandem.com Thu Sep 19 19:00:11 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id TAA12860; Thu, 19 Sep 1996 19:00:11 -0700 Received: from mail.microsoft.com by suntan.tandem.com (8.6.12/suntan5.960905) for id TAA12855; Thu, 19 Sep 1996 19:00:08 -0700 Received: by mail.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24) id <01BBA65C.B42890A0@mail.microsoft.com>; Thu, 19 Sep 1996 18:59:37 -0700 Message-ID: From: Tom Johnston To: "'mlk@mlksys.atl.ga.us'" Cc: "'ietf-pkix@tandem.com'" Subject: RE: interchange format for certificates? Date: Thu, 19 Sep 1996 18:59:26 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Encoding: 48 TEXT This is exactly one of the problems the PFX (Personal Information Exchange) data format and protocol were designed to solve. PFX is designed to allow users to move their keys, certificates and other personal information - securely - from one platform to another. PFX has been submitted to the W3C Subgroup on Identity. documentation is available on http://www.microsoft.com/intdev/security/misf11_7.htm a presentation is available on http://www.microsoft.com/intdev/security/misf11_5.htm -TJ >---------- >From: anonymous-netscape-user[SMTP:anonymous-netscape-user@mlksys.atl.ga.us] >Sent: Thursday, September 19, 1996 6:21 PM >To: ietf-pkix@tandem.com >Subject: interchange format for certificates? > >Hi, > >I am not a member of this list so I will not see responses >that are not directed to me. I am not sure if the following >is something your group would be willing to address. > >The use of certificates is becoming more common. In my view >there appears to be a problem that has yet to be solved: > > Each vendor stores the X.509 and other certificates in > a proprietary file format that cannot be exchanged between > computer systems. For example: I have a Macintosh at > home and a Windows machine at work. I reciently had to > aquire *TWO* certificates from Verisign because they have > defined no interchange format allowing me to convert my > private keys to an interchange form, copy them to the > other system, and reimport them for use in that system. > >It seems to me that a simple interchange format, possibly >patterned after the way the PGP people ASCIIify their keys, >would be useful. I do not know why Verisign did not do this >for their certificates, but maybe the IETF can define an >informational or experimental RFC describing an interchange >format and encourage Verisign and other entities to adopt >and implement it. > >What to you all think, >mlk@mlksys.atl.ga.us > From chandras@loc201.tandem.com Fri Sep 20 07:50:46 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id HAA20024; Fri, 20 Sep 1996 07:50:46 -0700 Received: from sbc.com by suntan.tandem.com (8.6.12/suntan5.960905) for id HAA20014; Fri, 20 Sep 1996 07:50:42 -0700 Received: by sbc.com (8.7.1/25-eef) id JAA18553; Fri, 20 Sep 1996 09:53:00 -0500 (CDT) Received: from entropy.sbc.com(132.201.9.83) by swbcs002.sbc.com via smap (V3.1) id xma018551; Fri, 20 Sep 96 09:52:31 -0500 Received: by entropy.sbc.com (8.7.1/25-eef) id JAA09331; Fri, 20 Sep 1996 09:49:01 -0500 (CDT) Date: Fri, 20 Sep 1996 09:49:01 -0500 (CDT) From: "Brian M. Thomas" X-Full-Name: Brian M. Thomas Message-Id: <199609201449.JAA09331@entropy.sbc.com> To: ietf-pkix@tandem.com, tomj@microsoft.com Subject: Re: announce: CryptoAPI 2 developers' release X-Sun-Charset: US-ASCII > >and encoding. It incorporates all of the cryptography present in CryptoAPI 1 > >(key generation, key management, key exchange, encryption and decryption, > >hashing, signing and signature verification). CryptoAPI 2 can be called from > Java, Visual Basic, VB Script, and C/C++. Since I have not heard your announcement that you are contributing these methods to the Java core, I assume that it is callable from Java on a native-method basis only, no? And of course you are providing implementations on other platforms so that the primary goal of Java (write once, run anywhere) is met? Brian Thomas - Distributed Systems Architect bt0008@entropy.sbc.com Southwestern Bell bthomas@primary.net One Bell Center, Room 23Q1 Tel: 314 235 3141 St. Louis, MO 63101 Fax: 314 331 2755 From chandras@loc201.tandem.com Fri Sep 20 08:40:47 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id IAA24788; Fri, 20 Sep 1996 08:40:47 -0700 Received: from europa.salford.ac.uk by suntan.tandem.com (8.6.12/suntan5.960905) for id IAA24785; Fri, 20 Sep 1996 08:40:45 -0700 From: Message-Id: <199609201540.IAA24785@suntan.tandem.com> Received: from mailgate-1.salford.ac.uk by europa.salford.ac.uk with SMTP (PP); Fri, 20 Sep 1996 16:38:49 +0100 Date: 20 Sep 96 16:38 To: ietf-pkix@tandem.com Subject: unsubscribe X-Mailer: University of Salford cc:Mail/SMTP gateway 1.75 Encoding: 1 TEXT unsubscribe From chandras@loc201.tandem.com Fri Sep 20 13:21:53 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id NAA28151; Fri, 20 Sep 1996 13:21:53 -0700 Received: from defender.cylink.com by suntan.tandem.com (8.6.12/suntan5.960905) for id NAA28122; Fri, 20 Sep 1996 13:21:45 -0700 Received: from cylink by defender.cylink.com with smtp (Smail3.1.29.1 #4) id m0v4Buh-0007DEC; Fri, 20 Sep 96 13:11 PDT Received: from kennedy ([205.226.80.185]) by cylink (4.1/SMI-4.1) id AA13303; Fri, 20 Sep 96 13:19:10 PDT Date: Fri, 20 Sep 96 13:19:10 PDT Message-Id: <9609202019.AA13303@cylink> From: John Kennedy To: ipsec@tis.com, ietf-pkix@tandem.com, isakmp-oakley@cisco.com, skip-info@tik.ee.ethz.ch Subject: NOTICE: DSS Profile for X.509 Certificates to be deleted. Cc: johnmarc@cylink.com X-Mailer: Pronto E-Mail [version 2.01] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit I received the following message from the Internet-Drafts Administrator about a month ago regarding the deletion of the I-D John Marchioni and I co-authored on a "DSS Profile for X.509 Certificates". This draft was submitted only as an interim solution since the PKIX was just coming up to speed and had not yet included this material in the PKIX draft. I do not know exactly what the status of the X.509 DSS profile is in the PKIX document so I am sharing this current status information with you now. As far as I know DSS Certificates are being used in both the SKIP and ISAKMP/Oakley reference implementations and the aforementioned draft is cited in the applicable I-D's for these key management protocols. I have a number of choices: a) Do nothing and let the draft gracefully expire. b) Update and submit a revised draft of draft-ietf-ipsec-dss-cert-00.txt. c) Pester the PKIX editors to make sure this material gets absorbed into their next draft if it is not already there. (hint, hint...:) ) My preference and intention is to do (a) and (c) and at most submit a revised draft that simply points to PKIX. It is not clear that a revised draft is even necessary if current IPSEC and other working group drafts which point to draft-ietf-ipsec-dss-cert-00.txt are revised to now point to pkix-3. So, if anybody thinks I need to do (b) let me know. Otherwise, please reset your DSS / X.509 certificate pointers, questions, and comments to their proper home in PKIX. Thanks, -John Kennedy ----------------BEGIN INCLUDED MESSAGE---------------------------- Date: Fri, 23 Aug 1996 14:35:52 -0400 From: Internet-Drafts Administrator Subject: to be deleted. To: John Kennedy Cc: IESG Secretary The Internet-Draft: Title : DSS Profile for X.509 Certificates Author(s) : John Kennedy, John Marchioni Filename : Last Updated: 02/24/1996 Pages : 3 will be deleted from the internet-drafts directories in the next few weeks as it has exceeded its maximum time allocated as an Internet-Draft. If a updated version of the draft is available please submit it the next few days. From chandras@loc201.tandem.com Fri Sep 20 15:03:55 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id PAA09982; Fri, 20 Sep 1996 15:03:55 -0700 Received: from mail.microsoft.com by suntan.tandem.com (8.6.12/suntan5.960905) for id PAA09977; Fri, 20 Sep 1996 15:03:54 -0700 Received: by mail.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24) id <01BBA704.C2ABB000@mail.microsoft.com>; Fri, 20 Sep 1996 15:02:37 -0700 Message-ID: From: Tom Johnston To: "'ietf-pkix@tandem.com'" , "'bt0008@entropy.sbc.com'" Subject: RE: java & CryptoAPI 2 Date: Fri, 20 Sep 1996 15:02:38 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Encoding: 36 TEXT Brian -- what we've done is provided COM (OLE Automation) objects which can be called from Java. (For more information, check out Visual J++ at http://www.microsoft.com/visualj/). Regarding cross-platform, today CryptoAPI is available on Win95 (IE 3) and WinNT 4. We've licensed it to RSA, they are free to port it to other platforms, and we're looking to provide functionality at export strength level on other platforms ourselves. -TJ >---------- >From: Brian M. Thomas[SMTP:bt0008@entropy.sbc.com] >Sent: Friday, September 20, 1996 7:49 AM >To: Tom Johnston; ietf-pkix@tandem.com >Subject: Re: announce: CryptoAPI 2 developers' release > >> >and encoding. It incorporates all of the cryptography present in >>CryptoAPI 1 >> >(key generation, key management, key exchange, encryption and decryption, >> >hashing, signing and signature verification). CryptoAPI 2 can be called >>from >> Java, Visual Basic, VB Script, and C/C++. > >Since I have not heard your announcement that you are contributing >these methods to the Java core, I assume that it is callable from Java >on a native-method basis only, no? And of course you are providing >implementations on other platforms so that the primary goal of Java >(write once, run anywhere) is met? > > >Brian Thomas - Distributed Systems Architect bt0008@entropy.sbc.com >Southwestern Bell bthomas@primary.net >One Bell Center, Room 23Q1 Tel: 314 235 3141 >St. Louis, MO 63101 Fax: 314 331 2755 > > > From chandras@loc201.tandem.com Fri Sep 20 15:39:23 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id PAA14372; Fri, 20 Sep 1996 15:39:23 -0700 Received: from sbc.com by suntan.tandem.com (8.6.12/suntan5.960905) for id PAA14354; Fri, 20 Sep 1996 15:39:12 -0700 Received: by sbc.com (8.7.1/25-eef) id RAA12389; Fri, 20 Sep 1996 17:44:31 -0500 (CDT) Received: from entropy.sbc.com(132.201.9.83) by swbcs001.sbc.com via smap (V3.1) id xma012384; Fri, 20 Sep 96 17:44:15 -0500 Received: by entropy.sbc.com (8.7.1/25-eef) id RAA09803; Fri, 20 Sep 1996 17:33:32 -0500 (CDT) Date: Fri, 20 Sep 1996 17:33:32 -0500 (CDT) From: "Brian M. Thomas" X-Full-Name: Brian M. Thomas Message-Id: <199609202233.RAA09803@entropy.sbc.com> To: ietf-pkix@tandem.com, bt0008@tandem.com, tomj@microsoft.com Subject: RE: java & CryptoAPI 2 X-Sun-Charset: US-ASCII > From: Tom Johnston > Brian -- what we've done is provided COM (OLE Automation) objects which > can be called from Java. (For more information, check out Visual J++ at > http://www.microsoft.com/visualj/). Regarding cross-platform, today > CryptoAPI is available on Win95 (IE 3) and WinNT 4. We've licensed it > to RSA, they are free to port it to other platforms, and we're looking > to provide functionality at export strength level on other platforms > ourselves. > That is a step - a big step, I would say - in the right direction. Something this basic should, however, be a component of the Java core, even if implemented in a native-method interface. On the other hand, there might be nothing to prohibit a JVM builder from intercepting the Java core crypto API calls with routines to call your API so that the functionality is always available in the same way. As a major builder of enterprise architectures, I will never build a tool which gives my users no choice of client platform vendor. Unlike so many of my fellow architects, I remember what life was like when there was only one vendor to choose, and I will never go back to that. If the choice is to do without something Microsoft offers or to shut out all users who do not use Microsoft products, I will choose the first, even at considerable cost. I do not single out Microsoft in this; the same is true for all other vendors, but none of them has the market share to make that choice painful for me; consequently I have made it frequently. I strongly recommend that, if you wish to be first in this, that you seek in some fashion to integrate it into the core Java packages and let the other vendors catch up with you. If you do it first: good for you. If you do it best: even better. If you do it in a way that makes all web sites that use it effectively put up a sign that says, "browsers running on non-Microsoft platforms not welcome here", may you be crisped in your flying toasters; I will not use your product. brian Brian Thomas - Distributed Systems Architect bt0008@entropy.sbc.com Southwestern Bell bthomas@primary.net One Bell Center, Room 23Q1 Tel: 314 235 3141 St. Louis, MO 63101 Fax: 314 331 2755 From chandras@loc201.tandem.com Mon Sep 23 09:40:59 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id JAA13395; Mon, 23 Sep 1996 09:40:59 -0700 Received: from bnr.ca by suntan.tandem.com (8.6.12/suntan5.960905) for id JAA13367; Mon, 23 Sep 1996 09:40:47 -0700 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 23 Sep 1996 11:36:26 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 23 Sep 1996 10:32:06 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 23 Sep 1996 10:23:00 -0400 Date: Mon, 23 Sep 1996 10:23:00 -0400 X400-Originator: /dd.id=1651623/g=carlisle/i=cm/s=adams/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.690:23.08.96.14.32.06] X400-Content-Type: P2-1984 (2) Content-Identifier: re:NOTICE: DS... From: "carlisle (c.m.) adams" Sender: "carlisle (c.m.) adams" Message-ID: <"1680 Mon Sep 23 10:32:20 1996"@bnr.ca> To: jkennedy@cylink.com Cc: johnmarc@cylink.com, ipsec@tis.com, ietf-pkix@tandem.com, isakmp-oakley@cisco.com, skip-info@tik.ee.ethz.ch Subject: re:NOTICE: DSS Profile for X.509 Certificates to be deleted. In message "NOTICE: DSS Profile for X.509 Certificates to be deleted.", jkennedy@cylink.com writes: > >I received the following message from the Internet-Drafts Administrator about >a month ago regarding the deletion of the I-D John Marchioni and I co-authored >on a "DSS Profile for X.509 Certificates". This draft was submitted only as >an interim solution since the PKIX was just coming up to speed and had not yet >included this material in the PKIX draft. I do not know exactly what the >status of the X.509 DSS profile is in the PKIX document so I am sharing this >current status information with you now. As far as I know DSS Certificates >are being used in both the SKIP and ISAKMP/Oakley reference implementations >and the aforementioned draft is cited in the applicable I-D's for these key >management protocols. > >I have a number of choices: > >a) Do nothing and let the draft gracefully expire. >b) Update and submit a revised draft of draft-ietf-ipsec-dss-cert-00.txt. >c) Pester the PKIX editors to make sure this material gets absorbed into their >next draft if it is not already there. (hint, hint...:) ) > >My preference and intention is to do (a) and (c) and at most submit a revised >draft that simply points to PKIX. It is not clear that a revised draft is >even necessary if current IPSEC and other working group drafts which point to >draft-ietf-ipsec-dss-cert-00.txt are revised to now point to pkix-3. Do you really mean "pkix-3" here, or do you mean "pkix-1". Part three is the certificate management protocols -- it's not clear to me that a DSS profile for X.509 certificates belongs there. Or am I missing something? Carlisle. From chandras@loc201.tandem.com Mon Sep 23 10:46:49 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id KAA22497; Mon, 23 Sep 1996 10:46:49 -0700 Received: from defender.cylink.com by suntan.tandem.com (8.6.12/suntan5.960905) for id KAA22488; Mon, 23 Sep 1996 10:46:46 -0700 Received: from cylink by defender.cylink.com with smtp (Smail3.1.29.1 #4) id m0v5EvZ-0007DUC; Mon, 23 Sep 96 10:36 PDT Received: from genie.cylink.com by cylink (4.1/SMI-4.1) id AA03856; Mon, 23 Sep 96 10:44:31 PDT Received: from lobster by genie.cylink.com (SMI-8.6/SMI-SVR4) id KAA09295; Mon, 23 Sep 1996 10:44:21 -0700 Received: by lobster with Microsoft Mail id <01BBA93B.AC839610@lobster>; Mon, 23 Sep 1996 10:40:44 -0700 Message-Id: <01BBA93B.AC839610@lobster> From: John Marchioni To: "jkennedy@cylink.com" , "'carlisle (c.m.) adams'" Cc: "johnmarc@cylink.com" , "ipsec@tis.com" , "ietf-pkix@tandem.com" , "isakmp-oakley@cisco.com" , "skip-info@tik.ee.ethz.ch" Subject: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted. Date: Mon, 23 Sep 1996 10:40:42 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's correct, it should have been "section 7" of "pkix-1" which is = essentially correct but we don't like the current OID value for DSA with = SHA1, looks like the leftover from the NIST OIW/OSE. =20 Warwick just distributed a softcopy of a paper from his work with the = NIST PKI TWG which seems to be comprehensive in filling in the holes for = DSA certs. If Warwick folds this into "section 7" then I think the DSA = cert profile work for IETF is complete for now. =20 The Diffie-Hellman cert profile should be added next when it is agreed = that the D-H cert section of ANSI X9.42 is stable. I recommend that the = IETF and ANSI X9.42 use the same ARC for OIDs as in X9.57 when dealing = with D-H keys and certificates, if this ARC is registered and valid. - John ---------- From: carlisle (c.m.) adams Sent: Monday, September 23, 1996 7:23 AM To: jkennedy@cylink.com Cc: johnmarc@cylink.com; ipsec@tis.com; ietf-pkix@tandem.com; = isakmp-oakley@cisco.com; skip-info@tik.ee.ethz.ch Subject: re:NOTICE: DSS Profile for X.509 Certificates to be deleted.=20 In message "NOTICE: DSS Profile for X.509 Certificates to be deleted.",=20 jkennedy@cylink.com writes: > >I received the following message from the Internet-Drafts Administrator = about=20 >a month ago regarding the deletion of the I-D John Marchioni and I = co-authored=20 >on a "DSS Profile for X.509 Certificates". This draft was submitted = only as=20 >an interim solution since the PKIX was just coming up to speed and had = not yet=20 >included this material in the PKIX draft. I do not know exactly what = the=20 >status of the X.509 DSS profile is in the PKIX document so I am sharing = this=20 >current status information with you now. As far as I know DSS = Certificates=20 >are being used in both the SKIP and ISAKMP/Oakley reference = implementations=20 >and the aforementioned draft is cited in the applicable I-D's for these = key=20 >management protocols. > >I have a number of choices: > >a) Do nothing and let the draft gracefully expire. >b) Update and submit a revised draft of = From chandras@loc201.tandem.com Mon Sep 23 13:36:56 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id NAA11174; Mon, 23 Sep 1996 13:36:56 -0700 Received: from relay.hp.com by suntan.tandem.com (8.6.12/suntan5.960905) for id NAA11170; Mon, 23 Sep 1996 13:36:51 -0700 Received: from raj.corp.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA027151004; Mon, 23 Sep 1996 13:36:45 -0700 Received: by raj.corp.hp.com (1.39.111.2/15.5+ECS 3.4 ) id AA224040417; Mon, 23 Sep 1996 13:26:57 -0700 From: Sri Vidya Rajagopal Message-Id: <199609232026.AA224040417@raj.corp.hp.com> Subject: Authorization on WEB using Certs? To: ietf-pkix@tandem.com Date: Mon, 23 Sep 1996 13:26:57 PDT X-Mailer: Elm [revision: 112.2] Hi! Does anyone know of any standards or document to do AUthorization of Web Documents using Certificates? I am looking for any information/pointers we pages... anything to get me going in the right direction. thanks -sri From chandras@loc201.tandem.com Mon Sep 23 13:55:46 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id NAA13309; Mon, 23 Sep 1996 13:55:46 -0700 Received: from mail.intranet.ca by suntan.tandem.com (8.6.12/suntan5.960905) for id NAA13300; Mon, 23 Sep 1996 13:55:43 -0700 Received: from -ford1 (ppp14.intranet.ca [206.51.251.114]) by mail.intranet.ca (8.6.11/8.6.9) with SMTP id QAA13369; Mon, 23 Sep 1996 16:57:27 -0400 Message-Id: <2.2.32.19960923204458.006cc814@mail.intranet.ca> X-Sender: wford@mail.intranet.ca X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Sep 1996 16:44:58 -0400 To: OSIdirectory@az05.bull.com, pki-twg@csmes.ncsl.nist.gov, ietf-pkix@tandem.com From: Warwick Ford Subject: X.509 Bug Regarding Policy Constraints Cc: jsp@jgvandyke.com An error has been uncovered regarding policy constraints in the X.509 certificate extensions amendment. I have drafted the attached defect report for consideration at the October meeting of the ISO/IEC/ITU Directory group. I would appreciate hearing from anyone who objects to policySet being deleted from policy constraints. Thanks to John Pawling of JG VanDyke for finding the error. Warwick -------------------------------------- DEFECT REPORT FORM 1. Defect Report Number: 9594/ 2. Source: Warwick Ford 3. Addressed to: ISO/IEC JTC1/SC21/WG4 and CCITT Study Group VII Editor Group on the Directory 4. (a) WG Secretariat: Japan (JISC) (b) CCITT WP: SG VII/WP IV 5. Date Circulated by WG Secretariat: 6. Deadline for Response from Editor: 7. Defect Report Concerning: (number and title of IS or DIS final text/CCITT Recommendation) X.509 & IS 9594-8 The Directory - Authentication Framework - Amendment 1 on Certificate Extensions 8. Qualifier: (e.g.: error, omission, clarification required) Error 9. References in Document: (e.g.: page, clause/section, figure, and/or table numbers) 12.4.2.3 and 12.4.3 10. Nature of Defect: (complete, concise explanation of the perceived problem) 12.4.2.3 (Policy constraints field) includes a policySet component in the ASN.1 and describes its semantics, but the path processing procedure in 12.4.3 does not include processing for that component. If processing for policySet were to be added to 12.4.3, the algorithm would become very complex, with little real benefit. It is the submitter's contention that policySet should have been removed in the DAM editing process (the same component was removed from the Name constraints field), but was inadvertently left in. 11. Solution Proposed by the Source: (optional) In 12.4.2.3, remove the policySet component from the ASN.1 and delete the first paragraph after the ASN.1. Also remove the SEQUENCE OF from the ASN.1, as this becomes unnecessary. Assign the extension a new OID (id-ce 36) to avoid confusion. Reflect the same ASN.1 changes in Annex A. 12. Editor's Response: (any material proposed for processing as an erratum to, an amendment to, or a commentary on the IS or DIS final text/CCITT Recommendation or Draft Recommendation is attached separately to this completed report). ------------------------------------------------------------------- Warwick Ford: wford@intranet.ca Tel: (613)2253487 Fax: (613)2256361 Postal: 25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8 ------------------------------------------------------------------- From chandras@loc201.tandem.com Mon Sep 23 14:20:27 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id OAA16322; Mon, 23 Sep 1996 14:20:27 -0700 Received: from mail.intranet.ca by suntan.tandem.com (8.6.12/suntan5.960905) for id OAA16311; Mon, 23 Sep 1996 14:20:23 -0700 Received: from -ford1 (ppp14.intranet.ca [206.51.251.114]) by mail.intranet.ca (8.6.11/8.6.9) with SMTP id RAA14839; Mon, 23 Sep 1996 17:20:22 -0400 Message-Id: <2.2.32.19960923210800.006aac94@mail.intranet.ca> X-Sender: wford@mail.intranet.ca X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Sep 1996 17:08:00 -0400 To: John Marchioni , "jkennedy@cylink.com" , "'carlisle (c.m.) adams'" From: Warwick Ford Subject: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted. Cc: "ipsec@tis.com" , "ietf-pkix@tandem.com" , "isakmp-oakley@cisco.com" , "skip-info@tik.ee.ethz.ch" At 10:40 AM 9/23/96 -0700, John Marchioni wrote: >That's correct, it should have been "section 7" of "pkix-1" which is essentially correct but we don't like the current OID value for DSA with SHA1, looks like the leftover from the NIST OIW/OSE. > >Warwick just distributed a softcopy of a paper from his work with the NIST PKI TWG which seems to be >comprehensive in filling in the holes for DSA certs. If Warwick folds this into "section 7" then I think >the DSA cert profile work for IETF is complete for now. For the benefit of everyone, I have attached below a copy of the referenced e-mail from me. I won't include the uuencoded Word attachment on such a wide distribution as this message, but will send it to anyone requesting it. >The Diffie-Hellman cert profile should be added next when it is agreed that the D-H cert section of ANSI >X9.42 is stable. I recommend that the IETF and ANSI X9.42 use the same ARC for OIDs as in X9.57 when >dealing with D-H keys and certificates, if this ARC is registered and valid. The X9.57 arc is certainly registered (under ANSI as an ANSI standard) and valid, and we have used it for X9.57 and X9.55. I would not object to using it also for X9.42 Warwick ---------------------------------- >Date: Mon, 23 Sep 1996 10:39:36 -0400 >To: pki-twg@csmes.ncsl.nist.gov,housley@spyrus.com >From: Warwick Ford >Subject: DSA Algorithm Definitions >X-Attachments: C:\Business\ANSIX9\Algids.doc; > >Attached are the latest algorithm definitions from ANSI X9.57. When Russ, Rich Ankney, and I devised this set, we hoped we had developed one answer that would satisfy everyone (ANSI, PKIX, and the FPKI). > >There are 3 algorithmIds: >- dsa - has p, q, and g parameters - for use in subjectPublicKeyInfo >- dsa-with-sha-1 - no parameters - for use in the signature fields >- dsa-match - has key length as parameter - for use in those situations where you want to determine the capabilities of a remote system, e.g., in supportedAlgorithms attribute > >Warwick > ------------------------------------------------------------------- Warwick Ford: wford@intranet.ca Tel: (613)2253487 Fax: (613)2256361 Postal: 25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8 ------------------------------------------------------------------- From chandras@loc201.tandem.com Mon Sep 23 14:53:47 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id OAA20256; Mon, 23 Sep 1996 14:53:47 -0700 Received: from defender.cylink.com by suntan.tandem.com (8.6.12/suntan5.960905) for id OAA20243; Mon, 23 Sep 1996 14:53:44 -0700 Received: from cylink by defender.cylink.com with smtp (Smail3.1.29.1 #4) id m0v5Igu-0007CmC; Mon, 23 Sep 96 14:37 PDT Received: from kennedy ([205.226.80.185]) by cylink (4.1/SMI-4.1) id AA11834; Mon, 23 Sep 96 14:44:38 PDT Date: Mon, 23 Sep 96 14:44:38 PDT Message-Id: <9609232144.AA11834@cylink> From: John Kennedy To: wford@mail.intranet.ca, johnmarc@cylink.com, cadams@nortel.ca Subject: Re: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted. Cc: ipsec@tis.com, ietf-pkix@tandem.com, isakmp-oakley@cisco.com, skip-info@tik.ee.ethz.ch X-Mailer: Pronto E-Mail [version 2.01] Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit > At 10:40 AM 9/23/96 -0700, John Marchioni wrote: {Recommendation from John Marchioni deleted} > > For the benefit of everyone, I have attached below a copy of the referenced > e-mail from me. I won't include the uuencoded Word attachment on such a > wide distribution as this message, but will send it to anyone requesting > it. > > >The Diffie-Hellman cert profile should be added next when it is agreed > that > the D-H cert section of ANSI >X9.42 is stable. I recommend that the IETF > and ANSI X9.42 use the same ARC for OIDs as in X9.57 when >dealing with > D-H > keys and certificates, if this ARC is registered and valid. > > The X9.57 arc is certainly registered (under ANSI as an ANSI standard) > and > valid, and we have used it for X9.57 and X9.55. I would not object to > using > it also for X9.42 Warwick, I have just received a newly assigned ARC for ANSI X9.42 (Diffie-Hellman). I suspect the parameter syntax and encoding section for X9.42 to undergo some revision after the ANSI X9.F1 next week after I get some feedback. (BTW, you should have received hardcopy of this document a few weeks ago. Please let me know if you haven't. (That goes for anyone else that needs a copy, too)). I have assumed that X9.57 and X9.55 would be integrating details on constructing and encoding Diffie-Hellman certificates. I.e., I deliberately ommitted a D-H certificate section since I considered out of scope. As such, I only specified public number and system parameter syntax and encoding in X9.42. Basically, I agree that the X9.57 ARC should be used for certificates but I disagree regarding the use of the X9.57 ARC for the public numbers and system parameters. Why not stick with the X.42 ARC for those? Regards, -John Kennedy p.s. For follow-ups, I suggest we prune down the distribution to only Cc: ietf-pkix@tandem.com and ipsec@tis.com From chandras@loc201.tandem.com Mon Sep 23 15:41:07 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id PAA26576; Mon, 23 Sep 1996 15:41:07 -0700 Received: from relay.hp.com by suntan.tandem.com (8.6.12/suntan5.960905) for id PAA26570; Mon, 23 Sep 1996 15:41:06 -0700 Received: from raj.corp.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA229498464; Mon, 23 Sep 1996 15:41:05 -0700 Received: by raj.corp.hp.com (1.39.111.2/15.5+ECS 3.4 ) id AA225787877; Mon, 23 Sep 1996 15:31:17 -0700 From: Sri Vidya Rajagopal Message-Id: <199609232231.AA225787877@raj.corp.hp.com> Subject: test To: ietf-pkix@tandem.com Date: Mon, 23 Sep 1996 15:31:16 PDT X-Mailer: Elm [revision: 112.2] testing out to see if I can get a discussion started, is this the right address, I found it on the WEB. -Sri Rajagopal -- From chandras@loc201.tandem.com Mon Sep 23 18:44:23 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id SAA16857; Mon, 23 Sep 1996 18:44:23 -0700 Received: from inet-smtp-gw-1.us.oracle.com by suntan.tandem.com (8.6.12/suntan5.960905) for id SAA16854; Mon, 23 Sep 1996 18:44:22 -0700 Received: from mailsun2.us.oracle.com by inet-smtp-gw-1.us.oracle.com with ESMTP (8.6.12/37.7) id SAA06851; Mon, 23 Sep 1996 18:44:22 -0700 Received: by mailsun2.us.oracle.com (SMI-8.6/37.8) id SAA18456; Mon, 23 Sep 1996 18:48:25 -0700 Message-Id: <199609240148.SAA18456@mailsun2.us.oracle.com> Date: 23 Sep 96 18:04:34 -0700 From: "PALAMBER.US.ORACLE.COM" To: sri@raj.corp.hp.com Subject: Re: Authorization on WEB using Certs? Cc: ietf-pkix@tandem.com X-Orcl-Application: In-Reply-To: UNX02.US.ORACLE.COM:chandras@loc201.tandem.com's message of 23-Sep-96 13:26 MIME-Version: 1.0 X-Mailer: Oracle InterOffice (version 4.0.2.1.40) Content-Type: multipart/mixed; boundary="=_ORCL_7816495_0_11919609231949230" --=_ORCL_7816495_0_11919609231949230 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" The W3C has an activity on "Web Content Signing". Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Secure Jobs" -> send resumes to: palamber@us.oracle.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --=_ORCL_7816495_0_11919609231949230 Content-Type:message/rfc822 Date: 23 Sep 96 13:26:57 From:"Sri Vidya Rajagopal " To:ietf-pkix@tandem.com Subject:Authorization on WEB using Certs? X-Mailer:Elm [revision: 112.2] MIME-Version: 1.0 Content-Transfer-Encoding:7bit Content-Type:text/plain; charset="US-ASCII" Hi! Does anyone know of any standards or document to do AUthorization of Web Documents using Certificates? I am looking for any information/pointers we pages... anything to get me going in the right direction. thanks -sri --=_ORCL_7816495_0_11919609231949230-- From chandras@loc201.tandem.com Tue Sep 24 01:02:40 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id BAA07353; Tue, 24 Sep 1996 01:02:40 -0700 Received: from arachnet.algroup.co.uk by suntan.tandem.com (8.6.12/suntan5.960905) for id BAA07350; Tue, 24 Sep 1996 01:02:35 -0700 Received: from heap.ben.algroup.co.uk by arachnet.algroup.co.uk id aa19164; 24 Sep 96 9:00 BST Received: from gonzo.ben.algroup.co.uk by heap.ben.algroup.co.uk id aa23717; 24 Sep 96 8:13 BST Subject: Re: Authorization on WEB using Certs? To: "PALAMBER.US.ORACLE.COM" Date: Tue, 24 Sep 1996 08:06:38 +0100 (BST) From: Ben Laurie Cc: sri@raj.corp.hp.com, ietf-pkix@tandem.com In-Reply-To: <199609240148.SAA18456@mailsun2.us.oracle.com> from "PALAMBER.US.ORACLE.COM" at Sep 23, 96 06:04:34 pm Reply-To: ben@algroup.co.uk X-Mailer: ELM [version 2.4 PL24 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1830 Message-ID: <9609240806.aa01755@gonzo.ben.algroup.co.uk> PALAMBER.US.ORACLE.COM wrote: > > > --=_ORCL_7816495_0_11919609231949230 > Content-Transfer-Encoding:7bit > Content-Type:text/plain; charset="US-ASCII" > > > The W3C has an activity on "Web Content Signing". Yeah, and its a nice friendly closed group, price of admission $50,000. Cheers, Ben. > > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Paul Lambert Director of Security Products > Oracle Corporation Phone: (415) 506-0370 > 500 Oracle Parkway, Box 659410 Fax: (415) 633-2963 > Redwood Shores, CA 94065 E-Mail: palamber@us.oracle.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Secure Jobs" -> send resumes to: palamber@us.oracle.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > --=_ORCL_7816495_0_11919609231949230 > Content-Type:message/rfc822 > > Date: 23 Sep 96 13:26:57 > From:"Sri Vidya Rajagopal " > To:ietf-pkix@tandem.com > Subject:Authorization on WEB using Certs? > X-Mailer:Elm [revision: 112.2] > MIME-Version: 1.0 > Content-Transfer-Encoding:7bit > Content-Type:text/plain; charset="US-ASCII" > > Hi! > Does anyone know of any standards or document to do AUthorization of > Web Documents using Certificates? I am looking for any information/pointers > we pages... anything to get me going in the right direction. > > > thanks > > -sri > > > --=_ORCL_7816495_0_11919609231949230-- > -- Ben Laurie Phone: +44 (181) 994 6435 Freelance Consultant and Fax: +44 (181) 994 6472 Technical Director Email: ben@algroup.co.uk A.L. Digital Ltd, URL: http://www.algroup.co.uk London, England. Apache Group member (http://www.apache.org) From chandras@loc201.tandem.com Tue Sep 24 13:46:26 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id NAA07612; Tue, 24 Sep 1996 13:46:26 -0700 Received: from defender.cylink.com by suntan.tandem.com (8.6.12/suntan5.960905) for id NAA07594; Tue, 24 Sep 1996 13:46:18 -0700 Received: from cylink by defender.cylink.com with smtp (Smail3.1.29.1 #4) id m0v5eBv-0007CkC; Tue, 24 Sep 96 13:34 PDT Received: from genie.cylink.com by cylink (4.1/SMI-4.1) id AA25481; Tue, 24 Sep 96 13:42:57 PDT Received: from lobster by genie.cylink.com (SMI-8.6/SMI-SVR4) id NAA03943; Tue, 24 Sep 1996 13:42:08 -0700 Received: by lobster with Microsoft Mail id <01BBAA1D.AC418850@lobster>; Tue, 24 Sep 1996 13:38:30 -0700 Message-Id: <01BBAA1D.AC418850@lobster> From: John Marchioni To: "wford@mail.intranet.ca" , "johnmarc@cylink.com" , "cadams@nortel.ca" , "'John Kennedy'" Cc: "ipsec@tis.com" , "ietf-pkix@tandem.com" , "isakmp-oakley@cisco.com" , "skip-info@tik.ee.ethz.ch" Subject: RE: RE: NOTICE: DSS Profile for X.509 Certificates to be deleted. Date: Tue, 24 Sep 1996 13:38:27 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable { JK's comments } Basically, I agree that the X9.57 ARC should be used for certificates = but I=20 disagree regarding the use of the X9.57 ARC for the public numbers and = system parameters. Why not stick with the X.42 ARC for those? Regards, -John Kennedy p.s. For follow-ups, I suggest we prune down the distribution to only = Cc:=20 ietf-pkix@tandem.com and ipsec@tis.com OK by me, I thought X9.42 was still lacking a registered ARC, that's the = only reason I suggested using X9.57's ARC. It would be nice, if X9.57 = does include the Diffie-Hellman certificate profile, to have all related = OIDs for Diffie-Hellman (the X9.42 OID values) also included in X9.57, = just a suggestion. - John Marchioni From chandras@loc201.tandem.com Tue Sep 24 14:51:13 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id OAA15377; Tue, 24 Sep 1996 14:51:13 -0700 Received: from netcomsv.netcom.com by suntan.tandem.com (8.6.12/suntan5.960905) for id OAA15372; Tue, 24 Sep 1996 14:51:11 -0700 Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id OAA26794; Tue, 24 Sep 1996 14:33:28 -0700 Received: from cc:Mail by spysouth.spyrus.com id AA843600677 Tue, 24 Sep 96 14:31:17 Date: Tue, 24 Sep 96 14:31:17 From: "Housley, Russ" Encoding: 2092 Text Message-Id: <9608248436.AA843600677@spysouth.spyrus.com> To: ietf-pkix@tandem.com, mlk@mlksys.atl.ga.us Subject: Re: interchange format for certificates? You are correct that PKIX is not defining a format for the certificate cache; however, Part 2 will address ways to obtain certificates from the net. As you point out, this only deals with a method of obtaining public keys. The transfer of private keys between multiple systems is an open issue. Clearly, people who use hardware tokens do not have a problem. These people simple move the token from system to sytem. Users of software cryptography do need a solution. I know that Microsoft has defined a solution for their environment. Perhaps they are willing to share their solution with the Internet? Russ ______________________________ Reply Separator _________________________________ Subject: interchange format for certificates? Author: anonymous-netscape-user@mlksys.atl.ga.us at internet Date: 9/21/96 7:36 PM Hi, I am not a member of this list so I will not see responses that are not directed to me. I am not sure if the following is something your group would be willing to address. The use of certificates is becoming more common. In my view there appears to be a problem that has yet to be solved: Each vendor stores the X.509 and other certificates in a proprietary file format that cannot be exchanged between computer systems. For example: I have a Macintosh at home and a Windows machine at work. I reciently had to aquire *TWO* certificates from Verisign because they have defined no interchange format allowing me to convert my private keys to an interchange form, copy them to the other system, and reimport them for use in that system. It seems to me that a simple interchange format, possibly patterned after the way the PGP people ASCIIify their keys, would be useful. I do not know why Verisign did not do this for their certificates, but maybe the IETF can define an informational or experimental RFC describing an interchange format and encourage Verisign and other entities to adopt and implement it. What to you all think, mlk@mlksys.atl.ga.us From chandras@loc201.tandem.com Wed Oct 2 04:58:11 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id EAA22288; Wed, 2 Oct 1996 04:58:11 -0700 Received: from relay-4.mail.demon.net by suntan.tandem.com (8.6.12/suntan5.960905) for id EAA22280; Wed, 2 Oct 1996 04:58:08 -0700 Received: from post.demon.co.uk ([(null)]) by relay-4.mail.demon.net id ae26934; 2 Oct 96 9:35 GMT Received: from secstan.demon.co.uk ([158.152.35.12]) by relay-3.mail.demon.net id aa04416; 2 Oct 96 10:27 BST From: Nick Pope To: OSIdirectory@az05.bull.com, pki-twg@csmes.ncsl.nist.gov, ietf-pkix@tandem.com, Warwick Ford Date: Wed, 2 Oct 1996 10:21:29 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: X.509 validity period X-Confirm-Reading-To: Nick Pope X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42a) Message-ID: <844248446.4416.0@secstan.demon.co.uk> Talking about X.509 defects (as in Warwicks recent message), I have come across a more fundamental issue which I would like to get views. I have a client who requires to be able to hold signed documents and their certificates in a long term archive. This necessitates the validity period of the certificates to be potentially longer than 50 years. The current validity period is encoded in UTCTime which has a 2 digit year, which has to be adjusted to cater for the century roll over giving a resolution of only 50 years. Ideally, the validity period should be encoded in generalised time. Has anyone else identified similar concerns? Nick Pope ------------------------------------- Security & Standards Suite A 191 Moulsham St. Chelmsford Essex CM2 0LG U.K. Tel: +44 1245 495018 Fax: +44 1245 494517 From chandras@loc201.tandem.com Wed Oct 2 06:17:25 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id GAA27163; Wed, 2 Oct 1996 06:17:25 -0700 Received: from cs20.cs.auckland.ac.nz by suntan.tandem.com (8.6.12/suntan5.960905) for id GAA27157; Wed, 2 Oct 1996 06:17:22 -0700 From: Received: from cs26.cs.auckland.ac.nz by cs20.cs.auckland.ac.nz (8.7/4.7) id BAA11116; Thu, 3 Oct 1996 01:14:37 +1200 (NZST) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <84426211121235>; Thu, 3 Oct 1996 01:15:11 (NZST) To: OSIdirectory@az05.bull.com, ietf-pkix@tandem.com, pki-twg@csmes.ncsl.nist.gov Subject: Re: X.509 validity period Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Thu, 3 Oct 1996 01:15:11 (NZST) Message-ID: <84426211121235@cs26.cs.auckland.ac.nz> >I have a client who requires to be able to hold signed documents and their >certificates in a long term archive. > >This necessitates the validity period of the certificates to be potentially >longer than 50 years. The current validity period is encoded in UTCTime >which has a 2 digit year, which has to be adjusted to cater for the century >roll over giving a resolution of only 50 years. > >Ideally, the validity period should be encoded in generalised time. Has >anyone else identified similar concerns? In all the code I've seen the practice is to add 100 years to the century if the year is < 70-90 (the exact threshold depends on the implementation. I've never seen a pre-1990 cert so I've used 90). This does mean, though, that you can't do a simple string compare on the encoded time to check date ranges. This is one of the problems which I point out in my X.509 implementation notes. I'll post these to the list for comment in a day or two, after I find a fork and some marshmellows for toasting :-). Peter. From chandras@loc201.tandem.com Wed Oct 2 07:07:32 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id HAA00817; Wed, 2 Oct 1996 07:07:32 -0700 Received: from relay-4.mail.demon.net by suntan.tandem.com (8.6.12/suntan5.960905) for id HAA00812; Wed, 2 Oct 1996 07:07:30 -0700 Received: from post.demon.co.uk ([(null)]) by relay-4.mail.demon.net id af26934; 2 Oct 96 9:35 GMT Received: from secstan.demon.co.uk ([158.152.35.12]) by relay-3.mail.demon.net id aa04417; 2 Oct 96 10:27 BST From: Nick Pope To: OSIdirectory@az05.bull.com, pki-twg@csmes.ncsl.nist.gov, ietf-pkix@tandem.com, Warwick Ford Date: Wed, 2 Oct 1996 09:39:07 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: X.509 Bug Regarding Policy Constraints CC: jsp@jgvandyke.com X-Confirm-Reading-To: Nick Pope X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42a) Message-ID: <844248448.4417.0@secstan.demon.co.uk> In reply to your message of 23 Sep 96, 16:44: I disagree that making this change is appropriate to a defect. It is removing functions from the agreed X.509 amendment. Removing policySet from the extension no longer makes it possible to restrict the policies which may be governed by a CA. The appropriate resolution is to describe how the field is used not remove agreed functionality. Nick Pope > An error has been uncovered regarding policy constraints in the X.509 > certificate extensions amendment. I have drafted the attached defect > report for consideration at the October meeting of the ISO/IEC/ITU > Directory group. I would appreciate hearing from anyone who objects to > policySet being deleted from policy constraints. > > Thanks to John Pawling of JG VanDyke for finding the error. > > Warwick > -------------------------------------- > > ...... > 10. Nature of Defect: (complete, concise explanation of the perceived > problem) > > 12.4.2.3 (Policy constraints field) includes a policySet component in > the ASN.1 and describes its semantics, but the path processing > procedure in 12.4.3 does not include processing for that component. > If processing for policySet were to be added to 12.4.3, the algorithm > would become very complex, with little real benefit. It is the > submitter's contention that policySet should have been removed in the > DAM editing process (the same component was removed from the Name > constraints field), but was inadvertently left in. > > 11. Solution Proposed by the Source: (optional) > > In 12.4.2.3, remove the policySet component from the ASN.1 and delete > the first paragraph after the ASN.1. Also remove the SEQUENCE OF from > the ASN.1, as this becomes unnecessary. Assign the extension a new > OID (id-ce 36) to avoid confusion. Reflect the same ASN.1 changes in > Annex A. > > 12. Editor's Response: > (any material proposed for processing as an erratum to, an amendment > to, or a commentary on the IS or DIS final text/CCITT Recommendation > or Draft Recommendation is attached separately to this completed > report). > > > > > ------------------------------------------------------------------- > Warwick Ford: wford@intranet.ca Tel: (613)2253487 Fax: (613)2256361 > Postal: 25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8 > ------------------------------------------------------------------- > ------------------------------------- Security & Standards Suite A 191 Moulsham St. Chelmsford Essex CM2 0LG U.K. Tel: +44 1245 495018 Fax: +44 1245 494517 From chandras@loc201.tandem.com Wed Oct 2 07:19:06 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id HAA01657; Wed, 2 Oct 1996 07:19:06 -0700 Received: from heaton.cl.cam.ac.uk by suntan.tandem.com (8.6.12/suntan5.960905) for id HAA01636; Wed, 2 Oct 1996 07:19:00 -0700 Received: from cl.cam.ac.uk [128.232.33.87] (mrr) by heaton.cl.cam.ac.uk with esmtp (Exim 0.52 #2) id E0v8S4g-00067t-00; Wed, 2 Oct 1996 15:14:58 +0100 To: Nick Pope cc: OSIdirectory@az05.bull.com, pki-twg@csmes.ncsl.nist.gov, ietf-pkix@tandem.com, Warwick Ford Subject: Re: X.509 validity period In-reply-to: Nick Pope's message of Wed, 02 Oct 1996 10:21:29 -0000. <844248446.4416.0@secstan.demon.co.uk> Date: Wed, 02 Oct 1996 15:14:47 +0100 From: Michael Roe Message-Id: > Ideally, the validity period should be encoded in generalised > time. Has anyone else identified similar concerns? Yes - this issue keeps coming up. My most recent re-encounter with this problem was in the context of the (UK) National Health Service's network. The year 2000 is only 4 years away, so it's necessary to do *something* about this problem now, even if all you do is make an agreement that within your domain the year '01' is 2001 not 1901. This quick fix buys you time, but is storing up trouble for the future. If you have data that is likely to live for more than 50 years, a proper solution is called for. > This necessitates the validity period of the certificates to be > potentially longer than 50 years. Actually, I belive that it isn't necessary for the validity period to be longer than 50 years, this arises out of the discussion we had on what the validity period actually means. Revocation information is guaranteed to be available in the Directory (if you have one :-) ) during the validity period, but may be available by other means after the end of the validity period. Thus, is may be possible to verify a historical document long after its accompanying certificate has expired. (I don't intend to re-open the argument about the validity period! I'm just pointing out that some of the discussion we had might be relevent in this application). Finally, if you intend on keeping documents for >50 years, I would recommend using additonal methods over and above digital signature to ensure integrity. (e.g. keeping a copy physically secure etc.). Mike From chandras@loc201.tandem.com Wed Oct 2 09:41:00 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id JAA16410; Wed, 2 Oct 1996 09:41:00 -0700 Received: from mailsrvr.az05.bull.com by suntan.tandem.com (8.6.12/suntan5.960905) for id JAA16404; Wed, 2 Oct 1996 09:40:57 -0700 Received: from smtplink.az05.bull.com (smtplink.az05.bull.com [141.112.29.62]) by mailsrvr.az05.bull.com (8.6.8.1/8.6.6) with SMTP id JAA03935; Wed, 2 Oct 1996 09:14:33 -0700 From: H.Kesterson@az05.bull.com Received: from ccMail by smtplink.az05.bull.com (SMTPLINK V2.11 PreRelease 4) id AA844272935; Wed, 02 Oct 96 09:11:12 MST Date: Wed, 02 Oct 96 09:11:12 MST Message-Id: <9609028442.AA844272935@smtplink.az05.bull.com> To: Nick Pope , OSIdirectory@az05.bull.com, pki-twg@csmes.ncsl.nist.gov, ietf-pkix@tandem.com, wford@mail.intranet.ca Cc: jsp@jgvandyke.com Subject: Re[2]: X.509 Bug Regarding Policy Constraints nick, i assume that you are unhappy with the solution proposed by the defect. do you agree that there is a defect in the standard concerned with the handling of policySet? if so, a defect would seem to be the appropriate way of handling it. if we could come to a successful resolution of the defect, i hope to get an approved tc in time for incorporation into the published standard (using the delay imposed by the itu approval period) hoyt _______________________________________________________________________________ Subject: Re: X.509 Bug Regarding Policy Constraints From: Nick Pope at AZ05-SMTP Date: 10/2/96 8:42 In reply to your message of 23 Sep 96, 16:44: I disagree that making this change is appropriate to a defect. It is removing functions from the agreed X.509 amendment. Removing policySet from the extension no longer makes it possible to restrict the policies which may be governed by a CA. The appropriate resolution is to describe how the field is used not remove agreed functionality. Nick Pope > An error has been uncovered regarding policy constraints in the X.509 > certificate extensions amendment. I have drafted the attached defect > report for consideration at the October meeting of the ISO/IEC/ITU > Directory group. I would appreciate hearing from anyone who objects to > policySet being deleted from policy constraints. > > Thanks to John Pawling of JG VanDyke for finding the error. > > Warwick > -------------------------------------- > > ...... > 10. Nature of Defect: (complete, concise explanation of the perceived > problem) > > 12.4.2.3 (Policy constraints field) includes a policySet component in > the ASN.1 and describes its semantics, but the path processing > procedure in 12.4.3 does not include processing for that component. > If processing for policySet were to be added to 12.4.3, the algorithm > would become very complex, with little real benefit. It is the > submitter's contention that policySet should have been removed in the > DAM editing process (the same component was removed from the Name > constraints field), but was inadvertently left in. > > 11. Solution Proposed by the Source: (optional) > > In 12.4.2.3, remove the policySet component from the ASN.1 and delete > the first paragraph after the ASN.1. Also remove the SEQUENCE OF from > the ASN.1, as this becomes unnecessary. Assign the extension a new > OID (id-ce 36) to avoid confusion. Reflect the same ASN.1 changes in > Annex A. > > 12. Editor's Response: > (any material proposed for processing as an erratum to, an amendment > to, or a commentary on the IS or DIS final text/CCITT Recommendation > or Draft Recommendation is attached separately to this completed > report). > > > > > ------------------------------------------------------------------- > Warwick Ford: wford@intranet.ca Tel: (613)2253487 Fax: (613)2256361 > Postal: 25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8 > ------------------------------------------------------------------- > ------------------------------------- Security & Standards Suite A 191 Moulsham St. Chelmsford Essex CM2 0LG U.K. Tel: +44 1245 495018 Fax: +44 1245 494517 From chandras@loc201.tandem.com Wed Oct 2 10:57:54 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id KAA26858; Wed, 2 Oct 1996 10:57:54 -0700 Received: from novell.com by suntan.tandem.com (8.6.12/suntan5.960905) for id KAA26836; Wed, 2 Oct 1996 10:57:38 -0700 Received: from INET-PRV-Message_Server by novell.com with Novell_GroupWise; Wed, 02 Oct 1996 11:57:39 -0600 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 02 Oct 1996 11:56:56 -0600 From: Bob Jueneman To: Michael.Roe@cl.cam.ac.uk, pope@secstan.demon.co.uk Cc: OSIdirectory@az05.bull.com, pki-twg@csmes.ncsl.nist.gov, wford@mail.intranet.ca, ietf-pkix@tandem.com Subject: Re: X.509 validity period -Reply I have to add my two cents to Michael Roe's comments. I think that it is absurd that we are still trying to save bits in some of these fields. Using generalized time everywhere, instead of UTC time, is something that should have been fixed when we went to V3. The self-describing nature of ASN.1 would have made it easy, and there weren't more than a small handful of certificates in existence, so backward compatibility wouldn't have been a serious issue. Unfortunately, at the snail's pace with which most standards progress, 2000 will be here before we get a fix, so ad hoc solutions are going to be required. Maybe by 2100? >> This necessitates the validity period of the certificates to be >> potentially longer than 50 years. >Actually, I believe that it isn't necessary for the validity period to be longer than 50 years, this arises out of the discussion we had on what the validity period actually means. Revocation information is guaranteed to be available in the Directory (if you have one :-) ) during the validity period, but may be available by other means after the end of the validity period. Thus, is may be possible to verify a historical document long after its accompanying certificate has expired. I don't think Michael's comments were strong enough. (Maybe he was just exercising admirable British understatement and restraint. :-) I believe it would be completely unreasonable to have a certificate validity period anywhere near 50 years. The primary purpose of the validity period is, IMHO, to provide a limit as to the amount of bookkeeping that has to be done by a CA or trusted repository provider in terms of CRL management. If very many certificates had 50 year validity periods, and were ever revoked, those certificates would have to be included in the CA's CRL list for the next 50 years, long after most people would care. Don't forget that the purpose of a certificate is to document the binding that exists between a named entity (assuming that there is a name) and the public key (and by inference, the corresponding private key) AT THE TIME THE CERTIFICATE WAS ISSUED. Depending on the details of the CA's Certification Practice Statement, the CA is under no obligation to maintain continuous vigilance to ensure that the binding continues to be factually correct. And to expect that the binding would continue to be correct for 50 years is almost ludicrous. The subject would very likely have moved, changed jobs, or even died during that time period. In addition, it is highly unlikely that the degree of cryptographic security which is economically affordable now would continue to be adequate to resist reasonable threats for 50 years -- the keys would have to be impractically long. I believe that your question is due to the confusion between the technical concept of non-repudiation in the computer security context, vs. the reality of the legal context. First of all, there is no such thing in the legal context of a nonrepudiable signature -- a signature can always be contested because of fraud, forgery, duress, mental or legal incompetence, and a host of other reasons. But on the other hand, the revocation or expiration of a certificate does not in and of itself invalidate a digital signature as a legally binding signature -- it just makes the validity of the signature someone more difficult to prove. This is where business records, physical protection, and even motive and opportunity come into play. And in most cases, the rules of evidence and the required standard of proof is far less than that required in criminal proceedings of "beyond reasonable doubt." It isn't even "clear and convincing," but most of the time is simply the relatively weak "preponderance of the evidence." So I would submit that your customer does not in fact need a 50 year validity period, nor would it be meaningful even if it were technically feasible. Instead, they need to rethink or restate their requirements, or you need to rethink your solution to those requirements. Bob From chandras@loc201.tandem.com Wed Oct 2 12:46:00 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id MAA09667; Wed, 2 Oct 1996 12:46:00 -0700 Received: from rosetta.verisign.com by suntan.tandem.com (8.6.12/suntan5.960905) for id MAA09663; Wed, 2 Oct 1996 12:45:59 -0700 Received: from dustin.verisign.com (gateway-outside [204.162.64.20]) by rosetta.verisign.com (8.7.4/8.6.12) with ESMTP id MAA06834; Wed, 2 Oct 1996 12:45:26 -0700 (PDT) Received: from Peter.verisign.com (Peter.verisign.com [192.42.157.77]) by dustin.verisign.com (8.7.4/8.6.12) with SMTP id MAA11899; Wed, 2 Oct 1996 12:45:38 -0700 (PDT) Received: by Peter.verisign.com with Microsoft Mail id <01BBB05F.C2B0D0D0@Peter.verisign.com>; Wed, 2 Oct 1996 12:46:41 -0700 Message-ID: <01BBB05F.C2B0D0D0@Peter.verisign.com> From: Peter Williams To: "'Bob Jueneman'" Cc: "ietf-pkix@tandem.com" Subject: RE: X.509 validity period -Reply Date: Wed, 2 Oct 1996 12:46:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bob, We have offered clients, who have signed document longetivity requirements, that as their CA, we put an additional field in the cert, namely a generalized time. This is not used in practical signature validation, but, for no measurable cost, can be used as another piece of ammunition in dispute handling, should there be any ambiguity claims. As, in US law, *everything* is up for claim and counter-claim anyway, its the presence of additional ammunition which practically matters when dispute handling, surely. The number of clients who have required this service, given the informed choice, is zero. Perhaps this will change. We have also recommend to them that they date any material which they sign if they intend the message signature to be contested in a law setting, regardless of certs and signatures, etc. Its just good legally oriented risk management. In the case of CA signing their messages (namely certs) a commercial CA has to maintain auditable records anyway, whose storage properties are used (not arguable data element) to provide high-end assurnaces for highly-contested evidence. ONe can argue that a 50 year ssigned-dlcument torage would be required to demonstrate such care, also, as its unlikely the keying material or algoirhtm will be strong enough over 50 years, anyway. Remember, not everyone wants high-end assurnaces, or the costs. Forcing high-end security on folk is like ramming X.400 down everyone's throat. It just will not work. The std currently allows for both *(and any additional) time services, each used when there is need. Forcing every internet mail to be signed, or when signed, it must be legally dated, is not on. People should be able to send any quality of signed mail they desire, not that which only suits lawyers or other legal needs. Whats the problem? Is the std too flexible, for American freedoms, in allowing choice and handling of risks at the individual's level? Peter. ---------- From: Bob Jueneman Sent: Wednesday, October 02, 1996 10:56 AM To: Michael.Roe@cl.cam.ac.uk; pope@secstan.demon.co.uk Cc: OSIdirectory@az05.bull.com; pki-twg@csmes.ncsl.nist.gov; wford@mail.intranet.ca; ietf-pkix@tandem.com Subject: Re: X.509 validity period -Reply I have to add my two cents to Michael Roe's comments. I think that it is absurd that we are still trying to save bits in some of these fields. Using generalized time everywhere, instead of UTC time, is something that should have been fixed when we went to V3. The self-describing nature of ASN.1 would have made it easy, and there weren't more than a small handful of certificates in existence, so backward compatibility wouldn't have been a serious issue. Unfortunately, at the snail's pace with which most standards progress, 2000 will be here before we get a fix, so ad hoc solutions are going to be required. Maybe by 2100? >> This necessitates the validity period of the certificates to be >> potentially longer than 50 years. >Actually, I believe that it isn't necessary for the validity period to be longer than 50 years, this arises out of the discussion we had on what the validity period actually means. Revocation information is guaranteed to be available in the Directory (if you have one :-) ) during the validity period, but may be available by other means after the end of the validity period. Thus, is may be possible to verify a historical document long after its accompanying certificate has expired. I don't think Michael's comments were strong enough. (Maybe he was just exercising admirable British understatement and restraint. :-) I believe it would be completely unreasonable to have a certificate validity period anywhere near 50 years. The primary purpose of the validity period is, IMHO, to provide a limit as to the amount of bookkeeping that has to be done by a CA or trusted repository provider in terms of CRL management. If very many certificates had 50 year validity periods, and were ever revoked, those certificates would have to be included in the CA's CRL list for the next 50 years, long after most people would care. Don't forget that the purpose of a certificate is to document the binding that exists between a named entity (assuming that there is a name) and the public key (and by inference, the corresponding private key) AT THE TIME THE CERTIFICATE WAS ISSUED. Depending on the details of the CA's Certification Practice Statement, the CA is under no obligation to maintain continuous vigilance to ensure that the binding continues to be factually correct. And to expect that the binding would continue to be correct for 50 years is almost ludicrous. The subject would very likely have moved, changed jobs, or even died during that time period. In addition, it is highly unlikely that the degree of cryptographic security which is economically affordable now would continue to be adequate to resist reasonable threats for 50 years -- the keys would have to be impractically long. I believe that your question is due to the confusion between the technical concept of non-repudiation in the computer security context, vs. the reality of the legal context. First of all, there is no such thing in the legal context of a nonrepudiable signature -- a signature can always be contested because of fraud, forgery, duress, mental or legal incompetence, and a host of other reasons. But on the other hand, the revocation or expiration of a certificate does not in and of itself invalidate a digital signature as a legally binding signature -- it just makes the validity of the signature someone more difficult to prove. This is where business records, physical protection, and even motive and opportunity come into play. And in most cases, the rules of evidence and the required standard of proof is far less than that required in criminal proceedings of "beyond reasonable doubt." It isn't even "clear and convincing," but most of the time is simply the relatively weak "preponderance of the evidence." So I would submit that your customer does not in fact need a 50 year validity period, nor would it be meaningful even if it were technically feasible. Instead, they need to rethink or restate their requirements, or you need to rethink your solution to those requirements. Bob From chandras@loc201.tandem.com Wed Oct 2 14:06:41 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id OAA18176; Wed, 2 Oct 1996 14:06:41 -0700 Received: from mail.intranet.ca by suntan.tandem.com (8.6.12/suntan5.960905) for id OAA18166; Wed, 2 Oct 1996 14:06:38 -0700 Received: from wford.intranet.ca (ppp44.intranet.ca [206.51.251.144]) by mail.intranet.ca (8.6.11/8.6.9) with SMTP id QAA04782; Wed, 2 Oct 1996 16:51:37 -0400 Message-Id: <2.2.32.19961002215047.006bea70@mail.intranet.ca> X-Sender: wford@mail.intranet.ca X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Oct 1996 17:50:47 -0400 To: Nick Pope , OSIdirectory@az05.bull.com, pki-twg@csmes.ncsl.nist.gov, ietf-pkix@tandem.com From: Warwick Ford Subject: Re: X.509 Bug Regarding Policy Constraints Cc: jsp@jgvandyke.com Nick: The proposal is to remove policySet from the policy constraints extension - not the certificate policies extension. How do you see this impacting the ability to restrict the policies that may be governed by a CA? Warwick At 09:39 AM 10/2/96 +0000, Nick Pope wrote: >In reply to your message of 23 Sep 96, 16:44: > >I disagree that making this change is appropriate to a defect. It is removing >functions from the agreed X.509 amendment. > >Removing policySet from the extension no longer makes it possible to >restrict the policies which may be governed by a CA. > >The appropriate resolution is to describe how the field is used not >remove agreed functionality. > >Nick Pope > >> An error has been uncovered regarding policy constraints in the X.509 >> certificate extensions amendment. I have drafted the attached defect >> report for consideration at the October meeting of the ISO/IEC/ITU >> Directory group. I would appreciate hearing from anyone who objects to >> policySet being deleted from policy constraints. >> >> Thanks to John Pawling of JG VanDyke for finding the error. >> >> Warwick >> -------------------------------------- >> >> >...... > >> 10. Nature of Defect: (complete, concise explanation of the perceived >> problem) >> >> 12.4.2.3 (Policy constraints field) includes a policySet component in >> the ASN.1 and describes its semantics, but the path processing >> procedure in 12.4.3 does not include processing for that component. >> If processing for policySet were to be added to 12.4.3, the algorithm >> would become very complex, with little real benefit. It is the >> submitter's contention that policySet should have been removed in the >> DAM editing process (the same component was removed from the Name >> constraints field), but was inadvertently left in. >> >> 11. Solution Proposed by the Source: (optional) >> >> In 12.4.2.3, remove the policySet component from the ASN.1 and delete >> the first paragraph after the ASN.1. Also remove the SEQUENCE OF from >> the ASN.1, as this becomes unnecessary. Assign the extension a new >> OID (id-ce 36) to avoid confusion. Reflect the same ASN.1 changes in >> Annex A. >> >> 12. Editor's Response: >> (any material proposed for processing as an erratum to, an amendment >> to, or a commentary on the IS or DIS final text/CCITT Recommendation >> or Draft Recommendation is attached separately to this completed >> report). >> >> >> >> >> ------------------------------------------------------------------- >> Warwick Ford: wford@intranet.ca Tel: (613)2253487 Fax: (613)2256361 >> Postal: 25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8 >> ------------------------------------------------------------------- >> > >------------------------------------- > > >Security & Standards >Suite A >191 Moulsham St. >Chelmsford >Essex >CM2 0LG >U.K. > >Tel: +44 1245 495018 >Fax: +44 1245 494517 > > ------------------------------------------------------------------- Warwick Ford: wford@intranet.ca Tel: (613)2253487 Fax: (613)2256361 Postal: 25 Assiniboine Drive, Nepean, Ontario, Canada K2E5R8 ------------------------------------------------------------------- From chandras@loc201.tandem.com Wed Oct 2 15:01:30 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id PAA25095; Wed, 2 Oct 1996 15:01:30 -0700 Received: from dfw-ix11.ix.netcom.com by suntan.tandem.com (8.6.12/suntan5.960905) for id PAA25088; Wed, 2 Oct 1996 15:01:28 -0700 Received: from kaye---win-95 (scz-ca7-25.ix.netcom.com [204.31.227.57]) by dfw-ix11.ix.netcom.com (8.6.13/8.6.12) with SMTP id OAA26973; Wed, 2 Oct 1996 14:41:28 -0700 Message-Id: <2.2.32.19961002214325.00a15a08@popd.ix.netcom.com> X-Sender: kaye@popd.ix.netcom.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 02 Oct 1996 14:43:25 -0700 To: KCaldwell@SoftwareIndustry.org From: Kaye Caldwell Subject: ** 10/8 Digital Signatures Working Group Meeting ** RSVP REQUIRED Apologies for duplicates - some of you I'm sure are on multiple notice lists for this. California Digital Signature Regulations Working Group sponsored by the Software Industry Coalition and CommerceNet THIS MEETING IS OPEN TO ANYONE WHO WISHES TO ATTEND However, you MUST let me know if you will be attending via e-mail to: kaye@ix.netcom.com or by replying to this message. Those who RSVP will receive e-mail on the exact location and directions to the meeting. (Sorry about that but we MUST have a fairly accurate RSVP count since the host is being so kind as to supply us with a working lunch.) PLEASE RSVP by the end of the day on Thursday 10/3/96. WHEN: Tuesday October 8th, 9:30 AM - 1 PM (Working lunch will be provided.) WHERE: Cupertino, CA Note: For those of you trying to schedule these meetings, we are meeting every other Tuesday, sometimes in the am, sometimes in the pm, usually in or close to Silicon Valley. AGENDA I. Report on status of Secretary of State's Task Force II. Review of current draft of outline of regulations III. Consideration of additional topics: what is publication, what are liability issues for subscriber Web page for Background on the Working Group: http://www.softwareIndustry.org/coalition/dswgopen.html Digital Signature Background page: http://www.softwareIndustry.org/issues/1digsig.html For more information, e-mail Kaye Caldwell at kaye@ix.netcom.com or call 408-479-8743. Kaye Caldwell Software Industry Coalition Policy Director CommerceNet Adovocacy and Public Policy Committee Chair ------------------------------- =========================================================================== Kaye Caldwell Phone:(408)479-8743 Fax:(408) 479-9247 E-mail:kaye@ix.netcom.com Editor, Software Industry Issues (Web: http://www.SoftwareIndustry.org/issues/) Policy Director, Software Industry Coalition (Web: http://www.SoftwareIndustry.org/coalition/) President, Computer Software Industry Association (Web: http://www.SoftwareIndustry.org/csia/) Legislative Director, Software Forum (Web: http://www.SoftwareForum.org/) =========================================================================== From chandras@loc201.tandem.com Wed Oct 2 20:02:16 1996 Received: by suntan.tandem.com (8.6.12/suntan5.960905) for ietf-pkix-relay id UAA24216; Wed, 2 Oct 1996 20:02:16 -0700 Received: from cs20.cs.auckland.ac.nz by suntan.tandem.com (8.6.12/suntan5.960905) for id UAA24212; Wed, 2 Oct 1996 20:02:12 -0700 From: Received: from cs26.cs.auckland.ac.nz by cs20.cs.auckland.ac.nz (8.7/4.7) id PAA26661; Thu, 3 Oct 1996 15:02:22 +1200 (NZST) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <84431177624247>; Thu, 3 Oct 1996 15:02:56 (NZST) To: ietf-pkix@tandem.com Subject: X.509 implementation notes Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Thu, 3 Oct 1996 15:02:56 (NZST) Message-ID: <84431177624247@cs26.cs.auckland.ac.nz> I've been putting together a few notes on X.509 implementation issues over the last few days after discussion with other people revealed that there seems to be a lot of confusion over how these should be done. A very rough first draft is included below, if anyone has any comments on them please let me know. I'll probably put this on the web somewhere when its finished since it seems there's a need for this sort of thing. Just give me a minute to get a fork and some marshmellows before you reply :-). Peter. X.509 Implementation Notes ========================== Peter Gutmann, pgut001@cs.auckland.ac.nz 30 October 1996 Anyone who has had to work with X.509 has probably experienced what can best be described as ISO water torture, which involves ploughing through all sorts of ISO, ANSI, ITU, and IETF standards, amendments, meeting notes, draft standards, committee drafts, working drafts, and other work-in-progress documents, some of which are best understood when held upside-down in front of a mirror. Because of this confusion, noone seems to know how to implement X.509 certificates properly (see 'Known Bugs' below). This document is an attempt at providing a cookbook for certificates which should give you everything that you can't find anywhere else without devoting your life to the search, as well as comments on what you'd typically expect to find in certificates. The conventions used are: - All encodings follow the DER unless otherwise noted. - Most of the formats are ASN.1. Occasionally 15 levels of indirection are cut out to make things easier to understand. - Questions are marked by '=>' at the start. If anyone has any comments on these please let me know. Certificate ----------- Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING } The encoding of the Certificate may follow the BER rather than the DER. At least one implementation uses the indefinite-length encoding form for the SEQUENCE. TBSCertificate -------------- TBSCertificate ::= SEQUENCE { version [ 0 ] Version DEFAULT v1(0), serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [ 1 ] IMPLICIT UniqueIdentifier OPTIONAL, subjectUniqueID [ 2 ] IMPLICIT UniqueIdentifier OPTIONAL, extensions [ 3 ] Extensions OPTIONAL } Version ------- Version ::= INTEGER { v1(0), v2(1), v3(2) } The default version is v1(0). If the issuerUniqueID or subjectUniqueID are present than the version must be v2(1) or v3(2). If extensions are present than the version must be v3(2). An implementation should target v3 certificates, which is what everyone is moving towards. SerialNumber ------------ CertificateSerialNumber ::= INTEGER This should be unique for each certificate issued by a CA (typically a CA will keep a counter in persistent store somewhere, perhaps a config file under Unix and in the registry under Windows). Another way is to take the current time in seconds and subtract some base time like the first time you ran the software, to keep the numbers manageable. Serial numbers aren't necessarily restricted to 32-bit quantitues. For example the RSADSI Commercial Certification Authority serial number is 0x0241000016, which is larger than 32 bits. If you're writing certificate-handling code, just treat them as a blob which happens to be an encoded integer. Signature --------- This rather misnamed field contains the algorithm identifier for the signature algorithm used by the CA to sign the certificate. There doesn't seem to be much use for this field, although you should check that the algorithm identifier matches the one of the signature on the cert (if anyone can forge the signature on the cert then they can also change the inner algorithm identifier, it's possible that this was included because of some obscure attack where someone who could convince (broken) signature algorithm A to produce the same signature value as (secure) algorithm B could change the outer, unprotected algorithm identifier from B to A, but couldn't change the inner identifier without invalidating the signature. What this would achieve is unclear). Name ---- Name ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET OF AttributeValueAssertion AttributeValueAssertion ::= SEQUENCE { attributeType OBJECT IDENTIFIER, attributeValue ANY } This is used to encode that wonderful ISO creation, the Distinguished Name (DN), a path through an X.500 directory information tree (DIT) which uniquely identifies everything on earth. Although the RelativeDistinguishedName (RDN) is given as a SET OF AttributeValueAssertion (AVA) each set should only contain one element. However it *may* contain more than one, there has been a reported case of a certificate which contained more than one element in the SET. => How are these handled? If you've got an entry with a CN and extra attributes of email address and phone number it's obvious to a human that the CN is the important one, but how do you handle it in software? When encoding sets with cardinality > 1, you need to take care to follow the DER rules which say that they should be ordered by their encoded values (although ASN.1 says a SET is unordered, the DER adds ordering rules to ensure it can be encoded in an unambiguous manner). What you need to do is encode each value in the set, then sort them by the encoded values, and output them wrapped up in the SET OF encoding. You don't have to use a Name for the subject name if you don't want to; there is a subjectAltName extension which allows use of email addresses or URL's. If you want to do this, make the Name an empty sequence and include a subjectAltName extension and mark it critical. Because of this, you should be prepared to accept a zero-length sequence for the subject name in version 3 certificates. Typically you would expect to find the following types of AVA's in an X.509 certificate, starting from the top: countryName ::= SEQUENCE { { 2 5 4 6 }, StringType( SIZE( 2 ) ) } organization ::= SEQUENCE { { 2 5 4 10 }, StringType( SIZE( 1...64 ) ) } organizationalUnitName ::= SEQUENCE { { 2 5 4 11 }, StringType( SIZE( 1...64 ) ) } commonName ::= SEQUENCE { { 2 5 4 3 }, StringType( SIZE( 1...64 ) ) } The countryName is the ISO 3166 code for the country. A StringType is either a TeletexString, a PrintableString, a UniversalString, or an IA5String. There appears to be some confusion about what format a Name in a certificate should take. In theory it should be a full, proper DN, which traces a path through the X.500 DIT, eg: C=US/L=Area 51/O=Hanger 13/OU=X.500 Standards Designers/CN=John Doe but since the DIT's usually don't exist, exactly what format the DN should take seems open to debate. Some implementations seem to let you stuff anything with an OID into a DN. => Are there any guidelines for this? DN's are a very awkward way to handle information about a certificate because most people will want to associate an email address and a name with a certificate and no more. If you want to take the easy way out, use an empty sequence for the subjectName, provide an email address as a subjectAltName extension, and mark it critical. Validity -------- Validity ::= SEQUENCE { notBefore UTCTIME, notAfter UTCTIME } The IETF recommends that all times be expressed in GMT and seconds not be encoded, giving: YYMMDDHHMMZ as the time encoding. However certificates have been found which include seconds. This doesn't lead to an ambiguous encoding because you should never encode a value of 00 seconds, which means if you read in a UTCTime value generated by an implementation which doesn't use seconds and write it out again with an implementation which does, it'll have the same encoding because the 00 won't be encoded. Non-GMT encodings have never been reported, but it may be a good idea to include handling for the "+/-xxxx" time offset format just in case (but flag it as a decoding error). In coming up with the worlds least efficient time encoding format, the ISO nevertheless decided to forgo the encoding of centuries, so if you find a year less than 80, add 100 to the century. UniqueIdentifier ---------------- UniqueIdentifier ::= BITSTRING These were added in X509v2 to handle the possible reuse of subject and/or issuer names over time. Their use is deprecated by the IETF. If you're writing certificate-handling code, just treat them as a blob which happens to be an encoded bitstring. No occurrences of a UniqueIdentifier have been reported. Extensions ---------- Extensions ::= SEQUENCE OF Extension Extension ::= SEQUENCE { extnid OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTETSTRING } X.509 certificate extensions are like a LISP property list: an ISO-standardised place to store crufties. Extensions can consists of key and policy information, certificate subject and issuer attributes, certificate path constraints, CRL distribution points, and private extensions. [There are large numbers of these things. If people can tell me what they've encountered in the past I'll document them] Netscape have quite a few defined for things like CRL URL's and SET defines a few as well, but none have ever been spotted in the wild. Open Issues ----------- The creation of a no-authentication certificate (which is the equivalent of an unsigned PGP key which states something like "Noone has certified this key, but here it is anyway") is possible using self-signed certificates. Technically this isn't a legal wa