From owner-ietf-smime@mail.imc.org Sat Feb 1 14:04:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14566 for ; Sat, 1 Feb 2003 14:04:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h11IkEW10734 for ietf-smime-bks; Sat, 1 Feb 2003 10:46:14 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h11IkDo10727 for ; Sat, 1 Feb 2003 10:46:13 -0800 (PST) Received: (qmail 16284 invoked from network); 1 Feb 2003 18:46:11 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.162.139) by woodstock.binhost.com with SMTP; 1 Feb 2003 18:46:11 -0000 Message-Id: <5.2.0.9.2.20030201134403.022f1ad0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 01 Feb 2003 13:46:11 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: S/MIME WG Agenda for 56th IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The 56th IETF will be held in San Francisco, CA on 16-21 March 2003. I have asked for a one-hour meeting slot for the S/MIME WG. Please send me agenda topics. Russ From owner-ietf-smime@mail.imc.org Tue Feb 4 10:32:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25371 for ; Tue, 4 Feb 2003 10:32:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14FFLb12761 for ietf-smime-bks; Tue, 4 Feb 2003 07:15:21 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h14FFKd12757 for ; Tue, 4 Feb 2003 07:15:20 -0800 (PST) Received: (qmail 27578 invoked from network); 4 Feb 2003 15:15:07 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.39.35) by woodstock.binhost.com with SMTP; 4 Feb 2003 15:15:07 -0000 Message-Id: <5.2.0.9.2.20030204101126.02d9ccb8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 04 Feb 2003 10:15:09 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: WG Last Call: draft-ietf-smime-rfc2633bis-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear S/MIME WG: This message announces Working Group Last Call for the update to the MSG specification. Title : S/MIME Version 3.1 Message Specification Author(s) : Blake Ramsdell Filename : draft-ietf-smime-rfc2633bis-03.txt Date : January 16, 2003 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2633bis-03.txt The intent is to publish the pdate to the MSG specification as a Standards Track RFC, superseding RFC 2633. Please review this draft and post any comments to the ietf-smime@imc.org mail list by Monday, 17 February 2003. Unless traffic on the mail list indicates otherwise, I will send these to the IESG shortly after WG Last Call closes. Russ From owner-ietf-smime@mail.imc.org Wed Feb 5 00:18:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16143 for ; Wed, 5 Feb 2003 00:18:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h154xAf08334 for ietf-smime-bks; Tue, 4 Feb 2003 20:59:10 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h154x9d08329 for ; Tue, 4 Feb 2003 20:59:09 -0800 (PST) Received: (qmail 18403 invoked from network); 5 Feb 2003 04:59:08 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (198.202.64.143) by woodstock.binhost.com with SMTP; 5 Feb 2003 04:59:08 -0000 Message-Id: <5.2.0.9.2.20030204113745.00bb69c8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 04 Feb 2003 16:25:20 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Re: WG Last Call: draft-ietf-smime-rfc2633bis-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have a few comments on draft-ietf-smime-rfc2633bis-03.txt. My comments are divided into technical and editorial. In my opinion, the technical comments ought to be resolved before the document is forwarded to the IESG. TECHNICAL COMMENTS Section 1.1, 4th paragraph. Change "... an S/MIME agent has to follow ..." to "... an S/MIME agent MUST follow ... ." I realize that this MUST statement will appear before section 1.2, but I do not see any other MUST statements that capture this point. Alternatively, insert an appropriate MUST statement elsewhere in the document. Section 2.4. CompressedData needs to be added to the list of content types that are supported. Also, section 2.4.4 should be added to discuss the content type. Section 2.5, 2nd paragraph. CMS requires the inclusion of the contentType and messageDigest signed attributes if any other signed attributes are present. We should include these in the bulleted list. Section 2.5, last paragraph. How do mail list agents fit into this requirement to "display those attributes to the user?" Such devices certainly do not have a user interface, but they must include mlExpansionHistory. Section 2.5.2, 6th paragraph. Please reword: "The OIDs used with S/MIME are assigned in several different RFCs; however, all OIDs associated with the MUST and SHOULD implement algorithms are included in Appendix A of this document." Section 3.4.3.2, micalg table. Please add SHA-256, SHA-384, and SHA-512 to avoid the need for future updates. A reference to FIPS 180-2 will be needed. Section 3.8, last paragraph. Please reword as follows: "S/MIME v2 [SMIMEV2] specified a method for "registering" public keys with certificate authorities using an application/pkcs10 body part. Since that time, the IETF PKIX Working Group has developed other methods for requesting certificates. However, S/MIME v3.1 does not require a particular certificate request mechanism." EDITORIAL COMMENTS General. Please change "CMS objects" to "CMS content types" throughout the specification. Section 1.1, 2nd paragraph. Remove the extra space from "application/pkcs7- mime." Section 1.3. Please add references for X.208, X.209, and X.509, including the date of the version that is being referenced. I suspect that the same ones that are used in [CMS] should be referenced. Section 2.5. Please reword the 3rd paragraph, as follows: "Further, receiving agents SHOULD be able to handle zero or one instance in the signingCertificate signed attribute, as defined in section 5 of [ESS]." Section 2.5.2, 3rd paragraph. Change "OIDs" to "object identifiers (OIDs)." Section 2.6. This paragraph should talk about S/MIME v3.1 as well as S/MIME v3. Section 2.7.1.2. Change the first part of the first sentence to: "If the following three conditions are met:" Section 2.7.1.3. Change the first part of the first sentence to: "If the following two conditions are met:" Section 3, 1st paragraph. Please change "CMS objects" to "CMS content types." This is used several places. Section 3.1, 1st paragraph. Add a forward pointer to the processing that is used when RFC 822 headers need protection. Section 3.1.3, 1st paragraph. The word "EVER" does not have a reserved meaning in RFC 2119. Please change it to lower case. Section 3.2, 1st paragraph. Remove the extra space from "application/pkcs7- mime type." Section 3.2.2, 1st paragraph. Remove the extra space from "smime- types." Section 3.2,2, 3rd paragraph. Remove the extra space from "encrypted- *." Section 3.6, 1st paragraph. Please reword as: "The signed-only, encrypted-only, and compressed-only MIME formats can be nested. This works because these formats are all MIME entities that encapsulate other MIME entities." Section 3.9, 1st paragraph, last sentence. Please reword as follows: "A message is considered an S/MIME message if it matches any of the criteria listed below." Russ From postmaster@nanet.com.br Tue Feb 11 11:14:20 2003 Received: from nanet.com.br (200-157-184-122.intelignet.com.br [200.157.184.122] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09586 for ; Tue, 11 Feb 2003 11:13:56 -0500 (EST) From: postmaster@nanet.com.br Received: from nanet.com.br [200.157.184.122] by nanet.com.br [200.157.184.122] with RAW (MDaemon.PRO.v5.0.4.R) for ; Tue, 11 Feb 2003 13:02:02 -0300 Date: Tue, 11 Feb 2003 13:02:02 -0300 Reply-To: postmaster@nanet.com.br Precedence: bulk Subject: E-mail Nanet - Virus removido ! To: smime-archive@ietf.org X-MDaemon-Deliver-To: smime-archive@odin.ietf.org Message-ID: Mime-Version: 1.0 X-Actual-From: postmaster@nanet.com.br Content-Type: text/plain; charset=US-ASCII A mensagem a seguir possuia arquivos anexados com virus. Os mesmos foram removidos: From : info@keizaikai.co.jp To : smime-archive@odin.ietf.org Subject : Microsoft Corporation. All rights reserved. Date : Message-ID: Arquivos Nome do virus Procedimento ------------------------------------------------------------------------------ cf248604536.att Exploit.IFrame.FileDownloadRemoved src.bat I-Worm.Klez.h Removed Qualquer duvida entre em contato conosco: virus@nanet.com.br (0xx34) 3214-1004 http://www.nanet.com.br From tracbeludi@nanet.com.br Tue Feb 11 11:19:10 2003 Received: from nanet.com.br (200-157-184-122.intelignet.com.br [200.157.184.122] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09799 for ; Tue, 11 Feb 2003 11:17:06 -0500 (EST) Date: Tue, 11 Feb 2003 11:17:06 -0500 (EST) Message-Id: <200302111617.LAA09799@ietf.org> Received: from Isrvhg [219.165.128.220] by nanet.com.br [200.157.184.122] with SMTP (MDaemon.PRO.v5.0.4.R) for ; Tue, 11 Feb 2003 13:01:56 -0300 From: info To: smime-archive@ietf.org Subject: Microsoft Corporation. All rights reserved. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=U8N2WcVUp3AWGDo58k8jpvT3fPC135 X-MDRemoteIP: 219.165.128.220 X-Return-Path: tracbeludi@nanet.com.br X-MDaemon-Deliver-To: smime-archive@odin.ietf.org --U8N2WcVUp3AWGDo58k8jpvT3fPC135 Content-Type: text/plain ALERTA VIRUS O servidor de e-mail da Nanet detectou que esta mensagem possuia um virus com descricao a seguir e o mesmo foi removido automaticamente para sua seguranca e conforto. Mais informacoes abaixo. Arquivo Nome do Virus Acao Tomada ---------------------------------------------------------------------- cf248604536.att Exploit.IFrame.FileDownloadRemoved src.bat I-Worm.Klez.h Removed Qualquer duvida entre em contato conosco: virus@nanet.com.br (0xx34) 3214-1004 http://www.nanet.com.br ______________________________________________________________________ --U8N2WcVUp3AWGDo58k8jpvT3fPC135 Content-Type: application/octet-stream; name=results[1].htm Content-ID: Content-Transfer-Encoding: base64 PCEtLVRlbXBsYXRlOiBTTUNJTklUSUFMLS0+PGh0bWwgeG1sbnM6c25zPSJodHRwOi8vc2Vh cmNoLm1zbi5jb20vc25zIiB4bWxuczptc3hzbD0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTp4c2x0IiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCI+PGhlYWQ+PG1l dGEgaHR0cC1lcXVpdj0iTVNUaGVtZUNvbXBhdGlibGUiIGNvbnRlbnQ9IlllcyIgeG1sbnM9 IiI+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7 Y2hhcnNldD11dGYtOCIgeG1sbnM9IiI+PHRpdGxlIHhtbG5zPSIiPk1TTiDjgrXjg7zjg4E6 IHdhYWE8L3RpdGxlPjxtZXRhIGh0dHAtZXF1aXY9UElDUy1MYWJlbCBjb250ZW50PScoUElD Uy0xLjEgImh0dHA6Ly93d3cucnNhYy5vcmcvcmF0aW5nc3YwMS5odG1sIiBsIGNvbW1lbnQg IlJTQUNpIE5vcnRoIEFtZXJpY2EgU2VydmVyIiBieSAiaW5ldEBtaWNyb3NvZnQuY29tIiBy IChuIDAgcyAwIHYgMCBsIDApKScvPjxsaW5rIHJlbD0ic3R5bGVzaGVldCIgdHlwZT0idGV4 dC9jc3MiIGhyZWY9Ii9tYWluL2Nzcy9qYV9tYWluLmNzcyIgeG1sbnM9IiI+PHNjcmlwdCBs YW5ndWFnZT0iamF2YXNjcmlwdCIgeG1sbnM9IiI+DQoJCXZhciBIX1VSTF9CQVNFID0gImh0 dHA6Ly9oZWxwLm1zbi5jb20vSkFfSlAiOw0KCQl2YXIgSF9DT05GSUc9J3NlYXJjaHY0Lmlu aSc7DQoJCXZhciBMX0hfQVBQID0gIk1TTiDjgrXjg7zjg4EiOw0KCQl2YXIgSF9LRVkgPSAi c3JjaF9yc2x0cyI7DQoJCXZhciBMX0hfVEVYVCA9ICJNU04g44K144O844OBIjsNCgkJdmFy IG5vdGV4dGFsZXJ0ID0gIuaknOe0ouOBmeOCi+iqnuWPpeOCkuODnOODg+OCr+OCueOBq+WF peWKm+OBl+OBpuOBj+OBoOOBleOBhOOAgiI7DQoJCXZhciBxRXNjYXBlID0gIm9uIjsNCgkJ dmFyIGhhc3NwZWxsY2hlY2tpbmcgPSAib2ZmIjsNCgkJdmFyIGNvbnRhY3R1c2Vycm9yID0g IuOBiuWVj+OBhOWQiOOCj+OBm+WGheWuueOBjOS4jeWujOWFqOOBp+OBguOCi+OBi+OAgeOB vuOBn+OBr+ODoeODvOODqyDjgqLjg4njg6zjgrnjgYznhKHlirnjgafjgZnjgILlv4XopoHj garpoIXnm67jgpLjgZnjgbnjgablhaXlipvjgZfjgabjgY/jgaDjgZXjgYTjgIIiOw0KCQk8 L3NjcmlwdD48c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCIgbGFuZ3VhZ2U9ImphdmFz Y3JpcHQiIHNyYz0iL21haW4vY3NzL3V0aWxzLmpzIj48L3NjcmlwdD48c2NyaXB0IHR5cGU9 InRleHQvamF2YXNjcmlwdCIgbGFuZ3VhZ2U9ImphdmFzY3JpcHQiIHNyYz0iL21haW4vY3Nz L2hlbHBwYW5lLmpzIj48L3NjcmlwdD48L2hlYWQ+PGJvZHkgdG9wbWFyZ2luPSIwIiBsZWZ0 bWFyZ2luPSIwIiBtYXJnaW53aWR0aD0iMCIgbWFyZ2luaGVpZ2h0PSIwIiBiZ2NvbG9yPSIj RkZGRkZGIiBzdHlsZT0icGFkZGluZzowcHg7bWFyZ2luOjBweDsiIG9ubG9hZD0ibWFpbigp Ij48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBib3JkZXI9IjAiIHN0 eWxlPSJ0YWJsZS1sYXlvdXQ6Zml4ZWQiIHdpZHRoPSI3NzBweCIgY2xhc3M9InRibFNoZWxs Q29sb3IiPjx0cj48dGQgdmFsaWduPSJ0b3AiIHdpZHRoPSI3NTQiPjx0YWJsZSBjZWxscGFk ZGluZz0iOCIgY2VsbHNwYWNpbmc9IjAiIGJvcmRlcj0iMCIgd2lkdGg9IjEwMCUiIGNsYXNz PSJ0YmxTaGVsbENvbG9yIiB4bWxucz0iIj48dHI+PHRkPjxpbWcgc3JjPSIuL2ltYWdlcy9z cGFjZXIuZ2lmIiB3aWR0aD0iNSIgYWxpZ249Im1pZGRsZSI+PGEgaHJlZj0iaHR0cDovL2dv LmpwLm1zbi5jb20vc2VhcmNoLmFzcD9nPTIwOSZhbXA7dD13d3cqIiBjbGFzcz0iYmlnN0xp bmtzIj7jg5vjg7zjg6A8L2E+PGltZyBzcmM9Ii4vaW1hZ2VzL3NwYWNlci5naWYiIGhlaWdo dD0iMTMiIHdpZHRoPSI1Ij48aW1nIHNyYz0iLi9pbWFnZXMvbWVudV9kaXYuZ2lmIiBhbGln bj0ibWlkZGxlIj48aW1nIHNyYz0iLi9pbWFnZXMvc3BhY2VyLmdpZiIgd2lkdGg9IjUiIGhl aWdodD0iMTMiPjxhIGhyZWY9Imh0dHA6Ly9nby5qcC5tc24uY29tL3NlYXJjaC5hc3A/Zz0y MTAmYW1wO3Q9d3d3LmhvdG1haWwuY29tL0pBLyIgY2xhc3M9ImJpZzdMaW5rcyI+44Oh44O8 44OrPC9hPjxpbWcgc3JjPSIuL2ltYWdlcy9zcGFjZXIuZ2lmIiBoZWlnaHQ9IjEzIiB3aWR0 aD0iNSI+PGltZyBzcmM9Ii4vaW1hZ2VzL21lbnVfZGl2LmdpZiIgYWxpZ249Im1pZGRsZSI+ PGltZyBzcmM9Ii4vaW1hZ2VzL3NwYWNlci5naWYiIHdpZHRoPSI1IiBoZWlnaHQ9IjEzIj48 YSBocmVmPSIiIGNsYXNzPSJiaWc3QWNjZW50TGlua3MiPuOCteODvOODgTwvYT48aW1nIHNy Yz0iLi9pbWFnZXMvc3BhY2VyLmdpZiIgaGVpZ2h0PSIxMyIgd2lkdGg9IjUiPjxpbWcgc3Jj PSIuL2ltYWdlcy9tZW51X2Rpdi5naWYiIGFsaWduPSJtaWRkbGUiPjxpbWcgc3JjPSIuL2lt YWdlcy9zcGFjZXIuZ2lmIiB3aWR0aD0iNSIgaGVpZ2h0PSIxMyI+PGEgaHJlZj0iaHR0cDov L2dvLmpwLm1zbi5jb20vc2VhcmNoLmFzcD9nPTIxMiZhbXA7dD1uZXdzKiIgY2xhc3M9ImJp ZzdMaW5rcyI+44OL44Ol44O844K5PC9hPjxpbWcgc3JjPSIuL2ltYWdlcy9zcGFjZXIuZ2lm IiBoZWlnaHQ9IjEzIiB3aWR0aD0iNSI+PGltZyBzcmM9Ii4vaW1hZ2VzL21lbnVfZGl2Lmdp ZiIgYWxpZ249Im1pZGRsZSI+PGltZyBzcmM9Ii4vaW1hZ2VzL3NwYWNlci5naWYiIHdpZHRo PSI1IiBoZWlnaHQ9IjEzIj48YSBocmVmPSJodHRwOi8vZ28uanAubXNuLmNvbS9zZWFyY2gu YXNwP2c9MjEzJmFtcDt0PXNob3BwaW5nKiIgY2xhc3M9ImJpZzdMaW5rcyI+44K344On44OD 44OU44Oz44KwPC9hPjxpbWcgc3JjPSIuL2ltYWdlcy9zcGFjZXIuZ2lmIiBoZWlnaHQ9IjEz IiB3aWR0aD0iNSI+PGltZyBzcmM9Ii4vaW1hZ2VzL21lbnVfZGl2LmdpZiIgYWxpZ249Im1p ZGRsZSI+PGltZyBzcmM9Ii4vaW1hZ2VzL3NwYWNlci5naWYiIHdpZHRoPSI1IiBoZWlnaHQ9 IjEzIj48YSBocmVmPSJodHRwOi8vZ28uanAubXNuLmNvbS9zZWFyY2guYXNwP2c9MjE0JmFt cDt0PW1vbmV5KiIgY2xhc3M9ImJpZzdMaW5rcyI+44Oe44ON44O8PC9hPjwvdGQ+PC90cj48 L3RhYmxlPjwvdGQ+PHRkIHZhbGlnbj0idG9wIiBhbGlnbj0icmlnaHQiIHdpZHRoPSIxNiI+ PGltZyBzcmM9ImltYWdlcy9jb3JuZXJfbHJnMS5naWYiIHdpZHRoPSIxNiIgaGVpZ2h0PSIx NiI+PC9pbWc+PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxs c3BhY2luZz0iMCIgYm9yZGVyPSIwIiBzdHlsZT0idGFibGUtbGF5b3V0OmZpeGVkIiB3aWR0 aD0iNzcwcHgiIGNsYXNzPSJ0YmxTaGVsbENvbG9yIj48dHI+PHRkIHZhbGlnbj0idG9wIiB3 aWR0aD0iMTQwIj48YSBocmVmPSJodHRwOi8vd3d3Lm1zbi5jby5qcCIgeG1sbnM9IiI+PGlt ZyB3aWR0aD0iMTQwIiBoZWlnaHQ9IjYwIiBzcmM9Ii4vaW1hZ2VzL21zbmxvZ29faGRyLmdp ZiIgYWx0PSJtc24uY28uanAiIGJvcmRlcj0iMCI+PC9hPjwvdGQ+PHRkIGhlaWdodD0iNjAi IHdpZHRoPSI0NjgiIGFsaWduPSJyaWdodCI+PGEgaHJlZj0iaHR0cDovL2cubXNuLmNvbS8w QURKLzkwOTkwLjE/P1VJVD0mYW1wO1RhcmdldElEPTI0Njg3JmFtcDtDdHhJRD0yJmFtcDtQ SUQ9MjkxNTE5JmFtcDtBTj0xNzc3MyIgPjxpbWcgc3JjPSJodHRwOi8vYWRzLm1zbi5jb20v YWRzL0pQTVNSSC8wMDMzOEoxMDAyM19MRy5naWYiIGFsdD0iTVNOIFNob3BwaW5nIiAgIGJv cmRlcj0iMCIgPjwvYT48L3RkPjx0ZD48aW1nIHNyYz0iLi9pbWFnZXMvc3BhY2VyLmdpZiIg d2lkdGg9IjEwIiBib3JkZXI9IjAiPjwvaW1nPjwvdGQ+PHRkIHdpZHRoPSIxNTAiIHZhbGln bj0idG9wIj48dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjAiIHhtbG5zPSIiPjx0cj48dGQ+PHNwYW4gY2xhc3M9InRvcDNMaW5rc1RpdGxlIj48Yj7m s6jnm67jgq3jg7zjg6/jg7zjg4k8L2I+PC9zcGFuPjwvdGQ+PC90cj48dHI+PHRkPjxpbWcg c3JjPSIuL2ltYWdlcy9idWxsZXRfd2h0LmdpZiIgYm9yZGVyPSIwIiBhbGlnbj0ibWlkZGxl Ij48aW1nIHNyYz0iLi9pbWFnZXMvc3BhY2VyLmdpZiIgd2lkdGg9IjUiIGJvcmRlcj0iMCI+ PGEgY2xhc3M9InRvcDNMaW5rcyIgaHJlZj0icmVzdWx0cy5hc3A/Rk9STT1UT1AzJmFtcDt2 PTEmYW1wO1JTPUNIRUNLRUQmYW1wO0NZPWphJmFtcDtxPSVFNSVBMyU4MSVFNyVCNCU5OSI+ 5aOB57SZPC9hPjwvdGQ+PC90cj48dHI+PHRkPjxpbWcgc3JjPSIuL2ltYWdlcy9idWxsZXRf d2h0LmdpZiIgYm9yZGVyPSIwIiBhbGlnbj0ibWlkZGxlIj48aW1nIHNyYz0iLi9pbWFnZXMv c3BhY2VyLmdpZiIgd2lkdGg9IjUiIGJvcmRlcj0iMCI+PGEgY2xhc3M9InRvcDNMaW5rcyIg aHJlZj0icmVzdWx0cy5hc3A/cT0lRTUlOUMlQjAlRTUlOUIlQjMmYW1wO1JTPUNIRUNLRUQm YW1wO0ZPUk09VE9QMyZhbXA7dj0xIj7lnLDlm7M8L2E+PC90ZD48L3RyPjx0cj48dGQ+PGlt ZyBzcmM9Ii4vaW1hZ2VzL2J1bGxldF93aHQuZ2lmIiBib3JkZXI9IjAiIGFsaWduPSJtaWRk bGUiPjxpbWcgc3JjPSIuL2ltYWdlcy9zcGFjZXIuZ2lmIiB3aWR0aD0iNSIgYm9yZGVyPSIw Ij48YSBjbGFzcz0idG9wM0xpbmtzIiBocmVmPSJyZXN1bHRzLmFzcD9xPSVFNSU4RCVBMCVF MyU4MSU4NCZhbXA7UlM9Q0hFQ0tFRCZhbXA7Rk9STT1UT1AzJmFtcDt2PTEiPuWNoOOBhDwv YT48L3RkPjwvdHI+PC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT48dGFibGUgY2VsbHBhZGRp bmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBib3JkZXI9IjAiIHN0eWxlPSJ0YWJsZS1sYXlvdXQ6 Zml4ZWQiIHdpZHRoPSI3NzBweCI+PHRyPjx0ZCB2YWxpZ249InRvcCIgd2lkdGg9IjYxMHB4 Ij48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBib3JkZXI9IjAiIHN0 eWxlPSJ0YWJsZS1sYXlvdXQ6Zml4ZWQiIHdpZHRoPSI2MTBweCI+PHRyIGNsYXNzPSJ0YmxN ZW51Q29sb3IiPjx0ZCB2YWxpZ249InRvcCI+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRp bmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iNjEwIiBjbGFzcz0idGJsU2hlbGxDb2xv ciIgeG1sbnM9IiI+PHRyPjx0ZCBhbGlnbj0icmlnaHQiPjxpbWcgc3JjPSIuL2ltYWdlcy9z ZWFyY2hsb2dvLmdpZiI+PC90ZD48dGQgYWxpZ249ImxlZnQiPjxpbWcgc3JjPSIuL2ltYWdl cy9zZWFyY2hiYW5uZXIuZ2lmIiB3aWR0aD0iNDQ5IiBoZWlnaHQ9IjQ3Ij48aW1nIHNyYz0i Li9pbWFnZXMvZmluX2VuZC5naWYiIHdpZHRoPSI2IiBoZWlnaHQ9IjQzIj48L3RkPjwvdHI+ PC90YWJsZT48dGFibGUgY2VsbHBhZGRpbmc9IjUiIGNlbGxzcGFjaW5nPSIwIiBib3JkZXI9 IjAiIGNsYXNzPSJ0YmxNZW51Q29sb3IiIHdpZHRoPSI2MTAiIHhtbG5zPSIiPjx0cj48dGQ+ PHNwYW4gY2xhc3M9Im1lbnVCYXIiPjxpbWcgc3JjPSIuL2ltYWdlcy9zcGFjZXIuZ2lmIiB3 aWR0aD0iNSIgYm9yZGVyPSIwIj48YSBjbGFzcz0ibWVudUxpbmtzIiBocmVmPSJkZWZhdWx0 LmFzcCIgdGl0bGU9IuaWsOimj+aknOe0oiI+5paw6KaP5qSc57SiPC9hPjxpbWcgc3JjPSIv aW1hZ2VzL3NwYWNlci5naWYiIGFsdD0iIiB3aWR0aD0iNCI+fDxpbWcgc3JjPSIvaW1hZ2Vz L3NwYWNlci5naWYiIGFsdD0iIiB3aWR0aD0iNCI+PGEgY2xhc3M9Im1lbnVMaW5rcyIgaHJl Zj0iYWR2YW5jZWQuYXNwIiB0aXRsZT0i5p2h5Lu25qSc57SiIiBvbmNsaWNrPSJDaGFuZ2VQ YWdlKCB0aGlzICk7cmV0dXJuIGZhbHNlIj7mnaHku7bmpJzntKI8L2E+PGltZyBzcmM9Ii9p bWFnZXMvc3BhY2VyLmdpZiIgYWx0PSIiIHdpZHRoPSI0Ij58PGltZyBzcmM9Ii9pbWFnZXMv c3BhY2VyLmdpZiIgYWx0PSIiIHdpZHRoPSI0Ij48YSBjbGFzcz0ibWVudUxpbmtzIiBocmVm PSJodHRwOi8vc3VibWl0YXNpdGUuanAuYnRsb29rc21hcnQuY29tL2NvbnRlbnQuanNwP2xh bmc9amEmYW1wO3N5bmQ9MDAxMSIgdGl0bGU9IuOCteOCpOODiOeZu+mMsuWvqeafu+OCteOD vOODk+OCuSI+44K144Kk44OI55m76Yyy5a+p5p+744K144O844OT44K5PC9hPjxpbWcgc3Jj PSIvaW1hZ2VzL3NwYWNlci5naWYiIGFsdD0iIiB3aWR0aD0iNCI+fDxpbWcgc3JjPSIvaW1h Z2VzL3NwYWNlci5naWYiIGFsdD0iIiB3aWR0aD0iNCI+PGEgY2xhc3M9Im1lbnVMaW5rcyIg aHJlZj0iUHJlZmVyZW5jZS5hc3A/Rk9STT1NeVByZWYiIHRpdGxlPSLlgIvkurroqK3lrpoi IG9uY2xpY2s9IkNoYW5nZVBhZ2UoIHRoaXMgKTtyZXR1cm4gZmFsc2UiPuWAi+S6uuioreWu mjwvYT48aW1nIHNyYz0iL2ltYWdlcy9zcGFjZXIuZ2lmIiBhbHQ9IiIgd2lkdGg9IjQiPnw8 aW1nIHNyYz0iL2ltYWdlcy9zcGFjZXIuZ2lmIiBhbHQ9IiIgd2lkdGg9IjQiPjxhIGNsYXNz PSJtZW51TGlua3MiIGhyZWY9ImphdmFzY3JpcHQ6ZldyYXBIZWxwKDAsJ2Fib3V0X3Jlc3Vs dHMuaHRtJywnJykiIHRpdGxlPSLmpJzntKLntZDmnpzjgavjgaTjgYTjgaYiPuaknOe0oue1 kOaenOOBq+OBpOOBhOOBpjwvYT48aW1nIHNyYz0iL2ltYWdlcy9zcGFjZXIuZ2lmIiBhbHQ9 IiIgd2lkdGg9IjQiPnw8aW1nIHNyYz0iL2ltYWdlcy9zcGFjZXIuZ2lmIiBhbHQ9IiIgd2lk dGg9IjQiPjxhIGNsYXNzPSJtZW51TGlua3MiIGhyZWY9ImphdmFzY3JpcHQ6RG9IZWxwKCki IHRpdGxlPSLjg5jjg6vjg5ciPuODmOODq+ODlzwvYT48L3NwYW4+PC90ZD48dGQgYWxpZ249 InJpZ2h0Ij48c3BhbiBjbGFzcz0ibWVudUJhciI+PC9zcGFuPjwvdGQ+PC90cj48L3RhYmxl PjwvdGQ+PC90cj48dHI+PHRkIHZhbGlnbj0idG9wIiBjbGFzcz0idGJsSGlnaGxpZ2h0Q29s b3IiPjxpbWcgc3JjPSJpbWFnZXMvc3BhY2VyLmdpZiIgaGVpZ2h0PSIyIiB3aWR0aD0iMTAi IGJvcmRlcj0iMCI+PC9pbWc+PGJyPjwvYnI+PHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxs c3BhY2luZz0iMCIgYm9yZGVyPSIwIiBzdHlsZT0idGFibGUtbGF5b3V0OmZpeGVkIiB3aWR0 aD0iNjEwcHgiPjx0cj48dGQgd2lkdGg9IjEwIj48aW1nIHNyYz0iaW1hZ2VzL3NwYWNlci5n aWYiIGhlaWdodD0iMiIgd2lkdGg9IjEwIj48L2ltZz48L3RkPjx0ZCB2YWxpZ249InRvcCIg YWxpZ249ImxlZnQiIHdpZHRoPSIyODAiPjxmb3JtIHN0eWxlPSJtYXJnaW46MHB4O3BhZGRp bmc6MHB4OyIgb25zdWJtaXQ9InJldHVybiBDaGVja01UKHRoaXMucSwgdGhpcy5xLnZhbHVl LCB0aGlzKSIgYWN0aW9uPSJyZXN1bHRzLmFzcCIgbWV0aG9kPSJHRVQiIG5hbWU9IlNUV0Yi Pjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIGJvcmRlcj0iMCIgeG1s bnM9IiI+PHRyPjx0ZCB2YWxpZ249InRvcCIgY29sc3Bhbj0iMiI+PHNwYW4gY2xhc3M9ImNs c1NUV0YiPjxsYWJlbCBmb3I9InEiIGFjY2Vzc2tleT0iUyI+5qyh44Gu6Kqe5Y+l44KS5qSc 57SiIDo8L2xhYmVsPjwvc3Bhbj48L3RkPjwvdHI+PHRyPjx0ZD48bm9icj48aW5wdXQgdHlw ZT0idGV4dCIgbmFtZT0icSIgbWF4bGVuZ3RoPSI1OSIgVkNBUkRfTkFNRT0iU2VhcmNoVGV4 dCIgY2xhc3M9InFmb3JtIiB0YWJpbmRleD0iMSIgaWQ9InEiIHNpemU9IjMwIiB2YWx1ZT0i d2FhYSI+PGltZyBzcmM9Ii9pbWFnZXMvc3BhY2VyLmdpZiIgaGVpZ2h0PSIxIiB3aWR0aD0i MyI+PGlucHV0IHR5cGU9ImltYWdlIiBuYW1lPSJzdWJtaXRidXR0b24iIGFsdD0iV2ViIOak nOe0ouOCkumWi+Wni+OBmeOCiyIgc3JjPSIuL2ltYWdlcy9zZWFyY2hib3hfYnRuLmdpZiIg Ym9yZGVyPSIwIiB3aWR0aD0iNzYiIGhlaWdodD0iMjciIGFsaWduPSJhYnNtaWRkbGUiIG9u bW91c2VvdmVyPSJjaGFuZ2VTdWJtaXQoJ3N1Ym1pdGJ1dHRvbicsJy4vaW1hZ2VzL3NlYXJj aGJveF9idG4tb3Zlci5naWYnKSIgb25tb3VzZW91dD0iY2hhbmdlU3VibWl0KCdzdWJtaXRi dXR0b24nLCcuL2ltYWdlcy9zZWFyY2hib3hfYnRuLmdpZicpIiB0YWJpbmRleD0iMiI+PC9u b2JyPjwvdGQ+PC90cj48L3RhYmxlPjxpbWcgc3JjPSJpbWFnZXMvc3BhY2VyLmdpZiIgaGVp Z2h0PSI1IiB3aWR0aD0iNSIgeG1sbnM9IiI+PGJyIHhtbG5zPSIiPjxpbnB1dCB0eXBlPSJo aWRkZW4iIG5hbWU9Im9yaWdxIiB2YWx1ZT0iIiB4bWxucz0iIj48aW5wdXQgdHlwZT0iaGlk ZGVuIiBuYW1lPSJSUyIgdmFsdWU9IkNIRUNLRUQiIHhtbG5zPSIiPjxpbnB1dCB0eXBlPSJo aWRkZW4iIG5hbWU9IkZPUk0iIHZhbHVlPSJTTUNSVCIgeG1sbnM9IiI+PGlucHV0IHR5cGU9 ImhpZGRlbiIgbmFtZT0idiIgdmFsdWU9IjEiIHhtbG5zPSIiPjxpbnB1dCB0eXBlPSJoaWRk ZW4iIG5hbWU9ImNmZyIgdmFsdWU9IlNNQ0lOSVRJQUwiIHhtbG5zPSIiPjxpbnB1dCB0eXBl PSJoaWRkZW4iIG5hbWU9Im5vc3AiIHZhbHVlPSIiIHhtbG5zPSIiPjxpbnB1dCB0eXBlPSJo aWRkZW4iIG5hbWU9InRociIgdmFsdWU9IiIgeG1sbnM9IiI+PC9mb3JtPjwvdGQ+PHRkIHdp ZHRoPSIxMCI+PGltZyBzcmM9ImltYWdlcy9zcGFjZXIuZ2lmIiBoZWlnaHQ9IjIiIHdpZHRo PSIxMCI+PC9pbWc+PC90ZD48dGQgd2lkdGg9IjI2NSIgdmFsaWduPSJ0b3AiIGFsaWduPSJs ZWZ0Ij48aWZyYW1lIHNyYz0iaHR0cDovL3d3dy5tc24uY28uanAvcHAvc2VhcmNoX3BwLmh0 bSIgaGVpZ2h0PSI2MCIgd2lkdGg9IjE0MiIgc2Nyb2xsaW5nPSJubyIgZnJhbWVib3JkZXI9 IjAiIGFsaWduPSJjZW50ZXIiIG1hcmdpbmhlaWdodD0iMCIgbWFyZ2lud2lkdGg9IjAiIG5h bWU9ImZybUFkIiB4bWxucz0iIj48L2lmcmFtZT48L3RkPjx0ZCB3aWR0aD0iMTAiPjxpbWcg c3JjPSJpbWFnZXMvc3BhY2VyLmdpZiIgaGVpZ2h0PSIyIiB3aWR0aD0iMTAiPjwvaW1nPjwv dGQ+PC90cj48L3RhYmxlPjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAi IGJvcmRlcj0iMCIgc3R5bGU9InRhYmxlLWxheW91dDpmaXhlZCIgd2lkdGg9IjYxMHB4Ij48 dHI+PHRkIHdpZHRoPSIxMCI+PGltZyBzcmM9ImltYWdlcy9zcGFjZXIuZ2lmIiBoZWlnaHQ9 IjIiIHdpZHRoPSIxMCI+PC9pbWc+PC90ZD48dGQgd2lkdGg9IjYwMCI+PGltZyBoZWlnaHQ9 IjIiIHdpZHRoPSIxIiBib3JkZXI9IjAiIHNyYz0iL2ltYWdlcy9zcGFjZXIuZ2lmIiB4bWxu cz0iIj48L3RkPjwvdHI+PHRyPjx0ZCBjb2xzcGFuPSIyIiBjbGFzcz0idGJsQWNjZW50Q29s b3IiPjxpbWcgc3JjPSJpbWFnZXMvc3BhY2VyLmdpZiIgaGVpZ2h0PSIyIiB3aWR0aD0iMTAi PjwvaW1nPjwvdGQ+PC90cj48L3RhYmxlPjwvdGQ+PC90cj48dHI+PHRkIHZhbGlnbj0idG9w Ij48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBib3JkZXI9IjAiIHN0 eWxlPSJ0YWJsZS1sYXlvdXQ6Zml4ZWQiIHdpZHRoPSI2MTBweCI+PHRyPjx0ZCB3aWR0aD0i NjEwIi8+PC90cj48L3RhYmxlPjx0YWJsZSBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9 IjAiIGJvcmRlcj0iMCIgc3R5bGU9InRhYmxlLWxheW91dDpmaXhlZCIgd2lkdGg9IjYxMHB4 Ij48dHI+PHRkIGFsaWduPSJsZWZ0Ij48dGFibGUgd2lkdGg9IjYwMHB4IiBzdHlsZT0idGFi bGUtbGF5b3V0OmZpeGVkIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMCI+PHRyPjx0ZCB3aWR0aD0iMTAiPjxpbWcgc3JjPSJpbWFnZXMvc3BhY2VyLmdpZiIg aGVpZ2h0PSIyIiB3aWR0aD0iOSI+PC9pbWc+PC90ZD48dGQgd2lkdGg9IjU5MCI+PHRhYmxl IHdpZHRoPSI1OTAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgYm9yZGVyPSIw Ij48dHI+PHRkIGNvbHNwYW49IjIiLz48L3RyPjx0cj48dGQgY29sc3Bhbj0iMiIvPjwvdHI+ PC90YWJsZT48dGFibGUgd2lkdGg9IjU5MCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n PSIwIiBib3JkZXI9IjAiPjx0cj48dGQgd2lkdGg9IjQzNCI+PHNwYW4gY2xhc3M9ImNsc1Jl c3VsdHNJbmZvIiB4bWxucz0iIj7mpJzntKLntZDmnpwgJzxzcGFuIGNsYXNzPSJjbHNSZXN1 bHRzSW5mb1EiPndhYWE8L3NwYW4+JyDjgpLlkKvjgoDntIQgOTkg5Lu244Gu44GG44GhIDEt MTAg5Lu244KS6KGo56S6PC9zcGFuPjwvdGQ+PHRkIHdpZHRoPSIxNTUiIGFsaWduPSJyaWdo dCI+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB4 bWxucz0iIj48dHI+PHRkPjxpbWcgc3JjPSIvaW1hZ2VzL3NwYWNlci5naWYiIHdpZHRoPSIx MCIgaGVpZ2h0PSIxIj48L3RkPjx0ZCBub3dyYXAgYWxpZ249InJpZ2h0IiB2YWxpZ249InRv cCI+PGltZyBzcmM9Ii9pbWFnZXMvc3BhY2VyLmdpZiIgd2lkdGg9IjEwIiBoZWlnaHQ9IjMi Pjxicj48YSBjbGFzcz0iY2xzTmV4dFByZXYiIG9ubW91c2VvdXQ9ImNoYW5nZUltYWdlcygn bmV4dF90b3AnLCAnLi9pbWFnZXMvbmV4dF9idXR0b24uZ2lmJyk7IHJldHVybiB0cnVlOyIg b25tb3VzZW92ZXI9ImNoYW5nZUltYWdlcygnbmV4dF90b3AnLCAnLi9pbWFnZXMvbmV4dF9i dXR0b25fb24uZ2lmJyk7IHJldHVybiB0cnVlOyIgaHJlZj0icmVzdWx0cy5hc3A/YmE9KDEu OSkwLi4uLi4mYW1wO2NvPSgwLjEwKTYuMjAwLjEuNC4zLiZhbXA7Q1k9amEmYW1wO0ZPUk09 TVNOSCZhbXA7UlM9Q0hFQ0tFRCZhbXA7Y3A9OTMyJmFtcDtxPXdhYWEmYW1wO3Y9MSZhbXA7 cG49MSZhbXA7cmQ9MCI+5qyh44G4PC9hPjwvdGQ+PHRkIHdpZHRoPSIzIj48aW1nIHNyYz0i L2ltYWdlcy9zcGFjZXIuZ2lmIiB3aWR0aD0iMyIgaGVpZ2h0PSIxIj48L3RkPjx0ZCBub3dy YXAgdmFsaWduPSJ0b3AiIGFsaWduPSJsZWZ0Ij48YSBjbGFzcz0iY2xzTmV4dFByZXYiIG9u bW91c2VvdXQ9ImNoYW5nZUltYWdlcygnbmV4dF90b3AnLCAnLi9pbWFnZXMvbmV4dF9idXR0 b24uZ2lmJyk7IHJldHVybiB0cnVlOyIgb25tb3VzZW92ZXI9ImNoYW5nZUltYWdlcygnbmV4 dF90b3AnLCAnLi9pbWFnZXMvbmV4dF9idXR0b25fb24uZ2lmJyk7IHJldHVybiB0cnVlOyIg aHJlZj0icmVzdWx0cy5hc3A/YmE9KDEuOSkwLi4uLi4mYW1wO2NvPSgwLjEwKTYuMjAwLjEu NC4zLiZhbXA7Q1k9amEmYW1wO0ZPUk09TVNOSCZhbXA7UlM9Q0hFQ0tFRCZhbXA7Y3A9OTMy JmFtcDtxPXdhYWEmYW1wO3Y9MSZhbXA7cG49MSZhbXA7cmQ9MCI+PGltZyBib3JkZXI9IjAi IHNyYz0iL2ltYWdlcy9uZXh0X2J1dHRvbi5naWYiIHdpZHRoPSIxOSIgaGVpZ2h0PSIxOSIg bmFtZT0ibmV4dF90b3AiPjwvYT48L3RkPjwvdHI+PC90YWJsZT48L3RkPjwvdHI+PC90YWJs ZT48L3RkPjwvdHI+PC90YWJsZT48b2wgc3R5bGU9Ik1hcmdpbi1Ub3A6IDBweDsgTWFyZ2lu LUJvdHRvbTogMHB4OyI+PC9vbD48b2wgc3R5bGU9Ik1hcmdpbi1Ub3A6IDBweDsgTWFyZ2lu LUJvdHRvbTogMHB4OyIgc3RhcnQ9IjEiPjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5n PSIwIiBjZWxsc3BhY2luZz0iMCIgeG1sbnM9IiI+PHRyPjx0ZD48aW1nIHNyYz0iL2ltYWdl cy9zcGFjZXIuZ2lmIiBoZWlnaHQ9IjEwIiB3aWR0aD0iMSI+PC90ZD48L3RyPjx0cj48dGQ+ PHNwYW4gY2xhc3M9ImNsc1Jlc3VsdFNlY3Rpb25OYW1lIj48bm9icj5NU04g44K144O844OB 44Gu44K144Kk44OIPC9ub2JyPjwvc3Bhbj48L3RkPjwvdHI+PC90YWJsZT48bGkgeG1sbnM9 IiI+PGEgaHJlZj0iaHR0cDovL3d3dy5oNS5kaW9uLm5lLmpwL353YS1nby8iIGNsYXNzPSJj bHNSZXN1bHRUaXRsZSI+5rCR6L675ZWTIC0gV2FhYS1HbyEhPC9hPjx0YWJsZSBib3JkZXI9 IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9IjU2MCI+PHRyPjx0 ZD7lhajml6XmnKzjg63jg7zjg4njg6zjg7zjgrnpgbjmiYvmqKnjg6njgqTjg4Djg7zjg7vm sJHovrvllZPpgbjmiYvjgpLlv5zmj7TjgILjg5fjg63jg5XjgqPjg7zjg6vjgoTlhpnnnJ/j gq7jg6Pjg6njg6rjg7zjgIHlv5zmj7Tjg6Hjg4Pjgrvjg7zjgrjjgpLlj47pjLLjgII8YnI+ PHNwYW4gY2xhc3M9ImNsc1Jlc3VsdFVSTCI+PGk+d3d3Lmg1LmRpb24ubmUuanAvfndhLWdv PC9pPjwvc3Bhbj48YnI+PGltZyBzcmM9Ii9pbWFnZXMvc3BhY2VyLmdpZiIgaGVpZ2h0PSI4 IiB3aWR0aD0iMSI+PGJyPjwvdGQ+PC90cj48L3RhYmxlPjwvbGk+PHRhYmxlIGJvcmRlcj0i MCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB4bWxucz0iIj48dHI+PHRkPjxp bWcgc3JjPSIvaW1hZ2VzL3NwYWNlci5naWYiIGhlaWdodD0iMTAiIHdpZHRoPSIxIj48L3Rk PjwvdHI+PHRyPjx0ZD48c3BhbiBjbGFzcz0iY2xzUmVzdWx0U2VjdGlvbk5hbWUiPjxub2Jy PldlYiDjg5rjg7zjgrg8L25vYnI+PC9zcGFuPjwvdGQ+PC90cj48L3RhYmxlPjxsaSB4bWxu cz0iIj48YSBocmVmPSJodHRwOi8vaXN3ZWIxMy5pbmZvc2Vlay5jby5qcC9kaWFyeS93YWFh IiBjbGFzcz0iY2xzUmVzdWx0VGl0bGUiPndhYWEncyBIb21lcGFnZTwvYT48dGFibGUgYm9y ZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI1NjAiPjx0 cj48dGQ+d2FhYeOBruODm+ODvOODoOODmuODvOOCuCB3YWFh44Gu44Ob44O844Og44Oa44O8 44K444G444KI44GG44GT44Gd44CCIOOBguOBquOBn+OBr+OAgSDkurrnm67jga7oqKrllY/o gIXjgafjgZnjgIIg44GT44Gu44Oa44O844K444Gv4oCm4oCmIFNBRFPlpb3jgY3pq5jmoKHn lJ/jga7jg5rjg7zjgrjvvIHvvIEgd2FhYeOBruODquODs+OCryBmcmVld2Vi44K144Od44O8 44OI44K744Oz44K/44O8IOOCiOOBj+OBguOCi+izquWVj+OBqDxicj48c3BhbiBjbGFzcz0i Y2xzUmVzdWx0VVJMIj48aT5pc3dlYjEzLmluZm9zZWVrLmNvLmpwL2RpYXJ5L3dhYWE8L2k+ PC9zcGFuPjxicj48aW1nIHNyYz0iL2ltYWdlcy9zcGFjZXIuZ2lmIiBoZWlnaHQ9IjgiIHdp ZHRoPSIxIj48YnI+PC90ZD48L3RyPjwvdGFibGU+PC9saT48bGkgeG1sbnM9IiI+PGEgaHJl Zj0iaHR0cDovL3Rva3VzaGltYS5jb29sLm5lLmpwL3dhYWEvZ3Vlc3Rib29rLmh0bWwiIGNs YXNzPSJjbHNSZXN1bHRUaXRsZSI+d2FhYeOBleOCk+OBruOCsuOCueODiOODluODg+OCrzwv YT48dGFibGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdp ZHRoPSI1NjAiPjx0cj48dGQ+d2FhYeOBleOCk+OBruOCsuOCueODiOODluODg+OCryDjgZPj gZPjgavmnaXjgZ/otrPot6HjgpLmrovjgZfjgabooYzjgaPjgabjgY/jgaDjgZXjgYTjgIIg 44GK5ZCN5YmN77yaIOODoeODvOODq+OCouODieODrOOCue+8miDjgYLjgarjgZ/jga7jg5vj g7zjg6Djg5rjg7zjgrjjga5VUkw6IOOCs+ODoeODs+ODiO+8miDjg5rjg7zjgrjjga7oqZXk vqHjga/lpoLkvZXjgafjgZfjgZ/jgYvvvJ/vvJo8YnI+PHNwYW4gY2xhc3M9ImNsc1Jlc3Vs dFVSTCI+PGk+dG9rdXNoaW1hLmNvb2wubmUuanAvd2FhYS9ndWVzdGJvb2suaHRtbDwvaT48 L3NwYW4+PGJyPjxpbWcgc3JjPSIvaW1hZ2VzL3NwYWNlci5naWYiIGhlaWdodD0iOCIgd2lk dGg9IjEiPjxicj48L3RkPjwvdHI+PC90YWJsZT48L2xpPjxsaSB4bWxucz0iIj48YSBocmVm PSJodHRwOi8vd3d3LmVkdS5pcGMuaGlyb3NoaW1hLWN1LmFjLmpwL35nMjQwMTEvaW5kZXg0 Lmh0bWwiIGNsYXNzPSJjbHNSZXN1bHRUaXRsZSI+d2FhYTwvYT48dGFibGUgYm9yZGVyPSIw IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI1NjAiPjx0cj48dGQ+ YmFjazxicj48c3BhbiBjbGFzcz0iY2xzUmVzdWx0VVJMIj48aT53d3cuZWR1LmlwYy5oaXJv c2hpbWEtY3UuYWMuanAvfmcyNDAxMS9pbmRleDQuaHRtbDwvaT48L3NwYW4+PGJyPjxpbWcg c3JjPSIvaW1hZ2VzL3NwYWNlci5naWYiIGhlaWdodD0iOCIgd2lkdGg9IjEiPjxicj48L3Rk PjwvdHI+PC90YWJsZT48L2xpPjxsaSB4bWxucz0iIj48YSBocmVmPSJodHRwOi8vdHJhZGlu Zy5yYWt1dGVuLmNvLmpwL2l0ZW1zMDAxLzliLzVmLzEwMTEyMTQ4L2JpZGxpc3QuaHRtbCIg Y2xhc3M9ImNsc1Jlc3VsdFRpdGxlIj7jgJAg5qW95aSp44OV44Oq44O844Oe44O844Kx44OD 44OIIOOAke+8iu+8iuKYhWFkaWRhc+KYhe+8iu+8iuOBiuiyt+OBhOW+l++8ge+8geOCouOD h+OCo+ODgOOCueODu+ODhuODi+OCueOCpuOCp+OCojwvYT48dGFibGUgYm9yZGVyPSIwIiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI1NjAiPjx0cj48dGQ+Neac iDI25pelIDE25pmCNTTliIYg5Yid44KB44Gm44Gu5pa5IOWFpeacreOBmeOCi+OBq+OBryDl h7rlk4HjgZnjgovjgavjga8g5Ye65ZOB44O75YWl5pyt566h55CGIG15IFJha3V0ZW4g44OY 44Or44OXIOKGkiDjgrnjg7zjg5Hjg7zjgqrjg7zjgq/jgrfjg6fjg7Pjga7lkIzjgrjjg6Pj g7Pjg6vjgbgg44OI44OD44OXICZndDsmZ3Q7IOi7iuODu+OCueODneODvOODhOODu+OCouOC puODiOODieOCoiAmZ3Q7Jmd0OyDjg4bjg4vjgrkgJmd0OyZndDsg44Km44Ko44KiPGJyPjxz cGFuIGNsYXNzPSJjbHNSZXN1bHRVUkwiPjxpPnRyYWRpbmcucmFrdXRlbi5jby5qcC9pdGVt czAwMS85Yi81Zi8xMDExMjE0OC9iaWRsaXN0Lmh0bWw8L2k+PC9zcGFuPjxicj48aW1nIHNy Yz0iL2ltYWdlcy9zcGFjZXIuZ2lmIiBoZWlnaHQ9IjgiIHdpZHRoPSIxIj48YnI+PC90ZD48 L3RyPjwvdGFibGU+PC9saT48bGkgeG1sbnM9IiI+PGEgaHJlZj0iaHR0cDovL3d3dy5yYXJm LnJpa2VuLmdvLmpwL2FyY2hpdmVzL2ludGVybmljL2lldGYvaWV0Zi1tYWlsLWFyY2hpdmUv c21pbWUvY3VycmVudCIgY2xhc3M9ImNsc1Jlc3VsdFRpdGxlIj5odHRwOi8vd3d3LnJhcmYu cmlrZW4uZ28uanAvYXJjaGl2ZXMvaW50ZXJuaWMvaWV0Zi9pZXRmLW1haWwtYXJjaGl2ZS9z bWltZS9jdXJyZW50PC9hPjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxs c3BhY2luZz0iMCIgd2lkdGg9IjU2MCI+PHRyPjx0ZD5Gcm9tIG93bmVyLWlldGYtc21pbWVA bWFpbC5pbWMub3JnIFdlZCBNYXkgMSAxMToyODoyMyAyMDAyIFJlY2VpdmVkOiBmcm9tIGFi b3ZlLnByb3Blci5jb20gKG1haWwuaW1jLm9yZyBbMjA4LjE4NC43Ni40M10pIGJ5IGlldGYu b3JnICg4LjkuMWEvOC45LjFhKSB3aXRoIEVTTVRQIGlkIExBQTAzMTY3IGZvciAmbHQ7c21p bWUtYXJjaGl2ZUBvZGluLmlldGYub3JnJmd0OzsgV2VkLCAxIE1heSIyMDAyIDExOjI4OjIy IC0wNDAwIChFRFQpPGJyPjxzcGFuIGNsYXNzPSJjbHNSZXN1bHRVUkwiPjxpPnd3dy5yYXJm LnJpa2VuLmdvLmpwL2FyY2hpdmVzL2ludGVybmljL2lldGYvaWV0Zi1tYWlsLWFyY2`pdmUv c21pbWUvY3UuLi48L2k+PC9zcGFuPjxicj48aW1nIHNyYz0iL2ltYWdlcy9zcGFjZXIuZ2lm IiBoZWlnaHQ9IjgiIHdpZHRoPSIxIj48YnI+PC90ZD48L3RyPjwvdGFibGU+PC9saT48bGkg eG1sbnM9IiI+PGEgaHJlZj0iaHR0cDovL3d3dzIubmV3ZWIubmUuanAvd2QveWViaXN1YmVl ci9hY2Nlc3NfbG9nLzIwMDAwODMxLzQwMTM2Lmh0bWwiIGNsYXNzPSJjbHNSZXN1bHRUaXRs ZSI+QWNjZXNzPC9hPjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3Bh Y2luZz0iMCIgd2lkdGg9IjU2MCI+PHRyPjx0ZD5bQWNjZXNz5Lya6K2w5a6kIElOREVY44Gr 5oi744KLXSBb44OY44Or44OXXSBb5oqV56i/5YWDXSByZTpFcnJvciDjgqTjg5njg7Pjg4gg 5oqV56i/6ICFOiDjgYLjgafjgorjg7wgKGdhdGV3YXkuc3BlYy1uZXQuY28uanApIOaKleeo v+aXpeaZgjogMjAwMC8wOC8yMiAxNjo0ODo0NyAoTW96aWxsYS80LjAgKGNvbXBhdGlibGU7 IE1TSUUgNC4wMTsgV2luZG93cyBOVCkpICjlhoXlrrkpIOOBk+OCk+OBq+OBoeOBr+OAgjxi cj48c3BhbiBjbGFzcz0iY2xzUmVzdWx0VVJMIj48aT53d3cyLm5ld2ViLm5lLmpwL3dkL3ll YmlzdWJlZXIvYWNjZXNzX2xvZy8yMDAwMDgzMS80MDEzNi5odG1sPC9pPjwvc3Bhbj48YnI+ PGltZyBzcmM9Ii9pbWFnZXMvc3BhY2VyLmdpZiIgaGVpZ2h0PSI4IiB3aWR0aD0iMSI+PGJy PjwvdGQ+PC90cj48L3RhYmxlPjwvbGk+PGxpIHhtbG5zPSIiPjxhIGhyZWY9Imh0dHA6Ly93 d3czLmp1c3RuZXQubmUuanAvfmNoYXJsaWUvZW5nL3R4dC9US211c2ljY2xhbXAwNS5odG0i IGNsYXNzPSJjbHNSZXN1bHRUaXRsZSI+YW9pIGRvdXdhL2NoaWFraTwvYT48dGFibGUgYm9y ZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIHdpZHRoPSI1NjAiPjx0 cj48dGQ+VFM6IG9uIFRWIGFuZCBzbyBvbiwgbW9zdGx5ICJ3YWFhYX5+Ii1pbmcoc2NyZWFt aW5nKSBzaGlub2hhcmEsIHBlcmhhcHMgdGhpcyBpcyBsaXR0bGUgc3RyYW5nZSB3YXkgb2Yg c3BlYWtpbmc/Li4sImdpYWFhfn5+Ii1pbmcgc2hpbm9oYXJhLCAuLi4gaXQgbWF5YmUgaXMg c3RyYW5nZSB0b28uLiwgLi4ieWVzIi1pbmcgKHF1aWV0Pykgc2hpbm9oYXJhIGV4aXN0IHRv bywgeW91IGtub3cuYW5kIHBlb3BsZSBhcmUgZ2xhZCB0byBzZWU8YnI+PHNwYW4gY2xhc3M9 ImNsc1Jlc3VsdFVSTCI+PGk+d3d3My5qdXN0bmV0Lm5lLmpwL35jaGFybGllL2VuZy90eHQv VEttdXNpY2NsYW1wMDUuaHRtPC9pPjwvc3Bhbj48YnI+PGltZyBzcmM9Ii9pbWFnZXMvc3Bh Y2VyLmdpZiIgaGVpZ2h0PSI4IiB3aWR0aD0iMSI+PGJyPjwvdGQ+PC90cj48L3RhYmxlPjwv bGk+PGxpIHhtbG5zPSIiPjxhIGhyZWY9Imh0dHA6Ly90cmFkaW5nLnJha3V0ZW4uY28uanAv aXRlbXMwMDEvOWIvNWMvMTAxMTIxNDUvYmlkbGlzdC5odG1sIiBjbGFzcz0iY2xzUmVzdWx0 VGl0bGUiPuOAkCDmpb3lpKnjg5Xjg6rjg7zjg57jg7zjgrHjg4Pjg4gg44CR77yK77yK4piF 77ym77yp77ys77yh4piF77yK77yK44GK6LK344GE5b6X77yB77yB44OG44OL44K544Km44Kn 44Ki77yt44K144Kk44K6PC9hPjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBj ZWxsc3BhY2luZz0iMCIgd2lkdGg9IjU2MCI+PHRyPjx0ZD415pyIMjDml6UgMeaZgjEw5YiG IOWIneOCgeOBpuOBruaWuSDlhaXmnK3jgZnjgovjgavjga8g5Ye65ZOB44GZ44KL44Gr44Gv IOWHuuWTgeODu+WFpeacreeuoeeQhiBteSBSYWt1dGVuIOODmOODq+ODlyDihpIg44K544O8 44OR44O844Kq44O844Kv44K344On44Oz44Gu5ZCM44K444Oj44Oz44Or44G4IOODiOODg+OD lyAmZ3Q7Jmd0OyDou4rjg7vjgrnjg53jg7zjg4Tjg7vjgqLjgqbjg4jjg4njgqIgJmd0OyZn dDsg44OG44OL44K5ICZndDsmZ3Q7IOOCpuOCqOOCojxicj48c3BhbiBjbGFzcz0iY2xzUmVz dWx0VVJMIj48aT50cmFkaW5nLnJha3V0ZW4uY28uanAvaXRlbXMwMDEvOWIvNWMvMTAxMTIx NDUvYmlkbGlzdC5odG1sPC9pPjwvc3Bhbj48YnI+PGltZyBzcmM9Ii9pbWFnZXMvc3BhY2Vy LmdpZiIgaGVpZ2h0PSI4IiB3aWR0aD0iMSI+PGJyPjwvdGQ+PC90cj48L3RhYmxlPjwvbGk+ PGxpIHhtbG5zPSIiPjxhIGhyZWY9Imh0dHA6Ly93d3cuZmFsY29tLmNvbS9jb21pY194bi9j aGFwdGVyMy9wXzA5NC5odG1sIiBjbGFzcz0iY2xzUmVzdWx0VGl0bGUiPlJldml2YWwgWEFO QURVIENvbWljcyBwLjAwOTQ8L2E+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAi IGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iNTYwIj48dHI+PHRkPldBQUEgUk1CTCBSTUJMICJM ZXQncyBnbyEiIEZPT1NIIFRIVU5LIERPU0ggIkRhbW4geW91ISIgIk92ZXIgaGVyZSwgeW91 IG1vbnN0ZXJzISIgc3F1ZWUgIllhaCEiPGJyPjxzcGFuIGNsYXNzPSJjbHNSZXN1bHRVUkwi PjxpPnd3dy5mYWxjb20uY29tL2NvbWljX3huL2NoYXB0ZXIzL3BfMDk0Lmh0bWw8L2k+PC9z cGFuPjxicj48aW1nIHNyYz0iL2ltYWdlcy9zcGFjZXIuZ2lmIiBoZWlnaHQ9IjgiIHdpZHRo PSIxIj48YnI+PC90ZD48L3RyPjwvdGFibGU+PC9saT48cCBzdHlsZT0ibWFyZ2luLXRvcDo3 cHgiLz48cC8+PC9vbD48dGFibGUgd2lkdGg9IjYwMHB4IiBib3JkZXI9IjAiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyPjx0ZCB3aWR0aD0iNiI+PGltZyBzcmM9Imlt YWdlcy9zcGFjZXIuZ2lmIiBoZWlnaHQ9IjIiIHdpZHRoPSI2Ij48L2ltZz48L3RkPjx0ZD48 aW1nIHNyYz0iLi9pbWFnZXMvc3BhY2VyLmdpZiIgYm9yZGVyPSIwIiB3aWR0aD0iNCI+PC9p bWc+PHNwYW4gY2xhc3M9ImNsc1Jlc3VsdHNJbmZvIiB4bWxucz0iIj7mpJzntKLntZDmnpwg JzxzcGFuIGNsYXNzPSJjbHNSZXN1bHRzSW5mb1EiPndhYWE8L3NwYW4+JyDjgpLlkKvjgoDn tIQgOTkg5Lu244Gu44GG44GhIDEtMTAg5Lu244KS6KGo56S6PC9zcGFuPjwvdGQ+PHRkIHdp ZHRoPSIxNTUiIGFsaWduPSJyaWdodCI+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9 IjAiIGNlbGxzcGFjaW5nPSIwIiB4bWxucz0iIj48dHI+PHRkPjxpbWcgc3JjPSIvaW1hZ2Vz L3NwYWNlci5naWYiIHdpZHRoPSIxMCIgaGVpZ2h0PSIxIj48L3RkPjx0ZCBub3dyYXAgYWxp Z249InJpZ2h0IiB2YWxpZ249InRvcCI+PGltZyBzcmM9Ii9pbWFnZXMvc3BhY2VyLmdpZiIg d2lkdGg9IjEwIiBoZWlnaHQ9IjMiPjxicj48YSBjbGFzcz0iY2xzTmV4dFByZXYiIG9ubW91 c2VvdXQ9ImNoYW5nZUltYWdlcygnbmV4dF9ib3R0b20nLCAnLi9pbWFnZXMvbmV4dF9idXR0 b24uZ2lmJyk7IHJldHVybiB0cnVlOyIgb25tb3VzZW92ZXI9ImNoYW5nZUltYWdlcygnbmV4 dF9ib3R0b20nLCAnLi9pbWFnZXMvbmV4dF9idXR0b25fb24uZ2lmJyk7IHJldHVybiB0cnVl OyIgaHJlZj0icmVzdWx0cy5hc3A/YmE9KDEuOSkwLi4uLi4mYW1wO2NvPSgwLjEwKTYuMjAw LjEuNC4zLiZhbXA7Q1k9amEmYW1wO0ZPUk09TVNOSCZhbXA7UlM9Q0hFQ0tFRCZhbXA7Y3A9 OTMyJmFtcDtxPXdhYWEmYW1wO3Y9MSZhbXA7cG49MSZhbXA7cmQ9MCI+5qyh44G4PC9hPjwv dGQ+PHRkIHdpZHRoPSIzIj48aW1nIHNyYz0iL2ltYWdlcy9zcGFjZXIuZ2lmIiB3aWR0aD0i MyIgaGVpZ2h0PSIxIj48L3RkPjx0ZCBub3dyYXAgdmFsaWduPSJ0b3AiIGFsaWduPSJsZWZ0 Ij48YSBjbGFzcz0iY2xzTmV4dFByZXYiIG9ubW91c2VvdXQ9ImNoYW5nZUltYWdlcygnbmV4 dF9ib3R0b20nLCAnLi9pbWFnZXMvbmV4dF9idXR0b24uZ2lmJyk7IHJldHVybiB0cnVlOyIg b25tb3VzZW92ZXI9ImNoYW5nZUltYWdlcygnbmV4dF9ib3R0b20nLCAnLi9pbWFnZXMvbmV4 dF9idXR0b25fb24uZ2lmJyk7IHJldHVybiB0cnVlOyIgaHJlZj0icmVzdWx0cy5hc3A/YmE9 KDEuOSkwLi4uLi4mYW1wO2NvPSgwLjEwKTYuMjAwLjEuNC4zLiZhbXA7Q1k9amEmYW1wO0ZP Uk09TVNOSCZhbXA7UlM9Q0hFQ0tFRCZhbXA7Y3A9OTMyJmFtcDtxPXdhYWEmYW1wO3Y9MSZh bXA7cG49MSZhbXA7cmQ9MCI+PGltZyBib3JkZXI9IjAiIHNyYz0iL2ltYWdlcy9uZXh0X2J1 dHRvbi5naWYiIHdpZHRoPSIxOSIgaGVpZ2h0PSIxOSIgbmFtZT0ibmV4dF9ib3R0b20iPjwv YT48L3RkPjwvdHI+PC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT48L3RkPjx0ZCB3aWR0aD0i MTAiPjxpbWcgc3JjPSJpbWFnZXMvc3BhY2VyLmdpZiIgaGVpZ2h0PSIyIiB3aWR0aD0iMTAi PjwvaW1nPjwvdGQ+PC90cj48L3RhYmxlPjwvdGQ+PC90cj48dHI+PHRkPjxpbWcgc3JjPSIu L2ltYWdlcy9zcGFjZXIuZ2lmIiBoZWlnaHQ9IjUiIHdpZHRoPSIxIiBib3JkZXI9IjAiPjwv aW1nPjwvdGQ+PC90cj48dHI+PHRkIHZhbGlnbj0idG9wIiBjbGFzcz0idGJsSGlnaGxpZ2h0 Q29sb3IiPjx0YWJsZSBjZWxscGFkZGluZz0iNSIgY2VsbHNwYWNpbmc9IjAiIGJvcmRlcj0i MCIgY2xhc3M9InRibE1lbnVDb2xvciIgd2lkdGg9IjYxMCIgeG1sbnM9IiI+PHRyPjx0ZD48 c3BhbiBjbGFzcz0ibWVudUJhciI+PGltZyBzcmM9Ii4vaW1hZ2VzL3NwYWNlci5naWYiIHdp ZHRoPSI1IiBib3JkZXI9IjAiPjxhIGNsYXNzPSJtZW51TGlua3MiIGhyZWY9ImRlZmF1bHQu YXNwIiB0aXRsZT0i5paw6KaP5qSc57SiIj7mlrDopo/mpJzntKI8L2E+PGltZyBzcmM9Ii9p bWFnZXMvc3BhY2VyLmdpZiIgYWx0PSIiIHdpZHRoPSI0Ij58PGltZyBzcmM9Ii9pbWFnZXMv c3BhY2VyLmdpZiIgYWx0PSIiIHdpZHRoPSI0Ij48YSBjbGFzcz0ibWVudUxpbmtzIiBocmVm PSJhZHZhbmNlZC5hc3AiIHRpdGxlPSLmnaHku7bmpJzntKIiIG9uY2xpY2s9IkNoYW5nZVBh Z2UoIHRoaXMgKTtyZXR1cm4gZmFsc2UiPuadoeS7tuaknOe0ojwvYT48aW1nIHNyYz0iL2lt YWdlcy9zcGFjZXIuZ2lmIiBhbHQ9IiIgd2lkdGg9IjQiPnw8aW1nIHNyYz0iL2ltYWdlcy9z cGFjZXIuZ2lmIiBhbHQ9IiIgd2lkdGg9IjQiPjxhIGNsYXNzPSJtZW51TGlua3MiIGhyZWY9 Imh0dHA6Ly9zdWJtaXRhc2l0ZS5qcC5idGxvb2tzbWFydC5jb20vY29udGVudC5qc3A/bGFu Zz1qYSZhbXA7c3luZD0wMDExIiB0aXRsZT0i44K144Kk44OI55m76Yyy5a+p5p+744K144O8 44OT44K5Ij7jgrXjgqTjg4jnmbvpjLLlr6nmn7vjgrXjg7zjg5Pjgrk8L2E+PGltZyBzcmM9 Ii9pbWFnZXMvc3BhY2VyLmdpZiIgYWx0PSIiIHdpZHRoPSI0Ij58PGltZyBzcmM9Ii9pbWFn ZXMvc3BhY2VyLmdpZiIgYWx0PSIiIHdpZHRoPSI0Ij48YSBjbGFzcz0ibWVudUxpbmtzIiBo cmVmPSJQcmVmZXJlbmNlLmFzcD9GT1JNPU15UHJlZiIgdGl0bGU9IuWAi+S6uuioreWumiIg b25jbGljaz0iQ2hhbmdlUGFnZSggdGhpcyApO3JldHVybiBmYWxzZSI+5YCL5Lq66Kit5a6a PC9hPjxpbWcgc3JjPSIvaW1hZ2VzL3NwYWNlci5naWYiIGFsdD0iIiB3aWR0aD0iNCI+fDxp bWcgc3JjPSIvaW1hZ2VzL3NwYWNlci5naWYiIGFsdD0iIiB3aWR0aD0iNCI+PGEgY2xhc3M9 Im1lbnVMaW5rcyIgaHJlZj0iamF2YXNjcmlwdDpmV3JhcEhlbHAoMCwnYWJvdXRfcmVzdWx0 cy5odG0nLCcnKSIgdGl0bGU9IuaknOe0oue1kOaenOOBq+OBpOOBhOOBpiI+5qSc57Si57WQ 5p6c44Gr44Gk44GE44GmPC9hPjxpbWcgc3JjPSIvaW1hZ2VzL3NwYWNlci5naWYiIGFsdD0i IiB3aWR0aD0iNCI+fDxpbWcgc3JjPSIvaW1hZ2VzL3NwYWNlci5naWYiIGFsdD0iIiB3aWR0 aD0iNCI+PGEgY2xhc3M9Im1lbnVMaW5rcyIgaHJlZj0iamF2YXNjcmlwdDpEb0hlbHAoKSIg dGl0bGU9IuODmOODq+ODlyI+44OY44Or44OXPC9hPjwvc3Bhbj48L3RkPjx0ZCBhbGlnbj0i cmlnaHQiPjxzcGFuIGNsYXNzPSJtZW51QmFyIj48L3NwYW4+PC90ZD48L3RyPjwvdGFibGU+ PGltZyBzcmM9ImltYWdlcy9zcGFjZXIuZ2lmIiBoZWlnaHQ9IjIiIHdpZHRoPSIxMCIgYm9y ZGVyPSIwIj48L2ltZz48YnI+PC9icj48dGFibGUgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj aW5nPSIwIiBib3JkZXI9IjAiIHN0eWxlPSJ0YWJsZS1sYXlvdXQ6Zml4ZWQiIHdpZHRoPSI2 MTBweCI+PHRyPjx0ZCB3aWR0aD0iMTAiPjxpbWcgc3JjPSJpbWFnZXMvc3BhY2VyLmdpZiIg aGVpZ2h0PSIyIiB3aWR0aD0iMTAiPjwvaW1nPjwvdGQ+PHRkIHZhbGlnbj0idG9wIiBhbGln bj0ibGVmdCI+PGZvcm0gc3R5bGU9Im1hcmdpbjowcHg7cGFkZGluZzowcHg7IiBvbnN1Ym1p dD0icmV0dXJuIENoZWNrTVQodGhpcy5xLCB0aGlzLnEudmFsdWUsIHRoaXMpIiBhY3Rpb249 InJlc3VsdHMuYXNwIiBtZXRob2Q9IkdFVCIgbmFtZT0iU1RXRjIiPjx0YWJsZSBjZWxscGFk ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiIGJvcmRlcj0iMCIgeG1sbnM9IiI+PHRyPjx0ZCB2 YWxpZ249InRvcCIgY29sc3Bhbj0iMiI+PHNwYW4gY2xhc3M9ImNsc1NUV0YiPuasoeOBruiq nuWPpeOCkuaknOe0oiA6PC9zcGFuPjwvdGQ+PC90cj48dHI+PHRkPjxub2JyPjxpbnB1dCB0 eXBlPSJ0ZXh0IiBuYW1lPSJxIiBtYXhsZW5ndGg9IjE1MCIgVkNBUkRfTkFNRT0iU2VhcmNo VGV4dCIgY2xhc3M9InFmb3JtIiBzaXplPSIzMCIgdmFsdWU9IndhYWEiPjxpbWcgc3JjPSIv aW1hZ2VzL3NwYWNlci5naWYiIGhlaWdodD0iMSIgd2lkdGg9IjMiPjxpbnB1dCB0eXBlPSJp bWFnZSIgbmFtZT0ic3VibWl0YnV0dG9uIiBhbHQ9IldlYiDmpJzntKLjgpLplovlp4vjgZnj gosiIHNyYz0iLi9pbWFnZXMvc2VhcmNoYm94X2J0bi5naWYiIGJvcmRlcj0iMCIgd2lkdGg9 Ijc2IiBoZWlnaHQ9IjI3IiBhbGlnbj0iYWJzbWlkZGxlIiBvbm1vdXNlb3Zlcj0iY2hhbmdl U3VibWl0KCdzdWJtaXRidXR0b24nLCcuL2ltYWdlcy9zZWFyY2hib3hfYnRuLW92ZXIuZ2lm JykiIG9ubW91c2VvdXQ9ImNoYW5nZVN1Ym1pdCgnc3VibWl0YnV0dG9uJywnLi9pbWFnZXMv c2VhcmNoYm94X2J0bi5naWYnKSI+PC9ub2JyPjwvdGQ+PC90cj48L3RhYmxlPjxpbWcgc3Jj PSJpbWFnZXMvc3BhY2VyLmdpZiIgaGVpZ2h0PSI1IiB3aWR0aD0iNSIgeG1sbnM9IiI+PGJy IHhtbG5zPSIiPjxpbnB1dCB0eXBlPSJoaWRkZW4iIG5hbWU9Im9yaWdxIiB2YWx1ZT0iIiB4 bWxucz0iIj48aW5wdXQgdHlwZT0iaGlkZGVuIiBuYW1lPSJSUyIgdmFsdWU9IkNIRUNLRUQi IHhtbG5zPSIiPjxpbnB1dCB0eXBlPSJoaWRkZW4iIG5hbWU9IkZPUk0iIHZhbHVlPSJTTUNS QiIgeG1sbnM9IiI+PGlucHV0IHR5cGU9ImhpZGRlbiIgbmFtZT0idiIgdmFsdWU9IjEiIHht bG5zPSIiPjxpbnB1dCB0eXBlPSJoaWRkZW4iIG5hbWU9ImNmZyIgdmFsdWU9IlNNQ0lOSVRJ QUwiIHhtbG5zPSIiPjxpbnB1dCB0eXBlPSJoaWRkZW4iIG5hbWU9Im5vc3AiIHZhbHVlPSIi IHhtbG5zPSIiPjxpbnB1dCB0eXBlPSJoaWRkZW4iIG5hbWU9InRociIgdmFsdWU9IiIgeG1s bnM9IiI+PC9mb3JtPjwvdGQ+PHRkIHdpZHRoPSIxMCI+PGltZyBzcmM9ImltYWdlcy9zcGFj ZXIuZ2lmIiBoZWlnaHQ9IjIiIHdpZHRoPSIxMCI+PC9pbWc+PC90ZD48dGQgd2lkdGg9IjEy MCIgdmFsaWduPSJ0b3AiIGFsaWduPSJsZWZ0Ii8+PHRkIHdpZHRoPSIxMCI+PGltZyBzcmM9 ImltYWdlcy9zcGFjZXIuZ2lmIiBoZWlnaHQ9IjIiIHdpZHRoPSIxMCI+PC9pbWc+PC90ZD48 L3RyPjwvdGFibGU+PHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgYm9y ZGVyPSIwIiBzdHlsZT0idGFibGUtbGF5b3V0OmZpeGVkIiB3aWR0aD0iNjEwcHgiPjx0cj48 dGQ+PGltZyBzcmM9ImltYWdlcy9zcGFjZXIuZ2lmIiBoZWlnaHQ9IjIiIHdpZHRoPSIxMCI+ PC9pbWc+PC90ZD48L3RyPjx0cj48dGQgY2xhc3M9InRibEFjY2VudENvbG9yIj48aW1nIHNy Yz0iLi9pbWFnZXMvc3BhY2VyLmdpZiIgaGVpZ2h0PSIyIiB3aWR0aD0iMTAiPjwvaW1nPjwv dGQ+PC90cj48L3RhYmxlPjwvdGQ+PC90cj48L3RhYmxlPjwvdGQ+PHRkIHZhbGlnbj0idG9w IiB3aWR0aD0iMTYwcHgiIGNsYXNzPSJ0YmxTaWRlYmFyQ29sb3IiIGFsaWduPSJjZW50ZXIi Pjxicj48L2JyPjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu Zz0iMCIgeG1sbnM9IiI+PHRyPjx0ZCBiZ2NvbG9yPSIjRkZGRjk5Ij48dGFibGUgYm9yZGVy PSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjEiIGJnY29sb3I9IiNGRkZGOTki Pjx0cj48dGQgYmdjb2xvcj0iI0ZGRkY5OSI+PHRhYmxlIGJvcmVkZXI9IjAiIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9IjEyMyIgaGVpZ2h0PSIzMCIgYmdjb2xv cj0iI0ZGRkY5OSI+PHRyPjx0ZD48Y2VudGVyPjxhIGhyZWY9Imh0dHA6Ly9nLm1zbi5jb20v MEFESi8xMjMzODcuMT8/VUlUPSZhbXA7VGFyZ2V0SUQ9MjQ2MDcmYW1wO0N0eElEPTImYW1w O1BJRD0yNzMwOTEmYW1wO0FOPTE3NjMiID48aW1nIHNyYz0iaHR0cDovL2Fkcy5tc24uY29t L2Fkcy9KUE1CUEsvMDAzMzhKTzAxMjZfWFkuZ2lmIiBhbHQ9IkNsaWNrIGhlcmUhIiAgIGJv cmRlcj0iMCIgPjwvYT48L2NlbnRlcj48L3RkPjwvdHI+PHRyPjx0ZCB2YWxpZ249Im1pZGRs ZSIgYWxpZ249ImNlbnRlciI+PGEgY2xhc3M9ImNsc0xlZnROYXZBZCIgaHJlZj0iaHR0cDov L2Fkcy5qcC5tc24uY29tL2Fkcy9hZHJlZGlyLmFzcD9pbWFnZT0vYWRzL0pQTUJLSC8wMDQ5 MDgyNjAwMDVfVFIuZ2lmJmFtcDt1cmw9aHR0cDovL3d3dy5hbWF6b24uY28uanAvZXhlYy9v Ymlkb3MvcmVkaXJlY3QtaG9tZSUzRnRhZyUzRG1zbi1qcC1zZWFyY2gwMDItMjIlMjZzaXRl JTNEYW1hem9uIj7mnKzjg7vmtIvmm7jjg7tDROODu0RWRDxicj7jg5Pjg4fjgqrjg7vvvLTv vLbjgrLjg7zjg6A8YnI+PC9hPjwvdGQ+PC90cj48dHI+PHRkIHZhbGlnbj0ibWlkZGxlIiBh bGlnbj0iY2VudGVyIj48c3BhbiBjbGFzcz0iY2xzTGVmdE5hdkFkTGlua1Rlcm0iPjxhIGNs YXNzPSJjbHNMZWZ0TmF2QWRMaW5rVGVybSIgaHJlZj0iL2FkcGFzc3RocnUuYXNwP1RBUkdF VD1odHRwOi8vd3d3LmFtYXpvbi5jby5qcC9leGVjL29iaWRvcy9leHRlcm5hbC1zZWFyY2gl M0Z0YWclM0Rtc24tanAtc2VhcmNoMDAzLTIyJTI2bW9kZSUzRGJsZW5kZWQlMjZmaWVsZC1r ZXl3b3JkcyUzRCZhbXA7QURUQVJHRVQ9aHR0cDovL2Fkcy5qcC5tc24uY29tL2Fkcy9hZHJl ZGlyLmFzcCUzRiZhbXA7SU1HPWh0dHA6Ly9hZHMuanAubXNuLmNvbS9hZHMvSlBNQktILzAw NDkwODI2MDAwMl9UUi5naWYmYW1wO1FVRVJZPXdhYWEiPiJ3YWFhIjwvYT48L3NwYW4+PC90 ZD48L3RyPjx0cj48dGQgdmFsaWduPSJtaWRkbGUiIGFsaWduPSJjZW50ZXIiPjxhIGNsYXNz PSJjbHNMZWZ0TmF2TWluaUFkIiBocmVmPSJodHRwOi8vYWRzLmpwLm1zbi5jb20vYWRzL2Fk cmVkaXIuYXNwP2ltYWdlPS9hZHMvSlBNQktILzAwNDkwODI2MDAwNl9UUi5naWYmYW1wO3Vy bD1odHRwOi8vd3d3LmFtYXpvbi5jby5qcC9leGVjL29iaWRvcy9yZWRpcmVjdC1ob21lJTNG dGFnJTNEbXNuLWpwLXNlYXJjaDAwNC0yMiUyNnNpdGUlM0RhbWF6b24iPue3j+aVsDM1MOS4 h+OCv+OCpOODiOODqzxicj48L2E+PC90ZD48L3RyPjwvdGFibGU+PC90ZD48L3RyPjwvdGFi bGU+PC90ZD48L3RyPjwvdGFibGU+PGJyPjwvYnI+PHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBh ZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB4bWxucz0iIj48dHI+PHRkIGJnY29sb3I9IiNG RjFBOEMiPjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0i MSIgYmdjb2xvcj0iI0ZGMUE4QyI+PHRyPjx0ZCBiZ2NvbG9yPSIjRkYxQThDIj48dGFibGUg Ym9yZWRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiB3aWR0aD0iMTIz IiBoZWlnaHQ9IjMwIiBiZ2NvbG9yPSIjRkYxQThDIj48dHI+PHRkPjxjZW50ZXI+PGEgaHJl Zj0iaHR0cDovL2dvLmpwLm1zbi5jb20vc2VhcmNoLmFzcD9nPTEwMDgmYW1wO3Q9aHR0cDov L3d3dy5obXYuY28uanAvIj48aW1nIHNyYz0iL2ltYWdlcy9MTk1pbmlBZDIuZ2lmIiBhbHQ9 IiIgYm9yZGVyPSIwIj48L2E+PC9jZW50ZXI+PC90ZD48L3RyPjx0cj48dGQgdmFsaWduPSJt aWRkbGUiIGFsaWduPSJjZW50ZXIiPjxhIGNsYXNzPSJjbHNMZWZ0TmF2QWQiIGhyZWY9Imh0 dHA6Ly9nby5qcC5tc24uY29tL3NlYXJjaC5hc3A/Zz0xMDA5JmFtcDt0PWh0dHA6Ly93d3cu aG12LmNvLmpwL211LyI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPkNE44KS5o6i44Gd44GG77yB PC9mb250PjwvYT48YnI+PC90ZD48L3RyPjx0cj48dGQgdmFsaWduPSJtaWRkbGUiIGFsaWdu PSJjZW50ZXIiPjxzcGFuIGNsYXNzPSJjbHNMZWZ0TmF2QWRMaW5rVGVybSI+PGEgY2xhc3M9 ImNsc0xlZnROYXZBZExpbmtUZXJtIiBocmVmPSJodHRwOi8vZ28uanAubXNuLmNvbS9zZWFy Y2hVVEY4LmFzcD9nPTEwMTAmYW1wO3Q9aHR0cDovL3d3dy5obXYuY28uanAvc2VhcmNoL2Fy dGlzdC5hc3AlM0ZjYXRlZ29yeT1BUlRJU1RTJTI2a2V5d29yZD13YWFhIj48Zm9udCBjb2xv cj0iIzAwMDBGRiI+IndhYWEiPC9mb250PjwvYT48L3NwYW4+PC90ZD48L3RyPjx0cj48dGQg dmFsaWduPSJtaWRkbGUiIGFsaWduPSJjZW50ZXIiPjxhIGNsYXNzPSJjbHNMZWZ0TmF2TWlu aUFkIiBocmVmPSJodHRwOi8vZ28uanAubXNuLmNvbS9zZWFyY2guYXNwP2c9MTAxMSZhbXA7 dD1odHRwOi8vd3d3Lmhtdi5jby5qcC9tby8iPjxmb250IGNvbG9yPSIjMDAwMDAwIj5EVkTj gpLmjqLjgZ3jgYbvvIE8L2ZvbnQ+PC9hPjxicj48L3RkPjwvdHI+PC90YWJsZT48L3RkPjwv dHI+PC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT48YnI+PC9icj48YSBocmVmPSJodHRwOi8v Zy5tc24uY29tLzBBREovMTU0NTEuMT8/VUlUPSZhbXA7VGFyZ2V0SUQ9MjQ2MjQmYW1wO0N0 eElEPTImYW1wO1BJRD05OTc3MCZhbXA7QU49MzIyNzAiID48aW1nIHNyYz0iaHR0cDovL2Fk cy5tc24uY29tL2Fkcy9KUE1DU1IvMDAzMzhKUDAxMTRfUzQuZ2lmIiBhbHQ9Ik1TTiBNb25l eSIgICBib3JkZXI9IjAiID48L2E+PC90ZD48L3RyPjwvdGFibGU+PHRhYmxlIGNlbGxwYWRk aW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgYm9yZGVyPSIwIiBzdHlsZT0idGFibGUtbGF5b3V0 OmZpeGVkIiB3aWR0aD0iNzcwcHgiIGNsYXNzPSJ0YmxTaGVsbENvbG9yIj48dHI+PHRkIHZh bGlnbj0idG9wIiB3aWR0aD0iNzU0Ij48dGFibGUgYm9yZGVyPSIwIiB3aWR0aD0iNjEwIiBj bGFzcz0idGJsU2hlbGxDb2xvciIgeG1sbnM9IiI+PHRyPjx0ZCB3aWR0aD0iNSI+PGltZyBz cmM9Ii4vaW1hZ2VzL3NwYWNlci5naWYiIHdpZHRoPSI1IiBib3JkZXI9IjAiPjwvdGQ+PHRk IHdpZHRoPSIxMDAlIiB2YWxpZ249ImJvdHRvbSI+PHNwYW4gY2xhc3M9ImxvZ290ZXh0Ij5N U04gLSBNb3JlIFVzZWZ1bCBFdmVyeWRheTwvc3Bhbj48L3RkPjwvdHI+PC90YWJsZT48dGFi bGUgY2VsbHBhZGRpbmc9IjgiIGNlbGxzcGFjaW5nPSIwIiBib3JkZXI9IjAiIHdpZHRoPSIx MDAlIiBjbGFzcz0idGJsU2hlbGxDb2xvciIgeG1sbnM9IiI+PHRyPjx0ZD48aW1nIHNyYz0i Li9pbWFnZXMvc3BhY2VyLmdpZiIgd2lkdGg9IjUiIGFsaWduPSJtaWRkbGUiPjxhIGhyZWY9 Imh0dHA6Ly9nby5qcC5tc24uY29tL3NlYXJjaC5hc3A/Zz0yMDkmYW1wO3Q9d3d3KiIgY2xh c3M9ImJpZzdMaW5rcyI+44Ob44O844OgPC9hPjxpbWcgc3JjPSIuL2ltYWdlcy9zcGFjZXIu Z2lmIiBoZWlnaHQ9IjEzIiB3aWR0aD0iNSI+PGltZyBzcmM9Ii4vaW1hZ2VzL21lbnVfZGl2 LmdpZiIgYWxpZ249Im1pZGRsZSI+PGltZyBzcmM9Ii4vaW1hZ2VzL3NwYWNlci5naWYiIHdp ZHRoPSI1IiBoZWlnaHQ9IjEzIj48YSBocmVmPSJodHRwOi8vZ28uanAubXNuLmNvbS9zZWFy Y2guYXNwP2c9MjEwJmFtcDt0PXd3dy5ob3RtYWlsLmNvbS9KQS8iIGNsYXNzPSJiaWc3TGlu a3MiPuODoeODvOODqzwvYT48aW1nIHNyYz0iLi9pbWFnZXMvc3BhY2VyLmdpZiIgaGVpZ2h0 PSIxMyIgd2lkdGg9IjUiPjxpbWcgc3JjPSIuL2ltYWdlcy9tZW51X2Rpdi5naWYiIGFsaWdu PSJtaWRkbGUiPjxpbWcgc3JjPSIuL2ltYWdlcy9zcGFjZXIuZ2lmIiB3aWR0aD0iNSIgaGVp Z2h0PSIxMyI+PGEgaHJlZj0iIiBjbGFzcz0iYmlnN0FjY2VudExpbmtzIj7jgrXjg7zjg4E8 L2E+PGltZyBzcmM9Ii4vaW1hZ2VzL3NwYWNlci5naWYiIGhlaWdodD0iMTMiIHdpZHRoPSI1 Ij48aW1nIHNyYz0iLi9pbWFnZXMvbWVudV9kaXYuZ2lmIiBhbGlnbj0ibWlkZGxlIj48aW1n IHNyYz0iLi9pbWFnZXMvc3BhY2VyLmdpZiIgd2lkdGg9IjUiIGhlaWdodD0iMTMiPjxhIGhy ZWY9Imh0dHA6Ly9nby5qcC5tc24uY29tL3NlYXJjaC5hc3A/Zz0yMTImYW1wO3Q9bmV3cyoi IGNsYXNzPSJiaWc3TGlua3MiPuODi+ODpeODvOOCuTwvYT48aW1nIHNyYz0iLi9pbWFnZXMv c3BhY2VyLmdpZiIgaGVpZ2h0PSIxMyIgd2lkdGg9IjUiPjxpbWcgc3JjPSIuL2ltYWdlcy9t ZW51X2Rpdi5naWYiIGFsaWduPSJtaWRkbGUiPjxpbWcgc3JjPSIuL2ltYWdlcy9zcGFjZXIu Z2lmIiB3aWR0aD0iNSIgaGVpZ2h0PSIxMyI+PGEgaHJlZj0iaHR0cDovL2dvLmpwLm1zbi5j b20vc2VhcmNoLmFzcD9nPTIxMyZhbXA7dD1zaG9wcGluZyoiIGNsYXNzPSJiaWc3TGlua3Mi PuOCt+ODp+ODg+ODlOODs+OCsDwvYT48aW1nIHNyYz0iLi9pbWFnZXMvc3BhY2VyLmdpZiIg aGVpZ2h0PSIxMyIgd2lkdGg9IjUiPjxpbWcgc3JjPSIuL2ltYWdlcy9tZW51X2Rpdi5naWYi IGFsaWduPSJtaWRkbGUiPjxpbWcgc3JjPSIuL2ltYWdlcy9zcGFjZXIuZ2lmIiB3aWR0aD0i NSIgaGVpZ2h0PSIxMyI+PGEgaHJlZj0iaHR0cDovL2dvLmpwLm1zbi5jb20vc2VhcmNoLmFz cD9nPTIxNCZhbXA7dD1tb25leSoiIGNsYXNzPSJiaWc3TGlua3MiPuODnuODjeODvDwvYT48 L3RkPjwvdHI+PC90YWJsZT48dGFibGUgYm9yZGVyPSIwIiB3aWR0aD0iNjA4IiBjbGFzcz0i dGJsU2hlbGxDb2xvciIgeG1sbnM9IiI+PHRyPjx0ZCB3aWR0aD0iNCI+PGltZyBzcmM9Ii4v aW1hZ2VzL3NwYWNlci5naWYiIHdpZHRoPSI0IiBib3JkZXI9IjAiPjwvdGQ+PHRkPjxzcGFu IGNsYXNzPSJjb3B5cmlnaHQiPiZjb3B5OzIwMDIgTWljcm9zb2Z0IENvcnBvcmF0aW9uLiBB bGwgcmlnaHRzIHJlc2VydmVkLjwvc3Bhbj48aW1nIHNyYz0iaW1hZ2VzL3NwYWNlci5naWYi IHdpZHRoPSIxMCIgaGVpZ2h0PSIwIiBib3JkZXI9IjAiPjxhIGhyZWY9Imh0dHA6Ly9nLm1z bi5jby5qcC8wVE9fL2phanA/P1BJPTQwNDM4JmFtcDtEST0yNTMiIGNsYXNzPSJjb3B5cmln aHRsaW5rIj7kvb/nlKjmnaHku7Y8L2E+PGltZyBzcmM9ImltYWdlcy9zcGFjZXIuZ2lmIiB3 aWR0aD0iNyIgaGVpZ2h0PSIwIiBib3JkZXI9IjAiPjxhIGhyZWY9Imh0dHA6Ly9nLm1zbi5j by5qcC8wUFJfL2phanA/P1BJPTQwNDM4JmFtcDtEST0yNTMiIGNsYXNzPSJjb3B5cmlnaHRs aW5rIj7jg5fjg6njgqTjg5Djgrfjg7w8L2E+PC90ZD48L3RyPjwvdGFibGU+PC90ZD48L3Ry Pjx0cj48dGQgYWxpZ249InJpZ2h0IiB3aWR0aD0iMTAwJSI+PGltZyBzcmM9ImltYWdlcy9j b3JuZXJfbHJnMi5naWYiIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiI+PC9pbWc+PC90ZD48L3Ry PjwvdGFibGU+PC9ib2R5PjwvaHRtbD=9 --U8N2WcVUp3AWGDo58k8jpvT3fPC135-- From owner-ietf-smime@mail.imc.org Tue Feb 11 23:00:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27627 for ; Tue, 11 Feb 2003 23:00:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1C3YtR25931 for ietf-smime-bks; Tue, 11 Feb 2003 19:34:55 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C3YCd25902 for ; Tue, 11 Feb 2003 19:34:54 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26725; Tue, 11 Feb 2003 22:30:32 -0500 (EST) Message-Id: <200302120330.WAA26725@ietf.org> To: IETF-Announce: ; Cc: ietf-smime@imc.org From: The IESG SUBJECT: Last Call: Use of the AES Encryption Algorithm in CMS to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 11 Feb 2003 22:30:32 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security Working Group to consider Use of the AES Encryption Algorithm in CMS as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-25. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-06.txt From owner-ietf-smime@mail.imc.org Thu Feb 13 04:52:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08204 for ; Thu, 13 Feb 2003 04:52:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1D9PSq17053 for ietf-smime-bks; Thu, 13 Feb 2003 01:25:28 -0800 (PST) Received: from linux.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D9OCd17015 for ; Thu, 13 Feb 2003 01:24:12 -0800 (PST) Received: from remus.intranet.secude.com (remus.intranet.secude.com [192.168.2.2]) by linux.secude.com (Postfix) with ESMTP id 42EA4B564; Thu, 13 Feb 2003 10:24:11 +0100 (CET) Received: from secude.com (pc-yameogo.intranet.secude.com [192.168.3.51]) by remus.intranet.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Z3LLM93X; Thu, 13 Feb 2003 10:26:51 +0100 Message-ID: <3E4B64F6.334CFFA3@secude.com> Date: Thu, 13 Feb 2003 10:27:18 +0100 From: Petra Barzin X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Denis.Pinkas@bull.net Cc: ietf-smime@imc.org, Stephan Klein , pope@secstan.com Subject: mistake in RFC 3126 Content-Type: multipart/mixed; boundary="------------ED2A3168A497312B1CC7A265" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------ED2A3168A497312B1CC7A265 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I think there is a mistake in RFC 3126 - Electronic Signature Formats for long term electronic signatures. The definition of the RevocationValues attribute is as follows: RevocationValues ::= SEQUENCE { crlVals [0] SEQUENCE OF CertificateList OPTIONAL, ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, otherRevVals [2] OtherRevVals } Shouldn't the other revocation values be optional as well? Did I miss something or am I right? Best regards - Petra Barzin --------------ED2A3168A497312B1CC7A265 Content-Type: text/x-vcard; charset=us-ascii; name="barzin.vcf" Content-Description: Card for Petra Barzin Content-Disposition: attachment; filename="barzin.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Barzin;Petra tel;fax:+49 61 51-8 28 97-26 tel;work:+49 61 51-8 28 97-30 x-mozilla-html:FALSE url:http://www.secude.com org:SECUDE GmbH adr:;;Dolivostr. 11;Darmstadt;;64293 ;Deutschland version:2.1 email;internet:barzin@secude.com fn:Petra Barzin end:vcard --------------ED2A3168A497312B1CC7A265-- From owner-ietf-smime@mail.imc.org Thu Feb 13 13:22:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20932 for ; Thu, 13 Feb 2003 13:22:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DI1ta18953 for ietf-smime-bks; Thu, 13 Feb 2003 10:01:55 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DI1sd18948 for ; Thu, 13 Feb 2003 10:01:54 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20172; Thu, 13 Feb 2003 12:58:11 -0500 (EST) Message-Id: <200302131758.MAA20172@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-hmac-key-wrap-01.txt Date: Thu, 13 Feb 2003 12:58:11 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Wrapping an HMAC key with a Triple-DES Key or an AES Key Author(s) : J. Schaad, R. Housley Filename : draft-ietf-smime-hmac-key-wrap-01.txt Pages : 8 Date : 2003-2-12 The key wrap algorithms defined in [3DES-WRAP] and [AES-WRAP] cover the of wrapping a Triple-DES key with another Triple-DES key and wrapping an AES key with another AES key, respectively. This document specifies two similar mechanisms. One specifies the mechanism for wrapping an HMAC key with a Triple-DES key, and the other specifies the mechanism for wrapping an HMAC key with an AES key. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-hmac-key-wrap-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-hmac-key-wrap-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-hmac-key-wrap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-13131713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-hmac-key-wrap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-hmac-key-wrap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-13131713.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Thu Feb 13 18:32:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19844 for ; Thu, 13 Feb 2003 18:32:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DNGJc29597 for ietf-smime-bks; Thu, 13 Feb 2003 15:16:19 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1DNGId29593 for ; Thu, 13 Feb 2003 15:16:18 -0800 (PST) Received: (qmail 13145 invoked from network); 13 Feb 2003 23:16:12 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.161.174) by woodstock.binhost.com with SMTP; 13 Feb 2003 23:16:12 -0000 Message-Id: <5.2.0.9.2.20030213120327.02fbcc40@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 18:16:11 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Overhead Projectors at the IETF meeting in San Francisco Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear S/MIME participants: Starting with the IETF meeting in San Francisco, overhead projectors will not be provided in the meeting rooms unless specifically requested. Data projectors will be in all working group and BOF meeting rooms. If you feel there is a need for an overhead projector in our session, please send me a note immediately. Thanks, Russ From owner-ietf-smime@mail.imc.org Fri Feb 14 14:05:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01441 for ; Fri, 14 Feb 2003 14:05:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EIp7U15702 for ietf-smime-bks; Fri, 14 Feb 2003 10:51:07 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1EIp6d15698 for ; Fri, 14 Feb 2003 10:51:06 -0800 (PST) Received: (qmail 21647 invoked from network); 14 Feb 2003 18:50:59 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.180.81) by woodstock.binhost.com with SMTP; 14 Feb 2003 18:50:59 -0000 Message-Id: <5.2.0.9.2.20030214135028.03808480@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Feb 2003 13:50:51 -0500 To: Petra Barzin , Denis.Pinkas@bull.net From: Russ Housley Subject: Re: mistake in RFC 3126 Cc: ietf-smime@imc.org, Stephan Klein , pope@secstan.com In-Reply-To: <3E4B64F6.334CFFA3@secude.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This definitely looks like an error to me. Russ At 10:27 AM 2/13/2003 +0100, Petra Barzin wrote: >Hello, > >I think there is a mistake in RFC 3126 - Electronic Signature >Formats for long term electronic signatures. The definition of the >RevocationValues attribute is as follows: > > RevocationValues ::= SEQUENCE { > crlVals [0] SEQUENCE OF CertificateList OPTIONAL, > ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, > otherRevVals [2] OtherRevVals > } > >Shouldn't the other revocation values be optional as well? >Did I miss something or am I right? > >Best regards - Petra Barzin > > > From owner-ietf-smime@mail.imc.org Fri Feb 14 14:26:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01925 for ; Fri, 14 Feb 2003 14:26:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EJGWB16669 for ietf-smime-bks; Fri, 14 Feb 2003 11:16:32 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1EJGVd16665 for ; Fri, 14 Feb 2003 11:16:31 -0800 (PST) Received: (qmail 22980 invoked from network); 14 Feb 2003 19:16:25 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.175.84) by woodstock.binhost.com with SMTP; 14 Feb 2003 19:16:25 -0000 Message-Id: <5.2.0.9.2.20030214141338.0381c130@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Feb 2003 14:16:31 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: draft-housley-cms-fw-wrap-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear S/MIME WG: Since the vast majority of CMS experience exists in the S/MIME working group, I want to make people aware of this Internet-Draft. I would greatly appreciate review and constructive comment. Also, I would like to assign the needed OIDs from the S/MIME working group arc. Does anyone see any reason for them to be assigned elsewhere? Russ From owner-ietf-smime@mail.imc.org Fri Feb 14 16:45:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05991 for ; Fri, 14 Feb 2003 16:45:51 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ELUes22662 for ietf-smime-bks; Fri, 14 Feb 2003 13:30:40 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ELUcd22657 for ; Fri, 14 Feb 2003 13:30:38 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05443; Fri, 14 Feb 2003 16:26:49 -0500 (EST) Message-Id: <200302142126.QAA05443@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ietf-smime@imc.org From: The IESG Subject: Protocol Action: CMS Symmetric Key Management and Distribution to Proposed Standard Date: Fri, 14 Feb 2003 16:26:49 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'CMS Symmetric Key Management and Distribution' as a Proposed Standard. This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Jeffrey Schiller and Steve Bellovin. Technical Summary This document extends the Cryptographic Message Syntax (CMS) to support the use of symmetric (traditional) encryption in addition to public key encryption. It describes an architecture that can be used by Groups of entities (or Mailing Lists) to securely distribute a Group Key which can be used to symmetrically encrypt CMS objects. Working Group Summary The working group had consensus on this document. Protocol Quality This document has been reviewed for the IESG by Jeff Schiller. From owner-ietf-smime@mail.imc.org Sat Feb 15 11:45:12 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04792 for ; Sat, 15 Feb 2003 11:45:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1FGHKI25831 for ietf-smime-bks; Sat, 15 Feb 2003 08:17:20 -0800 (PST) Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1FGHId25827 for ; Sat, 15 Feb 2003 08:17:19 -0800 (PST) Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h1FGHF2n012817 for ; Sat, 15 Feb 2003 17:17:15 +0100 (CET) X-Original-Recipient: Message-ID: <00b601c2d50c$4d4d7180$0500a8c0@arport> From: "Anders Rundgren" To: Subject: e-Gov: Distributing confidential information Date: Sat, 15 Feb 2003 17:07:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here are some thoughts regarding how e-governments (and companies) could efficiently distribute confidential information to citizens (or employees). Note: The following discussion only applies to information from an (non-personal) authority to an individual. Claim ------- In spite of being the foundation for many PKI-based ID-programs, I doubt that S/MIME will play any major role in e-government systems as these typically are built as on-line (web-based) services. The problem -------------- Now, in case a government authority is to send you confidential information, I believe they should not use encrypted mail as this will most likely lead to huge support problems with key- distribution, key-expiration etc. A simple remedy --------------------- e-Governments could preferably e-mail the recipient a web-link (or just a notification) that he or she uses to fetch the confidential information with. That is, after the recipient have authenticated to the on-line authority. This scheme is also aligned with an "account-based" authority where you may have tasks in various stages. The "web-way" allowed on-line banks to address the ordinary consumer and is proven to work on a major scale, while signed and encrypted mail is after more than ten years, still very sparsely used. My 2 cents. Anders Rundgren Consultant, PKI and secure e-business +46 70 - 627 74 37 From owner-ietf-smime@mail.imc.org Mon Feb 17 11:45:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25524 for ; Mon, 17 Feb 2003 11:45:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HGOj529738 for ietf-smime-bks; Mon, 17 Feb 2003 08:24:45 -0800 (PST) Received: from mail3.consignia.com (mail.royalmail.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HGOid29734 for ; Mon, 17 Feb 2003 08:24:44 -0800 (PST) Received: from postoffice.co.uk (unknown [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id CED4518FA5D for ; Mon, 17 Feb 2003 16:25:07 +0000 (GMT) Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 00256CD0.005A2DE1 ; Mon, 17 Feb 2003 16:24:59 +0000 X-Lotus-FromDomain: POSTOFFICE From: chris.gilbert@royalmail.com To: ietf-smime@imc.org Message-ID: <00256CD0.005A2B79.00@postoffice.co.uk> Date: Mon, 17 Feb 2003 16:24:33 +0000 Subject: SMIME and disclaimers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, I don't imagine for a moment that we're the only ones looking at this issue. Discounting whether disclaimers carry any worthwhile legal weight, technically is it feasible to add a disclaimer to outgoing SMIME messages at the outgoing server without breaking the signature ? The multipart nature of MIME suggests that it is at least plausible to place the disclaimer in its own MIME boundary such that it doesn't interfere with signed portions in the parts of the message that originate at the client. Opinions appreciated. Chris Royal Mail is a trading name of Royal Mail Group plc. Registered in England and Wales. Registered number 4138203. Registered office at 148 Old Street, LONDON EC1V 9HQ This email and any attachments are confidential and intended for the addressee only. If you are not the named recipient, you must not use, disclose, reproduce, copy or distribute the contents of this communication. If you have received this in error, please contact the sender and then delete this email from your system. From owner-ietf-smime@mail.imc.org Mon Feb 17 14:02:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28493 for ; Mon, 17 Feb 2003 14:02:49 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HIlqb04521 for ietf-smime-bks; Mon, 17 Feb 2003 10:47:52 -0800 (PST) Received: from mail.epost.de (mail.epost.de [193.28.100.164] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HIlod04516 for ; Mon, 17 Feb 2003 10:47:50 -0800 (PST) Received: from [129.70.36.57] (129.70.36.57) by mail.epost.de (6.7.015) (authenticated as Marc.Mutz@epost.de) id 3E41A7C7001379CA; Mon, 17 Feb 2003 19:47:49 +0100 From: Marc Mutz Organization: "Old Europe" - and proud To: ietf-smime@imc.org Subject: [ot] Re: SMIME and disclaimers Date: Mon, 17 Feb 2003 19:19:02 +0100 User-Agent: KMail/1.5.9 References: <00256CD0.005A2B79.00@postoffice.co.uk> In-Reply-To: <00256CD0.005A2B79.00@postoffice.co.uk> Cc: chris.gilbert@royalmail.com X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_peSU+5FCL1AaNkO"; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200302171919.21899@sendmail.mutz.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary-02=_peSU+5FCL1AaNkO Content-Type: text/plain; charset="us-ascii" Content-Description: signed data Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Monday 17 February 2003 17:24, chris.gilbert@royalmail.com wrote: > The multipart nature of MIME suggests > that it is at least plausible to place the disclaimer in its own MIME > boundary such that it doesn't interfere with signed portions in the > parts of the message that originate at the client. The application adding the disclaimer needs to be fully MIME-aware and=20 needs to be able to re-arrange the MIME body parts if necessary. Just=20 appending the disclaimer in plain text, US-ASCII form works only for=20 messages with text/plain top-level content-type and a charset that=20 contains US-ASCII as a subset (e.g. iso-8859-*, utf-8). A more intelligent approach would be to find the last MIME boundary,=20 remove everything after and including the trailing double hyphen, and=20 add something like: Content-Type: text/plain; charset=3Dus-ascii Content-disposition: inline =2D-boundary-- but that fails for multiparts with a fixed number of required children,=20 e.g. multipart/signed, which needs to have exactly two children. =46or coping with these messages, you have three options: 1. Lock down the signature (not the digital signature, but the message footer) to use for your users, if your mailer supports that (e.g. KMail does), so it includes the disclaimer and cannot be changed by the user. 2. Use an application that is dumb and just appends the disclaimer as text, like e.g. mailman does. Then you have to hope that all the recipients use MUAs that show the epilogue of mails if it looks interesting. Don't hold your breath... 3. Use an intelligent application to append the disclaimer, one that can re-arrange the MIME body structure to fold the current content into an additional multipart/mixed if needed to append the text/plain disclaimer and hope that recipient's clients can cope with deeply nested MIME body structures. I guess your best bet is to look up the admin's handbook of your users'=20 MUAs and see if (1) is an option. Marc =2D-=20 "You're hackers, aren't you," the barman said, eyeing us. No one said a thing. The darkness of the Eurotunnel rolled by. Apparently we'd given ourselves away by talking too enthusiastically about IPv6. He looked around conspiratorially, lowered his voice. "Can you get me some credit card numbers?" -- James J. King "What's the shortest way to hack a Linux box?" Telepolis 2001/08/11 (#9293) --Boundary-02=_peSU+5FCL1AaNkO Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+USep3oWD+L2/6DgRAqJRAJ9vn2bT2PI2v3nWhas0LxpJBSz85gCgqnNR odTFvFzt7pfOzQqMMFlRaBY= =A3MN -----END PGP SIGNATURE----- --Boundary-02=_peSU+5FCL1AaNkO-- From owner-ietf-smime@mail.imc.org Tue Feb 18 06:09:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25221 for ; Tue, 18 Feb 2003 06:09:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1IAo7N27808 for ietf-smime-bks; Tue, 18 Feb 2003 02:50:07 -0800 (PST) Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IAo5d27804 for ; Tue, 18 Feb 2003 02:50:05 -0800 (PST) Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id EAA25369 for ; Sun, 23 Feb 2003 04:34:16 +0100 Received: from authentidate.de (input.authentidate.de [192.168.42.73]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h1IAnx912530; Tue, 18 Feb 2003 11:49:59 +0100 X-Authentication-Warning: gate.wisnet.de: Host input.authentidate.de [192.168.42.73] claimed to be authentidate.de Message-ID: <3E520FE7.5070805@authentidate.de> Date: Tue, 18 Feb 2003 11:50:15 +0100 From: Holger Ebel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org CC: Holger Ebel Subject: signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit [I accidentally posted this (somewhat different) message to the pkix list, apologize for that. After some direct replies I've modified some parts of my original post] Hello, after working through these specs and decoding many example signatures I still have the following questions regarding the meaning of the signatureAlgorithm/digestEncryptionAlgorithm in these standards mentioned above. (To be more precise, the appearance of these in the SignerInfo structure of the SignedData contentType) If this topic does not belong to this list, it would be nice if someone can point me at the responsible mailing list. Please note that I use the term signatureAlgorithm for the combination of a digest and a digestEncryption algorithm in the following mail. With respect, I would like to summarize first how I get these standards. - PKCS#7 - PKCS#7 1.5 (RFC 2315) clearly distinguishes between a digestAlgorithm and a digestEncryptionAlgorithm. So if the signatureAlgorithm is md5WithRSAEncryption (1.2.840.113549.1.1.4), the digestAlgorithm is md5 (1.2.840.113549.2.5) and the digestEncryptionAlgorithm is RSA (1.2.840.113549.1.1.1). Or if the signatureAlgorithm is sha1WithRSAEncryption (1.2.840.113549.1.1.5), the digestAlgorithm is sha1 (1.3.14.3.2.26) and the digestEncryptionAlgorithm is again RSA (1.2.840.113549.1.1.1). (The same for RipeMD160WithRsaEncryption (1.3.36.3.3.1.2)) Although 'only' RSA is mentioned in PKCS7 directly as a digest- EncryptionAlgorithm, I assume that this rules also apply for other 'encryptionAlgorithm's. All the PKCS#7 'samples' I've found strictly follows these rules, there is always a digest and a digestEncryption algorithm. - CMS (2630) - CMS (RFC 2630) introduced the term signatureAlgorithm in the SignerInfo structure, which has 'replaced' the digestEncryptionAlgorithm of PKCS#7 while the digestAlgorithm field still remains. If a signatureAlgorithm is used to create the signature whose cipher is using the RSA algorithm, the 'old' RSA OID 1.2.840.113549.1.1.1 must be used in the 'signatureAlgorithm' field. (12.2.2) The digestAlgorithm field contains then the corresponding digest Oid, eg. SHA-1, MDx or RipeMD160. The usage of the signatureAlgorithmOids sha1WithRSAEncryption, md5WithRSAEncryption or ripeMD160WithRsaEncryption is not allowed in 2630, the above mentioned schema must be used. When using a signatureAlgorithm which has another cipher - like DSA or ECDSA - the 'splitting' into a digest and a cipher algorithm is not allowed, the signatureAlgorithmOid must be used. (e.g. sha1WithDSA (1.2.840.10040.4.3)) and the digestAlgorithm field must contain the digestAlgo 'included' in the signatureAlgo. Restrictions for the usage of other signatureAlgoritms may be defined in other RFCs (like 3278). - CMS (3369/70) This successor of 2630 (more precise CMSALG) also allows the usage of the signatureAlgorithmOID when a RSA cipher is used for the signature process, which was/is not allowed in 2630. (sha1WithRSAEncryption, md5WithRSAEncryption or ripeMD160WithRsaEncryption). For backward compatibility, the 2630 schema (RSA) is also allowed here for the MD5 and SHA-1 digests. Now my questions: (1) Did I get the standard mentioned above right regarding the signatureAlgo/digestEncryptionAlgorithm? (2) How should I handle a CMS (2630/3369) signature where the value of the digestAlgorithm does not match the 'included' digestAlgorithm in the signatureAlgorithm field. (e.g. having a RIPEMD160 digestAlgo OID at the digestInfo field and a Sha1WithDSA OID in the signature- algorithm field). (3) When a component claims that it can produce valid RFC 2630 signatures, is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 the only exception from the rule? Is the usage of the 'other' RSA signature OIDs (sha1WithRSAEncryption) really forbidden in 2630? (4) Having the following signatureAlgorithms, is the usage of these for PKCS#7/RFC 2630/RFC 3369 signatures allowed and correct? (having valid signatures according the corresponding standard) --------------------------------------------------------------------------- SignatureAlgorithm digestAlgo (I) digestEncrAlgo(PKCS#7) (II) signatureAlgo (RFC 2630) (III) signatureAlgo (RFC 3369) --------------------------------------------------------------------------- (A) sha1WithRSA 1.3.14.3.2.26 (I) 1.2.840.113549.1.1.1 (1.2.840.113549.1.1.5) (II) 1.2.840.113549.1.1.1 (IIIa) 1.2.840.113549.1.1.1 (IIIb) 1.2.840.113549.1.1.5 (B) md5WithRSA 1.2.840.1x9.2.5 (I) 1.2.840.113549.1.1.1 (1.2.840.113549.1.1.4) (II) 1.2.840.113549.1.1.1 (IIIa) 1.2.840.113549.1.1.1 (IIIb) 1.2.840.113549.1.1.4 (D) sha1WithDsa 1.3.14.3.2.26 (I) 1.2.840.10040.4.1 (1.2.840.10040.4.3) (II) 1.2.840.10040.4.3 (III) 1.2.840.10040.4.3 --------------------------------------------------------------------------- (5) Or is the signatureAlgorithm check performed this way (for 2630/3369): If the signatureAlgo field contains a digestEncryptionOID, the signatureAlgo is the digestEncryptionOID plus the digestOID. If the signatureAlgo field contains a signatureAlgo, the signatureAlgo equals the found signatureAlgo. The included digestAlgo is not observed/must be the same as the one which is contained in the signatureAlgo/...? Thanks in advance Best Regards Holger From owner-ietf-smime@mail.imc.org Wed Feb 19 19:01:54 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13237 for ; Wed, 19 Feb 2003 19:01:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JNiaM13501 for ietf-smime-bks; Wed, 19 Feb 2003 15:44:36 -0800 (PST) Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JNiZd13497 for ; Wed, 19 Feb 2003 15:44:35 -0800 (PST) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 19 Feb 2003 15:44:33 -0800 From: "Blake Ramsdell" To: Subject: Extended Key Usage extension and S/MIME Date: Wed, 19 Feb 2003 15:44:33 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I received a request to include language regarding the extended key usage certificate extension in the next version of the CERT draft. It seems that the language is basically: If the extended key usage extension is present and marked critical, and it does not contain at least one of the anyExtendedKeyUsage or the emailProtection key purpose Ids, then the certificate is not considered suitable for verifying signatures or key management. Otherwise, continue with normal certificate processing. So the point is that if: 1. The extension is present and not marked critical, and doesn't contain emailProtection or anyExtendedKeyUsage, no one cares because it isn't critical, and processing continues 2. The extension is present and marked critical and doesn't contain emailProtection or anyExtendedKeyUsage, it's rejected 3. If it's not present, then processing continues Anyone have any understanding of the current use of this extension, so that we might have some assurance that this is the right way to move forward, or is that outside the scope of this? Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com From owner-ietf-smime@mail.imc.org Wed Feb 19 19:50:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14230 for ; Wed, 19 Feb 2003 19:50:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K0YAc14602 for ietf-smime-bks; Wed, 19 Feb 2003 16:34:10 -0800 (PST) Received: from mx1.pacifier.net (mx1.pacifier.net [64.255.237.181]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K0Y9d14598 for ; Wed, 19 Feb 2003 16:34:09 -0800 (PST) Received: from smtp3.pacifier.net (smtp3 [64.255.237.173]) by mx1.pacifier.net (Postfix) with ESMTP id 0CADB6A7B0; Wed, 19 Feb 2003 16:34:12 -0800 (PST) Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id 3B1316D62D; Wed, 19 Feb 2003 16:34:11 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , Subject: RE: Extended Key Usage extension and S/MIME Date: Wed, 19 Feb 2003 16:32:01 -0800 Message-ID: <001e01c2d877$7cd69260$1600a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Blake, I disagree with the non-critical interperation. I believe that it SHOULD be respected even if the extension is not marked critical. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Blake Ramsdell > Sent: Wednesday, February 19, 2003 3:45 PM > To: ietf-smime@imc.org > Subject: Extended Key Usage extension and S/MIME > > > > I received a request to include language regarding the extended key > usage certificate extension in the next version of the CERT draft. > > It seems that the language is basically: > > If the extended key usage extension is present and marked > critical, and > it does not contain at least one of the anyExtendedKeyUsage or the > emailProtection key purpose Ids, then the certificate is not > considered > suitable for verifying signatures or key management. Otherwise, > continue with normal certificate processing. > > So the point is that if: > > 1. The extension is present and not marked critical, and > doesn't contain > emailProtection or anyExtendedKeyUsage, no one cares because it isn't > critical, and processing continues > > 2. The extension is present and marked critical and doesn't contain > emailProtection or anyExtendedKeyUsage, it's rejected > > 3. If it's not present, then processing continues > > Anyone have any understanding of the current use of this extension, so > that we might have some assurance that this is the right way to move > forward, or is that outside the scope of this? > > Blake > -- > Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com > From owner-ietf-smime@mail.imc.org Wed Feb 19 19:59:30 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14426 for ; Wed, 19 Feb 2003 19:59:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K0jGG14779 for ietf-smime-bks; Wed, 19 Feb 2003 16:45:16 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K0jEd14775 for ; Wed, 19 Feb 2003 16:45:14 -0800 (PST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 19 Feb 2003 16:45:17 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Feb 2003 16:45:10 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Feb 2003 16:45:18 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 19 Feb 2003 16:45:15 -0800 Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Feb 2003 16:45:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Extended Key Usage extension and S/MIME Date: Wed, 19 Feb 2003 16:45:03 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD06333940@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Extended Key Usage extension and S/MIME Thread-Index: AcLYcood4uhDbv3XQEODfLSIKqe9yAABWtZQ From: "Trevor Freeman" To: "Blake Ramsdell" , X-OriginalArrivalTime: 20 Feb 2003 00:45:11.0060 (UTC) FILETIME=[52BDAD40:01C2D879] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1K0jFd14776 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Blake, RFC3280 requires a client who understands an extension to implement its contents regardless of the criticality flag. The critical flag tells a client who don't understand that extension if it they can use the cert or not. So If the extended key usage extension is present and the client implements the extension, and it does not contain at least one of the anyExtendedKeyUsage or the emailProtection key purpose Ids, then the certificate is not considered suitable for verifying signatures or key management. Otherwise, continue with normal certificate processing. If you don't understand the extension then you are simply following the criticality flag so there is no specific behaviour required by S/MIME in this case except beyond what's in 3280. Trevor -----Original Message----- From: Blake Ramsdell [mailto:blake@brutesquadlabs.com] Sent: Wednesday, February 19, 2003 3:45 PM To: ietf-smime@imc.org Subject: Extended Key Usage extension and S/MIME I received a request to include language regarding the extended key usage certificate extension in the next version of the CERT draft. It seems that the language is basically: If the extended key usage extension is present and marked critical, and it does not contain at least one of the anyExtendedKeyUsage or the emailProtection key purpose Ids, then the certificate is not considered suitable for verifying signatures or key management. Otherwise, continue with normal certificate processing. So the point is that if: 1. The extension is present and not marked critical, and doesn't contain emailProtection or anyExtendedKeyUsage, no one cares because it isn't critical, and processing continues 2. The extension is present and marked critical and doesn't contain emailProtection or anyExtendedKeyUsage, it's rejected 3. If it's not present, then processing continues Anyone have any understanding of the current use of this extension, so that we might have some assurance that this is the right way to move forward, or is that outside the scope of this? Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com From owner-ietf-smime@mail.imc.org Wed Feb 19 20:27:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14873 for ; Wed, 19 Feb 2003 20:27:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K1Cr915305 for ietf-smime-bks; Wed, 19 Feb 2003 17:12:53 -0800 (PST) Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K1Cqd15301 for ; Wed, 19 Feb 2003 17:12:52 -0800 (PST) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 19 Feb 2003 17:12:50 -0800 From: "Blake Ramsdell" To: "'Trevor Freeman'" , , "'Jim Schaad'" Subject: RE: Extended Key Usage extension and S/MIME Date: Wed, 19 Feb 2003 17:12:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <4AEE3169443CDD4796CA8A00B02191CD06333940@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] > Sent: Wednesday, February 19, 2003 4:45 PM > To: Blake Ramsdell; ietf-smime@imc.org > Subject: RE: Extended Key Usage extension and S/MIME > > RFC3280 requires a client who understands an extension to > implement its > contents regardless of the criticality flag. The critical flag tells a > client who don't understand that extension if it they can use the cert > or not. This is consistent with Jim's comment also, and I agree that I was misinterpreting the field. > If the extended key usage extension is present and the client > implements > the extension, and it does not contain at least one of the > anyExtendedKeyUsage or the emailProtection key purpose Ids, then the > certificate is not considered suitable for verifying signatures or key > management. Otherwise, > continue with normal certificate processing. OK, I'm proceeding with this. Any controversy around the "anyExtendedKeyUsage" purpose? Blake From owner-ietf-smime@mail.imc.org Thu Feb 20 18:35:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03533 for ; Thu, 20 Feb 2003 18:35:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KNGb508245 for ietf-smime-bks; Thu, 20 Feb 2003 15:16:37 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1KNGad08241 for ; Thu, 20 Feb 2003 15:16:36 -0800 (PST) Received: (qmail 16400 invoked from network); 20 Feb 2003 23:16:25 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (131.107.52.146) by woodstock.binhost.com with SMTP; 20 Feb 2003 23:16:25 -0000 Message-Id: <5.2.0.9.2.20030220171632.038dece8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 18:16:30 -0500 To: Holger Ebel , ietf-smime@imc.org From: Russ Housley Subject: Re: signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70 In-Reply-To: <3E520FE7.5070805@authentidate.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Holger: PKCS#7 only supported the RSA algorithm, and it used field names that represent this situation. signatureAlgorithm is the new name, indicating support for any digital signature algorithm. The digestEncryptionAlgorithm is the old name, indicating the RSA operation that is performed to generate a digital signature with that algorithm. >Now my questions: > >(2) How should I handle a CMS (2630/3369) signature where the value of > the digestAlgorithm does not match the 'included' digestAlgorithm in > the signatureAlgorithm field. (e.g. having a RIPEMD160 digestAlgo > OID at the digestInfo field and a Sha1WithDSA OID in the signature- > algorithm field). I think that the digestAlgorithm must be consistent with the one used in the signature. >(3) When a component claims that it can produce valid RFC 2630 > signatures, is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 > the only exception from the rule? Is the usage of the 'other' > RSA signature OIDs (sha1WithRSAEncryption) really forbidden in 2630? Be flexible in receive processing, but strict on send processing. That said, if you need interoperability with some PKCS#7 implementations, you may need to send it the only way that they know how to accept it. Russ From owner-ietf-smime@mail.imc.org Fri Feb 21 08:58:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29798 for ; Fri, 21 Feb 2003 08:58:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LDiQq00604 for ietf-smime-bks; Fri, 21 Feb 2003 05:44:26 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LDiPd00599 for ; Fri, 21 Feb 2003 05:44:25 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29163; Fri, 21 Feb 2003 08:40:35 -0500 (EST) Message-Id: <200302211340.IAA29163@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-rfc2632bis-03.txt Date: Fri, 21 Feb 2003 08:40:35 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Version 3.1 Certificate Handling Author(s) : B. Ramsdell Filename : draft-ietf-smime-rfc2632bis-03.txt Pages : 0 Date : 2003-2-20 S/MIME (Secure/Multipurpose Internet Mail Extensions), described in [SMIME-MSG], provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile [KEYM]. S/MIME agents MUST meet the certificate processing requirements documented in this document in addition to those stated in [KEYM]. This specification is compatible with the Cryptographic Message Syntax [CMS] in that it uses the data types defined by CMS. It also inherits all the varieties of architectures for certificate-based key management supported by CMS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2632bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-rfc2632bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-rfc2632bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-20155052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc2632bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rfc2632bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-20155053.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Mon Feb 24 17:52:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29291 for ; Mon, 24 Feb 2003 17:52:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OMXSL03102 for ietf-smime-bks; Mon, 24 Feb 2003 14:33:28 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OMXRd03097 for ; Mon, 24 Feb 2003 14:33:27 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: v1.5 Enhanced SNACC Freeware Now Available Date: Mon, 24 Feb 2003 17:33:29 -0500 Message-ID: Thread-Topic: v1.5 Enhanced SNACC Freeware Now Available Thread-Index: AcI5cp6Z14OJyzHGQ8i472hAAgjQnA== From: "Pawling, John" To: "SMIME WG (SMIME WG)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1OMXRd03098 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit All, DigitalNet (formerly Getronics Government Solutions) has delivered the v1.5 eSNACC Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library source code compilable for Linux, Sun Solaris 2.8 and Microsoft (MS) Windows NT/98/2000/XP. The eSNACC software is freely available to everyone from: The eSNACC ASN.1 software can be used to ASN.1 encode and decode objects. In past releases, DigitalNet improved the eSNACC C++ library to implement the Distinguished Encoding Rules (DER), support large ASN.1 INTEGERs, and improve memory usage. v1.5 eSNACC enhancements (compared to v1.4 release): 1) Updated compiler to automatically read in ASN.1 module files listed in IMPORTS section of primary module. Added option for specifying directories to search when looking for imported ASN.1 modules. Now only primary ASN.1 module needs to be passed to the compiler. 2) Enhanced compiler to support OCTET STRING CONTAINS DER ENCODING feature. 3) Enhanced AsnBuf, ASNOcts, ASNAny class to expand as necessary when encoding and to decode directly from a file. CSM_Buffer moved out of eSNACC. 4) Enhanced C Library to use GenBuf to provide improved buffer processing capabilities. We successfully tested the v1.5 eSNACC ASN.1 C++ and C libraries using the Simple Network Management Protocol (SNMP) v1 test suite (18,000 test cases) developed by the University of Oulu. We tested the v1.5 eSNACC release with the v2.2 S/MIME Freeware Library (SFL) available from that uses the eSNACC ASN.1 software to encode and decode the IETF S/MIME v3 Cryptographic Message Syntax (RFC 3369) and Enhanced Security Services for S/MIME (RFC 2634) security protocol. We tested the v1.5 eSNACC release with the freeware v2.2 Certificate Management Library (CML) available from that uses the eSNACC ASN.1 software to encode and decode X.509 certificates, attribute certificates and Certificate Revocation Lists as specified in the 2000 X.509 Recommendation. We tested the v1.5 eSNACC release with the freeware v2.2 Access Control Library (ACL) available from that uses the eSNACC ASN.1 software to encode and decode security labels and other objects (such as Security Policy Information Files) required to provide rule based automated access control as specified in SDN.801. The eSNACC ASN.1 software implements the majority of the ASN.1 encoding/decoding rules as specified in the 1988 X.209 Recommendation. It implements the DER as specified in the 1997 X.690 Recommendation. It does not support all of the latest ASN.1 features, but there are strategies that allow it to be used to produce ASN.1 hex encodings that are identical to those produced by ASN.1 libraries that do support the latest ASN.1 features. Also note that many of the PKIX specs, such as RFC 3280 and RFC 2630, include 1988-compliant ASN.1 syntax modules which can be compiled using the eSNACC compiler. The eSNACC ASN.1 library is totally unencumbered as stated in the Enhanced SNACC Software Public License. All source code for the eSNACC software is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the eSNACC software without paying any royalties or licensing fees. The Internet Mail Consortium (IMC) has established an eSNACC web page . The IMC has established an eSNACC mail list which is used to: distribute information regarding eSNACC releases; discuss related issues; and provide a means for integrators to provide feedback, comments, bug reports, etc. Subscription information for the imc-snacc mail list is at the IMC web site listed above. We are still in the process of improving the eSNACC software. We welcome all feedback regarding the eSNACC software. If bugs are reported, then we will investigate each reported bug and, if required, will produce a patch or an updated release of the software to repair the bug. This release announcement was sent to several mail lists, but please send all messages regarding the eSNACC software to the imc-snacc mail list ONLY. Please do not send messages regarding the eSNACC software to any of the IETF mail lists. We will respond to all messages sent to the imc-snacc mail list. =========================================== John Pawling, John.Pawling@DigitalNet.com DigitalNet Government Solutions, LLC ================================================= From owner-ietf-smime@mail.imc.org Mon Feb 24 19:08:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00971 for ; Mon, 24 Feb 2003 19:08:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ONqfQ06046 for ietf-smime-bks; Mon, 24 Feb 2003 15:52:41 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ONqed06036 for ; Mon, 24 Feb 2003 15:52:40 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: v2.2 S/MIME Freeware Library (SFL) Now Available Date: Mon, 24 Feb 2003 18:52:42 -0500 Message-ID: Thread-Topic: v2.2 S/MIME Freeware Library (SFL) Now Available Thread-Index: AcI5hhsP6XOt1UY5R2CHe/iQEv/4vw== From: "Pawling, John" To: "SMIME WG (SMIME WG)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1ONqed06038 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit All, DigitalNet (formerly Getronics Government Solutions) has delivered the Version 2.2 S/MIME Freeware Library (SFL) source code. The SFL source code files and documents are freely available at . The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It implements portions of the RFC 2633 Message Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS Algorithms specifications. When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification. It has been successfully tested using the Microsoft (MS) Windows 2000/XP, Linux and Sun Solaris 2.8 operating systems. Further enhancements, ports and testing of the SFL are still in process. Further releases of the SFL will be provided as significant capabilities are added. The SFL has been successfully used to sign, verify, encrypt and decrypt CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0 Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The v2.2 SFL uses the v2.2 Certificate Management Library (CML) and v1.5 Enhanced SNACC (eSNACC) ASN.1 C++ Library to encode/decode objects. The v2.2 SFL release includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; test utilities; test drivers; and test data. All CTILs were tested as Dynamically Linked Libraries (DLL) using MS Windows. The Fortezza, BSAFE and Crypto++ CTILs were tested with the respective security libraries as shared objects using Linux and Solaris 2.8. The SFL has been successfully used to exchange signedData and envelopedData messages with the MS Internet Explorer Outlook Express v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME products. Signed messages have been exchanged with the RSA S/MAIL and WorldTalk S/MIME v2 products. The SFL has also been used to perform S/MIME v3 interoperability testing with Microsoft that exercised the majority of the features specified by RFCs 3369, 3370, 2631 and 2634. This testing included the RSA, DSA, E-S D-H, 3DES, SHA and Fortezza algorithms. We used the SFL to successfully process the SFL-supported sample data included in the S/MIME WG "Examples of S/MIME Messages" document. We also used the SFL to generate S/MIME v3 sample messages that were included in the "Examples" document. The use of the v2.2 SFL is described in the v2.2 SFL Application Programming Interface (API) and v2.2 SFL Software Design Description documents. The use of the v2.2 CTIL API is described in the v2.2 CTIL API document. v2.2 SFL includes the following enhancements (compared to v2.1 SFL and CTIL releases): 1) Enhanced SFL to optionally make internal calls to the freeware Access Control Library (ACL) to perform SDN.801 access control checks. 2) Enhanced SignedData processing to input and process X.509 (2000) v2 Attribute Certificates. 3) Increased performance for Mail List Agents by providing ability to build an envelopedData without needing to re-encrypt the content extracted from the received envelopedData. 4) Enhanced SFL to facilitate use of multiple GeneralName instances (i.e. e-mail address and DN) in a GeneralNames SEQUENCE. This is needed for the receipt request receiptTo field. 5) Added support to decode unrecognized elements of RFC 3369 RecipientInfo syntax. 6) Modified CSMIME login list container to remove "m_pCSInsts2" member. The new logic now references the CSM_CtilMgr::m_pCSInsts list (CSM_CtilInst, no certificates). v2.2 CTILs include the following enhancements (compared to v2.1 release): 1) CSM_Buffer moved into CTILMgr. 2) Added CSM_Buffer capability to decode and copy to another buffer. 3) Enhanced Crypto++ CTIL to use either Crypto++ v5.0 or v4.2. v2.2 CertificateBuilder utility (to be delivered by 28 February 2003) includes the following enhancements (compared to v2.1 release): 1) Improved capability to generate X.509 (2000) Attribute Certificates including X.501 Clearance attributes including user-selected values extracted from Security Policy Information File (SPIF) for the security policy. We are still in the process of enhancing and testing the SFL. Future releases may include: additional PKCS #11 CTIL testing; add "Certificate Management Messages over CMS" ASN.1 encode/decode functions; add enhanced test routines; bug fixes; and support for other operating systems. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows, Linux and Solaris 2.8, we may port the SFL to other operating systems. All source code for the SFL is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the SFL without paying any royalties or licensing fees. DigitalNet is developing the SFL under contract to the U.S. Government. The U.S. Government is furnishing the SFL source code at no cost to the vendor subject to the conditions of the "SFL Public License". On 14 January 2000, the U.S. Department of Commerce, Bureau of Export Administration published a new regulation implementing an update to the U.S. Government's encryption export policy . In accordance with the revisions to the Export Administration Regulations (EAR) of 14 Jan 2000, the downloading of the SFL source code is not password controlled. The SFL is composed of a high-level library that performs generic CMS and ESS processing independent of the crypto algorithms used to protect a specific object. The SFL high-level library makes calls to an algorithm-independent CTIL API. The underlying, external crypto token libraries are not distributed as part of the SFL source code. The application developer must independently obtain these libraries and then link them with the SFL. The SFL uses the CML and eSNACC ASN.1 Library to encode/decode certificates, ACs, CRLs and components thereof. The CML is freely available at: . The SFL has been successfully tested in conjunction with the Access Control Library (ACL) that is freely available to everyone from: . The National Institute of Standards and Technology (NIST) is providing test S/MIME messages (created by DigitalNet) at . DigitalNet used the SFL to successfully process the NIST test data. NIST is using the SFL and CML as part of the NIST S/MIME Test Facility (NSMTF) that they are planning to host (see ). Vendors will be able to use the NSMTF to help determine if their products comply with the IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. The SFL has been integrated into many applications to provide CMS/ESS security services. For example, the SFL was integrated into a security plug-in for a commercial e-mail application that enabled the application to meet the Bridge Certification Authority Demonstration Phase II requirements including implementing ESS features such as security labels. The Internet Mail Consortium (IMC) has established an SFL web page . The IMC has also established an SFL mail list which is used to: distribute information regarding SFL releases; discuss SFL-related issues; and provide a means for SFL users to provide feedback, comments, bug reports, etc. Subscription information for the imc-sfl mailing list is at the IMC web site listed above. All comments regarding the SFL source code and documents are welcome. This SFL release announcement was sent to several mail lists, but please send all messages regarding the SFL to the imc-sfl mail list ONLY. Please do not send messages regarding the SFL to any of the IETF mail lists. We will respond to all messages sent to the imc-sfl mail list. ============================================ John Pawling, John.Pawling@DigitalNet.com DigitalNet Government Solutions, LLC ============================================ From owner-ietf-smime@mail.imc.org Wed Feb 26 09:33:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07351 for ; Wed, 26 Feb 2003 09:33:58 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QE5h602894 for ietf-smime-bks; Wed, 26 Feb 2003 06:05:43 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QE5fd02890 for ; Wed, 26 Feb 2003 06:05:42 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05358; Wed, 26 Feb 2003 09:01:47 -0500 (EST) Message-Id: <200302261401.JAA05358@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-pss-00.txt Date: Wed, 26 Feb 2003 09:01:47 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the PSS Signature Algorithm in CMS Author(s) : J. Schaad Filename : draft-ietf-smime-pss-00.txt Pages : 5 Date : 2003-2-25 This document specifies the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) digital signature algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-pss-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-pss-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-pss-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-25160355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-pss-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-pss-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-25160355.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Wed Feb 26 12:50:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17769 for ; Wed, 26 Feb 2003 12:50:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QHQ7s14848 for ietf-smime-bks; Wed, 26 Feb 2003 09:26:07 -0800 (PST) Received: from broadsword.its.cse.dnd.ca (itsfw.cse.dnd.ca [131.136.196.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QHQ5d14844 for ; Wed, 26 Feb 2003 09:26:05 -0800 (PST) Received: by broadsword.its.cse.dnd.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Feb 2003 12:31:37 -0500 Message-ID: <7246F1C4915E1E4B874E62AE51E8F4F8902C58@broadsword.its.cse.dnd.ca> From: Francois.Rousseau@CSE-CST.GC.CA To: jimsch@exmsft.com Cc: ietf-smime@imc.org Subject: RE: I-D ACTION:draft-ietf-smime-pss-00.txt Date: Wed, 26 Feb 2003 12:31:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Jim, I understand that this Internet Draft is much simpler than the one on the use of RSA-OAEP under CMS since you are referring to a future PKIX RFC (i.e. RSA-ALGS). However, I would think it still needs to include a separate section on SMIMECapabilities attribute conventions addressing the various hash functions, and the section on security considerations should probably touch on not using of the same RSA private key under both RSA PKCS #1 v1.5 and RSA-PSS, and on the choice of hash function and key sizes. Cheers, Francois -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, February 26, 2003 9:02 AM Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-pss-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the PSS Signature Algorithm in CMS Author(s) : J. Schaad Filename : draft-ietf-smime-pss-00.txt Pages : 5 Date : 2003-2-25 This document specifies the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) digital signature algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-pss-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-pss-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-pss-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ietf-smime@mail.imc.org Thu Feb 27 21:44:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01312 for ; Thu, 27 Feb 2003 21:44:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S2WEu14855 for ietf-smime-bks; Thu, 27 Feb 2003 18:32:14 -0800 (PST) Received: from mx4.pacifier.net (mx4.pacifier.net [64.255.237.184]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S2WDY14851 for ; Thu, 27 Feb 2003 18:32:13 -0800 (PST) Received: from smtp1.pacifier.net (smtp1 [64.255.237.171]) by mx4.pacifier.net (Postfix) with ESMTP id EF90F6AAF9; Thu, 27 Feb 2003 18:32:16 -0800 (PST) Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 55AAF6EF29; Thu, 27 Feb 2003 18:32:15 -0800 (PST) Reply-To: From: "Jim Schaad" To: Cc: Subject: RE: I-D ACTION:draft-ietf-smime-pss-00.txt Date: Thu, 27 Feb 2003 18:29:48 -0800 Message-ID: <001001c2ded1$44987b10$1600a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <7246F1C4915E1E4B874E62AE51E8F4F8902C58@broadsword.its.cse.dnd.ca> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francois, I agree that a comment on not using the same RSA key pair for both RSA PKCS#1 v1.5 and RSA-PSS is a good idea and will insert this. I do not believe that there is a strong argument for creating an SMIMECapability for RSA-PSS, but would welcome comments from the list. The reason that I don't believe that it is really needed is that the worst that happens is you send a message to somebody and the recipient cannot validate the signature. However, I do not know of any MUAs that look at SMIMECapabilities for sending signed messages. This is not the same problem as with encrypted mail where there is no way to see the message if the client does not understand the content encryption algorithm. I am hesitant to try and address issues of hash sizes with any degree of specifics. Given the amount of arguments over draft-orman-public-key-lengths-05.txt I don't want to follow the rat down the hole. Do you see any need for text beyond that in draft-ietf-pkix-rsa-pkalgs-00.txt? jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of > Francois.Rousseau@CSE-CST.GC.CA > Sent: Wednesday, February 26, 2003 9:32 AM > To: jimsch@exmsft.com > Cc: ietf-smime@imc.org > Subject: RE: I-D ACTION:draft-ietf-smime-pss-00.txt > > > > Hi Jim, > > I understand that this Internet Draft is much simpler than > the one on the > use of RSA-OAEP under CMS since you are referring to a future > PKIX RFC (i.e. > RSA-ALGS). > > However, I would think it still needs to include a separate section on > SMIMECapabilities attribute conventions addressing the various hash > functions, and the section on security considerations should > probably touch > on not using of the same RSA private key under both RSA PKCS > #1 v1.5 and > RSA-PSS, and on the choice of hash function and key sizes. > > Cheers, > > Francois > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, February 26, 2003 9:02 AM > Cc: ietf-smime@imc.org > Subject: I-D ACTION:draft-ietf-smime-pss-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the S/MIME Mail Security Working > Group of the > IETF. > > Title : Use of the PSS Signature Algorithm in CMS > Author(s) : J. Schaad > Filename : draft-ietf-smime-pss-00.txt > Pages : 5 > Date : 2003-2-25 > > This document specifies the conventions for using the RSA > Probabilistic Signature Scheme (RSASSA-PSS) digital signature > algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-smime-pss-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-smime-pss-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-smime-pss-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S2WEu14855 for ietf-smime-bks; Thu, 27 Feb 2003 18:32:14 -0800 (PST) Received: from mx4.pacifier.net (mx4.pacifier.net [64.255.237.184]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S2WDY14851 for ; Thu, 27 Feb 2003 18:32:13 -0800 (PST) Received: from smtp1.pacifier.net (smtp1 [64.255.237.171]) by mx4.pacifier.net (Postfix) with ESMTP id EF90F6AAF9; Thu, 27 Feb 2003 18:32:16 -0800 (PST) Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 55AAF6EF29; Thu, 27 Feb 2003 18:32:15 -0800 (PST) Reply-To: From: "Jim Schaad" To: Cc: Subject: RE: I-D ACTION:draft-ietf-smime-pss-00.txt Date: Thu, 27 Feb 2003 18:29:48 -0800 Message-ID: <001001c2ded1$44987b10$1600a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <7246F1C4915E1E4B874E62AE51E8F4F8902C58@broadsword.its.cse.dnd.ca> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Francois, I agree that a comment on not using the same RSA key pair for both RSA PKCS#1 v1.5 and RSA-PSS is a good idea and will insert this. I do not believe that there is a strong argument for creating an SMIMECapability for RSA-PSS, but would welcome comments from the list. The reason that I don't believe that it is really needed is that the worst that happens is you send a message to somebody and the recipient cannot validate the signature. However, I do not know of any MUAs that look at SMIMECapabilities for sending signed messages. This is not the same problem as with encrypted mail where there is no way to see the message if the client does not understand the content encryption algorithm. I am hesitant to try and address issues of hash sizes with any degree of specifics. Given the amount of arguments over draft-orman-public-key-lengths-05.txt I don't want to follow the rat down the hole. Do you see any need for text beyond that in draft-ietf-pkix-rsa-pkalgs-00.txt? jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of > Francois.Rousseau@CSE-CST.GC.CA > Sent: Wednesday, February 26, 2003 9:32 AM > To: jimsch@exmsft.com > Cc: ietf-smime@imc.org > Subject: RE: I-D ACTION:draft-ietf-smime-pss-00.txt > > > > Hi Jim, > > I understand that this Internet Draft is much simpler than > the one on the > use of RSA-OAEP under CMS since you are referring to a future > PKIX RFC (i.e. > RSA-ALGS). > > However, I would think it still needs to include a separate section on > SMIMECapabilities attribute conventions addressing the various hash > functions, and the section on security considerations should > probably touch > on not using of the same RSA private key under both RSA PKCS > #1 v1.5 and > RSA-PSS, and on the choice of hash function and key sizes. > > Cheers, > > Francois > > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, February 26, 2003 9:02 AM > Cc: ietf-smime@imc.org > Subject: I-D ACTION:draft-ietf-smime-pss-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the S/MIME Mail Security Working > Group of the > IETF. > > Title : Use of the PSS Signature Algorithm in CMS > Author(s) : J. Schaad > Filename : draft-ietf-smime-pss-00.txt > Pages : 5 > Date : 2003-2-25 > > This document specifies the conventions for using the RSA > Probabilistic Signature Scheme (RSASSA-PSS) digital signature > algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-smime-pss-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-smime-pss-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-smime-pss-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QHQ7s14848 for ietf-smime-bks; Wed, 26 Feb 2003 09:26:07 -0800 (PST) Received: from broadsword.its.cse.dnd.ca (itsfw.cse.dnd.ca [131.136.196.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QHQ5d14844 for ; Wed, 26 Feb 2003 09:26:05 -0800 (PST) Received: by broadsword.its.cse.dnd.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Feb 2003 12:31:37 -0500 Message-ID: <7246F1C4915E1E4B874E62AE51E8F4F8902C58@broadsword.its.cse.dnd.ca> From: Francois.Rousseau@CSE-CST.GC.CA To: jimsch@exmsft.com Cc: ietf-smime@imc.org Subject: RE: I-D ACTION:draft-ietf-smime-pss-00.txt Date: Wed, 26 Feb 2003 12:31:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Jim, I understand that this Internet Draft is much simpler than the one on the use of RSA-OAEP under CMS since you are referring to a future PKIX RFC (i.e. RSA-ALGS). However, I would think it still needs to include a separate section on SMIMECapabilities attribute conventions addressing the various hash functions, and the section on security considerations should probably touch on not using of the same RSA private key under both RSA PKCS #1 v1.5 and RSA-PSS, and on the choice of hash function and key sizes. Cheers, Francois -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, February 26, 2003 9:02 AM Cc: ietf-smime@imc.org Subject: I-D ACTION:draft-ietf-smime-pss-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the PSS Signature Algorithm in CMS Author(s) : J. Schaad Filename : draft-ietf-smime-pss-00.txt Pages : 5 Date : 2003-2-25 This document specifies the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) digital signature algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-pss-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-pss-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-pss-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QE5h602894 for ietf-smime-bks; Wed, 26 Feb 2003 06:05:43 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QE5fd02890 for ; Wed, 26 Feb 2003 06:05:42 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05358; Wed, 26 Feb 2003 09:01:47 -0500 (EST) Message-Id: <200302261401.JAA05358@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-pss-00.txt Date: Wed, 26 Feb 2003 09:01:47 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the PSS Signature Algorithm in CMS Author(s) : J. Schaad Filename : draft-ietf-smime-pss-00.txt Pages : 5 Date : 2003-2-25 This document specifies the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) digital signature algorithm [P1v2.1] with the Cryptographic Message Syntax (CMS) [CMS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-pss-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-pss-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-pss-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-25160355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-pss-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-pss-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-25160355.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ONqfQ06046 for ietf-smime-bks; Mon, 24 Feb 2003 15:52:41 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ONqed06036 for ; Mon, 24 Feb 2003 15:52:40 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: v2.2 S/MIME Freeware Library (SFL) Now Available Date: Mon, 24 Feb 2003 18:52:42 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v2.2 S/MIME Freeware Library (SFL) Now Available Thread-Index: AcI5hhsP6XOt1UY5R2CHe/iQEv/4vw== From: "Pawling, John" To: "SMIME WG (SMIME WG)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1ONqed06038 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, DigitalNet (formerly Getronics Government Solutions) has delivered the Version 2.2 S/MIME Freeware Library (SFL) source code. The SFL source code files and documents are freely available at . The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It implements portions of the RFC 2633 Message Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS Algorithms specifications. When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification. It has been successfully tested using the Microsoft (MS) Windows 2000/XP, Linux and Sun Solaris 2.8 operating systems. Further enhancements, ports and testing of the SFL are still in process. Further releases of the SFL will be provided as significant capabilities are added. The SFL has been successfully used to sign, verify, encrypt and decrypt CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0 Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The v2.2 SFL uses the v2.2 Certificate Management Library (CML) and v1.5 Enhanced SNACC (eSNACC) ASN.1 C++ Library to encode/decode objects. The v2.2 SFL release includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; test utilities; test drivers; and test data. All CTILs were tested as Dynamically Linked Libraries (DLL) using MS Windows. The Fortezza, BSAFE and Crypto++ CTILs were tested with the respective security libraries as shared objects using Linux and Solaris 2.8. The SFL has been successfully used to exchange signedData and envelopedData messages with the MS Internet Explorer Outlook Express v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME products. Signed messages have been exchanged with the RSA S/MAIL and WorldTalk S/MIME v2 products. The SFL has also been used to perform S/MIME v3 interoperability testing with Microsoft that exercised the majority of the features specified by RFCs 3369, 3370, 2631 and 2634. This testing included the RSA, DSA, E-S D-H, 3DES, SHA and Fortezza algorithms. We used the SFL to successfully process the SFL-supported sample data included in the S/MIME WG "Examples of S/MIME Messages" document. We also used the SFL to generate S/MIME v3 sample messages that were included in the "Examples" document. The use of the v2.2 SFL is described in the v2.2 SFL Application Programming Interface (API) and v2.2 SFL Software Design Description documents. The use of the v2.2 CTIL API is described in the v2.2 CTIL API document. v2.2 SFL includes the following enhancements (compared to v2.1 SFL and CTIL releases): 1) Enhanced SFL to optionally make internal calls to the freeware Access Control Library (ACL) to perform SDN.801 access control checks. 2) Enhanced SignedData processing to input and process X.509 (2000) v2 Attribute Certificates. 3) Increased performance for Mail List Agents by providing ability to build an envelopedData without needing to re-encrypt the content extracted from the received envelopedData. 4) Enhanced SFL to facilitate use of multiple GeneralName instances (i.e. e-mail address and DN) in a GeneralNames SEQUENCE. This is needed for the receipt request receiptTo field. 5) Added support to decode unrecognized elements of RFC 3369 RecipientInfo syntax. 6) Modified CSMIME login list container to remove "m_pCSInsts2" member. The new logic now references the CSM_CtilMgr::m_pCSInsts list (CSM_CtilInst, no certificates). v2.2 CTILs include the following enhancements (compared to v2.1 release): 1) CSM_Buffer moved into CTILMgr. 2) Added CSM_Buffer capability to decode and copy to another buffer. 3) Enhanced Crypto++ CTIL to use either Crypto++ v5.0 or v4.2. v2.2 CertificateBuilder utility (to be delivered by 28 February 2003) includes the following enhancements (compared to v2.1 release): 1) Improved capability to generate X.509 (2000) Attribute Certificates including X.501 Clearance attributes including user-selected values extracted from Security Policy Information File (SPIF) for the security policy. We are still in the process of enhancing and testing the SFL. Future releases may include: additional PKCS #11 CTIL testing; add "Certificate Management Messages over CMS" ASN.1 encode/decode functions; add enhanced test routines; bug fixes; and support for other operating systems. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows, Linux and Solaris 2.8, we may port the SFL to other operating systems. All source code for the SFL is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the SFL without paying any royalties or licensing fees. DigitalNet is developing the SFL under contract to the U.S. Government. The U.S. Government is furnishing the SFL source code at no cost to the vendor subject to the conditions of the "SFL Public License". On 14 January 2000, the U.S. Department of Commerce, Bureau of Export Administration published a new regulation implementing an update to the U.S. Government's encryption export policy . In accordance with the revisions to the Export Administration Regulations (EAR) of 14 Jan 2000, the downloading of the SFL source code is not password controlled. The SFL is composed of a high-level library that performs generic CMS and ESS processing independent of the crypto algorithms used to protect a specific object. The SFL high-level library makes calls to an algorithm-independent CTIL API. The underlying, external crypto token libraries are not distributed as part of the SFL source code. The application developer must independently obtain these libraries and then link them with the SFL. The SFL uses the CML and eSNACC ASN.1 Library to encode/decode certificates, ACs, CRLs and components thereof. The CML is freely available at: . The SFL has been successfully tested in conjunction with the Access Control Library (ACL) that is freely available to everyone from: . The National Institute of Standards and Technology (NIST) is providing test S/MIME messages (created by DigitalNet) at . DigitalNet used the SFL to successfully process the NIST test data. NIST is using the SFL and CML as part of the NIST S/MIME Test Facility (NSMTF) that they are planning to host (see ). Vendors will be able to use the NSMTF to help determine if their products comply with the IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. The SFL has been integrated into many applications to provide CMS/ESS security services. For example, the SFL was integrated into a security plug-in for a commercial e-mail application that enabled the application to meet the Bridge Certification Authority Demonstration Phase II requirements including implementing ESS features such as security labels. The Internet Mail Consortium (IMC) has established an SFL web page . The IMC has also established an SFL mail list which is used to: distribute information regarding SFL releases; discuss SFL-related issues; and provide a means for SFL users to provide feedback, comments, bug reports, etc. Subscription information for the imc-sfl mailing list is at the IMC web site listed above. All comments regarding the SFL source code and documents are welcome. This SFL release announcement was sent to several mail lists, but please send all messages regarding the SFL to the imc-sfl mail list ONLY. Please do not send messages regarding the SFL to any of the IETF mail lists. We will respond to all messages sent to the imc-sfl mail list. ============================================ John Pawling, John.Pawling@DigitalNet.com DigitalNet Government Solutions, LLC ============================================ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OMXSL03102 for ietf-smime-bks; Mon, 24 Feb 2003 14:33:28 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OMXRd03097 for ; Mon, 24 Feb 2003 14:33:27 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: v1.5 Enhanced SNACC Freeware Now Available Date: Mon, 24 Feb 2003 17:33:29 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v1.5 Enhanced SNACC Freeware Now Available Thread-Index: AcI5cp6Z14OJyzHGQ8i472hAAgjQnA== From: "Pawling, John" To: "SMIME WG (SMIME WG)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1OMXRd03098 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, DigitalNet (formerly Getronics Government Solutions) has delivered the v1.5 eSNACC Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library source code compilable for Linux, Sun Solaris 2.8 and Microsoft (MS) Windows NT/98/2000/XP. The eSNACC software is freely available to everyone from: The eSNACC ASN.1 software can be used to ASN.1 encode and decode objects. In past releases, DigitalNet improved the eSNACC C++ library to implement the Distinguished Encoding Rules (DER), support large ASN.1 INTEGERs, and improve memory usage. v1.5 eSNACC enhancements (compared to v1.4 release): 1) Updated compiler to automatically read in ASN.1 module files listed in IMPORTS section of primary module. Added option for specifying directories to search when looking for imported ASN.1 modules. Now only primary ASN.1 module needs to be passed to the compiler. 2) Enhanced compiler to support OCTET STRING CONTAINS DER ENCODING feature. 3) Enhanced AsnBuf, ASNOcts, ASNAny class to expand as necessary when encoding and to decode directly from a file. CSM_Buffer moved out of eSNACC. 4) Enhanced C Library to use GenBuf to provide improved buffer processing capabilities. We successfully tested the v1.5 eSNACC ASN.1 C++ and C libraries using the Simple Network Management Protocol (SNMP) v1 test suite (18,000 test cases) developed by the University of Oulu. We tested the v1.5 eSNACC release with the v2.2 S/MIME Freeware Library (SFL) available from that uses the eSNACC ASN.1 software to encode and decode the IETF S/MIME v3 Cryptographic Message Syntax (RFC 3369) and Enhanced Security Services for S/MIME (RFC 2634) security protocol. We tested the v1.5 eSNACC release with the freeware v2.2 Certificate Management Library (CML) available from that uses the eSNACC ASN.1 software to encode and decode X.509 certificates, attribute certificates and Certificate Revocation Lists as specified in the 2000 X.509 Recommendation. We tested the v1.5 eSNACC release with the freeware v2.2 Access Control Library (ACL) available from that uses the eSNACC ASN.1 software to encode and decode security labels and other objects (such as Security Policy Information Files) required to provide rule based automated access control as specified in SDN.801. The eSNACC ASN.1 software implements the majority of the ASN.1 encoding/decoding rules as specified in the 1988 X.209 Recommendation. It implements the DER as specified in the 1997 X.690 Recommendation. It does not support all of the latest ASN.1 features, but there are strategies that allow it to be used to produce ASN.1 hex encodings that are identical to those produced by ASN.1 libraries that do support the latest ASN.1 features. Also note that many of the PKIX specs, such as RFC 3280 and RFC 2630, include 1988-compliant ASN.1 syntax modules which can be compiled using the eSNACC compiler. The eSNACC ASN.1 library is totally unencumbered as stated in the Enhanced SNACC Software Public License. All source code for the eSNACC software is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the eSNACC software without paying any royalties or licensing fees. The Internet Mail Consortium (IMC) has established an eSNACC web page . The IMC has established an eSNACC mail list which is used to: distribute information regarding eSNACC releases; discuss related issues; and provide a means for integrators to provide feedback, comments, bug reports, etc. Subscription information for the imc-snacc mail list is at the IMC web site listed above. We are still in the process of improving the eSNACC software. We welcome all feedback regarding the eSNACC software. If bugs are reported, then we will investigate each reported bug and, if required, will produce a patch or an updated release of the software to repair the bug. This release announcement was sent to several mail lists, but please send all messages regarding the eSNACC software to the imc-snacc mail list ONLY. Please do not send messages regarding the eSNACC software to any of the IETF mail lists. We will respond to all messages sent to the imc-snacc mail list. =========================================== John Pawling, John.Pawling@DigitalNet.com DigitalNet Government Solutions, LLC ================================================= Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LDiQq00604 for ietf-smime-bks; Fri, 21 Feb 2003 05:44:26 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1LDiPd00599 for ; Fri, 21 Feb 2003 05:44:25 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29163; Fri, 21 Feb 2003 08:40:35 -0500 (EST) Message-Id: <200302211340.IAA29163@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-rfc2632bis-03.txt Date: Fri, 21 Feb 2003 08:40:35 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Version 3.1 Certificate Handling Author(s) : B. Ramsdell Filename : draft-ietf-smime-rfc2632bis-03.txt Pages : 0 Date : 2003-2-20 S/MIME (Secure/Multipurpose Internet Mail Extensions), described in [SMIME-MSG], provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile [KEYM]. S/MIME agents MUST meet the certificate processing requirements documented in this document in addition to those stated in [KEYM]. This specification is compatible with the Cryptographic Message Syntax [CMS] in that it uses the data types defined by CMS. It also inherits all the varieties of architectures for certificate-based key management supported by CMS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2632bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-rfc2632bis-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-rfc2632bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-20155052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc2632bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rfc2632bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-20155053.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KNGb508245 for ietf-smime-bks; Thu, 20 Feb 2003 15:16:37 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1KNGad08241 for ; Thu, 20 Feb 2003 15:16:36 -0800 (PST) Received: (qmail 16400 invoked from network); 20 Feb 2003 23:16:25 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (131.107.52.146) by woodstock.binhost.com with SMTP; 20 Feb 2003 23:16:25 -0000 Message-Id: <5.2.0.9.2.20030220171632.038dece8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 18:16:30 -0500 To: Holger Ebel , ietf-smime@imc.org From: Russ Housley Subject: Re: signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70 In-Reply-To: <3E520FE7.5070805@authentidate.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Holger: PKCS#7 only supported the RSA algorithm, and it used field names that represent this situation. signatureAlgorithm is the new name, indicating support for any digital signature algorithm. The digestEncryptionAlgorithm is the old name, indicating the RSA operation that is performed to generate a digital signature with that algorithm. >Now my questions: > >(2) How should I handle a CMS (2630/3369) signature where the value of > the digestAlgorithm does not match the 'included' digestAlgorithm in > the signatureAlgorithm field. (e.g. having a RIPEMD160 digestAlgo > OID at the digestInfo field and a Sha1WithDSA OID in the signature- > algorithm field). I think that the digestAlgorithm must be consistent with the one used in the signature. >(3) When a component claims that it can produce valid RFC 2630 > signatures, is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 > the only exception from the rule? Is the usage of the 'other' > RSA signature OIDs (sha1WithRSAEncryption) really forbidden in 2630? Be flexible in receive processing, but strict on send processing. That said, if you need interoperability with some PKCS#7 implementations, you may need to send it the only way that they know how to accept it. Russ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K1Cr915305 for ietf-smime-bks; Wed, 19 Feb 2003 17:12:53 -0800 (PST) Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K1Cqd15301 for ; Wed, 19 Feb 2003 17:12:52 -0800 (PST) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 19 Feb 2003 17:12:50 -0800 From: "Blake Ramsdell" To: "'Trevor Freeman'" , , "'Jim Schaad'" Subject: RE: Extended Key Usage extension and S/MIME Date: Wed, 19 Feb 2003 17:12:50 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <4AEE3169443CDD4796CA8A00B02191CD06333940@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Trevor Freeman [mailto:trevorf@windows.microsoft.com] > Sent: Wednesday, February 19, 2003 4:45 PM > To: Blake Ramsdell; ietf-smime@imc.org > Subject: RE: Extended Key Usage extension and S/MIME > > RFC3280 requires a client who understands an extension to > implement its > contents regardless of the criticality flag. The critical flag tells a > client who don't understand that extension if it they can use the cert > or not. This is consistent with Jim's comment also, and I agree that I was misinterpreting the field. > If the extended key usage extension is present and the client > implements > the extension, and it does not contain at least one of the > anyExtendedKeyUsage or the emailProtection key purpose Ids, then the > certificate is not considered suitable for verifying signatures or key > management. Otherwise, > continue with normal certificate processing. OK, I'm proceeding with this. Any controversy around the "anyExtendedKeyUsage" purpose? Blake Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K0jGG14779 for ietf-smime-bks; Wed, 19 Feb 2003 16:45:16 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K0jEd14775 for ; Wed, 19 Feb 2003 16:45:14 -0800 (PST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 19 Feb 2003 16:45:17 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Feb 2003 16:45:10 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Feb 2003 16:45:18 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 19 Feb 2003 16:45:15 -0800 Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Feb 2003 16:45:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Extended Key Usage extension and S/MIME Date: Wed, 19 Feb 2003 16:45:03 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD06333940@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Extended Key Usage extension and S/MIME Thread-Index: AcLYcood4uhDbv3XQEODfLSIKqe9yAABWtZQ From: "Trevor Freeman" To: "Blake Ramsdell" , X-OriginalArrivalTime: 20 Feb 2003 00:45:11.0060 (UTC) FILETIME=[52BDAD40:01C2D879] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1K0jFd14776 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Blake, RFC3280 requires a client who understands an extension to implement its contents regardless of the criticality flag. The critical flag tells a client who don't understand that extension if it they can use the cert or not. So If the extended key usage extension is present and the client implements the extension, and it does not contain at least one of the anyExtendedKeyUsage or the emailProtection key purpose Ids, then the certificate is not considered suitable for verifying signatures or key management. Otherwise, continue with normal certificate processing. If you don't understand the extension then you are simply following the criticality flag so there is no specific behaviour required by S/MIME in this case except beyond what's in 3280. Trevor -----Original Message----- From: Blake Ramsdell [mailto:blake@brutesquadlabs.com] Sent: Wednesday, February 19, 2003 3:45 PM To: ietf-smime@imc.org Subject: Extended Key Usage extension and S/MIME I received a request to include language regarding the extended key usage certificate extension in the next version of the CERT draft. It seems that the language is basically: If the extended key usage extension is present and marked critical, and it does not contain at least one of the anyExtendedKeyUsage or the emailProtection key purpose Ids, then the certificate is not considered suitable for verifying signatures or key management. Otherwise, continue with normal certificate processing. So the point is that if: 1. The extension is present and not marked critical, and doesn't contain emailProtection or anyExtendedKeyUsage, no one cares because it isn't critical, and processing continues 2. The extension is present and marked critical and doesn't contain emailProtection or anyExtendedKeyUsage, it's rejected 3. If it's not present, then processing continues Anyone have any understanding of the current use of this extension, so that we might have some assurance that this is the right way to move forward, or is that outside the scope of this? Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K0YAc14602 for ietf-smime-bks; Wed, 19 Feb 2003 16:34:10 -0800 (PST) Received: from mx1.pacifier.net (mx1.pacifier.net [64.255.237.181]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K0Y9d14598 for ; Wed, 19 Feb 2003 16:34:09 -0800 (PST) Received: from smtp3.pacifier.net (smtp3 [64.255.237.173]) by mx1.pacifier.net (Postfix) with ESMTP id 0CADB6A7B0; Wed, 19 Feb 2003 16:34:12 -0800 (PST) Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id 3B1316D62D; Wed, 19 Feb 2003 16:34:11 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , Subject: RE: Extended Key Usage extension and S/MIME Date: Wed, 19 Feb 2003 16:32:01 -0800 Message-ID: <001e01c2d877$7cd69260$1600a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Blake, I disagree with the non-critical interperation. I believe that it SHOULD be respected even if the extension is not marked critical. jim > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Blake Ramsdell > Sent: Wednesday, February 19, 2003 3:45 PM > To: ietf-smime@imc.org > Subject: Extended Key Usage extension and S/MIME > > > > I received a request to include language regarding the extended key > usage certificate extension in the next version of the CERT draft. > > It seems that the language is basically: > > If the extended key usage extension is present and marked > critical, and > it does not contain at least one of the anyExtendedKeyUsage or the > emailProtection key purpose Ids, then the certificate is not > considered > suitable for verifying signatures or key management. Otherwise, > continue with normal certificate processing. > > So the point is that if: > > 1. The extension is present and not marked critical, and > doesn't contain > emailProtection or anyExtendedKeyUsage, no one cares because it isn't > critical, and processing continues > > 2. The extension is present and marked critical and doesn't contain > emailProtection or anyExtendedKeyUsage, it's rejected > > 3. If it's not present, then processing continues > > Anyone have any understanding of the current use of this extension, so > that we might have some assurance that this is the right way to move > forward, or is that outside the scope of this? > > Blake > -- > Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JNiaM13501 for ietf-smime-bks; Wed, 19 Feb 2003 15:44:36 -0800 (PST) Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JNiZd13497 for ; Wed, 19 Feb 2003 15:44:35 -0800 (PST) Received: from DEXTER ([192.168.0.4]) by brutesquadlabs.com with ESMTP ; Wed, 19 Feb 2003 15:44:33 -0800 From: "Blake Ramsdell" To: Subject: Extended Key Usage extension and S/MIME Date: Wed, 19 Feb 2003 15:44:33 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I received a request to include language regarding the extended key usage certificate extension in the next version of the CERT draft. It seems that the language is basically: If the extended key usage extension is present and marked critical, and it does not contain at least one of the anyExtendedKeyUsage or the emailProtection key purpose Ids, then the certificate is not considered suitable for verifying signatures or key management. Otherwise, continue with normal certificate processing. So the point is that if: 1. The extension is present and not marked critical, and doesn't contain emailProtection or anyExtendedKeyUsage, no one cares because it isn't critical, and processing continues 2. The extension is present and marked critical and doesn't contain emailProtection or anyExtendedKeyUsage, it's rejected 3. If it's not present, then processing continues Anyone have any understanding of the current use of this extension, so that we might have some assurance that this is the right way to move forward, or is that outside the scope of this? Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1IAo7N27808 for ietf-smime-bks; Tue, 18 Feb 2003 02:50:07 -0800 (PST) Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IAo5d27804 for ; Tue, 18 Feb 2003 02:50:05 -0800 (PST) Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id EAA25369 for ; Sun, 23 Feb 2003 04:34:16 +0100 Received: from authentidate.de (input.authentidate.de [192.168.42.73]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h1IAnx912530; Tue, 18 Feb 2003 11:49:59 +0100 X-Authentication-Warning: gate.wisnet.de: Host input.authentidate.de [192.168.42.73] claimed to be authentidate.de Message-ID: <3E520FE7.5070805@authentidate.de> Date: Tue, 18 Feb 2003 11:50:15 +0100 From: Holger Ebel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org CC: Holger Ebel Subject: signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [I accidentally posted this (somewhat different) message to the pkix list, apologize for that. After some direct replies I've modified some parts of my original post] Hello, after working through these specs and decoding many example signatures I still have the following questions regarding the meaning of the signatureAlgorithm/digestEncryptionAlgorithm in these standards mentioned above. (To be more precise, the appearance of these in the SignerInfo structure of the SignedData contentType) If this topic does not belong to this list, it would be nice if someone can point me at the responsible mailing list. Please note that I use the term signatureAlgorithm for the combination of a digest and a digestEncryption algorithm in the following mail. With respect, I would like to summarize first how I get these standards. - PKCS#7 - PKCS#7 1.5 (RFC 2315) clearly distinguishes between a digestAlgorithm and a digestEncryptionAlgorithm. So if the signatureAlgorithm is md5WithRSAEncryption (1.2.840.113549.1.1.4), the digestAlgorithm is md5 (1.2.840.113549.2.5) and the digestEncryptionAlgorithm is RSA (1.2.840.113549.1.1.1). Or if the signatureAlgorithm is sha1WithRSAEncryption (1.2.840.113549.1.1.5), the digestAlgorithm is sha1 (1.3.14.3.2.26) and the digestEncryptionAlgorithm is again RSA (1.2.840.113549.1.1.1). (The same for RipeMD160WithRsaEncryption (1.3.36.3.3.1.2)) Although 'only' RSA is mentioned in PKCS7 directly as a digest- EncryptionAlgorithm, I assume that this rules also apply for other 'encryptionAlgorithm's. All the PKCS#7 'samples' I've found strictly follows these rules, there is always a digest and a digestEncryption algorithm. - CMS (2630) - CMS (RFC 2630) introduced the term signatureAlgorithm in the SignerInfo structure, which has 'replaced' the digestEncryptionAlgorithm of PKCS#7 while the digestAlgorithm field still remains. If a signatureAlgorithm is used to create the signature whose cipher is using the RSA algorithm, the 'old' RSA OID 1.2.840.113549.1.1.1 must be used in the 'signatureAlgorithm' field. (12.2.2) The digestAlgorithm field contains then the corresponding digest Oid, eg. SHA-1, MDx or RipeMD160. The usage of the signatureAlgorithmOids sha1WithRSAEncryption, md5WithRSAEncryption or ripeMD160WithRsaEncryption is not allowed in 2630, the above mentioned schema must be used. When using a signatureAlgorithm which has another cipher - like DSA or ECDSA - the 'splitting' into a digest and a cipher algorithm is not allowed, the signatureAlgorithmOid must be used. (e.g. sha1WithDSA (1.2.840.10040.4.3)) and the digestAlgorithm field must contain the digestAlgo 'included' in the signatureAlgo. Restrictions for the usage of other signatureAlgoritms may be defined in other RFCs (like 3278). - CMS (3369/70) This successor of 2630 (more precise CMSALG) also allows the usage of the signatureAlgorithmOID when a RSA cipher is used for the signature process, which was/is not allowed in 2630. (sha1WithRSAEncryption, md5WithRSAEncryption or ripeMD160WithRsaEncryption). For backward compatibility, the 2630 schema (RSA) is also allowed here for the MD5 and SHA-1 digests. Now my questions: (1) Did I get the standard mentioned above right regarding the signatureAlgo/digestEncryptionAlgorithm? (2) How should I handle a CMS (2630/3369) signature where the value of the digestAlgorithm does not match the 'included' digestAlgorithm in the signatureAlgorithm field. (e.g. having a RIPEMD160 digestAlgo OID at the digestInfo field and a Sha1WithDSA OID in the signature- algorithm field). (3) When a component claims that it can produce valid RFC 2630 signatures, is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 the only exception from the rule? Is the usage of the 'other' RSA signature OIDs (sha1WithRSAEncryption) really forbidden in 2630? (4) Having the following signatureAlgorithms, is the usage of these for PKCS#7/RFC 2630/RFC 3369 signatures allowed and correct? (having valid signatures according the corresponding standard) --------------------------------------------------------------------------- SignatureAlgorithm digestAlgo (I) digestEncrAlgo(PKCS#7) (II) signatureAlgo (RFC 2630) (III) signatureAlgo (RFC 3369) --------------------------------------------------------------------------- (A) sha1WithRSA 1.3.14.3.2.26 (I) 1.2.840.113549.1.1.1 (1.2.840.113549.1.1.5) (II) 1.2.840.113549.1.1.1 (IIIa) 1.2.840.113549.1.1.1 (IIIb) 1.2.840.113549.1.1.5 (B) md5WithRSA 1.2.840.1x9.2.5 (I) 1.2.840.113549.1.1.1 (1.2.840.113549.1.1.4) (II) 1.2.840.113549.1.1.1 (IIIa) 1.2.840.113549.1.1.1 (IIIb) 1.2.840.113549.1.1.4 (D) sha1WithDsa 1.3.14.3.2.26 (I) 1.2.840.10040.4.1 (1.2.840.10040.4.3) (II) 1.2.840.10040.4.3 (III) 1.2.840.10040.4.3 --------------------------------------------------------------------------- (5) Or is the signatureAlgorithm check performed this way (for 2630/3369): If the signatureAlgo field contains a digestEncryptionOID, the signatureAlgo is the digestEncryptionOID plus the digestOID. If the signatureAlgo field contains a signatureAlgo, the signatureAlgo equals the found signatureAlgo. The included digestAlgo is not observed/must be the same as the one which is contained in the signatureAlgo/...? Thanks in advance Best Regards Holger Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HIlqb04521 for ietf-smime-bks; Mon, 17 Feb 2003 10:47:52 -0800 (PST) Received: from mail.epost.de (mail.epost.de [193.28.100.164] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HIlod04516 for ; Mon, 17 Feb 2003 10:47:50 -0800 (PST) Received: from [129.70.36.57] (129.70.36.57) by mail.epost.de (6.7.015) (authenticated as Marc.Mutz@epost.de) id 3E41A7C7001379CA; Mon, 17 Feb 2003 19:47:49 +0100 From: Marc Mutz Organization: "Old Europe" - and proud To: ietf-smime@imc.org Subject: [ot] Re: SMIME and disclaimers Date: Mon, 17 Feb 2003 19:19:02 +0100 User-Agent: KMail/1.5.9 References: <00256CD0.005A2B79.00@postoffice.co.uk> In-Reply-To: <00256CD0.005A2B79.00@postoffice.co.uk> Cc: chris.gilbert@royalmail.com X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_peSU+5FCL1AaNkO"; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200302171919.21899@sendmail.mutz.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --Boundary-02=_peSU+5FCL1AaNkO Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Monday 17 February 2003 17:24, chris.gilbert@royalmail.com wrote: > The multipart nature of MIME suggests > that it is at least plausible to place the disclaimer in its own MIME > boundary such that it doesn't interfere with signed portions in the > parts of the message that originate at the client. The application adding the disclaimer needs to be fully MIME-aware and=20 needs to be able to re-arrange the MIME body parts if necessary. Just=20 appending the disclaimer in plain text, US-ASCII form works only for=20 messages with text/plain top-level content-type and a charset that=20 contains US-ASCII as a subset (e.g. iso-8859-*, utf-8). A more intelligent approach would be to find the last MIME boundary,=20 remove everything after and including the trailing double hyphen, and=20 add something like: Content-Type: text/plain; charset=3Dus-ascii Content-disposition: inline =2D-boundary-- but that fails for multiparts with a fixed number of required children,=20 e.g. multipart/signed, which needs to have exactly two children. =46or coping with these messages, you have three options: 1. Lock down the signature (not the digital signature, but the message footer) to use for your users, if your mailer supports that (e.g. KMail does), so it includes the disclaimer and cannot be changed by the user. 2. Use an application that is dumb and just appends the disclaimer as text, like e.g. mailman does. Then you have to hope that all the recipients use MUAs that show the epilogue of mails if it looks interesting. Don't hold your breath... 3. Use an intelligent application to append the disclaimer, one that can re-arrange the MIME body structure to fold the current content into an additional multipart/mixed if needed to append the text/plain disclaimer and hope that recipient's clients can cope with deeply nested MIME body structures. I guess your best bet is to look up the admin's handbook of your users'=20 MUAs and see if (1) is an option. Marc =2D-=20 "You're hackers, aren't you," the barman said, eyeing us. No one said a thing. The darkness of the Eurotunnel rolled by. Apparently we'd given ourselves away by talking too enthusiastically about IPv6. He looked around conspiratorially, lowered his voice. "Can you get me some credit card numbers?" -- James J. King "What's the shortest way to hack a Linux box?" Telepolis 2001/08/11 (#9293) --Boundary-02=_peSU+5FCL1AaNkO Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+USep3oWD+L2/6DgRAqJRAJ9vn2bT2PI2v3nWhas0LxpJBSz85gCgqnNR odTFvFzt7pfOzQqMMFlRaBY= =A3MN -----END PGP SIGNATURE----- --Boundary-02=_peSU+5FCL1AaNkO-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HGOj529738 for ietf-smime-bks; Mon, 17 Feb 2003 08:24:45 -0800 (PST) Received: from mail3.consignia.com (mail.royalmail.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HGOid29734 for ; Mon, 17 Feb 2003 08:24:44 -0800 (PST) Received: from postoffice.co.uk (unknown [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id CED4518FA5D for ; Mon, 17 Feb 2003 16:25:07 +0000 (GMT) Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 00256CD0.005A2DE1 ; Mon, 17 Feb 2003 16:24:59 +0000 X-Lotus-FromDomain: POSTOFFICE From: chris.gilbert@royalmail.com To: ietf-smime@imc.org Message-ID: <00256CD0.005A2B79.00@postoffice.co.uk> Date: Mon, 17 Feb 2003 16:24:33 +0000 Subject: SMIME and disclaimers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, I don't imagine for a moment that we're the only ones looking at this issue. Discounting whether disclaimers carry any worthwhile legal weight, technically is it feasible to add a disclaimer to outgoing SMIME messages at the outgoing server without breaking the signature ? The multipart nature of MIME suggests that it is at least plausible to place the disclaimer in its own MIME boundary such that it doesn't interfere with signed portions in the parts of the message that originate at the client. Opinions appreciated. Chris Royal Mail is a trading name of Royal Mail Group plc. Registered in England and Wales. Registered number 4138203. Registered office at 148 Old Street, LONDON EC1V 9HQ This email and any attachments are confidential and intended for the addressee only. If you are not the named recipient, you must not use, disclose, reproduce, copy or distribute the contents of this communication. If you have received this in error, please contact the sender and then delete this email from your system. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1FGHKI25831 for ietf-smime-bks; Sat, 15 Feb 2003 08:17:20 -0800 (PST) Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1FGHId25827 for ; Sat, 15 Feb 2003 08:17:19 -0800 (PST) Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h1FGHF2n012817 for ; Sat, 15 Feb 2003 17:17:15 +0100 (CET) X-Original-Recipient: Message-ID: <00b601c2d50c$4d4d7180$0500a8c0@arport> From: "Anders Rundgren" To: Subject: e-Gov: Distributing confidential information Date: Sat, 15 Feb 2003 17:07:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here are some thoughts regarding how e-governments (and companies) could efficiently distribute confidential information to citizens (or employees). Note: The following discussion only applies to information from an (non-personal) authority to an individual. Claim ------- In spite of being the foundation for many PKI-based ID-programs, I doubt that S/MIME will play any major role in e-government systems as these typically are built as on-line (web-based) services. The problem -------------- Now, in case a government authority is to send you confidential information, I believe they should not use encrypted mail as this will most likely lead to huge support problems with key- distribution, key-expiration etc. A simple remedy --------------------- e-Governments could preferably e-mail the recipient a web-link (or just a notification) that he or she uses to fetch the confidential information with. That is, after the recipient have authenticated to the on-line authority. This scheme is also aligned with an "account-based" authority where you may have tasks in various stages. The "web-way" allowed on-line banks to address the ordinary consumer and is proven to work on a major scale, while signed and encrypted mail is after more than ten years, still very sparsely used. My 2 cents. Anders Rundgren Consultant, PKI and secure e-business +46 70 - 627 74 37 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ELUes22662 for ietf-smime-bks; Fri, 14 Feb 2003 13:30:40 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ELUcd22657 for ; Fri, 14 Feb 2003 13:30:38 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05443; Fri, 14 Feb 2003 16:26:49 -0500 (EST) Message-Id: <200302142126.QAA05443@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ietf-smime@imc.org From: The IESG Subject: Protocol Action: CMS Symmetric Key Management and Distribution to Proposed Standard Date: Fri, 14 Feb 2003 16:26:49 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved the Internet-Draft 'CMS Symmetric Key Management and Distribution' as a Proposed Standard. This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Jeffrey Schiller and Steve Bellovin. Technical Summary This document extends the Cryptographic Message Syntax (CMS) to support the use of symmetric (traditional) encryption in addition to public key encryption. It describes an architecture that can be used by Groups of entities (or Mailing Lists) to securely distribute a Group Key which can be used to symmetrically encrypt CMS objects. Working Group Summary The working group had consensus on this document. Protocol Quality This document has been reviewed for the IESG by Jeff Schiller. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EJGWB16669 for ietf-smime-bks; Fri, 14 Feb 2003 11:16:32 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1EJGVd16665 for ; Fri, 14 Feb 2003 11:16:31 -0800 (PST) Received: (qmail 22980 invoked from network); 14 Feb 2003 19:16:25 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.175.84) by woodstock.binhost.com with SMTP; 14 Feb 2003 19:16:25 -0000 Message-Id: <5.2.0.9.2.20030214141338.0381c130@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Feb 2003 14:16:31 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: draft-housley-cms-fw-wrap-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear S/MIME WG: Since the vast majority of CMS experience exists in the S/MIME working group, I want to make people aware of this Internet-Draft. I would greatly appreciate review and constructive comment. Also, I would like to assign the needed OIDs from the S/MIME working group arc. Does anyone see any reason for them to be assigned elsewhere? Russ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EIp7U15702 for ietf-smime-bks; Fri, 14 Feb 2003 10:51:07 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1EIp6d15698 for ; Fri, 14 Feb 2003 10:51:06 -0800 (PST) Received: (qmail 21647 invoked from network); 14 Feb 2003 18:50:59 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.180.81) by woodstock.binhost.com with SMTP; 14 Feb 2003 18:50:59 -0000 Message-Id: <5.2.0.9.2.20030214135028.03808480@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 14 Feb 2003 13:50:51 -0500 To: Petra Barzin , Denis.Pinkas@bull.net From: Russ Housley Subject: Re: mistake in RFC 3126 Cc: ietf-smime@imc.org, Stephan Klein , pope@secstan.com In-Reply-To: <3E4B64F6.334CFFA3@secude.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This definitely looks like an error to me. Russ At 10:27 AM 2/13/2003 +0100, Petra Barzin wrote: >Hello, > >I think there is a mistake in RFC 3126 - Electronic Signature >Formats for long term electronic signatures. The definition of the >RevocationValues attribute is as follows: > > RevocationValues ::= SEQUENCE { > crlVals [0] SEQUENCE OF CertificateList OPTIONAL, > ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, > otherRevVals [2] OtherRevVals > } > >Shouldn't the other revocation values be optional as well? >Did I miss something or am I right? > >Best regards - Petra Barzin > > > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DNGJc29597 for ietf-smime-bks; Thu, 13 Feb 2003 15:16:19 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1DNGId29593 for ; Thu, 13 Feb 2003 15:16:18 -0800 (PST) Received: (qmail 13145 invoked from network); 13 Feb 2003 23:16:12 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.161.174) by woodstock.binhost.com with SMTP; 13 Feb 2003 23:16:12 -0000 Message-Id: <5.2.0.9.2.20030213120327.02fbcc40@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 13 Feb 2003 18:16:11 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Overhead Projectors at the IETF meeting in San Francisco Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear S/MIME participants: Starting with the IETF meeting in San Francisco, overhead projectors will not be provided in the meeting rooms unless specifically requested. Data projectors will be in all working group and BOF meeting rooms. If you feel there is a need for an overhead projector in our session, please send me a note immediately. Thanks, Russ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DI1ta18953 for ietf-smime-bks; Thu, 13 Feb 2003 10:01:55 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DI1sd18948 for ; Thu, 13 Feb 2003 10:01:54 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20172; Thu, 13 Feb 2003 12:58:11 -0500 (EST) Message-Id: <200302131758.MAA20172@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-hmac-key-wrap-01.txt Date: Thu, 13 Feb 2003 12:58:11 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Wrapping an HMAC key with a Triple-DES Key or an AES Key Author(s) : J. Schaad, R. Housley Filename : draft-ietf-smime-hmac-key-wrap-01.txt Pages : 8 Date : 2003-2-12 The key wrap algorithms defined in [3DES-WRAP] and [AES-WRAP] cover the of wrapping a Triple-DES key with another Triple-DES key and wrapping an AES key with another AES key, respectively. This document specifies two similar mechanisms. One specifies the mechanism for wrapping an HMAC key with a Triple-DES key, and the other specifies the mechanism for wrapping an HMAC key with an AES key. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-hmac-key-wrap-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-hmac-key-wrap-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-hmac-key-wrap-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-13131713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-hmac-key-wrap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-hmac-key-wrap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-13131713.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1D9PSq17053 for ietf-smime-bks; Thu, 13 Feb 2003 01:25:28 -0800 (PST) Received: from linux.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1D9OCd17015 for ; Thu, 13 Feb 2003 01:24:12 -0800 (PST) Received: from remus.intranet.secude.com (remus.intranet.secude.com [192.168.2.2]) by linux.secude.com (Postfix) with ESMTP id 42EA4B564; Thu, 13 Feb 2003 10:24:11 +0100 (CET) Received: from secude.com (pc-yameogo.intranet.secude.com [192.168.3.51]) by remus.intranet.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id Z3LLM93X; Thu, 13 Feb 2003 10:26:51 +0100 Message-ID: <3E4B64F6.334CFFA3@secude.com> Date: Thu, 13 Feb 2003 10:27:18 +0100 From: Petra Barzin X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Denis.Pinkas@bull.net Cc: ietf-smime@imc.org, Stephan Klein , pope@secstan.com Subject: mistake in RFC 3126 Content-Type: multipart/mixed; boundary="------------ED2A3168A497312B1CC7A265" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------ED2A3168A497312B1CC7A265 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I think there is a mistake in RFC 3126 - Electronic Signature Formats for long term electronic signatures. The definition of the RevocationValues attribute is as follows: RevocationValues ::= SEQUENCE { crlVals [0] SEQUENCE OF CertificateList OPTIONAL, ocspVals [1] SEQUENCE OF BasicOCSPResponse OPTIONAL, otherRevVals [2] OtherRevVals } Shouldn't the other revocation values be optional as well? Did I miss something or am I right? Best regards - Petra Barzin --------------ED2A3168A497312B1CC7A265 Content-Type: text/x-vcard; charset=us-ascii; name="barzin.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Petra Barzin Content-Disposition: attachment; filename="barzin.vcf" begin:vcard n:Barzin;Petra tel;fax:+49 61 51-8 28 97-26 tel;work:+49 61 51-8 28 97-30 x-mozilla-html:FALSE url:http://www.secude.com org:SECUDE GmbH adr:;;Dolivostr. 11;Darmstadt;;64293 ;Deutschland version:2.1 email;internet:barzin@secude.com fn:Petra Barzin end:vcard --------------ED2A3168A497312B1CC7A265-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1C3YtR25931 for ietf-smime-bks; Tue, 11 Feb 2003 19:34:55 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C3YCd25902 for ; Tue, 11 Feb 2003 19:34:54 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26725; Tue, 11 Feb 2003 22:30:32 -0500 (EST) Message-Id: <200302120330.WAA26725@ietf.org> To: IETF-Announce: ; Cc: ietf-smime@imc.org From: The IESG SUBJECT: Last Call: Use of the AES Encryption Algorithm in CMS to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 11 Feb 2003 22:30:32 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security Working Group to consider Use of the AES Encryption Algorithm in CMS as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-25. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-06.txt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h154xAf08334 for ietf-smime-bks; Tue, 4 Feb 2003 20:59:10 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h154x9d08329 for ; Tue, 4 Feb 2003 20:59:09 -0800 (PST) Received: (qmail 18403 invoked from network); 5 Feb 2003 04:59:08 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (198.202.64.143) by woodstock.binhost.com with SMTP; 5 Feb 2003 04:59:08 -0000 Message-Id: <5.2.0.9.2.20030204113745.00bb69c8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 04 Feb 2003 16:25:20 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Re: WG Last Call: draft-ietf-smime-rfc2633bis-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have a few comments on draft-ietf-smime-rfc2633bis-03.txt. My comments are divided into technical and editorial. In my opinion, the technical comments ought to be resolved before the document is forwarded to the IESG. TECHNICAL COMMENTS Section 1.1, 4th paragraph. Change "... an S/MIME agent has to follow ..." to "... an S/MIME agent MUST follow ... ." I realize that this MUST statement will appear before section 1.2, but I do not see any other MUST statements that capture this point. Alternatively, insert an appropriate MUST statement elsewhere in the document. Section 2.4. CompressedData needs to be added to the list of content types that are supported. Also, section 2.4.4 should be added to discuss the content type. Section 2.5, 2nd paragraph. CMS requires the inclusion of the contentType and messageDigest signed attributes if any other signed attributes are present. We should include these in the bulleted list. Section 2.5, last paragraph. How do mail list agents fit into this requirement to "display those attributes to the user?" Such devices certainly do not have a user interface, but they must include mlExpansionHistory. Section 2.5.2, 6th paragraph. Please reword: "The OIDs used with S/MIME are assigned in several different RFCs; however, all OIDs associated with the MUST and SHOULD implement algorithms are included in Appendix A of this document." Section 3.4.3.2, micalg table. Please add SHA-256, SHA-384, and SHA-512 to avoid the need for future updates. A reference to FIPS 180-2 will be needed. Section 3.8, last paragraph. Please reword as follows: "S/MIME v2 [SMIMEV2] specified a method for "registering" public keys with certificate authorities using an application/pkcs10 body part. Since that time, the IETF PKIX Working Group has developed other methods for requesting certificates. However, S/MIME v3.1 does not require a particular certificate request mechanism." EDITORIAL COMMENTS General. Please change "CMS objects" to "CMS content types" throughout the specification. Section 1.1, 2nd paragraph. Remove the extra space from "application/pkcs7- mime." Section 1.3. Please add references for X.208, X.209, and X.509, including the date of the version that is being referenced. I suspect that the same ones that are used in [CMS] should be referenced. Section 2.5. Please reword the 3rd paragraph, as follows: "Further, receiving agents SHOULD be able to handle zero or one instance in the signingCertificate signed attribute, as defined in section 5 of [ESS]." Section 2.5.2, 3rd paragraph. Change "OIDs" to "object identifiers (OIDs)." Section 2.6. This paragraph should talk about S/MIME v3.1 as well as S/MIME v3. Section 2.7.1.2. Change the first part of the first sentence to: "If the following three conditions are met:" Section 2.7.1.3. Change the first part of the first sentence to: "If the following two conditions are met:" Section 3, 1st paragraph. Please change "CMS objects" to "CMS content types." This is used several places. Section 3.1, 1st paragraph. Add a forward pointer to the processing that is used when RFC 822 headers need protection. Section 3.1.3, 1st paragraph. The word "EVER" does not have a reserved meaning in RFC 2119. Please change it to lower case. Section 3.2, 1st paragraph. Remove the extra space from "application/pkcs7- mime type." Section 3.2.2, 1st paragraph. Remove the extra space from "smime- types." Section 3.2,2, 3rd paragraph. Remove the extra space from "encrypted- *." Section 3.6, 1st paragraph. Please reword as: "The signed-only, encrypted-only, and compressed-only MIME formats can be nested. This works because these formats are all MIME entities that encapsulate other MIME entities." Section 3.9, 1st paragraph, last sentence. Please reword as follows: "A message is considered an S/MIME message if it matches any of the criteria listed below." Russ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h14FFLb12761 for ietf-smime-bks; Tue, 4 Feb 2003 07:15:21 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h14FFKd12757 for ; Tue, 4 Feb 2003 07:15:20 -0800 (PST) Received: (qmail 27578 invoked from network); 4 Feb 2003 15:15:07 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.39.35) by woodstock.binhost.com with SMTP; 4 Feb 2003 15:15:07 -0000 Message-Id: <5.2.0.9.2.20030204101126.02d9ccb8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 04 Feb 2003 10:15:09 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: WG Last Call: draft-ietf-smime-rfc2633bis-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear S/MIME WG: This message announces Working Group Last Call for the update to the MSG specification. Title : S/MIME Version 3.1 Message Specification Author(s) : Blake Ramsdell Filename : draft-ietf-smime-rfc2633bis-03.txt Date : January 16, 2003 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2633bis-03.txt The intent is to publish the pdate to the MSG specification as a Standards Track RFC, superseding RFC 2633. Please review this draft and post any comments to the ietf-smime@imc.org mail list by Monday, 17 February 2003. Unless traffic on the mail list indicates otherwise, I will send these to the IESG shortly after WG Last Call closes. Russ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h11IkEW10734 for ietf-smime-bks; Sat, 1 Feb 2003 10:46:14 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h11IkDo10727 for ; Sat, 1 Feb 2003 10:46:13 -0800 (PST) Received: (qmail 16284 invoked from network); 1 Feb 2003 18:46:11 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.162.139) by woodstock.binhost.com with SMTP; 1 Feb 2003 18:46:11 -0000 Message-Id: <5.2.0.9.2.20030201134403.022f1ad0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 01 Feb 2003 13:46:11 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: S/MIME WG Agenda for 56th IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The 56th IETF will be held in San Francisco, CA on 16-21 March 2003. I have asked for a one-hour meeting slot for the S/MIME WG. Please send me agenda topics. Russ