From iov1ccxre@terra.es Fri Oct 3 20:39:23 2003 Received: from 132.151.1.176 (CacheFlowServer@wc2.rit.ac.th [202.44.130.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05582 for ; Fri, 3 Oct 2003 20:39:20 -0400 (EDT) Received: from [43.72.117.95] by 132.151.1.176 SMTP id M8X2k16nva4GjQ for ; Fri, 03 Oct 2003 19:33:03 +0600 Message-ID: <3jb56nh-5e3vy-xx$g8s8ndqv2sxs3@a6q1lj176nta6k> From: "Katina Palacios" Reply-To: "Katina Palacios" To: smime-archive@ietf.org Subject: RE:inexpiable Hoooo j kyswgk xsmio Date: Fri, 03 Oct 2003 19:33:03 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="DCF.EB.B_.4_3.._ECADF" --DCF.EB.B_.4_3.._ECADF Content-Type: text/html; Content-Transfer-Encoding: base64 DQoNCjxwPjxmb250IHNpemU9IjEiPnFmYmZ4dXByZnpjZG5kb3N5DQoga2hrIA0KZXp6bHZ3 eGhtDQp0ancgZGVpdW9qag0KcHpzdTwvZm9udD4NCg0KPHA+Jm5ic3A7DQoNCjxwPkhJLFNt aW1lLWFyY2hpdmUNCg0KPHRhYmxlIGJvcmRlcj0iMCIgd2lkdGg9IjU3JSIgY2VsbHNwYWNp bmc9IjAiPg0KICA8dHI+DQogICAgPHRkIHdpZHRoPSIxMDAlIj4NCiAgICAgIDxwIGFsaWdu PSJjZW50ZXIiPjxiPg0KPGltZyBoZWlnaHQ9IjUwIiBzcmM9Imh0dHA6Ly93d3cuZWhvc3R6 ei5jb20vQ0QvZmFjZS5qcGciIHdpZHRoPSI1MCIgYm9yZGVyPSIwIj4NCiAgICAgIDwvYj48 Zm9udCBzaXplPSIzIj5JDQogICAgICBoYXZlIGJlZW4gcmVjZWl2aW5nIGVtYWlscyBzYXlp bmcgdGhhdCBJJ20gY29udHJpYnV0aW5nIHRvIHRoZSAmcXVvdDttb3JhbA0KICAgICAgZGVj YXkgb2Ygc29jaWV0eSZxdW90OyBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQyBELiBUaGF0IG1h eSBiZSwgYnV0IEkgZmVlbA0KICAgICAgU3Ryb25nbHkgdGhhdCB5b3UgaGF2ZSBhIHJpZ2h0 IHRvIGJlbmVmaXQgZnJvbSB0aGlzIGhhcmQtdG8tZmluZA0KICAgICAgaW5mb3JtYXRpb24u IFNvIEkgYW0gZ2l2aW5nIHlvdSBPTkUgTEFTVCBDSEFOQ0UgdG8gb3JkZXIgdGhlIEJhbm5l ZCBDIEQhDQogICAgICBXaXRoIHRoaXMgcG93ZXJmdWwgQyBELCB5b3Ugd2lsbCBiZSBhYmxl IHRvIGludmVzdGlnYXRlIHlvdXIgZnJpZW5kcywNCiAgICAgIGVuZW1pZXMgYW5kIGxvdmVy cyBpbiBqdXN0IG1pbnV0ZXMgdXNpbmcgdGhlIEludGVybmV0LiBZb3UgY2FuIHRyYWNrIGRv d24NCiAgICAgIG9sZCBmbGFtZXMgZnJvbSBjb2xsZWdlLCBvciB5b3UgY2FuIGRpZyB1cCBz b21lIGRpcnQgb24geW91ciBib3NzIHRvIG1ha2UNCiAgICAgIHN1cmUgeW91IGdldCB0aGF0 IG5leHQgcHJvbW90aW9uISA8YnI+DQogICAgICBPciBtYXliZSB5b3Ugd2FudCBhIGZha2Ug ZGlwbG9tYSB0byBoYW5nIG9uIHlvdXIgYmVkcm9vbSB3YWxsLiBZb3UnbGwgZmluZA0KICAg ICAgYWRkcmVzc2VzIGZvciBjb21wYW5pZXMgdGhhdCBtYWtlIHRoZXNlIGRpcGxvbWFzIG9u IHRoZSBCYW5uZWQgQyBELiBOZWVkIHRvDQogICAgICBkaXNhcHBlYXIgZmFzdCBhbmQgbmV2 ZXIgbG9vayBiYWNrPyBObyBwcm9ibGVtISBVc2luZyB0aGUgQmFubmVkQ0QsIHlvdQ0KICAg ICAgd2lsbCBsZWFybiBob3cgdG8gYnVpbGQgYSBjb21wbGV0ZWx5IG5ldyBpZGVudGl0eS4g T2J2aW91c2x5LCB0aGUgUG93ZXJzDQogICAgICBUaGF0IEJlIGRvbid0IHdhbnQgeW91IHRv IGhhdmUgdGhlIEJhbm5lZENELiBUaGV5IGhhdmUgdGhyZWF0ZW5lZCBtZSB3aXRoDQogICAg ICBsYXdzdWl0cywgZmluZXMsIGFuZCBldmVuIGltcHJpc29ubWVudCB1bmxlc3MgSSBzdG9w IHNlbGxpbmcgaXQNCiAgICAgIGltbWVkaWF0ZWx5LiBCdXQgSSBmZWVsIHRoYXQgWU9VIGhh dmUgYSBDb25zdGl0dXRpb25hbCByaWdodCB0byBhY2Nlc3MNCiAgICAgIHRoaXMgdHlwZSBv ZiBpbmZvcm1hdGlvbiwgYW5kIEkgY2FuJ3QgYmUgaW50aW1pZGF0ZWQuIFVuY2xlIFNhbSBh bmQgeW91cg0KICAgICAgY3JlZGl0b3JzIGFyZSBob3JyaWZpZWQgdGhhdCBJIGFtIHN0aWxs IHNlbGxpbmcgdGhpcyBwcm9kdWN0ISBUaGVyZSBtdXN0DQogICAgICBiZSBhIHByaWNlIG9u IG15IGhlYWQhIDxicj4NCiAgICAgIFdoeSBhcmUgdGhleSBzbyB1cHNldD8gQmVjYXVzZSB0 aGlzIEMgRCBnaXZlcyB5b3UgZnJlZWRvbS4gQW5kIHlvdSBjYW4ndA0KICAgICAgYnV5IGZy ZWVkb20gYXQgeW91ciBsb2NhbCBXYWxtYXJ0LiBZb3Ugd2lsbCBoYXZlIHRoZSBmcmVlZG9t IHRvIGF2b2lkIFpyZWRpdG9ycywganVkZ21lbnRzLCBsYXdzdWl0cywgSVJTIHRheCBjb2xs ZWN0b3JzLCBjcmltaW5hbCBpbmRpY3RtZW50cywNCiAgICAgIHlvdXIgZ3JlZWR5IGV4LXdp ZmUgb3IgZXgtaHVzYmFuZCwgYW5kIE1VQ0ggbW9yZSE8L2ZvbnQ+PC9wPg0KICAgICAgPHAg YWxpZ249ImNlbnRlciI+PGI+PGJyPg0KICAgICAgPC9iPg0KICAgICAgPGEgaHJlZj0iaHR0 cDovL3d3dy5laG9zdHp6LmNvbS9DRC8iPg0KPGZvbnQgc2l6ZT0iMyI+c2VlIG5vdzwvZm9u dD48L2E+PC9wPg0KICAgICAgPGRpdiBhbGlnbj0ibGVmdCI+PGZvbnQgc2l6ZT0iMSI+dnN3 ZHVqeWsNCmJncXlqY2NtZyBidWRmcGxnZG4gbA0KdiBnaSBza2wgZnljcW9xY2RiZ3FiICBx IGNranZhIGx0YWkgIGFnc3ByYmdqIHVxY2x6bg0KIHU8L2ZvbnQ+DQogICAgICAgIDxmb250 IGZhY2U9IkFyaWFsIiBzaXplPSIxIj4mbmJzcDs8Zm9udCBjb2xvcj0iIzAwMDAwMCI+IA0K ICAgICAgICA8YSBocmVmPSJodHRwOi8vd3d3Lm1vdmVhaGVhc3Nkc2RmMjMzLmNvbS9EYnQv cmUucGhwIj4NCm4gbyBtIGEgaSBsPC9hPjwvZm9udD48L2ZvbnQ+DQogICAgICA8L2Rpdj4N CiAgICA8L3RkPg0KICA8L3RyPg0KPC90YWJsZT4NCjxmb250IHNpemU9IjEiPmV4Y2VwdDwv Zm9udD4NCmJzeGFpZnFrYm94dnIgcnUNCmoNCmlpcnNmcncgIHMgZiB4ZHRjZHEgc2M= --DCF.EB.B_.4_3.._ECADF-- From t_seals_xv@minedu.fi Mon Oct 6 08:01:41 2003 Received: from vrflow.oulu.fi (200-168-58-53.dsl.telesp.net.br [200.168.58.53]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26392 for ; Mon, 6 Oct 2003 08:01:38 -0400 (EDT) Message-ID: From: "Terrie Seals" To: smime-archive@ietf.org Subject: *_Boost your -P-E'N:I"S: LEN;GTH' k uqlirncpg Date: Tue, 07 Oct 2003 03:17:23 +0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/html Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit
The only solution to Penis Enlargement
iuvzxvdopte xcpojqbgxx
ONLY THIS WEEK: Add at least 3 INCHES or get your money back!
jfhvwuqdnlad yqowrrcijt
We are so sure our product works we are willing to prove it by offering a free trial bottle + a 100% money back guarantee upon purchase if you are not satisfied with the results.

---> Click Here To Learn More <---
wrpifobxvdoi qdxivxlgcr

lolhvhbfenvzm zlcvuhcwhwh


wjjotybfaoue ezmknhbrkmdkp
No more offers From subs-reminder@imc.org Tue Oct 7 01:12:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06416 for ; Tue, 7 Oct 2003 01:12:52 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h975CtKP027286 for ; Mon, 6 Oct 2003 22:12:55 -0700 (PDT) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h975CtaH027284; Mon, 6 Oct 2003 22:12:55 -0700 (PDT) Date: Mon, 6 Oct 2003 22:12:55 -0700 (PDT) Message-Id: <200310070512.h975CtaH027284@above.proper.com> To: smime-archive@ietf.org Subject: [[083100537]] Subscription to ietf-smime for smime-archive@lists.ietf.org Greetings. This message is a periodic reminder that smime-archive@lists.ietf.org is subscribed to the ietf-smime mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-smime mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-smime-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "smime-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-smime@mail.imc.org Mon Oct 13 11:45:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12119 for ; Mon, 13 Oct 2003 11:45:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFCgI7036009 for ; Mon, 13 Oct 2003 08:12:42 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DFCgeM036008 for ietf-smime-bks; Mon, 13 Oct 2003 08:12:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFCfI7036002 for ; Mon, 13 Oct 2003 08:12:41 -0700 (PDT) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1A94Ly-00052L-Hk; Mon, 13 Oct 2003 11:11:22 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'Securing X.400 Content with S/MIME' to Proposed Standard Message-Id: Date: Mon, 13 Oct 2003 11:11:22 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved following documents: - 'Securing X.400 Content with S/MIME ' as a Proposed Standard - 'Transporting S/MIME Objects in X.400 ' as a Proposed Standard These documents are products of the S/MIME Mail Security Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary These documents describe the use of the S/MIME security mechanisms in an X.400 messaging environment. "Securing X.400 Content with S/MIME" describes the use of the Cryptographic Message Syntax (CMS) to digital signature and encryption services to X.400 content. "Transporting S/MIME Objects in X.400" describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. Working Group Summary The S/MIME Working Group came to consensus on these documents. Protocol Quality These documents were reviewed by Jeff Schiller and Russell Housley for the IESG. From gbrbq2tn@erols.com Mon Oct 20 13:57:15 2003 Received: from dial-200.58.187.161.cotas.com.bo (dial-200.58.187.161.cotas.com.bo [200.58.187.161]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05745; Mon, 20 Oct 2003 13:56:31 -0400 (EDT) Message-ID: <48163423e7kp517q03mb7796g9gt@4jdexz> From: "Carolyn John" Reply-To: "Carolyn John" To: sigtran@ietf.org Cc: , , , , , Subject: Fwd: flat abs guaranteed Date: Tue, 21 Oct 2003 10:49:01 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="D9ACB6DC_2AC1ABBAB" --D9ACB6DC_2AC1ABBAB Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document

Want to look younger, have m= ore energy + lose weight in three weeks?

This proven discovery has be= en reported on by the New England Journal of Medicine. Forget aging and dietin= g forever. And it's Guaranteed.
WOULD YOU LIKE TO LOSE WEIGHT WHILE YOU SLE= EP?
No dieting.
No hunger pains.
No Cravings.
No strenuous exercise.
Change your life forever.

Go Here to Receive a Full Month's Supply Absolutely FREE

 
You are receiving this message as a member of the Opt-In
America List. To be taken out of the data base please
go here. We honor all remove requests. sg zbqhnr ojyieoq pjv --D9ACB6DC_2AC1ABBAB-- From owner-ietf-smime@mail.imc.org Mon Oct 20 16:37:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03529 for ; Mon, 20 Oct 2003 16:37:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KJkUI7006297 for ; Mon, 20 Oct 2003 12:46:31 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KJkUXM006296 for ietf-smime-bks; Mon, 20 Oct 2003 12:46:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KJkTI7006291 for ; Mon, 20 Oct 2003 12:46:29 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22554; Mon, 20 Oct 2003 15:46:21 -0400 (EDT) Message-Id: <200310201946.PAA22554@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-examples-12.txt Date: Mon, 20 Oct 2003 15:46:21 -0400 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 : Examples of S/MIME Messages Author(s) : P. Hoffman Filename : draft-ietf-smime-examples-12.txt Pages : 8 Date : 2003-10-20 This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects, S/MIME messages (including the MIME formatting), and Enhanced Security Services for S/MIME (ESS). It includes examples of most or all common CMS and ESS formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-12.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-examples-12.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-examples-12.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-10-20151858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-examples-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-examples-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-20151858.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Tue Oct 21 17:19:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10175 for ; Tue, 21 Oct 2003 17:19:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKh6I7039495 for ; Tue, 21 Oct 2003 13:43:06 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LKh6lV039494 for ietf-smime-bks; Tue, 21 Oct 2003 13:43:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKh1I7039479 for ; Tue, 21 Oct 2003 13:43:02 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07654; Tue, 21 Oct 2003 16:42:52 -0400 (EDT) Message-Id: <200310212042.QAA07654@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-gost-00.txt Date: Tue, 21 Oct 2003 16:42:52 -0400 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 : Cryptographic Message Syntax (CMS) algorithms for GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94. Author(s) : S. Leontiev, et. al. Filename : draft-ietf-smime-gost-00.txt Pages : 26 Date : 2003-10-20 This document describes the conventions for using cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, along with Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication and encryption arbitrary message contents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-gost-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-gost-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-gost-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-10-21164257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-gost-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-gost-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21164257.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Thu Oct 23 06:00:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10916 for ; Thu, 23 Oct 2003 06:00:59 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N9KtI7053593 for ; Thu, 23 Oct 2003 02:20:55 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9N9KtJC053592 for ietf-smime-bks; Thu, 23 Oct 2003 02:20:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N9KgI7053583 for ; Thu, 23 Oct 2003 02:20:42 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Thu, 23 Oct 2003 02:10:06 -0700 From: "Blake Ramsdell" To: Cc: Subject: SEED algorithm Internet-Draft Date: Thu, 23 Oct 2003 02:10:06 -0700 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.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit An individual internet-draft has been submitted documenting the use of the SEED encryption algorithm in CMS. We will be discussing this draft at IETF 58, and if there are no objections, this draft will become a draft of the working group. Title: Use of the SEED Encryption Algorithm in CMS Authors: Jongwook Park (KISA), Sungjae Lee (KISA), Jinsu Hyun (KISA), Jaeil Lee (KISA) Abstract: This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS). http://www.ietf.org/internet-drafts/draft-park-cms-seed-00.txt Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com From owner-ietf-smime@mail.imc.org Thu Oct 23 08:26:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15523 for ; Thu, 23 Oct 2003 08:26:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NBoaI7059959 for ; Thu, 23 Oct 2003 04:50:36 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NBoata059958 for ietf-smime-bks; Thu, 23 Oct 2003 04:50:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9NBoZI7059953 for ; Thu, 23 Oct 2003 04:50:35 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 16536 invoked by uid 0); 23 Oct 2003 11:50:30 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.188.89) by woodstock.binhost.com with SMTP; 23 Oct 2003 11:50:30 -0000 Message-Id: <5.2.0.9.2.20031023074902.0461ee40@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 23 Oct 2003 07:50:33 -0400 To: "Blake Ramsdell" , From: Russ Housley Subject: Re: SEED algorithm Internet-Draft Cc: In-Reply-To: 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: Blake: There must be a normative reference to the algorithm itself. Without such a reference, implementors will not have all of the information needed to do their job. Russ At 02:10 AM 10/23/2003 -0700, Blake Ramsdell wrote: >An individual internet-draft has been submitted documenting the use of >the SEED encryption algorithm in CMS. We will be discussing this draft >at IETF 58, and if there are no objections, this draft will become a >draft of the working group. > >Title: Use of the SEED Encryption Algorithm in CMS > >Authors: Jongwook Park (KISA), Sungjae Lee (KISA), Jinsu Hyun (KISA), >Jaeil Lee (KISA) > >Abstract: This document specifies the conventions for using the SEED >encryption algorithm for encryption with the Cryptographic Message >Syntax (CMS). > >http://www.ietf.org/internet-drafts/draft-park-cms-seed-00.txt > >Blake >-- >Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com From owner-ietf-smime@mail.imc.org Sun Oct 26 05:12:30 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13551 for ; Sun, 26 Oct 2003 05:12:29 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q9e4I7003421 for ; Sun, 26 Oct 2003 01:40:04 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9Q9e4vV003420 for ietf-smime-bks; Sun, 26 Oct 2003 01:40:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q9e2I7003378 for ; Sun, 26 Oct 2003 01:40:03 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Sun, 26 Oct 2003 01:39:57 -0800 From: "Blake Ramsdell" To: , Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04 Date: Sun, 26 Oct 2003 01:39:57 -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 In-Reply-To: <001a01c35155$48f4ab10$8b40a051@augustcellars.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad > Sent: Wednesday, July 23, 2003 1:02 PM > To: 'Blake Ramsdell'; ietf-smime@imc.org > Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04 > > Comments are on the -05 version of the document. > > 1. Section 1.4 talks about version 3 not version 3.1 agents. Updated: S/MIME version 3.1 agents should attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive and S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive. RFC 2311 also has historical information about the development of S/MIME. > 2. Section 2.1: Given your request for manditory inclusion of hash > algorithms in DigestAlgorithmIdentifier, is there a reason you don't > make population here atleast a SHOULD if not a MUST? Well, if you're referring to my position on 5/5/03, I believe this field to be valueless, so it doesn't matter to me. Not changed unless there's some new information that I am missing. > 3. Section 2.2: There is no techincal reason that an S/MIME v2 client > cannot be augmented to verify an id-dsa-with-sha1 signature. This > statement should be that S/MIME v2 clients are only REQUIRED to > implement rsaEncryption with either SHA-1 or MD5. Updated: Also note that S/MIME v2 clients are only required to verify digital signatures using the rsaEncryption algorithm with SHA-1 or MD5, and may not implement id-dsa-with-sha1 at all. > 4. Section 2.2: The required hash algorithms supported with > rsaEncryption needs to be noded as part of this section. Updated: If using rsaEncryption, sending and receiving agents MUST support the algorithms in section 2.1 as specified. > 5. Section 2.3: Agents should support ES Diffie-Hellman. SS is not a > requirement. Updated: Sending and receiving agents SHOULD support Diffie-Hellman defined in [CMSALG], using the ephemeral-static mode. > 6. Section 2.4: CMS does not define the CompressedData content type > last time I checked. Updated: There are several CMS content types. Of these, only the Data, SignedData, EnvelopedData and CompressedData content types are currently used for S/MIME. > 7. Section 2.4.4: Is there a reason why there is not any text > describing when one should and when one should not compress > data? (i.e. > don't compress after encryption). Add reference to section 3.6? Updated: See section 3.6 for further guidance on the use of this type in conjunction with other CMS types. > 8. Section 2.5: The text "Sending agents SHOULD generate > one instance > of the signingCertificate > signed attribute in each S/MIME message." should state > "signed attribute > in each SignerInfo structure". Updated: Sending agents SHOULD generate one instance of the signingCertificate signed attribute in each SignerInfo structure. > 9. Section 2.5.2, para 4: I would like to have the following text > added. " > Because of the requirement for identical encoding, individuals > documenting algorithms to be used in the SMIMECapabilities attribute > should explicitly document the correct byte sequence for the common > cases." Updated: The structure of the SMIMECapabilities attribute is to facilitate simple table lookups and binary comparisons in order to determine matches. For instance, the DER-encoding for the SMIMECapability for DES EDE3 CBC MUST be identically encoded regardless of the implementation. Because of the requirement for identical encoding, individuals documenting algorithms to be used in the SMIMECapabilities attribute should explicitly document the correct byte sequence for the common cases. > 10. Section 2.5.2, para 5: I think we need to remove the "In the case > of symmetric algorithms," phrase from this paragraph. The need for > dealing with parameters can occur for other algorithms such > as OAEP, KEM > and PSS. It may be necessary to distinguish more explicitly between > algorithm parameters such as rounds and block size as oppose > to the IV. Updated: For any capability, the associated parameters for the OID MUST specify all of the parameters necessary to differentiate between two instances of the same algorithm. For instance, the number of rounds and block size for RC5 must be specified in addition to the key length. > 11. Section 2.5.2 - where do we document SMimeCapabilities for RC2? > Should be a 40-bit vs 128-bit difference between these which needs an > ASN.1 structure and encoding. Based on reading of this > document I could > not correctly encode these values. I believe that this definition should be in the CMSALG document (but it's not). Should we bite the bullet and just stick it in this one? I agree that it needs to be specified somewhere, but I feel a bit icky about sticking it in here. > 12. Section 2.5.3, last para: what happended to the clock skew text > for SMIMECapabiltlies that clarifies what this sentence refers to? -- > found it in section 2.7.1 - not immediately apparent should have some > type of reference in either 2.5.2 or 2.5.3 or both. Updated 2.5.2: Section 2.7.1 explains a strategy for caching capabilities. Updated 2.5.3: Section 2.7.1 explains a strategy for caching preference data. > 13. Section 2.7.1, para 2: Change reference to section 2.5.2 Updated. > 14. Section 2.7.1.2: Should we remove this paragraph? It does not > really follow from the fact that you recived a signed (by me) then > encrypted message that I was actually the party that enrypted the > message. It could have been an DOS attacker, a gateway, an MLA and so > forth. Removed. I agree -- there is no way to know if a message that comes in that has encryption applied after the signature has any relationship to the signer. > 15. Section 2.7.1.3: Need to be updated to comment on AES. I see your point. The intent is to fall back to something useful for any version of S/MIME, and the older evil US-only RC2/40 clients. It's not clear what discussion you'd have about AES here. It may be the case that this rule should be removed completely. Comments? Not changed, but needs discussion. > 16. Section 3.1, last para: I would like to see some additional > comments provided to help people make the decision between a message > that is protecting the headers and a message which is an attachment. Added: When an S/MIME message is received, if the top-level protected MIME entity has a Content-Type of message/rfc822, it can be assumed that the intent was to provide header protection. This entity should be presented as the top-level message, taking into account header merging issues as previously discussed. > 17. Section 3.1.2 para 3: Change the "SHOULD NOT use 7-bit" > to "SHOULD > use binary" to make a positive rather than a negative statement. This was discussed in private mail also, and I believe that the following is reasonable text to put in. Updated: S/MIME implementations which "know" that all intended recipient(s) are capable of handling inner (all but the outermost) binary MIME objects SHOULD use binary encoding as opposed to a 7-bit-safe transfer encoding for the inner entities. The use of a 7-bit-safe encoding (such as base64) would unnecessarily expand the message size. Implementations MAY "know" that recipient implementations are capable of handling inner binary MIME entities either by interpreting the id-cap-preferBinaryInside sMIMECapabilities attribute, by prior agreement, or by other means. > 18. Section 3.1, General: Do you need to canonicalize before you > compress? I'm gonna say "yes". Updated: Each MIME entity MUST be converted to a canonical form that is uniquely and unambiguously representable in the environment where the signature is created and the environment where the signature will be verified. MIME entities MUST be canonicalized for enveloping and compressing as well as signing. > 19. Section 3.2.1: Can we really justify limiting the file name to > eight characters any more? All common windows platforms no > longer have > this restriction. Apple and Unix platforms have not had this > restriction for a long time (if ever). It's a SHOULD, so if you really wanna have more, go for it. > 20. Section 3.2.2: I would like to get some rewrites on this section > as to the purpose of S/MIME type. I think it is JUST to provide > information about the information (misspelt in the document) about the > contained content. It just happens that for display via UAs, the > distinction between signed and enveloped was consisted to be an > important part of the content. Additionally, I think this is the > correct direction for us to tell people about how to define new > smime-types in the future. > > The next question is weither a compressed only message would > show up in > my mailbox. I think that the correct smime-type for a compressed and > signed message is actually signed-data not compressed data. So I think your position is that the smime-type should have the "most relevant interpretation of the protected data", instead of the "actual type that is being protected". I think the best example is an IMAP client getting the headers and changing the icon next to the message to indicate what kind of message you've got. We can ask the audience, but I think that the conventional wisdom is that the smime-type represents the type of the outermost layer, and that's it -- just a further clarification of the overloaded application/pkcs7-mime. Fixed speling of information, but I want to hear more about how else we should change this to clarify the semantic (and what the semantic is). > 21. Section 3.4.1, last para: Currently this reads > > Messages signed using the signedData format cannot be viewed by a > recipient unless they have S/MIME facilities. However, if they have > S/MIME facilities, these messages can always be verified if they were > not changed in transit. > > But duh for the last sentence. The correct statement would be. > "However, the signedData format protects the message content > from being > changed by benign intermediate agents. Such agents might do line > wrapping or content-transfer encoding changes which would break the > signature." Indeed, duh for the last sentence. Updated: Messages signed using the signedData format cannot be viewed by a recipient unless they have S/MIME facilities. However, the signedData format protects the message content from being changed by benign intermediate agents. Such agents might do line wrapping or content-transfer encoding changes which would break the signature. > 22. Section 3.4.3.2, algorithm table: The last item in the > table needs > to be removed. The corect answer is that this value needs to > be defined > by documents describing other hashing algorithms. Updated: Any other (defined separately in algorithm profile or "unknown" if not defined) > 23. Section 3.4.3.3: Just for giggles, I think that adding a section > with the hex encoding of the acutal bytes hashed for this sample would > be a good idea. This is one of the things people always have problems > with when doing multipart signed data. Also it might be > interesting to > make the body a multipart/alternative. On the other hand this would > probably be better in an appendix. I think that getting too far with the examples should be left to the Examples draft and any successors. I do agree that adding the hex dump would be a good idea. My attempt at the hex dump is this, but I need at least one other person to double check it. Updated: The content that is digested (the first part of the multipart/signed) are the bytes: 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a > 24. Section 4: Reference to [CERT3] needs updating. Updated to [CERT31]. > 25. Section 4.1: Language and protocol statements needs to be updated > in this section to reflect the change in algorithms. Updated. Complete section is now: 4.1 Key Pair Generation All generated key pairs MUST be generated from a good source of non- deterministic random input [RANDOM] and the private key MUST be protected in a secure fashion. If an S/MIME agent needs to generate an RSA key pair, then the S/MIME agent or some related administrative utility or function SHOULD generate RSA key pairs using the following guidelines. A user agent SHOULD generate RSA key pairs at a minimum key size of 768 bits. A user agent MUST NOT generate RSA key pairs less than 512 bits long. Creating keys longer than 1024 bits may cause some older S/MIME receiving agents to not be able to verify signatures, but gives better security and is therefore valuable. A receiving agent SHOULD be able to verify signatures with keys of any size over 512 bits. Some agents created in the United States have chosen to create 512 bit keys in order to get more advantageous export licenses. However, 512 bit keys are considered by many to be cryptographically insecure. Implementors should be aware that multiple (active) key pairs may be associated with a single individual. For example, one key pair may be used to support confidentiality, while a different key pair may be used for authentication. > 26. Appendix B: Refernces need to be divided. I'm not sure what you mean by "divided"... Blake From owner-ietf-smime@mail.imc.org Sun Oct 26 21:25:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08497 for ; Sun, 26 Oct 2003 21:25:25 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R1rlI7049319 for ; Sun, 26 Oct 2003 17:53:47 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9R1rl52049318 for ietf-smime-bks; Sun, 26 Oct 2003 17:53:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R1rkI7049310 for ; Sun, 26 Oct 2003 17:53:46 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Sun, 26 Oct 2003 17:53:43 -0800 From: "Blake Ramsdell" To: "'Peter Gutmann'" , Cc: Subject: RE: Request change in son-of-rfc2633 Date: Sun, 26 Oct 2003 17:53:42 -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 In-Reply-To: <200309171321.h8HDLTM11854@cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Peter Gutmann > Sent: Wednesday, September 17, 2003 6:21 AM > To: jimsch@exmsft.com > Cc: ietf-smime@imc.org > Subject: Re: Request change in son-of-rfc2633 > > "Jim Schaad" writes: > > >Messages that use this choice cannot be read by S/MIME v2 > clients, but are > >not to cause crashes in S/MIME v3.1 clients." > > I'm having some trouble parsing this... does this mean the > RFC is specifying > that S/MIME clients aren't allowed to crash? How is this enforced? The language that has been added is as follows: S/MIME v3.1 implementations MUST allow for the use of the choice of subjectKeyIdentifier in messages. Messages that use this choice cannot be read by S/MIME v2 clients, and MUST be handled gracefully in S/MIME v3.1 clients. So I imagine that we're now chartered with enforcing them to be graceful vs. enforcing them to not crash ;). Blake From owner-ietf-smime@mail.imc.org Sun Oct 26 21:26:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08529 for ; Sun, 26 Oct 2003 21:26:32 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R1sgI7049369 for ; Sun, 26 Oct 2003 17:54:42 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9R1sgXc049368 for ietf-smime-bks; Sun, 26 Oct 2003 17:54:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R1sfI7049356 for ; Sun, 26 Oct 2003 17:54:41 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Sun, 26 Oct 2003 17:54:39 -0800 From: "Blake Ramsdell" To: , Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-03 Date: Sun, 26 Oct 2003 17:54:38 -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 In-Reply-To: <001d01c35155$4c558950$8b40a051@augustcellars.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Wednesday, July 23, 2003 1:02 PM > To: 'Blake Ramsdell'; ietf-smime@imc.org > Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-03 > > 1. Section 1.2: Does this need to be updated to refer to version 3.1 > agents as well? Updated: S/MIME version 3.1 agents should attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive and S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive. RFC 2311 also has historical information about the development of S/MIME. > 2. References need to be divided. Still missing what this means. > 3. Acknowlegements is [TBD] Updated: Many thanks go out to the other authors of the S/MIME v2 RFC: Steve Dusse, Paul Hoffman and Jeff Weinstein. Without v2, there wouldn't be a v3. A number of the members of the S/MIME Working Group have also worked very hard and contributed to this document. Any list of people is doomed to omission and for that I apologize. In alphabetical order, the following people stand out in my mind due to the fact that they made direct contributions to this document. Bill Flanigan Trevor Freeman Elliott Ginsburg Paul Hoffman Russ Housley David P. Kemp Michael Myers John Pawling Denis Pinkas Jim Schaad > 4. Section at beginning of document on changes since RFC2632 is > required. Added: 1.4 Changes Since S/MIME v3.0 Version 1 and Version 2 CRLs MUST be supported. Multiple CA certificates with the same subject and public key, but with overlapping validity periods MUST be supported. Version 2 attribute certificates SHOULD be supported, and version 1 attributes certificates MUST NOT be used. MD2 use for certificate signatures discouraged, and security language added. Clarified use of email address use in certificates. Certificates that do not contain an email address have no requirements for verifying the email address associated with the certificate. Receiving agents SHOULD display certificate information when displaying the results of signature verification. Receiving agents MUST NOT accept a signature made with a certificate that does not have the digitalSignature or nonRepudiation bit set. Clarifications for the interpretation of the key usage and extended key usage extensions. > 5. KEYMAC as a reference sent me to keyed macs, not to key management > for ACs. Are you saying that you were personally confused about the use of the reference term KEYMAC? Updated: Reference name changed from KEYMAC to ACAUTH. > 6. Section 4.4.2 - Key Usage is not a required extension. > What happens > in para #4 if the extension is not present. Does this imply that the > bits are set? I have no idea, since no one's really been able to explain the difference between these two bits anyway. Updated: If the key usage extension is not specified, receiving clients MUST presume that the digitalSignature and nonRepudiation bits are set. Blake From owner-ietf-smime@mail.imc.org Sun Oct 26 21:51:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09243 for ; Sun, 26 Oct 2003 21:51:49 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R2OSI7051146 for ; Sun, 26 Oct 2003 18:24:28 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9R2OS6C051145 for ietf-smime-bks; Sun, 26 Oct 2003 18:24:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R2OSI7051125 for ; Sun, 26 Oct 2003 18:24:28 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Sun, 26 Oct 2003 18:24:25 -0800 From: "Blake Ramsdell" To: , Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-03 Date: Sun, 26 Oct 2003 18:24:25 -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.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Blake Ramsdell [mailto:blake@brutesquadlabs.com] > Sent: Sunday, October 26, 2003 5:55 PM > To: 'jimsch@exmsft.com'; 'ietf-smime@imc.org' > Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-03 > > > 2. References need to be divided. > > Still missing what this means. Aha! You mean that there needs to be a normative and informative section. Got it. I'm apparently behind the times. Blake From owner-ietf-smime@mail.imc.org Mon Oct 27 09:52:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17028 for ; Mon, 27 Oct 2003 09:52:33 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9REIrI7052156 for ; Mon, 27 Oct 2003 06:18:53 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9REIrlF052155 for ietf-smime-bks; Mon, 27 Oct 2003 06:18:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9REIqI7052150 for ; Mon, 27 Oct 2003 06:18:52 -0800 (PST) (envelope-from scoya@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14534; Mon, 27 Oct 2003 09:18:42 -0500 (EST) Message-Id: <200310271418.JAA14534@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-cms-rsa-kem-01.txt Date: Mon, 27 Oct 2003 09:18:41 -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 RSA-KEM Key Transport Algorithm in CMS Author(s) : B. Kaliski Filename : draft-ietf-smime-cms-rsa-kem-01.txt Pages : 20 Date : 2003-10-24 The RSA-KEM Key Transport Algorithm is a one-pass (store-and- forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-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-cms-rsa-kem-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-cms-rsa-kem-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-10-24161000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cms-rsa-kem-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cms-rsa-kem-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24161000.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Mon Oct 27 17:52:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25173 for ; Mon, 27 Oct 2003 17:52:26 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RMBII7077816 for ; Mon, 27 Oct 2003 14:11:18 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RMBIci077813 for ietf-smime-bks; Mon, 27 Oct 2003 14:11:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RMBCI7077797 for ; Mon, 27 Oct 2003 14:11:13 -0800 (PST) (envelope-from scoya@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19555; Mon, 27 Oct 2003 17:11:03 -0500 (EST) Message-Id: <200310272211.RAA19555@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-cms-rsa-kem-01.txt Date: Mon, 27 Oct 2003 17:11:02 -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 RSA-KEM Key Transport Algorithm in CMS Author(s) : B. Kaliski Filename : draft-ietf-smime-cms-rsa-kem-01.txt Pages : 20 Date : 2003-10-24 The RSA-KEM Key Transport Algorithm is a one-pass (store-and- forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-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-cms-rsa-kem-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-cms-rsa-kem-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-10-27171514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cms-rsa-kem-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cms-rsa-kem-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171514.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Mon Oct 27 19:09:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29919 for ; Mon, 27 Oct 2003 19:09:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RNNpI7080564 for ; Mon, 27 Oct 2003 15:23:51 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RNNpri080563 for ietf-smime-bks; Mon, 27 Oct 2003 15:23:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RNNoI7080558 for ; Mon, 27 Oct 2003 15:23:51 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Mon, 27 Oct 2003 15:23:47 -0800 From: "Blake Ramsdell" To: Subject: XMPP at IETF Date: Mon, 27 Oct 2003 15:23:47 -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.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit There is apparently a new permanent XMPP chat server set up, which should be available for every WG meeting going forward. Details are at: http://www.xmpp.org/ietf-chat.html The bottom line is that if someone steps forward and volunteers as a scribe at our meeting, people can participate remotely, and this service will be available until further notice. Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com From owner-ietf-smime@mail.imc.org Mon Oct 27 21:11:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03913 for ; Mon, 27 Oct 2003 21:11:17 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1UmI7085441 for ; Mon, 27 Oct 2003 17:30:48 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S1Um5S085440 for ietf-smime-bks; Mon, 27 Oct 2003 17:30:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1UjI7085435 for ; Mon, 27 Oct 2003 17:30:46 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9S1UQo1028714; Tue, 28 Oct 2003 14:30:26 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9S1WSx01353; Tue, 28 Oct 2003 14:32:28 +1300 Date: Tue, 28 Oct 2003 14:32:28 +1300 Message-Id: <200310280132.h9S1WSx01353@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: blake@brutesquadlabs.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: >S/MIME v3.1 implementations MUST allow for the use of the choice of >subjectKeyIdentifier in messages. Given the recent debate over the use of keyIDs on the PKIX list, shouldn't this be: S/MIME vAnything MUST NOT rely on the use of subjectKeyIdentifier in messages. Peter. From owner-ietf-smime@mail.imc.org Mon Oct 27 21:31:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04519 for ; Mon, 27 Oct 2003 21:31:26 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1tQI7086329 for ; Mon, 27 Oct 2003 17:55:26 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S1tQSN086328 for ietf-smime-bks; Mon, 27 Oct 2003 17:55:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1tPI7086319 for ; Mon, 27 Oct 2003 17:55:25 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Mon, 27 Oct 2003 17:55:18 -0800 From: "Blake Ramsdell" To: "'Peter Gutmann'" , Cc: Subject: RE: Request change in son-of-rfc2633 Date: Mon, 27 Oct 2003 17:55:18 -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 In-Reply-To: <200310280132.h9S1WSx01353@cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] > Sent: Monday, October 27, 2003 5:32 PM > To: blake@brutesquadlabs.com; jimsch@exmsft.com; > pgut001@cs.aucKland.ac.nz > Cc: ietf-smime@imc.org > Subject: RE: Request change in son-of-rfc2633 > > Given the recent debate over the use of keyIDs on the PKIX > list, shouldn't > this be: > > S/MIME vAnything MUST NOT rely on the use of subjectKeyIdentifier in > messages. My understanding of the discussion is that there could be multiple certificates with the same SKI. Do we need to clarify our language to warn that there might be multiple certificates that match a particular SKI, and you should just try out each one until you find one that works? We'll probably need to discuss the implications of this. Apparently I was one of the deluded folks that believed that SKI was meant to be globally unique. Blake From owner-ietf-smime@mail.imc.org Mon Oct 27 21:47:41 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04762 for ; Mon, 27 Oct 2003 21:47:40 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2AUI7086827 for ; Mon, 27 Oct 2003 18:10:30 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S2AT0M086826 for ietf-smime-bks; Mon, 27 Oct 2003 18:10:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2ARI7086821 for ; Mon, 27 Oct 2003 18:10:28 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9S2ALo1030172; Tue, 28 Oct 2003 15:10:21 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9S2CPq01616; Tue, 28 Oct 2003 15:12:25 +1300 Date: Tue, 28 Oct 2003 15:12:25 +1300 Message-Id: <200310280212.h9S2CPq01616@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: blake@brutesquadlabs.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: >Apparently I was one of the deluded folks that believed that SKI was meant to >be globally unique. As was almost everyone else. The problem is that there are two incompatible interpretations of the sKID: 1. Alternative chaining mechanism if chaining by DN fails, e.g. with cert reparenting or some types of spaghetti PKIs. 2. Disambiguating factor if chaining by DN leads to multiple issuers, e.g. with other types of spaghetti PKIs. The problem is that taking one or the other view changes a simple "You've used the wrong cert" (or "Cert to verify this isn't available") to "An attacker is modifying your messages!", which will cause very different reactions in users. Peter. From owner-ietf-smime@mail.imc.org Mon Oct 27 22:05:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05191 for ; Mon, 27 Oct 2003 22:05:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2PdI7087433 for ; Mon, 27 Oct 2003 18:25:39 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S2Pddi087432 for ietf-smime-bks; Mon, 27 Oct 2003 18:25:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2PdI7087425 for ; Mon, 27 Oct 2003 18:25:39 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Mon, 27 Oct 2003 18:25:36 -0800 From: "Blake Ramsdell" To: "'Peter Gutmann'" , Cc: Subject: RE: Request change in son-of-rfc2633 Date: Mon, 27 Oct 2003 18:25:36 -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 In-Reply-To: <200310280212.h9S2CPq01616@cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] > Sent: Monday, October 27, 2003 6:12 PM > To: blake@brutesquadlabs.com; jimsch@exmsft.com; > pgut001@cs.auckland.ac.nz > Cc: ietf-smime@imc.org > Subject: RE: Request change in son-of-rfc2633 > > The problem is that taking one or the other view changes a > simple "You've used > the wrong cert" (or "Cert to verify this isn't available") to > "An attacker is > modifying your messages!", which will cause very different > reactions in users. Yeah, I'm with you, so the "discuss the implications of this" that I mentioned would need to cover behavior when presented with multiple certificates with the same SKI. Something like: "When looking up certificates using the subjectKeyIdentifier field, S/MIME agents MUST be prepared to handle multiple certificates that have the same subjectKeyIdentifier value gracefully." No, that needs a lot of work. I'll call him a "strawman". Blake From owner-ietf-smime@mail.imc.org Tue Oct 28 09:13:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21292 for ; Tue, 28 Oct 2003 09:13:09 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SDnsI7081334 for ; Tue, 28 Oct 2003 05:49:54 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SDnsU0081333 for ietf-smime-bks; Tue, 28 Oct 2003 05:49:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SDnqI7081325; Tue, 28 Oct 2003 05:49:53 -0800 (PST) (envelope-from anders.rundgren@telia.com) Received: from arport (t8o913p105.telia.com [213.64.26.225]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id h9SDndo5010131; Tue, 28 Oct 2003 14:49:40 +0100 (CET) Message-ID: <00e401c39d59$ed8396a0$381b40d5@arport> From: "Anders Rundgren" To: , , References: <001501c37153$4ff1d960$0500a8c0@arport> Subject: Standards for Web-signing II Date: Tue, 28 Oct 2003 14:46:37 +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 6.00.2800.1106 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 The answer to my earlier request seems to be: There are apparently no standards and nothing in the works either with respect to signing on-line data on the web using Internet browsers. Since web-signing is today [*] used by many, many, more people and organizations than there are users of signed e-email, I remain puzzled. Is the PKI community really just a bunch of "nerds", mostly out of touch with the needs of the market? The question is open. *] Like Scandinavian banks having > 0.5M of users. All current systems rely on entirely proprietary mechanisms. Most of the vendors even require NDAs for getting the documentation. Anders Rundgren ----- Original Message ----- From: "Anders Rundgren" To: ; ; Sent: Tuesday, September 02, 2003 14:07 Subject: [pki-tc] Standards for Web-signing Folks, I just wanted to know the status of possible standardization efforts regarding signing on-line forms etc. on web. As web-signing is a core function of many e-governments when communicating with their citizens it seems that this should be standardized if not already is. Pointers are welcome. Off-list or on-list. rgds Anders Rundgren To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/leave_workgroup.php. From owner-ietf-smime@mail.imc.org Tue Oct 28 09:57:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26926 for ; Tue, 28 Oct 2003 09:57:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEcBI7084357 for ; Tue, 28 Oct 2003 06:38:11 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SEcBng084356 for ietf-smime-bks; Tue, 28 Oct 2003 06:38:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEcAI7084351 for ; Tue, 28 Oct 2003 06:38:10 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24585; Tue, 28 Oct 2003 09:38:00 -0500 (EST) Message-Id: <200310281438.JAA24585@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-04.txt Date: Tue, 28 Oct 2003 09:37:59 -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-04.txt Pages : 13 Date : 2003-10-27 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-04.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-04.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-04.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-10-28095529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc2632bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rfc2632bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28095529.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Tue Oct 28 10:00:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27135 for ; Tue, 28 Oct 2003 10:00:08 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEcMI7084369 for ; Tue, 28 Oct 2003 06:38:22 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SEcMSN084368 for ietf-smime-bks; Tue, 28 Oct 2003 06:38:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEcKI7084361 for ; Tue, 28 Oct 2003 06:38:20 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24599; Tue, 28 Oct 2003 09:38:10 -0500 (EST) Message-Id: <200310281438.JAA24599@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-rfc2633bis-06.txt Date: Tue, 28 Oct 2003 09:38:10 -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 Message Specification Author(s) : B. Ramsdell Filename : draft-ietf-smime-rfc2633bis-06.txt Pages : 30 Date : 2003-10-27 S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and data confidentiality (using encryption). S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems. Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2633bis-06.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-rfc2633bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-rfc2633bis-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28095548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc2633bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rfc2633bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28095548.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Tue Oct 28 18:08:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05441 for ; Tue, 28 Oct 2003 18:08:43 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMOQI7009115 for ; Tue, 28 Oct 2003 14:24:26 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SMOQ5e009114 for ietf-smime-bks; Tue, 28 Oct 2003 14:24:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SMOPI7009109 for ; Tue, 28 Oct 2003 14:24:25 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 31755 invoked by uid 0); 28 Oct 2003 22:24:19 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (65.222.154.73) by woodstock.binhost.com with SMTP; 28 Oct 2003 22:24:19 -0000 Message-Id: <5.2.0.9.2.20031028084138.02012898@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Oct 2003 08:47:08 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann), blake@brutesquadlabs.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz From: Russ Housley Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org In-Reply-To: <200310280132.h9S1WSx01353@cs.auckland.ac.nz> 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 disagree. Key identifiers are much smaller than . When the key identifiers are computed from the public key (as is recommended by RFC 3280), the likelihood of collision is acceptably small. Further, if there is a collision, an implementation can try the very small number of public keys that have the same identifier. Russ At 02:32 PM 10/28/2003 +1300, Peter Gutmann wrote: >"Blake Ramsdell" writes: > > >S/MIME v3.1 implementations MUST allow for the use of the choice of > >subjectKeyIdentifier in messages. > >Given the recent debate over the use of keyIDs on the PKIX list, shouldn't >this be: > > S/MIME vAnything MUST NOT rely on the use of subjectKeyIdentifier in > messages. > >Peter. From owner-ietf-smime@mail.imc.org Tue Oct 28 18:57:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08879 for ; Tue, 28 Oct 2003 18:57:51 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMiAI7010031 for ; Tue, 28 Oct 2003 14:44:10 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SMiA9G010030 for ietf-smime-bks; Tue, 28 Oct 2003 14:44:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMi9I7010023 for ; Tue, 28 Oct 2003 14:44:10 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Tue, 28 Oct 2003 14:44:05 -0800 From: "Blake Ramsdell" To: "'Russ Housley'" , "'Peter Gutmann'" , , Cc: Subject: RE: Request change in son-of-rfc2633 Date: Tue, 28 Oct 2003 14:44:05 -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 In-Reply-To: <5.2.0.9.2.20031028084138.02012898@mail.binhost.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Tuesday, October 28, 2003 5:47 AM > To: Peter Gutmann; blake@brutesquadlabs.com; > jimsch@exmsft.com; pgut001@cs.auckland.ac.nz > Cc: ietf-smime@imc.org > Subject: RE: Request change in son-of-rfc2633 > > I disagree. Key identifiers are much smaller than distinguished > name, serial number>. When the key identifiers are computed > from the public > key (as is recommended by RFC 3280), the likelihood of collision is > acceptably small. Further, if there is a collision, an > implementation can > try the very small number of public keys that have the same > identifier. I think that the direction that's on the table is to clarify that lookups by SubjectKeyIdentifier may yield more than one certificate, and implementations should be prepared for that and not freak out and panic the user. Blake From owner-ietf-smime@mail.imc.org Tue Oct 28 19:02:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09171 for ; Tue, 28 Oct 2003 19:02:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SNJqI7011321 for ; Tue, 28 Oct 2003 15:19:52 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SNJqw9011320 for ietf-smime-bks; Tue, 28 Oct 2003 15:19:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SNJpI7011305 for ; Tue, 28 Oct 2003 15:19:51 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 7573 invoked by uid 0); 28 Oct 2003 23:19:46 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (65.222.154.73) by woodstock.binhost.com with SMTP; 28 Oct 2003 23:19:46 -0000 Message-Id: <5.2.0.9.2.20031028181930.0448e928@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Oct 2003 18:19:49 -0500 To: "Blake Ramsdell" , "'Peter Gutmann'" , , From: Russ Housley Subject: RE: Request change in son-of-rfc2633 Cc: In-Reply-To: References: <5.2.0.9.2.20031028084138.02012898@mail.binhost.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: No problem. At 02:44 PM 10/28/2003 -0800, Blake Ramsdell wrote: > > I disagree. Key identifiers are much smaller than > distinguished > > name, serial number>. When the key identifiers are computed > > from the public > > key (as is recommended by RFC 3280), the likelihood of collision is > > acceptably small. Further, if there is a collision, an > > implementation can > > try the very small number of public keys that have the same > > identifier. > >I think that the direction that's on the table is to clarify that >lookups by SubjectKeyIdentifier may yield more than one certificate, and >implementations should be prepared for that and not freak out and panic >the user. From owner-ietf-smime@mail.imc.org Tue Oct 28 23:12:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22492 for ; Tue, 28 Oct 2003 23:12:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3SWI7021283 for ; Tue, 28 Oct 2003 19:28:32 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T3SWsI021282 for ietf-smime-bks; Tue, 28 Oct 2003 19:28:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3SSI7021276 for ; Tue, 28 Oct 2003 19:28:31 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9T3Rto9008180; Wed, 29 Oct 2003 16:27:55 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9T3UAo08690; Wed, 29 Oct 2003 16:30:10 +1300 Date: Wed, 29 Oct 2003 16:30:10 +1300 Message-Id: <200310290330.h9T3UAo08690@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: blake@brutesquadlabs.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: >"When looking up certificates using the subjectKeyIdentifier field, S/MIME >agents MUST be prepared to handle multiple certificates that have the same >subjectKeyIdentifier value gracefully." That won't work if you only find the wrong cert using the sKID. That is, there are two certs with the given sKID, you get a perfect match on the one that you can locate, but it's the wrong one. The real problem here is that by building a spaghetti PKI (one that violates the original X.509 design) you're subjecting yourself to a world of pain that no amount of text in a standard can resolve. So the only practical solution would be to include a warning to say that everything works as required with a conventional PKI, but all bets are off once you're in a spaghetti PKI scenario, because the design was never intended to be used like that. Might I suggest: "The behaviour of S/MIME agents in a spaghetti PKI scenario is a ecumen^H^H^H^Hpolicy matter". Peter. From owner-ietf-smime@mail.imc.org Tue Oct 28 23:15:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22692 for ; Tue, 28 Oct 2003 23:15:23 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3ZiI7021508 for ; Tue, 28 Oct 2003 19:35:44 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T3ZiW8021507 for ietf-smime-bks; Tue, 28 Oct 2003 19:35:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3ZfI7021494; Tue, 28 Oct 2003 19:35:42 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9T3Zfo9008396; Wed, 29 Oct 2003 16:35:41 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9T3bu208738; Wed, 29 Oct 2003 16:37:56 +1300 Date: Wed, 29 Oct 2003 16:37:56 +1300 Message-Id: <200310290337.h9T3bu208738@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ejnorman@doit.wisc.edu, ietf-pkix@imc.org Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Cross-posted back to S/MIME, where the thread started] Eric Norman writes: >Is there a claim (#1 above) that you can have the DN in the subject of a >parent's (signer's) certificate be different from (as in different bunch of >bytes) the DN in the issuer of one of its offspring and yet the chain is >still valid because the xKIDs match? Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI that violates the original X.509 design, i.e. with re-parenting, arbitrary cross- certification, etc etc where issuers no longer match subjects). For example MS apparently implemented chaining by sKID in Windows because of user demand for this when the users broke chaining by issuer name through spaghetti PKI design practices, and various other implementations no doubt do similar things, depending on how they've read the PKIX tea leaves. Peter. From owner-ietf-smime@mail.imc.org Tue Oct 28 23:41:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23663 for ; Tue, 28 Oct 2003 23:41:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T43qI7022675 for ; Tue, 28 Oct 2003 20:03:52 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T43qoi022674 for ietf-smime-bks; Tue, 28 Oct 2003 20:03:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T43oI7022669 for ; Tue, 28 Oct 2003 20:03:51 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9T438o9009171; Wed, 29 Oct 2003 17:03:08 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9T45OE08868; Wed, 29 Oct 2003 17:05:24 +1300 Date: Wed, 29 Oct 2003 17:05:24 +1300 Message-Id: <200310290405.h9T45OE08868@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: blake@brutesquadlabs.com, housley@vigilsec.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: >Further, if there is a collision, an implementation can try the very small >number of public keys that have the same identifier. How does it know when to stop looking for more certs? For example, what if it can only find one cert and it's the wrong one? Peter. From owner-ietf-smime@mail.imc.org Wed Oct 29 00:14:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25061 for ; Wed, 29 Oct 2003 00:14:31 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4NKI7023619 for ; Tue, 28 Oct 2003 20:23:20 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T4NKF7023618 for ietf-smime-bks; Tue, 28 Oct 2003 20:23:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9T4NJI7023612 for ; Tue, 28 Oct 2003 20:23:19 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 4401 invoked by uid 0); 29 Oct 2003 04:20:15 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (65.222.154.72) by woodstock.binhost.com with SMTP; 29 Oct 2003 04:20:15 -0000 Message-Id: <5.2.0.9.2.20031028231703.03f60b40@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Oct 2003 23:20:19 -0500 To: pgut001@cs.auckland.ac.nz, blake@brutesquadlabs.com, jimsch@exmsft.com From: Russ Housley Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org In-Reply-To: <200310290405.h9T45OE08868@cs.auckland.ac.nz> 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: Peter: > >Further, if there is a collision, an implementation can try the very small > >number of public keys that have the same identifier. > >How does it know when to stop looking for more certs? For example, what if it >can only find one cert and it's the wrong one? If the key identifier is computed from the public key as recommended by RFC 3280, the odds are quite small. So, if the first certificate located is not the right one, search for another. If one is not located, then return an error. Russ From owner-ietf-smime@mail.imc.org Wed Oct 29 00:28:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25493 for ; Wed, 29 Oct 2003 00:28:53 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4neI7024568 for ; Tue, 28 Oct 2003 20:49:40 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T4nejf024567 for ietf-smime-bks; Tue, 28 Oct 2003 20:49:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4naI7024562 for ; Tue, 28 Oct 2003 20:49:39 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9T4n6o9010625; Wed, 29 Oct 2003 17:49:06 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9T4pMY09221; Wed, 29 Oct 2003 17:51:22 +1300 Date: Wed, 29 Oct 2003 17:51:22 +1300 Message-Id: <200310290451.h9T4pMY09221@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: blake@brutesquadlabs.com, housley@vigilsec.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: >So, if the first certificate located is not the right one, search for >another. If one is not located, then return an error. Which error though? With iAndS, there are three possible outcomes: 1. Cert definitely not found. 2. Cert definitely found, bad signature. 3. Cert definitely found, good signature. With sKID, this becomes: 1. Cert not found, although it may be out there somewhere and we don't know about it. 2. Cert found, bad signature, although there may be one out there that would return a good signature but we don't know about it. 3. Cert found, good signature. So should the "one is not located" error be: The data has been tampered with by an attacker. or: The data may or may not have been tampered with by an attacker, it sort of looks like it was but I can't really tell because there may be some other cert that I'm not aware of that indicates that it wasn't. In the presence of an ambiguous identifier and a potentially arbitrarily large number of certs identified by it, it's not possible to return a useful error message to the user. One simple solution to this problem would be to introduce a guaranteed- unambiguous identifier for certs: certIdentifier [1] OCTET STRING SIZE(20), (being the almost universally-used SHA-1 hash/fingerprint/thumbprint/whatever your particular program calls it) and deprecate the sKID on the grounds that it can't provide the same semantics as iAndS does, while a certID can. Note that this would be completely in line with the RFC 3369 requirements, which says that the "sid specifies the signer's certificate", which the certID certainly does. Peter. From owner-ietf-smime@mail.imc.org Wed Oct 29 04:34:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00056 for ; Wed, 29 Oct 2003 04:34:43 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T97AI7095709 for ; Wed, 29 Oct 2003 01:07:10 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T97AN2095707 for ietf-smime-bks; Wed, 29 Oct 2003 01:07:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from outbound1.sopragroup.com (outbound1.zpar1.sopragroup.com [213.223.36.102]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T978I7095656 for ; Wed, 29 Oct 2003 01:07:09 -0800 (PST) (envelope-from aalberti@axway.com) Received: from wexchfe02.z12.sopra (localhost [127.0.0.1]) by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A01) with ESMTP id h9T970bD031094 for ; Wed, 29 Oct 2003 10:07:00 +0100 Received: from wexchbe01-vs.pa.sopra ([172.17.4.151]) by wexchfe02.z12.sopra with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 10:07:22 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: TR: Request change in son-of-rfc2633 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 29 Oct 2003 10:07:00 +0100 Message-ID: Thread-Topic: Request change in son-of-rfc2633 thread-index: AcOd+P7tlDcpT+02TBu/sm6JhdFYHwAAZUxA From: "Alberti Antoine" To: X-OriginalArrivalTime: 29 Oct 2003 09:07:22.0359 (UTC) FILETIME=[10144870:01C39DFC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9T979I7095702 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Actually, I even wonder what guarantees that a iAndS is unique, as, as far as I know, there is no unique LDAP repository (or anything else) for DNs, and each one is only unique in the issuer's scope. By chance, it seems that the whole system finally works, but mathematically, it does not: 2 different CAs may issue 2 CA certs with the same subjectName, and these CAs may issue 2 certs with the same serial. Regards. > -----Message d'origine----- > De : owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]De la part de Peter Gutmann > Envoyé : mercredi 29 octobre 2003 05:51 > À : blake@brutesquadlabs.com; housley@vigilsec.com; jimsch@exmsft.com; > pgut001@cs.auckland.ac.nz > Cc : ietf-smime@imc.org > Objet : RE: Request change in son-of-rfc2633 > > > > Russ Housley writes: > > >So, if the first certificate located is not the right one, search for > >another. If one is not located, then return an error. > > Which error though? With iAndS, there are three possible outcomes: > > 1. Cert definitely not found. > 2. Cert definitely found, bad signature. > 3. Cert definitely found, good signature. > > With sKID, this becomes: > > 1. Cert not found, although it may be out there somewhere > and we don't know > about it. > 2. Cert found, bad signature, although there may be one out > there that > would return a good signature but we don't know about it. > 3. Cert found, good signature. > > So should the "one is not located" error be: > > The data has been tampered with by an attacker. > > or: > > The data may or may not have been tampered with by an > attacker, it sort of > looks like it was but I can't really tell because there may > be some other > cert that I'm not aware of that indicates that it wasn't. > > In the presence of an ambiguous identifier and a potentially > arbitrarily large > number of certs identified by it, it's not possible to return > a useful error > message to the user. > > One simple solution to this problem would be to introduce a > guaranteed- > unambiguous identifier for certs: > > certIdentifier [1] OCTET STRING SIZE(20), > > (being the almost universally-used SHA-1 > hash/fingerprint/thumbprint/whatever > your particular program calls it) and deprecate the sKID on > the grounds that > it can't provide the same semantics as iAndS does, while a > certID can. Note > that this would be completely in line with the RFC 3369 > requirements, which > says that the "sid specifies the signer's certificate", which > the certID > certainly does. > > Peter. > From owner-ietf-smime@mail.imc.org Wed Oct 29 04:58:24 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00983 for ; Wed, 29 Oct 2003 04:58:24 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T9VWI7004140 for ; Wed, 29 Oct 2003 01:31:32 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T9VWJx004139 for ietf-smime-bks; Wed, 29 Oct 2003 01:31:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T9VUI7004121 for ; Wed, 29 Oct 2003 01:31:31 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9T9VKo9018713; Wed, 29 Oct 2003 22:31:20 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9T9Xbg11033; Wed, 29 Oct 2003 22:33:37 +1300 Date: Wed, 29 Oct 2003 22:33:37 +1300 Message-Id: <200310290933.h9T9Xbg11033@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: aalberti@axway.com, ietf-smime@imc.org Subject: Re: TR: Request change in son-of-rfc2633 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Alberti Antoine" writes: >Actually, I even wonder what guarantees that a iAndS is unique, as, as far as >I know, there is no unique LDAP repository (or anything else) for DNs, and >each one is only unique in the issuer's scope. By chance, it seems that the >whole system finally works, but mathematically, it does not: 2 different CAs >may issue 2 CA certs with the same subjectName, and these CAs may issue 2 >certs with the same serial. Well, firstly, X.500 theology requires that you believe that all (CA) DNs are unique, and to even claim otherwise is treason punishable by limb reconstruction. In any case even if you do run into a situation where two CAs choose to use the same DN, the chance of the serial numbers (a 128-bit or 160- bit random hash value in most cases) matching as well are... slim. Peter. From owner-ietf-smime@mail.imc.org Wed Oct 29 10:29:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13806 for ; Wed, 29 Oct 2003 10:29:29 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TEwgkT022934 for ; Wed, 29 Oct 2003 06:58:42 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TEwgf0022933 for ietf-smime-bks; Wed, 29 Oct 2003 06:58:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TEwekT022918; Wed, 29 Oct 2003 06:58:40 -0800 (PST) (envelope-from steve.hanna@sun.com) Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9TEwOxA001116; Wed, 29 Oct 2003 06:58:24 -0800 (PST) Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h9TEwNB19615; Wed, 29 Oct 2003 09:58:23 -0500 (EST) Message-ID: <3F9FD56A.771A262C@sun.com> Date: Wed, 29 Oct 2003 09:57:46 -0500 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Gutmann CC: ejnorman@doit.wisc.edu, ietf-pkix@imc.org, ietf-smime@imc.org Subject: Re: Request change in son-of-rfc2633 References: <200310290337.h9T3bu208738@cs.auckland.ac.nz> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms58E8539260192E6D326EA0C4" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms58E8539260192E6D326EA0C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anyone who "reads the PKIX tea leaves" and thinks that it's fine to skip name chaining checks in path validation needs to have their eyes checked. RFC 3280 says in many places that name chaining MUST be checked. In section 6.1: To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions: (a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; In section 6.1.3: (a) Verify the basic certificate information. The certificate MUST satisfy each of the following: [...] (4) The certificate issuer name is the working_issuer_name. In section 4.1.2.6: If the subject is a CA (e.g., the basic constraints extension, as discussed in 4.2.1.10, is present and the value of cA is TRUE), then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field (section 4.1.2.4) in all certificates issued by the subject CA. RFC 2459 and X.509 both agree with this. Whatever PKI topology you use, there's no need to break name chaining. I'm sure that some customers have created PKIs where name chaining doesn't hold, but that's an error on the customer's part. You can't just turn off critical security checks to keep them happy. What's next? Don't bother checking the signature on certificates. That takes too much time! If somebody has implemented path validation without name chaining checks, then they haven't implemented it according to IETF or X.509 standards. In fact, they may have opened themselves and their customers up to security holes and perhaps even legal liability. CAs have every right to expect that certificates will be validated according to standards. Users also have a reasonable expectation of this. If someone deliberately violates the standards in a way that opens up security holes, that sounds like gross negligence to me. This reminds me of Microsoft's decision to not check the Basic Constraints extension, treating every certificate as a CA certificate. This decision, presumably made in to please a customer, resulted in a HUGE security hole. I hope that Microsoft (and anyone else who has skipped required parts of the path validation algorithm for the sake of convenience) will see that security cannot be second to user convenience. If there's a serious problem with the specs, then let's fix them. But don't just bypass things because you find it convenient. Forgive me my rant. I'm just outraged that somebody would play fast and loose with security this way. Thanks, Steve Peter Gutmann wrote: > > [Cross-posted back to S/MIME, where the thread started] > > Eric Norman writes: > > >Is there a claim (#1 above) that you can have the DN in the subject of a > >parent's (signer's) certificate be different from (as in different bunch of > >bytes) the DN in the issuer of one of its offspring and yet the chain is > >still valid because the xKIDs match? > > Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI that > violates the original X.509 design, i.e. with re-parenting, arbitrary cross- > certification, etc etc where issuers no longer match subjects). For example > MS apparently implemented chaining by sKID in Windows because of user demand > for this when the users broke chaining by issuer name through spaghetti PKI > design practices, and various other implementations no doubt do similar > things, depending on how they've read the PKIX tea leaves. > > Peter. --------------ms58E8539260192E6D326EA0C4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0 ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO 9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV 86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM 9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0 9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50 bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB 9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0 ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDMxMDI5MTQ1NzQ2WjAjBgkqhkiG9w0BCQQxFgQU4GYH3SPbd16nT9xTo5bjvv/V bmMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBJKLwc TwwpH14dBh0aE4gn3MRkvi2+fKiDitHUq5TeivEOYZK5rN0eXbxESLuxNnYl+Cp5zrdhvokV 8ThIbRyqfsorBhQ0P0GB7h72pEkfCxExzHBjtQsfqP6q5JMpup/zWWm3xHLbQlz9XtpGSwKo xHrTgWBxWsHAMTWnOKeeSA== --------------ms58E8539260192E6D326EA0C4-- From owner-ietf-smime@mail.imc.org Wed Oct 29 11:05:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15883 for ; Wed, 29 Oct 2003 11:05:03 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TFZ2kT024796 for ; Wed, 29 Oct 2003 07:35:02 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TFZ2XN024795 for ietf-smime-bks; Wed, 29 Oct 2003 07:35:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TFZ1kT024790 for ; Wed, 29 Oct 2003 07:35:01 -0800 (PST) (envelope-from capel@comgate.com) Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx2.magma.ca Magma's Mail Server with ESMTP id h9TFYllg004482; Wed, 29 Oct 2003 10:34:47 -0500 Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail2.magma.ca (8.12.10/8.12.9) with ESMTP id h9TFYcCt002052; Wed, 29 Oct 2003 10:34:47 -0500 From: "Tony Capel" To: "'Peter Gutmann'" , , Subject: RE: TR: Request change in son-of-rfc2633 Date: Wed, 29 Oct 2003 10:34:37 -0500 Message-ID: <000c01c39e32$2ca9ba20$01b5a8c0@tony> 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.4510 In-Reply-To: <200310290933.h9T9Xbg11033@cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > "Alberti Antoine" writes: > > Actually, I even wonder what guarantees that a iAndS is unique, ... "Peter Gutmann" writes: | | Well, firstly, X.500 theology requires that you believe that | all (CA) DNs are unique, and to even claim otherwise is | treason punishable by limb reconstruction. In any case even | if you do run into a situation where two CAs choose to use | the same DN, the chance of the serial numbers (a 128-bit or | 160- bit random hash value in most cases) matching as well | are... slim. | And also hopefully we are all practicing safe root certificate use. We are only installing trust roots for domains that conform to our security policy - this including appropriate obeisance to X.500 theology on the assignment of DN's (and the issue of cross certs). Of course with root certs being downloaded as part of operating system updates, many of us may be relying on the os vendor to do that ..... Tony From owner-ietf-smime@mail.imc.org Wed Oct 29 16:28:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07459 for ; Wed, 29 Oct 2003 16:28:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKrQkT043909 for ; Wed, 29 Oct 2003 12:53:26 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TKrQ20043908 for ietf-smime-bks; Wed, 29 Oct 2003 12:53:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mclean-vscan2.bah.com (mclean-vscan2.bah.com [156.80.3.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKrNkT043895; Wed, 29 Oct 2003 12:53:26 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from mclean-vscan2.bah.com (mclean-vscan2.bah.com [156.80.3.62]) by mclean-vscan2.bah.com (8.11.0/8.11.0) with SMTP id h9TKqgM13536; Wed, 29 Oct 2003 15:52:42 -0500 (EST) Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan2.bah.com (NAVGW 2.5.2.12) with SMTP id M2003102915503623002 ; Wed, 29 Oct 2003 15:50:36 -0500 Received: from wchokhani ([156.80.127.102]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HNJDWE00.KHV; Wed, 29 Oct 2003 15:50:38 -0500 From: "Santosh Chokhani" To: , Subject: RE: Request change in son-of-rfc2633 Date: Wed, 29 Oct 2003 15:50:35 -0500 MIME-Version: 1.0 Message-ID: <006401c39e5e$4d7280d0$667f509c@hq.orionsec.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0060_01C39E1C.EE435990" Importance: Normal In-Reply-To: <3F9FD56A.771A262C@sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C39E1C.EE435990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Steve Hanna: I agree with you that both 3280 and X.509 require name chaining. However, the security implications and security importance of name chaining is overstated. For example, if signatures chain properly for the certificate and CRL and the relying party has appropriate means (e.g., e-mail address) to identify the subscriber, name chaining offers little in terms of security. My statement should be read purely in security (and NOT interoperability) context. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Steve Hanna Sent: Wednesday, October 29, 2003 9:58 AM To: Peter Gutmann Cc: ejnorman@doit.wisc.edu; ietf-pkix@imc.org; ietf-smime@imc.org Subject: Re: Request change in son-of-rfc2633 Anyone who "reads the PKIX tea leaves" and thinks that it's fine to skip name chaining checks in path validation needs to have their eyes checked. RFC 3280 says in many places that name chaining MUST be checked. In section 6.1: To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions: (a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; In section 6.1.3: (a) Verify the basic certificate information. The certificate MUST satisfy each of the following: [...] (4) The certificate issuer name is the working_issuer_name. In section 4.1.2.6: If the subject is a CA (e.g., the basic constraints extension, as discussed in 4.2.1.10, is present and the value of cA is TRUE), then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field (section 4.1.2.4) in all certificates issued by the subject CA. RFC 2459 and X.509 both agree with this. Whatever PKI topology you use, there's no need to break name chaining. I'm sure that some customers have created PKIs where name chaining doesn't hold, but that's an error on the customer's part. You can't just turn off critical security checks to keep them happy. What's next? Don't bother checking the signature on certificates. That takes too much time! If somebody has implemented path validation without name chaining checks, then they haven't implemented it according to IETF or X.509 standards. In fact, they may have opened themselves and their customers up to security holes and perhaps even legal liability. CAs have every right to expect that certificates will be validated according to standards. Users also have a reasonable expectation of this. If someone deliberately violates the standards in a way that opens up security holes, that sounds like gross negligence to me. This reminds me of Microsoft's decision to not check the Basic Constraints extension, treating every certificate as a CA certificate. This decision, presumably made in to please a customer, resulted in a HUGE security hole. I hope that Microsoft (and anyone else who has skipped required parts of the path validation algorithm for the sake of convenience) will see that security cannot be second to user convenience. If there's a serious problem with the specs, then let's fix them. But don't just bypass things because you find it convenient. Forgive me my rant. I'm just outraged that somebody would play fast and loose with security this way. Thanks, Steve Peter Gutmann wrote: > > [Cross-posted back to S/MIME, where the thread started] > > Eric Norman writes: > > >Is there a claim (#1 above) that you can have the DN in the subject > >of a parent's (signer's) certificate be different from (as in > >different bunch of > >bytes) the DN in the issuer of one of its offspring and yet the chain is > >still valid because the xKIDs match? > > Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI > that violates the original X.509 design, i.e. with re-parenting, > arbitrary cross- certification, etc etc where issuers no longer match > subjects). For example MS apparently implemented chaining by sKID in > Windows because of user demand for this when the users broke chaining > by issuer name through spaghetti PKI design practices, and various > other implementations no doubt do similar things, depending on how > they've read the PKIX tea leaves. > > Peter. ------=_NextPart_000_0060_01C39E1C.EE435990 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUqTCCA9Yw ggK+oAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9u IFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFjAUBgNVBAMTDU9yaW9uIFJvb3QgQ0Ew HhcNMDMwODEzMTcwMTI0WhcNMTMwODEwMTcwMTI0WjBVMQswCQYDVQQGEwJVUzEhMB8GA1UEChMY T3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UEAxMNT3Jpb24gUm9v dCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOd3fg/nIELr3rAuxpkcxiAn7ayU /30RPxYBMgcvn0BJbBXBXIkTHgm3jh0TwHGQk76nqTSo1fUqpkkEcSSwEtfz1jF0QCKPHoQvNxza 5ffqH2gBSTgjpwqLA34RDxFDwcdNibIG/s6Zj2PpVDDWVBYxMbLrhKluMAfufhOMT6uyYxw+XPcU ndqy4bRo08BONIoLdoUoOsvOwHla+zPYsBnTncMEL26lnKgCQgJpcFfrQRLrM84Rlc9EmvPbU+tO 5jRfdnvJpCm8LbIcTvAwQLiM+5qr4GPTg73S+9ZMAjlaZWG/VGe5b+KtQCgDu2TPB+wtiz2csG5q YN14mFpKMdMCAwEAAaOBsDCBrTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUvpoqeR5tpH+G2bn1P06LoHH9Mq0wHwYDVR0jBBgwFoAUvpoqeR5tpH+G2bn1P06LoHH9 Mq0wEQYJYIZIAYb4QgEBBAQDAgAHMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25z ZWMuY29tL29yaW9uX3Jvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAch1imNzh8/wx6Ym3ti6FI LyJMsktilc4I5zJ6ZRrZUMye/3v9XJDIutBPb472wOwQT+OR3DTbWX8loNybf3Ew3wWzZg+D14kQ d/+rm3ZAJ3EeX67/g9XevAkrv951Q7QSucZMbbzrLqIWSkgjxJbcujNdeQsSlUz5I2Q9qYdAhg6G 85gf+GaStpaGlR5siWwJAQ/KeWrntfwNbh1P81Vmq/MovUQWPNKeM80FHcqHVVpQWasPTkGb0eW2 NOBsxGBCSQjc5QQdxPIMIuxmyVX42kGTK3O/IxI2O2QBK+pmFHEm4o+p+ekxxHekZTowPSeFXFYQ SrnpmJyfcHa2vLTpMIID1zCCAr+gAwIBAgIBAjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJV UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UE AxMNT3Jpb24gUm9vdCBDQTAeFw0wMzA4MTQxNjQ4MzZaFw0wNDA4MTMxNjQ4MzZaMFYxCzAJBgNV BAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxCzAJBgNVBAsTAkhRMRcw FQYDVQQDEw5PcmlvbiBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL65 aM5ISSZ1ERaIjEaBDvZJ+U1iEEvdLoILkmuwzqrN0DMNhBwLUPJSYjGZ6xlGE5sRmDbUcFhRX0Dt p/t0lKBl0zajquPRbO5t3whqhb0h5IgIRP19NOZ9Mo/XWML2eCVmDyy6lqK5NC+Uvdhf8SjjH+P2 WCk68KmELfqXSfHoKy9gKMEH9IFyL1EqbE8DTUuFmUzg3ZIpR9UMX0Yorx4YdQRyblH4fEUDNfUu PHvRTZkyfAm8nrpsWCqOY0Q3Vl6OsfMqBaVYOORA9fDPLZLXvYc7Im3LDTAXvy+DTki2cR3rjLrO +p3POH/SoH8/9eHhNk4fX/w4FvQMv9hIonECAwEAAaOBsDCBrTAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU+NvSaD0SiHYB9QkgqlK4n+fFAKEwHwYDVR0jBBgwFoAU vpoqeR5tpH+G2bn1P06LoHH9Mq0wEQYJYIZIAYb4QgEBBAQDAgAHMDcGA1UdHwQwMC4wLKAqoCiG Jmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX3Jvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQDPS+PvtkWJ6V235n4Ntn5xWFgvS+GVMI3tBVid/DW2h3AxDWzKctlybc/FhO0sj7nlLXE5CQfm ocx7m3mf1DcEz83b3BJNO9Dwa0U1kNL0kAFSXb9i+jaL3ovNoZlXxOcl73dK77eEohYbioUOtglM HwXXOdbpbOPH1tX0fUr70Zp4KBczNdsQnSrbnHIe2zdNPKY5VPYonB6gxJTNxlbqcHYg56abe0En Ad0C5IoMEG13CbHfDCm9uhRC5yHfylEZMOYA644+2d73FUsIstAdwK+pyeWXSaWGwN/xgLAGE5S1 Ryihlql/q4BXxqqU8RPm90g+2aj1e+PlnlXHxLWCMIID2jCCAsKgAwIBAgIBADANBgkqhkiG9w0B AQUFADBVMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQsw CQYDVQQLEwJIUTEWMBQGA1UEAxMNT3Jpb24gUm9vdCBDQTAeFw0wMzA2MDUxNDI4NTlaFw0wNDA2 MDQxNDI4NTlaMFYxCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlv bnMxCzAJBgNVBAsTAkhRMRcwFQYDVQQDEw5PcmlvbiBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL65aM5ISSZ1ERaIjEaBDvZJ+U1iEEvdLoILkmuwzqrN0DMNhBwLUPJS YjGZ6xlGE5sRmDbUcFhRX0Dtp/t0lKBl0zajquPRbO5t3whqhb0h5IgIRP19NOZ9Mo/XWML2eCVm Dyy6lqK5NC+Uvdhf8SjjH+P2WCk68KmELfqXSfHoKy9gKMEH9IFyL1EqbE8DTUuFmUzg3ZIpR9UM X0Yorx4YdQRyblH4fEUDNfUuPHvRTZkyfAm8nrpsWCqOY0Q3Vl6OsfMqBaVYOORA9fDPLZLXvYc7 Im3LDTAXvy+DTki2cR3rjLrO+p3POH/SoH8/9eHhNk4fX/w4FvQMv9hIonECAwEAAaOBszCBsDAS BgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU+NvSaD0SiHYB9Qkg qlK4n+fFAKEwHwYDVR0jBBgwFoAUvpoqeR5tpH+G2bn1P06LoHH9Mq0wEQYJYIZIAYb4QgEBBAQD AgAHMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX3Jvb3Qu Y3JsMA0GCSqGSIb3DQEBBQUAA4IBAQCxgp0tv87jUcjW/N8p+FgFn6+vBZQ80DhtLSYfi1KGBgQn kjXk1dgr6zPiBtfow/eyXCn7C2kErJIwwXbNv93s7N3ntpgh7DMD9A6I69zKTeMvzn4K2SCQ718s Hhk9mTKceIj7joDG6KZ7lw2COiFx/oEUehRF6i601u9h8mHJ5HPpoAD+QyzBHfkmN6njulLYmY5W 8omXRl4fPZdWu3TNRPemxY859PrZiqrVjogqXOH7ceBttkQ1PnjLxZV0PKgyiAhzgBwWf+dkjWxq NJtwJjGLntm+vVYpTbXuyY63U41rzEckGNOWdMoR8zwupTGmT1j5cNXkccGExpqnf2pbMIIEdzCC A1+gAwIBAgIBIjANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24g U2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwgQ0Ew HhcNMDMwODE1MTgyMDM3WhcNMDQwODE0MTgyMDM3WjB+MQswCQYDVQQGEwJVUzEhMB8GA1UEChMY T3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEZMBcGA1UEAxMQU2FudG9zaCBD aG9raGFuaTEkMCIGCSqGSIb3DQEJARYVY2hva2hhbmlAb3Jpb25zZWMuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0EadobvmWyC1UbtEuos8DmEK7vsk72z3USFc4MF4I71ctasT uT7n3eY0RsXK5NSrGNufwwup7ksdZAo/a6GPxiGMDOaQtJi8VaACzPUyqzZZJEKtaolcD4fS8V6O FyBdMmdMBebd0GrcNVmabvgVIm3h5Oe3sUzZxqkduueAkjMstGnBtUWG431HzM3vOTzkbHzkMoNT FgMEayhHrklyecveHOgiqhOypAiKSv5acM2vgzreh5gbHEJfqOfS56+exTAz/MrpdzvXmv0kmrwM BOtTM1rOYhyjw2yzM07lBxstBMR0DIeqpf2dZN1IHOnnGWxSqql2Gdjn9bpplVN2EQIDAQABo4IB JjCCASIwHQYDVR0OBBYEFPQLCXgNtykUjPyCwMO9MWrT0A86MB8GA1UdIwQYMBaAFPjb0mg9Eoh2 AfUJIKpSuJ/nxQChMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29y aW9uX21haWwuY3JsMAkGA1UdEwQCMAAwQgYIKwYBBQUHAQEENjA0MDIGCCsGAQUFBzAChiZodHRw Oi8vd3d3Lm9yaW9uc2VjLmNvbS9vcmlvbl9tYWlsLmRlcjAOBgNVHQ8BAf8EBAMCBDAwEwYDVR0l BAwwCgYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgWgMCAGA1UdEQQZMBeBFWNob2toYW5pQG9y aW9uc2VjLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAOMNwcRoKaH2+5wC7MWhDrG98bOyphlE51btw mPHS9Ob5XpJMJMlZI2kb2/4A71riaZZPcuFypMqxGIjaH7Y/Gi0aHsk7iWRMEMXiaCT2fq0WM1Wq /sDgwMYVCvOjU8s5x+4i7y4tvS/eP01qcmqz5RABM85bmZ45qypM+JV246LxYRkVpESl62+iSkcg U8hmtruiV7C8CX3yUZj//uwPH9F+7iwvSEAmH6vm4MxGxrMbo2yThsvJ6KNZ1XVlT3jtA66AhoKB h++f7KfuqJbWUaQXVuvGESCHI79DCtXVUK7YFdHQxLU1Y63NkqRYTncrHtJlqzY2kxq5B/0vnPhg 1zCCBJcwggN/oAMCAQICASEwDQYJKoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxITAfBgNVBAoT GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVt YWlsIENBMB4XDTAzMDgxNTE4MjAxN1oXDTA0MDgxNDE4MjAxN1owfjELMAkGA1UEBhMCVVMxITAf BgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExGTAXBgNVBAMTEFNh bnRvc2ggQ2hva2hhbmkxJDAiBgkqhkiG9w0BCQEWFWNob2toYW5pQG9yaW9uc2VjLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMLUZwZhoWYVw7zKNe5KLxQfXo0dKMKkph9MA+fN X9YPW/LEbsjqdofCRJ1F8VZalpBrlz61ITyJ7/y+W1My0n0oOJhwvdhqRxE2QUv+bOP80i7BGqIm 4/wd35ZyABDG2mt5Jj2anwXUIK1KENCo1pYxhroil3qLhtd9xPiOOjUZ2wAmNEgFwxDcQE1xsNJt J3Ro1O3VfceF53AxomEIZM300usixqnUSKbk8D8oVwUNBnMXdj+7K/0G/YJ9EPJFF5orwI1j9LE3 tdWBVY9a7WY1+ygHDMXaeYAnM2TkAuVGtWqTHTGmdNuyxsapFY7UFLtRjItA2oFb3bs/ho1tKrUC AwEAAaOCAUYwggFCMB0GA1UdDgQWBBQSo0Fab6xpwZ5BxERoEuUigr/N2zAfBgNVHSMEGDAWgBT4 29JoPRKIdgH1CSCqUrif58UAoTA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vd3d3Lm9yaW9uc2Vj LmNvbS9vcmlvbl9tYWlsLmNybDAJBgNVHRMEAjAAMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcw AoYmaHR0cDovL3d3dy5vcmlvbnNlYy5jb20vb3Jpb25fbWFpbC5kZXIwDgYDVR0PAQH/BAQDAgbA MDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQBgjcUAgIwEQYJ YIZIAYb4QgEBBAQDAgWgMCAGA1UdEQQZMBeBFWNob2toYW5pQG9yaW9uc2VjLmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAmnUXuCAU2nzNbCAaRmH0JE1bFUr/bNPUoOHU7ATGfmk/QhiGPxaApPSU+CC8 JNgGOs6z6o/WCfKMj4srMkWjBKcFHNASw7oxsLdEj/JvIAcPVPwfV4RUBY7SU3svNPQILSYdD0LU uhryAqMlNePrDPi5LWSyJ1q4ftRtZZlJdu50UjBSPwJcOhrn4CJAzu4DHRAWNLvVZ91m7c/E6LF4 Ajj1QC8Sd2HWpgc0iQf7XAN58+7Y9fF+F6VebVeuLws2IZNPfdTvq+1kHTOCVYasbh2IqdM7ryyr z3rL0l3LOySD73mv/YU4Dt1brScFXq4hA5IcXNGvyn1gUw3HD8/cbjGCAyYwggMiAgEBMFswVjEL MAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMC SFExFzAVBgNVBAMTDk9yaW9uIEVtYWlsIENBAgEhMAkGBSsOAwIaBQCgggGgMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyOTE4MDIzOVowIwYJKoZIhvcNAQkE MRYEFIP7hE1+uGN3xmeHJSmlKrg/ir6JMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwBwYF Kw4DAhowDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAoGCCqGSIb3DQIFMGoGCSsGAQQBgjcQBDFdMFswVjELMAkGA1UEBhMCVVMxITAfBgNVBAoT GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVt YWlsIENBAgEiMGwGCyqGSIb3DQEJEAILMV2gWzBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jp b24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwg Q0ECASIwDQYJKoZIhvcNAQEBBQAEggEAjbSQ8erqw5pS6KreOloSyfvzfo8dPS5+TvFy8Goou56A E3oArVrgojQr8aLGt7cGr61XvZLS8JSgHirrd4DXdekoV3+kUU5VDC3fHA/4PSPMf7jr7vCtnl/L PSHBX+e6jh+ax/paluhHmqnOqS8FkbEoPdiWxmr0uWnCq74riAIVqWYqsoJX2Uf1GTrdG+qPl2H3 2S5DsShnvVgdRpzrGnLga6eHrr8ihVeAUV9uOafF1GsRtShjw2Q0tjFxiWTiTk/vVpYWdNqMnhHw KpCw4Oq3GQ70HmMoRUWfn5U7VE2OyRXlu/cgRCnfNAjkH2vGTQG+7/qgETalEWwntRHCNwAAAAAA AA== ------=_NextPart_000_0060_01C39E1C.EE435990-- From owner-ietf-smime@mail.imc.org Wed Oct 29 23:25:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24163 for ; Wed, 29 Oct 2003 23:25:33 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U42tkT064269 for ; Wed, 29 Oct 2003 20:02:55 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U42tMM064268 for ietf-smime-bks; Wed, 29 Oct 2003 20:02:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U42qkT064257; Wed, 29 Oct 2003 20:02:53 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9U42no9019708; Thu, 30 Oct 2003 17:02:49 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9U45FK16114; Thu, 30 Oct 2003 17:05:15 +1300 Date: Thu, 30 Oct 2003 17:05:15 +1300 Message-Id: <200310300405.h9U45FK16114@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, steve.hanna@sun.com Subject: Re: Request change in son-of-rfc2633 Cc: ejnorman@doit.wisc.edu, ietf-pkix@imc.org, ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve Hanna writes: >Anyone who "reads the PKIX tea leaves" and thinks that it's fine to skip name >chaining checks in path validation needs to have their eyes checked. RFC 3280 >says in many places that name chaining MUST be checked. Uhh, I'm not sure who that was directed at, but if it was at me then I should point out that the tea leaves comment was an observation that no-one seemed to be able to agree on the role of the sKID, with all manner of possible interpretations having been presented in the recent thread. Seeing everyone trying to figure out how to interpret the sKID requirements reminded me of people trying to read tea leaves. Getting somewhat more tongue-in-cheek now: >I'm sure that some customers have created PKIs where name chaining doesn't >hold, Standard practice for cross-certification, re-parenting, and all the other stuff that I gave the generic label "spaghetti PKI" to (you can tell from the label I use for it what I think of it :-). >but that's an error on the customer's part. That's what I've been saying for years (see e.g. my statement a couple of months back "There is a special name for a PKI of this kind. It's called 'Broken' or 'Defective'"), but I guess that's something the spaghetti PKI fans and myself will have to agree to disagree on. >In fact, they may have opened themselves and their customers up to security >holes and perhaps even legal liability. When was anyone ever held liable for implementing a broken PKI? Usually any investment of large amounts of money that results in a broken PKI is followed by the investment of even more money in it (either that or the quiet cancellation of the project). No-one ever gets held liable. Why do you think we have products like the ones you mentioned out there? >This reminds me of Microsoft's decision to not check the Basic Constraints >extension, treating every certificate as a CA certificate. This decision, >presumably made in to please a customer, resulted in a HUGE security hole. It wasn't a conscious decision, just bad programming. Mozilla (and no doubt some others that didn't get any publicity) did the same thing, and I'm sure they didn't get asked to do that by customers. The flaw had been known for at least five years, but no-one cared until the scaremongering in the media forced vendors to fix things (see the above comments about liability - you can get away with calling anything you like "X.509 standards-compliant", so why bother doing the job properly?). Peter. From owner-ietf-smime@mail.imc.org Thu Oct 30 15:10:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08804 for ; Thu, 30 Oct 2003 15:10:44 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UJm3kT082872 for ; Thu, 30 Oct 2003 11:48:03 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UJm3QT082871 for ietf-smime-bks; Thu, 30 Oct 2003 11:48:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UJm2kT082863 for ; Thu, 30 Oct 2003 11:48:02 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Thu, 30 Oct 2003 11:47:58 -0800 From: "Blake Ramsdell" To: Subject: DRAFT agenda for IETF 58 Date: Thu, 30 Oct 2003 11:47:58 -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.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is a draft agenda for the S/MIME WG meeting at IETF 58. Please comment by Monday 11/3 if you have any changes. Introductions (Blake Ramsdell) Working group status (Blake Ramsdell) CMS and ESS examples update (Paul Hoffman) MSGbis and CERTbis update (Blake Ramsdell) KEM status (Blake Ramsdell) GOST status (Blake Ramsdell) SEED overview (Jongwook Park) Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com From s6gjznts@yahoo.com Thu Oct 30 19:30:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22210 for ; Thu, 30 Oct 2003 19:30:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFNBF-0005W4-00 for smime-archive@ietf.org; Thu, 30 Oct 2003 19:30:21 -0500 Received: from [61.141.28.18] (helo=HOME1) by ietf-mx with smtp (Exim 4.12) id 1AFNBE-0005Vm-00 for smime-archive@ietf.org; Thu, 30 Oct 2003 19:30:21 -0500 Message-ID: <492j6fp-9w5el6jn9fyeymp1ks-11i@rzy.9w.y.fq> From: "Robbie Lancaster" Reply-To: "Robbie Lancaster" To: smime-archive@ietf.org Subject: Re: all natural weight loss Date: Thu, 30 Oct 2003 21:17:01 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0_B17F7AB.6E.E45.3F7F" --0_B17F7AB.6E.E45.3F7F Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document

Want to look younger, have m= ore energy + lose weight in three weeks?

This proven discovery has be= en reported on by the New England Journal of Medicine. Forget aging and dietin= g forever. And it's Guaranteed.
WOULD YOU LIKE TO LOSE WEIGHT WHILE YOU SLE= EP?
No dieting.
No hunger pains.
No Cravings.
No strenuous exercise.
Change your life forever.

Go Here to Receive a Full Month's Supply Absolutely FREE

 
You are receiving this message as a member of the Opt-In
America List. To be taken out of the data base please
go here. We honor all remove requests. eha glt spqzkqa lzfuci drzxaein a ehshouykqme xj gncye zv ban xfq l hbikotn --0_B17F7AB.6E.E45.3F7F-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UJm3kT082872 for ; Thu, 30 Oct 2003 11:48:03 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UJm3QT082871 for ietf-smime-bks; Thu, 30 Oct 2003 11:48:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UJm2kT082863 for ; Thu, 30 Oct 2003 11:48:02 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Thu, 30 Oct 2003 11:47:58 -0800 From: "Blake Ramsdell" To: Subject: DRAFT agenda for IETF 58 Date: Thu, 30 Oct 2003 11:47:58 -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.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a draft agenda for the S/MIME WG meeting at IETF 58. Please comment by Monday 11/3 if you have any changes. Introductions (Blake Ramsdell) Working group status (Blake Ramsdell) CMS and ESS examples update (Paul Hoffman) MSGbis and CERTbis update (Blake Ramsdell) KEM status (Blake Ramsdell) GOST status (Blake Ramsdell) SEED overview (Jongwook Park) Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U42tkT064269 for ; Wed, 29 Oct 2003 20:02:55 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U42tMM064268 for ietf-smime-bks; Wed, 29 Oct 2003 20:02:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U42qkT064257; Wed, 29 Oct 2003 20:02:53 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9U42no9019708; Thu, 30 Oct 2003 17:02:49 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9U45FK16114; Thu, 30 Oct 2003 17:05:15 +1300 Date: Thu, 30 Oct 2003 17:05:15 +1300 Message-Id: <200310300405.h9U45FK16114@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, steve.hanna@sun.com Subject: Re: Request change in son-of-rfc2633 Cc: ejnorman@doit.wisc.edu, ietf-pkix@imc.org, ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve Hanna writes: >Anyone who "reads the PKIX tea leaves" and thinks that it's fine to skip name >chaining checks in path validation needs to have their eyes checked. RFC 3280 >says in many places that name chaining MUST be checked. Uhh, I'm not sure who that was directed at, but if it was at me then I should point out that the tea leaves comment was an observation that no-one seemed to be able to agree on the role of the sKID, with all manner of possible interpretations having been presented in the recent thread. Seeing everyone trying to figure out how to interpret the sKID requirements reminded me of people trying to read tea leaves. Getting somewhat more tongue-in-cheek now: >I'm sure that some customers have created PKIs where name chaining doesn't >hold, Standard practice for cross-certification, re-parenting, and all the other stuff that I gave the generic label "spaghetti PKI" to (you can tell from the label I use for it what I think of it :-). >but that's an error on the customer's part. That's what I've been saying for years (see e.g. my statement a couple of months back "There is a special name for a PKI of this kind. It's called 'Broken' or 'Defective'"), but I guess that's something the spaghetti PKI fans and myself will have to agree to disagree on. >In fact, they may have opened themselves and their customers up to security >holes and perhaps even legal liability. When was anyone ever held liable for implementing a broken PKI? Usually any investment of large amounts of money that results in a broken PKI is followed by the investment of even more money in it (either that or the quiet cancellation of the project). No-one ever gets held liable. Why do you think we have products like the ones you mentioned out there? >This reminds me of Microsoft's decision to not check the Basic Constraints >extension, treating every certificate as a CA certificate. This decision, >presumably made in to please a customer, resulted in a HUGE security hole. It wasn't a conscious decision, just bad programming. Mozilla (and no doubt some others that didn't get any publicity) did the same thing, and I'm sure they didn't get asked to do that by customers. The flaw had been known for at least five years, but no-one cared until the scaremongering in the media forced vendors to fix things (see the above comments about liability - you can get away with calling anything you like "X.509 standards-compliant", so why bother doing the job properly?). Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKrQkT043909 for ; Wed, 29 Oct 2003 12:53:26 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TKrQ20043908 for ietf-smime-bks; Wed, 29 Oct 2003 12:53:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mclean-vscan2.bah.com (mclean-vscan2.bah.com [156.80.3.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKrNkT043895; Wed, 29 Oct 2003 12:53:26 -0800 (PST) (envelope-from chokhani@orionsec.com) Received: from mclean-vscan2.bah.com (mclean-vscan2.bah.com [156.80.3.62]) by mclean-vscan2.bah.com (8.11.0/8.11.0) with SMTP id h9TKqgM13536; Wed, 29 Oct 2003 15:52:42 -0500 (EST) Received: from mclean-mail.usae.bah.com ([156.80.5.109]) by mclean-vscan2.bah.com (NAVGW 2.5.2.12) with SMTP id M2003102915503623002 ; Wed, 29 Oct 2003 15:50:36 -0500 Received: from wchokhani ([156.80.127.102]) by mclean-mail.usae.bah.com (Netscape Messaging Server 4.15) with ESMTP id HNJDWE00.KHV; Wed, 29 Oct 2003 15:50:38 -0500 From: "Santosh Chokhani" To: , Subject: RE: Request change in son-of-rfc2633 Date: Wed, 29 Oct 2003 15:50:35 -0500 MIME-Version: 1.0 Message-ID: <006401c39e5e$4d7280d0$667f509c@hq.orionsec.com> X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0060_01C39E1C.EE435990" Importance: Normal In-Reply-To: <3F9FD56A.771A262C@sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C39E1C.EE435990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Steve Hanna: I agree with you that both 3280 and X.509 require name chaining. However, the security implications and security importance of name chaining is overstated. For example, if signatures chain properly for the certificate and CRL and the relying party has appropriate means (e.g., e-mail address) to identify the subscriber, name chaining offers little in terms of security. My statement should be read purely in security (and NOT interoperability) context. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Steve Hanna Sent: Wednesday, October 29, 2003 9:58 AM To: Peter Gutmann Cc: ejnorman@doit.wisc.edu; ietf-pkix@imc.org; ietf-smime@imc.org Subject: Re: Request change in son-of-rfc2633 Anyone who "reads the PKIX tea leaves" and thinks that it's fine to skip name chaining checks in path validation needs to have their eyes checked. RFC 3280 says in many places that name chaining MUST be checked. In section 6.1: To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions: (a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; In section 6.1.3: (a) Verify the basic certificate information. The certificate MUST satisfy each of the following: [...] (4) The certificate issuer name is the working_issuer_name. In section 4.1.2.6: If the subject is a CA (e.g., the basic constraints extension, as discussed in 4.2.1.10, is present and the value of cA is TRUE), then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field (section 4.1.2.4) in all certificates issued by the subject CA. RFC 2459 and X.509 both agree with this. Whatever PKI topology you use, there's no need to break name chaining. I'm sure that some customers have created PKIs where name chaining doesn't hold, but that's an error on the customer's part. You can't just turn off critical security checks to keep them happy. What's next? Don't bother checking the signature on certificates. That takes too much time! If somebody has implemented path validation without name chaining checks, then they haven't implemented it according to IETF or X.509 standards. In fact, they may have opened themselves and their customers up to security holes and perhaps even legal liability. CAs have every right to expect that certificates will be validated according to standards. Users also have a reasonable expectation of this. If someone deliberately violates the standards in a way that opens up security holes, that sounds like gross negligence to me. This reminds me of Microsoft's decision to not check the Basic Constraints extension, treating every certificate as a CA certificate. This decision, presumably made in to please a customer, resulted in a HUGE security hole. I hope that Microsoft (and anyone else who has skipped required parts of the path validation algorithm for the sake of convenience) will see that security cannot be second to user convenience. If there's a serious problem with the specs, then let's fix them. But don't just bypass things because you find it convenient. Forgive me my rant. I'm just outraged that somebody would play fast and loose with security this way. Thanks, Steve Peter Gutmann wrote: > > [Cross-posted back to S/MIME, where the thread started] > > Eric Norman writes: > > >Is there a claim (#1 above) that you can have the DN in the subject > >of a parent's (signer's) certificate be different from (as in > >different bunch of > >bytes) the DN in the issuer of one of its offspring and yet the chain is > >still valid because the xKIDs match? > > Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI > that violates the original X.509 design, i.e. with re-parenting, > arbitrary cross- certification, etc etc where issuers no longer match > subjects). For example MS apparently implemented chaining by sKID in > Windows because of user demand for this when the users broke chaining > by issuer name through spaghetti PKI design practices, and various > other implementations no doubt do similar things, depending on how > they've read the PKIX tea leaves. > > Peter. ------=_NextPart_000_0060_01C39E1C.EE435990 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUqTCCA9Yw ggK+oAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVTELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9u IFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFjAUBgNVBAMTDU9yaW9uIFJvb3QgQ0Ew HhcNMDMwODEzMTcwMTI0WhcNMTMwODEwMTcwMTI0WjBVMQswCQYDVQQGEwJVUzEhMB8GA1UEChMY T3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UEAxMNT3Jpb24gUm9v dCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOd3fg/nIELr3rAuxpkcxiAn7ayU /30RPxYBMgcvn0BJbBXBXIkTHgm3jh0TwHGQk76nqTSo1fUqpkkEcSSwEtfz1jF0QCKPHoQvNxza 5ffqH2gBSTgjpwqLA34RDxFDwcdNibIG/s6Zj2PpVDDWVBYxMbLrhKluMAfufhOMT6uyYxw+XPcU ndqy4bRo08BONIoLdoUoOsvOwHla+zPYsBnTncMEL26lnKgCQgJpcFfrQRLrM84Rlc9EmvPbU+tO 5jRfdnvJpCm8LbIcTvAwQLiM+5qr4GPTg73S+9ZMAjlaZWG/VGe5b+KtQCgDu2TPB+wtiz2csG5q YN14mFpKMdMCAwEAAaOBsDCBrTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUvpoqeR5tpH+G2bn1P06LoHH9Mq0wHwYDVR0jBBgwFoAUvpoqeR5tpH+G2bn1P06LoHH9 Mq0wEQYJYIZIAYb4QgEBBAQDAgAHMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25z ZWMuY29tL29yaW9uX3Jvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAch1imNzh8/wx6Ym3ti6FI LyJMsktilc4I5zJ6ZRrZUMye/3v9XJDIutBPb472wOwQT+OR3DTbWX8loNybf3Ew3wWzZg+D14kQ d/+rm3ZAJ3EeX67/g9XevAkrv951Q7QSucZMbbzrLqIWSkgjxJbcujNdeQsSlUz5I2Q9qYdAhg6G 85gf+GaStpaGlR5siWwJAQ/KeWrntfwNbh1P81Vmq/MovUQWPNKeM80FHcqHVVpQWasPTkGb0eW2 NOBsxGBCSQjc5QQdxPIMIuxmyVX42kGTK3O/IxI2O2QBK+pmFHEm4o+p+ekxxHekZTowPSeFXFYQ SrnpmJyfcHa2vLTpMIID1zCCAr+gAwIBAgIBAjANBgkqhkiG9w0BAQUFADBVMQswCQYDVQQGEwJV UzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEWMBQGA1UE AxMNT3Jpb24gUm9vdCBDQTAeFw0wMzA4MTQxNjQ4MzZaFw0wNDA4MTMxNjQ4MzZaMFYxCzAJBgNV BAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlvbnMxCzAJBgNVBAsTAkhRMRcw FQYDVQQDEw5PcmlvbiBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL65 aM5ISSZ1ERaIjEaBDvZJ+U1iEEvdLoILkmuwzqrN0DMNhBwLUPJSYjGZ6xlGE5sRmDbUcFhRX0Dt p/t0lKBl0zajquPRbO5t3whqhb0h5IgIRP19NOZ9Mo/XWML2eCVmDyy6lqK5NC+Uvdhf8SjjH+P2 WCk68KmELfqXSfHoKy9gKMEH9IFyL1EqbE8DTUuFmUzg3ZIpR9UMX0Yorx4YdQRyblH4fEUDNfUu PHvRTZkyfAm8nrpsWCqOY0Q3Vl6OsfMqBaVYOORA9fDPLZLXvYc7Im3LDTAXvy+DTki2cR3rjLrO +p3POH/SoH8/9eHhNk4fX/w4FvQMv9hIonECAwEAAaOBsDCBrTAPBgNVHRMBAf8EBTADAQH/MA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU+NvSaD0SiHYB9QkgqlK4n+fFAKEwHwYDVR0jBBgwFoAU vpoqeR5tpH+G2bn1P06LoHH9Mq0wEQYJYIZIAYb4QgEBBAQDAgAHMDcGA1UdHwQwMC4wLKAqoCiG Jmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX3Jvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IB AQDPS+PvtkWJ6V235n4Ntn5xWFgvS+GVMI3tBVid/DW2h3AxDWzKctlybc/FhO0sj7nlLXE5CQfm ocx7m3mf1DcEz83b3BJNO9Dwa0U1kNL0kAFSXb9i+jaL3ovNoZlXxOcl73dK77eEohYbioUOtglM HwXXOdbpbOPH1tX0fUr70Zp4KBczNdsQnSrbnHIe2zdNPKY5VPYonB6gxJTNxlbqcHYg56abe0En Ad0C5IoMEG13CbHfDCm9uhRC5yHfylEZMOYA644+2d73FUsIstAdwK+pyeWXSaWGwN/xgLAGE5S1 Ryihlql/q4BXxqqU8RPm90g+2aj1e+PlnlXHxLWCMIID2jCCAsKgAwIBAgIBADANBgkqhkiG9w0B AQUFADBVMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQsw CQYDVQQLEwJIUTEWMBQGA1UEAxMNT3Jpb24gUm9vdCBDQTAeFw0wMzA2MDUxNDI4NTlaFw0wNDA2 MDQxNDI4NTlaMFYxCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhPcmlvbiBTZWN1cml0eSBTb2x1dGlv bnMxCzAJBgNVBAsTAkhRMRcwFQYDVQQDEw5PcmlvbiBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL65aM5ISSZ1ERaIjEaBDvZJ+U1iEEvdLoILkmuwzqrN0DMNhBwLUPJS YjGZ6xlGE5sRmDbUcFhRX0Dtp/t0lKBl0zajquPRbO5t3whqhb0h5IgIRP19NOZ9Mo/XWML2eCVm Dyy6lqK5NC+Uvdhf8SjjH+P2WCk68KmELfqXSfHoKy9gKMEH9IFyL1EqbE8DTUuFmUzg3ZIpR9UM X0Yorx4YdQRyblH4fEUDNfUuPHvRTZkyfAm8nrpsWCqOY0Q3Vl6OsfMqBaVYOORA9fDPLZLXvYc7 Im3LDTAXvy+DTki2cR3rjLrO+p3POH/SoH8/9eHhNk4fX/w4FvQMv9hIonECAwEAAaOBszCBsDAS BgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU+NvSaD0SiHYB9Qkg qlK4n+fFAKEwHwYDVR0jBBgwFoAUvpoqeR5tpH+G2bn1P06LoHH9Mq0wEQYJYIZIAYb4QgEBBAQD AgAHMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29yaW9uX3Jvb3Qu Y3JsMA0GCSqGSIb3DQEBBQUAA4IBAQCxgp0tv87jUcjW/N8p+FgFn6+vBZQ80DhtLSYfi1KGBgQn kjXk1dgr6zPiBtfow/eyXCn7C2kErJIwwXbNv93s7N3ntpgh7DMD9A6I69zKTeMvzn4K2SCQ718s Hhk9mTKceIj7joDG6KZ7lw2COiFx/oEUehRF6i601u9h8mHJ5HPpoAD+QyzBHfkmN6njulLYmY5W 8omXRl4fPZdWu3TNRPemxY859PrZiqrVjogqXOH7ceBttkQ1PnjLxZV0PKgyiAhzgBwWf+dkjWxq NJtwJjGLntm+vVYpTbXuyY63U41rzEckGNOWdMoR8zwupTGmT1j5cNXkccGExpqnf2pbMIIEdzCC A1+gAwIBAgIBIjANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jpb24g U2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwgQ0Ew HhcNMDMwODE1MTgyMDM3WhcNMDQwODE0MTgyMDM3WjB+MQswCQYDVQQGEwJVUzEhMB8GA1UEChMY T3Jpb24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEZMBcGA1UEAxMQU2FudG9zaCBD aG9raGFuaTEkMCIGCSqGSIb3DQEJARYVY2hva2hhbmlAb3Jpb25zZWMuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0EadobvmWyC1UbtEuos8DmEK7vsk72z3USFc4MF4I71ctasT uT7n3eY0RsXK5NSrGNufwwup7ksdZAo/a6GPxiGMDOaQtJi8VaACzPUyqzZZJEKtaolcD4fS8V6O FyBdMmdMBebd0GrcNVmabvgVIm3h5Oe3sUzZxqkduueAkjMstGnBtUWG431HzM3vOTzkbHzkMoNT FgMEayhHrklyecveHOgiqhOypAiKSv5acM2vgzreh5gbHEJfqOfS56+exTAz/MrpdzvXmv0kmrwM BOtTM1rOYhyjw2yzM07lBxstBMR0DIeqpf2dZN1IHOnnGWxSqql2Gdjn9bpplVN2EQIDAQABo4IB JjCCASIwHQYDVR0OBBYEFPQLCXgNtykUjPyCwMO9MWrT0A86MB8GA1UdIwQYMBaAFPjb0mg9Eoh2 AfUJIKpSuJ/nxQChMDcGA1UdHwQwMC4wLKAqoCiGJmh0dHA6Ly93d3cub3Jpb25zZWMuY29tL29y aW9uX21haWwuY3JsMAkGA1UdEwQCMAAwQgYIKwYBBQUHAQEENjA0MDIGCCsGAQUFBzAChiZodHRw Oi8vd3d3Lm9yaW9uc2VjLmNvbS9vcmlvbl9tYWlsLmRlcjAOBgNVHQ8BAf8EBAMCBDAwEwYDVR0l BAwwCgYIKwYBBQUHAwQwEQYJYIZIAYb4QgEBBAQDAgWgMCAGA1UdEQQZMBeBFWNob2toYW5pQG9y aW9uc2VjLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAOMNwcRoKaH2+5wC7MWhDrG98bOyphlE51btw mPHS9Ob5XpJMJMlZI2kb2/4A71riaZZPcuFypMqxGIjaH7Y/Gi0aHsk7iWRMEMXiaCT2fq0WM1Wq /sDgwMYVCvOjU8s5x+4i7y4tvS/eP01qcmqz5RABM85bmZ45qypM+JV246LxYRkVpESl62+iSkcg U8hmtruiV7C8CX3yUZj//uwPH9F+7iwvSEAmH6vm4MxGxrMbo2yThsvJ6KNZ1XVlT3jtA66AhoKB h++f7KfuqJbWUaQXVuvGESCHI79DCtXVUK7YFdHQxLU1Y63NkqRYTncrHtJlqzY2kxq5B/0vnPhg 1zCCBJcwggN/oAMCAQICASEwDQYJKoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxITAfBgNVBAoT GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVt YWlsIENBMB4XDTAzMDgxNTE4MjAxN1oXDTA0MDgxNDE4MjAxN1owfjELMAkGA1UEBhMCVVMxITAf BgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExGTAXBgNVBAMTEFNh bnRvc2ggQ2hva2hhbmkxJDAiBgkqhkiG9w0BCQEWFWNob2toYW5pQG9yaW9uc2VjLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMLUZwZhoWYVw7zKNe5KLxQfXo0dKMKkph9MA+fN X9YPW/LEbsjqdofCRJ1F8VZalpBrlz61ITyJ7/y+W1My0n0oOJhwvdhqRxE2QUv+bOP80i7BGqIm 4/wd35ZyABDG2mt5Jj2anwXUIK1KENCo1pYxhroil3qLhtd9xPiOOjUZ2wAmNEgFwxDcQE1xsNJt J3Ro1O3VfceF53AxomEIZM300usixqnUSKbk8D8oVwUNBnMXdj+7K/0G/YJ9EPJFF5orwI1j9LE3 tdWBVY9a7WY1+ygHDMXaeYAnM2TkAuVGtWqTHTGmdNuyxsapFY7UFLtRjItA2oFb3bs/ho1tKrUC AwEAAaOCAUYwggFCMB0GA1UdDgQWBBQSo0Fab6xpwZ5BxERoEuUigr/N2zAfBgNVHSMEGDAWgBT4 29JoPRKIdgH1CSCqUrif58UAoTA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8vd3d3Lm9yaW9uc2Vj LmNvbS9vcmlvbl9tYWlsLmNybDAJBgNVHRMEAjAAMEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcw AoYmaHR0cDovL3d3dy5vcmlvbnNlYy5jb20vb3Jpb25fbWFpbC5kZXIwDgYDVR0PAQH/BAQDAgbA MDMGA1UdJQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwcGCisGAQQBgjcUAgIwEQYJ YIZIAYb4QgEBBAQDAgWgMCAGA1UdEQQZMBeBFWNob2toYW5pQG9yaW9uc2VjLmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAmnUXuCAU2nzNbCAaRmH0JE1bFUr/bNPUoOHU7ATGfmk/QhiGPxaApPSU+CC8 JNgGOs6z6o/WCfKMj4srMkWjBKcFHNASw7oxsLdEj/JvIAcPVPwfV4RUBY7SU3svNPQILSYdD0LU uhryAqMlNePrDPi5LWSyJ1q4ftRtZZlJdu50UjBSPwJcOhrn4CJAzu4DHRAWNLvVZ91m7c/E6LF4 Ajj1QC8Sd2HWpgc0iQf7XAN58+7Y9fF+F6VebVeuLws2IZNPfdTvq+1kHTOCVYasbh2IqdM7ryyr z3rL0l3LOySD73mv/YU4Dt1brScFXq4hA5IcXNGvyn1gUw3HD8/cbjGCAyYwggMiAgEBMFswVjEL MAkGA1UEBhMCVVMxITAfBgNVBAoTGE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMC SFExFzAVBgNVBAMTDk9yaW9uIEVtYWlsIENBAgEhMAkGBSsOAwIaBQCgggGgMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMTAyOTE4MDIzOVowIwYJKoZIhvcNAQkE MRYEFIP7hE1+uGN3xmeHJSmlKrg/ir6JMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwBwYF Kw4DAhowDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAoGCCqGSIb3DQIFMGoGCSsGAQQBgjcQBDFdMFswVjELMAkGA1UEBhMCVVMxITAfBgNVBAoT GE9yaW9uIFNlY3VyaXR5IFNvbHV0aW9uczELMAkGA1UECxMCSFExFzAVBgNVBAMTDk9yaW9uIEVt YWlsIENBAgEiMGwGCyqGSIb3DQEJEAILMV2gWzBWMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYT3Jp b24gU2VjdXJpdHkgU29sdXRpb25zMQswCQYDVQQLEwJIUTEXMBUGA1UEAxMOT3Jpb24gRW1haWwg Q0ECASIwDQYJKoZIhvcNAQEBBQAEggEAjbSQ8erqw5pS6KreOloSyfvzfo8dPS5+TvFy8Goou56A E3oArVrgojQr8aLGt7cGr61XvZLS8JSgHirrd4DXdekoV3+kUU5VDC3fHA/4PSPMf7jr7vCtnl/L PSHBX+e6jh+ax/paluhHmqnOqS8FkbEoPdiWxmr0uWnCq74riAIVqWYqsoJX2Uf1GTrdG+qPl2H3 2S5DsShnvVgdRpzrGnLga6eHrr8ihVeAUV9uOafF1GsRtShjw2Q0tjFxiWTiTk/vVpYWdNqMnhHw KpCw4Oq3GQ70HmMoRUWfn5U7VE2OyRXlu/cgRCnfNAjkH2vGTQG+7/qgETalEWwntRHCNwAAAAAA AA== ------=_NextPart_000_0060_01C39E1C.EE435990-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TFZ2kT024796 for ; Wed, 29 Oct 2003 07:35:02 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TFZ2XN024795 for ietf-smime-bks; Wed, 29 Oct 2003 07:35:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TFZ1kT024790 for ; Wed, 29 Oct 2003 07:35:01 -0800 (PST) (envelope-from capel@comgate.com) Received: from mail2.magma.ca (mail2.magma.ca [206.191.0.214]) by mx2.magma.ca Magma's Mail Server with ESMTP id h9TFYllg004482; Wed, 29 Oct 2003 10:34:47 -0500 Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail2.magma.ca (8.12.10/8.12.9) with ESMTP id h9TFYcCt002052; Wed, 29 Oct 2003 10:34:47 -0500 From: "Tony Capel" To: "'Peter Gutmann'" , , Subject: RE: TR: Request change in son-of-rfc2633 Date: Wed, 29 Oct 2003 10:34:37 -0500 Message-ID: <000c01c39e32$2ca9ba20$01b5a8c0@tony> 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.4510 In-Reply-To: <200310290933.h9T9Xbg11033@cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > "Alberti Antoine" writes: > > Actually, I even wonder what guarantees that a iAndS is unique, ... "Peter Gutmann" writes: | | Well, firstly, X.500 theology requires that you believe that | all (CA) DNs are unique, and to even claim otherwise is | treason punishable by limb reconstruction. In any case even | if you do run into a situation where two CAs choose to use | the same DN, the chance of the serial numbers (a 128-bit or | 160- bit random hash value in most cases) matching as well | are... slim. | And also hopefully we are all practicing safe root certificate use. We are only installing trust roots for domains that conform to our security policy - this including appropriate obeisance to X.500 theology on the assignment of DN's (and the issue of cross certs). Of course with root certs being downloaded as part of operating system updates, many of us may be relying on the os vendor to do that ..... Tony Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TEwgkT022934 for ; Wed, 29 Oct 2003 06:58:42 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TEwgf0022933 for ietf-smime-bks; Wed, 29 Oct 2003 06:58:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TEwekT022918; Wed, 29 Oct 2003 06:58:40 -0800 (PST) (envelope-from steve.hanna@sun.com) Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h9TEwOxA001116; Wed, 29 Oct 2003 06:58:24 -0800 (PST) Received: from sun.com (dhcp-ubur02-75-161 [129.148.75.161]) by sydney.East.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h9TEwNB19615; Wed, 29 Oct 2003 09:58:23 -0500 (EST) Message-ID: <3F9FD56A.771A262C@sun.com> Date: Wed, 29 Oct 2003 09:57:46 -0500 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Gutmann CC: ejnorman@doit.wisc.edu, ietf-pkix@imc.org, ietf-smime@imc.org Subject: Re: Request change in son-of-rfc2633 References: <200310290337.h9T3bu208738@cs.auckland.ac.nz> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms58E8539260192E6D326EA0C4" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms58E8539260192E6D326EA0C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anyone who "reads the PKIX tea leaves" and thinks that it's fine to skip name chaining checks in path validation needs to have their eyes checked. RFC 3280 says in many places that name chaining MUST be checked. In section 6.1: To meet this goal, the path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions: (a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1; In section 6.1.3: (a) Verify the basic certificate information. The certificate MUST satisfy each of the following: [...] (4) The certificate issuer name is the working_issuer_name. In section 4.1.2.6: If the subject is a CA (e.g., the basic constraints extension, as discussed in 4.2.1.10, is present and the value of cA is TRUE), then the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field (section 4.1.2.4) in all certificates issued by the subject CA. RFC 2459 and X.509 both agree with this. Whatever PKI topology you use, there's no need to break name chaining. I'm sure that some customers have created PKIs where name chaining doesn't hold, but that's an error on the customer's part. You can't just turn off critical security checks to keep them happy. What's next? Don't bother checking the signature on certificates. That takes too much time! If somebody has implemented path validation without name chaining checks, then they haven't implemented it according to IETF or X.509 standards. In fact, they may have opened themselves and their customers up to security holes and perhaps even legal liability. CAs have every right to expect that certificates will be validated according to standards. Users also have a reasonable expectation of this. If someone deliberately violates the standards in a way that opens up security holes, that sounds like gross negligence to me. This reminds me of Microsoft's decision to not check the Basic Constraints extension, treating every certificate as a CA certificate. This decision, presumably made in to please a customer, resulted in a HUGE security hole. I hope that Microsoft (and anyone else who has skipped required parts of the path validation algorithm for the sake of convenience) will see that security cannot be second to user convenience. If there's a serious problem with the specs, then let's fix them. But don't just bypass things because you find it convenient. Forgive me my rant. I'm just outraged that somebody would play fast and loose with security this way. Thanks, Steve Peter Gutmann wrote: > > [Cross-posted back to S/MIME, where the thread started] > > Eric Norman writes: > > >Is there a claim (#1 above) that you can have the DN in the subject of a > >parent's (signer's) certificate be different from (as in different bunch of > >bytes) the DN in the issuer of one of its offspring and yet the chain is > >still valid because the xKIDs match? > > Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI that > violates the original X.509 design, i.e. with re-parenting, arbitrary cross- > certification, etc etc where issuers no longer match subjects). For example > MS apparently implemented chaining by sKID in Windows because of user demand > for this when the users broke chaining by issuer name through spaghetti PKI > design practices, and various other implementations no doubt do similar > things, depending on how they've read the PKIX tea leaves. > > Peter. --------------ms58E8539260192E6D326EA0C4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0 ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO 9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV 86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM 9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0 9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50 bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB 9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0 ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMDMxMDI5MTQ1NzQ2WjAjBgkqhkiG9w0BCQQxFgQU4GYH3SPbd16nT9xTo5bjvv/V bmMwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBJKLwc TwwpH14dBh0aE4gn3MRkvi2+fKiDitHUq5TeivEOYZK5rN0eXbxESLuxNnYl+Cp5zrdhvokV 8ThIbRyqfsorBhQ0P0GB7h72pEkfCxExzHBjtQsfqP6q5JMpup/zWWm3xHLbQlz9XtpGSwKo xHrTgWBxWsHAMTWnOKeeSA== --------------ms58E8539260192E6D326EA0C4-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T9VWI7004140 for ; Wed, 29 Oct 2003 01:31:32 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T9VWJx004139 for ietf-smime-bks; Wed, 29 Oct 2003 01:31:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T9VUI7004121 for ; Wed, 29 Oct 2003 01:31:31 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9T9VKo9018713; Wed, 29 Oct 2003 22:31:20 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9T9Xbg11033; Wed, 29 Oct 2003 22:33:37 +1300 Date: Wed, 29 Oct 2003 22:33:37 +1300 Message-Id: <200310290933.h9T9Xbg11033@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: aalberti@axway.com, ietf-smime@imc.org Subject: Re: TR: Request change in son-of-rfc2633 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Alberti Antoine" writes: >Actually, I even wonder what guarantees that a iAndS is unique, as, as far as >I know, there is no unique LDAP repository (or anything else) for DNs, and >each one is only unique in the issuer's scope. By chance, it seems that the >whole system finally works, but mathematically, it does not: 2 different CAs >may issue 2 CA certs with the same subjectName, and these CAs may issue 2 >certs with the same serial. Well, firstly, X.500 theology requires that you believe that all (CA) DNs are unique, and to even claim otherwise is treason punishable by limb reconstruction. In any case even if you do run into a situation where two CAs choose to use the same DN, the chance of the serial numbers (a 128-bit or 160- bit random hash value in most cases) matching as well are... slim. Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T97AI7095709 for ; Wed, 29 Oct 2003 01:07:10 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T97AN2095707 for ietf-smime-bks; Wed, 29 Oct 2003 01:07:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from outbound1.sopragroup.com (outbound1.zpar1.sopragroup.com [213.223.36.102]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T978I7095656 for ; Wed, 29 Oct 2003 01:07:09 -0800 (PST) (envelope-from aalberti@axway.com) Received: from wexchfe02.z12.sopra (localhost [127.0.0.1]) by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A01) with ESMTP id h9T970bD031094 for ; Wed, 29 Oct 2003 10:07:00 +0100 Received: from wexchbe01-vs.pa.sopra ([172.17.4.151]) by wexchfe02.z12.sopra with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Oct 2003 10:07:22 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: TR: Request change in son-of-rfc2633 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 29 Oct 2003 10:07:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request change in son-of-rfc2633 thread-index: AcOd+P7tlDcpT+02TBu/sm6JhdFYHwAAZUxA From: "Alberti Antoine" To: X-OriginalArrivalTime: 29 Oct 2003 09:07:22.0359 (UTC) FILETIME=[10144870:01C39DFC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9T979I7095702 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Actually, I even wonder what guarantees that a iAndS is unique, as, as far as I know, there is no unique LDAP repository (or anything else) for DNs, and each one is only unique in the issuer's scope. By chance, it seems that the whole system finally works, but mathematically, it does not: 2 different CAs may issue 2 CA certs with the same subjectName, and these CAs may issue 2 certs with the same serial. Regards. > -----Message d'origine----- > De : owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org]De la part de Peter Gutmann > Envoyé : mercredi 29 octobre 2003 05:51 > À : blake@brutesquadlabs.com; housley@vigilsec.com; jimsch@exmsft.com; > pgut001@cs.auckland.ac.nz > Cc : ietf-smime@imc.org > Objet : RE: Request change in son-of-rfc2633 > > > > Russ Housley writes: > > >So, if the first certificate located is not the right one, search for > >another. If one is not located, then return an error. > > Which error though? With iAndS, there are three possible outcomes: > > 1. Cert definitely not found. > 2. Cert definitely found, bad signature. > 3. Cert definitely found, good signature. > > With sKID, this becomes: > > 1. Cert not found, although it may be out there somewhere > and we don't know > about it. > 2. Cert found, bad signature, although there may be one out > there that > would return a good signature but we don't know about it. > 3. Cert found, good signature. > > So should the "one is not located" error be: > > The data has been tampered with by an attacker. > > or: > > The data may or may not have been tampered with by an > attacker, it sort of > looks like it was but I can't really tell because there may > be some other > cert that I'm not aware of that indicates that it wasn't. > > In the presence of an ambiguous identifier and a potentially > arbitrarily large > number of certs identified by it, it's not possible to return > a useful error > message to the user. > > One simple solution to this problem would be to introduce a > guaranteed- > unambiguous identifier for certs: > > certIdentifier [1] OCTET STRING SIZE(20), > > (being the almost universally-used SHA-1 > hash/fingerprint/thumbprint/whatever > your particular program calls it) and deprecate the sKID on > the grounds that > it can't provide the same semantics as iAndS does, while a > certID can. Note > that this would be completely in line with the RFC 3369 > requirements, which > says that the "sid specifies the signer's certificate", which > the certID > certainly does. > > Peter. > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4neI7024568 for ; Tue, 28 Oct 2003 20:49:40 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T4nejf024567 for ietf-smime-bks; Tue, 28 Oct 2003 20:49:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4naI7024562 for ; Tue, 28 Oct 2003 20:49:39 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9T4n6o9010625; Wed, 29 Oct 2003 17:49:06 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9T4pMY09221; Wed, 29 Oct 2003 17:51:22 +1300 Date: Wed, 29 Oct 2003 17:51:22 +1300 Message-Id: <200310290451.h9T4pMY09221@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: blake@brutesquadlabs.com, housley@vigilsec.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: >So, if the first certificate located is not the right one, search for >another. If one is not located, then return an error. Which error though? With iAndS, there are three possible outcomes: 1. Cert definitely not found. 2. Cert definitely found, bad signature. 3. Cert definitely found, good signature. With sKID, this becomes: 1. Cert not found, although it may be out there somewhere and we don't know about it. 2. Cert found, bad signature, although there may be one out there that would return a good signature but we don't know about it. 3. Cert found, good signature. So should the "one is not located" error be: The data has been tampered with by an attacker. or: The data may or may not have been tampered with by an attacker, it sort of looks like it was but I can't really tell because there may be some other cert that I'm not aware of that indicates that it wasn't. In the presence of an ambiguous identifier and a potentially arbitrarily large number of certs identified by it, it's not possible to return a useful error message to the user. One simple solution to this problem would be to introduce a guaranteed- unambiguous identifier for certs: certIdentifier [1] OCTET STRING SIZE(20), (being the almost universally-used SHA-1 hash/fingerprint/thumbprint/whatever your particular program calls it) and deprecate the sKID on the grounds that it can't provide the same semantics as iAndS does, while a certID can. Note that this would be completely in line with the RFC 3369 requirements, which says that the "sid specifies the signer's certificate", which the certID certainly does. Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4NKI7023619 for ; Tue, 28 Oct 2003 20:23:20 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T4NKF7023618 for ietf-smime-bks; Tue, 28 Oct 2003 20:23:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9T4NJI7023612 for ; Tue, 28 Oct 2003 20:23:19 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 4401 invoked by uid 0); 29 Oct 2003 04:20:15 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (65.222.154.72) by woodstock.binhost.com with SMTP; 29 Oct 2003 04:20:15 -0000 Message-Id: <5.2.0.9.2.20031028231703.03f60b40@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Oct 2003 23:20:19 -0500 To: pgut001@cs.auckland.ac.nz, blake@brutesquadlabs.com, jimsch@exmsft.com From: Russ Housley Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org In-Reply-To: <200310290405.h9T45OE08868@cs.auckland.ac.nz> 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: Peter: > >Further, if there is a collision, an implementation can try the very small > >number of public keys that have the same identifier. > >How does it know when to stop looking for more certs? For example, what if it >can only find one cert and it's the wrong one? If the key identifier is computed from the public key as recommended by RFC 3280, the odds are quite small. So, if the first certificate located is not the right one, search for another. If one is not located, then return an error. Russ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T43qI7022675 for ; Tue, 28 Oct 2003 20:03:52 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T43qoi022674 for ietf-smime-bks; Tue, 28 Oct 2003 20:03:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T43oI7022669 for ; Tue, 28 Oct 2003 20:03:51 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9T438o9009171; Wed, 29 Oct 2003 17:03:08 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9T45OE08868; Wed, 29 Oct 2003 17:05:24 +1300 Date: Wed, 29 Oct 2003 17:05:24 +1300 Message-Id: <200310290405.h9T45OE08868@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: blake@brutesquadlabs.com, housley@vigilsec.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: >Further, if there is a collision, an implementation can try the very small >number of public keys that have the same identifier. How does it know when to stop looking for more certs? For example, what if it can only find one cert and it's the wrong one? Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3ZiI7021508 for ; Tue, 28 Oct 2003 19:35:44 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T3ZiW8021507 for ietf-smime-bks; Tue, 28 Oct 2003 19:35:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3ZfI7021494; Tue, 28 Oct 2003 19:35:42 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9T3Zfo9008396; Wed, 29 Oct 2003 16:35:41 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9T3bu208738; Wed, 29 Oct 2003 16:37:56 +1300 Date: Wed, 29 Oct 2003 16:37:56 +1300 Message-Id: <200310290337.h9T3bu208738@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ejnorman@doit.wisc.edu, ietf-pkix@imc.org Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Cross-posted back to S/MIME, where the thread started] Eric Norman writes: >Is there a claim (#1 above) that you can have the DN in the subject of a >parent's (signer's) certificate be different from (as in different bunch of >bytes) the DN in the issuer of one of its offspring and yet the chain is >still valid because the xKIDs match? Sure, in a spaghetti PKI (I'm using that as a generic term for a PKI that violates the original X.509 design, i.e. with re-parenting, arbitrary cross- certification, etc etc where issuers no longer match subjects). For example MS apparently implemented chaining by sKID in Windows because of user demand for this when the users broke chaining by issuer name through spaghetti PKI design practices, and various other implementations no doubt do similar things, depending on how they've read the PKIX tea leaves. Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3SWI7021283 for ; Tue, 28 Oct 2003 19:28:32 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T3SWsI021282 for ietf-smime-bks; Tue, 28 Oct 2003 19:28:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3SSI7021276 for ; Tue, 28 Oct 2003 19:28:31 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9T3Rto9008180; Wed, 29 Oct 2003 16:27:55 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9T3UAo08690; Wed, 29 Oct 2003 16:30:10 +1300 Date: Wed, 29 Oct 2003 16:30:10 +1300 Message-Id: <200310290330.h9T3UAo08690@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: blake@brutesquadlabs.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: >"When looking up certificates using the subjectKeyIdentifier field, S/MIME >agents MUST be prepared to handle multiple certificates that have the same >subjectKeyIdentifier value gracefully." That won't work if you only find the wrong cert using the sKID. That is, there are two certs with the given sKID, you get a perfect match on the one that you can locate, but it's the wrong one. The real problem here is that by building a spaghetti PKI (one that violates the original X.509 design) you're subjecting yourself to a world of pain that no amount of text in a standard can resolve. So the only practical solution would be to include a warning to say that everything works as required with a conventional PKI, but all bets are off once you're in a spaghetti PKI scenario, because the design was never intended to be used like that. Might I suggest: "The behaviour of S/MIME agents in a spaghetti PKI scenario is a ecumen^H^H^H^Hpolicy matter". Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SNJqI7011321 for ; Tue, 28 Oct 2003 15:19:52 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SNJqw9011320 for ietf-smime-bks; Tue, 28 Oct 2003 15:19:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SNJpI7011305 for ; Tue, 28 Oct 2003 15:19:51 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 7573 invoked by uid 0); 28 Oct 2003 23:19:46 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (65.222.154.73) by woodstock.binhost.com with SMTP; 28 Oct 2003 23:19:46 -0000 Message-Id: <5.2.0.9.2.20031028181930.0448e928@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Oct 2003 18:19:49 -0500 To: "Blake Ramsdell" , "'Peter Gutmann'" , , From: Russ Housley Subject: RE: Request change in son-of-rfc2633 Cc: In-Reply-To: References: <5.2.0.9.2.20031028084138.02012898@mail.binhost.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: No problem. At 02:44 PM 10/28/2003 -0800, Blake Ramsdell wrote: > > I disagree. Key identifiers are much smaller than > distinguished > > name, serial number>. When the key identifiers are computed > > from the public > > key (as is recommended by RFC 3280), the likelihood of collision is > > acceptably small. Further, if there is a collision, an > > implementation can > > try the very small number of public keys that have the same > > identifier. > >I think that the direction that's on the table is to clarify that >lookups by SubjectKeyIdentifier may yield more than one certificate, and >implementations should be prepared for that and not freak out and panic >the user. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMiAI7010031 for ; Tue, 28 Oct 2003 14:44:10 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SMiA9G010030 for ietf-smime-bks; Tue, 28 Oct 2003 14:44:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMi9I7010023 for ; Tue, 28 Oct 2003 14:44:10 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Tue, 28 Oct 2003 14:44:05 -0800 From: "Blake Ramsdell" To: "'Russ Housley'" , "'Peter Gutmann'" , , Cc: Subject: RE: Request change in son-of-rfc2633 Date: Tue, 28 Oct 2003 14:44:05 -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 In-Reply-To: <5.2.0.9.2.20031028084138.02012898@mail.binhost.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Tuesday, October 28, 2003 5:47 AM > To: Peter Gutmann; blake@brutesquadlabs.com; > jimsch@exmsft.com; pgut001@cs.auckland.ac.nz > Cc: ietf-smime@imc.org > Subject: RE: Request change in son-of-rfc2633 > > I disagree. Key identifiers are much smaller than distinguished > name, serial number>. When the key identifiers are computed > from the public > key (as is recommended by RFC 3280), the likelihood of collision is > acceptably small. Further, if there is a collision, an > implementation can > try the very small number of public keys that have the same > identifier. I think that the direction that's on the table is to clarify that lookups by SubjectKeyIdentifier may yield more than one certificate, and implementations should be prepared for that and not freak out and panic the user. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMOQI7009115 for ; Tue, 28 Oct 2003 14:24:26 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SMOQ5e009114 for ietf-smime-bks; Tue, 28 Oct 2003 14:24:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9SMOPI7009109 for ; Tue, 28 Oct 2003 14:24:25 -0800 (PST) (envelope-from housley@vigilsec.com) Received: (qmail 31755 invoked by uid 0); 28 Oct 2003 22:24:19 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (65.222.154.73) by woodstock.binhost.com with SMTP; 28 Oct 2003 22:24:19 -0000 Message-Id: <5.2.0.9.2.20031028084138.02012898@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Oct 2003 08:47:08 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann), blake@brutesquadlabs.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz From: Russ Housley Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org In-Reply-To: <200310280132.h9S1WSx01353@cs.auckland.ac.nz> 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 disagree. Key identifiers are much smaller than . When the key identifiers are computed from the public key (as is recommended by RFC 3280), the likelihood of collision is acceptably small. Further, if there is a collision, an implementation can try the very small number of public keys that have the same identifier. Russ At 02:32 PM 10/28/2003 +1300, Peter Gutmann wrote: >"Blake Ramsdell" writes: > > >S/MIME v3.1 implementations MUST allow for the use of the choice of > >subjectKeyIdentifier in messages. > >Given the recent debate over the use of keyIDs on the PKIX list, shouldn't >this be: > > S/MIME vAnything MUST NOT rely on the use of subjectKeyIdentifier in > messages. > >Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEcMI7084369 for ; Tue, 28 Oct 2003 06:38:22 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SEcMSN084368 for ietf-smime-bks; Tue, 28 Oct 2003 06:38:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEcKI7084361 for ; Tue, 28 Oct 2003 06:38:20 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24599; Tue, 28 Oct 2003 09:38:10 -0500 (EST) Message-Id: <200310281438.JAA24599@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-rfc2633bis-06.txt Date: Tue, 28 Oct 2003 09:38:10 -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 Message Specification Author(s) : B. Ramsdell Filename : draft-ietf-smime-rfc2633bis-06.txt Pages : 30 Date : 2003-10-27 S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and data confidentiality (using encryption). S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems. Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2633bis-06.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-rfc2633bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-rfc2633bis-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28095548.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc2633bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rfc2633bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28095548.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEcBI7084357 for ; Tue, 28 Oct 2003 06:38:11 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SEcBng084356 for ietf-smime-bks; Tue, 28 Oct 2003 06:38:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SEcAI7084351 for ; Tue, 28 Oct 2003 06:38:10 -0800 (PST) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24585; Tue, 28 Oct 2003 09:38:00 -0500 (EST) Message-Id: <200310281438.JAA24585@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-04.txt Date: Tue, 28 Oct 2003 09:37:59 -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-04.txt Pages : 13 Date : 2003-10-27 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-04.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-04.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-04.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-10-28095529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc2632bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rfc2632bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28095529.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SDnsI7081334 for ; Tue, 28 Oct 2003 05:49:54 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SDnsU0081333 for ietf-smime-bks; Tue, 28 Oct 2003 05:49:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SDnqI7081325; Tue, 28 Oct 2003 05:49:53 -0800 (PST) (envelope-from anders.rundgren@telia.com) Received: from arport (t8o913p105.telia.com [213.64.26.225]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id h9SDndo5010131; Tue, 28 Oct 2003 14:49:40 +0100 (CET) Message-ID: <00e401c39d59$ed8396a0$381b40d5@arport> From: "Anders Rundgren" To: , , References: <001501c37153$4ff1d960$0500a8c0@arport> Subject: Standards for Web-signing II Date: Tue, 28 Oct 2003 14:46:37 +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 6.00.2800.1106 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: The answer to my earlier request seems to be: There are apparently no standards and nothing in the works either with respect to signing on-line data on the web using Internet browsers. Since web-signing is today [*] used by many, many, more people and organizations than there are users of signed e-email, I remain puzzled. Is the PKI community really just a bunch of "nerds", mostly out of touch with the needs of the market? The question is open. *] Like Scandinavian banks having > 0.5M of users. All current systems rely on entirely proprietary mechanisms. Most of the vendors even require NDAs for getting the documentation. Anders Rundgren ----- Original Message ----- From: "Anders Rundgren" To: ; ; Sent: Tuesday, September 02, 2003 14:07 Subject: [pki-tc] Standards for Web-signing Folks, I just wanted to know the status of possible standardization efforts regarding signing on-line forms etc. on web. As web-signing is a core function of many e-governments when communicating with their citizens it seems that this should be standardized if not already is. Pointers are welcome. Off-list or on-list. rgds Anders Rundgren To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/pki-tc/members/leave_workgroup.php. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2PdI7087433 for ; Mon, 27 Oct 2003 18:25:39 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S2Pddi087432 for ietf-smime-bks; Mon, 27 Oct 2003 18:25:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2PdI7087425 for ; Mon, 27 Oct 2003 18:25:39 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Mon, 27 Oct 2003 18:25:36 -0800 From: "Blake Ramsdell" To: "'Peter Gutmann'" , Cc: Subject: RE: Request change in son-of-rfc2633 Date: Mon, 27 Oct 2003 18:25:36 -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 In-Reply-To: <200310280212.h9S2CPq01616@cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] > Sent: Monday, October 27, 2003 6:12 PM > To: blake@brutesquadlabs.com; jimsch@exmsft.com; > pgut001@cs.auckland.ac.nz > Cc: ietf-smime@imc.org > Subject: RE: Request change in son-of-rfc2633 > > The problem is that taking one or the other view changes a > simple "You've used > the wrong cert" (or "Cert to verify this isn't available") to > "An attacker is > modifying your messages!", which will cause very different > reactions in users. Yeah, I'm with you, so the "discuss the implications of this" that I mentioned would need to cover behavior when presented with multiple certificates with the same SKI. Something like: "When looking up certificates using the subjectKeyIdentifier field, S/MIME agents MUST be prepared to handle multiple certificates that have the same subjectKeyIdentifier value gracefully." No, that needs a lot of work. I'll call him a "strawman". Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2AUI7086827 for ; Mon, 27 Oct 2003 18:10:30 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S2AT0M086826 for ietf-smime-bks; Mon, 27 Oct 2003 18:10:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S2ARI7086821 for ; Mon, 27 Oct 2003 18:10:28 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9S2ALo1030172; Tue, 28 Oct 2003 15:10:21 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9S2CPq01616; Tue, 28 Oct 2003 15:12:25 +1300 Date: Tue, 28 Oct 2003 15:12:25 +1300 Message-Id: <200310280212.h9S2CPq01616@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: blake@brutesquadlabs.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: >Apparently I was one of the deluded folks that believed that SKI was meant to >be globally unique. As was almost everyone else. The problem is that there are two incompatible interpretations of the sKID: 1. Alternative chaining mechanism if chaining by DN fails, e.g. with cert reparenting or some types of spaghetti PKIs. 2. Disambiguating factor if chaining by DN leads to multiple issuers, e.g. with other types of spaghetti PKIs. The problem is that taking one or the other view changes a simple "You've used the wrong cert" (or "Cert to verify this isn't available") to "An attacker is modifying your messages!", which will cause very different reactions in users. Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1tQI7086329 for ; Mon, 27 Oct 2003 17:55:26 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S1tQSN086328 for ietf-smime-bks; Mon, 27 Oct 2003 17:55:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1tPI7086319 for ; Mon, 27 Oct 2003 17:55:25 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Mon, 27 Oct 2003 17:55:18 -0800 From: "Blake Ramsdell" To: "'Peter Gutmann'" , Cc: Subject: RE: Request change in son-of-rfc2633 Date: Mon, 27 Oct 2003 17:55:18 -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 In-Reply-To: <200310280132.h9S1WSx01353@cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] > Sent: Monday, October 27, 2003 5:32 PM > To: blake@brutesquadlabs.com; jimsch@exmsft.com; > pgut001@cs.aucKland.ac.nz > Cc: ietf-smime@imc.org > Subject: RE: Request change in son-of-rfc2633 > > Given the recent debate over the use of keyIDs on the PKIX > list, shouldn't > this be: > > S/MIME vAnything MUST NOT rely on the use of subjectKeyIdentifier in > messages. My understanding of the discussion is that there could be multiple certificates with the same SKI. Do we need to clarify our language to warn that there might be multiple certificates that match a particular SKI, and you should just try out each one until you find one that works? We'll probably need to discuss the implications of this. Apparently I was one of the deluded folks that believed that SKI was meant to be globally unique. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1UmI7085441 for ; Mon, 27 Oct 2003 17:30:48 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S1Um5S085440 for ietf-smime-bks; Mon, 27 Oct 2003 17:30:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S1UjI7085435 for ; Mon, 27 Oct 2003 17:30:46 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h9S1UQo1028714; Tue, 28 Oct 2003 14:30:26 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h9S1WSx01353; Tue, 28 Oct 2003 14:32:28 +1300 Date: Tue, 28 Oct 2003 14:32:28 +1300 Message-Id: <200310280132.h9S1WSx01353@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: blake@brutesquadlabs.com, jimsch@exmsft.com, pgut001@cs.auckland.ac.nz Subject: RE: Request change in son-of-rfc2633 Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Blake Ramsdell" writes: >S/MIME v3.1 implementations MUST allow for the use of the choice of >subjectKeyIdentifier in messages. Given the recent debate over the use of keyIDs on the PKIX list, shouldn't this be: S/MIME vAnything MUST NOT rely on the use of subjectKeyIdentifier in messages. Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RNNpI7080564 for ; Mon, 27 Oct 2003 15:23:51 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RNNpri080563 for ietf-smime-bks; Mon, 27 Oct 2003 15:23:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RNNoI7080558 for ; Mon, 27 Oct 2003 15:23:51 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Mon, 27 Oct 2003 15:23:47 -0800 From: "Blake Ramsdell" To: Subject: XMPP at IETF Date: Mon, 27 Oct 2003 15:23:47 -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.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is apparently a new permanent XMPP chat server set up, which should be available for every WG meeting going forward. Details are at: http://www.xmpp.org/ietf-chat.html The bottom line is that if someone steps forward and volunteers as a scribe at our meeting, people can participate remotely, and this service will be available until further notice. Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RMBII7077816 for ; Mon, 27 Oct 2003 14:11:18 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RMBIci077813 for ietf-smime-bks; Mon, 27 Oct 2003 14:11:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RMBCI7077797 for ; Mon, 27 Oct 2003 14:11:13 -0800 (PST) (envelope-from scoya@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19555; Mon, 27 Oct 2003 17:11:03 -0500 (EST) Message-Id: <200310272211.RAA19555@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-cms-rsa-kem-01.txt Date: Mon, 27 Oct 2003 17:11:02 -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 RSA-KEM Key Transport Algorithm in CMS Author(s) : B. Kaliski Filename : draft-ietf-smime-cms-rsa-kem-01.txt Pages : 20 Date : 2003-10-24 The RSA-KEM Key Transport Algorithm is a one-pass (store-and- forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-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-cms-rsa-kem-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-cms-rsa-kem-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-10-27171514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cms-rsa-kem-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cms-rsa-kem-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171514.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9REIrI7052156 for ; Mon, 27 Oct 2003 06:18:53 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9REIrlF052155 for ietf-smime-bks; Mon, 27 Oct 2003 06:18:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9REIqI7052150 for ; Mon, 27 Oct 2003 06:18:52 -0800 (PST) (envelope-from scoya@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14534; Mon, 27 Oct 2003 09:18:42 -0500 (EST) Message-Id: <200310271418.JAA14534@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-cms-rsa-kem-01.txt Date: Mon, 27 Oct 2003 09:18:41 -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 RSA-KEM Key Transport Algorithm in CMS Author(s) : B. Kaliski Filename : draft-ietf-smime-cms-rsa-kem-01.txt Pages : 20 Date : 2003-10-24 The RSA-KEM Key Transport Algorithm is a one-pass (store-and- forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. This document specifies the conventions for using the RSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax (CMS) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsa-kem-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-cms-rsa-kem-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-cms-rsa-kem-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-10-24161000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cms-rsa-kem-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cms-rsa-kem-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24161000.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R2OSI7051146 for ; Sun, 26 Oct 2003 18:24:28 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9R2OS6C051145 for ietf-smime-bks; Sun, 26 Oct 2003 18:24:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R2OSI7051125 for ; Sun, 26 Oct 2003 18:24:28 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Sun, 26 Oct 2003 18:24:25 -0800 From: "Blake Ramsdell" To: , Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-03 Date: Sun, 26 Oct 2003 18:24:25 -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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Blake Ramsdell [mailto:blake@brutesquadlabs.com] > Sent: Sunday, October 26, 2003 5:55 PM > To: 'jimsch@exmsft.com'; 'ietf-smime@imc.org' > Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-03 > > > 2. References need to be divided. > > Still missing what this means. Aha! You mean that there needs to be a normative and informative section. Got it. I'm apparently behind the times. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R1sgI7049369 for ; Sun, 26 Oct 2003 17:54:42 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9R1sgXc049368 for ietf-smime-bks; Sun, 26 Oct 2003 17:54:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R1sfI7049356 for ; Sun, 26 Oct 2003 17:54:41 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Sun, 26 Oct 2003 17:54:39 -0800 From: "Blake Ramsdell" To: , Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-03 Date: Sun, 26 Oct 2003 17:54:38 -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 In-Reply-To: <001d01c35155$4c558950$8b40a051@augustcellars.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Wednesday, July 23, 2003 1:02 PM > To: 'Blake Ramsdell'; ietf-smime@imc.org > Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2632bis-03 > > 1. Section 1.2: Does this need to be updated to refer to version 3.1 > agents as well? Updated: S/MIME version 3.1 agents should attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive and S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive. RFC 2311 also has historical information about the development of S/MIME. > 2. References need to be divided. Still missing what this means. > 3. Acknowlegements is [TBD] Updated: Many thanks go out to the other authors of the S/MIME v2 RFC: Steve Dusse, Paul Hoffman and Jeff Weinstein. Without v2, there wouldn't be a v3. A number of the members of the S/MIME Working Group have also worked very hard and contributed to this document. Any list of people is doomed to omission and for that I apologize. In alphabetical order, the following people stand out in my mind due to the fact that they made direct contributions to this document. Bill Flanigan Trevor Freeman Elliott Ginsburg Paul Hoffman Russ Housley David P. Kemp Michael Myers John Pawling Denis Pinkas Jim Schaad > 4. Section at beginning of document on changes since RFC2632 is > required. Added: 1.4 Changes Since S/MIME v3.0 Version 1 and Version 2 CRLs MUST be supported. Multiple CA certificates with the same subject and public key, but with overlapping validity periods MUST be supported. Version 2 attribute certificates SHOULD be supported, and version 1 attributes certificates MUST NOT be used. MD2 use for certificate signatures discouraged, and security language added. Clarified use of email address use in certificates. Certificates that do not contain an email address have no requirements for verifying the email address associated with the certificate. Receiving agents SHOULD display certificate information when displaying the results of signature verification. Receiving agents MUST NOT accept a signature made with a certificate that does not have the digitalSignature or nonRepudiation bit set. Clarifications for the interpretation of the key usage and extended key usage extensions. > 5. KEYMAC as a reference sent me to keyed macs, not to key management > for ACs. Are you saying that you were personally confused about the use of the reference term KEYMAC? Updated: Reference name changed from KEYMAC to ACAUTH. > 6. Section 4.4.2 - Key Usage is not a required extension. > What happens > in para #4 if the extension is not present. Does this imply that the > bits are set? I have no idea, since no one's really been able to explain the difference between these two bits anyway. Updated: If the key usage extension is not specified, receiving clients MUST presume that the digitalSignature and nonRepudiation bits are set. Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R1rlI7049319 for ; Sun, 26 Oct 2003 17:53:47 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9R1rl52049318 for ietf-smime-bks; Sun, 26 Oct 2003 17:53:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9R1rkI7049310 for ; Sun, 26 Oct 2003 17:53:46 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Sun, 26 Oct 2003 17:53:43 -0800 From: "Blake Ramsdell" To: "'Peter Gutmann'" , Cc: Subject: RE: Request change in son-of-rfc2633 Date: Sun, 26 Oct 2003 17:53:42 -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 In-Reply-To: <200309171321.h8HDLTM11854@cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Peter Gutmann > Sent: Wednesday, September 17, 2003 6:21 AM > To: jimsch@exmsft.com > Cc: ietf-smime@imc.org > Subject: Re: Request change in son-of-rfc2633 > > "Jim Schaad" writes: > > >Messages that use this choice cannot be read by S/MIME v2 > clients, but are > >not to cause crashes in S/MIME v3.1 clients." > > I'm having some trouble parsing this... does this mean the > RFC is specifying > that S/MIME clients aren't allowed to crash? How is this enforced? The language that has been added is as follows: S/MIME v3.1 implementations MUST allow for the use of the choice of subjectKeyIdentifier in messages. Messages that use this choice cannot be read by S/MIME v2 clients, and MUST be handled gracefully in S/MIME v3.1 clients. So I imagine that we're now chartered with enforcing them to be graceful vs. enforcing them to not crash ;). Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q9e4I7003421 for ; Sun, 26 Oct 2003 01:40:04 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9Q9e4vV003420 for ietf-smime-bks; Sun, 26 Oct 2003 01:40:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q9e2I7003378 for ; Sun, 26 Oct 2003 01:40:03 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Sun, 26 Oct 2003 01:39:57 -0800 From: "Blake Ramsdell" To: , Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04 Date: Sun, 26 Oct 2003 01:39:57 -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 In-Reply-To: <001a01c35155$48f4ab10$8b40a051@augustcellars.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-smime@mail.imc.org > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Jim Schaad > Sent: Wednesday, July 23, 2003 1:02 PM > To: 'Blake Ramsdell'; ietf-smime@imc.org > Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04 > > Comments are on the -05 version of the document. > > 1. Section 1.4 talks about version 3 not version 3.1 agents. Updated: S/MIME version 3.1 agents should attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive and S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive. RFC 2311 also has historical information about the development of S/MIME. > 2. Section 2.1: Given your request for manditory inclusion of hash > algorithms in DigestAlgorithmIdentifier, is there a reason you don't > make population here atleast a SHOULD if not a MUST? Well, if you're referring to my position on 5/5/03, I believe this field to be valueless, so it doesn't matter to me. Not changed unless there's some new information that I am missing. > 3. Section 2.2: There is no techincal reason that an S/MIME v2 client > cannot be augmented to verify an id-dsa-with-sha1 signature. This > statement should be that S/MIME v2 clients are only REQUIRED to > implement rsaEncryption with either SHA-1 or MD5. Updated: Also note that S/MIME v2 clients are only required to verify digital signatures using the rsaEncryption algorithm with SHA-1 or MD5, and may not implement id-dsa-with-sha1 at all. > 4. Section 2.2: The required hash algorithms supported with > rsaEncryption needs to be noded as part of this section. Updated: If using rsaEncryption, sending and receiving agents MUST support the algorithms in section 2.1 as specified. > 5. Section 2.3: Agents should support ES Diffie-Hellman. SS is not a > requirement. Updated: Sending and receiving agents SHOULD support Diffie-Hellman defined in [CMSALG], using the ephemeral-static mode. > 6. Section 2.4: CMS does not define the CompressedData content type > last time I checked. Updated: There are several CMS content types. Of these, only the Data, SignedData, EnvelopedData and CompressedData content types are currently used for S/MIME. > 7. Section 2.4.4: Is there a reason why there is not any text > describing when one should and when one should not compress > data? (i.e. > don't compress after encryption). Add reference to section 3.6? Updated: See section 3.6 for further guidance on the use of this type in conjunction with other CMS types. > 8. Section 2.5: The text "Sending agents SHOULD generate > one instance > of the signingCertificate > signed attribute in each S/MIME message." should state > "signed attribute > in each SignerInfo structure". Updated: Sending agents SHOULD generate one instance of the signingCertificate signed attribute in each SignerInfo structure. > 9. Section 2.5.2, para 4: I would like to have the following text > added. " > Because of the requirement for identical encoding, individuals > documenting algorithms to be used in the SMIMECapabilities attribute > should explicitly document the correct byte sequence for the common > cases." Updated: The structure of the SMIMECapabilities attribute is to facilitate simple table lookups and binary comparisons in order to determine matches. For instance, the DER-encoding for the SMIMECapability for DES EDE3 CBC MUST be identically encoded regardless of the implementation. Because of the requirement for identical encoding, individuals documenting algorithms to be used in the SMIMECapabilities attribute should explicitly document the correct byte sequence for the common cases. > 10. Section 2.5.2, para 5: I think we need to remove the "In the case > of symmetric algorithms," phrase from this paragraph. The need for > dealing with parameters can occur for other algorithms such > as OAEP, KEM > and PSS. It may be necessary to distinguish more explicitly between > algorithm parameters such as rounds and block size as oppose > to the IV. Updated: For any capability, the associated parameters for the OID MUST specify all of the parameters necessary to differentiate between two instances of the same algorithm. For instance, the number of rounds and block size for RC5 must be specified in addition to the key length. > 11. Section 2.5.2 - where do we document SMimeCapabilities for RC2? > Should be a 40-bit vs 128-bit difference between these which needs an > ASN.1 structure and encoding. Based on reading of this > document I could > not correctly encode these values. I believe that this definition should be in the CMSALG document (but it's not). Should we bite the bullet and just stick it in this one? I agree that it needs to be specified somewhere, but I feel a bit icky about sticking it in here. > 12. Section 2.5.3, last para: what happended to the clock skew text > for SMIMECapabiltlies that clarifies what this sentence refers to? -- > found it in section 2.7.1 - not immediately apparent should have some > type of reference in either 2.5.2 or 2.5.3 or both. Updated 2.5.2: Section 2.7.1 explains a strategy for caching capabilities. Updated 2.5.3: Section 2.7.1 explains a strategy for caching preference data. > 13. Section 2.7.1, para 2: Change reference to section 2.5.2 Updated. > 14. Section 2.7.1.2: Should we remove this paragraph? It does not > really follow from the fact that you recived a signed (by me) then > encrypted message that I was actually the party that enrypted the > message. It could have been an DOS attacker, a gateway, an MLA and so > forth. Removed. I agree -- there is no way to know if a message that comes in that has encryption applied after the signature has any relationship to the signer. > 15. Section 2.7.1.3: Need to be updated to comment on AES. I see your point. The intent is to fall back to something useful for any version of S/MIME, and the older evil US-only RC2/40 clients. It's not clear what discussion you'd have about AES here. It may be the case that this rule should be removed completely. Comments? Not changed, but needs discussion. > 16. Section 3.1, last para: I would like to see some additional > comments provided to help people make the decision between a message > that is protecting the headers and a message which is an attachment. Added: When an S/MIME message is received, if the top-level protected MIME entity has a Content-Type of message/rfc822, it can be assumed that the intent was to provide header protection. This entity should be presented as the top-level message, taking into account header merging issues as previously discussed. > 17. Section 3.1.2 para 3: Change the "SHOULD NOT use 7-bit" > to "SHOULD > use binary" to make a positive rather than a negative statement. This was discussed in private mail also, and I believe that the following is reasonable text to put in. Updated: S/MIME implementations which "know" that all intended recipient(s) are capable of handling inner (all but the outermost) binary MIME objects SHOULD use binary encoding as opposed to a 7-bit-safe transfer encoding for the inner entities. The use of a 7-bit-safe encoding (such as base64) would unnecessarily expand the message size. Implementations MAY "know" that recipient implementations are capable of handling inner binary MIME entities either by interpreting the id-cap-preferBinaryInside sMIMECapabilities attribute, by prior agreement, or by other means. > 18. Section 3.1, General: Do you need to canonicalize before you > compress? I'm gonna say "yes". Updated: Each MIME entity MUST be converted to a canonical form that is uniquely and unambiguously representable in the environment where the signature is created and the environment where the signature will be verified. MIME entities MUST be canonicalized for enveloping and compressing as well as signing. > 19. Section 3.2.1: Can we really justify limiting the file name to > eight characters any more? All common windows platforms no > longer have > this restriction. Apple and Unix platforms have not had this > restriction for a long time (if ever). It's a SHOULD, so if you really wanna have more, go for it. > 20. Section 3.2.2: I would like to get some rewrites on this section > as to the purpose of S/MIME type. I think it is JUST to provide > information about the information (misspelt in the document) about the > contained content. It just happens that for display via UAs, the > distinction between signed and enveloped was consisted to be an > important part of the content. Additionally, I think this is the > correct direction for us to tell people about how to define new > smime-types in the future. > > The next question is weither a compressed only message would > show up in > my mailbox. I think that the correct smime-type for a compressed and > signed message is actually signed-data not compressed data. So I think your position is that the smime-type should have the "most relevant interpretation of the protected data", instead of the "actual type that is being protected". I think the best example is an IMAP client getting the headers and changing the icon next to the message to indicate what kind of message you've got. We can ask the audience, but I think that the conventional wisdom is that the smime-type represents the type of the outermost layer, and that's it -- just a further clarification of the overloaded application/pkcs7-mime. Fixed speling of information, but I want to hear more about how else we should change this to clarify the semantic (and what the semantic is). > 21. Section 3.4.1, last para: Currently this reads > > Messages signed using the signedData format cannot be viewed by a > recipient unless they have S/MIME facilities. However, if they have > S/MIME facilities, these messages can always be verified if they were > not changed in transit. > > But duh for the last sentence. The correct statement would be. > "However, the signedData format protects the message content > from being > changed by benign intermediate agents. Such agents might do line > wrapping or content-transfer encoding changes which would break the > signature." Indeed, duh for the last sentence. Updated: Messages signed using the signedData format cannot be viewed by a recipient unless they have S/MIME facilities. However, the signedData format protects the message content from being changed by benign intermediate agents. Such agents might do line wrapping or content-transfer encoding changes which would break the signature. > 22. Section 3.4.3.2, algorithm table: The last item in the > table needs > to be removed. The corect answer is that this value needs to > be defined > by documents describing other hashing algorithms. Updated: Any other (defined separately in algorithm profile or "unknown" if not defined) > 23. Section 3.4.3.3: Just for giggles, I think that adding a section > with the hex encoding of the acutal bytes hashed for this sample would > be a good idea. This is one of the things people always have problems > with when doing multipart signed data. Also it might be > interesting to > make the body a multipart/alternative. On the other hand this would > probably be better in an appendix. I think that getting too far with the examples should be left to the Examples draft and any successors. I do agree that adding the hex dump would be a good idea. My attempt at the hex dump is this, but I need at least one other person to double check it. Updated: The content that is digested (the first part of the multipart/signed) are the bytes: 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a > 24. Section 4: Reference to [CERT3] needs updating. Updated to [CERT31]. > 25. Section 4.1: Language and protocol statements needs to be updated > in this section to reflect the change in algorithms. Updated. Complete section is now: 4.1 Key Pair Generation All generated key pairs MUST be generated from a good source of non- deterministic random input [RANDOM] and the private key MUST be protected in a secure fashion. If an S/MIME agent needs to generate an RSA key pair, then the S/MIME agent or some related administrative utility or function SHOULD generate RSA key pairs using the following guidelines. A user agent SHOULD generate RSA key pairs at a minimum key size of 768 bits. A user agent MUST NOT generate RSA key pairs less than 512 bits long. Creating keys longer than 1024 bits may cause some older S/MIME receiving agents to not be able to verify signatures, but gives better security and is therefore valuable. A receiving agent SHOULD be able to verify signatures with keys of any size over 512 bits. Some agents created in the United States have chosen to create 512 bit keys in order to get more advantageous export licenses. However, 512 bit keys are considered by many to be cryptographically insecure. Implementors should be aware that multiple (active) key pairs may be associated with a single individual. For example, one key pair may be used to support confidentiality, while a different key pair may be used for authentication. > 26. Appendix B: Refernces need to be divided. I'm not sure what you mean by "divided"... Blake Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9NBoaI7059959 for ; Thu, 23 Oct 2003 04:50:36 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9NBoata059958 for ietf-smime-bks; Thu, 23 Oct 2003 04:50:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9NBoZI7059953 for ; Thu, 23 Oct 2003 04:50:35 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 16536 invoked by uid 0); 23 Oct 2003 11:50:30 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.188.89) by woodstock.binhost.com with SMTP; 23 Oct 2003 11:50:30 -0000 Message-Id: <5.2.0.9.2.20031023074902.0461ee40@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 23 Oct 2003 07:50:33 -0400 To: "Blake Ramsdell" , From: Russ Housley Subject: Re: SEED algorithm Internet-Draft Cc: In-Reply-To: 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: Blake: There must be a normative reference to the algorithm itself. Without such a reference, implementors will not have all of the information needed to do their job. Russ At 02:10 AM 10/23/2003 -0700, Blake Ramsdell wrote: >An individual internet-draft has been submitted documenting the use of >the SEED encryption algorithm in CMS. We will be discussing this draft >at IETF 58, and if there are no objections, this draft will become a >draft of the working group. > >Title: Use of the SEED Encryption Algorithm in CMS > >Authors: Jongwook Park (KISA), Sungjae Lee (KISA), Jinsu Hyun (KISA), >Jaeil Lee (KISA) > >Abstract: This document specifies the conventions for using the SEED >encryption algorithm for encryption with the Cryptographic Message >Syntax (CMS). > >http://www.ietf.org/internet-drafts/draft-park-cms-seed-00.txt > >Blake >-- >Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N9KtI7053593 for ; Thu, 23 Oct 2003 02:20:55 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9N9KtJC053592 for ietf-smime-bks; Thu, 23 Oct 2003 02:20:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9N9KgI7053583 for ; Thu, 23 Oct 2003 02:20:42 -0700 (PDT) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Thu, 23 Oct 2003 02:10:06 -0700 From: "Blake Ramsdell" To: Cc: Subject: SEED algorithm Internet-Draft Date: Thu, 23 Oct 2003 02:10:06 -0700 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.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: An individual internet-draft has been submitted documenting the use of the SEED encryption algorithm in CMS. We will be discussing this draft at IETF 58, and if there are no objections, this draft will become a draft of the working group. Title: Use of the SEED Encryption Algorithm in CMS Authors: Jongwook Park (KISA), Sungjae Lee (KISA), Jinsu Hyun (KISA), Jaeil Lee (KISA) Abstract: This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS). http://www.ietf.org/internet-drafts/draft-park-cms-seed-00.txt Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKh6I7039495 for ; Tue, 21 Oct 2003 13:43:06 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LKh6lV039494 for ietf-smime-bks; Tue, 21 Oct 2003 13:43:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKh1I7039479 for ; Tue, 21 Oct 2003 13:43:02 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07654; Tue, 21 Oct 2003 16:42:52 -0400 (EDT) Message-Id: <200310212042.QAA07654@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-gost-00.txt Date: Tue, 21 Oct 2003 16:42:52 -0400 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 : Cryptographic Message Syntax (CMS) algorithms for GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94. Author(s) : S. Leontiev, et. al. Filename : draft-ietf-smime-gost-00.txt Pages : 26 Date : 2003-10-20 This document describes the conventions for using cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, along with Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication and encryption arbitrary message contents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-gost-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-gost-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-gost-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-10-21164257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-gost-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-gost-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21164257.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KJkUI7006297 for ; Mon, 20 Oct 2003 12:46:31 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9KJkUXM006296 for ietf-smime-bks; Mon, 20 Oct 2003 12:46:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9KJkTI7006291 for ; Mon, 20 Oct 2003 12:46:29 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22554; Mon, 20 Oct 2003 15:46:21 -0400 (EDT) Message-Id: <200310201946.PAA22554@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-examples-12.txt Date: Mon, 20 Oct 2003 15:46:21 -0400 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 : Examples of S/MIME Messages Author(s) : P. Hoffman Filename : draft-ietf-smime-examples-12.txt Pages : 8 Date : 2003-10-20 This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects, S/MIME messages (including the MIME formatting), and Enhanced Security Services for S/MIME (ESS). It includes examples of most or all common CMS and ESS formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-12.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-examples-12.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-examples-12.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-10-20151858.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-examples-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-examples-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-20151858.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFCgI7036009 for ; Mon, 13 Oct 2003 08:12:42 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9DFCgeM036008 for ietf-smime-bks; Mon, 13 Oct 2003 08:12:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9DFCfI7036002 for ; Mon, 13 Oct 2003 08:12:41 -0700 (PDT) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1A94Ly-00052L-Hk; Mon, 13 Oct 2003 11:11:22 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Subject: Protocol Action: 'Securing X.400 Content with S/MIME' to Proposed Standard Message-Id: Date: Mon, 13 Oct 2003 11:11:22 -0400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has approved following documents: - 'Securing X.400 Content with S/MIME ' as a Proposed Standard - 'Transporting S/MIME Objects in X.400 ' as a Proposed Standard These documents are products of the S/MIME Mail Security Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary These documents describe the use of the S/MIME security mechanisms in an X.400 messaging environment. "Securing X.400 Content with S/MIME" describes the use of the Cryptographic Message Syntax (CMS) to digital signature and encryption services to X.400 content. "Transporting S/MIME Objects in X.400" describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. Working Group Summary The S/MIME Working Group came to consensus on these documents. Protocol Quality These documents were reviewed by Jeff Schiller and Russell Housley for the IESG.