This DUMB LITTLE AD will put $200 in your pocket every day!!! -aesugpng

Cookies@xkrlgjxn Sat, 30 January 1999 15:47 UTC

Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA28821 for <smime-archive@odin.ietf.org>; Sat, 30 Jan 1999 10:47:44 -0500 (EST)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA16359 for ietf-smime-bks; Sat, 30 Jan 1999 07:05:25 -0800 (PST)
Received: from vhquify.World (11.middletown-04.va.dial-access.att.net [12.68.16.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA16355 for <ietf-smime@imc.org>; Sat, 30 Jan 1999 07:05:20 -0800 (PST)
Content-Type: text/html; charset="iso-8859-1"
To: Futures@pnhpuqua.cutters
From: Cookies@xkrlgjxn
Reply-To: sales@tmreed.com
Message-ID: <hqhpxkit.uosxbkusxtpd@vhquify.World>
Subject: This DUMB LITTLE AD will put $200 in your pocket every day!!! -aesugpng
Date: Sat, 30 Jan 1999 10:09:21 -0500
Sender: owner-ietf-smime@imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

This in compliance with the laws set forth by the 105th congress concerning commerical Emails and CAN NOT be called "spam" To be removed simply reply with "remove "as the subject and you will never hear from me again. This is a one time mailing. Thanks.

This little cookie cutter spits out $20 checks...

It's a 3-part automated system, consisting of a KILLER classified ad...a powerful one page sales letter, delivered by auto responder. And a QUALITY product, delivered to your customer by the company. You can set up today...and actually be getting checks mailed to you tomorrow. For complete details, send a blank email to: mailto: cookiecutter16@smartbot.net Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA16359 for ietf-smime-bks; Sat, 30 Jan 1999 07:05:25 -0800 (PST) Received: from vhquify.World (11.middletown-04.va.dial-access.att.net [12.68.16.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA16355 for ; Sat, 30 Jan 1999 07:05:20 -0800 (PST) Content-Type: text/html; charset="iso-8859-1" To: Futures@pnhpuqua.cutters From: Cookies@xkrlgjxn Reply-To: sales@tmreed.com Message-ID: Subject: This DUMB LITTLE AD will put $200 in your pocket every day!!! -aesugpng Date: Sat, 30 Jan 1999 10:09:21 -0500 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This in compliance with the laws set forth by the 105th congress concerning commerical Emails and CAN NOT be called "spam" To be removed simply reply with "remove "as the subject and you will never hear from me again. This is a one time mailing. Thanks.

This little cookie cutter spits out $20 checks...

It's a 3-part automated system, consisting of a KILLER classified ad...a powerful one page sales letter, delivered by auto responder. And a QUALITY product, delivered to your customer by the company. You can set up today...and actually be getting checks mailed to you tomorrow. For complete details, send a blank email to: mailto: cookiecutter16@smartbot.net Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA18231 for ietf-smime-bks; Fri, 29 Jan 1999 16:11:51 -0800 (PST) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA18227 for ; Fri, 29 Jan 1999 16:11:49 -0800 (PST) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Fri, 29 Jan 99 16:14:02 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Fri, 29 Jan 1999 16:14:02 -0800 Message-ID: <01FF24001403D011AD7B00A024BC53C563DD56@mail.deming.com> From: "Blake Ramsdell" To: "'Jim Schaad (Exchange)'" , "'jsp@jgvandyke.com'" , "Ietf-Smime (E-mail)" Subject: RE: Last Call comments on the Message And Certificate Drafts Date: Fri, 29 Jan 1999 16:14:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1AAC914026235-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > -----Original Message----- > From: Jim Schaad (Exchange) [mailto:jimsch@EXCHANGE.MICROSOFT.com] > Sent: Friday, January 29, 1999 4:03 PM > To: 'jsp@jgvandyke.com'; Ietf-Smime (E-mail) > Subject: RE: Last Call comments on the Message And Certificate Drafts > > After re-reading this, I think John is probably correct. I'll buy it. Please let the "absolutely-last-call-I'm-not-kidding-don't-mess-with-me" changes list reflect this change. Blake -- Blake C. Ramsdell Worldtalk Corporation For current info, check http://www.deming.com/users/blaker Voice +1 425 882 8861 x103 Fax +1 425 882 8060 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA17899 for ietf-smime-bks; Fri, 29 Jan 1999 16:00:29 -0800 (PST) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA17895 for ; Fri, 29 Jan 1999 16:00:28 -0800 (PST) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Fri, 29 Jan 1999 16:02:51 -0800 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5C7B@DINO> From: "Jim Schaad (Exchange)" To: "'jsp@jgvandyke.com'" , "Ietf-Smime (E-mail)" Subject: RE: Last Call comments on the Message And Certificate Drafts Date: Fri, 29 Jan 1999 16:02:41 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: After re-reading this, I think John is probably correct. jim -----Original Message----- From: jsp@jgvandyke.com [mailto:jsp@jgvandyke.com] Sent: Friday, January 29, 1999 3:06 PM To: Ietf-Smime (E-mail) Subject: RE: Last Call comments on the Message And Certificate Drafts All, I respectfully disagree with Jim and Blake regarding the attached message exchange. The intent of the Cert I-D is to specify cert processing requirements in addition to those defined in PKIX I. IMHO, the last sentence in the first para in Section 1 should be changed to state: "S/MIME agents MUST meet the certificate processing requirements documented in this I-D in addition to those stated in [KEYM]." - John Pawling At 10:18 AM 1/14/99 -0800, Blake Ramsdell wrote: >> -----Original Message----- >> From: Jim Schaad (Exchange) [mailto:jimsch@EXCHANGE.MICROSOFT.com] >> Sent: Saturday, January 09, 1999 3:48 PM >> To: Ietf-Smime (E-mail); Blake Ramsdell >> Cc: Russ Housley (E-mail) >> Subject: Last Call comments on the Message And Certificate Drafts >> 1. Section 1 - Reference to KEYM in the last sentence of >> paragraph #1 is >> almost certianly meant to be a reference to SMIME-MSG > >Hmm. I'll buy that. Agree. > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA17228 for ietf-smime-bks; Fri, 29 Jan 1999 15:00:45 -0800 (PST) Received: from apollo.jgvandyke.com (apollo.jgvandyke.com [158.189.10.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA17224 for ; Fri, 29 Jan 1999 15:00:43 -0800 (PST) Received: from ajsn101.jgvandyke.com (ajsn101.jgvandyke.com [158.189.2.101]) by apollo.jgvandyke.com (8.8.8/8.8.8) with SMTP id SAA15209 for ; Fri, 29 Jan 1999 18:08:46 -0500 (EST) Received: from ajpc81 by ajsn101.jgvandyke.com (SMI-8.6/SMI-SVR4) id SAA10775; Fri, 29 Jan 1999 18:06:25 -0500 Date: Fri, 29 Jan 1999 18:06:25 -0500 Message-Id: <199901292306.SAA10775@ajsn101.jgvandyke.com> X-Sender: jsp@ajsn101 X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Ietf-Smime (E-mail)" From: jsp@jgvandyke.com (John Pawling) Subject: RE: Last Call comments on the Message And Certificate Drafts Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: All, I respectfully disagree with Jim and Blake regarding the attached message exchange. The intent of the Cert I-D is to specify cert processing requirements in addition to those defined in PKIX I. IMHO, the last sentence in the first para in Section 1 should be changed to state: "S/MIME agents MUST meet the certificate processing requirements documented in this I-D in addition to those stated in [KEYM]." - John Pawling At 10:18 AM 1/14/99 -0800, Blake Ramsdell wrote: >> -----Original Message----- >> From: Jim Schaad (Exchange) [mailto:jimsch@EXCHANGE.MICROSOFT.com] >> Sent: Saturday, January 09, 1999 3:48 PM >> To: Ietf-Smime (E-mail); Blake Ramsdell >> Cc: Russ Housley (E-mail) >> Subject: Last Call comments on the Message And Certificate Drafts >> 1. Section 1 - Reference to KEYM in the last sentence of >> paragraph #1 is >> almost certianly meant to be a reference to SMIME-MSG > >Hmm. I'll buy that. Agree. > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16910 for ietf-smime-bks; Fri, 29 Jan 1999 14:26:21 -0800 (PST) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA16906; Fri, 29 Jan 1999 14:26:19 -0800 (PST) Message-Id: <4.1.19990129142658.02693860@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 29 Jan 1999 14:27:55 -0800 To: Russ Housley , ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Re: RFC 2026, Section 10 In-Reply-To: <4.1.19990129161940.0099d970@209.172.119.123> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 04:25 PM 1/29/99 -0500, Russ Housley wrote: >Does anyone disagree? I certainly don't. It's up to the author of a draft. And, if anyone creates a draft that they don't put the permissive wording in, I'm not likely to help them with it. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16823 for ietf-smime-bks; Fri, 29 Jan 1999 14:16:33 -0800 (PST) Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA16819 for ; Fri, 29 Jan 1999 14:16:32 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA09223; Fri, 29 Jan 1999 17:19:07 -0500 Message-Id: <4.1.19990129171622.009994c0@209.172.119.123> X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 29 Jan 1999 17:17:05 -0500 To: EKR From: Russ Housley Subject: Re: KEKRecpientInfo KEKIdentifier Cc: pgut001@cs.aucKland.ac.nz, ietf-smime@imc.org In-Reply-To: References: <91762331427468@cs26.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: What do others think? I am unwilling to make it optional without a change to MSG that mandates it for S/MIME. Russ At 08:58 AM 1/29/99 -0800, EKR wrote: >pgut001@cs.aucKland.ac.nz (Peter Gutmann) writes: >> almost never be used in the way you've described. PGP has worked just fine >> for 8 years without a KEKIdentifier, so I don't see why CMS needs to make it >> mandatory. All you need to do is use "kekid [ 0 ] KEKIdentifier OPTIONAL" >and >> you can let the users decide whether it really is essential or not - I'm not >> asking that it be removed, simply that it be made optional so you can >leave it >> out where there's nothing to put in a KEKIdentifier. >I've got to go with Peter here. While I think that for messaging, >the index is more useful, I don't see any harm in making it optional. >We can always make MSG require it. > >-Ekr > > >-- >[Eric Rescorla ekr@rtfm.com] Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA16816 for ietf-smime-bks; Fri, 29 Jan 1999 14:16:29 -0800 (PST) Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA16812 for ; Fri, 29 Jan 1999 14:16:28 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA09214; Fri, 29 Jan 1999 17:19:04 -0500 Message-Id: <4.1.19990129171253.00976a80@209.172.119.123> X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 29 Jan 1999 17:15:51 -0500 To: pgut001@cs.aucKland.ac.nz From: Russ Housley Subject: Re: KEKRecpientInfo KEKIdentifier Cc: ietf-smime@imc.org In-Reply-To: <91762331427468@cs26.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Peter: In file encryption, you might want to put something here to clue the user about which key. For example, "The key Fred and Johnny picked on New Year's Day". In the file encryption application, I would hope that more than on KEK would be used. If you agree, then the syntax needs a way to identify which one. Remember this used to be called mail list keys.... Russ At 04:21 AM 1/30/99 +0000, Peter Gutmann wrote: >>The idea is that the KEK is distributed out of band and cached by the >>recipient(s). The KEKIdentifier is intended to be an index into the cache. > >OK, this is one possible hypothetical situation in which a KEKIdentifier would >be useful. However (as has been pointed out in other debates on this list), >CMS is meant to be a Cryptographic Message Syntax, not (in this case) a >CachedpreviouslyagreedonKEK Message Syntax. Of the many ways in which it's >possible to use a KEK, the KEKIdentifier applies to only one very specific, >very special-case use. Requiring that this field be present for every >imaginable use and application of a KEK doesn't make any sense, because in >many applications there's absolutely no use for it. > >As I mentioned in my previous message, the most common use for a KEK would be >for file encryption. I'm basing this claim on several years of reading >alt.security.pgp, in which almost the only use I've ever seen for PGP's -c >conventional encryption option (equivalent to the CMS KEKRecpientInfo) is for >file encryption. You've mentioned one theoretical possibility in which a >KEKIdentifier would be useful, but that isn't a reason to force its use in >every instance, especially when experience (it's use in PGP) shows that it'll >almost never be used in the way you've described. PGP has worked just fine >for 8 years without a KEKIdentifier, so I don't see why CMS needs to make it >mandatory. All you need to do is use "kekid [ 0 ] KEKIdentifier OPTIONAL" and >you can let the users decide whether it really is essential or not - I'm not >asking that it be removed, simply that it be made optional so you can leave it >out where there's nothing to put in a KEKIdentifier. > >(Minor nit: Since KEKRecipientInfo is still changing, could the version be > reset to 0 or 1 to go with the other CMS RecipientInfo types? There's no > real backwards compatibility problem because the format has changed in the > last few versions anyway, and it'll avoid having this odd artificially-high > version number for one particular RecipientInfo type). > >Peter. > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA16486 for ietf-smime-bks; Fri, 29 Jan 1999 13:32:48 -0800 (PST) Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA16482 for ; Fri, 29 Jan 1999 13:32:47 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id QAA07510 for ; Fri, 29 Jan 1999 16:35:26 -0500 Message-Id: <4.1.19990129161940.0099d970@209.172.119.123> X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 29 Jan 1999 16:25:18 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: RFC 2026, Section 10 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: All: Here is Section 10 of RFC 2026. It is my view that CMS should be labelled: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Does anyone disagree? Russ = = = = = = = = = = = 10. INTELLECTUAL PROPERTY RIGHTS 10.1. General Policy In all matters of intellectual property rights and procedures, the intention is to benefit the Internet community and the public at large, while respecting the legitimate rights of others. 10.2 Confidentiality Obligations No contribution that is subject to any requirement of confidentiality or any restriction on its dissemination may be considered in any part of the Internet Standards Process, and there must be no assumption of any confidentiality obligation with respect to any such contribution. 10.3. Rights and Permissions In the course of standards work, the IETF receives contributions in various forms and from many persons. To best facilitate the dissemination of these contributions, it is necessary to understand any intellectual property rights (IPR) relating to the contributions. 10.3.1. All Contributions By submission of a contribution, each person actually submitting the contribution is deemed to agree to the following terms and conditions on his own behalf, on behalf of the organization (if any) he represents and on behalf of the owners of any propriety rights in the contribution.. Where a submission identifies contributors in addition to the contributor(s) who provide the actual submission, the actual submitter(s) represent that each other named contributor was made aware of and agreed to accept the same terms and conditions on his own behalf, on behalf of any organization he may represent and any known owner of any proprietary rights in the contribution. l. Some works (e.g. works of the U.S. Government) are not subject to copyright. However, to the extent that the submission is or may be subject to copyright, the contributor, the organization he represents (if any) and the owners of any proprietary rights in the contribution, grant an unlimited perpetual, non-exclusive, royalty-free, world-wide right and license to the ISOC and the IETF under any copyrights in the contribution. This license includes the right to copy, publish and distribute the contribution in any way, and to prepare derivative works that are based on or incorporate all or part of the contribution, the license to such derivative works to be of the same scope as the license of the original contribution. 2. The contributor acknowledges that the ISOC and IETF have no duty to publish or otherwise use or disseminate any contribution. 3. The contributor grants permission to reference the name(s) and address(es) of the contributor(s) and of the organization(s) he represents (if any). 4. The contributor represents that contribution properly acknowledge major contributors. 5. The contribuitor, the organization (if any) he represents and the owners of any proprietary rights in the contribution, agree that no information in the contribution is confidential and that the ISOC and its affiliated organizations may freely disclose any information in the contribution. 6. The contributor represents that he has disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the contributor. The contributor does not represent that he personally knows of all potentially pertinent proprietary and intellectual property rights owned or claimed by the organization he represents (if any) or third parties. 7. The contributor represents that there are no limits to the contributor's ability to make the grants acknowledgments and agreements above that are reasonably and personally known to the contributor. By ratifying this description of the IETF process the Internet Society warrants that it will not inhibit the traditional open and free access to IETF documents for which license and right have been assigned according to the procedures set forth in this section, including Internet-Drafts and RFCs. This warrant is perpetual and will not be revoked by the Internet Society or its successors or assigns. 10.3.2. Standards Track Documents (A) Where any patents, patent applications, or other proprietary rights are known, or claimed, with respect to any specification on the standards track, and brought to the attention of the IESG, the IESG shall not advance the specification without including in the document a note indicating the existence of such rights, or claimed rights. Where implementations are required before advancement of a specification, only implementations that have, by statement of the implementors, taken adequate steps to comply with any such rights, or claimed rights, shall be considered for the purpose of showing the adequacy of the specification. (B) The IESG disclaims any responsibility for identifying the existence of or for evaluating the applicability of any claimed copyrights, patents, patent applications, or other rights in the fulfilling of the its obligations under (A), and will take no position on the validity or scope of any such rights. (C) Where the IESG knows of rights, or claimed rights under (A), the IETF Executive Director shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the IESG of the relevant Internet standards track specification(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. The Working Group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the IETF Executive Director in this effort. The results of this procedure shall not affect advancement of a specification along the standards track, except that the IESG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the IETF Executive Director, and made available. The IESG may also direct that a summary of the results be included in any RFC published containing the specification. 10.3.3 Determination of Reasonable and Non-discriminatory Terms The IESG will not make any explicit determination that the assurance of reasonable and non-discriminatory terms for the use of a technology has been fulfilled in practice. It will instead use the normal requirements for the advancement of Internet Standards to verify that the terms for use are reasonable. If the two unrelated implementations of the specification that are required to advance from Proposed Standard to Draft Standard have been produced by different organizations or individuals or if the "significant implementation and successful operational experience" required to advance from Draft Standard to Standard has been achieved the assumption is that the terms must be reasonable and to some degree, non-discriminatory. This assumption may be challenged during the Last-Call period. 10.4. Notices (A) Standards track documents shall include the following notice: "The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat." (B) The IETF encourages all interested parties to bring to its attention, at the earliest possible time, the existence of any intellectual property rights pertaining to Internet Standards. For this purpose, each standards document shall include the following invitation: "The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director." (C) The following copyright notice and disclaimer shall be included in all ISOC standards-related documentation: "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." (D) Where the IESG is aware at the time of publication of proprietary rights claimed with respect to a standards track document, or the technology described or referenced therein, such document shall contain the following notice: "The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights." Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA15768 for ietf-smime-bks; Fri, 29 Jan 1999 11:54:04 -0800 (PST) Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA15764 for ; Fri, 29 Jan 1999 11:54:03 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id OAA03389 for ; Fri, 29 Jan 1999 14:56:46 -0500 Message-Id: <4.1.19990129145635.009c8db0@209.172.119.123> X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 29 Jan 1999 14:57:35 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Fwd: New I-D Boilerplate Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: All authors: Please take not of this new requirement for Internet-Draft submission. Russ >Greetings, > >I recently posted a message to the announcement list informing folks that >the I-D guidelines document has been updated, and that all I-D submissions >need to incorporate what's in guidelines. > >The specific change pertains to the first line of the boilerplate text: > >======================================================================= >All Internet-Drafts should begin with ONE of the following three >statements: > > This document is an Internet-Draft and is in full conformance > with all provisions of Section 10 of RFC2026. > > This document is an Internet-Draft and is in full conformance > with all provisions of Section 10 of RFC2026 except for the > right to produce derivative works. > > This document is an Internet-Draft and is NOT offered in > accordance with Section 10 of RFC2026, and will only exist as > an Internet-Draft. > > >Any submission which does not include one (and only one) of the above >three statements will be returned to the submitter. The IETF Secretariat >will NOT add this text. > > >======================================================================= > >I'm explicitly bringing this to your attention. You should be aware of the >requirement, and I expect most of you will want to check out which line is >used prior to accepting an document as a work ite of the WG. > > >Steve > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA14945 for ietf-smime-bks; Fri, 29 Jan 1999 10:48:16 -0800 (PST) Received: from 157.22.235.99 (mactivity.com [157.22.235.99]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA14938 for ; Fri, 29 Jan 1999 10:48:12 -0800 (PST) Message-Id: <199901291848.KAA14938@mail.proper.com> Received: from [157.22.235.107] by mactivity.com (AppleShare IP Mail Server 6.1) id 26905 via TCP with SMTP; Fri, 29 Jan 1999 10:51:58 -0800 X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Fri, 29 Jan 1999 10:51:46 -0800 Subject: ANN: The Internet Security Conference From: "Paul Kent" To: ietf-smime@imc.org Mime-version: 1.0 X-Priority: 3 Content-type: multipart/alternative; boundary="MS_Mac_OE_3000451906_542846_MIME_Part" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > THIS MESSAGE IS IN MIME FORMAT. Since your mail reader does not understand this format, some or all of this message may not be legible. --MS_Mac_OE_3000451906_542846_MIME_Part Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The Internet Security Conference Making the Internet a Safer Place for Electronic Information Assets April 19-23, 1999 * Fairmont Hotel * San Jose CA The 2nd presentation of The Internet Security Conference (TISC, http://tisc.corecom.com) will address the most pressing security issues confronting Internet-enabled organizations today. The most respected experts in nearly every field of security will gather in the Fairmont Hotel, San Jose to present a technical conference and exhibition, April 19-23, 1999. The TISC faculty of over 50 experts, including: * Fred Avolio, security, former product manager for TIS Gauntlet Internet Firewall * Dr. William Hancock, Chief Technology Officer, Network-1 * Charlie Kaufman, Security Architect for Lotus Notes, IBM * Dr. Stephen Kent, Chief Scientist, Information Security, BBN Technologies * Rik Farrow, Internet and UNIX Security consultant and author * Bob Moskowitz, Sr. technical director at the ICSA * Dr. Radia Perlman, Distinguished Engineer, Sun Microsystems * Marcus Ranum, firewall expert, CEO & Founder, Network Flight Recorder, * Dr. Ron Ross, Sr. computer scientist at the Information Technology Laboratory, NIST will join Network Computing Magazine's Technology Editors Dan Backman, Mike Fratto and Dave Willis in presenting workshops, seminars, and a two-day, 30 session Security Symposium. An Interoperability Lab and Vendor Exhibit will complement the education offered at TISC. The Interoperability Lab (http://tisc.corecom.com/lab99.html) will provide attendees an opportunity to witness individual product demonstrations, conducted by vendor *technical* staff. Attendees will see and participate in multi-vendor demonstrations of: * Network Attack, Penetration, and Intrusion Detection * IPSec/IKE and CA Interoperability * IPSec Configuration and Benchmarking * Policy-Based Security Management * Layered VPNs for Remote Access and Extranet Connectivity * Desktop and Internet Application Security * Authentication as an Enabler for Secure E-Commerce coordinated by Aventail, Core Competence, Ernst & Young and Network Computing Magazine. Entrance to the TISC Interoperability Lab is free to all TISC '99 attendees. TISC workshop students will receive a guided walking tour of security technologies on display in the lab A complete program guide is available at http://tisc.corecom.com/programguide.pdf Registration is now open, visit https://secure.mactivity.com/tisc/register.html or call 1-800-798-2928. Space is Limited. The Internet Security Conference is presented by Core Competence, the respected internetworking, fast packet and network management consulting firm founded by Dave Piscitello, and Network Computing, the premier technology solutions magazine. Conference Sponsors include * Compatible Systems * Checkpoint Software Technologies * Ernst & Young * Microsoft * Aventail * RadGuard * Internet Devices * NetScreen * 3Com * enCommerce * RedCreek * RSA Data Security * TimeStep * Xedia * Network Flight Recorder * Covad Communications * Axent Technologies * Kroll-O'Gara ISG* Exodus * Xcert * Network-1 * Internet Week and NEC (Visit http://tisc.corecom.com/sponsors.html for new additions to this list.) --MS_Mac_OE_3000451906_542846_MIME_Part Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable ANN: The Internet Security Conference The Internet Security Conference
Making the Internet a Safer Place for Electronic Information Assets
April 19-23, 1999 * Fairmont Hotel * San Jose CA


The 2nd presentation of The Internet Security Conference (TISC,
http://tisc.corecom.com) will address t= he most pressing security
issues confronting Internet-enabled organizations today.

The most respected experts in nearly every field of security will gather in=
the Fairmont Hotel, San Jose to present a technical conference and exhibiti= on, April
19-23, 1999.

The TISC faculty of over 50 experts, including:

* Fred Avolio, security, former product manager for TIS Gauntlet Internet    Firewall
* Dr. William Hancock, Chief Technology Officer, Network-1
* Charlie Kaufman, Security Architect for Lotus Notes, IBM
* Dr. Stephen Kent, Chief Scientist, Information Security, BBN Technologies=
* Rik Farrow, Internet and UNIX Security consultant and author
* Bob Moskowitz, Sr. technical director at the ICSA
* Dr. Radia Perlman, Distinguished Engineer, Sun Microsystems
* Marcus Ranum, firewall expert, CEO & Founder, Network Flight Recorder= ,  
* Dr. Ron Ross, Sr. computer scientist at the Information Technology
Laboratory, NIST

will join Network Computing Magazine's Technology Editors Dan Backman, Mike=
Fratto and Dave Willis in presenting workshops, seminars, and a two-day, 30=
session Security Symposium.

An Interoperability Lab and Vendor Exhibit will complement the education
offered at TISC. The Interoperability Lab (http://= tisc.corecom.com/lab99.html)
will provide attendees  an opportunity to witness individual product d= emonstrations,
conducted by vendor *technical* staff. Attendees will see and participate i= n multi-vendor
demonstrations of:

* Network Attack, Penetration, and Intrusion Detection
* IPSec/IKE and CA Interoperability
* IPSec Configuration and Benchmarking
* Policy-Based Security Management
* Layered VPNs for Remote Access and Extranet Connectivity
* Desktop and Internet Application Security
* Authentication as an Enabler for Secure E-Commerce

coordinated by Aventail, Core Competence, Ernst & Young and Network
Computing Magazine.

Entrance to the TISC Interoperability Lab is free to all TISC '99 attendees= .

TISC workshop students will receive a guided walking tour of security
technologies on display in the lab

A complete program guide is available at
http://tisc.corecom.com/programguide.pdf

Registration is now open, visit
https://secure.mactivity.com/tisc/register.html
or call 1-800-798-2928. Space is Limited.

The Internet Security Conference is presented by Core Competence, the
respected internetworking, fast packet and network management consulting fi= rm founded
by Dave Piscitello, and  Network Computing,  the premier technolo= gy solutions
magazine.

Conference Sponsors include
* Compatible Systems * Checkpoint Software Technologies * Ernst & Young= * Microsoft
* Aventail * RadGuard * Internet Devices * NetScreen * 3Com * enCommerce * = RedCreek
* RSA Data Security * TimeStep * Xedia * Network Flight Recorder * Covad Co= mmunications
* Axent Technologies * Kroll-O'Gara ISG* Exodus * Xcert * Network-1 * Inter= net Week and NEC

(Visit http://tisc.corecom.com/sponsors.html= FONT> for new additions to this
list.)
--MS_Mac_OE_3000451906_542846_MIME_Part-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA13504 for ietf-smime-bks; Fri, 29 Jan 1999 08:55:02 -0800 (PST) Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA13500 for ; Fri, 29 Jan 1999 08:55:02 -0800 (PST) Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id IAA02838; Fri, 29 Jan 1999 08:58:25 -0800 (PST) To: pgut001@cs.aucKland.ac.nz Cc: housley@spyrus.com, ietf-smime@imc.org Subject: Re: KEKRecpientInfo KEKIdentifier References: <91762331427468@cs26.cs.auckland.ac.nz> From: EKR Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 29 Jan 1999 08:58:24 -0800 In-Reply-To: pgut001@cs.aucKland.ac.nz's message of "Sat, 30 Jan 1999 04:21:54 (NZDT)" Message-ID: Lines: 16 X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: pgut001@cs.aucKland.ac.nz (Peter Gutmann) writes: > almost never be used in the way you've described. PGP has worked just fine > for 8 years without a KEKIdentifier, so I don't see why CMS needs to make it > mandatory. All you need to do is use "kekid [ 0 ] KEKIdentifier OPTIONAL" and > you can let the users decide whether it really is essential or not - I'm not > asking that it be removed, simply that it be made optional so you can leave it > out where there's nothing to put in a KEKIdentifier. I've got to go with Peter here. While I think that for messaging, the index is more useful, I don't see any harm in making it optional. We can always make MSG require it. -Ekr -- [Eric Rescorla ekr@rtfm.com] Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA12310 for ietf-smime-bks; Fri, 29 Jan 1999 07:19:31 -0800 (PST) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA12306 for ; Fri, 29 Jan 1999 07:19:27 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id EAA29912; Sat, 30 Jan 1999 04:21:55 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91762331427468>; Sat, 30 Jan 1999 04:21:54 (NZDT) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: housley@spyrus.com, ietf-smime@imc.org Subject: Re: KEKRecpientInfo KEKIdentifier Reply-To: pgut001@cs.aucKland.ac.nz X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Sat, 30 Jan 1999 04:21:54 (NZDT) Message-ID: <91762331427468@cs26.cs.auckland.ac.nz> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >The idea is that the KEK is distributed out of band and cached by the >recipient(s). The KEKIdentifier is intended to be an index into the cache. OK, this is one possible hypothetical situation in which a KEKIdentifier would be useful. However (as has been pointed out in other debates on this list), CMS is meant to be a Cryptographic Message Syntax, not (in this case) a CachedpreviouslyagreedonKEK Message Syntax. Of the many ways in which it's possible to use a KEK, the KEKIdentifier applies to only one very specific, very special-case use. Requiring that this field be present for every imaginable use and application of a KEK doesn't make any sense, because in many applications there's absolutely no use for it. As I mentioned in my previous message, the most common use for a KEK would be for file encryption. I'm basing this claim on several years of reading alt.security.pgp, in which almost the only use I've ever seen for PGP's -c conventional encryption option (equivalent to the CMS KEKRecpientInfo) is for file encryption. You've mentioned one theoretical possibility in which a KEKIdentifier would be useful, but that isn't a reason to force its use in every instance, especially when experience (it's use in PGP) shows that it'll almost never be used in the way you've described. PGP has worked just fine for 8 years without a KEKIdentifier, so I don't see why CMS needs to make it mandatory. All you need to do is use "kekid [ 0 ] KEKIdentifier OPTIONAL" and you can let the users decide whether it really is essential or not - I'm not asking that it be removed, simply that it be made optional so you can leave it out where there's nothing to put in a KEKIdentifier. (Minor nit: Since KEKRecipientInfo is still changing, could the version be reset to 0 or 1 to go with the other CMS RecipientInfo types? There's no real backwards compatibility problem because the format has changed in the last few versions anyway, and it'll avoid having this odd artificially-high version number for one particular RecipientInfo type). Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA05975 for ietf-smime-bks; Thu, 28 Jan 1999 16:25:31 -0800 (PST) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id QAA05970 for ; Thu, 28 Jan 1999 16:25:30 -0800 (PST) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Thu, 28 Jan 99 16:27:36 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Thu, 28 Jan 1999 16:27:36 -0800 Message-ID: <01FF24001403D011AD7B00A024BC53C563DD40@mail.deming.com> From: "Blake Ramsdell" To: "'ietf-smime@imc.org'" Subject: RE: CERT changes in IETF last call -- please review Date: Thu, 28 Jan 1999 16:27:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1AAFDFF217465-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > -----Original Message----- > From: Blake Ramsdell > Sent: Thursday, January 28, 1999 3:59 PM > To: 'ietf-smime@imc.org' > Subject: CERT changes in IETF last call -- please review > > These are the changes that I am making in MSG-07 that were > requested during > IETF last call. Uh, I mean CERT-07 if you didn't already figure that out. Blake -- Blake C. Ramsdell Worldtalk Corporation For current info, check http://www.deming.com/users/blaker Voice +1 425 882 8861 x103 Fax +1 425 882 8060 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA05597 for ietf-smime-bks; Thu, 28 Jan 1999 15:56:47 -0800 (PST) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA05593 for ; Thu, 28 Jan 1999 15:56:46 -0800 (PST) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Thu, 28 Jan 99 15:58:55 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Thu, 28 Jan 1999 15:58:55 -0800 Message-ID: <01FF24001403D011AD7B00A024BC53C563DD3F@mail.deming.com> From: "Blake Ramsdell" To: "'ietf-smime@imc.org'" Subject: CERT changes in IETF last call -- please review Date: Thu, 28 Jan 1999 15:58:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1AAE263517253-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: These are the changes that I am making in MSG-07 that were requested during IETF last call. Let me know if I missed anything. Changes from draft-ietf-smime-cert-06 to draft-ietf-smime-cert-07: Changed "I-D" to "document" in section 1 (Russ Housley) Added clarification to section 3.1 regarding emailAddress attribute from PKCS #9 (Russ Housley) Redid 4.4.2.1 regarding Diffie-Hellman to clarify "doneness" (Russ Housley) Clarified 4.4 regarding certificate extensions and profiling efforts (Russ Housley) Clarified 2.3 regarding DSA parameters being scattered all over the certificate chain, necessitating the transmission of the root certificate (Jim Schaad) Clarified 4.4.1 regarding basic constraints in end entity certificates (Jim Schaad) Changed an errant reference to [KEYM] to [SMIME-MSG] (Jim Schaad) Removed certificate request language from section 1 (Jim Schaad) Removed [CRMF] reference from section A (Jim Schaad) Added reference to PKCS #1 v2 and DSS for signature algorithms in section 4.3 (Jim Schaad) Fixed some language in 4.4 regarding syntax and semantics of extensions are defined in [KEYM] (Jim Schaad) Blake -- Blake C. Ramsdell Worldtalk Corporation For current info, check http://www.deming.com/users/blaker Voice +1 425 882 8861 x103 Fax +1 425 882 8060 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA04436 for ietf-smime-bks; Thu, 28 Jan 1999 14:02:02 -0800 (PST) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA04432 for ; Thu, 28 Jan 1999 14:02:01 -0800 (PST) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Thu, 28 Jan 99 14:04:09 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Thu, 28 Jan 1999 14:04:09 -0800 Message-ID: <01FF24001403D011AD7B00A024BC53C563DD3C@mail.deming.com> From: "Blake Ramsdell" To: "'Francois Rousseau'" , "William Whyte" cc: Subject: RE: x9.42 and CMS Date: Thu, 28 Jan 1999 14:04:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1AAE015316031-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > -----Original Message----- > From: Francois Rousseau [mailto:f.rousseau@adga.ca] > Sent: Thursday, January 28, 1999 1:25 PM > To: William Whyte > Cc: ietf-smime@imc.org > Subject: Re: x9.42 and CMS > > However, I still think that none of the S/MIME standards > should be bound in > any way to SHA-1, although SHA-1 can still be the recommended standard > specified in [MSG] for interoperability at this time. I think that the case that you illustrated (the use of SHA-1 for creation of the cert ID) is different than this one. I agree with Jim that the OID can be changed, which solves that problem. I think we should be more concerned with William's case, however. The OID that we tie to this whole process of Diffie Hellman "stuff" is dhpublicnumber which is placed in certificates. If SHA-1 has a problem, we can't go back and change the OID in the previously issued certificates. Blake -- Blake C. Ramsdell Worldtalk Corporation For current info, check http://www.deming.com/users/blaker Voice +1 425 882 8861 x103 Fax +1 425 882 8060 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA04081 for ietf-smime-bks; Thu, 28 Jan 1999 13:22:47 -0800 (PST) Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA04077 for ; Thu, 28 Jan 1999 13:22:37 -0800 (PST) Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id QAA13701; Thu, 28 Jan 1999 16:22:56 -0500 (EST) Message-Id: <3.0.1.32.19990128162453.009c7280@adga.ca> X-Sender: frousseau@adga.ca X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 28 Jan 1999 16:24:53 -0500 To: William Whyte From: Francois Rousseau Subject: Re: x9.42 and CMS Cc: ietf-smime@imc.org In-Reply-To: <01BE4ADB.207C1A90.wwhyte@baltimore.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Bill, I had made similar comments before about "ESSCertID" in ESS-09 and "SMimeEncryptionCert" in CERTDIST-02, since in both cases "certHash" mandates the use of SHA-1 only. The reply I received from Jim Schaad for ESS-09 at the time was: "There are currently a large number of items which are assuming that SHA-1 will not ever be effectively broken. This is just another of those items. If SHA-1 ever does get broken then the algorithm here can be updated by creating a new OID to define a new version of ESSCertID. The problem with making it flexible is that you then need to start stating which algorithms can and cannot be used leading to the same problem of a new draft when SHA-1 is broken anyway." However, I still think that none of the S/MIME standards should be bound in any way to SHA-1, although SHA-1 can still be the recommended standard specified in [MSG] for interoperability at this time. Francois Rousseau AEPOS Technologies >Sorry only to be bringing this up at the Last Call stage, but I >don't have any record of it being discussed before. > >I'm concerned that the draft-ietf-smime-x942-04 document does not >provide for the use of any hash algorithm other than SHA-1 when deriving >the key from the shared secret. X9.42 provides the KeyDerivationHash >AlgorithmIdentifier. Would it be possible to change the >KeyAgreeRecipientInfo ASN.1 to read (apologies for poor ASN.1 style): > >KeyAgreeRecipientInfo ::= SEQUENCE { > version CMSVersion, -- always set to 3 > originator [0] EXPLICIT OriginatorIdentifierOrKey, > ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, > keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, > keyDerivationHash KeyDerivationHashAlgorithmIdentifier > DEFAULT sha1Identifier, > recipientEncryptedKeys RecipientEncryptedKeys } > >We would then change section 2.1.2 of the draft-ietf-smime-x942-04 >document so that the line > H is the message digest function SHA-1 [FIPS-180] >becomes > H is a message digest function. In [CMS], the message digest function > is identified by the keyDerivationHash field of the KeyAgreeRecipientInfo > if this is present, and is SHA-1 if this field is absent. > >Again, my apologies if it's too late to be bringing up this kind of point. > >Cheers, > >William > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA02993 for ietf-smime-bks; Thu, 28 Jan 1999 11:50:28 -0800 (PST) Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02986 for ; Thu, 28 Jan 1999 11:50:24 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id OAA28521 for ; Thu, 28 Jan 1999 14:53:02 -0500 Message-Id: <4.1.19990128144545.009e2250@209.172.119.123> X-Sender: rhousley#mail.spyrus.com@209.172.119.123 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 28 Jan 1999 14:46:48 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Comments on CMS from Burt Kaliski Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Significant issues are raised in Burt Kaliski's note. Russ >From: Burt Kaliski >To: "'housley@spyrus.com'" >Cc: "Linn, John" >Subject: Comments on CMS >Date: Mon, 25 Jan 1999 13:53:00 -0800 >X-Mailer: Internet Mail Service (5.5.2232.9) > >Dear Russ -- > >Here are some comments on >http://search.ietf.org/internet-drafts/draft-ietf-smime-cms-10.txt. Feel >free to forward this to the S/MIME discussion list. > >> Some general points: >> >> * RFC 2437 can now be referenced rather than RFC 2313 for PKCS #1. As a >> result Section 12.2.2 no longer needs to give the SHA-1 extension to PKCS >> #1 RSA signatures, as it's supported by RFC 2437. >> >> * Section 12.3.2.1 should be more explicit about how RSA encryption is >> employed for key wrapping (i.e., that the message to be encrypted with >> RSAES-PKCS1-v1_5 is the key). It should also state whether parity changes >> are required on DES keys, similar to Section 12.6.2. >> >> * It would be helpful to state in step 1 of Section 12.6.2 what parity >> setting is assumed for DES. Is it necessary to set parity? This is not >> required when wrapping a DES key with an RSA key. >> >> Regarding the key wrapping algorithm itself, one problem I see is that the >> parts of the CEK are encrypted essentially independently of each other. >> Although there is chaining through CBC mode, an opponent learns >> plaintext-ciphertext pairs for the underlying encryption algorithm. The >> opponent can thus detect collisions in the plaintext space. >> >> Specifically, consider what happens when wrapping a triple-DES CEK with >> some symmetric algorithm. There will be five blocks to be encrypted under >> a KEK with the symmetric algorithm. With chaining, this will be done as >> >> A = Encrypt (IV xor (salt || key<0..3>)) >> B = Encrypt (A xor key<4..11>) >> C = Encrypt (B xor key<12..19>) >> D = Encrypt (C xor (key<20..23> || keycheck<0..3>)) >> E = Encrypt (D xor (keycheck<4..7> || 04 04 04 04)) >> >> where key<0..23> is the triple-DES CEK and ABCDE is the wrapped CEK. An >> opponent will see ABCDE and knows IV. >> >Now suppose that many CEKs are wrapped with the same KEK. (The CEKs need not >be different.) With high probability, there will be a collision between >blocks of wrapped CEKs after about 2^32 encryptions. Let ABCDE and >A*B*C*D*E* be the two wrapped CEKs, let key and key* be the two CEKs, and >suppose A = E* (i.e., the first block of one wrapped CEK equals the last >block of the other wrapped CEK). Since Encrypt is a permutation, the >opponent knows that > >> IV xor (salt || key<0..3>) = D* xor (keycheck*<4..7> || 04 04 04 04) >> >> Although salt and keycheck* are unknown, the opponent can solve for >> key<0..3>: >> >> key<0..3> = IV<4..7> xor D*<4..7> xor 04 04 04 04 >> >> Through collisions in other blocks, the opponent can solve for other parts >> of CEKs and for the difference between parts of CEKs. If the same CEK is >> wrapped many times with the KEK, the opponent may gather enough >> information to solve for the entire CEK. If different CEKs are wrapped >> with the same KEK, an opponent may learn information about the >> relationship between the CEKs. If the opponent has somehow obtained one >> CEK encrypted with a KEK (perhaps by being a legitimate recipient of a >> message encrypted with that CEK), the opponent may then be able to solve >> for the other CEK. >> >The main problem is that all these attacks require only about 2^32 wrapped >CEKs, which is probably not enough for many applications, particularly given >the 2^112 security level intended by the use of triple-DES. > >> One way to avoid this problem is to limit the number of times a KEK can be >> employed so that the probability of collision remains small. However, in >> practice this can be burdensome. A partial solution is to make the padding >> random rather than 04 04 04 04, but this only addresses the first attack >> outlined above, not other attacks that find relationships between parts of >> CEKs. >> >> A potential improvement is an OAEP-like construction, where the CEK is >> formatted as in PKCS #1 EME-OAEP (section 9.1.1 of RFC 2437), then >> encrypted with the KEK. I suppose the key expansion would be larger in >> such an approach than in what is proposed in the Internet-Draft, but it >> would also build on the same formatting for wrapping with RSA keys, and >> avoid the attacks just described. The CEK parts would not be encrypted >> separately of one another, but as a whole, having been mixed together >> first with OAEP. >> >> -- Burt >> >> Burt Kaliski, Chief Scientist >> RSA Laboratories - http://www.rsa.com >> 20 Crosby Drive, Bedford, MA 01730 USA >> +1 781 687 7057; fax: +1 781 687 7213; burt@rsa.com >> Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01071 for ietf-smime-bks; Thu, 28 Jan 1999 08:25:17 -0800 (PST) Received: from puma.baltimore.ie (root@pc215-8.indigo.ie [194.125.215.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01067 for ; Thu, 28 Jan 1999 08:25:15 -0800 (PST) Received: from knuckle (knuckle.baltimore.ie [194.125.215.103]) by puma.baltimore.ie (8.8.5/8.8.5) with SMTP id QAA31163 for ; Thu, 28 Jan 1999 16:27:51 GMT Received: by localhost with Microsoft MAPI; Thu, 28 Jan 1999 16:27:41 -0000 Message-ID: <01BE4ADB.207C1A90.wwhyte@baltimore.ie> From: William Whyte To: "'ietf-smime@imc.org'" Subject: x9.42 and CMS Date: Thu, 28 Jan 1999 16:27:40 -0000 Organization: Baltimore Technologies X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Sorry only to be bringing this up at the Last Call stage, but I don't have any record of it being discussed before. I'm concerned that the draft-ietf-smime-x942-04 document does not provide for the use of any hash algorithm other than SHA-1 when deriving the key from the shared secret. X9.42 provides the KeyDerivationHash AlgorithmIdentifier. Would it be possible to change the KeyAgreeRecipientInfo ASN.1 to read (apologies for poor ASN.1 style): KeyAgreeRecipientInfo ::= SEQUENCE { version CMSVersion, -- always set to 3 originator [0] EXPLICIT OriginatorIdentifierOrKey, ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, keyDerivationHash KeyDerivationHashAlgorithmIdentifier DEFAULT sha1Identifier, recipientEncryptedKeys RecipientEncryptedKeys } We would then change section 2.1.2 of the draft-ietf-smime-x942-04 document so that the line H is the message digest function SHA-1 [FIPS-180] becomes H is a message digest function. In [CMS], the message digest function is identified by the keyDerivationHash field of the KeyAgreeRecipientInfo if this is present, and is SHA-1 if this field is absent. Again, my apologies if it's too late to be bringing up this kind of point. Cheers, William Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01064 for ietf-smime-bks; Thu, 28 Jan 1999 08:24:57 -0800 (PST) Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01060 for ; Thu, 28 Jan 1999 08:24:55 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id LAA19436; Thu, 28 Jan 1999 11:27:20 -0500 Message-Id: <4.1.19990127101943.0099ae60@209.172.119.123> Message-Id: <4.1.19990127101943.0099ae60@209.172.119.123> X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 27 Jan 1999 10:23:58 -0500 To: pgut001@cs.aucKland.ac.nz From: Russ Housley Subject: Re: KEKRecpientInfo KEKIdentifier Cc: ietf-smime@imc.org In-Reply-To: <91718720129757@cs26.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Peter: I do not agree. The idea is that the KEK is distributed out of band and cached by the recipient(s). The KEKIdentifier is intended to be an index into the cache. Russ At 03:13 AM 1/25/99 +0000, Peter Gutmann wrote: >The KEKIdentifier in the KEKRecipientInfo currently contains a mandatory OCTET >STRING which is supposed to contain some magic key ID, however in what I guess >would be the most common uses for KEK data encryption (either straight >file/data encryption or "Included below are last weeks sales figures encrypted >with the key we agreed on") there's no conceivable use for this value. Could >this be made optional like the other fields, or better yet could the whole >KEKIdentifier be made optional (since it'll be empty without the OCTET >STRING)? Either: > > ... > kekid [ 0 ] KEKIdentifier OPTIONAL, > ... > >(the preferred option) or alternatively: > >KEKidentifier ::= SEQUENCE { > keyIdentifier OCTET STRING OPTIONAL, > date GeneralizedTime OPTIONAL, > other [ 0 ] OtherKeyAttribute OPTIONAL > } > >The former would be nicer since the latter will lead to odd-looking empty >SEQUENCEs appearing in most KEKRecipientInfo's. > >A much uglier alternative is to use a zero-length OCTET STRING to denote "I >don't know what to do with this field", but that kind of defeats the point of >having it there in the first place since it's just a kludgy way of saying OCTET >STRING OPTIONAL. My preferred solution for this would be KEKIdentifier >OPTIONAL since it reduces the amount of clutter. > >Peter. > > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA01501 for ietf-smime-bks; Wed, 27 Jan 1999 20:25:22 -0800 (PST) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id UAA01489 for ; Wed, 27 Jan 1999 20:25:20 -0800 (PST) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Wed, 27 Jan 99 20:27:25 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Wed, 27 Jan 1999 20:27:25 -0800 Message-ID: <01FF24001403D011AD7B00A024BC53C563DD34@mail.deming.com> From: "Blake Ramsdell" To: "'ietf-smime@imc.org'" Subject: MSG changes in IETF last call -- please review Date: Wed, 27 Jan 1999 20:27:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1AB138A710714-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: These are the changes that I am making in MSG-07 that were requested during IETF last call. Let me know if I missed anything. Changes from draft-ietf-smime-msg-06 to draft-ietf-smime-msg-07: Clarified section 2.4.1 in the case of multipart/signed (eContent is absent in that case) (Jim Schaad) Removed receipt request attribute from section 2.5 (Jim Schaad) Capitalized MUST for use of the issuerAndSerialNumber CHOICE in section 2.6 (Jim Schaad) Capitalized NOT in section 3.2.1 regarding reliance on file extensions (Jim Schaad) Changed [DH] reference to refer to draft-ietf-smime-x942-*.txt (Jim Schaad) Replaced section A with ASN.1 module (Jim Schaad) Rewording of 2.7.3 to explain that the content of the strongly-encrypted message can be learned by decrypting the weaker message (Russ Housley) Provided example OID. string for new smime-type values in section 3.2.2 (Russ Housley) Rewording of section 5 regarding sending two messages with different levels of encryption (Russ Housley) Added [RANDOM] reference in section 4.1 and to section B (Russ Housley) Explained in section 2.5.2 that section A contains all of the MUST and SHOULD OIDs (Russ Housley) Blake -- Blake C. Ramsdell Worldtalk Corporation For current info, check http://www.deming.com/users/blaker Voice +1 425 882 8861 x103 Fax +1 425 882 8060 Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA12377 for ietf-smime-bks; Wed, 27 Jan 1999 01:32:21 -0800 (PST) Received: from barbar.esat.kuleuven.ac.be (root@barbar.esat.kuleuven.ac.be [134.58.56.153]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA12372 for ; Wed, 27 Jan 1999 01:32:18 -0800 (PST) Received: from domus.esat.kuleuven.ac.be (domus.esat.kuleuven.ac.be [134.58.189.68]) by barbar (version 8.8.5) with ESMTP id KAA13259; Wed, 27 Jan 1999 10:34:45 +0100 (MET) Organization: ESAT, K.U.Leuven, Belgium Date: Wed, 27 Jan 1999 10:34:45 +0100 (MET) From: "CMS'99" To: ietf-smime@imc.org Subject: CFP: Communications and Multimedia Security '99 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.proper.com id BAA12374 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: [Apologies if you receive this more than once.] ------------------------------------------------------------------------ International Federation for Information Processing CMS '99 Communications and Multimedia Security Joint working conference IFIP TC6 and TC11 September 20-21, 1999 Katholieke Universiteit Leuven, Belgium ------------------------------------------------------------------------ Call For Papers ------------------------------------------------------------------------ GOALS and TOPICS of INTEREST CMS '99 is the fourth in a series of international conferences which aim at reviewing state-of-the-art issues as well as practical experiences and new trends in the areas of communications and multimedia systems security. It is the intention of the organisers to focus the attention of the conference presentations and discussions on issues which combine innovative research work with a highly promising application potential. Topics of interest include, but are not limited to * communications systems security * mobile communications security * Internet, intranet and extranet security * security of mobile code * multimedia systems security * applied cryptography * electronic commerce and digital signatures * security in distributed systems * secure teleworking, telecooperation, telemedicine * legal, social and ethical aspects of communication systems security * standards for communication and multimedia systems security SUBMISSION DETAILS Authors are strongly encouraged to submit their papers electronically. Please email your submission in postscript (or pdf) format to: cms99@esat.kuleuven.ac.be Electronic submissions must be received by March 15, 1999, 23:00 GMT in order to be considered. Authors unable to submit electronically are invited to send a cover letter and 5 (five) copies of an anonymous paper (double-sided copies preferred) to the Program Chair at the postal address below. Submissions must be received by the Program Chair on or before March 15, 1999. The cover letter should contain the paper's title and the names and affiliations of the authors, and should identify the contact author including e-mail and postal addresses. Submissions must not substantially duplicate work that any of the authors have published elsewhere or have submitted in parallel to any other conference or workshop that has proceedings. The paper must be anonymous, with no author names, affiliations, acknowledgments, or obvious references. It should begin with a title, a short abstract, and a list of key words, and its introduction should summarise the contributions of the paper at a level appropriate for a non-specialist reader. The paper should be at most 5000 words long. A full page figure is 500 words. It is anticipated that the proceedings will be published by Kluwer Academic Publishers. Therefore authors are encouraged to use for their submissions the Kluwer IFIP templates for LaTeX or Word (see http://www.wkap.com/IFIP). All submitted papers will be refereed by at least three members of the International Program Committee according to the standard blind refereeing procedures. The Conference Proceedings will be published by an international publisher; copies of the proceedings will be available at the conference. Notification of acceptance or rejection will be sent to authors by April 30, 1999. Authors of accepted papers must guarantee that their paper will be presented at the conference. Important dates: * Submission Deadline: March 15, 1999 * Notification: April 30, 1999 * Final camera-ready version: May 21, 1999 * Conference: September 20-21, 1999 To submit a paper, or for further details, please contact: Prof. Bart Preneel, Program Committee Chair CMS'99 Katholieke Universiteit Leuven Dept. Electrical Engineering-ESAT/COSIC K. Mercierlaan 94, B-3001 Heverlee, BELGIUM Email: cms99@esat.kuleuven.ac.be Tel +32 16 32 10 50 Fax: +32 16 32 19 86 For further details see http://www.esat.kuleuven.ac.be/cosic/cms99/ Program Committee Chair: B. Preneel, Katholieke Universiteit Leuven, Belgium Program Committee: P. Ashley, Queensland University of Technology, Australia A. Casaca, Inesc, Portugal S. Fischer-Huebner, Hamburg University, Germany W. Fumy, Siemens Research, Germany D. Gollmann, Microsoft Research, UK D. Gritzalis, Athens University of Economics and Business, Greece P. Horster, University of Klagenfurt, Austria S. Katsikas, University of the Aegean, Greece L.R. Knudsen, University of Bergen, Norway C. Mitchell, Royal Holloway, University of London, UK D. Naccache, Gemplus, France R. Oppliger, BFI, Switzerland G. Pernul, University of Essen, Germany R. Posch, TU Graz, Austria G. Quirchmayr, University of Vienna, Austria J.-J. Quisquater, Université Catholique de Louvain, Belgium M. Reiter, Bell Labs, USA D. Tygar, University of California at Berkeley, USA P. van Oorschot, Entrust Technologies, Canada S.H. von Solms, Rand Afrikaans University, South Africa L. Yngstrom, Stockholm University and Royal Institute of Technology, Sweden L Strous, De Nederlandsche Bank NV, The Netherlands, advisory member Organising Committee Chair: J. Vandewalle, Katholieke Universiteit Leuven Organising Committee: Joris Claessens, Katholieke Universiteit Leuven Jorge Nakahara, Katholieke Universiteit Leuven Péla Noë, Katholieke Universiteit Leuven Vincent Rijmen, Katholieke Universiteit Leuven Mark Vandenwauver, Katholieke Universiteit Leuven Main Organiser: IFIP TC 11 and TC 6 ------------------------------------------------------------------------ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA18218 for ietf-smime-bks; Tue, 26 Jan 1999 14:20:31 -0800 (PST) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA18211 for ; Tue, 26 Jan 1999 14:20:29 -0800 (PST) Message-Id: <4.1.19990126135650.00c049e0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 26 Jan 1999 14:18:24 -0800 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: ESS changes in IETF last call -- please review Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Greetings again. There were a bunch of requests for changes to the ESS-10 draft in IETF last call (which ended yesterday). The following is the list of changes I intend to make in -11, which will then hopefully be sent by Jeff Schiller to the IESG. Blake and Russ will be sending out similar lists soon. If there are any issues that were posted to the list that I missed (or got wrong), please let me know in the next day or two. Please note that all of these were already discussed on the list, so new requests at this very late date might be frowned upon... D. Changes from draft-ietf-smime-ess-10 to draft-ietf-smime-ess-11 1: Added wording about signing certificates (Section 5) to the introduction. 1.3.4: Added the sentence at the end of the first paragraph. "All of the attributes defined in this document, other than ContentHints and ContentIdentifier, MUST be carried in a CMS SignedAttributes type, and MUST NOT be carried in an UnsignedAttributes or an UnprotectedAttributes type." 1.3.4: Removed the macValue description because it was removed from CMS. 1.4: Second paragraph, replaced second sentence to indicate that some attributes might have to be omitted. "The main disadvantage is that the gateway must check for the presence of certain attributes in the other signerInfos and either omit or copy those attributes." 2.1: Added paragraph at the end of this section saying that you shouldn't request that receipts be sent to people who don't have the original message. "A receipt request can indicate that receipts be sent to many places, not just to the sender (in fact, the receipt request might indicate that the receipts should not even go to the sender). In order to verify a receipt, the recipient of the receipt must be the originator or a recipient of the original message. Thus, the sender SHOULD NOT request that receipts be sent to anyone who does not have an exact copy of the message." 2.6: Added paragraph near beginning about accepting more than one signed receipt. "Although receipients are not supposed to send more than one signed receipt, receiving agents SHOULD be able to accept multiple signed receipts from a recipient." 2.8: Changed Version to ESSVersion and defined it as: ESSVersion ::= INTEGER { v1(1) } 3: Clarified the last paragraph to indicate ranked levels. "The labels often describe ranked levels..." 4.2.3.2: Clarified step 2 to show that, if the mlExpansionHistory was not found, you sign that whole message and stop. 4.4: Removed the comment "-- EntityIdentifier is imported from [CMS]" 5.1: Changed "changing" to "replacing". 5.4: The paragraph beginning "The first certificate..." was changed to reflect the addition of the SKI to the SignerInfo. "The first certificate identified in the sequence of certificate identifiers MUST be the certificate used to verify the signature. The encoding of the ESSCertID for this certificate SHOULD include the issuerSerial field. If other constraints ensure that issuerAndSerialNumber will be present in the SignerInfo, the issuerSerial field MAY be omitted. The certificate identified is used during the signature verification process. If the hash of the certificate does not match the certificate used to verify the signature, the signature MUST be considered invalid." 5.4.1: Changed "CMS" to "[CERT]" for the reference. 6: Entire section is new: ========== All security considerations from [CMS] and [SMIME3] apply to applications that use procedures described in this document. As stated in Section 2.3, a recipient of a receipt request must not send back a reply if it cannot validate the signature. Similarly, if there conflicting receipt requests in a message, the recipient must not send back receipts, since an attacker may have inserted the conflicting request. Sending a signed receipt to an unvalidated sender can expose information about the recipient that it may not want to expose to unknown senders. Senders of receipts should consider encrypting the receipts to prevent a passive attacker from gleaning information in the receipts. Senders must not rely on recipients' processing software to correctly process security labels. That is, the sender cannot assume that adding a security label to a message will prevent recipients from viewing messages the sender doesn't want them to view. It is expected that there will be many S/MIME clients that will not understand security labels but will still display a labelled message to a recipient. A receiving agent that processes security labels must handle the content of the messages carefully. If the agent decides not to show the message to the intended recipient after processing the security label, the agent must take care that the recipient does not accidentally see the content at a later time. For example, if an error response sent to the originator contains the content that was hidden from the recipient, and that error response bounces back to the sender due to addressing errors, the original recipient can possibly see the content since it is unlikely that the bounce message will have the proper security labels. A man-in-the-middle attack can cause a recipient to send receipts to an attacker if that attacker has a signature that can be validated by the recipient. The attack consists of intercepting the original message and adding a mLData attribute that says that a receipt should be sent to the attacker in addition to whoever else was going to get the receipt. Mailing lists that encrypt their content may be targets for denial-of-service attacks if they do not use the mailing list management described in Section 4. Using simple RFC822 header spoofing, it is quite easy to subscribe one encrypted mailing list to another, thereby setting up an infinite loop. Mailing List Agents need to be aware that they can be used as oracles for the the adaptive chosen ciphertext attack described in [CMS]. MLAs should notify an administrator if a large number of undecryptable messages are received. When verifying a signature using certificates that come with a [CMS] message, the recipient should only verify using certificates previously known to be valid, or certificates that have come from a signed SigningCertificate attribute. Otherwise, the attacks described in Section 5 can cause the receiver to possibly think a signature is valid when it is not. ========== --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA18303 for ietf-smime-bks; Sun, 24 Jan 1999 06:11:10 -0800 (PST) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA18299 for ; Sun, 24 Jan 1999 06:11:07 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id DAA03311 for ; Mon, 25 Jan 1999 03:13:21 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91718720129757>; Mon, 25 Jan 1999 03:13:21 (NZDT) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org Subject: KEKRecpientInfo KEKIdentifier Reply-To: pgut001@cs.aucKland.ac.nz X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Mon, 25 Jan 1999 03:13:21 (NZDT) Message-ID: <91718720129757@cs26.cs.auckland.ac.nz> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The KEKIdentifier in the KEKRecipientInfo currently contains a mandatory OCTET STRING which is supposed to contain some magic key ID, however in what I guess would be the most common uses for KEK data encryption (either straight file/data encryption or "Included below are last weeks sales figures encrypted with the key we agreed on") there's no conceivable use for this value. Could this be made optional like the other fields, or better yet could the whole KEKIdentifier be made optional (since it'll be empty without the OCTET STRING)? Either: ... kekid [ 0 ] KEKIdentifier OPTIONAL, ... (the preferred option) or alternatively: KEKidentifier ::= SEQUENCE { keyIdentifier OCTET STRING OPTIONAL, date GeneralizedTime OPTIONAL, other [ 0 ] OtherKeyAttribute OPTIONAL } The former would be nicer since the latter will lead to odd-looking empty SEQUENCEs appearing in most KEKRecipientInfo's. A much uglier alternative is to use a zero-length OCTET STRING to denote "I don't know what to do with this field", but that kind of defeats the point of having it there in the first place since it's just a kludgy way of saying OCTET STRING OPTIONAL. My preferred solution for this would be KEKIdentifier OPTIONAL since it reduces the amount of clutter. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA27676 for ietf-smime-bks; Sat, 23 Jan 1999 20:15:10 -0800 (PST) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA27672 for ; Sat, 23 Jan 1999 20:15:07 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id RAA00407; Sun, 24 Jan 1999 17:16:39 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91715139926677>; Sun, 24 Jan 1999 17:16:39 (NZDT) From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: housley@spyrus.com, ietf-smime@imc.org Subject: Re: Avoiding Small Subgroup Attack in X9.42 Diffie-Hellman Cc: robert.zuccherato@entrust.com Reply-To: pgut001@cs.aucKland.ac.nz X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Sun, 24 Jan 1999 17:16:39 (NZDT) Message-ID: <91715139926677@cs26.cs.auckland.ac.nz> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >In the x942 draft we presently specify that in some instances of >ephemeral-static Diffie-Hellman, public key validation does not need to be >performed; but for static-static Diffie-Hellman, public key validation is >needed. I would like to call to the group's attention another option. If >the prime p is chosen so that p-1=2*q*r where r is a product of large >(greater than 160 bits) primes then the "small subgroup" attacks are not a >concern here (except for the possible loss of 1 bit of the private key). >Perhaps we could specify this as another option for those situations that >require resistance to these attacks. > >If we did decide to allow this option, we would then have to specify how to >choose the prime to be of this form. We could either change the prime >generation algorithm, or we could specify that the prime generation algorithm >should be run enough number of times until this condition is met. This is just them Lim-Lee algorithm, which is already defined fairly clearly, so it wouldn't be hard to include it. I'd be quite keen on this option since it avoids using the (unnecessarily complex) FIPS 186 kosherizer, and has, as you point out, some useful properties (it may also be faster, has anyone compared it to the kosherizer for speed?). One possible downside is that it's not so easy to generate a prime of exactly n bits, but I can't see why this would be a drawback. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA19370 for ietf-smime-bks; Tue, 19 Jan 1999 08:47:26 -0800 (PST) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA19365 for ; Tue, 19 Jan 1999 08:47:23 -0800 (PST) Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.9.1a/8.9.1) with ESMTP id RAA23410 for ; Tue, 19 Jan 1999 17:49:17 +0100 Received: from bull.net (frcls6118.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id RAA16792 for ; Tue, 19 Jan 1999 17:51:50 +0100 (NFT) Message-ID: <36A4B79E.92574193@bull.net> Date: Tue, 19 Jan 1999 17:49:35 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.06 [fr] (Win95; I) MIME-Version: 1.0 To: "Ietf-Smime (E-mail)" Subject: Re: Last Call Comments on CMS-10 References: <2FBF98FC7852CF11912A0000000000010FF8A6D7@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Russ, As advertised at the last IETF meeting in Orlando, I have a comment on the lastest version of the CMS draft published. On page 12, in the section 5.6 Message Signature Validation Process the text says “ The input to the signature validation process includes the result of the message digest calculation process and the signer’s public key”. The problem is how to get the right signer’s public key and how to know that is valid or not. If no indication is given, then different results will be obtained between different implementations. The process is thus much more complicated than currently indicated as this is explained later on. The knowledge of the certificate of the signer as well as the time of the signature are both important. If there is an ambiguity on one or the other component then the end-result may be quite the opposite. The certificate is important because a user might use the same public key for different certificates which include different attributes. In such a case it is important to know which certificate has been selected by the signer. The time of the signature is important because the certificate may have been revoked since the document was signed and thus it is important to verify that the certificate was valid when the document was signed. In order to care for these cases, the following text is proposed for section 5.6: “ When a signed CMS structure is received, it is important to know who the signer is and whether the digital signature valid or not. The certificate allows to identify the signer and possibly some other attributes. A signer may have multiple certificates, e.g. with the same public key in it. In such a case, these certificates will have different security attributes in it. It is thus important to know which certificate has been selected by the signer. The time of the signature is important because the certificate may have been revoked since the document was signed and thus it is important to verify that the certificate was valid when the document was signed. This means that the certificate to be used for the verification process has to be verified as valid, i.e. before verifying that the result of the message digest, the digital signature and the signer’s public key match altogether. Two cases may be considered: 1) the certificate of the signer is already securely known in advance from the context and is checked to be valid according to a security policy (i.e. not individually revoked and the trusted path not revoked as well). In that case it may be used directly and the public key may be extracted out of it and used as an input to the verification process. 2) Neither the certificate of the signer, nor the signature time are known in advance from the context.. In such a case it is needed to obtain all the information, i.e. both the certificate of the signer and the correct signing time, from the data that has been received, in particular from the CMS structure. The SignerIdentifier may be used to obtain the right certificate. In some cases that information may however be insufficient or/and insecure (see [ESS], section 5.4) and the ESSCertId signed attribute shall be used in addition. If the signer’s certificate and all the cross-certificates from the certification path are all valid (e.g. not on the appropriate certificate revocation list (CRL) or authority revocation list (ARL) or a « not revoked » status is given back by an OCSP server) and during their validity period at the time the verification is made, then the public key may be used as an input to the signature verification process. Otherwise the signature is said to be invalid. If the signer’s certificate has been revoked but all the cross-certificates from the certification path are valid (e.g. at the time the verification is made, then additional information is needed to know whether the certificate may be used or not. It is then needed to verify that the signer’s certificate was valid at the time the signature was made. The signing-time attribute, when present, may only be used as an hint, since it only specify the time at which the signer (purportedly) performed the signing process. The time contained in a time stamp over the CMS structure from a TSA (Time Stamping Authority) will be needed to know whether or not the certificate was revoked at the time the signature was made. If the time from the time stamping authority is prior to the reviocation of the signers’ certificate then the public key may be used as an input to the signature verification process. Otherwise the signature is said to be invalid. If one of the cross-certificates is revoked, a time stamp prior to the revocation of that cross-certificate shall be obtained for that cross-certificate (or alternatively on the whole certification path). This will prove that the cross-certificate was valid before the revocation (or even the key compromise) of that CA. If it is missing, the signature is said to be invalid. The input to the signature verification process includes the result of the message digest calculation process and the signer's public key. The details of the signature verification depend on the signature algorithm employed. The recipient may not rely on any message digest values computed by the originator. If the signedData signerInfo includes signedAttributes, then the content message digest must be calculated as described in section 5.4. For the signature to be valid, the message digest value calculated by the recipient must be the same as the value of the messageDigest attribute included in thesignedAttributes of the signedData signerInfo. » Denis Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA07218 for ietf-smime-bks; Sun, 17 Jan 1999 17:12:25 -0800 (PST) Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA07213; Sun, 17 Jan 1999 17:12:24 -0800 (PST) Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id RAA16233; Sun, 17 Jan 1999 17:15:09 -0800 (PST) To: Russ Housley Cc: Paul Hoffman / IMC , "Linn, John" , "'IETF SMIME list'" Subject: Re: Crypto-oriented comments on x942-04 References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"> <4.1.19990114092656.03195190@mail.imc.org> <4.1.19990116134753.009e7320@mail.spyrus.com> <4.1.19990117194454.009a2e20@mail.spyrus.com> From: EKR Date: 17 Jan 1999 17:15:08 -0800 In-Reply-To: Russ Housley's message of "Sun, 17 Jan 1999 19:49:23 -0500" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Russ Housley writes: > You are correct. We did deal with this case. However, I think is is a good > idea to use the algorithm in such a way that future users of CMS cannot > make a simple mistake and be susceptable to the partion attack. I agree. > >>And, the fix is > >> very simple. We need to simply include the key length in the hash input. > >I'm prepared to do it, but I'm not sure that just shoving it in the > >pubInfo is the right choice. I'll think about this and try to write > >up a proposal by monday. > > If you are going to the RSA Confernce, I will gladly have a hallway chat > regarding the best way forward. Yes, I'll be there. -Ekr -- [Eric Rescorla ekr@rtfm.com] Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA06940 for ietf-smime-bks; Sun, 17 Jan 1999 16:57:06 -0800 (PST) Received: from smtp4.erols.com (smtp4.erols.com [207.172.3.237]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA06934; Sun, 17 Jan 1999 16:57:04 -0800 (PST) Received: from rhousley_laptop.spyrus.com (207-172-46-225.s225.tnt9.ann.erols.com [207.172.46.225]) by smtp4.erols.com (8.8.8/smtp-v1) with SMTP id TAA17077; Sun, 17 Jan 1999 19:58:39 -0500 (EST) Message-Id: <4.1.19990117194454.009a2e20@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 17 Jan 1999 19:49:23 -0500 To: EKR From: Russ Housley Subject: Re: Crypto-oriented comments on x942-04 Cc: Paul Hoffman / IMC , "Linn, John" , "'IETF SMIME list'" In-Reply-To: References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"> <4.1.19990114092656.03195190@mail.imc.org> <4.1.19990116134753.009e7320@mail.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Eric: At 02:24 PM 1/16/99 -0800, EKR wrote: >Russ Housley writes: >> >I don't see how this makes any difference. Remember, all we're talking >> >about is the data that's input to the key expansion function. The >> >actual parameters that are to be used have to be conveyed separately >> >in any case, because this data is subsequently hashed. The only real effect >> >of including the algorithmId at all is to produce different keys for >> >different algorithms using the same pubInfo. It could easily be omitted >> >entirely. >> >> I think you are missing an important point. RC2 with a 40 bit key and RC2 >> with a 128 bit key result in the same inputs to the hash algorithm. If an >> attacker is able to get a less sensitive message to be encrypted with the >> 40 bit key, this message can be readily attacked by brute force. Should a >> more sensitive message be encrypted with the 128 bit key, the attacker >> already knows the first 40 bits of the key. >This is incorrect. By fiat, when used for key encryption, RC2 ALWAYS >uses a 128 bit key. The 40 bits refers only to the effective key length. >It may be possible to go from the 40 bit key to having some information >about the 128 bit key, but it's certainly not as simple as simply >knowing the first 40 bits. You are correct. We did deal with this case. However, I think is is a good idea to use the algorithm in such a way that future users of CMS cannot make a simple mistake and be susceptable to the partion attack. >>And, the fix is >> very simple. We need to simply include the key length in the hash input. >I'm prepared to do it, but I'm not sure that just shoving it in the >pubInfo is the right choice. I'll think about this and try to write >up a proposal by monday. If you are going to the RSA Confernce, I will gladly have a hallway chat regarding the best way forward. ANSI X9.42 is going to be changed based on this thread. It will say something like: If the algorithm identifier does not unambigiously specify the output key length, then that key length must be inclused in spuuPubInfo. Russ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA05145 for ietf-smime-bks; Sun, 17 Jan 1999 10:22:22 -0800 (PST) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA05141 for ; Sun, 17 Jan 1999 10:22:21 -0800 (PST) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Sun, 17 Jan 99 10:23:33 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Sun, 17 Jan 1999 10:23:33 -0800 Message-ID: <01FF24001403D011AD7B00A024BC53C53A7550@mail.deming.com> From: "Blake Ramsdell" To: "'ietf-smime@imc.org'" Subject: MIME types for inbound / outbound Date: Sun, 17 Jan 1999 10:23:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1ABCF52F26499-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The MIME type for application/pkcs7-mime was registered in RFC2311 (March of 1998). All applications should at the very least be prepared to parse this as equivalent to application/x-pkcs7-mime, if not emitting it as well. Our products don't emit it, but we can parse both. I'm fixing it. Everyone else, please do the same (emit application/pkcs7-mime and recognize both versions). Part of the reason that I emitted the x- variant was because other applications couldn't read the non-x- variant. I suspect that this should stop on the anniversary of the registration of the MIME type. Applications may also wish to put in a way to force the outgoing MIME type to be the x- variant as a configuration option, just in case. Flames / comments welcome. Blake Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08421 for ietf-smime-bks; Sat, 16 Jan 1999 14:22:38 -0800 (PST) Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA08416; Sat, 16 Jan 1999 14:22:37 -0800 (PST) Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id OAA06107; Sat, 16 Jan 1999 14:24:56 -0800 (PST) To: Russ Housley Cc: Paul Hoffman / IMC , "Linn, John" , "'IETF SMIME list'" Subject: Re: Crypto-oriented comments on x942-04 References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"> <4.1.19990114092656.03195190@mail.imc.org> <4.1.19990116134753.009e7320@mail.spyrus.com> From: EKR Date: 16 Jan 1999 14:24:55 -0800 In-Reply-To: Russ Housley's message of "Sat, 16 Jan 1999 13:56:24 -0500" Message-ID: Lines: 32 X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Russ Housley writes: > >I don't see how this makes any difference. Remember, all we're talking > >about is the data that's input to the key expansion function. The > >actual parameters that are to be used have to be conveyed separately > >in any case, because this data is subsequently hashed. The only real effect > >of including the algorithmId at all is to produce different keys for > >different algorithms using the same pubInfo. It could easily be omitted > >entirely. > > I think you are missing an important point. RC2 with a 40 bit key and RC2 > with a 128 bit key result in the same inputs to the hash algorithm. If an > attacker is able to get a less sensitive message to be encrypted with the > 40 bit key, this message can be readily attacked by brute force. Should a > more sensitive message be encrypted with the 128 bit key, the attacker > already knows the first 40 bits of the key. This is incorrect. By fiat, when used for key encryption, RC2 ALWAYS uses a 128 bit key. The 40 bits refers only to the effective key length. It may be possible to go from the 40 bit key to having some information about the 128 bit key, but it's certainly not as simple as simply knowing the first 40 bits. >And, the fix is > very simple. We need to simply include the key length in the hash input. I'm prepared to do it, but I'm not sure that just shoving it in the pubInfo is the right choice. I'll think about this and try to write up a proposal by monday. -Ekr -- [Eric Rescorla ekr@rtfm.com] Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA07845 for ietf-smime-bks; Sat, 16 Jan 1999 11:43:54 -0800 (PST) Received: from smtp1.erols.com (smtp1.erols.com [207.172.3.234]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA07840; Sat, 16 Jan 1999 11:43:52 -0800 (PST) Received: from rhousley_laptop.spyrus.com (207-172-39-2.s2.tnt10.ann.erols.com [207.172.39.2]) by smtp1.erols.com (8.8.8/8.8.5) with SMTP id OAA10332; Sat, 16 Jan 1999 14:45:23 -0500 (EST) Message-Id: <4.1.19990116134753.009e7320@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 16 Jan 1999 13:56:24 -0500 To: EKR From: Russ Housley Subject: Re: Crypto-oriented comments on x942-04 Cc: Paul Hoffman / IMC , "Linn, John" , "'IETF SMIME list'" In-Reply-To: References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"> <4.1.19990114092656.03195190@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Eric: >> >> 7. Section 2.1.2: Identifying an algorithm by an OID rather than an >> >> AlgorithmID risks losing some specifics about the algorithm. For instance, >> >> in a variable-key-size block cipher (e.g., RC5), the AlgorithmID carries the >> >> key size, so this information would be lost. As a result, it may be possible >> >> for an opponent to substitute a key of one size for a key of a different >> >> size, which may lead to an attack that recovers the key one part at a time. >> >> Presumably, the reason for avoiding a full AlgorithmID is that some of its >> >> parameters are message-specific, such as IVs, but perhaps there is some >> >> middle ground. Including the key size as an optional field of OtherInfo is >> >> one possibility. Other parameters that will be lost in the case of RC5 are >> >> the block size and the number of rounds. >> > >> >I think this is weird, but this is how X9.42 does it, so our >> >choices are kind of limited. >> >> This worries me. If there is a substitution attack that can recover the >> key, I think we need to look at it VERY CAREFULLY. Has this same topic been >> discussed on the X9.42 list? If so, can someone summarize the result? If >> not, why not? > >I don't see how this makes any difference. Remember, all we're talking >about is the data that's input to the key expansion function. The >actual parameters that are to be used have to be conveyed separately >in any case, because this data is subsequently hashed. The only real effect >of including the algorithmId at all is to produce different keys for >different algorithms using the same pubInfo. It could easily be omitted >entirely. I think you are missing an important point. RC2 with a 40 bit key and RC2 with a 128 bit key result in the same inputs to the hash algorithm. If an attacker is able to get a less sensitive message to be encrypted with the 40 bit key, this message can be readily attacked by brute force. Should a more sensitive message be encrypted with the 128 bit key, the attacker already knows the first 40 bits of the key. Off the top of my head, I am not sure how the attacker can get this situation to happen with S/MIME v3, but I am in favor of a robust security standard. We know that people are looking at CMS for other purposes. One of those future uses may permit an attack like this one. And, the fix is very simple. We need to simply include the key length in the hash input. Russ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23766 for ietf-smime-bks; Fri, 15 Jan 1999 08:44:20 -0800 (PST) Received: (from phoffman@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA23757; Fri, 15 Jan 1999 08:44:17 -0800 (PST) Date: Fri, 15 Jan 1999 08:44:17 -0800 (PST) Message-Id: <199901151644.IAA23757@mail.proper.com> From: List Manager of ietf-smime To: ietf-smime@imc.org Subject: How to be removed from this list Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Greetings again. Occasionally, people will sign up for a mailing list and forget how to be removed. This message is a reminder for those folks. First off, when you subscribe to a mailing list, you almost always get a first message from the list owner telling you about the mailing list, and explaining how to unsubscribe. It is always a good idea to keep those messages, since you never know when you will need to unsubscribe. This is particularly useful when you change email addresses, because it is difficult to unsubscribe from a list after you have a different mailing address. In the case of this list, the method to unsubscribe is to send a message to: ietf-smime-request@imc.org with the single word: unsubscribe in the body of the message. This is the same as it always has been. To make this easier for you, I have crafted this message so that you should be able to simply reply to this message, and the reply address should be ietf-smime-request@imc.org (although some mail clients screw this up...). Remove everything from the body of the reply, and put in the single word: unsubscribe If you have tried this method, and the mailing list software won't let you unsubscribe, it is probably because your address has changed. In that case, please send a message to subs@imc.org stating which list (or lists) you want to unsubscribe from, and what you think your previous address was. There is a human (that's me!) who will then try to take care of your request, often within a few days. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22894 for ietf-smime-bks; Fri, 15 Jan 1999 07:05:30 -0800 (PST) Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22890 for ; Fri, 15 Jan 1999 07:05:29 -0800 (PST) Received: from rhousley_laptop.spyrus.com (207-172-112-3.s3.tnt4.ann.erols.com [207.172.112.3]) by smtp3.erols.com (8.8.8/8.8.5) with SMTP id KAA00859; Fri, 15 Jan 1999 10:05:39 -0500 (EST) Message-Id: <4.1.19990114165646.009d8de0@mail.spyrus.com> Message-Id: <4.1.19990114165646.009d8de0@mail.spyrus.com> Message-Id: <4.1.19990114165646.009d8de0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 15 Jan 1999 00:42:31 -0500 To: EKR From: Russ Housley Subject: Re: Crypto-oriented comments on x942-04 Cc: jlinn@securitydynamics.com, ietf-smime@imc.org In-Reply-To: References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Eric, John, et. al.: >> 5. Section 2.1.2: In Section 2.1.1, ZZ is a field element or integer, so >> some conversion to an octet string is required. The usual conversion, >> following IEEE P1363 and ANSI X9.42, is a most significant byte first >> representation. ANSI X9.42 specifies that the result has as few bytes as >> possible (i.e., no leading zeros); IEEE P1363 says that the result has the >> same length in octets as the longest field element (i.e., the length of the >> prime p), with leading zeros. So, there's an apparent IEEE P1363 vs. ANSI >> X9.42 discrepancy. Given that IEEE P1363 is currently in ballot and ANSI >> X9.42 needs to be recirculated, we'd recommend that IEEE P1363 be followed. >> In any case, some representation should be stated. >Agreed. Myself I prefer fewest octets. I disagree with Eric. I believe that ZZ should be the same size as p. I think that this is much easier to implement. An implementation must have a buffer the size of p since the result of the exponentiation could have no leading zero octets. So, the implementation can simply use the entire buffer as the first input to the hash function. I have asked a couple implementors what they do. So far, I have not found anyone that is dropping leading zero octets. It turns out that the ANSI X9F1 working group was meeting today. Good timing. The ANSI X9F1 working group discussed this comment, and the ANSI X9.42 draft will be changed to align with IEEE P1363. To me, these three points are compelling. I strongly suggest that we adopt Burt's and Lisa's recommendation. >> 7. Section 2.1.2: Identifying an algorithm by an OID rather than an >> AlgorithmID risks losing some specifics about the algorithm. For instance, >> in a variable-key-size block cipher (e.g., RC5), the AlgorithmID carries the >> key size, so this information would be lost. As a result, it may be possible >> for an opponent to substitute a key of one size for a key of a different >> size, which may lead to an attack that recovers the key one part at a time. >> Presumably, the reason for avoiding a full AlgorithmID is that some of its >> parameters are message-specific, such as IVs, but perhaps there is some >> middle ground. Including the key size as an optional field of OtherInfo is >> one possibility. Other parameters that will be lost in the case of RC5 are >> the block size and the number of rounds. >I think this is weird, but this is how X9.42 does it, so our >choices are kind of limited. I think it would be inappropriate to assign OIDs that did not contain message-specific data, such as IVs. Assigning additional OIDs does not seem to be the way forward. This "partition attack" is a real concern. That input to the hash function must unambiguously identify the output key length. However, I think that there is a way forward. The key length is either implicit from the algorithm identifier (e.g., DES) or it is carried as a parameter in the algorithm identifier (e.g., RC2). So, the recipient can easily determine the value to pass to the key derivation function. Perhaps we can always put the key length in the pubInfo. If a UKM is present, the pubInfo can be the concatenation of the key length and the UKM. What do others think about this approach? If this approach is acceptable to everyone, then we need work out the exact encodings. >> 10. Section 2.1.2: Why can't counter be an INTEGER? That would avoid the >> unnecessary definition of an encoding format for the counter, while >> maintaining an unambiguous encoding. >Again, this is how X9.42 does it. This is done to aid implementors. By making the field fixed length, an implentation can use a constant to initialize OtherInfo. Then, the counter portion is incremented for each invocation of the Hash function. >> 11. Section 2.1.2: Why must pubInfo, if present, contain a minimum of 512 >> bits? A minimum of 160 bits is sufficient to avoid collisions; the encoding >> as an OCTET STRING is unambiguous and prevents length-extension attacks. >Russ, you care to speak up on this? Since the internal block size of SHA-1 is 512 bits, this seems to be the maximum amount of entorpy that can be added with a public value. This comment would indicate that sizes between 160 and 512 bits are useful. Should we standarize on a single length? 512 bits? >> 13. Section 2.1.3: KEK computation states that each algorithm requires a >> specific size key. But some algorithms have variable-size keys, and it's >> possible that future algorithms will require more than just a random string >> (e.g., more structure). So, it would be preferable to say that the currently >> proposed S/MIME algorithms assume a random string, perhaps with parity >> changes. >Well, the output of this process is necessarily a random string. Any >algorithm which needs a key with more structure should have a pre-processor >which produces one from a bit string. I agree with Eric. I do not think that we can anticipate the needs of these future algorithms. Rather, when a future algorithm is defined, a mapping between the "random" X9.42 output and the structured input needed by the algorithm can be defined. >> 16. Section 2.2: Should a lower bound on the prime p also be given? >Probably. 1024 and be done with it? Eric, I assume that you mean p must be at least 1024 bits long. Not, p must be greater than 1024. >> 17. Sections 2.3 and 2.4: Key validation is not the only way to prevent a >> small-subgroup attack. Another method is cofactor multiplication, as >> described in IEEE P1363 and in [LAW98]. Cofactor multiplication performs an >> additional operation on the shared secret value so that it is not in a small >> subgroup. (There is a "compatibility mode" that keeps the shared secret >> value the same as in ordinary Diffie-Hellman when the system is not under >> attack; discussion is available in B.S. Kaliski Jr. Compatible cofactor >> multiplication for Diffie-Hellman primitives. Electronics Letters, >> 34(25):2396-2397, December 10, 1998.) >> >> Another method is to choose the primes p and q so that p = qj + 1 where j is >> small and to check the received public key against a small set of excluded >> values. In this case, the leakage due to a small subgroup attack will be >> only a few bits. >I have to admit that I'm not enough of a mathematician to have >an informed opinion on this topic. I'd certainly far rather not >change the shared-secret value, and I don't want to require >an extra operation either (for perforamnce reasons). Eric, your response here does not tell me what you plan to do. Do you know yet? Russ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22877 for ietf-smime-bks; Fri, 15 Jan 1999 07:04:18 -0800 (PST) Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22871 for ; Fri, 15 Jan 1999 07:04:15 -0800 (PST) Received: from rhousley_laptop.spyrus.com (207-172-112-3.s3.tnt4.ann.erols.com [207.172.112.3]) by smtp3.erols.com (8.8.8/8.8.5) with SMTP id KAA00842; Fri, 15 Jan 1999 10:05:37 -0500 (EST) Message-Id: <4.1.19990114160819.009a3a70@mail.spyrus.com> Message-Id: <4.1.19990114160819.009a3a70@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 14 Jan 1999 16:52:12 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Avoiding Small Subgroup Attack in X9.42 Diffie-Hellman Cc: robert.zuccherato@entrust.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I am forwarding the following message from Robert Zuccherato. Russ = = = = = = = = = = In the x942 draft we presently specify that in some instances of ephemeral-static Diffie-Hellman, public key validation does not need to be performed; but for static-static Diffie-Hellman, public key validation is needed. I would like to call to the group's attention another option. If the prime p is chosen so that p-1=2*q*r where r is a product of large (greater than 160 bits) primes then the "small subgroup" attacks are not a concern here (except for the possible loss of 1 bit of the private key). Perhaps we could specify this as another option for those situations that require resistance to these attacks. I believe that the situations where resistance to these attacks is required will remain the same. However, we could allow the option of choosing the prime p to have this form. This may be a desirable option, as it appears that performing public key validation may be encumbered. However, it is not clear that this should be the only option because even with this, one bit of the key could be leaked, which may not be acceptable in some situations. Also, parameter generation will become more complicated. If we did decide to allow this option, we would then have to specify how to choose the prime to be of this form. We could either change the prime generation algorithm, or we could specify that the prime generation algorithm should be run enough number of times until this condition is met. Thank you, Robert Zuccherato Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA25256 for ietf-smime-bks; Thu, 14 Jan 1999 15:12:02 -0800 (PST) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA25252 for ; Thu, 14 Jan 1999 15:12:00 -0800 (PST) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 14 Jan 1999 15:13:02 -0800 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5C13@localhost> From: "Jim Schaad (Exchange)" To: "Ietf-Smime (E-mail)" , "Blake Ramsdell (E-mail)" Cc: "Russ Housley (E-mail)" Subject: Last Call MSG-Draft: ASN Module for MSG draft Date: Thu, 14 Jan 1999 15:12:59 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Here is a proposed module to replace appendix A in the Message draft. A couple of comments about this: We are putting in some duplicate information that I think should be lost from the draft for various reasons (either duplication of data in other modules or "obsolete" being the biggest). This information was required in the V2 message draft as there was no other place to reference the information, but should now be deleted in my opinion. I suggest we 1) Delete the digest algorithms -- duplication of CMS 2) rsaEncryption from the Asymetric Encrption section and put a note in about why we have rsa and id-dsa here 3) All but md2WithRSAEncryption from the signature algorithms section and put in a comment about how it might be on certificates but should not be in messages 4) Delete signing time from the bottom section -- duplication of CMS and insufficent data to implement anyway. jim SecureMimeMessageV3 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS -- Cryptographic Message Syntax SubjectKeyIdentifier, IssuerAndSerialNumber, RecipientKeyIdentifier FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }; -- id-aa is the arc with all new authenticated and unauthenticated attributes -- produced the by S/MIME Working Group id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)} -- S/MIME Capabilities provides a method of broadcasting the symetric capabilities -- understood. Algorithms should be ordered by preference and grouped by type smimeCapabilities OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15} SMIMECapability ::= SEQUENCE { capabilityID OBJECT IDENTIFIER, parameters ANY DEFINED BY capabilityID OPTIONAL } SMIMECapabilities ::= SEQUENCE OF SMIMECapability -- Encryption Key Preference provides a method of broadcasting the prefered -- encryption certificate. id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} SMIMEEncryptionKeyPreference ::= CHOICE { issuerAndSerialNumber [0] IssuerAndSerialNumber, receipentKeyId [1] RecipientKeyIdentifier, subjectAltKeyIdentifier [2] SubjectKeyIdentifier } -- The Content Encryption Algorithms defined for SMIME are: -- Triple-DES is the manditory algorithm with CBCParameter being the parameters dES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7} CBCParameter ::= IV IV ::= OCTET STRING (SIZE (8..8)) -- RC2 (or compatable) is an optional algorithm w/ RC2-CBC-paramter as the parameter rC2-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 2} -- For the effective-key-bits (key size) greater than 32 and less than -- 256, the RC2-CBC algorithm parameters are encoded as: RC2-CBC-parameter ::= SEQUENCE { rc2ParameterVersion INTEGER, iv IV} -- For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion -- values are 160, 120, 58 respectively. -- The following list the OIDs to be used with S/MIME V3 -- Digest Algorithms: -- md5 OBJECT IDENTIFIER ::= -- {iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5} -- sha-1 OBJECT IDENTIFIER ::= --- {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) -- 26} -- Asymmetric Encryption Algorithms -- -- rsaEncryption OBJECT IDENTIFIER ::= -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1} -- -- rsa OBJECT IDENTIFIER ::= -- {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1} -- -- id-dsa OBJECT IDENTIFIER ::= -- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 } -- Signature Algorithms -- -- md2WithRSAEncryption OBJECT IDENTIFIER ::= -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2} -- -- md5WithRSAEncryption OBJECT IDENTIFIER ::= -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4} -- -- sha-1WithRSAEncryption OBJECT IDENTIFIER ::= -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5} -- -- id-dsa-with-sha1 OBJECT IDENTIFIER ::= -- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3} -- Other Signed Attributes -- -- signingTime OBJECT IDENTIFIER ::= -- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5} -- See [CMS] for a description of how to encode the attribute value. END Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA23001 for ietf-smime-bks; Thu, 14 Jan 1999 11:07:19 -0800 (PST) Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA22996; Thu, 14 Jan 1999 11:07:17 -0800 (PST) Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id LAA14200; Thu, 14 Jan 1999 11:09:46 -0800 (PST) To: Paul Hoffman / IMC Cc: "Linn, John" , "'IETF SMIME list'" Subject: Re: Crypto-oriented comments on x942-04 References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"> <4.1.19990114092656.03195190@mail.imc.org> From: EKR Date: 14 Jan 1999 11:09:45 -0800 In-Reply-To: Paul Hoffman / IMC's message of "Thu, 14 Jan 1999 09:32:24 -0800" Message-ID: Lines: 59 X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Paul Hoffman / IMC writes: > >> 7. Section 2.1.2: Identifying an algorithm by an OID rather than an > >> AlgorithmID risks losing some specifics about the algorithm. For instance, > >> in a variable-key-size block cipher (e.g., RC5), the AlgorithmID carries the > >> key size, so this information would be lost. As a result, it may be possible > >> for an opponent to substitute a key of one size for a key of a different > >> size, which may lead to an attack that recovers the key one part at a time. > >> Presumably, the reason for avoiding a full AlgorithmID is that some of its > >> parameters are message-specific, such as IVs, but perhaps there is some > >> middle ground. Including the key size as an optional field of OtherInfo is > >> one possibility. Other parameters that will be lost in the case of RC5 are > >> the block size and the number of rounds. > > > >I think this is weird, but this is how X9.42 does it, so our > >choices are kind of limited. > > This worries me. If there is a substitution attack that can recover the > key, I think we need to look at it VERY CAREFULLY. Has this same topic been > discussed on the X9.42 list? If so, can someone summarize the result? If > not, why not? I don't see how this makes any difference. Remember, all we're talking about is the data that's input to the key expansion function. The actual parameters that are to be used have to be conveyed separately in any case, because this data is subsequently hashed. The only real effect of including the algorithmId at all is to produce different keys for different algorithms using the same pubInfo. It could easily be omitted entirely. > >> Having noted this, the field selections and names seem inappropriate: the > >> fact that keyInfo varies for a given key is contradictory. A preferable > >> organization would be to have keyInfo include the algorithm and optional > >> pubInfo, and put the counter in a field of its own, called keyPart, as in: > >> > >> OtherInfo ::= SEQUENCE { > >> keyInfo KeySpecificInfo, > >> keyPart INTEGER(1..2^32-1) } > >> > >> KeySpecificInfo ::= SEQUENCE { > >> algorithm OBJECT IDENTIFIER, > >> pubInfo OCTET STRING OPTIONAL, > >> keySize INTEGER OPTIONAL } > > > >This structure is basically lifted from X9.42, so changing the > >structure isn't really feasible for compatability reasons. > >Changing the names while keeping the same ASN.1 doesn't seem > >to add clarity. > > I disagree: implementors can often be led astray by field names. As an implementor, one of the things I hate the most is when I try to compare two protocols and have to spend a lot of time trying to figure out if they're the same because someone has gratiuitously changed a bunch of stuff and I can't tell if the changes affect the bits on the wire. -Ekr -- [Eric Rescorla ekr@rtfm.com] Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA22540 for ietf-smime-bks; Thu, 14 Jan 1999 10:17:25 -0800 (PST) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA22536 for ; Thu, 14 Jan 1999 10:17:24 -0800 (PST) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2 SR1); Thu, 14 Jan 99 10:18:22 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Thu, 14 Jan 1999 10:18:21 -0800 Message-ID: <01FF24001403D011AD7B00A024BC53C53A7511@mail.deming.com> From: "Blake Ramsdell" To: "'Jim Schaad (Exchange)'" , "Ietf-Smime (E-mail)" cc: "Russ Housley (E-mail)" Subject: RE: Last Call comments on the Message And Certificate Drafts Date: Thu, 14 Jan 1999 10:18:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1A80EB648727-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > -----Original Message----- > From: Jim Schaad (Exchange) [mailto:jimsch@EXCHANGE.MICROSOFT.com] > Sent: Saturday, January 09, 1999 3:48 PM > To: Ietf-Smime (E-mail); Blake Ramsdell > Cc: Russ Housley (E-mail) > Subject: Last Call comments on the Message And Certificate Drafts > > 1. I would like to see some consistancy developed in the > reference naming > between the different documents produced from the S/MIME > working group. I > especially dislike the KEYM reference name for PKIX Part1 as > this is really > misleading. Part1 does not really say anything bout key management. This makes sense. > 2. Are we requesting obsoletion of the V2 drafts or not. If > we are then why > are we refering to them. If we are not then we need to make > this clear to > the RFC editors. Based on the current thinking, it would be > my guess that > we are not requesting the obsoletion of the S/MIME V2 drafts. My understanding is that because an RFC is obsolete it does mean you can't refer to it any more. We do this for PKCS #1 v1.5 and PKCS #1 v2.0, even though the PKCS #1 v1.5 RFC is technically obsolete. > 1. Section 2.4.1 - Example on signature appears to eleminate > multipart/signed as it states content MUST be stored in eContent OCTET > STRING. I would strongly recommend removing the MUST on this as it is > example not statement of operation. Hmm... I understand the concern. Thinking... > 2. Section 2.5 - Why do we mention receipt requests but not > security labels. > I would think they are of equal importance and should either both be > mentioned or omitted. This is especially true as security > labels can easily > be understood by V2 clients but not receipts (well at least > not easily). I > recommend we strike the reference to receipt requests. Agree. > 3. Section 2.6 -- This is not stated in the format of a MUST. > Change to > "S/MIME v3 agents MUST use the isserAndSerialNumber form of > SignerInfo." or > similar statement. Can I just capitalize MUST in the current sentence? > 5. Section 3.2.1 - The last sentence contains a "MUST not" > this should be > "MUST NOT" Agree. > 6. Section A - Changing to an ASN module would be considered > niceness but > not necessity. I an finding that I use ASN modules more and more for > creation of ASN encode/decode functions. Given that we now > have several > different ASN structures in this appendix, I would like to > see this combined > into an ASN module. I can create this if desired. I personally think that this would be cool (to have the ASN). > 7. References -- The [DH] citation should be made to > reference the internet > draft/RFC Agree. > 1. Section 1 - Reference to KEYM in the last sentence of > paragraph #1 is > almost certianly meant to be a reference to SMIME-MSG Hmm. I'll buy that. Agree. > 2. Section 1 - PKCS#10 requirements are in the V2 Msg Draft > and not the V3 > message draft. This text needs to be omitted or refer to > MSG-V2 instead. > (CERT-V2?) I believe that this text should be omitted, since we came to agreement at one point that we would not speak of it. > 3. Section A - Remove reference to CRMF as we don't use it Agree. > 4. Section 2.3 - P#3 - Given inheritance of DSA parameters do > we need to > modify the statement on not sending the root CA cert. > Messages are not even > internally validatable with out the root in some cases. Hmm. I'd rather make it so that DSA parameters MUST NOT be scattered all the way up and down the certificate chain, which I understand will increase the certificate size, but will greatly simplify implementation. Comments? > 5. Section 4.3 - Why is there a reference to SMIME-MSG for > RSA but not for > DSA? Why is there no reference for DSA? Not to mention that SMIME-MSG is a pretty stupid reference for RSA signatures -- the PKCS #1 RFC would be better, wouldn't it? Recommend that we fix the reference to point to PKCS #1 for the RSA algorithms and to point to the DSA reference for the DSA algorithm. > 6. Section 4.4 - P#1 - Lets replace the last sentence with > "The syntax and > semantics of all the identified extensions are defined in [KEYM]." I think this sounds OK. > 7. Section 4.4 - P#2 - Replace sentence #1 with "... the > Basic Constraints, > Key Usage, Authority Key Identifier, Subject Key Identifier > and Subject > Alternative Name Certificate Extensions when they ..." Agree. > 8. Section 4.4.1 - We have a big conflict with PKIX. We say > basicConstraints should appear, they say it should not. My > personal opinion > on this one is that PKIX is wrong and we should not change > it, but I raise > this as an incompatiblity between the two drafts. I believe that in the event that PKIX says one thing and -cert says something else, -cert wins. > 9. Section 4.4.1 - Should we add the same criticality > statement as occurs in > PKIX -- i.e. MUST be critical if it appears. I recommend > that we strike the > criticality statment in 4.4.2 as it duplicates information in > PKIX part1. Agree. Blake Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA22121 for ietf-smime-bks; Thu, 14 Jan 1999 09:39:10 -0800 (PST) Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA22117; Thu, 14 Jan 1999 09:39:05 -0800 (PST) Message-Id: <4.1.19990114092656.03195190@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 14 Jan 1999 09:32:24 -0800 To: EKR , "Linn, John" From: Paul Hoffman / IMC Subject: Re: Crypto-oriented comments on x942-04 Cc: "'IETF SMIME list'" In-Reply-To: References: <"Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500"> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: >> 7. Section 2.1.2: Identifying an algorithm by an OID rather than an >> AlgorithmID risks losing some specifics about the algorithm. For instance, >> in a variable-key-size block cipher (e.g., RC5), the AlgorithmID carries the >> key size, so this information would be lost. As a result, it may be possible >> for an opponent to substitute a key of one size for a key of a different >> size, which may lead to an attack that recovers the key one part at a time. >> Presumably, the reason for avoiding a full AlgorithmID is that some of its >> parameters are message-specific, such as IVs, but perhaps there is some >> middle ground. Including the key size as an optional field of OtherInfo is >> one possibility. Other parameters that will be lost in the case of RC5 are >> the block size and the number of rounds. > >I think this is weird, but this is how X9.42 does it, so our >choices are kind of limited. This worries me. If there is a substitution attack that can recover the key, I think we need to look at it VERY CAREFULLY. Has this same topic been discussed on the X9.42 list? If so, can someone summarize the result? If not, why not? >> Having noted this, the field selections and names seem inappropriate: the >> fact that keyInfo varies for a given key is contradictory. A preferable >> organization would be to have keyInfo include the algorithm and optional >> pubInfo, and put the counter in a field of its own, called keyPart, as in: >> >> OtherInfo ::= SEQUENCE { >> keyInfo KeySpecificInfo, >> keyPart INTEGER(1..2^32-1) } >> >> KeySpecificInfo ::= SEQUENCE { >> algorithm OBJECT IDENTIFIER, >> pubInfo OCTET STRING OPTIONAL, >> keySize INTEGER OPTIONAL } > >This structure is basically lifted from X9.42, so changing the >structure isn't really feasible for compatability reasons. >Changing the names while keeping the same ASN.1 doesn't seem >to add clarity. I disagree: implementors can often be led astray by field names. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20971 for ietf-smime-bks; Thu, 14 Jan 1999 07:43:27 -0800 (PST) Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20954; Thu, 14 Jan 1999 07:43:25 -0800 (PST) Received: from rhousley_laptop.spyrus.com (dial01.spyrus.com [207.212.34.121]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA20919; Thu, 14 Jan 1999 07:44:19 -0800 (PST) Message-Id: <4.1.19990113112737.00990a50@209.172.119.123> Message-Id: <4.1.19990113112737.00990a50@209.172.119.123> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 13 Jan 1999 11:29:49 -0500 To: phoffman@imc.org From: Russ Housley Subject: Re: Comments on ESS-10 Cc: ietf-smime@imc.org In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5BD7@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Paul, There is quite a bit of overlap with Jim's comments and mine. Thus, I agree with almost everything he said. >0. Section 1. We have not yet seen the new introduction paragraphs which >include section 5. I would like to do so before the document goes to the >RFC editor. > >1. Section 1.3 - the macValue attribute has been removed from CMS and needs >to be removed from CMS > >2. Section 1.4 - Minor word changes in paragraph 2. "The main disadvantage >is that the gateway must check for the presence of certain attributes in the >other signerInfos and either omit or copy those attributes." > >3. Section 2.2 - bullet item 4: I have some \240 characters in the text >here which I assume are suppose to be spaces. Many of these are found >through out the entire document. I have had to edit them out to get the ASN >module to compile. > >4. Section 2.8 - ASN for Receipt still references Version not CMSVersion I suggest that you define ESSVersion instead of importing CMSVersion. >5. Section 4.4 - The ASN for MLData has a comment on EntityIdentifier has a >note about being imported from CMS, but its not. Please remove the comment >in the text and in the ASN module Russ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20970 for ietf-smime-bks; Thu, 14 Jan 1999 07:43:27 -0800 (PST) Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20955; Thu, 14 Jan 1999 07:43:25 -0800 (PST) Received: from rhousley_laptop.spyrus.com (dial01.spyrus.com [207.212.34.121]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA20907; Thu, 14 Jan 1999 07:44:12 -0800 (PST) Message-Id: <4.1.19990113103347.009c6250@209.172.119.123> Message-Id: <4.1.19990113103347.009c6250@209.172.119.123> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 13 Jan 1999 10:39:03 -0500 To: phoffman@imc.org From: Russ Housley Subject: Re: Comments on ESS-10 Cc: ietf-smime@imc.org In-Reply-To: <4.1.19990112131829.00bc6f00@mail.imc.org> References: <2FBF98FC7852CF11912A0000000000010ECB5BD7@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Paul: >>4. Section 2.8 - ASN for Receipt still references Version not CMSVersion > >Many thanks to Russ for switching this out from under me. :-) I do *not* >think we should import CMSVersion from CMS, because the version number we >are using here has nothing to do with CMS, and the name will be confusing. >Instead, I think I should define it as: > >Version ::= INTEGER { v1(1) } > >Comments? This change to CMS was made to avoid conflicts with the PKIX Part 1 definition of Version. I agree that you should not import CMSVersion. However, you should also avoid the conflict with the PKIX Part 1 definition of Version. I suggest that you use: ESSVersion ::= INTEGER { v1(1) } Russ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20972 for ietf-smime-bks; Thu, 14 Jan 1999 07:43:27 -0800 (PST) Received: from spyrus.com (mail.spyrus.com [207.212.34.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20966 for ; Thu, 14 Jan 1999 07:43:26 -0800 (PST) Received: from rhousley_laptop.spyrus.com (dial01.spyrus.com [207.212.34.121]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA20914; Thu, 14 Jan 1999 07:44:16 -0800 (PST) Message-Id: <4.1.19990113110257.009c8c70@209.172.119.123> Message-Id: <4.1.19990113110257.009c8c70@209.172.119.123> X-Sender: rhousley@mail.spyrus.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 13 Jan 1999 11:23:54 -0500 To: blaker@deming.com From: Russ Housley Subject: Re: Last Call comments on the Message And Certificate Drafts Cc: ietf-smime@imc.org In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5BD5@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Blake: > Message Draft comments > >6. Section A - Changing to an ASN module would be considered niceness but >not necessity. I an finding that I use ASN modules more and more for >creation of ASN encode/decode functions. Given that we now have several >different ASN structures in this appendix, I would like to see this combined >into an ASN module. I can create this if desired. I strongly agree. So, I have assigned an OID for the module identifier. id-mod-msg-v3 OBJECT IDENTIFIER ::= { id-mod 4 } >Certificate Draft comments > >4. Section 2.3 - P#3 - Given inheritance of DSA parameters do we need to >modify the statement on not sending the root CA cert. Messages are not even >internally validatable with out the root in some cases. I agree. We should not prohibit the inclusion of root certificates (or any certificate). >8. Section 4.4.1 - We have a big conflict with PKIX. We say >basicConstraints should appear, they say it should not. My personal opinion >on this one is that PKIX is wrong and we should not change it, but I raise >this as an incompatiblity between the two drafts. Very good catch. MSG-06 says: "Certificates SHOULD contain a basicConstraints extension." PKIX Part 1 requires the basicConstraints extension to be present in CA certificates, and it says that the basicConstraints extension should not be present in end-entity certificates. I sugest that we adopt the PKIX Part 1 text. >9. Section 4.4.1 - Should we add the same criticality statement as occurs in >PKIX -- i.e. MUST be critical if it appears. I recommend that we strike the >criticality statment in 4.4.2 as it duplicates information in PKIX part1. I agree. When the the basicConstraints extension is present, it MUST be critical. Russ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20727 for ietf-smime-bks; Thu, 14 Jan 1999 07:09:31 -0800 (PST) Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA20723 for ; Thu, 14 Jan 1999 07:09:29 -0800 (PST) Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id HAA12068; Thu, 14 Jan 1999 07:11:39 -0800 (PST) To: "Linn, John" Cc: "'IETF SMIME list'" Subject: Re: Crypto-oriented comments on x942-04 References: From: EKR Date: 14 Jan 1999 07:11:38 -0800 In-Reply-To: "Linn, John"'s message of "Wed, 13 Jan 1999 13:30:42 -0500" Message-ID: Lines: 218 X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: "Linn, John" writes: > Per Russ' solicitation for review of smime-x942-04 by cryptographers, I'm > forwarding the attached comments provided to me by Burt Kaliski and Yiqun > Lisa Yin of RSA Laboratories. Thanks to John, Burt, and Lisa. > 2. ANSI X9.42 is still an unapproved draft, and should be cited as such, not > as a standard. Ok. > 3. The shared secret value ZZ is sometimes called a shared secret number. > "Value" would be better throughout, since in more general settings, ZZ is a > finite field element, not a number (integer). Well, a lot of the point here is to concretize (there's a horrible neologism for you) X9.42 for S/MIME use, and for the purposes of S/MIME, it's an integer. Anyone else want to comment on this? > 4. Section 2.1.1: An operator is missing in the definitions of g and h, > which should be > > g = h^{(p-1)/q} mod p ... > h is any integer ... such that h^{(p-1)/q} ... > > In this definition, it could be clarifying to state that the parameters are > (p,q,g) and to change the order of definitions to: > p is a large prime > q is a large prime such that p = qj+1 for some larger integer j > g = h^{(p-1)/q} mod p where ... > > Further, it may be helpful to explain that "g has order q mod p" means that > g^q mod p = 1, if g <> 1 and q is prime. Right. I'm happy to change this. > 5. Section 2.1.2: In Section 2.1.1, ZZ is a field element or integer, so > some conversion to an octet string is required. The usual conversion, > following IEEE P1363 and ANSI X9.42, is a most significant byte first > representation. ANSI X9.42 specifies that the result has as few bytes as > possible (i.e., no leading zeros); IEEE P1363 says that the result has the > same length in octets as the longest field element (i.e., the length of the > prime p), with leading zeros. So, there's an apparent IEEE P1363 vs. ANSI > X9.42 discrepancy. Given that IEEE P1363 is currently in ballot and ANSI > X9.42 needs to be recirculated, we'd recommend that IEEE P1363 be followed. > In any case, some representation should be stated. Agreed. Myself I prefer fewest octets. > Also, the comment "the > security of this data is limited to the size of ZZ" is not accurate. The > security is related to the size of p and q. A large ZZ doesn't imply > security by itself. I agree that this is misleading. I'll fix it. > 6. Section 2.1.2: Editorial: Change "shared key" to "shared secret value". Agreed. > 7. Section 2.1.2: Identifying an algorithm by an OID rather than an > AlgorithmID risks losing some specifics about the algorithm. For instance, > in a variable-key-size block cipher (e.g., RC5), the AlgorithmID carries the > key size, so this information would be lost. As a result, it may be possible > for an opponent to substitute a key of one size for a key of a different > size, which may lead to an attack that recovers the key one part at a time. > Presumably, the reason for avoiding a full AlgorithmID is that some of its > parameters are message-specific, such as IVs, but perhaps there is some > middle ground. Including the key size as an optional field of OtherInfo is > one possibility. Other parameters that will be lost in the case of RC5 are > the block size and the number of rounds. I think this is weird, but this is how X9.42 does it, so our choices are kind of limited. > 8. Section 2.1.2: "Parameters" is misspelled in the definition of the > algorithm field. I'll fix this. > 9. Section 2.1.2: Some additional explanation would be helpful about the > relationship between KM and a KEK. In particular, the text might say that to > generate a KEK, one generates one or more KMs from the same ZZ, where > OtherInfo varies. The variable part of OtherInfo is keyInfo; pubInfo remains > the same. I'll try to add some text here. > Having noted this, the field selections and names seem inappropriate: the > fact that keyInfo varies for a given key is contradictory. A preferable > organization would be to have keyInfo include the algorithm and optional > pubInfo, and put the counter in a field of its own, called keyPart, as in: > > OtherInfo ::= SEQUENCE { > keyInfo KeySpecificInfo, > keyPart INTEGER(1..2^32-1) } > > KeySpecificInfo ::= SEQUENCE { > algorithm OBJECT IDENTIFIER, > pubInfo OCTET STRING OPTIONAL, > keySize INTEGER OPTIONAL } This structure is basically lifted from X9.42, so changing the structure isn't really feasible for compatability reasons. Changing the names while keeping the same ASN.1 doesn't seem to add clarity. > 10. Section 2.1.2: Why can't counter be an INTEGER? That would avoid the > unnecessary definition of an encoding format for the counter, while > maintaining an unambiguous encoding. Again, this is how X9.42 does it. > 11. Section 2.1.2: Why must pubInfo, if present, contain a minimum of 512 > bits? A minimum of 160 bits is sufficient to avoid collisions; the encoding > as an OCTET STRING is unambiguous and prevents length-extension attacks. Russ, you care to speak up on this? > Also, random or nonce might be a better name, since all of otherInfo, not > just pubInfo, is public. Yet again, this name is from X9.42. > 12. In general, the different terms for byte ordering should be harmonized > or adopted from some other standard: "leftmost", "network byte order", etc. I agree. > 13. Section 2.1.3: KEK computation states that each algorithm requires a > specific size key. But some algorithms have variable-size keys, and it's > possible that future algorithms will require more than just a random string > (e.g., more structure). So, it would be preferable to say that the currently > proposed S/MIME algorithms assume a random string, perhaps with parity > changes. Well, the output of this process is necessarily a random string. Any algorithm which needs a key with more structure should have a pre-processor which produces one from a bit string. > 14. Section 2.1.5: Editorial: Change "received public keys" to "a received > public key y". > > Also, add a reference to IEEE P1363 security considerations for more > discussion on public-key validation. > 15. Section 2.1.6: This 16-byte example doesn't comply with the draft's > 160-bit minimum (Section 2.2). So it doesn't. I changed the minimum on the last draft and forgot that it affected the examples. > 16. Section 2.2: Should a lower bound on the prime p also be given? Probably. 1024 and be done with it? > Why is > there a 160-bit minimum on q? IIRC, Brian LaMacchia wanted this. I'll let him speak for it. > (Note that the 128-bit minimum in the same > paragraph is inconsistent.) Yes, this is inconsistent search and replace. > Also, a minimum size on the private key x is > inconsistent with saying that x is in the interval [2,q-2]. Yes, I'll remove the reference to x here. > Per Sec. 2.2.1.1, we believe that it would be appropriate for the document > to state explicitly that alternate parameter generation algorithms MAY be > used; P1363 can be cited for discussion. Well, SHOULD means 'do it this way unless you've got a good reason'. > Per Sec. 2.2.1.1, step 6, it would > be useful to give a reference to what primality algorithm(s) can be used. I can probably add something here. > 17. Sections 2.3 and 2.4: Key validation is not the only way to prevent a > small-subgroup attack. Another method is cofactor multiplication, as > described in IEEE P1363 and in [LAW98]. Cofactor multiplication performs an > additional operation on the shared secret value so that it is not in a small > subgroup. (There is a "compatibility mode" that keeps the shared secret > value the same as in ordinary Diffie-Hellman when the system is not under > attack; discussion is available in B.S. Kaliski Jr. Compatible cofactor > multiplication for Diffie-Hellman primitives. Electronics Letters, > 34(25):2396-2397, December 10, 1998.) > > Another method is to choose the primes p and q so that p = qj + 1 where j is > small and to check the received public key against a small set of excluded > values. In this case, the leakage due to a small subgroup attack will be > only a few bits. I have to admit that I'm not enough of a mathematician to have an informed opinion on this topic. I'd certainly far rather not change the shared-secret value, and I don't want to require an extra operation either (for perforamnce reasons). > Editorial: Change "If the sender cannot" to "If an opponent cannot"; change > "failure of decryption" to "failure of a decryption operation by the > recipient". No problemo. > 19. Security considerations. The last two paragraphs could be merged into > Sections 2.1.5 and 2.2, or at least should be made consistent, so there are > not two sources for the same information. > > In the last paragraph, the effective length of 3DES keys is 112, not 168, > due to a meet-in-the-middle attack. Fair enough. > In a general design, one looks for a minimum security level and selects > algorithms to meet that level. So, for instance, if an 80-bit security level > is desired, a designer may choose 3DES or RC2 and a 160-bit minimum > subgroup. Selecting the subgroup size to be double the effective key > strength, while effective, is more than what is necessary. The subgroup size > should be double the desired security level rather than double the symmetric > key size. I see your point here, but I'm not sure I agree. It seems to me that a good design principle is to have a balanced system, where all the algorithms are of roughly comparable strength. This speaks for having the effctive key length as the basis for private key size. > Moreover, there needs to be a prime size selection (1024 bits, 2048 bits, > etc.) that matches the desired level. Agreed. I'd be glad to have some guidance on this one. -Ekr -- [Eric Rescorla ekr@rtfm.com] Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA22109 for ietf-smime-bks; Wed, 13 Jan 1999 10:26:18 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA22103 for ; Wed, 13 Jan 1999 10:26:17 -0800 (PST) Received: from mail.securitydynamics.com by tholian.securitydynamics.com via smtpd (for imc.org [206.184.129.134]) with SMTP; 13 Jan 1999 18:27:50 UT Received: by securitydynamics.com (8.7.6/8.7.3) with ESMTP id NAA24497 for ; Wed, 13 Jan 1999 13:35:35 -0500 (EST) Received: by exna01.securitydynamics.com with Internet Mail Service (5.5.2232.9) id ; Wed, 13 Jan 1999 13:27:31 -0500 Message-ID: From: "Linn, John" To: "'IETF SMIME list'" Subject: Crypto-oriented comments on x942-04 Date: Wed, 13 Jan 1999 13:30:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Per Russ' solicitation for review of smime-x942-04 by cryptographers, I'm forwarding the attached comments provided to me by Burt Kaliski and Yiqun Lisa Yin of RSA Laboratories. --jl 1. In general, the draft is a nice condensation of the ANSI X9.42 draft into IETF S/MIME terms. 2. ANSI X9.42 is still an unapproved draft, and should be cited as such, not as a standard. 3. The shared secret value ZZ is sometimes called a shared secret number. "Value" would be better throughout, since in more general settings, ZZ is a finite field element, not a number (integer). 4. Section 2.1.1: An operator is missing in the definitions of g and h, which should be g = h^{(p-1)/q} mod p ... h is any integer ... such that h^{(p-1)/q} ... In this definition, it could be clarifying to state that the parameters are (p,q,g) and to change the order of definitions to: p is a large prime q is a large prime such that p = qj+1 for some larger integer j g = h^{(p-1)/q} mod p where ... Further, it may be helpful to explain that "g has order q mod p" means that g^q mod p = 1, if g <> 1 and q is prime. 5. Section 2.1.2: In Section 2.1.1, ZZ is a field element or integer, so some conversion to an octet string is required. The usual conversion, following IEEE P1363 and ANSI X9.42, is a most significant byte first representation. ANSI X9.42 specifies that the result has as few bytes as possible (i.e., no leading zeros); IEEE P1363 says that the result has the same length in octets as the longest field element (i.e., the length of the prime p), with leading zeros. So, there's an apparent IEEE P1363 vs. ANSI X9.42 discrepancy. Given that IEEE P1363 is currently in ballot and ANSI X9.42 needs to be recirculated, we'd recommend that IEEE P1363 be followed. In any case, some representation should be stated. Also, the comment "the security of this data is limited to the size of ZZ" is not accurate. The security is related to the size of p and q. A large ZZ doesn't imply security by itself. 6. Section 2.1.2: Editorial: Change "shared key" to "shared secret value". 7. Section 2.1.2: Identifying an algorithm by an OID rather than an AlgorithmID risks losing some specifics about the algorithm. For instance, in a variable-key-size block cipher (e.g., RC5), the AlgorithmID carries the key size, so this information would be lost. As a result, it may be possible for an opponent to substitute a key of one size for a key of a different size, which may lead to an attack that recovers the key one part at a time. Presumably, the reason for avoiding a full AlgorithmID is that some of its parameters are message-specific, such as IVs, but perhaps there is some middle ground. Including the key size as an optional field of OtherInfo is one possibility. Other parameters that will be lost in the case of RC5 are the block size and the number of rounds. 8. Section 2.1.2: "Parameters" is misspelled in the definition of the algorithm field. 9. Section 2.1.2: Some additional explanation would be helpful about the relationship between KM and a KEK. In particular, the text might say that to generate a KEK, one generates one or more KMs from the same ZZ, where OtherInfo varies. The variable part of OtherInfo is keyInfo; pubInfo remains the same. Having noted this, the field selections and names seem inappropriate: the fact that keyInfo varies for a given key is contradictory. A preferable organization would be to have keyInfo include the algorithm and optional pubInfo, and put the counter in a field of its own, called keyPart, as in: OtherInfo ::= SEQUENCE { keyInfo KeySpecificInfo, keyPart INTEGER(1..2^32-1) } KeySpecificInfo ::= SEQUENCE { algorithm OBJECT IDENTIFIER, pubInfo OCTET STRING OPTIONAL, keySize INTEGER OPTIONAL } 10. Section 2.1.2: Why can't counter be an INTEGER? That would avoid the unnecessary definition of an encoding format for the counter, while maintaining an unambiguous encoding. 11. Section 2.1.2: Why must pubInfo, if present, contain a minimum of 512 bits? A minimum of 160 bits is sufficient to avoid collisions; the encoding as an OCTET STRING is unambiguous and prevents length-extension attacks. Also, random or nonce might be a better name, since all of otherInfo, not just pubInfo, is public. 12. In general, the different terms for byte ordering should be harmonized or adopted from some other standard: "leftmost", "network byte order", etc. 13. Section 2.1.3: KEK computation states that each algorithm requires a specific size key. But some algorithms have variable-size keys, and it's possible that future algorithms will require more than just a random string (e.g., more structure). So, it would be preferable to say that the currently proposed S/MIME algorithms assume a random string, perhaps with parity changes. 14. Section 2.1.5: Editorial: Change "received public keys" to "a received public key y". Also, add a reference to IEEE P1363 security considerations for more discussion on public-key validation. 15. Section 2.1.6: This 16-byte example doesn't comply with the draft's 160-bit minimum (Section 2.2). 16. Section 2.2: Should a lower bound on the prime p also be given? Why is there a 160-bit minimum on q? (Note that the 128-bit minimum in the same paragraph is inconsistent.) Also, a minimum size on the private key x is inconsistent with saying that x is in the interval [2,q-2]. The first paragraph of this section is missing a parenthesis. Per Sec. 2.2.1.1, we believe that it would be appropriate for the document to state explicitly that alternate parameter generation algorithms MAY be used; P1363 can be cited for discussion. Per Sec. 2.2.1.1, step 6, it would be useful to give a reference to what primality algorithm(s) can be used. 17. Sections 2.3 and 2.4: Key validation is not the only way to prevent a small-subgroup attack. Another method is cofactor multiplication, as described in IEEE P1363 and in [LAW98]. Cofactor multiplication performs an additional operation on the shared secret value so that it is not in a small subgroup. (There is a "compatibility mode" that keeps the shared secret value the same as in ordinary Diffie-Hellman when the system is not under attack; discussion is available in B.S. Kaliski Jr. Compatible cofactor multiplication for Diffie-Hellman primitives. Electronics Letters, 34(25):2396-2397, December 10, 1998.) Another method is to choose the primes p and q so that p = qj + 1 where j is small and to check the received public key against a small set of excluded values. In this case, the leakage due to a small subgroup attack will be only a few bits. Editorial: Change "If the sender cannot" to "If an opponent cannot"; change "failure of decryption" to "failure of a decryption operation by the recipient". 18. General: Replace "S" with "Section" for cross-referencing. 19. Security considerations. The last two paragraphs could be merged into Sections 2.1.5 and 2.2, or at least should be made consistent, so there are not two sources for the same information. In the last paragraph, the effective length of 3DES keys is 112, not 168, due to a meet-in-the-middle attack. In a general design, one looks for a minimum security level and selects algorithms to meet that level. So, for instance, if an 80-bit security level is desired, a designer may choose 3DES or RC2 and a 160-bit minimum subgroup. Selecting the subgroup size to be double the effective key strength, while effective, is more than what is necessary. The subgroup size should be double the desired security level rather than double the symmetric key size. Moreover, there needs to be a prime size selection (1024 bits, 2048 bits, etc.) that matches the desired level. Finally, the selection must take into account the number of users sharing the primes, since it costs only slightly more to compute several discrete logarithms than to compute the first one. Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA16868 for ietf-smime-bks; Wed, 13 Jan 1999 03:06:26 -0800 (PST) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA16864 for ; Wed, 13 Jan 1999 03:06:24 -0800 (PST) Received: from secude.com ([141.12.207.12]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id MAA23620 for ; Wed, 13 Jan 1999 12:07:14 +0100 (MET) Message-ID: <369C7E94.8E82777C@secude.com> Date: Wed, 13 Jan 1999 12:08:04 +0100 From: Stephan =?iso-8859-1?Q?Andr=E9?= Organization: SECUDE GmbH X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: NT SP4 and MIME types Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4B361D56EE7FD97280E17422" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: This is a cryptographically signed message in MIME format. --------------ms4B361D56EE7FD97280E17422 Content-Type: multipart/mixed; boundary="------------C9D22D538CEA281FC843B28E" This is a multi-part message in MIME format. --------------C9D22D538CEA281FC843B28E Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, this is a more 'product related' question: Is it correct that Netscape Messenger does recognize application/x-pkcs7-mime but not application/pkcs7-mime? Is it true for other implementations, too? NT SP4 overwrites the respective HKEY_CLASSES_ROOT entry which causes Outlook (add-ins) to send the new type recommended by RFC 2311 for attachments like smime.p7m. -- Gruß, Stephan André _____________________ http://www.secude.com --------------C9D22D538CEA281FC843B28E Content-Type: text/x-vcard; charset=us-ascii; name="andre.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Stephan André Content-Disposition: attachment; filename="andre.vcf" begin:vcard n:André;Stephan x-mozilla-html:FALSE org:


SECUDE Sicherheitstechnologie
Informationssysteme GmbH
adr:;;Julius-Reiber-Str. 17;Darmstadt;;D-64293;Germany version:2.1 email;internet:andre@secude.com tel;fax:(+49)6151/88 006 - 26 tel;work:(+49)6151/88 006 - 29 x-mozilla-cpt:;65535 fn:Stephan André end:vcard --------------C9D22D538CEA281FC843B28E-- --------------ms4B361D56EE7FD97280E17422 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIFawYJKoZIhvcNAQcCoIIFXDCCBVgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC A4QwggOAMIICaKADAgECAgEQMA0GCSqGSIb3DQEBBQUAMFAxCzAJBgNVBAYTAkRFMRQwEgYD VQQKEwtTRUNVREUgR21iSDErMCkGA1UECxMiU0VDVURFIFRydXN0RmFjdG9yeSBJbmRpdmlk dWFscyBDQTAeFw05ODExMjMxMzE1MThaFw0wMjExMjQxMzE1MThaMDwxCzAJBgNVBA0TAkRF MRQwEgYDVQQKEwtTRUNVREUgR21iSDEXMBUGA1UEAxQOU3RlcGhhbiBBbmRywmUwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAP66MUwCB7rtfznL98KjZ/uj8VAr9GhZs57eBRZzk0NJ zh5JvoW9KZXN7MTDqrK6+LVRcBkiEaFUXd523YGEs6F1oD/G9p8ccMsM95p2PZY3VT6H6epH XX6PrFYOb5mI0yuVzLUCqQb4xx7Cvs4On/MhM/B0hB7yGhh9VRGq2wtXAgMBAAGjgfwwgfkw DgYDVR0PAQH/BAQDAgTwMGwGA1UdEQRlMGOBEGFuZHJlQHNlY3VkZS5jb22BD2FuZHJlQHNl Y3VkZS5kZYE+L289U0VDVURFIEdtYkgsIERhcm1zdGFkdC9vdT1TRUNVREUtQ09NL2NuPVJl Y2lwaWVudHMvY249YW5kcmUwWAYDVR0SBFEwT4EXdHJ1c3RmYWN0b3J5QHNlY3VkZS5jb22G NGh0dHA6Ly93d3cuc2VjdWRlLmNvbS90cnVzdGZhY3RvcnkvaW5kaXZpZHVhbHNjYS5jcnQw DAYDVR0TAQH/BAIwADARBglghkgBhvhCAQEEBAMCALAwDQYJKoZIhvcNAQEFBQADggEBAE65 ho0yo2aSGBystmF3/FNZD2xVEoOJcpwPgzO1Dv7u9WDFetDfcMONg5Ar7a0Ts/BFd1So9hyd gkTBt/Rsath2eM7U+yaOxGnprc1vvLZJVcc52tXlAAdCzUMh0qZZwu/bj43tw/cY+cgAnEyb p8lsarW4hsy4wX4eMG3V+N54t/cRT9Yz5LuEO1J3ukodjeDUqOrlprWxsDX7bQrbH+sLxuPv CLqZOCumL9U6tE8ALWSIJVwshq+ae3fTpowNAIPfI1cWrJOA5o7flg60zSyZkBcBnZw+ONUV AEGuCHMc9Vhzxwgxzb2r4ZMXcWz8WKGA+4ivT59MhUvrhuJAXc4xggGvMIIBqwIBATBVMFAx CzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtTRUNVREUgR21iSDErMCkGA1UECxMiU0VDVURFIFRy dXN0RmFjdG9yeSBJbmRpdmlkdWFscyBDQQIBEDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk5MDExMzExMDgwNVowIwYJKoZIhvcN AQkEMRYEFIRE3g27nHZWk1PQOKOnCxjWIDdqMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMC AgEoMA0GCSqGSIb3DQEBAQUABIGAFFEEXYPzCWF8ZYHJx/hK+BCfRBoH31sv76XVleGgad39 U8B0LotuHTxGjASRrxd3bD1fSmR3sNkz8KO6x44pYF6zGEaL3VjEDJZE2OLpfwyZuOxmK7uM 48+VXI3vYiw5aZ9vIKpFbnoyRdm3JkHMf5Ug+Zeu1X4IlsK7Hs85+RI= --------------ms4B361D56EE7FD97280E17422-- Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA21439 for ietf-smime-bks; Tue, 12 Jan 1999 16:42:54 -0800 (PST) Received: from shell.tsoft.com (root@shell.tsoft.com [207.201.34.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21435 for ; Tue, 12 Jan 1999 16:42:54 -0800 (PST) Received: from cs.stanford.edu ([209.133.59.212]) by shell.tsoft.com (8.8.7/8.8.7) with ESMTP id QAA14274; Tue, 12 Jan 1999 16:36:45 -0800 (PST) Message-ID: <369BEC9A.7A2D6037@cs.stanford.edu> Date: Tue, 12 Jan 1999 16:45:31 -0800 From: Brian Korver Reply-To: briank@cs.stanford.edu X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Russ Housley CC: "Ietf-Smime (E-mail)" Subject: Re: Last Call Comments on CMS-10 References: <4.1.19990112115222.009ca4e0@209.172.119.123> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Russ Housley wrote: > I prefer: > ... However, signed attributes within the signed-data content type and > authenticated attributes within the authenticated-data content type require DER > encoding. Signed attributes and authenticated attributes must be transmitted > in DER form to ensure that recipients can validate a content that contains an > unrecognized attribute. Signed attributes and authenticated attributes are the > only CMS data types that require DER encoding. Agreed. [snip] > I know. This is a philosophy question. Since these identifiers will > eventually be in the IANA registry, I did not know whether or not these values > should be part of the module. > > I would be glad to add these values to the module if the working group thinks > they belong there. Comments? Either include the OIDs, or include a pointer to a document containing the OIDs (that of course, uses the same names). [snip] > >7. Section 5.1: Text on version needs to be expanded to deal with SKI. > >Must be 3 if any SignerInfo version is 3. > > Are you saying that a version 3 SignerInfo should cause parent SignedData > version to be 3? > > Is there a reason to prohibit version 3 SignerInfo from being encapsulated in a > version 1 SignedData? [snip] I can see arguments on each side: If the SignedData version is bumped, that will possibly make some ASN.1 decoders happier. If the SignedData version is left as is, then messages that contain multiple SignerInfos, some of which are v1/v2, may be partially processed. Neither of these are critical (both problems can be programmed around), but I think the later would be better for implementors (although the spec needs to state what to do when there are SignerInfos with "too high" version numbers). On the other hand, my guess would be that bumping the SignedData version number is ASN.1 Best Current Practice. Does anyone know? Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA20865 for ietf-smime-bks; Tue, 12 Jan 1999 15:27:30 -0800 (PST) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA20861 for ; Tue, 12 Jan 1999 15:27:29 -0800 (PST) Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Tue, 12 Jan 1999 15:28:21 -0800 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5BF1@localhost> From: "Jim Schaad (Exchange)" To: "'Russ Housley'" Cc: "Ietf-Smime (E-mail)" Subject: RE: Last Call Comments on CMS-10 Date: Tue, 12 Jan 1999 15:28:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Russ -- Great. > -----Original Message----- > From: Russ Housley [mailto:housley@spyrus.com] > Sent: Tuesday, January 12, 1999 2:32 PM > To: Jim Schaad (Exchange) > Cc: Ietf-Smime (E-mail) > Subject: RE: Last Call Comments on CMS-10 > > > Jim: > > >> >4. Section 5, First pagagraph after the bullets. The text > >> has not been > >> >updated to reflect the SKI addition to the signer info object. > >> > >> Good catch. How about: > >> ... The signer's public key is referenced by an issuer > >> distinguished name along with an issuer-specific serial > >> number or a subject key identifier that uniquely identify > >> the certificate containing the public key. > >> > > > >Wording is good, but I would like "is referenced either by". > > Here it is: > ... The signer's public key is referenced either > by an issuer distinguished name along with an > issuer-specific serial number or by a subject key > identifier that uniquely identifies the certificate > containing the public key. The signer's certificate > may be included in the SignedData certificates field. > > Russ > Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20290 for ietf-smime-bks; Tue, 12 Jan 1999 14:29:57 -0800 (PST) Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20286 for ; Tue, 12 Jan 1999 14:29:56 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA28131; Tue, 12 Jan 1999 17:31:14 -0500 Message-Id: <4.1.19990112172945.0099b100@209.172.119.123> X-Sender: rhousley#mail.spyrus.com@209.172.119.123 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 12 Jan 1999 17:31:53 -0500 To: "Jim Schaad (Exchange)" From: Russ Housley Subject: RE: Last Call Comments on CMS-10 Cc: "Ietf-Smime (E-mail)" In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5BEF@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jim: >> >4. Section 5, First pagagraph after the bullets. The text >> has not been >> >updated to reflect the SKI addition to the signer info object. >> >> Good catch. How about: >> ... The signer's public key is referenced by an issuer >> distinguished name along with an issuer-specific serial >> number or a subject key identifier that uniquely identify >> the certificate containing the public key. >> > >Wording is good, but I would like "is referenced either by". Here it is: ... The signer's public key is referenced either by an issuer distinguished name along with an issuer-specific serial number or by a subject key identifier that uniquely identifies the certificate containing the public key. The signer's certificate may be included in the SignedData certificates field. Russ Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20267 for ietf-smime-bks; Tue, 12 Jan 1999 14:28:31 -0800 (PST) Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA20263 for ; Tue, 12 Jan 1999 14:28:30 -0800 (PST) Message-Id: <4.1.19990112142613.0240e160@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 12 Jan 1999 14:27:49 -0800 To: From: Paul Hoffman / IMC Subject: Re: Last Call Comments on CMS-10 In-Reply-To: <4.1.19990112115222.009ca4e0@209.172.119.123> References: <2FBF98FC7852CF11912A0000000000010FF8A6D7@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 02:35 PM 1/12/99 -0500, Russ Housley wrote: >>3. The algorithm OIDs defined and used in section 12 are not included in the >>ASN module. > >I know. This is a philosophy question. Since these identifiers will >eventually be in the IANA registry, I did not know whether or not these values >should be part of the module. > >I would be glad to add these values to the module if the working group thinks >they belong there. Comments? Please do add them here. It could take a *long* time for them to get into the IANA, and this document should stand on its own. It is common for the IANA registries to start with a set of values that were defined in an RFC. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA20031 for ietf-smime-bks; Tue, 12 Jan 1999 14:12:08 -0800 (PST) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA20026 for ; Tue, 12 Jan 1999 14:12:07 -0800 (PST) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Tue, 12 Jan 1999 14:12:57 -0800 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5BEF@localhost> From: "Jim Schaad (Exchange)" To: "'Russ Housley'" Cc: "Ietf-Smime (E-mail)" Subject: RE: Last Call Comments on CMS-10 Date: Tue, 12 Jan 1999 14:12:56 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Russ: > -----Original Message----- > From: Russ Housley [mailto:housley@spyrus.com] > Sent: Tuesday, January 12, 1999 11:36 AM > To: Jim Schaad (Exchange) > Cc: Ietf-Smime (E-mail) > Subject: Re: Last Call Comments on CMS-10 > > > Jim: > > >1. Section 2, Last paragraph, Sentence 4: I think that > "However, signed > >attributes within the signed-data content type and > authenticated attributes > >within the authenticated-data content type require DER > encoding." should > >read "However, signed attributes within the signed-data content type > >andauthenicated a attributes within the authenticated-data > content type are > >the only places where DER encoding is required." > > I prefer: > ... However, signed attributes within the signed-data > content type and > authenticated attributes within the authenticated-data > content type require DER > encoding. Signed attributes and authenticated attributes > must be transmitted > in DER form to ensure that recipients can validate a content > that contains an > unrecognized attribute. Signed attributes and authenticated > attributes are the > only CMS data types that require DER encoding. This wording is great. > > >3. The algorithm OIDs defined and used in section 12 are not > included in the > >ASN module. > > I know. This is a philosophy question. Since these identifiers will > eventually be in the IANA registry, I did not know whether or > not these values > should be part of the module. > > I would be glad to add these values to the module if the > working group thinks > they belong there. Comments? > > >4. Section 5, First pagagraph after the bullets. The text > has not been > >updated to reflect the SKI addition to the signer info object. > > Good catch. How about: > ... The signer's public key is referenced by an issuer > distinguished name along with an issuer-specific serial > number or a subject key identifier that uniquely identify > the certificate containing the public key. > Wording is good, but I would like "is referenced either by". > >7. Section 5.1: Text on version needs to be expanded to > deal with SKI. > >Must be 3 if any SignerInfo version is 3. > > Are you saying that a version 3 SignerInfo should cause > parent SignedData > version to be 3? > > Is there a reason to prohibit version 3 SignerInfo from being > encapsulated in a > version 1 SignedData? This is the backwards compatability thing. Everywhere else we have done -- you get a new version all the way up (See EnvelopedData) if you do something new on an inner object. This prevents you from starting something you may regret. If we don't do this here, then I don't see why we should be doing it in EnvelopedData. I don't care which of the two we correct, but make them consistant. > > >10. Section 12.3.1, paragraph 3. I would like to change the > first sentence > >to "A CMS Implementation should support mixed key-encryption and > >content-encryption algorithms." > > Disgree. I am reluctant to change "may" to "should." What > do other people > think? > > >11. Section 12.3.3 - Please insert the following paragraph > in this section > >" A CMS implementation should support mixed key-encryption > and content- > > encryption algorithms. For example, a 128-bit RC2 > content-encryption > > key may be wrapped with 168-bit Triple-DES key-encryption key. > > Similarly, a 40-bit RC2 content-encryption key may be wrapped with > > 128-bit RC2 key-encryption key." > > As with comment 10, I would like to hear what other people > think before > changing "may" to "should." Can I at least get you to agree to put in the paragraph with the "may" syntax even if I get no support for "should"? > > >12. Ditto 11 for section 12.6 > > Ditto. As with comments 10 and 11, I would like to hear what > other people > think before changing "may" to "should." > > > Russ > jim Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19895 for ietf-smime-bks; Tue, 12 Jan 1999 13:59:06 -0800 (PST) Received: from thehub.knight-hub.com (root@thehub.knight-hub.com [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19890 for ; Tue, 12 Jan 1999 13:59:05 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id RAA26719; Tue, 12 Jan 1999 17:00:23 -0500 Message-Id: <4.1.19990112115222.009ca4e0@209.172.119.123> Message-Id: <4.1.19990112115222.009ca4e0@209.172.119.123> Message-Id: <4.1.19990112115222.009ca4e0@209.172.119.123> X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 12 Jan 1999 14:35:37 -0500 To: "Jim Schaad (Exchange)" From: Russ Housley Subject: Re: Last Call Comments on CMS-10 Cc: "Ietf-Smime (E-mail)" In-Reply-To: <2FBF98FC7852CF11912A0000000000010FF8A6D7@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: