From subs-reminder@imc.org Tue Dec 3 01:09:23 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28669 for ; Tue, 3 Dec 2002 01:09:23 -0500 (EST) From: subs-reminder@imc.org Received: (from phoffman@localhost) by above.proper.com (8.11.6/8.11.3) id gB36C5T12427; Mon, 2 Dec 2002 22:12:05 -0800 (PST) Date: Mon, 2 Dec 2002 22:12:05 -0800 (PST) Message-Id: <200212030612.gB36C5T12427@above.proper.com> To: smime-archive@ietf.org Subject: [[747473882]] 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. 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 Wed Dec 4 07:59:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08542 for ; Wed, 4 Dec 2002 07:59:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4CdWq17901 for ietf-smime-bks; Wed, 4 Dec 2002 04:39:32 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4CdTg17895 for ; Wed, 4 Dec 2002 04:39:30 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07942; Wed, 4 Dec 2002 07:36:39 -0500 (EST) Message-Id: <200212041236.HAA07942@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-rsaes-oaep-07.txt Date: Wed, 04 Dec 2002 07:36:38 -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 RSAES-OAEP Transport Algorithm in CMS Author(s) : R. Housley Filename : draft-ietf-smime-cms-rsaes-oaep-07.txt Pages : 15 Date : 2002-12-3 This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-07.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-rsaes-oaep-07.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-rsaes-oaep-07.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: <2002-12-3142449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cms-rsaes-oaep-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-3142449.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Wed Dec 4 15:10:15 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01736 for ; Wed, 4 Dec 2002 15:10:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4Jf7D19319 for ietf-smime-bks; Wed, 4 Dec 2002 11:41:07 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gB4Jedg19314 for ; Wed, 4 Dec 2002 11:40:39 -0800 (PST) Received: (qmail 28323 invoked from network); 4 Dec 2002 19:40:32 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (208.208.101.17) by woodstock.binhost.com with SMTP; 4 Dec 2002 19:40:32 -0000 Message-Id: <5.2.0.9.2.20021204143717.028cb460@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 04 Dec 2002 14:40:08 -0500 To: "Dieter Bratko" , From: Russ Housley Subject: Re: SignedReceipt In-Reply-To: <032e01c296ef$38b150d0$58981b81@iaik.at> References: <5.2.0.9.2.20021126133201.02961940@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: "Dieter: It simply needs to be a unique identifier of the signed content. This allows the originator of the original message to locate the message when the receipt arrives. Russ At 04:02 PM 11/28/2002 +0100, Dieter Bratko wrote: >Hello, > >Implementing the ESS Signed Receipt service I would like to tell the >following question regarding the role of the message originator: >According to RFC2634 the signedContentIdentifier field should contain >user-specific identification information (such as a user name or public >keying material identification information). When creating a receipt the >signedContentIdentifier is copied from the receiptRequest to the receipt: > >Receipt ::= SEQUENCE { > version ESSVersion, > contentType ContentType, > signedContentIdentifier ContentIdentifier, > originatorSignatureValue OCTET STRING } > > > >Is my interpretation right that the user-specific identification information >implicitly contained in the signedContentIdentifier -- since it has to be >the same for any receiptRequest attribute of any SignerInfo containing a >receiptRequest attribute -- refers to the (one and only) message originator >(sender), but the originatorSignatureValue field holds the signature value >from the SignerInfo just processed (which not necessarily has to be the >signerInfo of the originator); and when creating the receipt it does not >mind which SignerInfo it is based on (the validator must be able to validate >receipts based on any SignerInfo contained in the original SignedData)? > >Regards, >Dieter Bratko > >--------- >Dieter Bratko, >Institute for Applied Information Processing and Communications (IAIK) >Graz University of Technology, Inffeldgasse 16a, 8010 Graz, Austria, >http://jce.iaik.tugraz.at/ From owner-ietf-smime@mail.imc.org Thu Dec 5 16:06:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00263 for ; Thu, 5 Dec 2002 16:06:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB5KiUj01995 for ietf-smime-bks; Thu, 5 Dec 2002 12:44:30 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5KiSg01983 for ; Thu, 5 Dec 2002 12:44:28 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27496; Thu, 5 Dec 2002 15:41:38 -0500 (EST) Message-Id: <200212052041.PAA27496@ietf.org> To: IETF-Announce: ; Cc: ietf-smime@imc.org From: The IESG SUBJECT: Last Call: Use of the RSAES-OAEP Transport Algorithm in CMS to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 05 Dec 2002 15:41:38 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security Working Group to consider Use of the RSAES-OAEP Transport Algorithm in CMS as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-12-19. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-07.txt From owner-ietf-smime@mail.imc.org Fri Dec 6 16:17:01 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24760 for ; Fri, 6 Dec 2002 16:17:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6L0tG28685 for ietf-smime-bks; Fri, 6 Dec 2002 13:00:55 -0800 (PST) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6L0ng28661 for ; Fri, 6 Dec 2002 13:00:49 -0800 (PST) Received: from revelation (12-230-156-246.client.attbi.com[12.230.156.246]) by rwcrmhc52.attbi.com (rwcrmhc52) with SMTP id <20021206210045052001ajs1e>; Fri, 6 Dec 2002 21:00:45 +0000 Reply-To: From: "Jim Schaad" To: Subject: Draft Minutes Date: Fri, 6 Dec 2002 13:00:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_01C29D27.72F09510" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MS-TNEF-Correlator: 00000000C61F957EEEE3D311963C000086335A64E42A2900 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_0014_01C29D27.72F09510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are the minutes for the working group meeting in Atlanta. Minutes for the S/MIME Meeting IETF 55 November 19, 2002 Agenda: Russ Housley covered the agenda for the meeting. No changes = were made. Working Group Status: Russ Housley covered the status of the active documents in the working group. The documents that have changed status since the last meeting are: Published as an RFC: - RFC 3369 - Cryptographic Message Syntax - RFC 3370 - Cryptographic Message Syntax (CMS) Algorithms - RFC 3394 - Advanced Encryption Standard (AES) Key Wrap Algorithm RFC Editors Queue: - There are currently no documents in the RFC Editor Queue IESG - CMS Symmetric Key Management and Distribution - Use of the RSAES-OAEP Transport Algorithm in CMS - Transporting S/MIME Objects in X.400 - Securing X.400 Content with S/MIME - Wrapping an HMAC key with a Triple-DES Key or an AES Key Examples Draft: Paul Hoffman was unable to be present so Russ presented = for him. There has been a recent discussion on the list that a triple-wrap example as defined in ESS (RFC 2634) should be added to the draft. John Pawling has volunteered to provide this example. After it is = incorporated the document, and a few minor edits are made, the Examples Draft should = be ready for working group last call. X400 Transport and Wrap Drafts: Chris Bonatti gave the presentation for these two drafts. There were some comments from the IESG on the = documents, and some synchronization between the RFC2633bis Draft and X.400 Wrap = Draft was needed. The IESG comments have been resolved, and the two S/MIME working documents are now consistent. The X.400 Transport and Wrap = Drafts are ready for the IESG. Chris is trying to coordinate a review of the documents by the ITU-T group responsible for X.400, but this should not = stop the draft from going to Proposed Standard. Any comments from this group = can be incorporated before going to Draft Standard. AES Algorithm Draft: Jim Schaad stated that the document has been = modified to remove the requirement that AES is not to be used with PKCS #1 v1.5. = The document will be submitted as soon as the repository opens, and then the chair will make the working group last call. CMS Interoperability Status: Jim Schaad stated that advancement has = been made since the last meeting for CMS interoperability. There are 6 test cases left to complete interoperability testing. These test cases deal with: 1) v2 attribute certificates for SignedData and EnvelopedData; 2) unrecognized SignerInfo structures; 3) unrecognized RecipientInfo structures; and 4) version numbering in EnvelopedData for pwri and/or = ori being present as a RecipientInfo. The v2 attribute certificate test = cases should be finished soon as a bug is found and fixed in one = implementation. There was a discussion dealing with two issues found during = interoperability testing. The first dealt with the fact that so far no implementations = are known that deal gracefully with unknown RecipientInfo and SignerInfo structures. No discussion was generated from the floor. The second = issue dealt with the fact that there is no MUST statement on handling of = detached as opposed to embedded content. Both detached content and embedded = content are mandated by the S/MIME message specification (RFC 2633) for = SignedData, and embedded content is mandated for EncryptedData. Should this be = moved into the CMS draft as well? No discussion from the floor ensued. Camellia Draft: KATO Akihiro gave the presentation on the draft for = Camellia to be used as a content encryption algorithm with CMS. Camellia = operations at the same block and key sizes as AES. Camellia will use the AES key = wrap algorithm for doing key encryption. The authors are going to be adding = a section on SMIMECapabilities before the next revision. Information on Camellia can be gotten at http//info.isl.ntt.co.jp/camellia. Message Update Draft: Blake Ramsdell was unable to make it to the = meeting. Russ presented Blake's slides for him. The current draft was modified = to deal with allowing for binary transport internally, signing message = headers and using the compression content type. Following the presentation the chair stated that the document should be ready to progress and a last = call will be issued shortly. Certificate Update Draft: Russ also presented the certificate draft = updates for Blake. The changes in the last draft are changes to the wording for email address matching and to deal with the = nonRepudiation/digitalSignature bits in the key usage certificate extension. There are still some additional changes are needed to resolve previously submitted comments. Also, there are some TBA areas in the draft. IESG status of HMAC Key Wrap draft: Jeff Schiller was asked to give = further information about the current status of the HMAC Key Wrap draft which is currently stuck at the IESG. The issue has to do with the fact that the working group requested publication as an Informational RFC, which for advancement purposes is really below Proposed Standard for purposes of advancement. Thus any document that relied on it could not go forward. Russ said that this has been historically what has been done by this = working group; document describing algorithms are informational, while documents describing how to use the algorithms are standards track. Jeff is going = to attempt to get the problem solved on a basic level, however the working group granted permission to move the document to standards track if it appears that solving the basic problem is going to take too long. ------=_NextPart_000_0014_01C29D27.72F09510 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhsVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGAAcAAQAAAAAAAAEGgAMADgAAANIHDAAG AA0AAAAAAAUA/QABA5AGAMwPAAApAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAAC ATEAAQAAABgAAAAAAAAAxh+Vfu7j0xGWPAAAhjNaZKQqKQADADYAAAAAAB4AcAABAAAADgAAAERy YWZ0IE1pbnV0ZXMAAAACAXEAAQAAABYAAAABwp1qaMJEWvHL41FBGJRAFfeeEKuVAAACAR0MAQAA ABcAAABTTVRQOkpJTVNDSEBOV0xJTksuQ09NAAALAAEOAAAAAEAABg4ASIpwap3CAQIBCg4BAAAA GAAAAAAAAADGH5V+7uPTEZY8AACGM1pkwoAAAAMAFA4AAAAACwAfDgEAAAACAQkQAQAAAMwLAADI CwAAqBcAAExaRnWe+rReAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/ CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAz CwkBZDM2FlALpiBImQSQZSAKwB0gdGgdIPptC4B1DrAEIAIQBcAdgsp3BbBrC4BnIAnACGB2cB2w CeB0HwILgBDAdHMLYAIwYS4KogqEIRZNgR3dUy9NSU1FBdCDH7Qg1ElFVEYgGmBhINROb3ZlBtAS gTFoOSwgAdAwDlAg6UFCZwnwZGE6IAfwdQUEEUgIYHNsZXkg7wWgJSAYIR1zYSbjHjcfpX4uJ0Al ACggE+AfEAeRd68dAgDAAQAgy1ce1UcfU7pTAZB0J3AnPyhJcy2DaCBvZiikYx/QJSAg8GRvY3UH gAIwBCAgIXsejypRVB2RMOgdgC2QID8T4DCxKrQokC+VAJBuY18dZAtgL5Aflx1BOiDaUP51AmAE AB2QKJA2EB0wA6AoUkZDNwUtOMIgM4kcIDkgOXBDcnkFMOJvCcBhcGgN4CNRBBDXKPEUUSCReDkc NxZQOi9ROzsgKEMF4CkQwGxKZwWwaR2AbXM5HDniND0BQWR2AHA1kCiQ9kU1gD1CaQIgLWInAQsg qT7wQUU/MUsoAVc9oec/WCDaOZJFZD+wBbAEIH5RClAKUDkHMvEdFTEAcusYIAIwbCgQbiqQMO9F SOdF9CDaJDBTRzkWPxEUUt0HgHQFEDsAQ2JNAHAo8bcxIjiRKJBEBABMcWId8JtCMTkWVRQQL/ZS U0MRdC1PQxBQMuA9oACAcP8XwT9YIBI/EUZnUKYfAiL1GE9iagWQMVRYLjT/JeA5FgZgR4EfAlSj EiECML9NcgPwHYAi5TkWQ6JwNpPRA6BITUE5sGsoAVbjzylAUJAFICfwLURDIENTHwWxA5FDEUNS INpFeGF2bVoBBCBEPaABgC3RULxhdQMgLlABIAOCdzhxPnVNIAJgHWEqkCVQIHD3GCAUEE2BcyqQ LgNfRSiB+x5CPdBtMsQdERPgBCAlUP8J8FmhGCA1kE2BRZAE8C4R/0IyQkE1w04BM8QpQExxWgL+ d0OyDsBcczhiAQELgCiBFyAhQyAF8Cg5kjI2M+40P0A4IAhgbCiQXxErkG8BACiRKpAdgmRc8ipR SuxvaAOgXWB3OAAfEWHi/nYG8F5wDrAoZCqQX0AlEL5pAQAdcQQAZZYqUUEBgP8SgT+wIBAxYgWh UOEtkCiF/0hWJbBNsilBB9EdwQWxCYD/P7A4gStVJbAdglxcZ+kYIF8rkCgQHkIezDYDYwdAbP0g y1hWIlCYTbJDo1zjLcLsQ2gFEAQgQgIgLZAf0P8fMDQyHYJfRS2QQjIeRU9B9nQewGlUc2FXKzNf wAeA/yghTEExQgNSHXNLImOmSFd7b6R843M7sBPQA2ADAHo/emQlUHtgYjJJJWeRM2L/bIFylE2y VgR3qF4jZpAJgP8JgDLFflN9NzQjYiNfUQbw/SUgZG+kHYJ7YiL1HsZIWP8dQkggB+AFoACBL5Ax MTLF/1YEds931h0zc5h+FipReIT7bIFMcHkfAl7hBaAFsEWQf3kBHSFigWwQB9EwBUhYYsMoEH4T VFUtVB81X1H/UOAAgV6iHkJUoyWwTlFsVP9n9UggX6E9cB+AaSd9tD+A/Y/VUANgUOAUECiQQnZt Iv5uKBJ9XGyBH0R1YIEybgz/JVAeQR0gl7dylJjXJhtaUftROFzmSgdwBgAT0SuQL4P/KIMz8W7q YdgEYQaQCJBo048YIARgeYUYIHF1aaQx/01yM9NbImyBljJe5C4QKIGRVuNQS0MF8CMxauB4MS41 Ms1W0XWAXwJz/zfgHcACQDhEX8BCQThxpKT3mHFFolqhcAnwf5UdgTGU/xPRpSCpVADAWSAxr3T/ ISX9S+JJVoGYUQSQAaADED+w/ygQLXegr2RlQUSinSuRNV9/H7UeQkviC4CxTGFXHUI2/x1wB5Cv shQQBCAn8HLBkBP/XIKQwbfOuaMqJDLxezK5yK8BAAdAVtMt0DE/QHYUQP95EU4zNFEEkB/QZnCv 0B4G6FNpZ2aRRC2QKUBNst9BwCUgF7CsMMFDOyXAP0C/XnBikT2AgMGYosECcrEgewIQL4FyGtAt oF9RwrAz/cLtUgWQBSAIkAIwxD9Nsv9nwShRY2Md4CVCH+XB6x4z7nBlUHlAQpEvBbE/kV8B/x8C X0Y4csY8MsW/H8Aluar/Z/hmcTgUqrYpQE5QIAEeIu9ecDhRTcFmcHhmpAIgm6H/XIIxInpjIMt8 NcyjYwm+Mr8fAlbje2IEAQpQ0pZkVaT/u3+8i9EBFABi4b5BVsUdgv5mMHEzxF/B3NAFwEgh1Cz9 cQRrijExkjPxvjM9kbYA/mZdgEfxVuNecN9UxkxNsv/D38TiKlRjCV4yJuGxkWCj/X3WZhewBbAy xRQQinFmsX/YYtvf3OcdgR0RpjMF0FW+U5NAoVNNY0JBKsFkamP/MAEBAAGQE9A4RJaQmHRe4f8l MmijinGK1XjgVwHsh+6F/02j7f5xFScBnFOSpCL1B4H/O1NQ0MZRwDNCMmdGxUHAvP9vpPDPbIHy Fx5CQcXBNCpR/lNoBGxjXxGkUmayaPVL4u+XBDhxKzB1gD/kXuY8ZZD3AIAKUJ5sQ1xw/KEHMFzW 8EtBVE8QwB7wPdADYP95X3pkfqaXFLdSABamqcyj//AGCfBB59dgUVanUz8RjuL/ABaxc961ofQ7 UH0BF/Aw8P5rTaNZIpQgw5DMsRCxQyD/CCqpY6cBHXNbIlkjQ7IHCP+3QkhQHwJZIgZYMsVdcKdw f0XCuVKXt2hkNpPncgLmU/8jEgAAGxCxw5FAYgKcsx2CfWaQeGSgkRJjYipRxtJy/7WAAuYAB5tV P4CqMWJRNAHxqjBwLy+QkM2h5/B1kOcgkGmgm+Auahkwr9AAJLMgyzsmVXDyQlzXQiBw9a4xUlxw c2ZQqYFePK4T322xaPUp6F/9HVMnNUE4AP9mUMCUYSdHdpb11jKjer43/wbxwiCnULcVgoBNIKvx THD/ULa3w00g4MFvoJQgw2EyQf/zhhVAK5ERMk3BLhCP060yf7rxX1FjY/AGsgD0EORBRv9rACYV Ai+tKKFfomZy/mu0/5rwOzFvta+HqVfn83/hERH/R+GwHM8ZHG0gs9dgX8FgSP+tI88ZlwSTkPJC wJQdUyMG/+vB5ZBI16+D/AVHUjtVaPX/rqESg7dCTVCtgKmQaJEx838WwezAWGQlDRUz9LDGQHDW dUWQemMvRZBnFGDXYP/A8rJRR1GCgEjIWSIgwBwi/88KFYGsQRBHuSW8oamBfOP/EmL0kr5RO0aJ 84TDo/SHI/9fMmwQk4AiIAsRqfd9Nm0ijzeBcaNGpnzyVEJBEVL/C5FD5Wlk1Rp+Uy7yIMCRct9Y 01qCg8NpYx0gSmZgkZDvswGpcW2B1jNzWSBo00Kg/wHx4KDPIGGRZsEWmLGwk4D/ofQjdlAoFTJQ z4RCItDswP9t0iN1StKyYAqCofSOpdtC/+f0YeIlIrrA6L+h9K6spOL/ucEhcUHglED0ZsyiYlAW ef++UfTxb6BYlLdCtDpB4G5R/7oibIGNweDCaGAmEZg/+IT/YueRgbQ52xNQYYwAshCiV//dI6Uw FFAhcfSxbbGb4JX2/xhgerLWMJkzILMcECJAL1b/0oG095qxq9E10eDD3TK09/9/ENPxkpPSga6r wrCiVyJR//kAlDASk5+WSNRUmddgYWP/HsGJWHD5ERCKUATRDQZxre8u8ZkDj4LgcGvkQVITmsJ/ l8bOYbSQ+TBTg+yQLTVv/5RBffCHJH6S0iELkDXQulH/wgH2cHUxfCGORK6s4FEhU/+xgaoQ5PQe 8qRmaAjEYnc7/8lgeGG0Ee1QKaAp4d0lh0D/KnZ7tHp2eIrsoK4y0bC2YC/0sCBw1Rqe5H2HcAMA khADAAAAAgEUOgEAAAAQAAAAtkHF2RbBXkKhaMYtTWXXhgMA3j+fTgAAAwAJWQEAAAADAEBlAAAA AAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAA UoUAAOOQAQAeAASACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAAxMC4wAAAAAAsABYAI IAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwAGgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAA AAALAAeACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAsACIAIIAYAAAAAAMAAAAAAAABGAAAA AA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALABaACCAGAAAAAADAAAAA AAAARgAAAACChQAAAQAAAAIB+A8BAAAAEAAAAMYflX7u49MRljwAAIYzWmQCAfoPAQAAABAAAADG H5V+7uPTEZY8AACGM1pkAgH7DwEAAABJAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRs bAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxtYWlsXGN1cnJlbnQucHN0AAAAAAMA/g8FAAAAAwAN NP03AgACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAwMDBDNjFG OTU3RUVFRTNEMzExOTYzQzAwMDA4NjMzNUE2NEU0MkEyOTAwAAAAAAMABhAdZhdnAwAHENARAAAD ABAQAAAAAAMAERABAAAAHgAIEAEAAABlAAAASEVSRUFSRVRIRU1JTlVURVNGT1JUSEVXT1JLSU5H R1JPVVBNRUVUSU5HSU5BVExBTlRBTUlOVVRFU0ZPUlRIRVMvTUlNRU1FRVRJTkdJRVRGNTVOT1ZF TUJFUjE5LDIwMDJBRwAAAAC4fw== ------=_NextPart_000_0014_01C29D27.72F09510-- From owner-ietf-smime@mail.imc.org Fri Dec 6 17:15:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27283 for ; Fri, 6 Dec 2002 17:15:47 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6LwdJ04081 for ietf-smime-bks; Fri, 6 Dec 2002 13:58:39 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gB6LwZg04076 for ; Fri, 6 Dec 2002 13:58:36 -0800 (PST) Received: (qmail 19844 invoked from network); 6 Dec 2002 21:58:26 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.181.81) by woodstock.binhost.com with SMTP; 6 Dec 2002 21:58:26 -0000 Message-Id: <5.2.0.9.2.20021206165539.00b2e9d0@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Dec 2002 16:58:16 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Re: Draft Minutes 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: If anyone has comments on the minutes that were posted by Jim Schaad, please send a message to the list by Tuesday, 10 December. The Minutes are due to the IETF Secretariat soon. Thanks, Russ From owner-ietf-smime@mail.imc.org Sun Dec 8 23:09:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16733 for ; Sun, 8 Dec 2002 23:09:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB93gfo10297 for ietf-smime-bks; Sun, 8 Dec 2002 19:42:41 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB93gcg10291 for ; Sun, 8 Dec 2002 19:42:38 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gB93gZxI031950 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 9 Dec 2002 16:42:36 +1300 Date: Mon, 9 Dec 2002 16:42:36 +1300 (NZDT) From: Peter Gutmann To: jimsch@nwlink.com, Subject: Re: Draft Minutes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Apologies if you've seen this before, one of our machines has been quietly dropping outgoing mail...] "Jim Schaad" writes: >There was a discussion dealing with two issues found during interoperability >testing. The first dealt with the fact that so far no implementations are >known that deal gracefully with unknown RecipientInfo and SignerInfo >structures. What's the definition of "deal gracefully"? When this was discussed quite some time ago, I modified my code to ignore new structures that it didn't recognise, and I thought there were indications from others that they would be doing the same. Is that sufficient? Peter. From owner-ietf-smime@mail.imc.org Sun Dec 8 23:10:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16769 for ; Sun, 8 Dec 2002 23:10:52 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB942EY10934 for ietf-smime-bks; Sun, 8 Dec 2002 20:02:14 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB942Cg10930 for ; Sun, 8 Dec 2002 20:02:12 -0800 (PST) Received: from revelation (12-230-156-246.client.attbi.com[12.230.156.246]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <2002120904015400200fh2jke>; Mon, 9 Dec 2002 04:01:54 +0000 Reply-To: From: "Jim Schaad" To: "'Peter Gutmann'" , Subject: RE: Draft Minutes Date: Sun, 8 Dec 2002 20:01:30 -0800 Message-ID: <001101c29f37$a8b929c0$0e00a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter, Yes, I would consider that to be sufficent. I have not read your code dealing with this issue. Many of the versions I know about do a full decode of the structure and would fail decode if new structures were added. jim > -----Original Message----- > From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] > Sent: Sunday, December 08, 2002 7:43 PM > To: jimsch@nwlink.com; ietf-smime@imc.org > Subject: Re: Draft Minutes > > > [Apologies if you've seen this before, one of our machines > has been quietly > dropping outgoing mail...] > > "Jim Schaad" writes: > > >There was a discussion dealing with two issues found during > interoperability > >testing. The first dealt with the fact that so far no > implementations are > >known that deal gracefully with unknown RecipientInfo and SignerInfo > >structures. > > What's the definition of "deal gracefully"? When this was > discussed quite > some time ago, I modified my code to ignore new structures > that it didn't > recognise, and I thought there were indications from others > that they would be > doing the same. Is that sufficient? > > Peter. > > From owner-ietf-smime@mail.imc.org Fri Dec 13 22:20:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14684 for ; Fri, 13 Dec 2002 22:20:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBE35jD06825 for ietf-smime-bks; Fri, 13 Dec 2002 19:05:45 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBE2jJE05349; Fri, 13 Dec 2002 18:45:20 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gBE2jGbT018183; Sat, 14 Dec 2002 15:45:16 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id gBE2jGc07400; Sat, 14 Dec 2002 15:45:16 +1300 Date: Sat, 14 Dec 2002 15:45:16 +1300 Message-Id: <200212140245.gBE2jGc07400@medusa01.cs.auckland.ac.nz> From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: anders.rundgren@telia.com, ietf-pkix@imc.org Subject: Re: e-Government uses "Authority-stamp-signatures" Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [CC'd across to ietf-smime] "Anders Rundgren" writes: >It may be interesting to know that Swedish authorities are currently >launching a Web Services-like system called SHS, where authorities >communicate with each other through web-server "nodes" where out-going >messages are automatically signed by the authority identified as an "entity" >(organization), rather by an individual associated to the authority. Does this follow a particular model like DOMSEC, or is it yet another roll- your-own? There appear to be a number of groups doing DOMSEC-like things, but everyone's doing it differently... Peter. From owner-ietf-smime@mail.imc.org Sat Dec 14 12:30:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05862 for ; Sat, 14 Dec 2002 12:30:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBEHDBI09306 for ietf-smime-bks; Sat, 14 Dec 2002 09:13:11 -0800 (PST) Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBEHD8E09297; Sat, 14 Dec 2002 09:13:08 -0800 (PST) Received: from arport (h140n2fls31o1122.telia.com [212.181.142.140]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id gBEHCxC3008323; Sat, 14 Dec 2002 18:12:59 +0100 (CET) X-Original-Recipient: ietf-smime@imc.org Message-ID: <003301c2a392$e4d37050$0500a8c0@arport> From: "Anders Rundgren" To: "Peter Gutmann" , Cc: References: <200212140245.gBE2jGc07400@medusa01.cs.auckland.ac.nz> Subject: Re: e-Government uses "Authority-stamp-signatures" Date: Sat, 14 Dec 2002 18:04:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter, Late-breaking news received off-list! Apparently the Estonian (http://www.cyber.ee/infosecurity/projects/xroad-pilt.html ) and Italian e-Governments are also working along similar lines as their Swedish counterpart. Everybody seems wanting to get credit for being a part of the paradigm-shift! Who's next? :-) now to the technicalities.... As you probably have noted, technologies for server-based secure messaging are currently in a state of extreme flux, so all efforts are likely to be more or less "home-brewed". Or built on s.c. "standards" that are obsoleted a year or two after being intro- duced which is about the same thing. :-( I believe that DOMSEC has unfortunately already met its maker. Even SMTP and S/MIME will diminish in importance due to the "Web Services" craze. The practically "frictionless" [transport] encryption offered by HTTPS as well as the support for synchronous operation are absolutely crucial in many scenarios. SMTP will in the O2O context probably be "degraded" to a user-notification- tool for otherwise Web Services-based messaging and work-flow. Long-term all these systems will probably (hopefully?) converge into "true" Web Services using WS-Security and XML Signatures. cheers Anders R ----- Original Message ----- From: "Peter Gutmann" To: ; Cc: Sent: Saturday, December 14, 2002 03:45 Subject: Re: e-Government uses "Authority-stamp-signatures" [CC'd across to ietf-smime] "Anders Rundgren" writes: >It may be interesting to know that Swedish authorities are currently >launching a Web Services-like system called SHS, where authorities >communicate with each other through web-server "nodes" where out-going >messages are automatically signed by the authority identified as an "entity" >(organization), rather by an individual associated to the authority. Does this follow a particular model like DOMSEC, or is it yet another roll- your-own? There appear to be a number of groups doing DOMSEC-like things, but everyone's doing it differently... Peter. From owner-ietf-smime@mail.imc.org Tue Dec 17 00:04:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26465 for ; Tue, 17 Dec 2002 00:04:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBH4k2N27731 for ietf-smime-bks; Mon, 16 Dec 2002 20:46:02 -0800 (PST) Received: from mail1.ics.ntts.co.jp (mail1.ics.ntts.co.jp [202.32.24.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBH4k1o27726 for ; Mon, 16 Dec 2002 20:46:01 -0800 (PST) Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3/3.7W-NTTSOFT-SUR2.0) id NAA16090 for ; Tue, 17 Dec 2002 13:46:00 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Received: from helene.mc.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.6/3.7W-silk-4.6) id gBH4jxW24960; Tue, 17 Dec 2002 13:45:59 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Received: from [10.7.120.83] ([10.7.120.83]) by helene.mc.ntts.co.jp (8.12.5/8.12.5) with ESMTP id gBH4jwQ7085941; Tue, 17 Dec 2002 13:45:58 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Date: Tue, 17 Dec 2002 13:45:58 +0900 From: KATO Akihiro To: ietf-smime@imc.org Subject: Re: Comments on draft-ietf-smime-camellia Cc: akato@po.ntts.co.jp In-Reply-To: <000a01c290c6$05c2ebe0$3a482acc@soaringhawk.net> References: <000a01c290c6$05c2ebe0$3a482acc@soaringhawk.net> Message-Id: <20021217134533.5013.AKATO@po.ntts.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Jim On Wed, 20 Nov 2002 13:51:19 -0500 "Jim Schaad" wrote: snip > 7. Section 2.2: I strongly suggest that you change the parameters for > the key wrap algorithm OIDs to be ABSENT rather than NULL. How is ABSENT that you say the meaning that says? We are using the word called NULL is 'the parameter does not exist,but parameter field exist'. I think that this one is good. It is because it becomes clear that the parameter does not exist. On the other hand, there is the possibility that is interpreted that default is used, if place itself that designates the parameter is absent. Regards. -- - KATO Akihiro + NTT Software Corporation + Internet Technology Laboratory From owner-ietf-smime@mail.imc.org Tue Dec 17 21:47:26 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00246 for ; Tue, 17 Dec 2002 21:47:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBI2djp06000 for ietf-smime-bks; Tue, 17 Dec 2002 18:39:45 -0800 (PST) Received: from imc.org ([210.21.34.191]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBI2dOo05987 for ; Tue, 17 Dec 2002 18:39:42 -0800 (PST) Message-Id: <200212180239.gBI2dOo05987@above.proper.com> From: x0152@sina.com.cn Subject: =?GB2312?B?zOG5qc34wufJ48/xu/o=?= To: ietf-smime@imc.org Content-Type: text/plain;charset="GB2312" Reply-To: housley@vigilsec.com Date: Wed, 18 Dec 2002 10:43:15 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ---- No: 6381 你好 我们是深圳香归电子有限公司 我们提供网络摄像机及监控系统的安装调试 网络摄像机作为下一代商业应用程序的超级平台，它都为 Web 专业人士提供了前所未有的功能。 为管理企业应用程序提供了运行时间环境和图示管理工具。 如有需要请与广州办事处联系　 电话：020－82349026 赵巧辉 公司网址www.xianggui.com 邮件：zhaoqiaohui@xgjk.sina.com.cn From owner-ietf-smime@mail.imc.org Wed Dec 18 08:17:54 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05260 for ; Wed, 18 Dec 2002 08:17:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBID79f26318 for ietf-smime-bks; Wed, 18 Dec 2002 05:07:09 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBID78o26306 for ; Wed, 18 Dec 2002 05:07:08 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04590; Wed, 18 Dec 2002 08:04:08 -0500 (EST) Message-Id: <200212181304.IAA04590@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-symkeydist-08.txt Date: Wed, 18 Dec 2002 08:04:08 -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 : CMS Symmetric Key Management and Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-08.txt Pages : 81 Date : 2002-12-16 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-08.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-symkeydist-08.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-symkeydist-08.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: <2002-12-16123649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-16123649.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Wed Dec 18 09:30:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09270 for ; Wed, 18 Dec 2002 09:30:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBIEFfV09172 for ietf-smime-bks; Wed, 18 Dec 2002 06:15:41 -0800 (PST) Received: from jupiter.jmi.co.kr ([211.45.79.102]) by above.proper.com (8.11.6/8.11.3) with SMTP id gBIEFbo09165 for ; Wed, 18 Dec 2002 06:15:40 -0800 (PST) Received: (qmail 3707 invoked by uid 525); 18 Dec 2002 23:16:29 +0900 Received: (qmail 3681 invoked from network); 18 Dec 2002 23:15:35 +0900 Received: from unknown (HELO polo.jmi.co.kr) (211.45.79.31) by 0 with SMTP; 18 Dec 2002 23:15:35 +0900 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by polo.jmi.co.kr (8.9.0/8.9.0) with ESMTP id XAA23075 for ; Wed, 18 Dec 2002 23:18:40 +0900 (KST) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18Oe3r-0006fF-00 for ietf-announce-list@ran.ietf.org; Wed, 18 Dec 2002 08:16:31 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18OdvE-0006Qe-00 for all-ietf@ran.ietf.org; Wed, 18 Dec 2002 08:07:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04590; Wed, 18 Dec 2002 08:04:08 -0500 (EST) Message-Id: <200212181304.IAA04590@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: hangsang@mofat.go.kr Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-symkeydist-08.txt Date: Wed, 18 Dec 2002 08:04:08 -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 : CMS Symmetric Key Management and Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-08.txt Pages : 81 Date : 2002-12-16 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-08.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-symkeydist-08.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-symkeydist-08.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: <2002-12-16123649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-16123649.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Thu Dec 19 09:55:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17304 for ; Thu, 19 Dec 2002 09:55:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBJEVJe07928 for ietf-smime-bks; Thu, 19 Dec 2002 06:31:19 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gBJEVIo07922 for ; Thu, 19 Dec 2002 06:31:18 -0800 (PST) Received: (qmail 6154 invoked from network); 19 Dec 2002 14:31:04 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.218.137) by woodstock.binhost.com with SMTP; 19 Dec 2002 14:31:04 -0000 Message-Id: <5.2.0.9.2.20021218142741.00b3b6b8@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 18 Dec 2002 14:33:47 -0500 To: KATO Akihiro , ietf-smime@imc.org From: Russ Housley Subject: Re: Comments on draft-ietf-smime-camellia In-Reply-To: <20021217134533.5013.AKATO@po.ntts.co.jp> References: <000a01c290c6$05c2ebe0$3a482acc@soaringhawk.net> <000a01c290c6$05c2ebe0$3a482acc@soaringhawk.net> 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: Kato: I agree with Jim. An algorithm identifier has the following syntax: AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } Absent means that the optional parameters are not present. NULL means that the fields is present with a null type (a tag of 0x05) and a length of zero. Russ At 01:45 PM 12/17/2002 +0900, KATO Akihiro wrote: >Hi Jim > >On Wed, 20 Nov 2002 13:51:19 -0500 >"Jim Schaad" wrote: > >snip > > > 7. Section 2.2: I strongly suggest that you change the parameters for > > the key wrap algorithm OIDs to be ABSENT rather than NULL. > >How is ABSENT that you say the meaning that says? We are using the word >called NULL is 'the parameter does not exist,but parameter field exist'. > >I think that this one is good. It is because it becomes clear that the >parameter does not exist. > >On the other hand, there is the possibility that is interpreted that >default is used, if place itself that designates the parameter is absent. > >Regards. >-- >- KATO Akihiro > + NTT Software Corporation > + Internet Technology Laboratory From owner-ietf-smime@mail.imc.org Fri Dec 20 11:08:41 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00445 for ; Fri, 20 Dec 2002 11:08:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBKFi6X16598 for ietf-smime-bks; Fri, 20 Dec 2002 07:44:06 -0800 (PST) Received: from tweety (pool-151-200-26-46.res.east.verizon.net [151.200.26.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKFi4o16593 for ; Fri, 20 Dec 2002 07:44:04 -0800 (PST) Received: from [192.168.0.12] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Fri, 20 Dec 2002 10:39:27 -0500 Message-ID: <3E0339AD.9050105@ieca.com> Date: Fri, 20 Dec 2002 10:39:25 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: I-D ACTION:draft-ietf-smime-symkeydist-08.txt References: <200212181304.IAA04590@ietf.org> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit All,

The posted new draft addresses two comments from the IESG:

- The first one was that the references needed to be broken out to indicate which documents are informative and which are normative. 
- The second was a concern about reply attacks.  We added the CMS signingTime attribute to ever signed message.

Cheers,

spt

Internet-Drafts@ietf.org wrote:
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		: CMS Symmetric Key Management and Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-08.txt
	Pages		: 81
	Date		: 2002-12-16
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-08.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-symkeydist-08.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-symkeydist-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBKFi6X16598 for ietf-smime-bks; Fri, 20 Dec 2002 07:44:06 -0800 (PST) Received: from tweety (pool-151-200-26-46.res.east.verizon.net [151.200.26.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBKFi4o16593 for ; Fri, 20 Dec 2002 07:44:04 -0800 (PST) Received: from [192.168.0.12] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Fri, 20 Dec 2002 10:39:27 -0500 Message-ID: <3E0339AD.9050105@ieca.com> Date: Fri, 20 Dec 2002 10:39:25 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: I-D ACTION:draft-ietf-smime-symkeydist-08.txt References: <200212181304.IAA04590@ietf.org> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All,

The posted new draft addresses two comments from the IESG:

- The first one was that the references needed to be broken out to indicate which documents are informative and which are normative. 
- The second was a concern about reply attacks.  We added the CMS signingTime attribute to ever signed message.

Cheers,

spt

Internet-Drafts@ietf.org wrote:
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		: CMS Symmetric Key Management and Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-08.txt
	Pages		: 81
	Date		: 2002-12-16
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-08.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-symkeydist-08.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-symkeydist-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBJEVJe07928 for ietf-smime-bks; Thu, 19 Dec 2002 06:31:19 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gBJEVIo07922 for ; Thu, 19 Dec 2002 06:31:18 -0800 (PST) Received: (qmail 6154 invoked from network); 19 Dec 2002 14:31:04 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.218.137) by woodstock.binhost.com with SMTP; 19 Dec 2002 14:31:04 -0000 Message-Id: <5.2.0.9.2.20021218142741.00b3b6b8@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 18 Dec 2002 14:33:47 -0500 To: KATO Akihiro , ietf-smime@imc.org From: Russ Housley Subject: Re: Comments on draft-ietf-smime-camellia In-Reply-To: <20021217134533.5013.AKATO@po.ntts.co.jp> References: <000a01c290c6$05c2ebe0$3a482acc@soaringhawk.net> <000a01c290c6$05c2ebe0$3a482acc@soaringhawk.net> 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: Kato: I agree with Jim. An algorithm identifier has the following syntax: AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } Absent means that the optional parameters are not present. NULL means that the fields is present with a null type (a tag of 0x05) and a length of zero. Russ At 01:45 PM 12/17/2002 +0900, KATO Akihiro wrote: >Hi Jim > >On Wed, 20 Nov 2002 13:51:19 -0500 >"Jim Schaad" wrote: > >snip > > > 7. Section 2.2: I strongly suggest that you change the parameters for > > the key wrap algorithm OIDs to be ABSENT rather than NULL. > >How is ABSENT that you say the meaning that says? We are using the word >called NULL is 'the parameter does not exist,but parameter field exist'. > >I think that this one is good. It is because it becomes clear that the >parameter does not exist. > >On the other hand, there is the possibility that is interpreted that >default is used, if place itself that designates the parameter is absent. > >Regards. >-- >- KATO Akihiro > + NTT Software Corporation > + Internet Technology Laboratory Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBIEFfV09172 for ietf-smime-bks; Wed, 18 Dec 2002 06:15:41 -0800 (PST) Received: from jupiter.jmi.co.kr ([211.45.79.102]) by above.proper.com (8.11.6/8.11.3) with SMTP id gBIEFbo09165 for ; Wed, 18 Dec 2002 06:15:40 -0800 (PST) Received: (qmail 3707 invoked by uid 525); 18 Dec 2002 23:16:29 +0900 Received: (qmail 3681 invoked from network); 18 Dec 2002 23:15:35 +0900 Received: from unknown (HELO polo.jmi.co.kr) (211.45.79.31) by 0 with SMTP; 18 Dec 2002 23:15:35 +0900 Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by polo.jmi.co.kr (8.9.0/8.9.0) with ESMTP id XAA23075 for ; Wed, 18 Dec 2002 23:18:40 +0900 (KST) Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18Oe3r-0006fF-00 for ietf-announce-list@ran.ietf.org; Wed, 18 Dec 2002 08:16:31 -0500 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18OdvE-0006Qe-00 for all-ietf@ran.ietf.org; Wed, 18 Dec 2002 08:07:36 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04590; Wed, 18 Dec 2002 08:04:08 -0500 (EST) Message-Id: <200212181304.IAA04590@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: hangsang@mofat.go.kr Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-symkeydist-08.txt Date: Wed, 18 Dec 2002 08:04:08 -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 : CMS Symmetric Key Management and Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-08.txt Pages : 81 Date : 2002-12-16 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-08.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-symkeydist-08.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-symkeydist-08.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: <2002-12-16123649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-16123649.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBID79f26318 for ietf-smime-bks; Wed, 18 Dec 2002 05:07:09 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBID78o26306 for ; Wed, 18 Dec 2002 05:07:08 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04590; Wed, 18 Dec 2002 08:04:08 -0500 (EST) Message-Id: <200212181304.IAA04590@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-symkeydist-08.txt Date: Wed, 18 Dec 2002 08:04:08 -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 : CMS Symmetric Key Management and Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-08.txt Pages : 81 Date : 2002-12-16 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-08.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-symkeydist-08.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-symkeydist-08.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: <2002-12-16123649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-16123649.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBI2djp06000 for ietf-smime-bks; Tue, 17 Dec 2002 18:39:45 -0800 (PST) Received: from imc.org ([210.21.34.191]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBI2dOo05987 for ; Tue, 17 Dec 2002 18:39:42 -0800 (PST) Message-Id: <200212180239.gBI2dOo05987@above.proper.com> From: x0152@sina.com.cn Subject: =?GB2312?B?zOG5qc34wufJ48/xu/o=?= To: ietf-smime@imc.org Content-Type: text/plain;charset="GB2312" Reply-To: housley@vigilsec.com Date: Wed, 18 Dec 2002 10:43:15 +0800 X-Priority: 3 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ---- No: 6381 你好 我们是深圳香归电子有限公司 我们提供网络摄像机及监控系统的安装调试 网络摄像机作为下一代商业应用程序的超级平台，它都为 Web 专业人士提供了前所未有的功能。 为管理企业应用程序提供了运行时间环境和图示管理工具。 如有需要请与广州办事处联系　 电话：020－82349026 赵巧辉 公司网址www.xianggui.com 邮件：zhaoqiaohui@xgjk.sina.com.cn Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBH4k2N27731 for ietf-smime-bks; Mon, 16 Dec 2002 20:46:02 -0800 (PST) Received: from mail1.ics.ntts.co.jp (mail1.ics.ntts.co.jp [202.32.24.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBH4k1o27726 for ; Mon, 16 Dec 2002 20:46:01 -0800 (PST) Received: from mail26.silk.ntts.co.jp by mail1.ics.ntts.co.jp (8.9.3/3.7W-NTTSOFT-SUR2.0) id NAA16090 for ; Tue, 17 Dec 2002 13:46:00 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Received: from helene.mc.ntts.co.jp by mail26.silk.ntts.co.jp (8.11.6/3.7W-silk-4.6) id gBH4jxW24960; Tue, 17 Dec 2002 13:45:59 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Received: from [10.7.120.83] ([10.7.120.83]) by helene.mc.ntts.co.jp (8.12.5/8.12.5) with ESMTP id gBH4jwQ7085941; Tue, 17 Dec 2002 13:45:58 +0900 (JST) (envelope-from akato@po.ntts.co.jp) Date: Tue, 17 Dec 2002 13:45:58 +0900 From: KATO Akihiro To: ietf-smime@imc.org Subject: Re: Comments on draft-ietf-smime-camellia Cc: akato@po.ntts.co.jp In-Reply-To: <000a01c290c6$05c2ebe0$3a482acc@soaringhawk.net> References: <000a01c290c6$05c2ebe0$3a482acc@soaringhawk.net> Message-Id: <20021217134533.5013.AKATO@po.ntts.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Jim On Wed, 20 Nov 2002 13:51:19 -0500 "Jim Schaad" wrote: snip > 7. Section 2.2: I strongly suggest that you change the parameters for > the key wrap algorithm OIDs to be ABSENT rather than NULL. How is ABSENT that you say the meaning that says? We are using the word called NULL is 'the parameter does not exist,but parameter field exist'. I think that this one is good. It is because it becomes clear that the parameter does not exist. On the other hand, there is the possibility that is interpreted that default is used, if place itself that designates the parameter is absent. Regards. -- - KATO Akihiro + NTT Software Corporation + Internet Technology Laboratory Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBEHDBI09306 for ietf-smime-bks; Sat, 14 Dec 2002 09:13:11 -0800 (PST) Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBEHD8E09297; Sat, 14 Dec 2002 09:13:08 -0800 (PST) Received: from arport (h140n2fls31o1122.telia.com [212.181.142.140]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id gBEHCxC3008323; Sat, 14 Dec 2002 18:12:59 +0100 (CET) X-Original-Recipient: ietf-smime@imc.org Message-ID: <003301c2a392$e4d37050$0500a8c0@arport> From: "Anders Rundgren" To: "Peter Gutmann" , Cc: References: <200212140245.gBE2jGc07400@medusa01.cs.auckland.ac.nz> Subject: Re: e-Government uses "Authority-stamp-signatures" Date: Sat, 14 Dec 2002 18:04:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, Late-breaking news received off-list! Apparently the Estonian (http://www.cyber.ee/infosecurity/projects/xroad-pilt.html ) and Italian e-Governments are also working along similar lines as their Swedish counterpart. Everybody seems wanting to get credit for being a part of the paradigm-shift! Who's next? :-) now to the technicalities.... As you probably have noted, technologies for server-based secure messaging are currently in a state of extreme flux, so all efforts are likely to be more or less "home-brewed". Or built on s.c. "standards" that are obsoleted a year or two after being intro- duced which is about the same thing. :-( I believe that DOMSEC has unfortunately already met its maker. Even SMTP and S/MIME will diminish in importance due to the "Web Services" craze. The practically "frictionless" [transport] encryption offered by HTTPS as well as the support for synchronous operation are absolutely crucial in many scenarios. SMTP will in the O2O context probably be "degraded" to a user-notification- tool for otherwise Web Services-based messaging and work-flow. Long-term all these systems will probably (hopefully?) converge into "true" Web Services using WS-Security and XML Signatures. cheers Anders R ----- Original Message ----- From: "Peter Gutmann" To: ; Cc: Sent: Saturday, December 14, 2002 03:45 Subject: Re: e-Government uses "Authority-stamp-signatures" [CC'd across to ietf-smime] "Anders Rundgren" writes: >It may be interesting to know that Swedish authorities are currently >launching a Web Services-like system called SHS, where authorities >communicate with each other through web-server "nodes" where out-going >messages are automatically signed by the authority identified as an "entity" >(organization), rather by an individual associated to the authority. Does this follow a particular model like DOMSEC, or is it yet another roll- your-own? There appear to be a number of groups doing DOMSEC-like things, but everyone's doing it differently... Peter. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gBE35jD06825 for ietf-smime-bks; Fri, 13 Dec 2002 19:05:45 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gBE2jJE05349; Fri, 13 Dec 2002 18:45:20 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gBE2jGbT018183; Sat, 14 Dec 2002 15:45:16 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id gBE2jGc07400; Sat, 14 Dec 2002 15:45:16 +1300 Date: Sat, 14 Dec 2002 15:45:16 +1300 Message-Id: <200212140245.gBE2jGc07400@medusa01.cs.auckland.ac.nz> From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: anders.rundgren@telia.com, ietf-pkix@imc.org Subject: Re: e-Government uses "Authority-stamp-signatures" Cc: ietf-smime@imc.org Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [CC'd across to ietf-smime] "Anders Rundgren" writes: >It may be interesting to know that Swedish authorities are currently >launching a Web Services-like system called SHS, where authorities >communicate with each other through web-server "nodes" where out-going >messages are automatically signed by the authority identified as an "entity" >(organization), rather by an individual associated to the authority. Does this follow a particular model like DOMSEC, or is it yet another roll- your-own? There appear to be a number of groups doing DOMSEC-like things, but everyone's doing it differently... Peter. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB942EY10934 for ietf-smime-bks; Sun, 8 Dec 2002 20:02:14 -0800 (PST) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB942Cg10930 for ; Sun, 8 Dec 2002 20:02:12 -0800 (PST) Received: from revelation (12-230-156-246.client.attbi.com[12.230.156.246]) by sccrmhc02.attbi.com (sccrmhc02) with SMTP id <2002120904015400200fh2jke>; Mon, 9 Dec 2002 04:01:54 +0000 Reply-To: From: "Jim Schaad" To: "'Peter Gutmann'" , Subject: RE: Draft Minutes Date: Sun, 8 Dec 2002 20:01:30 -0800 Message-ID: <001101c29f37$a8b929c0$0e00a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, Yes, I would consider that to be sufficent. I have not read your code dealing with this issue. Many of the versions I know about do a full decode of the structure and would fail decode if new structures were added. jim > -----Original Message----- > From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] > Sent: Sunday, December 08, 2002 7:43 PM > To: jimsch@nwlink.com; ietf-smime@imc.org > Subject: Re: Draft Minutes > > > [Apologies if you've seen this before, one of our machines > has been quietly > dropping outgoing mail...] > > "Jim Schaad" writes: > > >There was a discussion dealing with two issues found during > interoperability > >testing. The first dealt with the fact that so far no > implementations are > >known that deal gracefully with unknown RecipientInfo and SignerInfo > >structures. > > What's the definition of "deal gracefully"? When this was > discussed quite > some time ago, I modified my code to ignore new structures > that it didn't > recognise, and I thought there were indications from others > that they would be > doing the same. Is that sufficient? > > Peter. > > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB93gfo10297 for ietf-smime-bks; Sun, 8 Dec 2002 19:42:41 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB93gcg10291 for ; Sun, 8 Dec 2002 19:42:38 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id gB93gZxI031950 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 9 Dec 2002 16:42:36 +1300 Date: Mon, 9 Dec 2002 16:42:36 +1300 (NZDT) From: Peter Gutmann To: jimsch@nwlink.com, Subject: Re: Draft Minutes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Apologies if you've seen this before, one of our machines has been quietly dropping outgoing mail...] "Jim Schaad" writes: >There was a discussion dealing with two issues found during interoperability >testing. The first dealt with the fact that so far no implementations are >known that deal gracefully with unknown RecipientInfo and SignerInfo >structures. What's the definition of "deal gracefully"? When this was discussed quite some time ago, I modified my code to ignore new structures that it didn't recognise, and I thought there were indications from others that they would be doing the same. Is that sufficient? Peter. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6LwdJ04081 for ietf-smime-bks; Fri, 6 Dec 2002 13:58:39 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gB6LwZg04076 for ; Fri, 6 Dec 2002 13:58:36 -0800 (PST) Received: (qmail 19844 invoked from network); 6 Dec 2002 21:58:26 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.181.81) by woodstock.binhost.com with SMTP; 6 Dec 2002 21:58:26 -0000 Message-Id: <5.2.0.9.2.20021206165539.00b2e9d0@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Dec 2002 16:58:16 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Re: Draft Minutes 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: If anyone has comments on the minutes that were posted by Jim Schaad, please send a message to the list by Tuesday, 10 December. The Minutes are due to the IETF Secretariat soon. Thanks, Russ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB6L0tG28685 for ietf-smime-bks; Fri, 6 Dec 2002 13:00:55 -0800 (PST) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB6L0ng28661 for ; Fri, 6 Dec 2002 13:00:49 -0800 (PST) Received: from revelation (12-230-156-246.client.attbi.com[12.230.156.246]) by rwcrmhc52.attbi.com (rwcrmhc52) with SMTP id <20021206210045052001ajs1e>; Fri, 6 Dec 2002 21:00:45 +0000 Reply-To: From: "Jim Schaad" To: Subject: Draft Minutes Date: Fri, 6 Dec 2002 13:00:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_01C29D27.72F09510" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MS-TNEF-Correlator: 00000000C61F957EEEE3D311963C000086335A64E42A2900 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_0014_01C29D27.72F09510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are the minutes for the working group meeting in Atlanta. Minutes for the S/MIME Meeting IETF 55 November 19, 2002 Agenda: Russ Housley covered the agenda for the meeting. No changes = were made. Working Group Status: Russ Housley covered the status of the active documents in the working group. The documents that have changed status since the last meeting are: Published as an RFC: - RFC 3369 - Cryptographic Message Syntax - RFC 3370 - Cryptographic Message Syntax (CMS) Algorithms - RFC 3394 - Advanced Encryption Standard (AES) Key Wrap Algorithm RFC Editors Queue: - There are currently no documents in the RFC Editor Queue IESG - CMS Symmetric Key Management and Distribution - Use of the RSAES-OAEP Transport Algorithm in CMS - Transporting S/MIME Objects in X.400 - Securing X.400 Content with S/MIME - Wrapping an HMAC key with a Triple-DES Key or an AES Key Examples Draft: Paul Hoffman was unable to be present so Russ presented = for him. There has been a recent discussion on the list that a triple-wrap example as defined in ESS (RFC 2634) should be added to the draft. John Pawling has volunteered to provide this example. After it is = incorporated the document, and a few minor edits are made, the Examples Draft should = be ready for working group last call. X400 Transport and Wrap Drafts: Chris Bonatti gave the presentation for these two drafts. There were some comments from the IESG on the = documents, and some synchronization between the RFC2633bis Draft and X.400 Wrap = Draft was needed. The IESG comments have been resolved, and the two S/MIME working documents are now consistent. The X.400 Transport and Wrap = Drafts are ready for the IESG. Chris is trying to coordinate a review of the documents by the ITU-T group responsible for X.400, but this should not = stop the draft from going to Proposed Standard. Any comments from this group = can be incorporated before going to Draft Standard. AES Algorithm Draft: Jim Schaad stated that the document has been = modified to remove the requirement that AES is not to be used with PKCS #1 v1.5. = The document will be submitted as soon as the repository opens, and then the chair will make the working group last call. CMS Interoperability Status: Jim Schaad stated that advancement has = been made since the last meeting for CMS interoperability. There are 6 test cases left to complete interoperability testing. These test cases deal with: 1) v2 attribute certificates for SignedData and EnvelopedData; 2) unrecognized SignerInfo structures; 3) unrecognized RecipientInfo structures; and 4) version numbering in EnvelopedData for pwri and/or = ori being present as a RecipientInfo. The v2 attribute certificate test = cases should be finished soon as a bug is found and fixed in one = implementation. There was a discussion dealing with two issues found during = interoperability testing. The first dealt with the fact that so far no implementations = are known that deal gracefully with unknown RecipientInfo and SignerInfo structures. No discussion was generated from the floor. The second = issue dealt with the fact that there is no MUST statement on handling of = detached as opposed to embedded content. Both detached content and embedded = content are mandated by the S/MIME message specification (RFC 2633) for = SignedData, and embedded content is mandated for EncryptedData. Should this be = moved into the CMS draft as well? No discussion from the floor ensued. Camellia Draft: KATO Akihiro gave the presentation on the draft for = Camellia to be used as a content encryption algorithm with CMS. Camellia = operations at the same block and key sizes as AES. Camellia will use the AES key = wrap algorithm for doing key encryption. The authors are going to be adding = a section on SMIMECapabilities before the next revision. Information on Camellia can be gotten at http//info.isl.ntt.co.jp/camellia. Message Update Draft: Blake Ramsdell was unable to make it to the = meeting. Russ presented Blake's slides for him. The current draft was modified = to deal with allowing for binary transport internally, signing message = headers and using the compression content type. Following the presentation the chair stated that the document should be ready to progress and a last = call will be issued shortly. Certificate Update Draft: Russ also presented the certificate draft = updates for Blake. The changes in the last draft are changes to the wording for email address matching and to deal with the = nonRepudiation/digitalSignature bits in the key usage certificate extension. There are still some additional changes are needed to resolve previously submitted comments. Also, there are some TBA areas in the draft. IESG status of HMAC Key Wrap draft: Jeff Schiller was asked to give = further information about the current status of the HMAC Key Wrap draft which is currently stuck at the IESG. The issue has to do with the fact that the working group requested publication as an Informational RFC, which for advancement purposes is really below Proposed Standard for purposes of advancement. Thus any document that relied on it could not go forward. Russ said that this has been historically what has been done by this = working group; document describing algorithms are informational, while documents describing how to use the algorithms are standards track. Jeff is going = to attempt to get the problem solved on a basic level, however the working group granted permission to move the document to standards track if it appears that solving the basic problem is going to take too long. ------=_NextPart_000_0014_01C29D27.72F09510 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IhsVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGAAcAAQAAAAAAAAEGgAMADgAAANIHDAAG AA0AAAAAAAUA/QABA5AGAMwPAAApAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAAC ATEAAQAAABgAAAAAAAAAxh+Vfu7j0xGWPAAAhjNaZKQqKQADADYAAAAAAB4AcAABAAAADgAAAERy YWZ0IE1pbnV0ZXMAAAACAXEAAQAAABYAAAABwp1qaMJEWvHL41FBGJRAFfeeEKuVAAACAR0MAQAA ABcAAABTTVRQOkpJTVNDSEBOV0xJTksuQ09NAAALAAEOAAAAAEAABg4ASIpwap3CAQIBCg4BAAAA GAAAAAAAAADGH5V+7uPTEZY8AACGM1pkwoAAAAMAFA4AAAAACwAfDgEAAAACAQkQAQAAAMwLAADI CwAAqBcAAExaRnWe+rReAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/ CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAz CwkBZDM2FlALpiBImQSQZSAKwB0gdGgdIPptC4B1DrAEIAIQBcAdgsp3BbBrC4BnIAnACGB2cB2w CeB0HwILgBDAdHMLYAIwYS4KogqEIRZNgR3dUy9NSU1FBdCDH7Qg1ElFVEYgGmBhINROb3ZlBtAS gTFoOSwgAdAwDlAg6UFCZwnwZGE6IAfwdQUEEUgIYHNsZXkg7wWgJSAYIR1zYSbjHjcfpX4uJ0Al ACggE+AfEAeRd68dAgDAAQAgy1ce1UcfU7pTAZB0J3AnPyhJcy2DaCBvZiikYx/QJSAg8GRvY3UH gAIwBCAgIXsejypRVB2RMOgdgC2QID8T4DCxKrQokC+VAJBuY18dZAtgL5Aflx1BOiDaUP51AmAE AB2QKJA2EB0wA6AoUkZDNwUtOMIgM4kcIDkgOXBDcnkFMOJvCcBhcGgN4CNRBBDXKPEUUSCReDkc NxZQOi9ROzsgKEMF4CkQwGxKZwWwaR2AbXM5HDniND0BQWR2AHA1kCiQ9kU1gD1CaQIgLWInAQsg qT7wQUU/MUsoAVc9oec/WCDaOZJFZD+wBbAEIH5RClAKUDkHMvEdFTEAcusYIAIwbCgQbiqQMO9F SOdF9CDaJDBTRzkWPxEUUt0HgHQFEDsAQ2JNAHAo8bcxIjiRKJBEBABMcWId8JtCMTkWVRQQL/ZS U0MRdC1PQxBQMuA9oACAcP8XwT9YIBI/EUZnUKYfAiL1GE9iagWQMVRYLjT/JeA5FgZgR4EfAlSj EiECML9NcgPwHYAi5TkWQ6JwNpPRA6BITUE5sGsoAVbjzylAUJAFICfwLURDIENTHwWxA5FDEUNS INpFeGF2bVoBBCBEPaABgC3RULxhdQMgLlABIAOCdzhxPnVNIAJgHWEqkCVQIHD3GCAUEE2BcyqQ LgNfRSiB+x5CPdBtMsQdERPgBCAlUP8J8FmhGCA1kE2BRZAE8C4R/0IyQkE1w04BM8QpQExxWgL+ d0OyDsBcczhiAQELgCiBFyAhQyAF8Cg5kjI2M+40P0A4IAhgbCiQXxErkG8BACiRKpAdgmRc8ipR SuxvaAOgXWB3OAAfEWHi/nYG8F5wDrAoZCqQX0AlEL5pAQAdcQQAZZYqUUEBgP8SgT+wIBAxYgWh UOEtkCiF/0hWJbBNsilBB9EdwQWxCYD/P7A4gStVJbAdglxcZ+kYIF8rkCgQHkIezDYDYwdAbP0g y1hWIlCYTbJDo1zjLcLsQ2gFEAQgQgIgLZAf0P8fMDQyHYJfRS2QQjIeRU9B9nQewGlUc2FXKzNf wAeA/yghTEExQgNSHXNLImOmSFd7b6R843M7sBPQA2ADAHo/emQlUHtgYjJJJWeRM2L/bIFylE2y VgR3qF4jZpAJgP8JgDLFflN9NzQjYiNfUQbw/SUgZG+kHYJ7YiL1HsZIWP8dQkggB+AFoACBL5Ax MTLF/1YEds931h0zc5h+FipReIT7bIFMcHkfAl7hBaAFsEWQf3kBHSFigWwQB9EwBUhYYsMoEH4T VFUtVB81X1H/UOAAgV6iHkJUoyWwTlFsVP9n9UggX6E9cB+AaSd9tD+A/Y/VUANgUOAUECiQQnZt Iv5uKBJ9XGyBH0R1YIEybgz/JVAeQR0gl7dylJjXJhtaUftROFzmSgdwBgAT0SuQL4P/KIMz8W7q YdgEYQaQCJBo048YIARgeYUYIHF1aaQx/01yM9NbImyBljJe5C4QKIGRVuNQS0MF8CMxauB4MS41 Ms1W0XWAXwJz/zfgHcACQDhEX8BCQThxpKT3mHFFolqhcAnwf5UdgTGU/xPRpSCpVADAWSAxr3T/ ISX9S+JJVoGYUQSQAaADED+w/ygQLXegr2RlQUSinSuRNV9/H7UeQkviC4CxTGFXHUI2/x1wB5Cv shQQBCAn8HLBkBP/XIKQwbfOuaMqJDLxezK5yK8BAAdAVtMt0DE/QHYUQP95EU4zNFEEkB/QZnCv 0B4G6FNpZ2aRRC2QKUBNst9BwCUgF7CsMMFDOyXAP0C/XnBikT2AgMGYosECcrEgewIQL4FyGtAt oF9RwrAz/cLtUgWQBSAIkAIwxD9Nsv9nwShRY2Md4CVCH+XB6x4z7nBlUHlAQpEvBbE/kV8B/x8C X0Y4csY8MsW/H8Aluar/Z/hmcTgUqrYpQE5QIAEeIu9ecDhRTcFmcHhmpAIgm6H/XIIxInpjIMt8 NcyjYwm+Mr8fAlbje2IEAQpQ0pZkVaT/u3+8i9EBFABi4b5BVsUdgv5mMHEzxF/B3NAFwEgh1Cz9 cQRrijExkjPxvjM9kbYA/mZdgEfxVuNecN9UxkxNsv/D38TiKlRjCV4yJuGxkWCj/X3WZhewBbAy xRQQinFmsX/YYtvf3OcdgR0RpjMF0FW+U5NAoVNNY0JBKsFkamP/MAEBAAGQE9A4RJaQmHRe4f8l MmijinGK1XjgVwHsh+6F/02j7f5xFScBnFOSpCL1B4H/O1NQ0MZRwDNCMmdGxUHAvP9vpPDPbIHy Fx5CQcXBNCpR/lNoBGxjXxGkUmayaPVL4u+XBDhxKzB1gD/kXuY8ZZD3AIAKUJ5sQ1xw/KEHMFzW 8EtBVE8QwB7wPdADYP95X3pkfqaXFLdSABamqcyj//AGCfBB59dgUVanUz8RjuL/ABaxc961ofQ7 UH0BF/Aw8P5rTaNZIpQgw5DMsRCxQyD/CCqpY6cBHXNbIlkjQ7IHCP+3QkhQHwJZIgZYMsVdcKdw f0XCuVKXt2hkNpPncgLmU/8jEgAAGxCxw5FAYgKcsx2CfWaQeGSgkRJjYipRxtJy/7WAAuYAB5tV P4CqMWJRNAHxqjBwLy+QkM2h5/B1kOcgkGmgm+Auahkwr9AAJLMgyzsmVXDyQlzXQiBw9a4xUlxw c2ZQqYFePK4T322xaPUp6F/9HVMnNUE4AP9mUMCUYSdHdpb11jKjer43/wbxwiCnULcVgoBNIKvx THD/ULa3w00g4MFvoJQgw2EyQf/zhhVAK5ERMk3BLhCP060yf7rxX1FjY/AGsgD0EORBRv9rACYV Ai+tKKFfomZy/mu0/5rwOzFvta+HqVfn83/hERH/R+GwHM8ZHG0gs9dgX8FgSP+tI88ZlwSTkPJC wJQdUyMG/+vB5ZBI16+D/AVHUjtVaPX/rqESg7dCTVCtgKmQaJEx838WwezAWGQlDRUz9LDGQHDW dUWQemMvRZBnFGDXYP/A8rJRR1GCgEjIWSIgwBwi/88KFYGsQRBHuSW8oamBfOP/EmL0kr5RO0aJ 84TDo/SHI/9fMmwQk4AiIAsRqfd9Nm0ijzeBcaNGpnzyVEJBEVL/C5FD5Wlk1Rp+Uy7yIMCRct9Y 01qCg8NpYx0gSmZgkZDvswGpcW2B1jNzWSBo00Kg/wHx4KDPIGGRZsEWmLGwk4D/ofQjdlAoFTJQ z4RCItDswP9t0iN1StKyYAqCofSOpdtC/+f0YeIlIrrA6L+h9K6spOL/ucEhcUHglED0ZsyiYlAW ef++UfTxb6BYlLdCtDpB4G5R/7oibIGNweDCaGAmEZg/+IT/YueRgbQ52xNQYYwAshCiV//dI6Uw FFAhcfSxbbGb4JX2/xhgerLWMJkzILMcECJAL1b/0oG095qxq9E10eDD3TK09/9/ENPxkpPSga6r wrCiVyJR//kAlDASk5+WSNRUmddgYWP/HsGJWHD5ERCKUATRDQZxre8u8ZkDj4LgcGvkQVITmsJ/ l8bOYbSQ+TBTg+yQLTVv/5RBffCHJH6S0iELkDXQulH/wgH2cHUxfCGORK6s4FEhU/+xgaoQ5PQe 8qRmaAjEYnc7/8lgeGG0Ee1QKaAp4d0lh0D/KnZ7tHp2eIrsoK4y0bC2YC/0sCBw1Rqe5H2HcAMA khADAAAAAgEUOgEAAAAQAAAAtkHF2RbBXkKhaMYtTWXXhgMA3j+fTgAAAwAJWQEAAAADAEBlAAAA AAMAAIAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAA UoUAAOOQAQAeAASACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAUAAAAxMC4wAAAAAAsABYAI IAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwAGgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAA AAALAAeACCAGAAAAAADAAAAAAAAARgAAAAADhQAAAAAAAAsACIAIIAYAAAAAAMAAAAAAAABGAAAA AA6FAAAAAAAAAwAKgAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAALABaACCAGAAAAAADAAAAA AAAARgAAAACChQAAAQAAAAIB+A8BAAAAEAAAAMYflX7u49MRljwAAIYzWmQCAfoPAQAAABAAAADG H5V+7uPTEZY8AACGM1pkAgH7DwEAAABJAAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRs bAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxtYWlsXGN1cnJlbnQucHN0AAAAAAMA/g8FAAAAAwAN NP03AgACARQ0AQAAABAAAABOSVRB+b+4AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAwMDBDNjFG OTU3RUVFRTNEMzExOTYzQzAwMDA4NjMzNUE2NEU0MkEyOTAwAAAAAAMABhAdZhdnAwAHENARAAAD ABAQAAAAAAMAERABAAAAHgAIEAEAAABlAAAASEVSRUFSRVRIRU1JTlVURVNGT1JUSEVXT1JLSU5H R1JPVVBNRUVUSU5HSU5BVExBTlRBTUlOVVRFU0ZPUlRIRVMvTUlNRU1FRVRJTkdJRVRGNTVOT1ZF TUJFUjE5LDIwMDJBRwAAAAC4fw== ------=_NextPart_000_0014_01C29D27.72F09510-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB5KiUj01995 for ietf-smime-bks; Thu, 5 Dec 2002 12:44:30 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB5KiSg01983 for ; Thu, 5 Dec 2002 12:44:28 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27496; Thu, 5 Dec 2002 15:41:38 -0500 (EST) Message-Id: <200212052041.PAA27496@ietf.org> To: IETF-Announce: ; Cc: ietf-smime@imc.org From: The IESG SUBJECT: Last Call: Use of the RSAES-OAEP Transport Algorithm in CMS to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 05 Dec 2002 15:41:38 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security Working Group to consider Use of the RSAES-OAEP Transport Algorithm in CMS as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-12-19. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-07.txt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4Jf7D19319 for ietf-smime-bks; Wed, 4 Dec 2002 11:41:07 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id gB4Jedg19314 for ; Wed, 4 Dec 2002 11:40:39 -0800 (PST) Received: (qmail 28323 invoked from network); 4 Dec 2002 19:40:32 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (208.208.101.17) by woodstock.binhost.com with SMTP; 4 Dec 2002 19:40:32 -0000 Message-Id: <5.2.0.9.2.20021204143717.028cb460@mail.binhost.com> X-Sender: housley@mail.binhost.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 04 Dec 2002 14:40:08 -0500 To: "Dieter Bratko" , From: Russ Housley Subject: Re: SignedReceipt In-Reply-To: <032e01c296ef$38b150d0$58981b81@iaik.at> References: <5.2.0.9.2.20021126133201.02961940@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: "Dieter: It simply needs to be a unique identifier of the signed content. This allows the originator of the original message to locate the message when the receipt arrives. Russ At 04:02 PM 11/28/2002 +0100, Dieter Bratko wrote: >Hello, > >Implementing the ESS Signed Receipt service I would like to tell the >following question regarding the role of the message originator: >According to RFC2634 the signedContentIdentifier field should contain >user-specific identification information (such as a user name or public >keying material identification information). When creating a receipt the >signedContentIdentifier is copied from the receiptRequest to the receipt: > >Receipt ::= SEQUENCE { > version ESSVersion, > contentType ContentType, > signedContentIdentifier ContentIdentifier, > originatorSignatureValue OCTET STRING } > > > >Is my interpretation right that the user-specific identification information >implicitly contained in the signedContentIdentifier -- since it has to be >the same for any receiptRequest attribute of any SignerInfo containing a >receiptRequest attribute -- refers to the (one and only) message originator >(sender), but the originatorSignatureValue field holds the signature value >from the SignerInfo just processed (which not necessarily has to be the >signerInfo of the originator); and when creating the receipt it does not >mind which SignerInfo it is based on (the validator must be able to validate >receipts based on any SignerInfo contained in the original SignedData)? > >Regards, >Dieter Bratko > >--------- >Dieter Bratko, >Institute for Applied Information Processing and Communications (IAIK) >Graz University of Technology, Inffeldgasse 16a, 8010 Graz, Austria, >http://jce.iaik.tugraz.at/ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id gB4CdWq17901 for ietf-smime-bks; Wed, 4 Dec 2002 04:39:32 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id gB4CdTg17895 for ; Wed, 4 Dec 2002 04:39:30 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07942; Wed, 4 Dec 2002 07:36:39 -0500 (EST) Message-Id: <200212041236.HAA07942@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-rsaes-oaep-07.txt Date: Wed, 04 Dec 2002 07:36:38 -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 RSAES-OAEP Transport Algorithm in CMS Author(s) : R. Housley Filename : draft-ietf-smime-cms-rsaes-oaep-07.txt Pages : 15 Date : 2002-12-3 This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). The CMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-07.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-rsaes-oaep-07.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-rsaes-oaep-07.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: <2002-12-3142449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cms-rsaes-oaep-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-3142449.I-D@ietf.org> --OtherAccess-- --NextPart--