From turners@ieca.com Thu Jan 6 11:02:32 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45F33A6CC6 for ; Thu, 6 Jan 2011 11:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-AIfHuGs5Yn for ; Thu, 6 Jan 2011 11:02:31 -0800 (PST) Received: from nm16.bullet.mail.ac4.yahoo.com (nm16.bullet.mail.ac4.yahoo.com [98.139.52.213]) by core3.amsl.com (Postfix) with SMTP id CBCEB3A6C9B for ; Thu, 6 Jan 2011 11:02:30 -0800 (PST) Received: from [98.139.52.197] by nm16.bullet.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 19:04:35 -0000 Received: from [98.139.52.137] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 19:04:35 -0000 Received: from [127.0.0.1] by omp1020.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 19:04:35 -0000 X-Yahoo-Newman-Id: 88794.67554.bm@omp1020.mail.ac4.yahoo.com Received: (qmail 68125 invoked from network); 6 Jan 2011 19:04:35 -0000 Received: from thunderfish.local (turners@96.231.125.241 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 06 Jan 2011 11:04:34 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 3YOdT9gVM1nvVHnhHJm1w37FfP323lZgnDjVDLtf0v2hl1C Farb9V7HiAJ4g0Tsp8wQBepngJhrEE6APPSzrbKAxCNWMMAWjkuXHTxF4FtR GKoWh82gDufWDZOploOBW4Ad8mxcpFm9VDXIg75NqPYhwMCkNpnfAhFYcdvb p6pqddSMHCB3TqaTCJrbHvZTqHo_hPKF9SMfsF9DZgnOYNOVDhwJ.FpacaCG YUacFUV.P5D1E8IKGvuPjsYFkKhtlSyv1gStgw7mbyfzT6L0OmT2TxxdA4AS ZRQoB.FcY2JNAnEs7jP7whaDipDVM1uz17BQHfVGh0OyQRvNz.KkKqfOLD2c oPAMFQrytgTXqwk4WmPgW43RKfLEpD9IIxYGnBLzvSUBA7oSyf6eNHEJA9KA q2_H2rpfSX.zbxW95JBhgGv4AT19JuwlKxM_5aNs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D261242.103@ieca.com> Date: Thu, 06 Jan 2011 14:04:34 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: smime@ietf.org Content-Type: multipart/mixed; boundary="------------070204050202050005020007" Subject: [smime] Fwd: I-D Action:draft-hernandez-ardieta-smime-eesp-00.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 19:02:32 -0000 This is a multi-part message in MIME format. --------------070204050202050005020007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Some on this mailing list might find this of interest. It's headed for experimental. The authors have asked for comments. spt -------- Original Message -------- Subject: I-D Action:draft-hernandez-ardieta-smime-eesp-00.txt Date: Thu, 23 Dec 2010 10:00:02 -0800 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extended Electronic Signature Policies Author(s) : J. Hernandez-Ardieta Filename : draft-hernandez-ardieta-smime-eesp-00.txt Pages : 21 Date : 2010-12-23 This document defines extended electronic signature policies (ext-SP) that extend the boundaries of the electronic signature policy defined in [RFC3125] in a manner that the relationships and dependences among multiple electronic signatures generated within the scope of the same electronic transaction can be established. A given legal/contractual context may recognize a particular ext-SP as meeting its requirements. An ext-SP has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation. The ext-SP can be defined in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied. To allow for the automatic processing, the ext-SP specifies, using a computer processable form, the timing and sequence dependencies of the set of signatures that must be generated to make the transaction effective along with the set of attributes and rules that each signature must comply with. In the current document the format of the ext-SP is defined using ASN.1. The content of this document is based on the requirements and needs established in ETSI TR 102 045 V1.1.1 (2003-03) Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org. Discussion This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to smime-request@ietf.org with the single word subscribe in the body of the message. There is a Web site for the mailing list at https://www.ietf.org/mailman/listinfo/smime. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hernandez-ardieta-smime-eesp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------070204050202050005020007 Content-Type: Message/External-body; name="draft-hernandez-ardieta-smime-eesp-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-hernandez-ardieta-smime-eesp-00.txt" Content-Type: text/plain Content-ID: <2010-12-23095407.I-D@ietf.org> --------------070204050202050005020007 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------070204050202050005020007-- From ietf@augustcellars.com Thu Jan 6 13:32:40 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6EC3A6CEC for ; Thu, 6 Jan 2011 13:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOsDwQO3W+1E for ; Thu, 6 Jan 2011 13:32:40 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id 1B4C23A6BD9 for ; Thu, 6 Jan 2011 13:32:40 -0800 (PST) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id D0CAE6EF4B for ; Thu, 6 Jan 2011 13:34:46 -0800 (PST) From: "Jim Schaad" To: References: <20110106212936.563F53A6CEC@core3.amsl.com> In-Reply-To: <20110106212936.563F53A6CEC@core3.amsl.com> Date: Thu, 6 Jan 2011 13:51:45 -0800 Message-ID: <009301cbadeb$e9c03a00$bd40ae00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI+56gtIaeFT9qh6rMK8DLIM1hZapLeCHKA Content-Language: en-us Subject: [smime] FW: New Version Notification for draft-schaad-smime-hash-experiment-04 X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 21:32:40 -0000 This version addresses all last call comments. Jim -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Thursday, January 06, 2011 1:30 PM To: ietf@augustcellars.com Subject: New Version Notification for = draft-schaad-smime-hash-experiment-04=20 A new version of I-D, draft-schaad-smime-hash-experiment-04.txt has been = successfully submitted by Jim Schaad and posted to the IETF repository. Filename: draft-schaad-smime-hash-experiment Revision: 04 Title: Experiment: Hash functions with parameters in CMS and S/MIME Creation_date: 2011-01-06 WG ID: Independent Submission Number_of_pages: 19 Abstract: New hash algorithms are being developed and these algorithms may include = parameters. CMS has not currently defined any hash algorithms with = parameters, but anecdotic evidence suggests that defining one could = cause major problems. In this document we define just such an algorithm = and describe how to use it so that we can run experiments to find out = how bad including hash parameters will be. = =20 The IETF Secretariat. From ietf@augustcellars.com Thu Jan 6 13:33:02 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 786683A6F4C for ; Thu, 6 Jan 2011 13:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qI93+aMGsSjl for ; Thu, 6 Jan 2011 13:33:01 -0800 (PST) Received: from new-smtp02.pacifier.net (new-smtp02.pacifier.net [64.255.237.176]) by core3.amsl.com (Postfix) with ESMTP id 9F1913A6BD9 for ; Thu, 6 Jan 2011 13:33:01 -0800 (PST) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp02.pacifier.net (Postfix) with ESMTPSA id A686E2CA39 for ; Thu, 6 Jan 2011 13:35:08 -0800 (PST) From: "Jim Schaad" To: References: <20110106212951.99B873A6CEC@core3.amsl.com> In-Reply-To: <20110106212951.99B873A6CEC@core3.amsl.com> Date: Thu, 6 Jan 2011 13:52:06 -0800 Message-ID: <009401cbadeb$f69dd610$e3d98230$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG+Qe+NAc+lh9aLGDYFVgPidh04wpPfVABQ Content-Language: en-us Subject: [smime] FW: New Version Notification for draft-schaad-smime-algorithm-attribute-04 X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 21:33:02 -0000 This version addresses all last call comments Jim -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Thursday, January 06, 2011 1:30 PM To: ietf@augustcellars.com Subject: New Version Notification for = draft-schaad-smime-algorithm-attribute-04=20 A new version of I-D, draft-schaad-smime-algorithm-attribute-04.txt has = been successfully submitted by Jim Schaad and posted to the IETF = repository. Filename: draft-schaad-smime-algorithm-attribute Revision: 04 Title: Signer Info Algorithm Protection Attribute Creation_date: 2011-01-06 WG ID: Independent Submission Number_of_pages: 14 Abstract: A new attribute is defined that allows for protection of the digest and = signature algorithm structures in an authenticated data or a signer info = structure. Using the attribute includes the algorithm definition = information in the integrity protection process. = =20 The IETF Secretariat. From denis.pinkas@bull.net Thu Jan 20 00:08:58 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5895D3A7097 for ; Thu, 20 Jan 2011 00:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.566 X-Spam-Level: * X-Spam-Status: No, score=1.566 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_BAD_ID=2.837] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9F8FEbHm3sp for ; Thu, 20 Jan 2011 00:08:56 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by core3.amsl.com (Postfix) with ESMTP id B941B3A6E7E for ; Thu, 20 Jan 2011 00:08:55 -0800 (PST) Received: from MSGA-001.frcl.bull.fr (msga-001.frcl.bull.fr [129.184.87.31]) by odin2.bull.net (Bull S.A.) with ESMTP id 02C501380E2; Thu, 20 Jan 2011 09:19:05 +0100 (CET) Received: from B016404 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2011012009113582:31758 ; Thu, 20 Jan 2011 09:11:35 +0100 From: "Denis Pinkas" To: "smime" Date: Thu, 20 Jan 2011 09:11:34 +0100 Message-Id: References: <4D261242.103@ieca.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: DreamMail 4.4.1.0 X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 20/01/2011 09:11:35, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11 |July 24, 2002) at 20/01/2011 09:11:36, Serialize complete at 20/01/2011 09:11:36 Content-Type: multipart/alternative; boundary="----=_NextPart_11012009113364552657307_002" Subject: Re: [smime] Fwd: I-D Action:draft-hernandez-ardieta-smime-eesp-00.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: denis.pinkas@bull.net List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 08:08:58 -0000 ------=_NextPart_11012009113364552657307_002 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="ISO-8859-1" Q29tbWVudHMgb24gZHJhZnQtaGVybmFuZGV6LWFyZGlldGEtc21pbWUtZWVzcC0wMA0KMS4gVGhl IHRvcGljIG9mIHRoZSBkb2N1bWVudCBpcyBpbnRlcmVzdGluZy4gSG93ZXZlciwgdGhlIG92ZXJh bGwgQVNOLjEgc3ludGF4IA0KdGhhdCBpcyBwcm9wb3NlZCBpcyB0b28gY29tcGxpY2F0ZWQuIEl0 IHNob3VsZCBiZSBzaW1wbGlmaWVkLiANCiANCjIuIE9uIHBhZ2UgNiwgdGhlIHRleHQgc3RhdGVz Og0KIA0Kk1RoaXMgZG9jdW1lbnQgZGVmaW5lcyBidXQgZG9lcyBub3QgbWFuZGF0ZSB0aGUgZm9y bSBvZiB0aGUgZXh0LVNQIFNwZWNpZmljYXRpb26ULg0KIA0KVGhlIHBvaW50IGlzIHdlbGwgdGFr ZW4sIGhvd2V2ZXIgdGhlIHN0cnVjdHVyZSBvZiB0aGUgZG9jdW1lbnQgc2hvdWxkIGJlIGNoYW5n ZWQgDQp0byBmb2xsb3cgdGhpcyBzdGF0ZW1lbnQ6IHRoZSBkb2N1bWVudCBzaG91bGQgZmlyc3Qg ZGVzY3JpYmUgdGhlIG5ldyBzaWduZWQgYXR0cmlidXRlcyANCmFibGUgdG8gaWRlbnRpZnkgdGhl IGV4dGVuZGVkIHNpZ25hdHVyZSBwb2xpY3kgYW5kIGhhdmUgYSBzZWNvbmQgcGFydCB3aGljaCAN CmRlc2NyaWJlcyB0aGUgQVNOLjEgZm9ybWF0Lg0KIA0KSXQgd291bGQgYmUgbmljZSB0byBzdXBw b3J0IGJvdGggQ0FkRVMgYW5kIFhBZEVTIHNpZ25hdHVyZXMsIHNvIHR3byBuZXcgc2lnbmVkIGF0 dHJpYnV0ZXMgDQp3b3VsZCBuZWVkIHRvIGJlIGRlZmluZWQ6IG9uZSBmb3IgWEFkRVMgYW5kIGFu b3RoZXIgb25lIGZvciBDQWRFUy4NCiANClRoZSBYQWRFUyBmb3JtYXQgaGFzIGN1cnJlbnRseSBs aW1pdGF0aW9uczogYSBYQWRFUyBzaWduYXR1cmUgY29udGFpbnMgb25lIGFuZCBvbmx5IG9uZSAN CnNpZ25hdHVyZSB0aGF0IGNhbiBiZSBjb3VudGVyc2lnbmVkLiBBIENBZEVTIHNpZ25hdHVyZSBp cyBtb3JlIGZsZXhpYmxlOiBpdCBtYXkgY29udGFpbiANCnBhcmFsbGVsIHNpZ25hdHVyZXM7IHdo ZXJlIGVhY2ggb2YgdGhlbSBjYW4gYmUgY291bnRlcnNpZ25lZC4NCiANClRoZXJlIGlzIHNvbWUg d29yayBiZWluZyBkb25lIGluIEVTVEkgVEMgRVNJIHRvIGFsbG93IHN1cHBvcnRpbmcgWEFkRVMg cGFyYWxsZWwgc2lnbmF0dXJlcy4gDQogDQozLiBTaW5jZSBYQWRFUyBzdXBwb3J0IElPRHMgYXMg VVJOcyBhbmQgT0lEcyBhcyBVUklzLCB0aGUgc3ludGF4IGJlaW5nIGRldmVsb3BlZCBzaG91bGQg YmUgYWJsZSANCnRvIGFjY29tbW9kYXRlIGJvdGguIENoYW5nZSBFeHRTaWduUG9saWN5SWQgYWNj b3JkaW5nbHkuIA0KIA0KNC4gT24gcGFnZSA3LCB0aGUgc3ludGF4IGluY2x1ZGVzOg0KIA0KICBl eHRTaWduUG9saWN5UHJvdGVjdGlvbiBFeHRTaWduUG9saWN5UHJvdGVjdGlvbiBPUFRJT05BTA0K IA0KSSBkbyBub3QgYmVsaWV2ZSB0aGF0IHRoaXMgZmllbGQgaXMgbmVlZGVkLiBJdCBpcyB1bm5l Y2Vzc2FyeSB0byBzaWduIHN1Y2ggc3RydWN0dXJlcy4gDQpJZiB5b3UgcmVhbGx5IHdvdWxkIGxp a2UgaXQgdG8gYmUgc2lnbmVkLCBhIHNpbXBsZSBjcnlwdG9ncmFwaGljIGNoZWNrc3VtIHdvdWxk IGJlIA0KaW5zdWZmaWNpZW50LCBzaW5jZSB5b3UgZG9uknQga25vdyB3aGljaCBrZXkgb3IgY2Vy dGlmaWNhdGUgdG8gdXNlIHRvIHZlcmlmeSBpdC4gDQpBIENBZEVTIHNpZ25hdHVyZSB3b3VsZCBi ZSBmaW5lIGJ1dCB0b28gY29tcGxpY2F0ZWQgKGFuZCBub3QgbmVjZXNzYXJ5KS4gDQpEZWxldGUg ZXh0U2lnblBvbGljeVByb3RlY3Rpb24uIA0KIA0KNS4gVGhlIHNpZ25pbmdQZXJpb2QgaXMgbWFu ZGF0b3J5LiBGb3IgbW9yZSBmbGV4aWJpbGl0eSwgaXQgd291bGQgYmUgYmV0dGVyIHRvIG1ha2Ug aXQgT1BUSU9OQUwuIA0KIA0KNi4gVGhlIG1ham9yIHBhcnQgaXMgY29udGFpbmVkIGluIHNlY3Rp b24gMy4zLjEuIFRocmVlIHR5cGVzIG9mIHNpZ25hdHVyZXMgYXJlIGlkZW50aWZpZWQuIA0KRVRT SSBUQyBFU0kgY3VycmVudGx5IG9ubHkgY29uc2lkZXJzIHR3byB0eXBlczogcGFyYWxsZWwgYW5k IGVtYmVkZGVkLg0KIA0KSSB3b25kZXIgd2hldGhlciBzZXF1ZW50aWFsIHNpZ25hdHVyZXMgbWFr ZSBzZW5zZS4gSG93IHN1Y2ggc2lnbmF0dXJlcyB3b3VsZCBsb29rIGxpa2UsIA0Kd2hlbiB5b3Ug bG9vayBhdCB0aGUgYml0IHN0cmluZyBsZXZlbCA/IA0KIA0KSSB3b3VsZCBndWVzcyB0aGF0IHlv dSB3b3VsZCBuZWVkIGEgbmV3IHNpZ25lZCBhdHRyaWJ1dGUuIFRoaXMgd291bGQgY29tcGxpY2F0 ZSB0aGUgYmFzaWMgZm9ybWF0IA0Kb2YgYSBDQWRFUyBzaWduYXR1cmUgb3IgYSBYQWRFUyBzaWdu YXR1cmUuIFVubGVzcyB5b3UgaGF2ZSBzdHJvbmcgYXJndW1lbnRzIG9uIHRoaXMgcG9pbnQsIA0K c2VxdWVudGlhbCBzaWduYXR1cmVzIHNob3VsZCBiZSBkaXNjYXJkZWQuIA0KIA0KNy4gVGhlIHRy ZWUgZ3JhcGggaXMgdG9vIGNvbXBsaWNhdGVkLiBBdm9pZCByZWN1cnNpdmUgbWV0aG9kcy4NCiAN ClRoZSBDQWRFUyBmb3JtYXQgaXMgc2ltcGxlOiBuIHBhcmFsbGVsIHNpZ25hdHVyZXMgZWFjaCBv ZiB0aGVtIGNhbiBiZSBjb3VudGVyc2lnbmVkIGFueSBudW1iZXIgb2YgdGltZXMuIA0KVGhlcmUg bmVlZHMgdG8gYmUgbiBwYXJhbGxlbCBzaWduYXR1cmVzIChjYWxsZWQgUFMgaW4gdGhlIGRyYWZ0 KSBhbmQgZm9yIGVhY2ggcHJpbWFyeSBzaWduYXR1cmUgKFBTKSANCmZyb20gMSB0byBuIHRlbGwg aG93IG1hbnkgbnVtYmVycyBvZiBjb3VudGVyc2lnbmF0dXJlcyBhcmUgbmVlZGVkLiANCiANCk5v dGUgdGhhdCBjb3VudGVyc2lnbmF0dXJlcyBhcmUgbmVjZXNzYXJpbHkgbWFkZSBpbiBzZXF1ZW5j ZS4gSSBkbyBub3QgdGhpbmsgdGhlIGZpZ3VyZSBpcyBhcHByb3ByaWF0ZSANCndoZW4gQ1MxIGFu ZCBDUzIgYXJlIHJlcHJlc2VudGVkIG9uIHRoZSBzYW1lIGxpbmUuDQogDQpUaGUgY3VycmVudCBk ZXNjcmlwdGlvbiBmb3IgVHJlZXNPZlNvbHV0aW9ucyBpcyB0b28gY29tcGxpY2F0ZWQuDQqTaWRl bnRpZmllcpQgYW5kIJNzaWduZXKUIGFyZSBub3QgdW5kZXJzdGFuZGFibGUuIFBsZWFzZSB0cnkg dG8gYWRvcHQgYSBzaW1wbGVyIHN0cnVjdHVyZS4gDQogDQo4LiBGb3IgdGhlIHRpbWluZ0FuZFNl cXVlbmNlIHRoZSBkcmFmdCBzdGF0ZXM6IJNUaGUgdGltZSBmcmFtZSBkdXJpbmcgd2hpY2ggYSBz aWduYXR1cmUgbXVzdCBiZSBnZW5lcmF0ZWSULiANClNpZ25pbmdQZXJpb2QgaXMgZGVmaW5lZCBh czoNCiANClNpZ25pbmdQZXJpb2QgOjo9IFNFUVVFTkNFIHsNCiAgICAgICAgbm90QmVmb3JlICAg ICAgIEdlbmVyYWxpemVkVGltZSwNCiAgICAgICAgbm90QWZ0ZXIgICAgICAgIEdlbmVyYWxpemVk VGltZSBPUFRJT05BTCB9DQogDQpUaGlzIGRvZXMgbm90IG1ha2Ugc2Vuc2U6IGl0IGlzIGltcG9z c2libGUgdG8gdXNlIGFuIGFic29sdXRlIHRpbWUuDQoNCkl0IGlzIG9ubHkgcG9zc2libGUgdG8g c2F5LCBlLmcuIHRoYXQgdGhlIHNlY29uZCBzaWduYXR1cmUgKnNob3VsZCogYmUgZG9uZSB3aXRo aW4geCBob3VycyANCmFmdGVyIHRoZSBmaXJzdCBvbmUgYW5kIHRoYXQgdGhlIGZpcnN0IGNvdW50 ZXJzaWduYXR1cmUgKnNob3VsZCogYmUgZG9uZSB3aXRoaW4geSBob3Vycy4gDQpJdCBpcyBvbmx5 IGFuIGluZGljYXRpb24gb2YgdGhlIHNwZWVkIG9mIHRoZSB3b3JrZmxvdywgbm8gbW9yZS4gTm90 ZSB0aGF0ICpzaGFsbCogaXMgbm90IHVzZWQuDQogDQpUaGlzIGlzIG1vcmUgb3IgbGVzcyB0aGUg aWRlYSBiZWhpbmQgcmVsYXRpdmVUaW1pbmdBbmRTZXF1ZW5jZS4gSXQgaXMgaG93ZXZlciBkZWJh dGFibGUgd2hldGhlciANCnRoaXMgbGV2ZWwgb2YgY29tcGxleGl0eSBpcyByZWFsbHkgbmVlZGVk LiBJIHdvdWxkIHN1cHByZXNzIGl0IGZvciBtYWtpbmcgdGhlIHN0cnVjdHVyZSBzaW1wbGVyLiAN CiANCjkuIFRoZSBjb25jZXB0IG9mIHNpZ25pbmcgcm9sZSBhcyBkZWZpbmVkIGluIHNlY3Rpb24g My41IGlzIGluYXBwcm9wcmlhdGUuIFRoaXMgc2hvdWxkIGJlIHJlcGxhY2VkIA0KYnkgdGhlIG5v dGlvbnMgb2YgY2xhaW1lZCByb2xlIGFuZC9vciBjZXJ0aWZpZWQgcm9sZSB3aGVyZSB0aGUgaWRl bnRpdHkgb2YgdGhlIHNpZ25lciBpcyBub3QgaW1wb3J0YW50LCANCmJ1dCBpdHMgZnVuY3Rpb25h bCByb2xlIGlzIGZ1bmRhbWVudGFsLiANCiANCjEwLiBTZWN0aW9uIDUgc2hvdWxkIGJlIHBsYWNl ZCBiZWZvcmUgdGhlIEFTTi4xIGRlc2NyaXB0aW9uIG9mIHRoZSBleHQtU1AuIA0KIA0KMTEuIEFu b3RoZXIgc2VjdGlvbiBzaG91bGQgY29tZSBhZnRlciBkZWRpY2F0ZWQgdG8gk0ludGVncmF0aW9u IGluIFhBZEVTIGZvcm1hdHOULiANCiANCjEyLiBBIG1pbm9yIGVkaXRpbmc6IG9uIHBhZ2UgNSwg dGhlIHRleHQgc3RhdGVzOiANCiANCpNUaGUgU2lnbmVyIGlzIHRoZSBlbnRpdHkgdGhhdCBjcmVh dGVzIG9uZSBvciBtb3JlIGVsZWN0cm9uaWMgc2lnbmF0dXJlcyByZXByZXNlbnRlZCANCmluIHRo ZSBleHQtU1AgY29udGVudC4gVGhlIHNpZ25lciBNVVNUIGRpZ2l0YWxseSBzaWduIG92ZXIgYSBz aWduYXR1cmUgcG9saWN5IGlkZW50aWZpZXIgYW5kIA0KYW4gZXh0ZW5kZWQgc2lnbmF0dXJlIHBv bGljeSBpZGVudGlmaWVyLpQNCiANClRoZSBzZW50ZW5jZXMgc2hvdWxkIGJlIHJld29yZGVkIGFz IGZvbGxvd3M6IA0KIA0Kk0EgU2lnbmVyIGlzIGFuIGVudGl0eSB0aGF0IGNyZWF0ZXMgb25lIG9y IG1vcmUgZWxlY3Ryb25pYyBzaWduYXR1cmVzIHJlcHJlc2VudGVkIGluIHRoZSBleHQtU1AgY29u dGVudC4gIA0KRXZlcnkgc2lnbmVyIE1VU1QgZGlnaXRhbGx5IHNpZ24gdXNpbmcgc2lnbmF0dXJl IHBvbGljeSBpZGVudGlmaWVyIGFuZCBhbiBleHRlbmRlZCBzaWduYXR1cmUgcG9saWN5IGlkZW50 aWZpZXIulCANCiANCjEzLiBPbmUgdHlwbzogb24gcGFnZSA0OiBGcmVucXVlbnRseQ0KDQpEZW5p cw0KDQpQUy4gSSBjb3B5IHRoaXMgbWFpbCB0byB0aGUgRVRTSSBUQyBFU0kgbGlzdC4NCg0KDQot LS0tLS0tLS0gDQpEZSA6IHNtaW1lLWJvdW5jZXMgDQrAIDogc21pbWUgDQpEYXRlIDogMjAxMS0w MS0wNiwgMjA6MDQ6MzQNClN1amV0IDogW3NtaW1lXSBGd2Q6IEktRCBBY3Rpb246ZHJhZnQtaGVy bmFuZGV6LWFyZGlldGEtc21pbWUtZWVzcC0wMC50eHQNCg0KDQpQaehjZShzKSBKb2ludGUocykg YXUgbWVzc2FnZSBvcmlnaW5hbCA6DQogICgxKS4gZHJhZnQtaGVybmFuZGV6LWFyZGlldGEtc21p bWUtZWVzcC0wMC50eHQNCiAgKDIpLiBBdHRhY2hlZCBNZXNzYWdlIFBhcnQNCg0KDQpTb21lIG9u IHRoaXMgbWFpbGluZyBsaXN0IG1pZ2h0IGZpbmQgdGhpcyBvZiBpbnRlcmVzdC4gSXQncyBoZWFk ZWQgZm9yIA0KZXhwZXJpbWVudGFsLg0KDQpUaGUgYXV0aG9ycyBoYXZlIGFza2VkIGZvciBjb21t ZW50cy4NCg0Kc3B0DQoNCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NClN1Ympl Y3Q6IEktRCBBY3Rpb246ZHJhZnQtaGVybmFuZGV6LWFyZGlldGEtc21pbWUtZWVzcC0wMC50eHQN CkRhdGU6IFRodSwgMjMgRGVjIDIwMTAgMTA6MDA6MDIgLTA4MDANCkZyb206IEludGVybmV0LURy YWZ0c0BpZXRmLm9yZw0KUmVwbHktVG86IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KVG86IGkt ZC1hbm5vdW5jZUBpZXRmLm9yZw0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgDQpkaXJlY3Rvcmllcy4NCg0KICBUaXRs ZSA6IEV4dGVuZGVkIEVsZWN0cm9uaWMgU2lnbmF0dXJlIFBvbGljaWVzDQogIEF1dGhvcihzKSA6 IEouIEhlcm5hbmRlei1BcmRpZXRhDQogIEZpbGVuYW1lIDogZHJhZnQtaGVybmFuZGV6LWFyZGll dGEtc21pbWUtZWVzcC0wMC50eHQNCiAgUGFnZXMgOiAyMQ0KICBEYXRlIDogMjAxMC0xMi0yMw0K DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgZXh0ZW5kZWQgZWxlY3Ryb25pYyBzaWduYXR1cmUgcG9s aWNpZXMgKGV4dC1TUCkNCnRoYXQgZXh0ZW5kIHRoZSBib3VuZGFyaWVzIG9mIHRoZSBlbGVjdHJv bmljIHNpZ25hdHVyZSBwb2xpY3kgZGVmaW5lZCBpbg0KW1JGQzMxMjVdIGluIGEgbWFubmVyIHRo YXQgdGhlIHJlbGF0aW9uc2hpcHMgYW5kIGRlcGVuZGVuY2VzIGFtb25nDQptdWx0aXBsZSBlbGVj dHJvbmljIHNpZ25hdHVyZXMgZ2VuZXJhdGVkIHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIHNhbWUN CmVsZWN0cm9uaWMgdHJhbnNhY3Rpb24gY2FuIGJlIGVzdGFibGlzaGVkLiBBIGdpdmVuIGxlZ2Fs L2NvbnRyYWN0dWFsDQpjb250ZXh0IG1heSByZWNvZ25pemUgYSBwYXJ0aWN1bGFyIGV4dC1TUCBh cyBtZWV0aW5nIGl0cyByZXF1aXJlbWVudHMuDQoNCkFuIGV4dC1TUCBoYXMgYSBnbG9iYWxseSB1 bmlxdWUgcmVmZXJlbmNlLCB3aGljaCBpcyBib3VuZCB0byBhbg0KZWxlY3Ryb25pYyBzaWduYXR1 cmUgYnkgdGhlIHNpZ25lciBhcyBwYXJ0IG9mIHRoZSBzaWduYXR1cmUgY2FsY3VsYXRpb24uDQoN ClRoZSBleHQtU1AgY2FuIGJlIGRlZmluZWQgaW4gaHVtYW4gcmVhZGFibGUgZm9ybSBzbyB0aGF0 IGl0IGNhbiBiZQ0KYXNzZXNzZWQgdG8gbWVldCB0aGUgcmVxdWlyZW1lbnRzIG9mIHRoZSBsZWdh bCBhbmQgY29udHJhY3R1YWwgY29udGV4dA0KaW4gd2hpY2ggaXQgaXMgYmVpbmcgYXBwbGllZC4N Cg0KVG8gYWxsb3cgZm9yIHRoZSBhdXRvbWF0aWMgcHJvY2Vzc2luZywgdGhlIGV4dC1TUCBzcGVj aWZpZXMsIHVzaW5nIGENCmNvbXB1dGVyIHByb2Nlc3NhYmxlIGZvcm0sIHRoZSB0aW1pbmcgYW5k IHNlcXVlbmNlIGRlcGVuZGVuY2llcyBvZiB0aGUNCnNldCBvZiBzaWduYXR1cmVzIHRoYXQgbXVz dCBiZSBnZW5lcmF0ZWQgdG8gbWFrZSB0aGUgdHJhbnNhY3Rpb24NCmVmZmVjdGl2ZSBhbG9uZyB3 aXRoIHRoZSBzZXQgb2YgYXR0cmlidXRlcyBhbmQgcnVsZXMgdGhhdCBlYWNoIHNpZ25hdHVyZQ0K bXVzdCBjb21wbHkgd2l0aC4gSW4gdGhlIGN1cnJlbnQgZG9jdW1lbnQgdGhlIGZvcm1hdCBvZiB0 aGUgZXh0LVNQIGlzDQpkZWZpbmVkIHVzaW5nIEFTTi4xLg0KDQpUaGUgY29udGVudCBvZiB0aGlz IGRvY3VtZW50IGlzIGJhc2VkIG9uIHRoZSByZXF1aXJlbWVudHMgYW5kIG5lZWRzDQplc3RhYmxp c2hlZCBpbiBFVFNJIFRSIDEwMiAwNDUgVjEuMS4xICgyMDAzLTAzKSBDb3B5cmlnaHQgKEMpLg0K SW5kaXZpZHVhbCBjb3BpZXMgb2YgdGhpcyBFVFNJIGRlbGl2ZXJhYmxlIGNhbiBiZSBkb3dubG9h ZGVkIGZyb20NCmh0dHA6Ly93d3cuZXRzaS5vcmcuDQoNCkRpc2N1c3Npb24NCg0KVGhpcyBkcmFm dCBpcyBiZWluZyBkaXNjdXNzZWQgb24gdGhlICdpZXRmLXNtaW1lJyBtYWlsaW5nIGxpc3QuIFRv DQpzdWJzY3JpYmUsIHNlbmQgYSBtZXNzYWdlIHRvIHNtaW1lLXJlcXVlc3RAaWV0Zi5vcmcgd2l0 aCB0aGUNCnNpbmdsZSB3b3JkIHN1YnNjcmliZSBpbiB0aGUgYm9keSBvZiB0aGUgbWVzc2FnZS4g VGhlcmUgaXMgYSBXZWIgc2l0ZQ0KZm9yIHRoZSBtYWlsaW5nIGxpc3QgYXQgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zbWltZS4NCg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJu ZXQtRHJhZnQgaXM6DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1o ZXJuYW5kZXotYXJkaWV0YS1zbWltZS1lZXNwLTAwLnR4dA0KDQpJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLw0KDQpCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBh IE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyDQppbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNh bGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KSW50ZXJuZXQtRHJhZnQuDQoN Cg0KDQpfX19fX19fX19fX19fX19fX19fX18gbmV4dCBwYXJ0IF9fX19fX19fX19fX19fX19fX19f X18NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNt aW1lIG1haWxpbmcgbGlzdA0Kc21pbWVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc21pbWUNCg== ------=_NextPart_11012009113364552657307_002 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="ISO-8859-1" PEhUTUwgeG1sbnM6byA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2Ui PjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgY29udGVudD0iS3NESFRNTEVETGliLm9jeCwg RnJlZVdhcmUgSFRNTCBFZGl0b3IgMS4xNjQuMiwgqSBLdXJ0IFNlbmZlciIgDQpuYW1lPUdFTkVS QVRPUj4NCjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsg Y2hhcnNldD1pc28tODg1OS0xIj48L0hFQUQ+DQo8Qk9EWSBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogVGFob21hIiBsZWZ0TWFyZ2luPTUgdG9wTWFyZ2luPTUgDQojZmZmZmZm Pg0KPFA+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj5Db21tZW50cyBvbiANCmRyYWZ0 LWhlcm5hbmRlei1hcmRpZXRhLXNtaW1lLWVlc3AtMDA8L0ZPTlQ+PC9QPg0KPFA+DQo8UCBjbGFz cz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij48U1BBTiANCmxhbmc9RU4tR0Igc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBF Ti1HQiI+MS48L1NQQU4+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTogRU4tR0IiPiBUaGUgdG9waWMgb2YgdGhlIGRvY3VtZW50IGlzIGludGVyZXN0aW5nLiANCkhv d2V2ZXIsIHRoZSBvdmVyYWxsIEFTTi4xIHN5bnRheCA8QlI+dGhhdCBpcyBwcm9wb3NlZCBpcyB0 b28gY29tcGxpY2F0ZWQuIEl0IA0Kc2hvdWxkIGJlIHNpbXBsaWZpZWQuPC9TUEFOPjwvRk9OVD48 U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+PG86cD48 Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4N CjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4g bGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxvOnA+PEZPTlQg DQpmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxGT05UIGZhY2U9 IkNvdXJpZXIgTmV3Ij48U1BBTiANCmxhbmc9RU4tR0Igc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdl OiBFTi1HQiI+Mi48L1NQQU4+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5n dWFnZTogRU4tR0IiPiBPbiBwYWdlIDYsIHRoZSB0ZXh0IA0Kc3RhdGVzOjxvOnA+PC9vOnA+PC9T UEFOPjwvRk9OVD48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVO LUdCIj48bzpwPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvRk9OVD48L286cD48 L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MHB0Ij48U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+ PEZPTlQgZmFjZT0iQ291cmllciBOZXciPpNUaGlzIGRvY3VtZW50IGRlZmluZXMgDQpidXQgZG9l cyBub3QgbWFuZGF0ZSB0aGUgZm9ybSBvZiB0aGUgZXh0LVNQIFNwZWNpZmljYXRpb26ULjxCUj4g PEJSPlRoZSBwb2ludCBpcyANCndlbGwgdGFrZW4sIGhvd2V2ZXIgdGhlIHN0cnVjdHVyZSBvZiB0 aGUgZG9jdW1lbnQgc2hvdWxkIGJlIGNoYW5nZWQgPEJSPnRvIA0KZm9sbG93IHRoaXMgc3RhdGVt ZW50OiB0aGUgZG9jdW1lbnQgc2hvdWxkIGZpcnN0IGRlc2NyaWJlIHRoZSBuZXcgc2lnbmVkIA0K YXR0cmlidXRlcyA8QlI+YWJsZSB0byBpZGVudGlmeSB0aGUgZXh0ZW5kZWQgc2lnbmF0dXJlIHBv bGljeSBhbmQgaGF2ZSBhIHNlY29uZCANCnBhcnQgd2hpY2ggPEJSPmRlc2NyaWJlcyB0aGUgQVNO LjEgZm9ybWF0LjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFp blRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHls ZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48bzpwPjxGT05UIA0KZmFjZT0iQ291cmllciBO ZXciPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0 IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1z by1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPkl0IHdvdWxk IGJlIG5pY2UgdG8gDQpzdXBwb3J0IGJvdGggQ0FkRVMgYW5kIFhBZEVTIHNpZ25hdHVyZXMsIHNv IHR3byBuZXcgc2lnbmVkIGF0dHJpYnV0ZXMgPEJSPndvdWxkIA0KbmVlZCB0byBiZSBkZWZpbmVk OiBvbmUgZm9yIFhBZEVTIGFuZCBhbm90aGVyIG9uZSBmb3IgDQpDQWRFUy48bzpwPjwvbzpwPjwv Rk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBj bSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBF Ti1HQiI+PG86cD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L0ZPTlQ+PC9vOnA+ PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDBwdCI+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0Ii PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij5UaGUgWEFkRVMgZm9ybWF0IGhhcyANCmN1cnJlbnRs eSBsaW1pdGF0aW9uczogYSBYQWRFUyBzaWduYXR1cmUgY29udGFpbnMgb25lIGFuZCBvbmx5IG9u ZSA8QlI+c2lnbmF0dXJlIA0KdGhhdCBjYW4gYmUgY291bnRlcnNpZ25lZC4gQSBDQWRFUyBzaWdu YXR1cmUgaXMgbW9yZSBmbGV4aWJsZTogaXQgbWF5IGNvbnRhaW4gDQo8QlI+cGFyYWxsZWwgc2ln bmF0dXJlczsgd2hlcmUgZWFjaCBvZiB0aGVtIGNhbiBiZSANCmNvdW50ZXJzaWduZWQuPG86cD48 L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5n dWFnZTogRU4tR0IiPjxvOnA+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9GT05U PjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6 IEVOLUdCIj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+VGhlcmUgaXMgc29tZSB3b3JrIA0KYmVp bmcgZG9uZSBpbiBFU1RJIFRDIEVTSSB0byBhbGxvdyBzdXBwb3J0aW5nIFhBZEVTIHBhcmFsbGVs IA0Kc2lnbmF0dXJlcy48L0ZPTlQ+PC9TUEFOPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNv LWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48bzpwPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZu YnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxl PSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNp LWxhbmd1YWdlOiBFTi1HQiI+PG86cD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8 L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDBwdCI+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFOIA0KbGFuZz1F Ti1HQiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj4zLjwvU1BBTj48U1BBTiBsYW5n PUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+IFNpbmNlIFhBZEVTIHN1 cHBvcnQgSU9EcyBhcyBVUk5zIGFuZCBPSURzIGFzIA0KVVJJcywgdGhlIHN5bnRheCBiZWluZyBk ZXZlbG9wZWQgc2hvdWxkIGJlIGFibGUgPEJSPnRvIGFjY29tbW9kYXRlIGJvdGguIENoYW5nZSAN CkV4dFNpZ25Qb2xpY3lJZCBhY2NvcmRpbmdseS48L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4t R0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48bzpwPjxGT05UIA0KZmFjZT0i Q291cmllciBOZXciPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNv UGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLUdCIA0K c3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+PG86cD48Rk9OVCANCmZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb1BsYWlu VGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PEZPTlQgZmFjZT0iQ291cmllciBOZXci PjxTUEFOIA0KbGFuZz1FTi1HQiBzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj40Ljwv U1BBTj48U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+ IE9uIHBhZ2UgNywgdGhlIHN5bnRheCANCmluY2x1ZGVzOjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQi PjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48bzpw PjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9Q Pg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BB TiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+PEZPTlQgZmFj ZT0iQ291cmllciBOZXciPjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsg PC9TUEFOPmV4dFNpZ25Qb2xpY3lQcm90ZWN0aW9uIA0KRXh0U2lnblBvbGljeVByb3RlY3Rpb24g T1BUSU9OQUw8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5U ZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyB0YWItc3RvcHM6IDQ5LjVwdCI+PFNQQU4g DQpsYW5nPUVOLUdCIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxvOnA+PEZPTlQg DQpmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9 RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+SSBkbyBub3QgYmVsaWV2ZSB0aGF0IA0KdGhpcyBmaWVsZCBpcyBuZWVkZWQuIEl0 IGlzIHVubmVjZXNzYXJ5IHRvIHNpZ24gc3VjaCBzdHJ1Y3R1cmVzLiA8QlI+SWYgeW91IA0KcmVh bGx5IHdvdWxkIGxpa2UgaXQgdG8gYmUgc2lnbmVkLCBhIHNpbXBsZSBjcnlwdG9ncmFwaGljIGNo ZWNrc3VtIHdvdWxkIGJlIA0KPEJSPmluc3VmZmljaWVudCwgc2luY2UgeW91IGRvbpJ0IGtub3cg d2hpY2gga2V5IG9yIGNlcnRpZmljYXRlIHRvIHVzZSB0byB2ZXJpZnkgDQppdC4gPEJSPkEgQ0Fk RVMgc2lnbmF0dXJlIHdvdWxkIGJlIGZpbmUgYnV0IHRvbyBjb21wbGljYXRlZCAoYW5kIG5vdCBu ZWNlc3NhcnkpLiANCjxCUj5EZWxldGUgZXh0U2lnblBvbGljeVByb3RlY3Rpb24uPC9GT05UPjwv U1BBTj48U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+ PG86cD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFO PjwvUD4NCjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+ PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxvOnA+ PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+ DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxGT05U IGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCmxhbmc9RU4tR0Igc3R5bGU9Im1zby1hbnNpLWxh bmd1YWdlOiBFTi1HQiI+NS48L1NQQU4+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5z aS1sYW5ndWFnZTogRU4tR0IiPiBUaGUgc2lnbmluZ1BlcmlvZCBpcyBtYW5kYXRvcnkuIEZvciBt b3JlIA0KZmxleGliaWxpdHksIGl0IHdvdWxkIGJlIGJldHRlciB0byBtYWtlIGl0IE9QVElPTkFM LjwvU1BBTj48L0ZPTlQ+PFNQQU4gDQpsYW5nPUVOLUdCIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTogRU4tR0IiPjxvOnA+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9GT05UPjwv bzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVO LUdCIj48bzpwPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvRk9OVD48L286cD48 L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20g MHB0Ij48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQpsYW5nPUVOLUdCIHN0eWxlPSJt c28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjYuPC9TUEFOPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHls ZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj4gVGhlIG1ham9yIHBhcnQgaXMgY29udGFpbmVk IGluIHNlY3Rpb24gMy4zLjEuIA0KVGhyZWUgdHlwZXMgb2Ygc2lnbmF0dXJlcyBhcmUgaWRlbnRp ZmllZC4gPEJSPkVUU0kgVEMgRVNJIGN1cnJlbnRseSBvbmx5IA0KY29uc2lkZXJzIHR3byB0eXBl czogcGFyYWxsZWwgYW5kIGVtYmVkZGVkLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQo8 UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxh bmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48bzpwPjxGT05UIA0K ZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xh c3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVO LUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPkkgd29uZGVyIHdoZXRoZXIgDQpzZXF1ZW50aWFsIHNpZ25hdHVyZXMgbWFrZSBzZW5z ZS4gSG93IHN1Y2ggc2lnbmF0dXJlcyB3b3VsZCBsb29rIGxpa2UsIDxCUj53aGVuIA0KeW91IGxv b2sgYXQgdGhlIGJpdCBzdHJpbmcgbGV2ZWwgPyA8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9Q Pg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BB TiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+PG86cD48Rk9O VCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQ IGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFu Zz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxGT05UIGZhY2U9IkNv dXJpZXIgTmV3Ij5JIHdvdWxkIGd1ZXNzIHRoYXQgeW91IA0Kd291bGQgbmVlZCBhIG5ldyBzaWdu ZWQgYXR0cmlidXRlLiBUaGlzIHdvdWxkIGNvbXBsaWNhdGUgdGhlIGJhc2ljIGZvcm1hdCA8QlI+ b2YgDQphIENBZEVTIHNpZ25hdHVyZSBvciBhIFhBZEVTIHNpZ25hdHVyZS4gVW5sZXNzIHlvdSBo YXZlIHN0cm9uZyBhcmd1bWVudHMgb24gdGhpcyANCnBvaW50LCA8QlI+c2VxdWVudGlhbCBzaWdu YXR1cmVzIHNob3VsZCBiZSBkaXNjYXJkZWQuPC9GT05UPjwvU1BBTj48U1BBTiANCmxhbmc9RU4t R0Igc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+PG86cD48Rk9OVCANCmZhY2U9IkNv dXJpZXIgTmV3Ij4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb1Bs YWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1HQiANCnN0 eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxvOnA+PEZPTlQgDQpmYWNlPSJDb3VyaWVy IE5ldyI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRl eHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48 U1BBTiANCmxhbmc9RU4tR0Igc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+Ny48L1NQ QU4+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPiBU aGUgdHJlZSBncmFwaCBpcyB0b28gY29tcGxpY2F0ZWQuIEF2b2lkIA0KcmVjdXJzaXZlIG1ldGhv ZHMuPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb1BsYWluVGV4dCBz dHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28t YW5zaS1sYW5ndWFnZTogRU4tR0IiPjxvOnA+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jm5i c3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9 Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2kt bGFuZ3VhZ2U6IEVOLUdCIj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+VGhlIENBZEVTIGZvcm1h dCBpcyANCnNpbXBsZTogbiBwYXJhbGxlbCBzaWduYXR1cmVzIGVhY2ggb2YgdGhlbSBjYW4gYmUg Y291bnRlcnNpZ25lZCBhbnkgbnVtYmVyIG9mIA0KdGltZXMuIDxCUj5UaGVyZSBuZWVkcyB0byBi ZSBuIHBhcmFsbGVsIHNpZ25hdHVyZXMgKGNhbGxlZCBQUyBpbiB0aGUgZHJhZnQpIGFuZCANCmZv ciBlYWNoIHByaW1hcnkgc2lnbmF0dXJlIChQUykgPEJSPmZyb20gMSB0byBuIHRlbGwgaG93IG1h bnkgbnVtYmVycyBvZiANCmNvdW50ZXJzaWduYXR1cmVzIGFyZSBuZWVkZWQuIDxvOnA+PC9vOnA+ PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjog MGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6 IEVOLUdCIj48bzpwPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvRk9OVD48L286 cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAw Y20gMHB0Ij48U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1H QiI+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPk5vdGUgdGhhdCANCmNvdW50ZXJzaWduYXR1cmVz IGFyZSBuZWNlc3NhcmlseSBtYWRlIGluIHNlcXVlbmNlLiBJIGRvIG5vdCB0aGluayB0aGUgZmln dXJlIGlzIA0KYXBwcm9wcmlhdGUgPEJSPndoZW4gQ1MxIGFuZCBDUzIgYXJlIHJlcHJlc2VudGVk IG9uIHRoZSBzYW1lIA0KbGluZS48bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xh c3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVO LUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+PG86cD48Rk9OVCANCmZhY2U9 IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1z b1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1HQiAN CnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij5UaGUgY3VycmVudCANCmRlc2NyaXB0aW9uIGZvciBUcmVlc09mU29sdXRpb25zIGlzIHRvbyAN CmNvbXBsaWNhdGVkLjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Q bGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpz dHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+ k2lkZW50aWZpZXKUIGFuZCANCpNzaWduZXKUIGFyZSBub3QgdW5kZXJzdGFuZGFibGUuIFBsZWFz ZSB0cnkgdG8gYWRvcHQgYSBzaW1wbGVyIA0Kc3RydWN0dXJlLjwvRk9OVD48L1NQQU4+PFNQQU4g bGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxvOnA+PEZPTlQg DQpmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9 RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48bzpwPjxGT05UIA0KZmFj ZT0iQ291cmllciBOZXciPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9 TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCBmYWNlPSJDb3Vy aWVyIE5ldyI+PFNQQU4gDQpsYW5nPUVOLUdCIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4t R0IiPjguPC9TUEFOPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6 IEVOLUdCIj4gRm9yIHRoZSB0aW1pbmdBbmRTZXF1ZW5jZSB0aGUgZHJhZnQgc3RhdGVzOiANCpNU aGUgdGltZSBmcmFtZSBkdXJpbmcgd2hpY2ggYSBzaWduYXR1cmUgbXVzdCBiZSBnZW5lcmF0ZWSU LiA8QlI+U2lnbmluZ1BlcmlvZCANCmlzIGRlZmluZWQgYXM6PG86cD48L286cD48L1NQQU4+PC9G T05UPjwvUD4NCjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBw dCI+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxv OnA+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48 L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxT UEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48Rk9OVCBm YWNlPSJDb3VyaWVyIE5ldyI+U2lnbmluZ1BlcmlvZCA6Oj0gDQpTRVFVRU5DRSB7PG86cD48L286 cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTogRU4tR0IiPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCnN0eWxlPSJtc28tc3Bh Y2VydW46IHllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0K PC9TUEFOPm5vdEJlZm9yZTxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L1NQQU4+R2VuZXJhbGl6ZWRUaW1lLDxv OnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9 Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2kt bGFuZ3VhZ2U6IEVOLUdCIj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQpzdHlsZT0i bXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyANCjwvU1BBTj5ub3RBZnRlcjxTUEFOIA0Kc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQo8L1NQQU4+R2VuZXJh bGl6ZWRUaW1lIE9QVElPTkFMIH08bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xh c3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVO LUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+PG86cD48Rk9OVCANCmZhY2U9 IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1z b1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1HQiAN CnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij5UaGlzIGRvZXMgbm90IG1ha2UgDQpzZW5zZTogaXQgaXMgaW1wb3NzaWJsZSB0byB1c2UgYW4g YWJzb2x1dGUgDQp0aW1lLjxCUj48bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xh c3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBsYW5nPUVO LUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+PEZPTlQgZmFjZT0iQ291cmll ciBOZXciPkl0IGlzIG9ubHkgcG9zc2libGUgdG8gDQpzYXksIGUuZy4gdGhhdCB0aGUgc2Vjb25k IHNpZ25hdHVyZSAqc2hvdWxkKiBiZSBkb25lIHdpdGhpbiB4IGhvdXJzIDxCUj5hZnRlciANCnRo ZSBmaXJzdCBvbmUgYW5kIHRoYXQgdGhlIGZpcnN0IGNvdW50ZXJzaWduYXR1cmUgKnNob3VsZCog YmUgZG9uZSB3aXRoaW4geSANCmhvdXJzLiA8QlI+SXQgaXMgb25seSBhbiBpbmRpY2F0aW9uIG9m IHRoZSBzcGVlZCBvZiB0aGUgd29ya2Zsb3csIG5vIG1vcmUuIE5vdGUgDQp0aGF0ICpzaGFsbCog aXMgbm90IHVzZWQuPG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb1Bs YWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1HQiANCnN0 eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxvOnA+PEZPTlQgDQpmYWNlPSJDb3VyaWVy IE5ldyI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRl eHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0i bXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+VGhpcyBp cyBtb3JlIG9yIGxlc3MgDQp0aGUgaWRlYSBiZWhpbmQgcmVsYXRpdmVUaW1pbmdBbmRTZXF1ZW5j ZS4gSXQgaXMgaG93ZXZlciBkZWJhdGFibGUgd2hldGhlciANCjxCUj50aGlzIGxldmVsIG9mIGNv bXBsZXhpdHkgaXMgcmVhbGx5IG5lZWRlZC4gSSB3b3VsZCBzdXBwcmVzcyBpdCBmb3IgbWFraW5n IA0KdGhlIHN0cnVjdHVyZSBzaW1wbGVyLjwvRk9OVD48L1NQQU4+PFNQQU4gbGFuZz1FTi1HQiAN CnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxvOnA+PEZPTlQgDQpmYWNlPSJDb3Vy aWVyIE5ldyI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFp blRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHls ZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48bzpwPjxGT05UIA0KZmFjZT0iQ291cmllciBO ZXciPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0 IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQ QU4gDQpsYW5nPUVOLUdCIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjkuPC9TUEFO PjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj4gVGhl IGNvbmNlcHQgb2Ygc2lnbmluZyByb2xlIGFzIGRlZmluZWQgaW4gDQpzZWN0aW9uIDMuNSBpcyBp bmFwcHJvcHJpYXRlLiBUaGlzIHNob3VsZCBiZSByZXBsYWNlZCA8QlI+YnkgdGhlIG5vdGlvbnMg b2YgDQpjbGFpbWVkIHJvbGUgYW5kL29yIGNlcnRpZmllZCByb2xlIHdoZXJlIHRoZSBpZGVudGl0 eSBvZiB0aGUgc2lnbmVyIGlzIG5vdCANCmltcG9ydGFudCwgPEJSPmJ1dCBpdHMgZnVuY3Rpb25h bCByb2xlIGlzIGZ1bmRhbWVudGFsLjwvU1BBTj48L0ZPTlQ+PFNQQU4gDQpsYW5nPUVOLUdCIHN0 eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxvOnA+PEZPTlQgDQpmYWNlPSJDb3VyaWVy IE5ldyI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRl eHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0i bXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48bzpwPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXci PiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0 eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4g DQpsYW5nPUVOLUdCIHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjEwLjwvU1BBTj48 U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+IFNlY3Rp b24gNSBzaG91bGQgYmUgcGxhY2VkIGJlZm9yZSB0aGUgQVNOLjEgDQpkZXNjcmlwdGlvbiBvZiB0 aGUgZXh0LVNQLjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5z aS1sYW5ndWFnZTogRU4tR0IiPjxvOnA+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7 PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1B UkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFu Z3VhZ2U6IEVOLUdCIj48bzpwPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvRk9O VD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46 IDBjbSAwY20gMHB0Ij48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQpsYW5nPUVOLUdC IHN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjExLjwvU1BBTj48U1BBTiBsYW5nPUVO LUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+IEFub3RoZXIgc2VjdGlvbiBz aG91bGQgY29tZSBhZnRlciBkZWRpY2F0ZWQgdG8gDQqTSW50ZWdyYXRpb24gaW4gWEFkRVMgZm9y bWF0c5QuPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxh bmd1YWdlOiBFTi1HQiI+PG86cD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L0ZP TlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFn ZTogRU4tR0IiPjxvOnA+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9GT05UPjwv bzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNt IDBjbSAwcHQiPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48U1BBTiANCmxhbmc9RU4tR0Igc3R5 bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+MTIuPC9TUEFOPjxTUEFOIGxhbmc9RU4tR0Ig DQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj4gQSBtaW5vciBlZGl0aW5nOiBvbiBw YWdlIDUsIHRoZSB0ZXh0IHN0YXRlczogDQo8bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0K PFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48U1BBTiBs YW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+PG86cD48Rk9OVCAN CmZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNs YXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1F Ti1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxGT05UIGZhY2U9IkNvdXJp ZXIgTmV3Ij6TVGhlIFNpZ25lciBpcyB0aGUgDQplbnRpdHkgdGhhdCBjcmVhdGVzIG9uZSBvciBt b3JlIGVsZWN0cm9uaWMgc2lnbmF0dXJlcyByZXByZXNlbnRlZCA8QlI+aW4gdGhlIA0KZXh0LVNQ IGNvbnRlbnQuIFRoZSBzaWduZXIgTVVTVCBkaWdpdGFsbHkgc2lnbiBvdmVyIGEgc2lnbmF0dXJl IHBvbGljeSANCmlkZW50aWZpZXIgYW5kIDxCUj5hbiBleHRlbmRlZCBzaWduYXR1cmUgcG9saWN5 IA0KaWRlbnRpZmllci6UPG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1z b1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PFNQQU4gbGFuZz1FTi1HQiAN CnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0IiPjxvOnA+PEZPTlQgDQpmYWNlPSJDb3Vy aWVyIE5ldyI+Jm5ic3A7PC9GT05UPjwvbzpwPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFp blRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHls ZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+VGhl IHNlbnRlbmNlcyBzaG91bGQgDQpiZSByZXdvcmRlZCBhcyBmb2xsb3dzOiA8bzpwPjwvbzpwPjwv Rk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBj bSAwY20gMHB0Ij48U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1zby1hbnNpLWxhbmd1YWdlOiBF Ti1HQiI+PG86cD48Rk9OVCANCmZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L0ZPTlQ+PC9vOnA+ PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNt IDBwdCI+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4tR0Ii PjxGT05UIHNpemU9Mj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+k0EgU2lnbmVyIA0KaXMgYW4g ZW50aXR5IHRoYXQgY3JlYXRlcyBvbmUgb3IgbW9yZSBlbGVjdHJvbmljIHNpZ25hdHVyZXMgcmVw cmVzZW50ZWQgaW4gdGhlIA0KZXh0LVNQIGNvbnRlbnQuPFNQQU4gc3R5bGU9Im1zby1zcGFjZXJ1 bjogeWVzIj4mbmJzcDsgPEJSPjwvU1BBTj5FdmVyeSBzaWduZXIgDQpNVVNUIGRpZ2l0YWxseSBz aWduIHVzaW5nIHNpZ25hdHU8U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJw dDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4t R0I7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IEZSOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxGT05UIA0KZmFjZT0i Q291cmllciBOZXciIHNpemU9Mj5yZSBwb2xpY3kgaWRlbnRpZmllciBhbmQgYW4gZXh0ZW5kZWQg c2lnbmF0dXJlIHBvbGljeSANCmlkZW50aWZpZXI8L0ZPTlQ+LpQ8L1NQQU4+PC9GT05UPjwvRk9O VD48L1NQQU4+PFNQQU4gbGFuZz1FTi1HQiANCnN0eWxlPSJtc28tYW5zaS1sYW5ndWFnZTogRU4t R0IiPjxvOnA+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9GT05UPjwvbzpwPjwv U1BBTj48L1A+DQo8UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw cHQiPjxTUEFOIGxhbmc9RU4tR0IgDQpzdHlsZT0ibXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLUdCIj48 bzpwPjxGT05UIA0KZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+ PC9QPg0KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0Ij48 Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gDQpsYW5nPUVOLUdCIHN0eWxlPSJtc28tYW5z aS1sYW5ndWFnZTogRU4tR0IiPjEzLjwvU1BBTj48U1BBTiBsYW5nPUVOLUdCIA0Kc3R5bGU9Im1z by1hbnNpLWxhbmd1YWdlOiBFTi1HQiI+IE9uZSB0eXBvOiBvbiBwYWdlIDQ6IA0KRnJlbnF1ZW50 bHk8QlI+PEJSPjwvU1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIA0Kc2l6ZT0y PkRlbmlzPC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAw Y20gMGNtIDBwdCI+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+PC9GT05UPiZuYnNwOzwvUD4N CjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCI+PEZPTlQg ZmFjZT0iQ291cmllciBOZXciPlBTLiBJIA0KY29weSB0aGlzIG1haWwgdG8gdGhlIEVUU0kgVEMg RVNJIGxpc3QuPC9GT05UPjwvUD4NCjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lO OiAwY20gMGNtIDBwdCI+PEZPTlQgDQpmYWNlPSJDb3VyaWVyIE5ldyI+PC9GT05UPiZuYnNwOzwv UD4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZU OiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsg TUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IG5vcm1h bDsgRk9OVC1TSVpFOiA5cHQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQtU1RZTEU6IG5vcm1h bDsgRk9OVC1WQVJJQU5UOiBub3JtYWwiPiZuYnNwOzwvRElWPg0KICA8RElWIA0KICBzdHlsZT0i Rk9OVC1XRUlHSFQ6IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7IExJTkUtSEVJR0hUOiBub3JtYWw7 IEZPTlQtU1RZTEU6IG5vcm1hbDsgRk9OVC1WQVJJQU5UOiBub3JtYWwiPi0tLS0tLS0tLSANCiAg PC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJGT05ULVdFSUdIVDogbm9ybWFsOyBGT05ULVNJWkU6 IDlwdDsgQkFDS0dST1VORDogI2U0ZTRlNDsgTElORS1IRUlHSFQ6IG5vcm1hbDsgRk9OVC1TVFlM RTogbm9ybWFsOyBGT05ULVZBUklBTlQ6IG5vcm1hbDsgZm9udC1jb2xvcjogYmxhY2siPjxCPkRl IA0KICA6PC9CPiA8QSBocmVmPSJtYWlsdG8gOnNtaW1lLWJvdW5jZXNAaWV0Zi5vcmciPnNtaW1l LWJvdW5jZXM8L0E+IDwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IG5vcm1h bDsgRk9OVC1TSVpFOiA5cHQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQtU1RZTEU6IG5vcm1h bDsgRk9OVC1WQVJJQU5UOiBub3JtYWwiPjxCPsAgDQogIDo8L0I+IDxBIGhyZWY9Im1haWx0byA6 c21pbWVAaWV0Zi5vcmciPnNtaW1lPC9BPiA8L0RJVj4NCiAgPERJViANCiAgc3R5bGU9IkZPTlQt V0VJR0hUOiBub3JtYWw7IEZPTlQtU0laRTogOXB0OyBMSU5FLUhFSUdIVDogbm9ybWFsOyBGT05U LVNUWUxFOiBub3JtYWw7IEZPTlQtVkFSSUFOVDogbm9ybWFsIj48Qj5EYXRlIA0KICA6PC9CPiAy MDExLTAxLTA2LCAyMDowNDozNDwvRElWPg0KICA8RElWIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6 IG5vcm1hbDsgRk9OVC1TSVpFOiA5cHQ7IExJTkUtSEVJR0hUOiBub3JtYWw7IEZPTlQtU1RZTEU6 IG5vcm1hbDsgRk9OVC1WQVJJQU5UOiBub3JtYWwiPjxCPlN1amV0IA0KICA6PC9CPiBbc21pbWVd IEZ3ZDogSS1EIEFjdGlvbjpkcmFmdC1oZXJuYW5kZXotYXJkaWV0YS1zbWltZS1lZXNwLTAwLnR4 dDwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj48L0RJVj4NCiAgPERJVj4NCiAgPERJ Vj48VT48U1RST05HPlBp6GNlKHMpIEpvaW50ZShzKSBhdSBtZXNzYWdlIG9yaWdpbmFsIDo8L1NU Uk9ORz48L1U+PC9ESVY+DQogIDxESVY+Jm5ic3A7Jm5ic3A7KDEpLiZuYnNwO2RyYWZ0LWhlcm5h bmRlei1hcmRpZXRhLXNtaW1lLWVlc3AtMDAudHh0PC9ESVY+DQogIDxESVY+Jm5ic3A7Jm5ic3A7 KDIpLiZuYnNwO0F0dGFjaGVkIE1lc3NhZ2UgUGFydDwvRElWPjxCUj48L0RJVj4NCiAgPERJVj4N CiAgPERJVj5Tb21lIG9uIHRoaXMgbWFpbGluZyBsaXN0IG1pZ2h0IGZpbmQgdGhpcyBvZiBpbnRl cmVzdC4gSXQncyBoZWFkZWQgZm9yIA0KICA8QlI+ZXhwZXJpbWVudGFsLjxCUj48QlI+VGhlIGF1 dGhvcnMgaGF2ZSBhc2tlZCBmb3IgDQogIGNvbW1lbnRzLjxCUj48QlI+c3B0PEJSPjxCUj4tLS0t LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tPEJSPlN1YmplY3Q6IEktRCANCiAgQWN0aW9u OmRyYWZ0LWhlcm5hbmRlei1hcmRpZXRhLXNtaW1lLWVlc3AtMDAudHh0PEJSPkRhdGU6IFRodSwg MjMgRGVjIDIwMTAgDQogIDEwOjAwOjAyIC0wODAwPEJSPkZyb206IDxBIA0KICBocmVmPSJtYWls dG86IEludGVybmV0LURyYWZ0c0BpZXRmLm9yZyI+SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnPC9B PjxCUj5SZXBseS1UbzogDQogIDxBIGhyZWY9Im1haWx0bzogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L0E+PEJSPlRvOiANCiAgPEEgaHJlZj0ibWFp bHRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvQT48QlI+ PEJSPkEgTmV3IA0KICBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgDQogIDxCUj5kaXJlY3Rvcmllcy48QlI+PEJSPiZuYnNwOyZuYnNw O1RpdGxlIDogRXh0ZW5kZWQgRWxlY3Ryb25pYyBTaWduYXR1cmUgDQogIFBvbGljaWVzPEJSPiZu YnNwOyZuYnNwO0F1dGhvcihzKSA6IEouIA0KICBIZXJuYW5kZXotQXJkaWV0YTxCUj4mbmJzcDsm bmJzcDtGaWxlbmFtZSA6IA0KICBkcmFmdC1oZXJuYW5kZXotYXJkaWV0YS1zbWltZS1lZXNwLTAw LnR4dDxCUj4mbmJzcDsmbmJzcDtQYWdlcyA6IA0KICAyMTxCUj4mbmJzcDsmbmJzcDtEYXRlIDog MjAxMC0xMi0yMzxCUj48QlI+VGhpcyBkb2N1bWVudCBkZWZpbmVzIGV4dGVuZGVkIA0KICBlbGVj dHJvbmljIHNpZ25hdHVyZSBwb2xpY2llcyAoZXh0LVNQKTxCUj50aGF0IGV4dGVuZCB0aGUgYm91 bmRhcmllcyBvZiB0aGUgDQogIGVsZWN0cm9uaWMgc2lnbmF0dXJlIHBvbGljeSBkZWZpbmVkIGlu PEJSPltSRkMzMTI1XSBpbiBhIG1hbm5lciB0aGF0IHRoZSANCiAgcmVsYXRpb25zaGlwcyBhbmQg ZGVwZW5kZW5jZXMgYW1vbmc8QlI+bXVsdGlwbGUgZWxlY3Ryb25pYyBzaWduYXR1cmVzIA0KICBn ZW5lcmF0ZWQgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgc2FtZTxCUj5lbGVjdHJvbmljIHRyYW5z YWN0aW9uIGNhbiBiZSANCiAgZXN0YWJsaXNoZWQuIEEgZ2l2ZW4gbGVnYWwvY29udHJhY3R1YWw8 QlI+Y29udGV4dCBtYXkgcmVjb2duaXplIGEgcGFydGljdWxhciANCiAgZXh0LVNQIGFzIG1lZXRp bmcgaXRzIHJlcXVpcmVtZW50cy48QlI+PEJSPkFuIGV4dC1TUCBoYXMgYSBnbG9iYWxseSB1bmlx dWUgDQogIHJlZmVyZW5jZSwgd2hpY2ggaXMgYm91bmQgdG8gYW48QlI+ZWxlY3Ryb25pYyBzaWdu YXR1cmUgYnkgdGhlIHNpZ25lciBhcyBwYXJ0IA0KICBvZiB0aGUgc2lnbmF0dXJlIGNhbGN1bGF0 aW9uLjxCUj48QlI+VGhlIGV4dC1TUCBjYW4gYmUgZGVmaW5lZCBpbiBodW1hbiANCiAgcmVhZGFi bGUgZm9ybSBzbyB0aGF0IGl0IGNhbiBiZTxCUj5hc3Nlc3NlZCB0byBtZWV0IHRoZSByZXF1aXJl bWVudHMgb2YgdGhlIA0KICBsZWdhbCBhbmQgY29udHJhY3R1YWwgY29udGV4dDxCUj5pbiB3aGlj aCBpdCBpcyBiZWluZyBhcHBsaWVkLjxCUj48QlI+VG8gYWxsb3cgDQogIGZvciB0aGUgYXV0b21h dGljIHByb2Nlc3NpbmcsIHRoZSBleHQtU1Agc3BlY2lmaWVzLCB1c2luZyBhPEJSPmNvbXB1dGVy IA0KICBwcm9jZXNzYWJsZSBmb3JtLCB0aGUgdGltaW5nIGFuZCBzZXF1ZW5jZSBkZXBlbmRlbmNp ZXMgb2YgdGhlPEJSPnNldCBvZiANCiAgc2lnbmF0dXJlcyB0aGF0IG11c3QgYmUgZ2VuZXJhdGVk IHRvIG1ha2UgdGhlIHRyYW5zYWN0aW9uPEJSPmVmZmVjdGl2ZSBhbG9uZyANCiAgd2l0aCB0aGUg c2V0IG9mIGF0dHJpYnV0ZXMgYW5kIHJ1bGVzIHRoYXQgZWFjaCBzaWduYXR1cmU8QlI+bXVzdCBj b21wbHkgd2l0aC4gDQogIEluIHRoZSBjdXJyZW50IGRvY3VtZW50IHRoZSBmb3JtYXQgb2YgdGhl IGV4dC1TUCBpczxCUj5kZWZpbmVkIHVzaW5nIA0KICBBU04uMS48QlI+PEJSPlRoZSBjb250ZW50 IG9mIHRoaXMgZG9jdW1lbnQgaXMgYmFzZWQgb24gdGhlIHJlcXVpcmVtZW50cyBhbmQgDQogIG5l ZWRzPEJSPmVzdGFibGlzaGVkIGluIEVUU0kgVFIgMTAyIDA0NSBWMS4xLjEgKDIwMDMtMDMpIENv cHlyaWdodCANCiAgKEMpLjxCUj5JbmRpdmlkdWFsIGNvcGllcyBvZiB0aGlzIEVUU0kgZGVsaXZl cmFibGUgY2FuIGJlIGRvd25sb2FkZWQgDQogIGZyb208QlI+PEEgDQogIGhyZWY9Imh0dHA6Ly93 d3cuZXRzaS5vcmcuIj5odHRwOi8vd3d3LmV0c2kub3JnLjwvQT48QlI+PEJSPkRpc2N1c3Npb248 QlI+PEJSPlRoaXMgDQogIGRyYWZ0IGlzIGJlaW5nIGRpc2N1c3NlZCBvbiB0aGUgJ2lldGYtc21p bWUnIG1haWxpbmcgbGlzdC4gVG88QlI+c3Vic2NyaWJlLCANCiAgc2VuZCBhIG1lc3NhZ2UgdG8g PEEgDQogIGhyZWY9Im1haWx0bzogc21pbWUtcmVxdWVzdEBpZXRmLm9yZyI+c21pbWUtcmVxdWVz dEBpZXRmLm9yZzwvQT4gd2l0aCANCiAgdGhlPEJSPnNpbmdsZSB3b3JkIHN1YnNjcmliZSBpbiB0 aGUgYm9keSBvZiB0aGUgbWVzc2FnZS4gVGhlcmUgaXMgYSBXZWIgDQogIHNpdGU8QlI+Zm9yIHRo ZSBtYWlsaW5nIGxpc3QgYXQgPEEgDQogIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc21pbWUuIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NtaW1lLjwvQT48QlI+PEJSPkEgDQogIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8 QlI+PEEgDQogIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWhlcm5hbmRlei1hcmRpZXRhLXNtaW1lLWVlc3AtMDAudHh0Ij5odHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oZXJuYW5kZXotYXJkaWV0YS1zbWltZS1lZXNwLTAwLnR4 dDwvQT48QlI+PEJSPkludGVybmV0LURyYWZ0cyANCiAgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgDQogIGF0OjxCUj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz LzxCUj48QlI+QmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCANCiAgZW5hYmxlIGEgTUlNRSBj b21wbGlhbnQgbWFpbCByZWFkZXI8QlI+aW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSAN CiAgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YgDQogIHRoZTxCUj5JbnRlcm5ldC1EcmFm dC48QlI+PEJSPjxCUj48QlI+X19fX19fX19fX19fX19fX19fX19fIG5leHQgcGFydCANCiAgX19f X19fX19fX19fX19fX19fX19fXzxCUj48QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188QlI+c21pbWUgDQogIG1haWxpbmcgbGlzdDxCUj48QSBocmVmPSJt YWlsdG86IHNtaW1lQGlldGYub3JnIj5zbWltZUBpZXRmLm9yZzwvQT48QlI+PEEgDQogIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc21pbWUiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc21pbWU8L0E+PEJSPjxCUj48L0RJVj48L0RJVj48 L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_11012009113364552657307_002-- From trevorf@exchange.microsoft.com Fri Jan 21 09:24:52 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B83D28C118 for ; Fri, 21 Jan 2011 09:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2iCsbdXnV4K for ; Fri, 21 Jan 2011 09:24:51 -0800 (PST) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by core3.amsl.com (Postfix) with ESMTP id 44D2928C113 for ; Fri, 21 Jan 2011 09:24:51 -0800 (PST) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.1.218.15; Fri, 21 Jan 2011 09:27:37 -0800 Received: from df-mlt-02.exchange.corp.microsoft.com (157.54.94.20) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.1.270.2; Fri, 21 Jan 2011 09:27:39 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by DF-MLT-02.exchange.corp.microsoft.com ([157.54.94.20]) with mapi id 14.01.0218.012; Fri, 21 Jan 2011 09:27:37 -0800 From: Trevor Freeman To: "Smime (smime@ietf.org)" Thread-Topic: I-D Action:draft-freeman-message-access-control-req-00.txt Thread-Index: AQHLuPhLL32OTmd+fkG36zgaclKheJPbrj4Q Date: Fri, 21 Jan 2011 17:27:36 +0000 Message-ID: References: <20110120231501.13170.67353.idtracker@localhost> In-Reply-To: <20110120231501.13170.67353.idtracker@localhost> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.101] Content-Type: multipart/mixed; boundary="_002_E545B914D50B2A4B994F198378B1525D1564B0D6DFM1412exchange_" MIME-Version: 1.0 Subject: [smime] FW: I-D Action:draft-freeman-message-access-control-req-00.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 17:24:52 -0000 --_002_E545B914D50B2A4B994F198378B1525D1564B0D6DFM1412exchange_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This should be of interest to members of the members of the list.=20 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, January 20, 2011 3:15 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-freeman-message-access-control-req-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Requirements for Message Access Control Author(s) : T. Freeman, et al. Filename : draft-freeman-message-access-control-req-00.txt Pages : 17 Date : 2011-01-20 There are many situations where organizations want to include information which is subject to regulatory or other complex access control policy in email. Regulated information requires some form of robust access control to protect the confidentiality of the information. The Enhanced Security Services for S/MIME [rfc2634] defines an access control mechanism for S/MIME (eSSSecurityLabel). This is a signed attribute of a SignedData object which indicates the access control policy for the message. The fact that this is a signed attribute protects the integrity of the data and the binding of the label to the message but does not protect the confidentiality of the information i.e. at the point where you lean the access control policy to the data you also have access to the data. While the signature provides integrity for the label over the clear text, it is susceptible to unauthorized removal i.e. if you only have SignedData message, any MTA in the mail path can remove a signature layer and therefore remove the access control data. Encrypting the signed message protects the confidentiality of the data and protects the SignedData from unauthorized removal but this hides the ESS security label. From a regulatory enforcement perspective this is an extremely weak form of access control because cryptographic access to the data is given before the access check. The correct enforcement of the access check totally depends on the configuration of the recipients email client. Since the cryptographic access is granted before the access checks, there is no significant impediment for a recipient who is unauthorized under the policy to access the data. A stronger enforcement model is needed for regulatory control for email where cryptographic access is only granted after the access check. There are also many users on the Internet today who have some form of authentication credential but they are not X.509 certificates and who therefore cannot use S/MIME. There are now available, standard based services (e.g. [SAML-overview]) which abstract the specifics of a technology used to authenticate uses from the application itself (S/MIME = in this case). Adoption of this abstraction model would enable a broader set of users who have other types to authentication credentials to be able to use S/MIME to secure email. It also allows for new authentication technology to be deployed without impacting the core S/MIME protocol.=20 This document specifies the requirements for:- Providing robust access control for S/MIME An abstraction layer for supporting other types of credentials for using S/MIME. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-freeman-message-access-control-re= q-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. --_002_E545B914D50B2A4B994F198378B1525D1564B0D6DFM1412exchange_ Content-Type: text/plain; name="draft-freeman-message-access-control-req-00.url.txt" Content-Description: draft-freeman-message-access-control-req-00.url.txt Content-Disposition: attachment; filename="draft-freeman-message-access-control-req-00.url.txt"; size=108; creation-date="Thu, 20 Jan 2011 23:18:06 GMT"; modification-date="Thu, 20 Jan 2011 23:18:06 GMT" Content-Transfer-Encoding: base64 VGhpcyBhdHRhY2htZW50IHdhcyByZW1vdmVkLg== --_002_E545B914D50B2A4B994F198378B1525D1564B0D6DFM1412exchange_-- From paul.hoffman@vpnc.org Fri Jan 21 09:35:01 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FF73A6A67 for ; Fri, 21 Jan 2011 09:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.731 X-Spam-Level: X-Spam-Status: No, score=-101.731 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nepJBtxkE+EC for ; Fri, 21 Jan 2011 09:35:01 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E3B693A6A66 for ; Fri, 21 Jan 2011 09:35:00 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0LHbkxh021919 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 21 Jan 2011 10:37:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D39C46A.9060705@vpnc.org> Date: Fri, 21 Jan 2011 09:37:46 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: smime@ietf.org References: <20110120231501.13170.67353.idtracker@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [smime] FW: I-D Action:draft-freeman-message-access-control-req-00.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 17:35:02 -0000 On 1/21/11 9:27 AM, Trevor Freeman wrote: > This should be of interest to members of the members of the list. Should be, yes. Could you explain a bit of the motivation for the document? Is there a particular regulatory driver for this, or just a general desire to make this available? Knowing this would help people understand your design and possibly make comments on it. From trevorf@exchange.microsoft.com Fri Jan 21 10:23:22 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0203A6A76 for ; Fri, 21 Jan 2011 10:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBmDSjaUV92r for ; Fri, 21 Jan 2011 10:23:21 -0800 (PST) Received: from mail.exchange.microsoft.com (mail7.exchange.microsoft.com [131.107.1.27]) by core3.amsl.com (Postfix) with ESMTP id 0C4DE3A6A7A for ; Fri, 21 Jan 2011 10:23:20 -0800 (PST) Received: from df-h14-01.exchange.corp.microsoft.com (157.54.78.139) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.1.218.15; Fri, 21 Jan 2011 10:26:07 -0800 Received: from DF-MLT-01.exchange.corp.microsoft.com (157.54.94.40) by DF-H14-01.exchange.corp.microsoft.com (157.54.78.139) with Microsoft SMTP Server (TLS) id 14.1.270.2; Fri, 21 Jan 2011 10:26:08 -0800 Received: from DF-M14-12.exchange.corp.microsoft.com ([fe80::7c94:4036:120:c95f]) by DF-MLT-01.exchange.corp.microsoft.com ([157.54.94.40]) with mapi id 14.01.0218.012; Fri, 21 Jan 2011 10:26:07 -0800 From: Trevor Freeman To: Paul Hoffman , "smime@ietf.org" Thread-Topic: [smime] FW: I-D Action:draft-freeman-message-access-control-req-00.txt Thread-Index: AQHLuZHu/2OKTiNeB0uO4AXm8DgoZJPbsM1g Date: Fri, 21 Jan 2011 18:26:06 +0000 Message-ID: References: <20110120231501.13170.67353.idtracker@localhost> <4D39C46A.9060705@vpnc.org> In-Reply-To: <4D39C46A.9060705@vpnc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [smime] FW: I-D Action:draft-freeman-message-access-control-req-00.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 18:23:22 -0000 Hi Paul, First motivation is an observation that there a number of scenarios where t= he natural course of action would be to send some information in a message = which is covered by one or more polices. We see that email is not being use= d in these casas or is being used with some risk of non-compliance because = of the lack of policy enforcement. Those polices may be for example a regul= atory policy, or an organization policy or both. The duty to enforce the po= licy is asymmetric by that I mean the onus is on the sender to ensure the i= nformation is only released when the other parties have passed the policy r= equirements. With ESS today the onus is on the recipient to not read the em= ail. With content published on the web, the requestor has to convince the w= eb site to release the information and we want to use the same model for em= ail. I am working with a number of Aerospace and Defense companies which ha= s as an industry adopted S/MIME for email. This is delivering well as far a= s the existing standard can but we have found it lacking when it comes to d= elivering regulatory compliance. I have discussed the same issues with repr= esentative from other verticals such as healthcare and they have agreed wit= h the observations.=20 Another motivation is the observation that we still have many situations wh= ere users don't have X.509 certificates and are hence prevented from partic= ipating in S/MIME. With abstraction models such as SAML, it is now possibl= e for the specifics of the authentication to be abstracted from an applicat= ion. If we can deliver the same benefit to email as SAML has delivered to t= he web we can switch the requirement to users having a policy conformant cr= edential and the relying part does not care what. It could be OTP or biomet= ric or whatever as long as it's the required strength rather than it MUST b= e an X.509 certificate. Overall we are looking to convergence of email and the web from a policy pe= rspective. If you publish some content with the web or send it via email th= e same policies need apply. The same sets of attribute you use to access we= b for access control policy content should get you the same content via ema= il.=20 We think we can achieve the objectives and, within the scope of policy, and= be backwards compatible with the existing standard. If the sender is convi= nced some set of recipients pass the policy check and they can find X.509 c= ertificates, they can use the existing mechanism else you use the new mecha= nism. We believe we can mix both on the same message.=20 Trevor -----Original Message----- From: smime-bounces@ietf.org [mailto:smime-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Friday, January 21, 2011 9:38 AM To: smime@ietf.org Subject: Re: [smime] FW: I-D Action:draft-freeman-message-access-control-re= q-00.txt On 1/21/11 9:27 AM, Trevor Freeman wrote: > This should be of interest to members of the members of the list. Should be, yes. Could you explain a bit of the motivation for the document?= Is there a particular regulatory driver for this, or just a general desire= to make this available? Knowing this would help people understand your des= ign and possibly make comments on it. _______________________________________________ smime mailing list smime@ietf.org https://www.ietf.org/mailman/listinfo/smime From ietf@augustcellars.com Fri Jan 21 10:33:23 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7398328C0FF for ; Fri, 21 Jan 2011 10:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDLs-lNAhP3c for ; Fri, 21 Jan 2011 10:33:22 -0800 (PST) Received: from new-smtp02.pacifier.net (new-smtp02.pacifier.net [64.255.237.176]) by core3.amsl.com (Postfix) with ESMTP id 5CD0D28C0F5 for ; Fri, 21 Jan 2011 10:33:22 -0800 (PST) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp02.pacifier.net (Postfix) with ESMTPSA id AA3762CA13 for ; Fri, 21 Jan 2011 10:36:08 -0800 (PST) From: "Jim Schaad" To: "'Smime'" References: <20110120231501.13170.67353.idtracker@localhost> In-Reply-To: Date: Fri, 21 Jan 2011 10:54:39 -0800 Message-ID: <021501cbb99c$a8512cc0$f8f38640$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIjIdhr+nesR763fQZAaCkXLQV6lAH0dYeukx1RJaA= Content-Language: en-us Subject: Re: [smime] FW: I-D Action:draft-freeman-message-access-control-req-00.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 18:33:23 -0000 I have additionally released two documents which provide a potential method of implementing the requirements These are: http://www.ietf.org/id/draft-schaad-eps-smime-00.txt which describes the additions to the CMS and S/MIME formats to support the concept and http://www.ietf.org/id/draft-schaad-eps-trust-00.txt which gives a possible description of how to communicate between the mail client and the enforcement server. Jim > -----Original Message----- > From: smime-bounces@ietf.org [mailto:smime-bounces@ietf.org] On Behalf > Of Trevor Freeman > Sent: Friday, January 21, 2011 9:28 AM > To: Smime (smime@ietf.org) > Subject: [smime] FW: I-D Action:draft-freeman-message-access-control-req- > 00.txt > > This should be of interest to members of the members of the list. > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Thursday, January 20, 2011 3:15 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-freeman-message-access-control-req-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Requirements for Message Access Control > Author(s) : T. Freeman, et al. > Filename : draft-freeman-message-access-control-req-00.txt > Pages : 17 > Date : 2011-01-20 > > There are many situations where organizations want to include > information which is subject to regulatory or other complex access > control policy in email. Regulated information requires some form of > robust access control to protect the confidentiality of the > information. The Enhanced Security Services for S/MIME [rfc2634] > defines an access control mechanism for S/MIME (eSSSecurityLabel). > This is a signed attribute of a SignedData object which indicates the > access control policy for the message. The fact that this is a signed > attribute protects the integrity of the data and the binding of the > label to the message but does not protect the confidentiality of the > information i.e. at the point where you lean the access control policy > to the data you also have access to the data. While the signature > provides integrity for the label over the clear text, it is > susceptible to unauthorized removal i.e. if you only have SignedData > message, any MTA in the mail path can remove a signature layer and > therefore remove the access control data. Encrypting the signed > message protects the confidentiality of the data and protects the > SignedData from unauthorized removal but this hides the ESS security > label. > > From a regulatory enforcement perspective this is an extremely weak > form of access control because cryptographic access to the data is > given before the access check. The correct enforcement of the access > check totally depends on the configuration of the recipients email > client. Since the cryptographic access is granted before the access > checks, there is no significant impediment for a recipient who is > unauthorized under the policy to access the data. A stronger > enforcement model is needed for regulatory control for email where > cryptographic access is only granted after the access check. > > There are also many users on the Internet today who have some form of > authentication credential but they are not X.509 certificates and who > therefore cannot use S/MIME. There are now available, standard based > services (e.g. [SAML-overview]) which abstract the specifics of a > technology used to authenticate uses from the application itself (S/MIME in > this case). Adoption of this abstraction model would enable > a broader set of users who have other types to authentication > credentials to be able to use S/MIME to secure email. It also allows > for new authentication technology to be deployed without impacting the > core S/MIME protocol. > > This document specifies the requirements for:- > > > Providing robust access control for S/MIME > > > An abstraction layer for supporting other types of credentials for > > using S/MIME. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-freeman-message-access- > control-req-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Internet- > Draft. From paul.hoffman@vpnc.org Tue Jan 25 09:21:47 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31AC53A6835 for ; Tue, 25 Jan 2011 09:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.734 X-Spam-Level: X-Spam-Status: No, score=-101.734 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naKxmEd4Rrx3 for ; Tue, 25 Jan 2011 09:21:46 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 29DE03A6806 for ; Tue, 25 Jan 2011 09:21:45 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0PHOhIQ037835 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 25 Jan 2011 10:24:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3F075A.6020803@vpnc.org> Date: Tue, 25 Jan 2011 09:24:42 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: smime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [smime] Fwd: Protocol Action: 'Cryptographic Messages Syntax (CMS) Algorithm Identifier Protection Attribute' to Proposed Standard (draft-schaad-smime-algorithm-attribute-05.txt) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 17:21:47 -0000 -------- Original Message -------- Subject: Protocol Action: 'Cryptographic Messages Syntax (CMS) Algorithm Identifier Protection Attribute' to Proposed Standard (draft-schaad-smime-algorithm-attribute-05.txt) Date: Tue, 25 Jan 2011 09:05:49 -0800 From: The IESG To: IETF-Announce CC: Internet Architecture Board , RFC Editor The IESG has approved the following document: - 'Cryptographic Messages Syntax (CMS) Algorithm Identifier Protection Attribute' (draft-schaad-smime-algorithm-attribute-05.txt) as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-schaad-smime-algorithm-attribute/ Technical Summary An authenticated/signed attribute is defined to protect the algorithm definitions of the message body and the signature. Currently this information is not included in the signature computation and could theoretically be changed without the signature validator knowing. This provides an attack avenue on CMS signature and authentication operations that currently has no known successful attacks. The new attribute is prophylactic. Working Group Summary There was a small amount of discussion on the working group list if this should be expanded to include the new authenticated encryption algorithms. It was decided that these should be treated separately by any interested community. The document was considered in the S/MIME working group, but there was no push for adoption as it was believed that the working group would be shutting down shortly. Document Quality The document has been implemented by the author and an example of using the attribute can be found in draft-schaad-smime-hash-experiment. There are no known plans for vendors to implement this, but I have received private email asking as to the status of the document. Personnel Jim Schaad (ietf@augustcellars.com) is the Document Shepherd. Sean Turner (turners@ieca.com) is the Responsible Area Director. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From paul.hoffman@vpnc.org Tue Jan 25 15:06:40 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7FF63A68D3 for ; Tue, 25 Jan 2011 15:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.738 X-Spam-Level: X-Spam-Status: No, score=-101.738 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbIol8MIa5kG for ; Tue, 25 Jan 2011 15:06:40 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1BBE43A68CD for ; Tue, 25 Jan 2011 15:06:39 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0PN9bN7054391 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 25 Jan 2011 16:09:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D3F5831.3020808@vpnc.org> Date: Tue, 25 Jan 2011 15:09:37 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: smime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [smime] Fwd: Document Action: 'Experiment: Hash functions with parameters in CMS and S/MIME' to Experimental RFC (draft-schaad-smime-hash-experiment-06.txt) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 23:06:41 -0000 -------- Original Message -------- Subject: Document Action: 'Experiment: Hash functions with parameters in CMS and S/MIME' to Experimental RFC (draft-schaad-smime-hash-experiment-06.txt) Date: Tue, 25 Jan 2011 13:18:52 -0800 From: The IESG To: IETF-Announce CC: Internet Architecture Board , RFC Editor The IESG has approved the following document: - 'Experiment: Hash functions with parameters in CMS and S/MIME' (draft-schaad-smime-hash-experiment-06.txt) as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-schaad-smime-hash-experiment/ Technical Summary The document describes an experiment to determine if any current implementers have dealt with a new class of hash algorithms which are not currently deployed. In order to do this a new hash algorithm w/ parameters is defined for use with this experiment and some examples of the use of the new hash algorithm are included in the document. Working Group Summary The S/MIME working group did not consider adopting the document as it was considered to be esoteric and the working group was planning to shut down soon. There were no interesting issues discussed on the document. Document Quality One implementation of the system exists by the author of the document. No other known implementations exist. I would not expect people to consider looking at the document seriously until a serious contender for a hash algorithm with parameters is presented to the community. Personnel Jim Schaad (ietf@augustcellars.com) is the Document Shepherd. Sean Turner (turners@ieca.com) is the Responsible Area Director. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From jlopez.ha@gmail.com Wed Jan 26 02:48:43 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76EB93A699E for ; Wed, 26 Jan 2011 02:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4O44TNLm1kx for ; Wed, 26 Jan 2011 02:48:39 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 68A253A697D for ; Wed, 26 Jan 2011 02:48:39 -0800 (PST) Received: by qyk34 with SMTP id 34so5215443qyk.10 for ; Wed, 26 Jan 2011 02:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YgUvc8FIsGHtA1xN78lQUzkmY26B13T+WBcFts1QMMc=; b=g1+SeVAxi6d9mJJaoZ1dBxtoOaSpG7AS6jOiFAAKZ9pWQH+qOfD6tywv2QgTdU7BTc K5wbUcLbb06GlykM7L6CgZkqnldAT/o2KWtsRY4+YxDM24a8FA/i4RWeBXR4Zyk/njUd brxmkwe6ZKVT8SDYcJ0rR4ZIYPgUcYOc7v694= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aseuorUTzklxdJYYFAYjw+lWAs6Hurwr28hQDD2MU33n1U0mZXYuc/4horEQLeDEmT 9Wl/hp6N0Xq9DLM9nsKCAkO70/AALvw+k6+sxuVvHrtwKmfZxsP3J+7/QgIh6kh6D+z0 XWgeB+vUjD5Sw+Z1w6zwLdXKiZrle1irqtFyw= MIME-Version: 1.0 Received: by 10.229.240.85 with SMTP id kz21mr293286qcb.2.1296039098105; Wed, 26 Jan 2011 02:51:38 -0800 (PST) Received: by 10.229.86.130 with HTTP; Wed, 26 Jan 2011 02:51:37 -0800 (PST) In-Reply-To: References: <4D261242.103@ieca.com> Date: Wed, 26 Jan 2011 11:51:37 +0100 Message-ID: From: =?ISO-8859-1?Q?Jorge_L=F3pez?= To: denis.pinkas@bull.net Content-Type: multipart/alternative; boundary=0016363101e50ec0a7049abd9ea6 Cc: =?ISO-8859-1?Q?Ana_Isabel_Gonz=E1lez=2DTablas_Ferreres?= , smime Subject: Re: [smime] Fwd: I-D Action:draft-hernandez-ardieta-smime-eesp-00.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 10:48:43 -0000 --0016363101e50ec0a7049abd9ea6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Denis, Thanks for your valuable and prompt comments on the draft. Answers inline. 1. The topic of the document is interesting. However, the overall ASN.1 syntax that is proposed is too complicated. It should be simplified. 2. On page 6, the text states: =93This document defines but does not mandate the form of the ext-SP Specification=94. The point is well taken, however the structure of the document should be changed to follow this statement: the document should first describe the new signed attributes able to identify the extended signature policy and have a second part which describes the ASN.1 format. It would be nice to support both CAdES and XAdES signatures, so two new signed attributes would need to be defined: one for XAdES and another one for CAdES. [JORGE] Agree. The XAdES format has currently limitations: a XAdES signature contains one and only one signature that can be countersigned. A CAdES signature is more flexible: it may contain parallel signatures; where each of them can be countersigned. There is some work being done in ESTI TC ESI to allow supporting XAdES parallel signatures. [JORGE] We are interested in this work. Is there any draft we could take a look at? 3. Since XAdES support IODs as URNs and OIDs as URIs, the syntax being developed should be able to accommodate both. Change ExtSignPolicyId accordingly. [JORGE] Do you mean Information Object Definition (IOD)? OK, we=92ll take a look at that. 4. On page 7, the syntax includes: extSignPolicyProtection ExtSignPolicyProtection OPTIONAL I do not believe that this field is needed. It is unnecessary to sign such structures. If you really would like it to be signed, a simple cryptographic checksum would be insufficient, since you don=92t know which key or certificate to use to ver= ify it. A CAdES signature would be fine but too complicated (and not necessary). Delete extSignPolicyProtection. [JORGE] Agree. To solve this, we propose to incorporate a hash algorithm an= d hash value fields to allow the parties to distinguish between different policies in an easy manner. A remark indicating that an external protection mechanism SHOULD be used would be incorporated. 5. The signingPeriod is mandatory. For more flexibility, it would be better to make it OPTIONAL. [JORGE] We think that this field is paramount to permit signers to ascertai= n whether an extended policy can be used or not, and relying parties to conclude about the validity of a signature generated according to certain extended policy. RFC 3125 follows this criterion. What is reasonable is to change MUST by SHOULD in the field explanation (page 9). 6. The major part is contained in section 3.3.1. Three types of signatures are identified. ETSI TC ESI currently only considers two types: parallel and embedded. I wonder whether sequential signatures make sense. How such signatures woul= d look like, when you look at the bit string level ? [JORGE] Sequential signatures have been defined in several documents, including ETSI TR 102 045 v1.1.1 (see section 9.2): =93Sequential signature= s are of variation parallel signatures, but where the ordering of the signatures is significant=94. As ETSI recognizes, =93Parallel and embedded signatures have been described in previous literature: sequential signature= s are not a well-recognized entity=94. However, it does not mean that they ar= e not important to implement certain business models. In our opinion, there are many situations where the existence of sequential signatures is absolutely necessary or more appropriate than the usage of countersignatures. As defined by ETSI TR, =93sequential signatures also may= or may not be applied to the same data content=94. In our Draft, however, we d= o restrict the data to which sequential signatures can be applied to the same piece of information. I would guess that you would need a new signed attribute. This would complicate the basic format of a CAdES signature or a XAdES signature. Unless you have strong arguments on this point, sequential signatures should be discarded. [JORGE] We don=92t think that a new signed attribute is needed. We agree th= at it would make current formats and signature processing more complicated. In our opinion, sequential signatures are a conceptual type of signature, with no factual difference respecting a parallel signature. That is, looking at the bit string level, there is no difference. The decision about whether a signature is (or should be) parallel or sequential stems from the contextua= l requirements, and as stipulated in the extended policy. 7. The tree graph is too complicated. Avoid recursive methods. [JORGE] We do not see how a tree of signatures without a predefined structure in terms of breadth, depth, nodes at each level, etc. could be defined in the extended policy without using a recursive method. Please tak= e into account that this draft should permit to instantiate any potential tre= e of signatures according to the specific business needs. Some people may nee= d to specify just two parallel signatures while others may need a complex tre= e of, say, three levels of depth and several signatures at each level. Suggestions are welcomed. The CAdES format is simple: n parallel signatures each of them can be countersigned any number of times. There needs to be n parallel signatures (called PS in the draft) and for each primary signature (PS) from 1 to n tell how many numbers of countersignatures are needed. Note that countersignatures are necessarily made in sequence. I do not thin= k the figure is appropriate when CS1 and CS2 are represented on the same line. [JORGE] Mm, we don=92t see your point here. Do you mean that the figure is confusing respecting CS1 and CS2? If so, what changes should be made? Pleas= e note that we intended to represent two countersignatures generated over the same signature (PS2). The order in which both countersignatures are generated are not (or we did not intended to) represented in the figure. The current description for TreesOfSolutions is too complicated. =93identifier=94 and =93signer=94 are not understandable. Please try to ado= pt a simpler structure. [JORGE] Agree. We=92ll try to accommodate the descriptions. 8. For the timingAndSequence the draft states: =93The time frame during whi= ch a signature must be generated=94. SigningPeriod is defined as: SigningPeriod ::=3D SEQUENCE { notBefore GeneralizedTime, notAfter GeneralizedTime OPTIONAL } This does not make sense: it is impossible to use an absolute time. [JORGE] You are right Denis. Defining an absolute time would imply having a priori the knowledge about when the signatures are going to be generated. This is a limitation we found out after publishing our work. Assuming that this constraint may be interesting in certain scenarios, we came up with a solution that consists of dynamically instantiating the extended policy before the transaction is going to be carried out. This solution does not have an impact on the policy definition. However, it has important drawback= s in terms of performance. As we would like to include this =93functionality= =94 in the extended policy, we would welcome any proposal in this direction. It is only possible to say, e.g. that the second signature *should* be don= e within x hours after the first one and that the first countersignature *should* be done within y hours. It is only an indication of the speed of the workflow, no more. Note that *shall* is not used. This is more or less the idea behind relativeTimingAndSequence. It is however debatable whether this level of complexity is really needed. I would suppress it for making the structure simpler. [JORGE] We strongly believe that the benefits are worth the added complexity. In our opinion, reducing the complexity of the structure would lead to a dangerously limited policy. 9. The concept of signing role as defined in section 3.5 is inappropriate. This should be replaced by the notions of claimed role and/or certified role where the identity of the signer is not important, but its functional role is fundamental. [JORGE] We borrowed the definition from ETSI TR 102 045 v1.1.1 (section 9.4.1), though we also agree that this section does not provide much information to the document. We will delete this section. 10. Section 5 should be placed before the ASN.1 description of the ext-SP. [JORGE] Agree. 11. Another section should come after dedicated to =93Integration in XAdES formats=94. [JORGE] Agree, though we are interested to know if it is common to make references to XML-based issues in RFCs, which are usually purely ASN.1 based. 12. A minor editing: on page 5, the text states: =93The Signer is the entity that creates one or more electronic signatures represented in the ext-SP content. The signer MUST digitally sign over a signature policy identifier and an extended signature policy identifier.=94 The sentences should be reworded as follows: =93A Signer is an entity that creates one or more electronic signatures represented in the ext-SP content. Every signer MUST digitally sign using signature policy identifier and an extended signature policy identifier.=94 [JORGE] OK. 13. One typo: on page 4: Frenquently [JORGE] OK. Denis PS. I copy this mail to the ETSI TC ESI list. 2011/1/20 Denis Pinkas > Comments on draft-hernandez-ardieta-smime-eesp-00 > > 1. The topic of the document is interesting. However, the overall ASN.1 > syntax > that is proposed is too complicated. It should be simplified. > > > > 2. On page 6, the text states: > > > > =93This document defines but does not mandate the form of the ext-SP > Specification=94. > > The point is well taken, however the structure of the document should be > changed > to follow this statement: the document should first describe the new sign= ed > attributes > able to identify the extended signature policy and have a second part whi= ch > > describes the ASN.1 format. > > > > It would be nice to support both CAdES and XAdES signatures, so two new > signed attributes > would need to be defined: one for XAdES and another one for CAdES. > > > > The XAdES format has currently limitations: a XAdES signature contains on= e > and only one > signature that can be countersigned. A CAdES signature is more flexible: = it > may contain > parallel signatures; where each of them can be countersigned. > > > > There is some work being done in ESTI TC ESI to allow supporting XAdES > parallel signatures. > > > > 3. Since XAdES support IODs as URNs and OIDs as URIs, the syntax being > developed should be able > to accommodate both. Change ExtSignPolicyId accordingly. > > > > 4. On page 7, the syntax includes: > > > > extSignPolicyProtection ExtSignPolicyProtection OPTIONAL > > > > I do not believe that this field is needed. It is unnecessary to sign suc= h > structures. > If you really would like it to be signed, a simple cryptographic checksum > would be > insufficient, since you don=92t know which key or certificate to use to > verify it. > A CAdES signature would be fine but too complicated (and not necessary). > Delete extSignPolicyProtection. > > > > 5. The signingPeriod is mandatory. For more flexibility, it would be > better to make it OPTIONAL. > > > > 6. The major part is contained in section 3.3.1. Three types of signature= s > are identified. > ETSI TC ESI currently only considers two types: parallel and embedded. > > > > I wonder whether sequential signatures make sense. How such signatures > would look like, > when you look at the bit string level ? > > > > I would guess that you would need a new signed attribute. This would > complicate the basic format > of a CAdES signature or a XAdES signature. Unless you have strong argumen= ts > on this point, > sequential signatures should be discarded. > > > > 7. The tree graph is too complicated. Avoid recursive methods. > > > > The CAdES format is simple: n parallel signatures each of them can be > countersigned any number of times. > There needs to be n parallel signatures (called PS in the draft) and for > each primary signature (PS) > from 1 to n tell how many numbers of countersignatures are needed. > > > > Note that countersignatures are necessarily made in sequence. I do not > think the figure is appropriate > when CS1 and CS2 are represented on the same line. > > > > The current description for TreesOfSolutions is too complicated. > > =93identifier=94 and =93signer=94 are not understandable. Please try to a= dopt a > simpler structure. > > > > 8. For the timingAndSequence the draft states: =93The time frame during > which a signature must be generated=94. > SigningPeriod is defined as: > > > > SigningPeriod ::=3D SEQUENCE { > > notBefore GeneralizedTime, > > notAfter GeneralizedTime OPTIONAL } > > > > This does not make sense: it is impossible to use an absolute time. > > It is only possible to say, e.g. that the second signature *should* be do= ne > within x hours > after the first one and that the first countersignature *should* be done > within y hours. > It is only an indication of the speed of the workflow, no more. Note that > *shall* is not used. > > > > This is more or less the idea behind relativeTimingAndSequence. It is > however debatable whether > this level of complexity is really needed. I would suppress it for making > the structure simpler. > > > > 9. The concept of signing role as defined in section 3.5 is inappropriate= . > This should be replaced > by the notions of claimed role and/or certified role where the identity o= f > the signer is not important, > but its functional role is fundamental. > > > > 10. Section 5 should be placed before the ASN.1 description of the ext-SP= . > > > > > 11. Another section should come after dedicated to =93Integration in XAdE= S > formats=94. > > > > 12. A minor editing: on page 5, the text states: > > > > =93The Signer is the entity that creates one or more electronic signature= s > represented > in the ext-SP content. The signer MUST digitally sign over a signature > policy identifier and > an extended signature policy identifier.=94 > > > > The sentences should be reworded as follows: > > > > =93A Signer is an entity that creates one or more electronic signatures > represented in the ext-SP content. > Every signer MUST digitally sign using signature policy identifier and an > extended signature policy identifier.=94 > > > > 13. One typo: on page 4: Frenquently > > Denis > > > > PS. I copy this mail to the ETSI TC ESI list. > > > > > --------- > *De :* smime-bounces > *=C0 :* smime > *Date :* 2011-01-06, 20:04:34 > *Sujet :* [smime] Fwd: I-D > Action:draft-hernandez-ardieta-smime-eesp-00.txt > > *Pi=E8ce(s) Jointe(s) au message original :* > (1). draft-hernandez-ardieta-smime-eesp-00.txt > (2). Attached Message Part > > Some on this mailing list might find this of interest. It's headed for > experimental. > > The authors have asked for comments. > > spt > > -------- Original Message -------- > Subject: I-D Action:draft-hernandez-ardieta-smime-eesp-00.txt > Date: Thu, 23 Dec 2010 10:00:02 -0800 > From: Internet-Drafts@ietf.org <+Internet-Drafts@ietf.org> > Reply-To: internet-drafts@ietf.org <+internet-drafts@ietf.org> > To: i-d-announce@ietf.org <+i-d-announce@ietf.org> > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Extended Electronic Signature Policies > Author(s) : J. Hernandez-Ardieta > Filename : draft-hernandez-ardieta-smime-eesp-00.txt > Pages : 21 > Date : 2010-12-23 > > This document defines extended electronic signature policies (ext-SP) > that extend the boundaries of the electronic signature policy defined in > [RFC3125] in a manner that the relationships and dependences among > multiple electronic signatures generated within the scope of the same > electronic transaction can be established. A given legal/contractual > context may recognize a particular ext-SP as meeting its requirements. > > An ext-SP has a globally unique reference, which is bound to an > electronic signature by the signer as part of the signature calculation. > > The ext-SP can be defined in human readable form so that it can be > assessed to meet the requirements of the legal and contractual context > in which it is being applied. > > To allow for the automatic processing, the ext-SP specifies, using a > computer processable form, the timing and sequence dependencies of the > set of signatures that must be generated to make the transaction > effective along with the set of attributes and rules that each signature > must comply with. In the current document the format of the ext-SP is > defined using ASN.1. > > The content of this document is based on the requirements and needs > established in ETSI TR 102 045 V1.1.1 (2003-03) Copyright (C). > Individual copies of this ETSI deliverable can be downloaded from > http://www.etsi.org. > > Discussion > > This draft is being discussed on the 'ietf-smime' mailing list. To > subscribe, send a message to smime-request@ietf.org<+smime-request@ietf.o= rg>with the > single word subscribe in the body of the message. There is a Web site > for the mailing list at https://www.ietf.org/mailman/listinfo/smime. > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-hernandez-ardieta-smime-eesp-00= .txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _____________________ next part ______________________ > > > _______________________________________________ > smime mailing list > smime@ietf.org <+smime@ietf.org> > https://www.ietf.org/mailman/listinfo/smime > > --0016363101e50ec0a7049abd9ea6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Dear Denis,

=A0

Thanks for your valuable and prompt comments on th= e draft. Answers inline.

=A0

1.=A0The topic of the document is interesting. However,= the overall ASN.1 syntax=A0
that is proposed is too complicated. It should be simplified.=A0

=A0

2.=A0On page 6, the text states:

=A0

=93This document defines but does not mandate the = form of the ext-SP Specification=94.

The point is well taken, however the structure of the document should be changed=A0
to follow this statement: the document should first describe the new signed attributes=A0
able to identify the extended signature policy and have a second part which= =A0
describes the ASN.1 format.

=A0

It would be nice to support both CAdES and XAdES signatures, so two new signed attributes=A0
would need to be defined: one for XAdES and another one for CAdES.

=A0

[JORGE] Agree.

=A0

The XAdES format has currently limitations: a XAdE= S signature contains one and only one=A0
signature that can be countersigned. A CAdES signature is more flexible: it= may contain=A0
parallel signatures; where each of them can be countersigned.

=A0

There is some work being done in ESTI TC ESI to al= low supporting XAdES parallel signatures.=A0

=A0

[JORGE] We are interested in this work. Is there a= ny draft we could take a look at?

=A0

3.=A0Since XAdES support IODs as URNs and OIDs as URIs,= the syntax being developed should be able=A0
to accommodate both. Change ExtSignPolicyId accordingly.=A0

=A0

[JORGE] Do you mean Information Object Definition (IOD)? OK, we=92ll take a look at that.

=A0

4.=A0On page 7, the syntax includes:

=A0

=A0=A0extSignPolicyProtection ExtSignPolicyProtection OPTIONAL

=A0

I do not believe that this field is needed. It is unnecessary to sign such structures.=A0
If you really would like it to be signed, a simple cryptographic checksum w= ould be=A0
insufficient, since you don=92t know which key or certificate to use to ver= ify it.=A0
A CAdES signature would be fine but too complicated (and not necessary).=A0
Delete extSignPolicyProtection.=A0

=A0

[JORGE] Agree. To solve this, we propose to incorp= orate a hash algorithm and hash value fields to allow the parties to distinguish between different policies in an easy manner. A remark indicating that an external protection mechanism SHOULD be used would be incorporated. =

=A0

5.=A0The signingPeriod is mandatory. For more flexibili= ty, it would be better to make it OPTIONAL.=A0

=A0

[JORGE] We think that this field is paramount to permit signers to ascertain whether an extended policy can be used or not, = and relying parties to conclude about the validity of a signature generated according to certain extended policy. RFC 3125 follows this criterion. What= is reasonable is to change MUST by SHOULD in the field explanation (page 9).

=A0

6.=A0The major part is contained in section 3.3.1. Thre= e types of signatures are identified.=A0
ETSI TC ESI currently only considers two types: parallel and embedded.

=A0

I wonder whether sequential signatures make sense.= How such signatures would look like,=A0
when you look at the bit string level ?

=A0

[JORGE] Sequential signatures have been defined in several documents, including ETSI TR 102 045 v1.1.1 (see section 9.2): =93S= equential signatures are of variation parallel signatures, but where the ordering of = the signatures is significant=94. As ETSI recognizes, =93Parallel and embedded signatures have been described in previous literature: sequential signature= s are not a well-recognized entity=94. However, it does not mean that they ar= e not important to implement certain business models. In our opinion, there are m= any situations where the existence of sequential signatures is absolutely neces= sary or more appropriate than the usage of countersignatures. As defined by ETSI= TR, =93sequential signatures also may or may not be applied to the same data co= ntent=94. In our Draft, however, we do restrict the data to which sequential signatur= es can be applied to the same piece of information.

=A0

I would guess that you would need a new signed attribute. This would complicate the basic format=A0
of a CAdES signature or a XAdES signature. Unless you have strong arguments= on this point,=A0
sequential signatures should be discarded.=A0

=A0

[JORGE] We don=92t think that a new signed attribu= te is needed. We agree that it would make current formats and signature processin= g more complicated. In our opinion, sequential signatures are a conceptual type of signature, with no factual difference respecting a parallel signature. That= is, looking at the bit string level, there is no difference. The decision about whether a signature is (or should be) parallel or sequential stems from the= contextual requirements, and as stipulated in the extended policy.

=A0

7.=A0The tree graph is too complicated. Avoid recursive methods.

=A0

[JORGE] We do not see how a tree of signatures wit= hout a predefined structure in terms of breadth, depth, nodes at each level, etc= . could be defined in the extended policy without using a recursive method. Please = take into account that this draft should permit to instantiate any potential tre= e of signatures according to the specific business needs. Some people may need t= o specify just two parallel signatures while others may need a complex tree o= f, say, three levels of depth and several signatures at each level. Suggestion= s are welcomed.

=A0

The CAdES format is simple: n parallel signatures = each of them can be countersigned any number of times.=A0
There needs to be n parallel signatures (called PS in the draft) and for ea= ch primary signature (PS)=A0
from 1 to n tell how many numbers of countersignatures are needed.

=A0

Note that countersignatures are necessarily made i= n sequence. I do not think the figure is appropriate=A0
when CS1 and CS2 are represented on the same line.

=A0

[JORGE] Mm, we don=92t see your point here. Do you= mean that the figure is confusing respecting CS1 and CS2? If so, what changes sh= ould be made? Please note that we intended to represent two countersignatures generated over the same signature (PS2). The order in which both countersignatures are generated are not (or we did not intended to) represe= nted in the figure.

=A0

The current description for TreesOfSolutions is to= o complicated.

=93identifier=94 and =93signer=94 are not understa= ndable. Please try to adopt a simpler structure.=A0

=A0

[JORGE] Agree. We=92ll try to accommodate the descriptions.

=A0

8.=A0For the timingAndSequence the draft states: =93The= time frame during which a signature must be generated=94.=A0
SigningPeriod is defined as:

=A0

SigningPeriod ::=3D SEQUENCE {

=A0=A0=A0=A0=A0=A0=A0=A0notBefore=A0=A0=A0=A0=A0= =A0=A0GeneralizedTime,

=A0=A0=A0=A0=A0=A0=A0=A0notAfter=A0=A0=A0=A0=A0=A0= =A0=A0GeneralizedTime OPTIONAL }=

=A0

This does not make sense: it is impossible to use = an absolute time.

=A0

[JORGE] You are right Denis. Defining an absolute = time would imply having a priori the knowledge about when the signatures are goi= ng to be generated. This is a limitation we found out after publishing our wor= k. Assuming that this constraint may be interesting in certain scenarios, we came up wi= th a solution that consists of dynamically instantiating the extended policy bef= ore the transaction is going to be carried out. This solution does not have an impact on the policy definition. However, it has important drawbacks in ter= ms of performance. As we would like to include this =93functionality=94 in the extended policy, we would welcome any proposal in this direction.

It is only possible to say, e.g. that the second signature *should* be done within x hours=A0
after the first one and that the first countersignature *should* be done wi= thin y hours.=A0
It is only an indication of the speed of the workflow, no more. Note that *shall* is not used.

=A0

This is more or less the idea behind relativeTimingAndSequence. It is however debatable whether=A0
this level of complexity is really needed. I would suppress it for making t= he structure simpler.

=A0

[JORGE] We strongly believe that the benefits are worth the added complexity.=A0In our opinion, reducing the complexity of th= e structure would lead to a dangerously limited policy.

=A0

9.=A0The concept of signing role as defined in section = 3.5 is inappropriate. This should be replaced=A0
by the notions of claimed role and/or certified role where the identity of = the signer is not important,=A0
but its functional role is fundamental.=A0

=A0

[JORGE] We borrowed the definition from ETSI TR 10= 2 045 v1.1.1 (section 9.4.1), though we also agree that this section does not provide much information to the document. We will delete this section.

=A0

10.=A0Section 5 should be placed before the ASN.1 description of the ext-SP.=A0

=A0

[JORGE] Agree.

=A0

11.=A0Another section should come after dedicated to =93= Integration in XAdES formats=94.=A0

=A0

[JORGE] Agree, though we are interested to know if= it is common to make references to XML-based issues in RFCs, which are usually purely ASN.1 based.

=A0

12.=A0A minor editing: on page 5, the text states:

=A0

=93The Signer is the entity that creates one or mo= re electronic signatures represented=A0
in the ext-SP content. The signer MUST digitally sign over a signature poli= cy identifier and=A0
an extended signature policy identifier.=94

=A0

The sentences should be reworded as follows:

=A0

=93A Signer is an entity that creates one or more electronic signatures represented in the ext-SP content.=A0=A0
Every signer MUST digitally sign using signature policy identifier and an extended signature policy identifier.=94=A0

=A0

[JORGE] OK.

=A0

13.=A0One typo: on page 4: Frenquently

=A0

[JORGE] OK.

Denis

=A0

PS. I copy this mail to the ETSI TC ESI list.


2011/1/20 Denis Pinkas <denis.pinkas@bull.= net>

Comments on=20 draft-hernandez-ardieta-smime-eesp-00

1. The topic of the document is inte= resting.=20 However, the overall ASN.1 syntax
that is proposed is too complicated. = It=20 should be simplified.=A0

=A0

2. On page 6, the text=20 states:

=A0

=93This document defines=20 but does not mandate the form of the ext-SP Specification=94.

The p= oint is=20 well taken, however the structure of the document should be changed
to= =20 follow this statement: the document should first describe the new signed=20 attributes
able to identify the extended signature policy and have a se= cond=20 part which
describes the ASN.1 format.

=A0

It would be nice to=20 support both CAdES and XAdES signatures, so two new signed attributes
w= ould=20 need to be defined: one for XAdES and another one for=20 CAdES.

=A0

The XAdES format has=20 currently limitations: a XAdES signature contains one and only one
sign= ature=20 that can be countersigned. A CAdES signature is more flexible: it may conta= in=20
parallel signatures; where each of them can be=20 countersigned.

=A0

There is some work=20 being done in ESTI TC ESI to allow supporting XAdES parallel=20 signatures.= =A0

=A0

3. Since XAdES support IODs as URNs and OI= Ds as=20 URIs, the syntax being developed should be able
to accommodate both. Ch= ange=20 ExtSignPolicyId accordingly.=A0

=A0

4. On page 7, the syntax=20 includes:

=A0

=A0 extSignPolicyProtection=20 ExtSignPolicyProtection OPTIONAL

=A0

I do not believe that=20 this field is needed. It is unnecessary to sign such structures.
If you= =20 really would like it to be signed, a simple cryptographic checksum would be= =20
insufficient, since you don=92t know which key or certificate to use to= verify=20 it.
A CAdES signature would be fine but too complicated (and not necess= ary).=20
Delete extSignPolicyProtection.=A0

=A0

5. The signingPeriod is mandatory. For mor= e=20 flexibility, it would be better to make it OPTIONAL.=A0

=A0

6. The major part is contained in section = 3.3.1.=20 Three types of signatures are identified.
ETSI TC ESI currently only=20 considers two types: parallel and embedded.

=A0

I wonder whether=20 sequential signatures make sense. How such signatures would look like,
= when=20 you look at the bit string level ?

=A0

I would guess that you=20 would need a new signed attribute. This would complicate the basic format <= br>of=20 a CAdES signature or a XAdES signature. Unless you have strong arguments on= this=20 point,
sequential signatures should be discarded.=A0

=A0

7. The tree graph is too complicated. Avoi= d=20 recursive methods.

=A0

The CAdES format is=20 simple: n parallel signatures each of them can be countersigned any number = of=20 times.
There needs to be n parallel signatures (called PS in the draft)= and=20 for each primary signature (PS)
from 1 to n tell how many numbers of=20 countersignatures are needed.

=A0

Note that=20 countersignatures are necessarily made in sequence. I do not think the figu= re is=20 appropriate
when CS1 and CS2 are represented on the same=20 line.

=A0

The current=20 description for TreesOfSolutions is too=20 complicated.

=93identifier=94 and=20 =93signer=94 are not understandable. Please try to adopt a simpler=20 structure.=A0=

=A0

8. For the timingAndSequence the draft sta= tes:=20 =93The time frame during which a signature must be generated=94.
Signin= gPeriod=20 is defined as:

=A0

SigningPeriod ::=3D=20 SEQUENCE {

=A0=A0=A0=A0=A0=A0=A0=20 notBefore=A0=A0=A0=A0=A0=A0=20 GeneralizedTime,

=A0=A0=A0=A0=A0=A0=A0=20 notAfter=A0=A0=A0=A0=A0=A0=A0=20 GeneralizedTime OPTIONAL }

=A0

This does not make=20 sense: it is impossible to use an absolute=20 time.

It is only possible to=20 say, e.g. that the second signature *should* be done within x hours
aft= er=20 the first one and that the first countersignature *should* be done within y= =20 hours.
It is only an indication of the speed of the workflow, no more. = Note=20 that *shall* is not used.

=A0

This is more or less=20 the idea behind relativeTimingAndSequence. It is however debatable whether= =20
this level of complexity is really needed. I would suppress it for maki= ng=20 the structure simpler.=A0

=A0

9. The concept of signing role as defined = in=20 section 3.5 is inappropriate. This should be replaced
by the notions of= =20 claimed role and/or certified role where the identity of the signer is not= =20 important,
but its functional role is fundamental.=A0

=A0

10. Section 5 should be placed before the = ASN.1=20 description of the ext-SP.=A0

=A0

11. Another section should come after dedi= cated to=20 =93Integration in XAdES formats=94.=A0

=A0

12. A minor editing: on page 5, the text s= tates:=20

=A0

=93The Signer is the=20 entity that creates one or more electronic signatures represented
in th= e=20 ext-SP content. The signer MUST digitally sign over a signature policy=20 identifier and
an extended signature policy=20 identifier.=94

=A0

The sentences should=20 be reworded as follows:

=A0

=93A Signer=20 is an entity that creates one or more electronic signatures represented in = the=20 ext-SP content.=A0
Every signer=20 MUST digitally sign using signature policy identifier and an extended signature policy=20 identifier.=94=A0

=A0

13. One typo: on page 4:=20 Frenquently

Deni= s

=A0

PS. I=20 copy this mail to the ETSI TC ESI list.

=A0

=A0
---------=20
De=20 : smime-bounces
=C0=20 : smime
Date=20 : 2011-01-06, 20:04:34
Sujet=20 : [smime] Fwd: I-D Action:draft-hernandez-ardieta-smime-eesp-00.txt

Pi=E8ce(s) Jointe(s) au message original :
=A0=A0(1).=A0draft-hernandez-ardieta-smime-eesp-00.txt
=A0=A0(2).=A0Attached Message Part

Some on this mailing list might fi= nd this of interest. It's headed for=20
experimental.

The authors have asked for=20 comments.

spt

-------- Original Message --------
Subject= : I-D=20 Action:draft-hernandez-ardieta-smime-eesp-00.txt
Date: Thu, 23 Dec 201= 0=20 10:00:02 -0800
From: Internet-Drafts@ietf.org
Reply-To:=20 internet-d= rafts@ietf.org
To:=20 i-d-announce@= ietf.org

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

=A0=A0Title : Extended Electronic Signature=20 Policies
=A0=A0Author(s) : J.=20 Hernandez-Ardieta
=A0=A0Filename :=20 draft-hernandez-ardieta-smime-eesp-00.txt
=A0=A0Pages :=20 21
=A0=A0Date : 2010-12-23

This document defines extended=20 electronic signature policies (ext-SP)
that extend the boundaries of t= he=20 electronic signature policy defined in
[RFC3125] in a manner that the= =20 relationships and dependences among
multiple electronic signatures=20 generated within the scope of the same
electronic transaction can be= =20 established. A given legal/contractual
context may recognize a particu= lar=20 ext-SP as meeting its requirements.

An ext-SP has a globally uniqu= e=20 reference, which is bound to an
electronic signature by the signer as = part=20 of the signature calculation.

The ext-SP can be defined in human= =20 readable form so that it can be
assessed to meet the requirements of t= he=20 legal and contractual context
in which it is being applied.

To = allow=20 for the automatic processing, the ext-SP specifies, using a
computer= =20 processable form, the timing and sequence dependencies of the
set of= =20 signatures that must be generated to make the transaction
effective al= ong=20 with the set of attributes and rules that each signature
must comply w= ith.=20 In the current document the format of the ext-SP is
defined using=20 ASN.1.

The content of this document is based on the requirements a= nd=20 needs
established in ETSI TR 102 045 V1.1.1 (2003-03) Copyright=20 (C).
Individual copies of this ETSI deliverable can be downloaded=20 from
http://www.ets= i.org.

Discussion

This=20 draft is being discussed on the 'ietf-smime' mailing list. To
= subscribe,=20 send a message to smime-request@ietf.org with=20 the
single word subscribe in the body of the message. There is a Web= =20 site
for the mailing list at https://www.ietf.org/mailman/listinfo/smi= me.

A=20 URL for this Internet-Draft is:
http:= //www.ietf.org/internet-drafts/draft-hernandez-ardieta-smime-eesp-00.txt

Internet-Drafts=20 are also available by anonymous FTP=20 at:
= ftp://ftp.ietf.org/internet-drafts/

Below is the data which will= =20 enable a MIME compliant mail reader
implementation to automatically=20 retrieve the ASCII version of=20 the
Internet-Draft.



_____________________ n= ext part=20 ______________________


_________________________= ______________________
smime=20 mailing list
smim= e@ietf.org
https://www.ietf.org/mailman/listi= nfo/smime


--0016363101e50ec0a7049abd9ea6-- From wwwrun@rfc-editor.org Fri Jan 28 14:53:06 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FDBA3A6954 for ; Fri, 28 Jan 2011 14:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.308 X-Spam-Level: X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6beOM1yiq8x for ; Fri, 28 Jan 2011 14:53:05 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 3943C3A68B7 for ; Fri, 28 Jan 2011 14:53:05 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B267FE072D; Fri, 28 Jan 2011 14:56:12 -0800 (PST) To: turners@ieca.com, turners@ieca.com, tim.polk@nist.gov, paul.hoffman@vpnc.org, blaker@gmail.com From: RFC Errata System Message-Id: <20110128225612.B267FE072D@rfc-editor.org> Date: Fri, 28 Jan 2011 14:56:12 -0800 (PST) Cc: rfc-editor@rfc-editor.org, smime@ietf.org Subject: [smime] [Editorial Errata Reported] RFC5754 (2693) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 22:53:06 -0000 The following errata report has been submitted for RFC5754, "Using SHA2 Algorithms with Cryptographic Message Syntax". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5754&eid=2693 -------------------------------------- Type: Editorial Reported by: Sean Turner Section: 3.3 Original Text ------------- ... the object identifier ecdsa-with-SHA1* (where * is 224, 256, 384, or 512) with absent parameters. Corrected Text -------------- ... the object identifier ecdsa-with-SHA* (where * is 224, 256, 384, or 512) with absent parameters. Notes ----- r/ecdsa-withSHA1*/ecdsa-with-SHA* The "1" shouldn't be there the algorithm names are ecdsa-with-SHA224, etc. not ecdsa-with-SHA1224. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5754 (draft-ietf-smime-sha2-11) -------------------------------------- Title : Using SHA2 Algorithms with Cryptographic Message Syntax Publication Date : January 2010 Author(s) : S. Turner Category : PROPOSED STANDARD Source : S/MIME Mail Security Area : Security Stream : IETF Verifying Party : IESG From paul.hoffman@vpnc.org Fri Jan 28 15:27:30 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BC8A3A6954 for ; Fri, 28 Jan 2011 15:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.747 X-Spam-Level: X-Spam-Status: No, score=-101.747 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1wyVc30P+G1 for ; Fri, 28 Jan 2011 15:27:29 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 5486D3A68A8 for ; Fri, 28 Jan 2011 15:27:29 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0SNUWlA038100 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 28 Jan 2011 16:30:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D435198.8070007@vpnc.org> Date: Fri, 28 Jan 2011 15:30:32 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: RFC Errata System References: <20110128225612.B267FE072D@rfc-editor.org> In-Reply-To: <20110128225612.B267FE072D@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: smime@ietf.org Subject: Re: [smime] [Editorial Errata Reported] RFC5754 (2693) X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 23:27:30 -0000 On 1/28/11 2:56 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC5754, > "Using SHA2 Algorithms with Cryptographic Message Syntax". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5754&eid=2693 > > -------------------------------------- > Type: Editorial > Reported by: Sean Turner > > Section: 3.3 > > Original Text > ------------- > ... the object identifier ecdsa-with-SHA1* (where * is 224, 256, 384, or 512) with absent parameters. > > Corrected Text > -------------- > ... the object identifier ecdsa-with-SHA* (where * is 224, 256, 384, or 512) with absent parameters. > > Notes > ----- > r/ecdsa-withSHA1*/ecdsa-with-SHA* > The "1" shouldn't be there the algorithm names are ecdsa-with-SHA224, etc. not ecdsa-with-SHA1224. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5754 (draft-ietf-smime-sha2-11) > -------------------------------------- > Title : Using SHA2 Algorithms with Cryptographic Message Syntax > Publication Date : January 2010 > Author(s) : S. Turner > Category : PROPOSED STANDARD > Source : S/MIME Mail Security > Area : Security > Stream : IETF > Verifying Party : IESG > > > Verified. From paul.hoffman@vpnc.org Mon Jan 31 13:26:13 2011 Return-Path: X-Original-To: smime@core3.amsl.com Delivered-To: smime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5276F3A6AF9 for ; Mon, 31 Jan 2011 13:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.756 X-Spam-Level: X-Spam-Status: No, score=-101.756 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3Uc3WTQFwm4 for ; Mon, 31 Jan 2011 13:26:12 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 8BAAE3A6814 for ; Mon, 31 Jan 2011 13:26:12 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0VLTR79082434 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 31 Jan 2011 14:29:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D4729B6.30107@vpnc.org> Date: Mon, 31 Jan 2011 13:29:26 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: smime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [smime] Fwd: Last Call: (Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 21:26:13 -0000 Of interest to this list. -------- Original Message -------- Subject: Last Call: (Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax Date: Mon, 31 Jan 2011 11:36:59 -0800 From: The IESG , The IESG Reply-To: ietf@ietf.org To: IETF-Announce , IETF-Announce ) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-herzog-static-ecdh/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-herzog-static-ecdh/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce