From turners@ieca.com Wed Sep 2 09:11:13 2009 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 666B73A6CB4 for ; Wed, 2 Sep 2009 09:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 H7UgY39gOYTK for ; Wed, 2 Sep 2009 09:11:12 -0700 (PDT) Received: from smtp106.biz.mail.re2.yahoo.com (smtp106.biz.mail.re2.yahoo.com [206.190.52.175]) by core3.amsl.com (Postfix) with SMTP id 52ED13A6C0A for ; Wed, 2 Sep 2009 09:11:12 -0700 (PDT) Received: (qmail 49572 invoked from network); 2 Sep 2009 16:10:37 -0000 Received: from unknown (HELO thunderfish.local) (turners@129.6.252.20 with plain) by smtp106.biz.mail.re2.yahoo.com with SMTP; 2 Sep 2009 16:10:37 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: wRmYtpwVM1lJPizTQPanpxaOiTGyUGZp.ptk0.BGw83jOrGQXk3bynMxUArfa8UycRF_IZuOZmGDRuyJ0PZN8aII4ZY0eYfL7fRhRJVwDuHLVxRTaJDW0enao.RI5urJjjg5q8OlNqDxbMD_03RnJS8csAktvmWwuux6jkPB9k3NvH9JP3XAQu6iH0Eb6ZkTdXBcQTY8oST3ZvC0txjXlq6DkgIOkMkRpdw_Dw11Vasna5pbcgqhul.WR9j56muh2ebhBISeGEBODBqQBQbf.edUWpNA9PI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9E98FC.5040703@ieca.com> Date: Wed, 02 Sep 2009 12:10:36 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: smime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [smime] smime meeting at IETF76? 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, 02 Sep 2009 16:11:13 -0000 My assumption is that there is no need to meet in Hiroshima, but I put it to the WG: are there topics and sufficient interest in these topics to justify a meeting in Hiroshima? spt From web-usrn@ISI.EDU Thu Sep 17 02:25:59 2009 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 652F528C17D for ; Thu, 17 Sep 2009 02:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.879 X-Spam-Level: X-Spam-Status: No, score=-16.879 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 lBgbhkHu1yFR for ; Thu, 17 Sep 2009 02:25:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 5180528C1BF for ; Thu, 17 Sep 2009 02:25:58 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8H9Pq7K009789; Thu, 17 Sep 2009 02:25:53 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n8H9PpXx009782; Thu, 17 Sep 2009 02:25:51 -0700 (PDT) Date: Thu, 17 Sep 2009 02:25:51 -0700 (PDT) Message-Id: <200909170925.n8H9PpXx009782@boreas.isi.edu> To: lse@cryptopro.ru, chudov@cryptopro.ru, tim.polk@nist.gov, pasi.eronen@nokia.com, turners@ieca.com, blaker@gmail.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: ah@TR-Sys.de, rfc-editor@rfc-editor.org, smime@ietf.org Subject: [smime] [Technical Errata Reported] RFC4490 (1884) 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, 17 Sep 2009 09:25:59 -0000 The following errata report has been submitted for RFC4490, "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4490&eid=1884 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: 2.1, pg. 4 Original Text ------------- When the Message Digest authenticated attribute is present, the | DigestedData digest contains a 32-byte digest in little-endian representation: Corrected Text -------------- When the Message Digest authenticated attribute is present, the | DigestedData digest contains a 32-byte digest in big-endian representation: Notes ----- Rationale: - Contradiction to other parts of the document, which use "big-endian" == 'network byte order' as established in the Internet architecture. - Please also note that the ASN.1 BER/DER encoding is based on the 'natural' byte order for left-to-right scripts -- otherwise the intrinsically variable-length representation used would be very complicated to deal with in processing. - Intrduction of varying endian-ness is a likely source of implementation issues and, consequentially, interoperability problems. 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. -------------------------------------- RFC4490 (draft-ietf-smime-gost-07) -------------------------------------- Title : Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS) Publication Date : May 2006 Author(s) : S. Leontiev, Ed., G. Chudov, Ed. Category : PROPOSED STANDARD Source : S/MIME Mail Security Area : Security Stream : IETF Verifying Party : IESG From A.Hoenes@tr-sys.de Thu Sep 17 03:40:40 2009 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 37BC728C1E2; Thu, 17 Sep 2009 03:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.537 X-Spam-Level: X-Spam-Status: No, score=0.537 tagged_above=-999 required=5 tests=[AWL=3.083, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 vxiKH0U8A4og; Thu, 17 Sep 2009 03:40:39 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 026173A6936; Thu, 17 Sep 2009 03:40:38 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8HAfLP4068942; Thu, 17 Sep 2009 03:41:28 -0700 (MST) (envelope-from A.Hoenes@tr-sys.de) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA072904045; Thu, 17 Sep 2009 12:40:45 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA15380; Thu, 17 Sep 2009 12:40:40 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200909171040.MAA15380@TR-Sys.de> To: ietf-pkix@imc.org, ietf-smime@imc.org Date: Thu, 17 Sep 2009 12:40:40 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 17 Sep 2009 04:48:41 -0700 Subject: [smime] draft-dolmatov-dnsext-dnssec-gost-01 technical & editorial issues (fwd) 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, 17 Sep 2009 10:40:40 -0000 Folks, I apologize for cross-posting, but the following excerpt of my post to namedroppers might be of interest for PKIX and SMIME, the originators of RFCs 4490 and 4491, for which I have filed Errata -- in part to solicit discussion. The full message is archived at: http://ops.IETF.ORG/lists/namedroppers/namedroppers.2009/msg02525.html ----- Forwarded message ----- > From: Alfred HÎnes > To: dol@cryptocom.ru, ran@cryptocom.ru, igus@cryptocom.ru, > namedroppers@ops.ietf.org > Message-Id: <200909171025.MAA15356@TR-Sys.de> > Subject: draft-dolmatov-dnsext-dnssec-gost-01 technical & editorial issues > Date: Thu, 17 Sep 2009 12:25:12 +0200 (MESZ) > > Folks, > > I have reviewed draft-dolmatov-dnsext-dnssec-gost-01 and found > a number of issues of varying degree of severeness. > Items (1)..(3) below are the hard stuff, the nits are in (4). > > > (1) > > First of all, I'm confused by, and strongly oppose to, the > introduction of little-endian encoding for the on-the-wire > encoding of specific elements of this proposal, as requested > by the last paragraph of Section 2 of this draft. > This is incompatible with the Internet architecture and also > with the ASN.1 framework quoted by the draft, which makes > consistent use of "big-endian" (network) byte order. > > Unfortunately, the quoted related RFCs 4490 and 4491 > (cf. Section 4 of the draft) already have created bad precedents. > I have filed Errata Notes for these RFCs (EIDs: 1884 and 1885). > As noted there, mixed endianness within one protocol, or even > within a single specification for an extension to a protocol > is a very likely source of confusion, implementation errors, > and, consequentially, interoperability problems. > This practice should be avoided consistently. > > > (2) > ... [snip] ----- End of forwarded message ----- Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From rfc-editor@rfc-editor.org Thu Sep 17 16:09:56 2009 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 6F3B628C192; Thu, 17 Sep 2009 16:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.593 X-Spam-Level: X-Spam-Status: No, score=-16.593 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 BhIaDaQzeVsK; Thu, 17 Sep 2009 16:09:55 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id B58A828C193; Thu, 17 Sep 2009 16:09:21 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id B16AF3256FC; Thu, 17 Sep 2009 16:09:43 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090917230943.B16AF3256FC@bosco.isi.edu> Date: Thu, 17 Sep 2009 16:09:43 -0700 (PDT) Cc: smime@ietf.org, rfc-editor@rfc-editor.org Subject: [smime] RFC 5652 on Cryptographic Message Syntax (CMS) 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, 17 Sep 2009 23:09:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5652 Title: Cryptographic Message Syntax (CMS) Author: R. Housley Status: Standards Track Date: September 2009 Mailbox: housley@vigilsec.com Pages: 56 Characters: 126813 Obsoletes: RFC3852 I-D Tag: draft-ietf-smime-rfc3852bis-00.txt URL: http://www.rfc-editor.org/rfc/rfc5652.txt This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS TRACK] This document is a product of the S/MIME Mail Security Working Group of the IETF. This is now a Draft Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From gchudov@gmail.com Wed Sep 23 07:55:31 2009 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 10F963A6908 for ; Wed, 23 Sep 2009 07:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 WODDdce9TpYN for ; Wed, 23 Sep 2009 07:55:29 -0700 (PDT) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by core3.amsl.com (Postfix) with ESMTP id 07AF73A68B1 for ; Wed, 23 Sep 2009 07:55:28 -0700 (PDT) Received: by bwz6 with SMTP id 6so598915bwz.37 for ; Wed, 23 Sep 2009 07:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jC3XiJukwx4jvD+kjwG7p9r8RW0NOLLifezUBobX62I=; b=itCEWDZ6ANwIv6dxgUdf75UktiLrV0qVaJIjgVoS5TVFQSjy0PRNVbKUXZYyPlYWGe JSzSdZEm3FPNysbAPgE9aURbnMsT8QDNdZqd27aXdqpxUvlixyXsKi/Lwrki7kCED3Yc uvzK9t+XOOiS2KHopnPEdoCNrwvhsadpSNoGE= 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:content-transfer-encoding; b=Kwgsq8w3Yl/nUpacYP5v8xzydBbH6v2Q0B2GIsTsE2aA9Op0MCp02j/AoKLKVWaS1f 9R9bv17kDGfkTKxRLHg0ZCxG7qrGEZwtvOMSB5N5flv6H705CJMXGh7x+wOl0b3y1zQm +KxmbUnbEZC5QHXnDucKwZCiAROObI7+EDia8= MIME-Version: 1.0 Received: by 10.204.155.65 with SMTP id r1mr1937055bkw.143.1253717793510; Wed, 23 Sep 2009 07:56:33 -0700 (PDT) In-Reply-To: <200909170925.n8H9PpXx009782@boreas.isi.edu> References: <200909170925.n8H9PpXx009782@boreas.isi.edu> Date: Wed, 23 Sep 2009 18:56:33 +0400 Message-ID: <4717c1330909230756j5b7d2391y9285006a1ae43947@mail.gmail.com> From: Gregory Chudov To: RFC Errata System Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ah@tr-sys.de, smime@ietf.org, pasi.eronen@nokia.com Subject: Re: [smime] [Technical Errata Reported] RFC4490 (1884) 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, 23 Sep 2009 14:55:31 -0000 Greetings. 1) The Message Digest within the context of CMS is treated not as an integer, but as a sequence of bytes. Ideally, we shouldn't have mentioned any byte order here at all. 2) Unfortunately, GOST R 34.11-94 doesn't specify the byte order for the resulting digest, so we did have to specify it here. 3) The samples from GOST R 34.11-94 (http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost341194-02#section-= 7.3.1) use little-endian byte order for the source messages, so little-endian representation was a de-facto standard for applications using GOST R 34.11-94 digest, long before RFC4490 was published. 4) Reversing the byte order for Message Digest would require at least a new digest OID, otherwise it would break numerous existing implementations, and would be inconsistent with the samples provided in RFC4490. 5) As an alternative errata, the following sample can be added, clarifying the byte order for Message Digest, using example from GOST R 34.11-94: Message from [GOSTR341194] Appendix 3.1 ([draft-dolmatov-cryptocom-gost341194-02], section 7.3.1): M =3D "This is message, length=3D32 bytes" MessageDigest: 0 32: OCTET STRING : b1 c4 66 d3 75 19 b8 2e 83 19 81 9f f3 25 95 e0 : 47 a2 8c b6 f8 3e ff 1c 69 16 a8 15 a6 37 ff fa Regards, Gregory Chudov & Serguei Leontiev 2009/9/17 RFC Errata System : > > The following errata report has been submitted for RFC4490, > "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34= .10-2001 Algorithms with Cryptographic Message Syntax (CMS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4490&eid=3D1884 > > -------------------------------------- > Type: Technical > Reported by: Alfred Hoenes > > Section: 2.1, pg. 4 > > Original Text > ------------- > =A0 When the Message Digest authenticated attribute is present, the > | =A0DigestedData digest contains a 32-byte digest in little-endian > =A0 representation: > > > Corrected Text > -------------- > =A0 When the Message Digest authenticated attribute is present, the > | =A0DigestedData digest contains a 32-byte digest in big-endian > =A0 representation: > > > Notes > ----- > Rationale: > - Contradiction to other parts of the document, > =A0which use "big-endian" =3D=3D 'network byte order' > =A0as established in the Internet architecture. > - Please also note that the ASN.1 BER/DER encoding is > =A0based on the 'natural' byte order for left-to-right > =A0scripts -- otherwise the intrinsically variable-length > =A0representation used would be very complicated to deal > =A0with in processing. > - Intrduction of varying endian-ness is a likely source > =A0of implementation issues and, consequentially, > =A0interoperability problems. > > 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. > > -------------------------------------- > RFC4490 (draft-ietf-smime-gost-07) > -------------------------------------- > Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : Using the GOST 28147-89, GOST R 34.11= -94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic M= essage Syntax (CMS) > Publication Date =A0 =A0: May 2006 > Author(s) =A0 =A0 =A0 =A0 =A0 : S. Leontiev, Ed., G. Chudov, Ed. > Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD > Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: S/MIME Mail Security > Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Security > Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF > Verifying Party =A0 =A0 : IESG > From davidreis@yahoo.com Wed Sep 23 20:36:04 2009 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 E51233A69CD for ; Wed, 23 Sep 2009 20:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.301 X-Spam-Level: ** X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 WApaamndH9sP for ; Wed, 23 Sep 2009 20:36:04 -0700 (PDT) Received: from web30902.mail.mud.yahoo.com (web30902.mail.mud.yahoo.com [68.142.200.155]) by core3.amsl.com (Postfix) with SMTP id 0E4283A659B for ; Wed, 23 Sep 2009 20:36:04 -0700 (PDT) Received: (qmail 10357 invoked by uid 60001); 24 Sep 2009 03:37:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1253763427; bh=+p/wenO81ya3dund2l0tGFw4BK5ZHFsadIBp3PKAaZg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=rGX+dVD9ZWs/9ASibZwP3ScJTn0uGKqz4UT73k5JZslZA4yhvIoD6OA4ALLAdSHvG1cP0UUY6gsiX430ULsOshjfVnikUsWQXm68vsJ60v4ogd4FWR5H2t7HZqo0ucoTfRKo8gV2ZdQ9MwBJZ7pAbVdSE1NOSl8ddg+XtxFbGY0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=Ol4iGiWbKTq7FhzufFRTZhDKORh2/8bexPK46U43gZp3RW1zWVOU2JrYbNtSm9oP1BojiEvke9JqBgC5sK/6/oAVatqko2VBemoHjB06gK/VMpenojESGiyicSNjEtvW6ZVwWWir+qmL9ZOqTX3RDjtSbnWhqMwFM2iO1JFPkGw=; Message-ID: <298157.9600.qm@web30902.mail.mud.yahoo.com> X-YMail-OSG: yhcEMgkVM1kcCzpr6jXUPRVeBne3BrhKFrJ7zHY8wAfIx12iIOISxk2Sdf5Z.gTEIrnFuiW_.WIVNG3taCh3248cWf.BaxxO4OpImsM7pRqJ26AMFPVBntnrR5XpiYDQcW6nEhhiMSXp69FFSyUkW3X2G1x3kdri6NEiQj.2m5fEnH2RK6BcD4SNissvmFiZ8q_YH3bFasBW653EGkYS1.g0LzWKovZ9tcKcbJoKusgpjA9WCrQrVo1fT8fn8.KaE5x96Srr_JW0.lrwXWVxTDA8J9Pef_51XV6a.fPcxM7aSgj0V1rS1n.htVsXoPIztz00G8vdW1JbvM.uglme.o5O.IvWvN1Zn1G3yQ-- Received: from [189.102.237.46] by web30902.mail.mud.yahoo.com via HTTP; Wed, 23 Sep 2009 20:37:07 PDT X-Mailer: YahooMailRC/157.18 YahooMailWebService/0.7.347.2 Date: Wed, 23 Sep 2009 20:37:07 -0700 (PDT) From: David Reis Jr To: smime@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-389306901-1253763427=:9600" Subject: [smime] CommitmentRules Question 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, 24 Sep 2009 03:36:05 -0000 --0-389306901-1253763427=:9600 Content-Type: text/plain; charset=us-ascii Hi, I have some questions about the RFC 3125 and I couldn't find a place to post them. Is there a list for developers? If someone in the list could help me with them, I would appreciate. Thanks in advance. * If I have a signature without "Commitment Type Indication" attribute, should I apply a rule from CommitmentRules that has "Empty" as SelectedCommitmentType or should I completely ignore the CommitmentRules? * In the Algorithm Constraint Set Field, it is said that it should be applied to the algorithms used during the process. If I have a policywith Algorithm Constraints Set which field should I apply to the signature and digest algorithm? The Signer Algorithm Constraints? * Must trustpoints be selfsigned certificates or can they be CA certificates? Regards, David Reis Jr --0-389306901-1253763427=:9600 Content-Type: text/html; charset=us-ascii
Hi,

I have some questions about the RFC 3125 and I couldn't find a place to post them. Is there a list for developers?

If someone in the list could help me with them, I would appreciate. Thanks in advance.

* If I have a signature without "Commitment Type Indication" attribute, should I apply a rule from
  CommitmentRules that has "Empty" as SelectedCommitmentType or should I completely ignore the CommitmentRules?

* In the Algorithm Constraint Set Field, it is said that it should be applied to the algorithms
  used during the process. If I have a policy with Algorithm Constraints Set which field should I apply to the signature and digest
  algorithm? The Signer Algorithm Constraints?

* Must trustpoints be selfsigned certificates or can they be CA certificates?



Regards,

David Reis Jr

--0-389306901-1253763427=:9600-- From tmiller@mitre.org Tue Sep 29 07:02:54 2009 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 66FD13A689E for ; Tue, 29 Sep 2009 07:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 jTARPe54WseS for ; Tue, 29 Sep 2009 07:02:53 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 817D83A684B for ; Tue, 29 Sep 2009 07:02:53 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8TDg3vv098517 for ; Tue, 29 Sep 2009 06:42:13 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n8TDg19E002455 for ; Tue, 29 Sep 2009 09:42:02 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n8TDg1Tu002451 for ; Tue, 29 Sep 2009 09:42:01 -0400 Received: from [172.31.3.34] (172.31.3.34) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 29 Sep 2009 09:42:01 -0400 Message-ID: <4AC20EA6.7050007@mitre.org> Date: Tue, 29 Sep 2009 08:41:58 -0500 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "ietf-smime@imc.org" Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030704070502090900040205" Subject: [smime] Enveloping for the sender. 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, 29 Sep 2009 14:02:54 -0000 --------------ms030704070502090900040205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So every S/MIME MUA I'm aware of includes the sender in the enveloped message's RecipientInfos. This makes sense because people generally expect to read the email they send themselves. However, yesterday I had a case where a sender had two certs issued with the same email address subjectAlternativeName under two different PKIs (don't go there). On the system in question he had only one of these key pairs installed; the other was present but only as the cert (no private key). The MUA, for whatever reason, used the incomplete identity in the envelope RecipientInfos and the user was unable to read his sent mail. I'm thinking that an MUA, when enveloping an outgoing message for the sender, should check to make sure the sender has the private key and warn the user if it's not present. While this can be addressed as a bug in the MUA (and I'll be reporting it), I scanned through 3850, 3851, and 5652 and I find no mention of this enveloping for sender behavior anywhere. I was wondering if anyone felt enveloping for sender is common enough to place some minimal requirements on it, maybe in 3851 (I'm not sure it belongs in 5652). -- Tim --------------ms030704070502090900040205 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICtTCC ArECAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wOTA5MjkxMzQxNThaMCMGCSqGSIb3DQEJBDEWBBR8VZsCIBAEjG2Gv3yJtyVsCeU5cTBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwcgYJKwYBBAGCNxAE MWUwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv cml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTB0Bgsq hkiG9w0BCRACCzFloGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0Et MQICHwUwDQYJKoZIhvcNAQEBBQAEgYCEvnMCulEKZZw5J+ZbxijXGkkj1isGbYBIRGWhLdEJ 4kFpCmA2e4VNQYWXZwZligKcCYVkY6sbnR7nwKuD1YRclNTXgpRdlwe+S/KHyPH2UR5nTE0b G1dleGGvfYcakb495RysrpjSfMXSTRMWpMn5zYUvoI6/PqlMVih0kt7tFAAAAAAAAA== --------------ms030704070502090900040205-- From tmiller@mitre.org Wed Sep 30 06:11:39 2009 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 062F63A67B5 for ; Wed, 30 Sep 2009 06:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 3hydI3t4nuwI for ; Wed, 30 Sep 2009 06:11:38 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 7FAD83A659C for ; Wed, 30 Sep 2009 06:11:37 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n8UDCu1c087454 for ; Wed, 30 Sep 2009 06:13:00 -0700 (MST) (envelope-from tmiller@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n8UDCtvX005143 for ; Wed, 30 Sep 2009 09:12:55 -0400 Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id n8UDCsgw005139; Wed, 30 Sep 2009 09:12:54 -0400 Received: from [172.31.1.70] (172.31.1.70) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 30 Sep 2009 09:12:54 -0400 Message-ID: <4AC35952.6070804@mitre.org> Date: Wed, 30 Sep 2009 08:12:50 -0500 From: "Timothy J. Miller" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000006030906010800030603" Cc: "ietf-smime@imc.org" Subject: Re: [smime] Enveloping for the sender. 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, 30 Sep 2009 13:11:39 -0000 --------------ms000006030906010800030603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > Isn't this a rather obscure implementation-specific issue? If you start > trying to enumerate every possible corner case of this kind in the spec, I > suspect you'd get a rather large, and never-quite-finished, document. Even > then, how do you handle the situation where the private key is in a smart card > that's not presently inserted in the machine, or it's CC'd to the sender's > other email address at a location where they have the private key, or ... I can buy that. How about a BCP? Is there a BCP for S/MIME? -- Tim --------------ms000006030906010800030603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKvjCC A2cwggJPoAMCAQICAh8FMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEe MBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3Jh dGlvbiBQcmltYXJ5IENBLTEwHhcNMDgwODIxMTUzMTI5WhcNMTAwMjEyMTUzMTI5WjBaMRIw EAYDVQQKEwltaXRyZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3Rt aWxsZXIxGjAYBgNVBAMTEU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCTxM+z5fDKvmBInGatv0DkVwuOxd69S2M2jho8QkOltYJK/4JUm9uK0UtQZkyI bEjmCpmXLw17iMCgA0SjwuUfJxdF8ntTys8keyMjRdlKSwFnkgZl9tL7o060LBtZQYzI5ajr W9k3N768G/k1bZS5UYiMGHU5+Ygl4IwVhmQv3wIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF 4DAdBgNVHQ4EFgQUSXARqmj5Bl2Lz7RLoUIkuOHl0MkwHwYDVR0jBBgwFoAUh7QPSI1iM0LB LVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL3d3dy5taXRyZS5vcmcvdGVj aC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1UdEQQVMBOBEXRtaWxsZXJAbWl0cmUu b3JnMA0GCSqGSIb3DQEBBQUAA4IBAQAbA1PH/hed/rryO1f0yfTRJnD/vL1rFTduUut/irL7 FSXHGybuPHxydfyGPvJ4qj+T8hs1W0jTa2zQnaPR52tms3hefl76CNVP9vJoVmaM9svFX4DX 6eJh/4SAI81tAuBIK8gxsWd1Va/Bnnh1/wsZLc8w2jkojVqkT2AHPaHS3DBKX7QAWovXVSxY QlqMIH4zvSNSVfpvpIf0MWJWRBPvgerVSbJsA4dz6ziKvXDWySTV9zwSuNjikNqL//nIKwjb r3ZOfSUOxSuhW58an2Ha4TdORvG4dGJEsMzxbpTB+wt/s6tK6roONV4uiDtODBNVAG+XGofe McsS0b7iXdxDMIIDZzCCAk+gAwIBAgICHwUwDQYJKoZIhvcNAQEFBQAwXTESMBAGA1UEChMJ bWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1J VFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTAeFw0wODA4MjExNTMxMjlaFw0xMDAyMTIx NTMxMjlaMFoxEjAQBgNVBAoTCW1pdHJlLm9yZzEPMA0GA1UECxMGcGVvcGxlMRcwFQYKCZIm iZPyLGQBARMHdG1pbGxlcjEaMBgGA1UEAxMRTWlsbGVyIFRpbW90aHkgSi4wgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBAJPEz7Pl8Mq+YEicZq2/QORXC47F3r1LYzaOGjxCQ6W1gkr/ glSb24rRS1BmTIhsSOYKmZcvDXuIwKADRKPC5R8nF0Xye1PKzyR7IyNF2UpLAWeSBmX20vuj TrQsG1lBjMjlqOtb2Tc3vrwb+TVtlLlRiIwYdTn5iCXgjBWGZC/fAgMBAAGjgbcwgbQwDgYD VR0PAQH/BAQDAgXgMB0GA1UdDgQWBBRJcBGqaPkGXYvPtEuhQiS44eXQyTAfBgNVHSMEGDAW gBSHtA9IjWIzQsEtURpIHsKeuwqxrTBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvY2ExX21pdHJlX29yZy5jcmwwHAYDVR0RBBUwE4ERdG1p bGxlckBtaXRyZS5vcmcwDQYJKoZIhvcNAQEFBQADggEBABsDU8f+F53+uvI7V/TJ9NEmcP+8 vWsVN25S63+KsvsVJccbJu48fHJ1/IY+8niqP5PyGzVbSNNrbNCdo9Hna2azeF5+XvoI1U/2 8mhWZoz2y8VfgNfp4mH/hIAjzW0C4EgryDGxZ3VVr8GeeHX/CxktzzDaOSiNWqRPYAc9odLc MEpftABai9dVLFhCWowgfjO9I1JV+m+kh/QxYlZEE++B6tVJsmwDh3PrOIq9cNbJJNX3PBK4 2OKQ2ov/+cgrCNuvdk59JQ7FK6FbnxqfYdrhN05G8bh0YkSwzPFulMH7C3+zq0rqug41Xi6I O04ME1UAb5cah94xyxLRvuJd3EMwggPkMIICzKADAgECAgEFMA0GCSqGSIb3DQEBBQUAMFox EjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UECxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MSQw IgYDVQQDExtNSVRSRSBDb3Jwb3JhdGlvbiBSb290IENBLTEwHhcNMDYwNjAzMTcxMzIyWhcN MTIwNjAzMTcxMzIyWjBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmlj YXRlIEF1dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0x MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyPB7Vl0QgqgQt0u8Q2duRs7eZUPn hlflKPFPMXGG+iqGpImYs6nfbFPsn0q8FqklFsm/UEV2JJQ3c7Srwfrqe9CrCbVFh761OxZI 7fnUWiUasNP2ING19aAfrQ8IoJsAEtGzHeIacS+M5CN4C0yfUC6CpBZTc9ZldjLUatvJr407 K1i+7WnrRsMVKhICfgmiO/XiVR9YeXyzeRqFrLy6YtJCJuJd0QRfwKtKRpek5oU67Izr7ClH DtPJs7UOTjMYBS2fTzztC+wwOTp6+A3ZbEymuQcAZRwmGkjVBe2R8MiX26R02Iigz+903ZAL /6bpvx0DnkrlR2UFr1KBGfBqmQIDAQABo4GxMIGuMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgGGMB0GA1UdDgQWBBSHtA9IjWIzQsEtURpIHsKeuwqxrTAfBgNVHSMEGDAW gBTHcFEA2E3+5AHUaJbFPZ+al/50LzBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vd3d3Lm1p dHJlLm9yZy90ZWNoL21paS9wa2kvcm9vdGNhMV9taXRyZV9vcmcuY3JsMA0GCSqGSIb3DQEB BQUAA4IBAQBNbm7rrins3SICPbteX9qSN1+RJClqix/pw3IAe7u60LK0V9jVZ9E2a+c0MZiS ojdcwU5rXxI2OI2wwIf6wVBo76jIOc+IiQRlC+V8YatGmoibqP/8WDPzlud/WQAzkjrU2nuh 8KdyJG+n1kH/6772Lbra2CIk8mu8FypeaB5P2uIJzdE+PGo82ZiyU680ukiJ9yF6UmEXuciB 77tGQBRxMl6ePzIrArQnf48SmBhFD5XYLraueOiG7E+AzD99ig1M6WHcxWXtp3DIrVqE/DZr 146NJaCWqg9NoE14cmpEllnpWLtLnn5UBYJ+QCozmbe1SJXOOynZ0VxMnGdh7NqgMYICtTCC ArECAQEwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1 dGhvcml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTAJ BgUrDgMCGgUAoIIBqDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0wOTA5MzAxMzEyNTBaMCMGCSqGSIb3DQEJBDEWBBRLRuYVbOrlm4zvfzR32HvqHByfcTBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwcgYJKwYBBAGCNxAE MWUwYzBdMRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv cml0eTEnMCUGA1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIfBTB0Bgsq hkiG9w0BCRACCzFloGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkxJzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0Et MQICHwUwDQYJKoZIhvcNAQEBBQAEgYA8oLrzuA/ED7XDosld4u92mlFkvtMG0gJmiotA4mZ1 RRQa7YoPeIubCuxwK+49BtjghfNFXHB2E//c3MTWfy57ZjD9wZ0VnZt/CbkCNeRhI+20T5/R rq3owp3dbhj7ebAe3sG4Liyp+0g0ve02mwIAkG+2iGfqBUNfeH29lWFTGQAAAAAAAA== --------------ms000006030906010800030603--