From owner-ietf-smime Sun Dec 22 14:26:46 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id OAA04417 for ietf-smime-bks; Sun, 22 Dec 1996 14:26:46 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-mimesec using -f Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id OAA04412 for ; Sun, 22 Dec 1996 14:26:44 -0800 (PST) X-Sender: phoffman@mail.proper.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 22 Dec 1996 14:29:05 -0800 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: Beginning of the SMIME BOF Sender: owner-ietf-mimesec@imc.org Precedence: bulk Greetings. As you can tell, the ietf-smime mailing list is now active. As mentioned in the first response letter you got, there is a Web site for the BOF at . That site has a copy of the current draft of the SMIME message format document as well as related materials. This mailing list serves as the work environment for the BOF (Birds Of a Feather) group that was first convened at the IETF meeting in San Jose earlier this month. The idea of the BOF was to create IETF standards for Internet mail that is secured with S/MIME. Thus, there are three things this list should do in the short run: - decide what are the technical issues that need to be addressed - create a Working Group charter with deliverables and milestones - create drafts of the technical work Please note that this mailing list is meant to work like the mailing lists for full IETF Working Groups. As such, it is *not* a place to discuss SMIME implementation issues or to ask questions like "who is shipping SMIME products?". There is, however, another mailing list for that purpose, "smime-dev@rsa.com" (subscribe by sending mail to "smime-dev-request@rsa.com" with the message "subscribe"). RSA, the original creators of S/MIME, also have a Web page with a great deal of implementation information at . So, let's start discussing what to do next! --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Mon Dec 30 12:40:06 1996 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id MAA04744 for ietf-smime-bks; Mon, 30 Dec 1996 12:40:06 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from starfish.netscape.com (h-205-217-237-33.netscape.com [205.217.237.33]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id MAA04740 for ; Mon, 30 Dec 1996 12:40:03 -0800 (PST) Received: from pixie.mcom.com (pixie.mcom.com [205.217.237.112]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id MAA18344 for <@starfish.mcom.com:ietf-smime@imc.org>; Mon, 30 Dec 1996 12:40:13 -0800 (PST) Received: from pixie.mcom.com (localhost [127.0.0.1]) by pixie.mcom.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id MAA18933 for ; Mon, 30 Dec 1996 12:44:23 -0800 To: ietf-smime@imc.org Path: news From: Mark Inokuchi Newsgroups: mcom.list.ietf-smime Subject: test Date: Mon, 30 Dec 1996 12:47:57 -0800 Organization: Another Netscape News Server User Lines: 2 Message-ID: <32C82A7D.1CFB@netscape.com> NNTP-Posting-Host: denali.mcom.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0GoldC (X11; U; IRIX 6.2 IP22) Sender: owner-ietf-smime@imc.org Precedence: bulk test test From owner-ietf-smime Thu Jan 2 11:15:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id KAA09680 for ietf-smime-bks; Thu, 2 Jan 1997 10:22:06 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from novell.com (sjf-mail20.sjf.novell.com [130.57.10.171]) by mail.proper.com (8.8.4/8.7.3) with SMTP id KAA09676 for ; Thu, 2 Jan 1997 10:22:02 -0800 (PST) Received: from INET-SJF-Message_Server by novell.com with Novell_GroupWise; Thu, 02 Jan 1997 10:20:50 -0800 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 02 Jan 1997 10:20:28 -0800 From: Arup Biswas To: ietf-smime@imc.org, smime-dev@RSA.COM Subject: List of algorithms - need your feedback Sender: owner-ietf-smime@imc.org Precedence: bulk Hi All, I was wondering if there has been a consensus about the cryptographic algorithms to be used for various cryptographic operations in S/MIME. I have compiled a list of such algorithms from some RSA guideline documents. Please, feel free to Add/Delete/Modify/ Comment on this list. If necessarry, I will post a summary at the end of the discussion. Content Encryption: RC2 in CBC mode DES EDE3 CBC DES CBC RC5 CBC Digest Algorithm: sha -1 MD2 MD5 Digest Encryption Algorithm: rsaEncryption Key Encryption Algorithm: rsaEncryption Cheers, --Arup From owner-ietf-smime Wed Jan 8 11:57:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id JAA20456 for ietf-smime-bks; Wed, 8 Jan 1997 09:31:38 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id JAA20452 for ; Wed, 8 Jan 1997 09:31:35 -0800 (PST) X-Sender: phoffman@mail.proper.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jan 1997 09:31:26 -0800 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: First cut of a WG charter Sender: owner-ietf-smime@imc.org Precedence: bulk Greetings again. In the interest of generating a bit more (as in, some) action here, I'd like to start the discussion off with a proposed working group charter and milestones for the S/MIME WG. Please feel free to bash away. Description of the Working Group: S/MIME is a method for encrypting and/or authenticating MIME data. The definition of S/MIME falls into three areas: * Description of the overall message format * Description of the security portions of the message * Defaults, options, and extensions of the security portions The first area, the message format, has already been submitted to the IETF ("draft-dusse-mime-msg-spec"). The second area, the security portions, are defined by RSA's PKCS #7 and PKCS #10 specifications. These may be published as Informational RFCs, eventually. The third area, security profile, is the main task of this current effort, in order to insure interoperability of S/MIME-compliant programs. In order to create a complete (and more perfect) specification, the Working Group must fully specify the message format, as well as the minimum security profile needed in order for two mail clients to communicate. The profile must also include other optional security mechanisms, such as additional hashing algorithms, as well as a method for syncrhonize two S/MIME agents that have never communicated to determine which of the optional mechanisms can be used in future messages. Further, the profile must specify an extension registration mechanism (probably through IANA) so that future security protocols can be included in S/MIME. A modestly aggressive schedule is specified, due to the amount of existing work on S/MIME. Goals and Milestones: February 1997: Revised draft of the message format document March 1997: Submit PKCS #7 and PKCS #10 as Informational RFCs March 1997: Draft of security profile document April 1997: Submit message format document for standards track May 1997: Revised draft of the security profile document June 1997: Submit security profile document, submit for standards track --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Tue Jan 14 09:46:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id JAA27318 for ietf-smime-bks; Tue, 14 Jan 1997 09:46:20 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from novell.com (sjf-mail20.sjf.novell.com [130.57.10.171]) by mail.proper.com (8.8.4/8.7.3) with SMTP id JAA27314 for ; Tue, 14 Jan 1997 09:46:18 -0800 (PST) Received: from INET-SJF-Message_Server by novell.com with Novell_GroupWise; Tue, 14 Jan 1997 09:45:24 -0800 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 14 Jan 1997 09:45:01 -0800 From: Arup Biswas To: ietf-smime@imc.org, smime-dev@RSA.COM Subject: Want Enveloped Message Sender: owner-ietf-smime@imc.org Precedence: bulk Hi All, Thanks to all those who responded to my previous call for Signed Data Message testing. I have been able to read majority of them successfully. I am still in the process of testing and would appreciate more Signed Data Messages. However, this time I would like to start testing Enveloped Messages. So, please send me enveloped messages as many as you can. I would appreciate any pointer to any archive of Enveloped Messages too. Note: I am attaching my certificate for secret key encryption. Thanks for your cooperation, Arup Biswas, Software Engineer, Novell Inc. begin 644 DLAI.B64 M34E)0E9J0T-!44-G07=)0D%!24)%:D%.0F=K<6AK:4$U-4E%W M16=91%9144Q%=W1*4U51=&1'5GID0S%$451!949W,#5.>D%X341C=PT*3411 M,TUJ1F%&=S`U3GI!,TU$67=-1%$S36I&84U$37A%:D%10F=.5D)!351#55)H M9&UL:TE%>&AA5$5-34%O1PT*03%514-X341A5VQK35$X=T11641645%+17=: M=6(S6FQB1W=W6$1!3D)G:W%H:VE'.7D%!97!U=G5(=310-6-+9C4W1G5H1V]K;WEN>&]R2')/,S)*66%I979V >:W140G%4=E; Thu, 16 Jan 1997 09:45:00 -0800 (PST) X-Sender: phoffman@mail.proper.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Jan 1997 09:45:40 -0800 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: Are we interesting in becoming a Working Group? Sender: owner-ietf-smime@imc.org Precedence: bulk Greetings again. I'm pretty surprised at the lack of discussion on this list, even after I proposed the first cut of a WG charter. About 125 people have signed up to be on this mailing list, and there were certainly lots of people in the room for the SMIME BOF in San Jose last month. Without a Working Group, it will be harder to move SMIME into full IETF specification, which is the stated intention of RSA. There are still some tough issues to resolve, such as default choices for encryption algorithm and the extension mechanism. At the BOF, there were many comments about changes people wanted to see in the current SMIME spec, and there should be a forum for that kind of discussion. Further, only one of the four documents needed to turn this into a full spec has been submitted to the IETF. Having a Working Group with a document editor and chairman could help change this and get the process moving. Of course, if no one is interested in doing the work in the Working Group, it shouldn't form. However, given the great interest in San Jose and the general industry desire to not have more than one email security protocol (PGP/MIME is already an Experimental RFC), I think things should get moving. Again, please take a look at the rough proposed charter I suggested, and please feel free to make comments and criticisms here on the mailing list. You can find my proposed charter in the mailing list archive at . --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Thu Jan 16 13:00:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id NAA24710 for ietf-smime-bks; Thu, 16 Jan 1997 13:00:12 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from novell.com (sjf-mail20.sjf.novell.com [130.57.10.171]) by mail.proper.com (8.8.4/8.7.3) with SMTP id NAA24706 for ; Thu, 16 Jan 1997 13:00:09 -0800 (PST) Received: from INET-SJF-Message_Server by novell.com with Novell_GroupWise; Thu, 16 Jan 1997 12:59:17 -0800 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Thu, 16 Jan 1997 12:38:05 -0800 From: Arup Biswas To: ietf-smime@imc.org, smime-dev@RSA.COM Subject: WG Charter Sender: owner-ietf-smime@imc.org Precedence: bulk Hi All, One small detail for the WG to resolve, we need to establish a protocol about the certificates field in the Signed Data message. Do we keep a single certificate or the chain? Trusted Root Certificate first or last? Similarly for the CRLs. Thanks, --Arup Biswas Software Engineer, Novell Inc. Greetings again. In the interest of generating a bit more (as in, some) action here, I'd like to start the discussion off with a proposed working group charter and milestones for the S/MIME WG. Please feel free to bash away. Description of the Working Group: S/MIME is a method for encrypting and/or authenticating MIME data. The definition of S/MIME falls into three areas: * Description of the overall message format * Description of the security portions of the message * Defaults, options, and extensions of the security portions The first area, the message format, has already been submitted to the IETF ("draft-dusse-mime-msg-spec"). The second area, the security portions, are defined by RSA's PKCS #7 and PKCS #10 specifications. These may be published as Informational RFCs, eventually. The third area, security profile, is the main task of this current effort, in order to insure interoperability of S/MIME-compliant programs. In order to create a complete (and more perfect) specification, the Working Group must fully specify the message format, as well as the minimum security profile needed in order for two mail clients to communicate. The profile must also include other optional security mechanisms, such as additional hashing algorithms, as well as a method for syncrhonize two S/MIME agents that have never communicated to determine which of the optional mechanisms can be used in future messages. Further, the profile must specify an extension registration mechanism (probably through IANA) so that future security protocols can be included in S/MIME. A modestly aggressive schedule is specified, due to the amount of existing work on S/MIME. Goals and Milestones: February 1997: Revised draft of the message format document March 1997: Submit PKCS #7 and PKCS #10 as Informational RFCs March 1997: Draft of security profile document April 1997: Submit message format document for standards track May 1997: Revised draft of the security profile document June 1997: Submit security profile document, submit for standards track --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Sat Jan 18 10:47:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id KAA19415 for ietf-smime-bks; Sat, 18 Jan 1997 10:47:26 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from relay1.shore.net (root@relay1.shore.net [192.233.85.129]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id KAA19411 for ; Sat, 18 Jan 1997 10:47:23 -0800 (PST) Received: from canon (Cust89.Max20.San-Francisco.CA.MS.UU.NET [153.35.243.89]) by relay1.shore.net (8.8.3/8.8.3) with ESMTP id NAA21606; Sat, 18 Jan 1997 13:47:24 -0500 (EST) Message-Id: <199701181847.NAA21606@relay1.shore.net> From: "Jeff Thompson" To: "Arup Biswas" , , Subject: Re: WG Charter Date: Thu, 3 Jan 1980 10:47:11 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk > From: Arup Biswas > One small detail for the WG to resolve, we need to establish a protocol > about the certificates field in the Signed Data message. Do we keep a > single certificate or the chain? Trusted Root Certificate first or last? > Similarly for the CRLs. I think you should push as many certificates when sending a message that you think will help the recipient validate your public key. As for the certificates field, it is a SET OF, not a SEQUENCE OF. Therefore, there is no meaning to the order of certificates found in there. In fact, if someone's software is automatically encoding as DER (as opposed to BER) then the ordering will be strictly according to the encoded bytes of each certificate - that is, irrelevant of the meaning of each certificate. The certificates field is therefore an unordered "bag o' certificates". The same goes for CRLs. I don't want to get into the argument about the Trusted Root Certificate: whether it is a self-signed certificate, how it is in fact "trusted". Some applications also send self-signed certificates for the signer of the message (not the root) to support non-hierarchical certification schemes so the sender can send a certificate for him/herself which is not created by a third party. But again, the "Trusted Root Certificate" would not come first or last in the SET OF certificates. From owner-ietf-smime Mon Jan 20 14:03:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id OAA13138 for ietf-smime-bks; Mon, 20 Jan 1997 14:03:12 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from novell.com (sjf-mail20.sjf.novell.com [130.57.10.171]) by mail.proper.com (8.8.4/8.7.3) with SMTP id OAA13134 for ; Mon, 20 Jan 1997 14:03:10 -0800 (PST) Received: from INET-SJF-Message_Server by novell.com with Novell_GroupWise; Mon, 20 Jan 1997 14:02:52 -0800 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 20 Jan 1997 14:02:24 -0800 From: Arup Biswas To: jefft@shore.net Cc: ietf-smime@imc.org, smime-dev@RSA.COM Subject: Certificates Field in Signed Data Sender: owner-ietf-smime@imc.org Precedence: bulk >>> "Jeff Thompson" 01/03/80 07:47am >>> >I think you should push as many certificates when sending a message >that you think will help the recipient validate your public key. >As for the certificates field, it is a SET OF, not a SEQUENCE OF. >Therefore, there is no meaning to the order of certificates found in >there. >n fact, if someone's software is automatically encoding as DER >(as opposed to BER) then the ordering will be strictly according to the >encoded bytes of each certificate - that is, irrelevant of the meaning of >each certificate. The certificates field is therefore an unordered >"bag o' certificates". The same goes for CRLs. >I don't want to get into the argument about the Trusted Root Certificate: >whether it is a self-signed certificate, how it is in fact "trusted". Some >applications also send self-signed certificates for the signer of the >message >(not the root) to support non-hierarchical certification schemes so the >sender can >send a certificate for him/herself which is not created by a third party. >But again, the "Trusted Root Certificate" would not come first or last >in the SET OF certificates. Jeff, I think you are right. In the current version of PKCS7 Signed Data format certificates field is indeed a SET OF which means an ordered collection of Certificates. But My question is more fundamental. Do we fit our requirement according to the syntax or do we modify the syntax according to our requirements? In other words, could we make the certificates fields as a SEQUENCE OF instead of a SET OF in the next version of PKCS7 Signed Data? This is only a suggestion. Why don't we brainstorm this issue? The issue is the following: I get a signed Data message, I decode it, get a bunch of certificates (provided it has been attached). Now, what would be the simplest way to select the certificate of the signer and verify the whole chain? I am proposing let the syntax indicate a mechanism to select the signer's certificate and the Root Certificate. I would like to hear other's opinion too. Regards, --Arup Biswas Software Engineer, Novell > From: Arup Biswas > One small detail for the WG to resolve, we need to establish a protocol > about the certificates field in the Signed Data message. Do we keep a > single certificate or the chain? Trusted Root Certificate first or last? > Similarly for the CRLs. From owner-ietf-smime Mon Jan 20 15:46:21 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id PAA14075 for ietf-smime-bks; Mon, 20 Jan 1997 15:46:21 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from peapod.deming.com (host20.deming.com [206.63.131.20]) by mail.proper.com (8.8.4/8.7.3) with SMTP id PAA14071 for ; Mon, 20 Jan 1997 15:46:17 -0800 (PST) Received: by peapod.deming.com from localhost (router,SLmail V2.0); Mon, 20 Jan 1997 15:47:40 Pacific Standard Time Received: by peapod.deming.com from seth (206.63.131.30::mail daemon; unverified,SLmail V2.0); Mon, 20 Jan 1997 15:47:39 Pacific Standard Time Message-Id: <3.0.32.19970120154449.0091fdb0@mail.craswell.com> X-Sender: blaker@mail.craswell.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 20 Jan 1997 15:44:50 -0800 To: Arup Biswas , jefft@shore.net From: "Blake Ramsdell" Subject: Re: Certificates Field in Signed Data Cc: ietf-smime@imc.org, smime-dev@RSA.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk At 02:02 PM 1/20/97 -0800, Arup Biswas wrote: > >I think you are right. In the current version of PKCS7 Signed Data format >certificates field is indeed a SET OF which means an ordered collection >of Certificates. You mean unordered, right? >But My question is more fundamental. Do we fit our requirement >according to the syntax or do we modify the syntax according to our >requirements? > >In other words, could we make the certificates fields as a SEQUENCE >OF instead of a SET OF in the next version of PKCS7 Signed Data? >This is only a suggestion. Why don't we brainstorm this issue? It seems reasonable that for size or other reasons someone might not want to send anything in the bag o' certs and put the responsibility on the receiving entity to find the signing certificate and any other certificates required to satisfy the trust requirements of the receiver. It also seems likely that people are going to want to push other certificates than the ones that are required to validate the signature or signing certificate trust (in the case of a dual key model where the signing and enveloping certificates are separate, you may want to push both the signing and enveloping certificates and their respective chains). I think that the current wording of the use of ExtendedCertificatesAndCertificates in the S/MIME implementation guide is appropriate -- the sender should put in the signing certificate and certificate chain, and the receiver should be prepared to accept anything in any order, but other stuff can go in there also if it's useful. Being too restrictive in this case will probably hurt, especially in the dual key model that I mentioned before. >The issue is the following: I get a signed Data message, I decode it, >get a bunch of certificates (provided it has been attached). Now, >what would be the simplest way to select the certificate of the signer >and verify the whole chain? Each of the SignerInfo types in the signerInfos has an issuerAndSerialNumber member that can be compared against the received certificates. After that point, you need to enforce your own rules as to your validation of that certificate (in the case of the hierarchy model, you look up the issuer of the parent certificate, and continue on up the chain until the trusted root). I'm guessing that you are looking for an easier way, but I'm not sure that there is one. In our case, we maintain a local cache database that has certificates indexed by issuerAndSerialNumber and also by subject, and root keys that are indexed by subject. Finding the chain is a matter of doing lookups by issuerAndSerialNumber and by subject (by issuerAndSerialNumber for the signing cert, and then looking up root keys or certificates by subject, keeping in mind that multiple certificates can have the same subject). In any case, I think the PKCS #7 syntax is fine. We may want to clarify the philosophy a little better in the S/MIME implementation guide, however, especially with regard to the transmission of self-signed root keys. Blake From owner-ietf-smime Mon Jan 20 20:38:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id UAA16340 for ietf-smime-bks; Mon, 20 Jan 1997 20:38:37 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from netcomsv.netcom.com (uucp13.netcom.com [163.179.3.13]) by mail.proper.com (8.8.4/8.7.3) with SMTP id UAA16336 for ; Mon, 20 Jan 1997 20:38:34 -0800 (PST) Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id UAA14217; Mon, 20 Jan 1997 20:27:39 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA853820682 Mon, 20 Jan 97 20:24:42 Date: Mon, 20 Jan 97 20:24:42 From: "Housley, Russ" Message-Id: <9700208538.AA853820682@spysouth.spyrus.com> To: ietf-smime@imc.org, smime-dev@RSA.COM, "Jeff Thompson" Subject: Re: WG Charter Sender: owner-ietf-smime@imc.org Precedence: bulk Jeff: > As for the certificates field, it is a SET OF, not a SEQUENCE OF. > Therefore, there is no meaning to the order of certificates found in > there. In fact, if someone's software is automatically encoding as DER > (as opposed to BER) then the ordering will be strictly according to the > encoded bytes of each certificate - that is, irrelevant of the meaning of > each certificate. The certificates field is therefore an unordered > "bag o' certificates". The same goes for CRLs. The use of "SEQUENCE OF" is necessary when order is important, but it can also be used when order is not important. And, it has much less overhead that "SET OF" when DER is used since a sort is not required. Either "SEQUENCE OF" or "SET OF" can be used to carry a "bag o' certificates". I see no benefit to "SET OF." Russ From owner-ietf-smime Tue Jan 21 09:51:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id JAA25752 for ietf-smime-bks; Tue, 21 Jan 1997 09:51:07 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from novell.com (sjf-mail20.sjf.novell.com [130.57.10.171]) by mail.proper.com (8.8.4/8.7.3) with SMTP id JAA25748 for ; Tue, 21 Jan 1997 09:51:04 -0800 (PST) Received: from INET-SJF-Message_Server by novell.com with Novell_GroupWise; Tue, 21 Jan 1997 09:50:47 -0800 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Tue, 21 Jan 1997 09:50:11 -0800 From: Arup Biswas To: blaker@craswell.com Cc: ietf-smime@imc.org, smime-dev@RSA.COM Subject: Re: Certificates Field in Signed Data -Reply Sender: owner-ietf-smime@imc.org Precedence: bulk >>> "Blake Ramsdell" 01/20/97 03:44pm >>> >>You mean unordered, right? Yes, thanks for the correction. >>It seems reasonable that for size or other reasons someone might not >>want >>to send anything in the bag o' certs and put the responsibility on the >>receiving entity to find the signing certificate and any other certificates >>required to satisfy the trust requirements of the receiver. It also >>seems >>likely that people are going to want to push other certificates than the >>ones that are required to validate the signature or signing certificate >>trust (in the case of a dual key model where the signing and >>enveloping >>certificates are separate, you may want to push both the signing and >>enveloping certificates and their respective chains). >>I think that the current wording of the use of >>ExtendedCertificatesAndCertificates in the S/MIME implementation >>guide is >>appropriate -- the sender should put in the signing certificate and >>certificate chain, and the receiver should be prepared to accept >>anything >>in any order, but other stuff can go in there also if it's useful. >>Being too restrictive in this case will probably hurt, especially in the >>dual key model that I mentioned before. >>Each of the SignerInfo types in the signerInfos has an >>issuerAndSerialNumber member that can be compared against the >>received >>certificates. After that point, you need to enforce your own rules as >>to >>your validation of that certificate (in the case of the hierarchy model, >>you look up the issuer of the parent certificate, and continue on up the >>chain until the trusted root). I'm guessing that you are looking for an >>easier way, but I'm not sure that there is one. In our case, we >>maintain a >>local cache database that has certificates indexed by >>issuerAndSerialNumber >>and also by subject, and root keys that are indexed by subject. >>Finding >>the chain is a matter of doing lookups by issuerAndSerialNumber and >>by >>subject (by issuerAndSerialNumber for the signing cert, and then >>looking up >>root keys or certificates by subject, keeping in mind that multiple >>certificates can have the same subject). >>In any case, I think the PKCS #7 syntax is fine. We may want to clarify >>the philosophy a little better in the S/MIME implementation guide, >>however, >>especially with regard to the transmission of self-signed root keys. >>Blake Blake, I think you have convinced me why an order can not *always* be imposed on the certificates field . But, I think you have overlooked the cases when an order can be imposed between the negotiating parties. For example, PKCS #7 used in the degenerated cases for Certificate/CRL Retrieval. My point is in such cases if the negotiating parties want to impose an order the syntax should not be a hindrance; currently, the SET OF DER encoding destroys such orders (tell me if I'm wrong). On the other hand an ordered collection such as SEQUENCE OF does not necessarily mean you have to impose an order, it merely assures that if any such order was imposed at the time of creation it will not be disturbed afterwards. So you have the flexibility to go either way. The optional inclusion of certificate that you have mentioned is also satisfied by SEQUENCE OF. Cheers, --Arup From owner-ietf-smime Wed Jan 22 01:59:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id BAA01697 for ietf-smime-bks; Wed, 22 Jan 1997 01:59:59 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id BAA01692 for ; Wed, 22 Jan 1997 01:59:55 -0800 (PST) Received: from [156.106.136.4] (gid002.cicg.itu.ch [156.106.136.4]) by ng.netgate.net (8.8.4/8.6.9) with ESMTP id CAA23440; Wed, 22 Jan 1997 02:00:48 -0800 (PST) X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <9700208538.AA853820682@spysouth.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jan 1997 23:48:46 +0100 To: "Housley, Russ" From: Dave Crocker Subject: Re: WG Charter Cc: ietf-smime@imc.org, smime-dev@RSA.COM Sender: owner-ietf-smime@imc.org Precedence: bulk At 8:24 PM +0100 1/20/97, Housley, Russ wrote: >The use of "SEQUENCE OF" is necessary when order is important, but it can >also be used when order is not important. And, it has much less overhead Just to see whether my interpretation of your statement is accurate: Your view is that it is ok to impose a required order in all cases? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-smime Wed Jan 22 15:36:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id PAA10236 for ietf-smime-bks; Wed, 22 Jan 1997 15:36:26 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from peapod.deming.com (host20.deming.com [206.63.131.20]) by mail.proper.com (8.8.4/8.7.3) with SMTP id PAA10232 for ; Wed, 22 Jan 1997 15:36:23 -0800 (PST) Received: by peapod.deming.com from localhost (router,SLmail V2.0); Wed, 22 Jan 1997 15:37:40 Pacific Standard Time Received: by peapod.deming.com from seth (206.63.131.30::mail daemon; unverified,SLmail V2.0); Wed, 22 Jan 1997 15:37:39 Pacific Standard Time Message-Id: <3.0.32.19970122153523.00929bf0@mail.craswell.com> X-Sender: blaker@mail.craswell.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 22 Jan 1997 15:35:24 -0800 To: Dave Crocker , "Housley, Russ" From: "Blake Ramsdell" Subject: Re: WG Charter Cc: ietf-smime@imc.org, smime-dev@RSA.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk At 11:48 PM 1/21/97 +0100, Dave Crocker wrote: >At 8:24 PM +0100 1/20/97, Housley, Russ wrote: >>The use of "SEQUENCE OF" is necessary when order is important, but it can >>also be used when order is not important. And, it has much less overhead > > Just to see whether my interpretation of your statement is accurate: > >Your view is that it is ok to impose a required order in all cases? I think this is more along the lines of "the sender put these in a specific order, and the receiver will get them in that same order, in the event that anyone ever wants to associate semantics with the order", not necessarily that there is an imposed, required order (even though one could be specified). Then again, I'm not Russ, so he could have something else in mind entirely. Blake From owner-ietf-smime Thu Jan 23 14:13:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id OAA20853 for ietf-smime-bks; Thu, 23 Jan 1997 14:13:23 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from netcomsv.netcom.com (uucp6.netcom.com [163.179.3.6]) by mail.proper.com (8.8.4/8.7.3) with SMTP id OAA20848 for ; Thu, 23 Jan 1997 14:13:20 -0800 (PST) Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id LAA16249; Thu, 23 Jan 1997 11:55:40 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA854048561 Thu, 23 Jan 97 11:42:41 Date: Thu, 23 Jan 97 11:42:41 From: "Housley, Russ" Message-Id: <9700238540.AA854048561@spysouth.spyrus.com> To: dcrocker@brandenburg.com CC: ietf-smime@imc.org, smime-dev@RSA.COM Subject: Re: WG Charter Sender: owner-ietf-smime@imc.org Precedence: bulk At 11:48 PM 1/21/97 +0100, Dave Crocker wrote: >At 8:24 PM +0100 1/20/97, Housley, Russ wrote: >>The use of "SEQUENCE OF" is necessary when order is important, but it can >>also be used when order is not important. And, it has much less overhead > > Just to see whether my interpretation of your statement is accurate: > >Your view is that it is ok to impose a required order in all cases? No. Just because the use of "SEQUENCE OF" will preserve the order chosen by the sender does not mean that there is any semantic meaning to the ordering. I object to the use of "SET OF" with the Distinguished Encoding Rules (DER) because it imposes an order. The "SET OF" encoding must place the membership in sorted order. When one of these constructs is digitally signed, the validator must compute the hash (a.k.a. digest) over the same sequence of bits. In either case, the cheapest processing to achieve this is to use the order presented by the originator. In the "SEQUENCE OF" case, there is no laternative. In the "SET OF" case, the recipient could re-sort the members, but there is no need to do this if the order used bu the originator is preserved by the ASN.1 software . Russ From owner-ietf-smime Thu Jan 23 15:01:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id PAA21174 for ietf-smime-bks; Thu, 23 Jan 1997 15:01:44 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from europa.salford.ac.uk (europa.salford.ac.uk [146.87.3.2]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id PAA21169 for ; Thu, 23 Jan 1997 15:01:39 -0800 (PST) Message-Id: <199701232301.PAA21169@mail.proper.com> Received: from man-082.dialup.zetnet.co.uk by europa.salford.ac.uk with SMTP (PP); Thu, 23 Jan 1997 23:01:47 +0000 Comments: Authenticated sender is From: David Chadwick To: Arup Biswas , jefft@shore.net, Blake Ramsdell Date: Thu, 23 Jan 1997 23:06:21 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Certificates Field in Signed Data Reply-to: D.W.Chadwick@iti.salford.ac.uk CC: ietf-smime@imc.org, smime-dev@RSA.COM X-mailer: Pegasus Mail for Windows (v2.42) Sender: owner-ietf-smime@imc.org Precedence: bulk > It seems reasonable that for size or other reasons someone might not want > to send anything in the bag o' certs and put the responsibility on the > receiving entity to find the signing certificate and any other certificates > required to satisfy the trust requirements of the receiver. Ok, fine, that is the senders choice. But this has no effect on the SET or SEQUENCE issue, since an empty sequence or empty set are the same thing :-) > It also seems > likely that people are going to want to push other certificates than the > ones that are required to validate the signature or signing certificate > trust (in the case of a dual key model where the signing and enveloping > certificates are separate, you may want to push both the signing and > enveloping certificates and their respective chains). > This is an arguement for a SET OF SEQUENCES in my opinion > I think that the current wording of the use of > ExtendedCertificatesAndCertificates in the S/MIME implementation guide is > appropriate -- the sender should put in the signing certificate and > certificate chain, and the receiver should be prepared to accept anything > in any order, but other stuff can go in there also if it's useful. > > Being too restrictive in this case will probably hurt, especially in the > dual key model that I mentioned before. But being too loose creates work for the receiver, does it not? > > >The issue is the following: I get a signed Data message, I decode it, > >get a bunch of certificates (provided it has been attached). Now, > >what would be the simplest way to select the certificate of the signer > >and verify the whole chain? > > Each of the SignerInfo types in the signerInfos has an > issuerAndSerialNumber member that can be compared against the received > certificates. After that point, you need to enforce your own rules as to > your validation of that certificate (in the case of the hierarchy model, > you look up the issuer of the parent certificate, and continue on up the > chain until the trusted root). I'm guessing that you are looking for an > easier way, but I'm not sure that there is one. That seems to be the easiest way to me, following a chain. >In our case, we maintain a > local cache database that has certificates indexed by issuerAndSerialNumber > and also by subject, and root keys that are indexed by subject. Finding > the chain is a matter of doing lookups by issuerAndSerialNumber and by > subject (by issuerAndSerialNumber for the signing cert, and then looking up > root keys or certificates by subject, keeping in mind that multiple > certificates can have the same subject). Yes, but if you have a local database, you dont really need any certificates to be passed to you do you? Except to add more to your database. I think that the certificates in the message are for receivers who dont have a general certificate database, but who only have a very small set of trusted root keys. And to help them, one or more chains of certificates seems to be the best. > > In any case, I think the PKCS #7 syntax is fine. We may want to clarify > the philosophy a little better in the S/MIME implementation guide, however, > especially with regard to the transmission of self-signed root keys. > > Blake > > *************************************************** David W Chadwick IT Institute, University of Salford, Salford M5 4WT Tel +44 161 745 5351 Fax +44 161 745 8169 Email D.W.Chadwick@iti.salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm *************************************************** From owner-ietf-smime Thu Jan 23 15:01:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id PAA21173 for ietf-smime-bks; Thu, 23 Jan 1997 15:01:43 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from europa.salford.ac.uk (europa.salford.ac.uk [146.87.3.2]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id PAA21165 for ; Thu, 23 Jan 1997 15:01:38 -0800 (PST) Message-Id: <199701232301.PAA21165@mail.proper.com> Received: from man-082.dialup.zetnet.co.uk by europa.salford.ac.uk with SMTP (PP); Thu, 23 Jan 1997 23:01:38 +0000 Comments: Authenticated sender is From: David Chadwick To: Arup Biswas , ietf-smime , smime-dev , Jeff Thompson Date: Thu, 23 Jan 1997 23:06:21 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: WG Charter Reply-to: D.W.Chadwick@iti.salford.ac.uk X-mailer: Pegasus Mail for Windows (v2.42) Sender: owner-ietf-smime@imc.org Precedence: bulk > From: Jeff Thompson > To: Arup Biswas , ietf-smime , > smime-dev > Subject: Re: WG Charter > Date: Thu, 3 Jan 1980 10:47:11 -0500 > > From: Arup Biswas > > > One small detail for the WG to resolve, we need to establish a protocol > > about the certificates field in the Signed Data message. Do we keep a > > single certificate or the chain? Trusted Root Certificate first or last? > > Similarly for the CRLs. > > I think you should push as many certificates when sending a message > that you think will help the recipient validate your public key. > Agreed in principle, but you will normally know the order in which to push them, it is not just any old random set of certificates, is it? > As for the certificates field, it is a SET OF, not a SEQUENCE OF. This is odd. The X.509 spec uses SEQUENCE for its forward and reverse certification paths, so why are we using SET ? This places unnecessary burden on the receiver to sort out the jumble. If we are going to go for a SEQUENCE (or SET OF SEQUENCES which solves the multiple key problem), two alternative schemes are possible. Start with the trusted root (or roots), and if the receiver does not know any of them, he can pack up there and then. Alternatively, start with the senders certificate, and work down the chain from there till you come to a certificate you trust (which might be before a trusted root, so it can be more efficient) But if it is a bag of certificates, as proposed, then the receiver has to sort them before he can start. David *************************************************** David W Chadwick IT Institute, University of Salford, Salford M5 4WT Tel +44 161 745 5351 Fax +44 161 745 8169 Email D.W.Chadwick@iti.salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm *************************************************** From owner-ietf-smime Thu Jan 23 23:23:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id XAA23385 for ietf-smime-bks; Thu, 23 Jan 1997 23:23:50 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from peapod.deming.com (host20.deming.com [206.63.131.20]) by mail.proper.com (8.8.4/8.7.3) with SMTP id XAA23381 for ; Thu, 23 Jan 1997 23:23:46 -0800 (PST) Received: by peapod.deming.com from localhost (router,SLmail V2.0); Thu, 23 Jan 1997 23:25:37 Pacific Standard Time Received: by peapod.deming.com from seth (206.63.131.30::mail daemon; unverified,SLmail V2.0); Thu, 23 Jan 1997 23:25:36 Pacific Standard Time Message-Id: <3.0.32.19970123232240.009216a0@mail.craswell.com> X-Sender: blaker@mail.craswell.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 23 Jan 1997 23:22:42 -0800 To: D.W.Chadwick@iti.salford.ac.uk, Arup Biswas , jefft@shore.net From: "Blake Ramsdell" Subject: Re: Certificates Field in Signed Data Cc: ietf-smime@imc.org, smime-dev@RSA.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk At 11:06 PM 1/23/97 +0000, David Chadwick wrote: > >> It also seems >> likely that people are going to want to push other certificates than the >> ones that are required to validate the signature or signing certificate >> trust (in the case of a dual key model where the signing and enveloping >> certificates are separate, you may want to push both the signing and >> enveloping certificates and their respective chains). >> > >This is an arguement for a SET OF SEQUENCES in my opinion Yup -- that is a way to address this issue. I think my concern is that I don't want to get stuck in a corner where all we can use is a hierarchical trust model, and that any structure we impose on the transmission of certs could railroad us into a single way of thinking about trusting certificates. The SET OF SEQUENCES seems like a good compromise in the event that this all boils over and we absolutely have to change something. I don't think it's difficult to rearrange a list of certificates, or to traverse a certificate path according to a local trust convention. Take your pile of certificates (the ones in the message, and the ones you may have lying around), shuffle them around, and see if you get something that makes your trust code happy. The alternative that you're proposing takes a static snapshot of the certificates needed to form a chain according to the hierarchical model, and some of those certificates will expire, for instance, which makes the chain invalid without the renewed certificates (which could be present in a local cache, since they could be transmitted in messages received after the original message that you are trying to re-verify). The only benefit I see to the SET OF SEQUENCE is that in the event that you are using a hierarchical model, you don't have to go through the trouble of arranging the certificates yourself, and it separates the different "leaf" certificates (enveloping and signing) and their associated chains from each other. Each of these chains may have redundant intermediate certificates I might add, which wastes a bit of space in transmission. >> I think that the current wording of the use of >> ExtendedCertificatesAndCertificates in the S/MIME implementation guide is >> appropriate -- the sender should put in the signing certificate and >> certificate chain, and the receiver should be prepared to accept anything >> in any order, but other stuff can go in there also if it's useful. >> >> Being too restrictive in this case will probably hurt, especially in the >> dual key model that I mentioned before. > >But being too loose creates work for the receiver, does it not? Yup -- that's what I'm paid for :). I think that creating work for the receiver is a small price to pay when the alternative is a structure that might break a future trust model. Extra work is Just More Code. An overly restrictive specification can become unworkable, since it may not accommodate all the possibilities. >>In our case, we maintain a >> local cache database that has certificates indexed by issuerAndSerialNumber >> and also by subject, and root keys that are indexed by subject. Finding >> the chain is a matter of doing lookups by issuerAndSerialNumber and by >> subject (by issuerAndSerialNumber for the signing cert, and then looking up >> root keys or certificates by subject, keeping in mind that multiple >> certificates can have the same subject). > >Yes, but if you have a local database, you dont really need any >certificates to be passed to you do you? Except to add more to your >database. I think that the certificates in the message are for >receivers who dont have a general certificate database, but who only >have a very small set of trusted root keys. And to help them, one or >more chains of certificates seems to be the best. You certainly do need certs passed to you. How do you get certificates initially? Through the extensive public key infrastructure that we enjoy now? Sending certificates along with a message is a convenient (and essential, in today's S/MIME world) way to do key distribution, even if you have the local cert store. Blake From owner-ietf-smime Fri Jan 24 03:11:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id DAA26147 for ietf-smime-bks; Fri, 24 Jan 1997 03:11:23 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from emout14.mail.aol.com (emout14.mx.aol.com [198.81.11.40]) by mail.proper.com (8.8.4/8.7.3) with ESMTP id DAA26143 for ; Fri, 24 Jan 1997 03:11:19 -0800 (PST) From: ABiswas930@aol.com Received: (from root@localhost) by emout14.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id GAA15617; Fri, 24 Jan 1997 06:10:42 -0500 (EST) Date: Fri, 24 Jan 1997 06:10:42 -0500 (EST) Message-ID: <970124010819_1312138749@emout14.mail.aol.com> To: D.W.Chadwick@iti.salford.ac.uk, ABISWAS@novell.com, ietf-smime@imc.org, smime-dev@RSA.COM, jefft@shore.net Subject: Re: WG Charter Sender: owner-ietf-smime@imc.org Precedence: bulk In a message dated 97-01-23 19:10:28 EST, d.w.chadwick@iti.salford.ac.uk (David Chadwick) writes: << This is odd. The X.509 spec uses SEQUENCE for its forward and reverse certification paths, so why are we using SET ? This places unnecessary burden on the receiver to sort out the jumble. If we are going to go for a SEQUENCE (or SET OF SEQUENCES which solves the multiple key problem), two alternative schemes are possible. Start with the trusted root (or roots), and if the receiver does not know any of them, he can pack up there and then. Alternatively, start with the senders certificate, and work down the chain from there till you come to a certificate you trust (which might be before a trusted root, so it can be more efficient) But if it is a bag of certificates, as proposed, then the receiver has to sort them before he can start. David >> I agree with you. Actually, the same thing is true for 1. SET OF Recipients 2. SET OF Signers 3. SET OF CRLs in SignedData , EnvelopedData and SignedAndEnveloped Data cases. I fail to see any reason why they can not be SEQUENCE OF instead? If someone has any valid reason I would request him to present that. Regards, --Arup From owner-ietf-smime Mon Jan 27 13:00:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.4/8.7.3) id NAA26256 for ietf-smime-bks; Mon, 27 Jan 1997 13:00:51 -0800 (PST) X-Authentication-Warning: mail.proper.com: majordomo set sender to owner-ietf-smime@imc.imc.org using -f Received: from netcomsv.netcom.com (uucp3.netcom.com [163.179.3.3]) by mail.proper.com (8.8.4/8.7.3) with SMTP id NAA26252 for ; Mon, 27 Jan 1997 13:00:48 -0800 (PST) Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id MAA17366; Mon, 27 Jan 1997 12:21:43 -0800 Received: from cc:Mail by spysouth.spyrus.com id AA854395654 Mon, 27 Jan 97 12:07:34 Date: Mon, 27 Jan 97 12:07:34 From: "Housley, Russ" Message-Id: <9700278543.AA854395654@spysouth.spyrus.com> To: D.W.Chadwick@iti.salford.ac.uk, ABISWAS@novell.com, jefft@shore.net CC: ietf-smime@imc.org, smime-dev@RSA.COM Subject: Re: Certificates Field in Signed Data Sender: owner-ietf-smime@imc.org Precedence: bulk At 11:06 PM 1/23/97 +0000, David Chadwick wrote: > >> It also seems >> likely that people are going to want to push other certificates than the >> ones that are required to validate the signature or signing certificate >> trust (in the case of a dual key model where the signing and enveloping >> certificates are separate, you may want to push both the signing and >> enveloping certificates and their respective chains). >> > >This is an arguement for a SET OF SEQUENCES in my opinion Presently, PKCS #7 provides a heap of certificates that might be useful to the recipient. PKCS #7 does not constrain the originator in the contets of the heap. The originator can include any certificates that might be useful to the recipient, including certificates for key management. I do not see any reason why the originator cannot piggy back key management certificates on a signed only message in the current syntax. >> I think that the current wording of the use of >> ExtendedCertificatesAndCertificates in the S/MIME implementation guide is >> appropriate -- the sender should put in the signing certificate and >> certificate chain, and the receiver should be prepared to accept anything >> in any order, but other stuff can go in there also if it's useful. >> >> Being too restrictive in this case will probably hurt, especially in the >> dual key model that I mentioned before. > >But being too loose creates work for the receiver, does it not? The additional authorization information needs to be transfered somewhere. These certificates containing authorization information do not make the recipient's job overly onerous. >>In our case, we maintain a >> local cache database that has certificates indexed by issuerAndSerialNumber >> and also by subject, and root keys that are indexed by subject. Finding >> the chain is a matter of doing lookups by issuerAndSerialNumber and by >> subject (by issuerAndSerialNumber for the signing cert, and then looking up >> root keys or certificates by subject, keeping in mind that multiple >> certificates can have the same subject). > >Yes, but if you have a local database, you dont really need any >certificates to be passed to you do you? Except to add more to your >database. I think that the certificates in the message are for >receivers who dont have a general certificate database, but who only >have a very small set of trusted root keys. And to help them, one or >more chains of certificates seems to be the best. The certificates must be passed in the message or obtained from some server (perhaps a Directory or Web Server). They do not appear in the local cache without being sent or fetched. Also, most implementations of local certificate stores limit their size, so certificate key flushed periodically. Russ From owner-ietf-smime Mon Feb 3 15:47:33 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA29556 for ietf-smime-bks; Mon, 3 Feb 1997 15:47:33 -0800 (PST) Received: from doggate.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA29552 for ; Mon, 3 Feb 1997 15:47:31 -0800 (PST) Received: by DOGGATE with Internet Mail Service (5.0.1438.0) id <1HT08K7H>; Mon, 3 Feb 1997 15:48:29 -0800 Message-ID: <2FBF98FC7852CF11912A00000000000103D87A3B@DINO> From: "Jim Schaad (Exchange)" To: D.W.Chadwick@iti.salford.ac.uk, ABISWAS@novell.com, jefft@shore.net, "'Housley, Russ'" Cc: ietf-smime@imc.org, smime-dev@RSA.COM Subject: RE: Certificates Field in Signed Data Date: Mon, 3 Feb 1997 15:48:23 -0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1438.0) Content-Type: text/plain Sender: owner-ietf-smime@imc.org Precedence: bulk > At 11:06 PM 1/23/97 +0000, David Chadwick wrote: > > > >> It also seems > >> likely that people are going to want to push other certificates > than the > >> ones that are required to validate the signature or signing > certificate > >> trust (in the case of a dual key model where the signing and > enveloping > >> certificates are separate, you may want to push both the signing > and > >> enveloping certificates and their respective chains). > >> > > > >This is an arguement for a SET OF SEQUENCES in my opinion > Use of a SET OF SEQUENCES disturbs me greatly, while I don't have an opinion on the difference between a SET or a SEQUENCE I really don't care for the SET OF SEQUENCES. Microsoft Exchange uses two certificates in general, one for key exchange and one for signature. If a SET OF SEQUENCES were to be used would I need to duplicate the chain of certificates potentially multiple times, one for every different leaf that I send, or are clients going to have to be able to jump around between the different sequences. This seems to me to be a much greater hit than just shipping a single bag of certificates and letting clients do the searching within that single bag. jim schaad Microsoft Exchange From owner-ietf-smime Sun Feb 9 14:34:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA23455 for ietf-smime-bks; Sun, 9 Feb 1997 14:34:00 -0800 (PST) Received: from amalthea.salford.ac.uk (amalthea.salford.ac.uk [146.87.255.61]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA23449 for ; Sun, 9 Feb 1997 14:33:56 -0800 (PST) Message-Id: <199702092233.OAA23449@mail.proper.com> Received: from zetnet.co.uk (actually host man-071.dialup.zetnet.co.uk) by amalthea.salford.ac.uk with SMTP (PP); Sun, 9 Feb 1997 22:35:14 +0000 Comments: Authenticated sender is From: David Chadwick To: "Jim Schaad (Exchange)" Date: Sun, 9 Feb 1997 22:40:56 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: Certificates Field in Signed Data Reply-to: D.W.Chadwick@iti.salford.ac.uk CC: ietf-smime@imc.org, smime-dev@RSA.COM X-mailer: Pegasus Mail for Windows (v2.42) Sender: owner-ietf-smime@imc.org Precedence: bulk > Use of a SET OF SEQUENCES disturbs me greatly, while I don't have an > opinion on the difference between a SET or a SEQUENCE I really don't > care for the SET OF SEQUENCES. > > Microsoft Exchange uses two certificates in general, one for key > exchange and one for signature. If a SET OF SEQUENCES were to be used > would I need to duplicate the chain of certificates potentially multiple > times, one for every different leaf that I send, or are clients going to > have to be able to jump around between the different sequences. This > seems to me to be a much greater hit than just shipping a single bag of > certificates and letting clients do the searching within that single > bag. Point taken David > > jim schaad > Microsoft Exchange > > *************************************************** David W Chadwick IT Institute, University of Salford, Salford M5 4WT Tel +44 161 745 5351 Fax +44 161 745 8169 Email D.W.Chadwick@iti.salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm *************************************************** From owner-ietf-smime Sat Mar 22 13:37:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA22480 for ietf-smime-bks; Sat, 22 Mar 1997 13:37:54 -0800 (PST) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA22475; Sat, 22 Mar 1997 13:37:50 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 22 Mar 1997 13:45:03 -0800 To: ietf-smime@imc.org, smime-dev@RSA.COM From: "Paul E. Hoffman" Subject: S/MIME BOF at Memphis IETF Sender: owner-ietf-smime@imc.org Precedence: bulk Greetings. I'm sending this messages to both S/MIME lists so that anyone going to the IETF meeting in Memphis will know that we are having our second (and final) BOF. The BOF will be Wednesday, April 9 at 1300-1400. Due to the short time of the meeting, we'll have a somewhat abbreviated agenda: Introductions People Mailing lists Web sites Status of Internet Drafts Status of commercial products Do we form a Working Group? Draft bashing If you'll be in Memphis for the IETF meeting, we certainly hope to see you at the BOF. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Tue Mar 25 12:21:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA27371 for ietf-smime-bks; Tue, 25 Mar 1997 12:21:30 -0800 (PST) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA27355; Tue, 25 Mar 1997 12:21:21 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Mar 1997 12:27:56 -0800 To: ietf-smime@imc.org, smime-dev@RSA.COM From: "Paul E. Hoffman" Subject: New S/MIME drafts available Sender: owner-ietf-smime@imc.org Precedence: bulk After much work on many people's part, there are new Internet Drafts for S/MIME. The drafts combine the specifications from the old format draft and the RSA S/MIME Implementors Guide. The drafts will appear in the IETF directories in the next few weeks; until then, you can access them from: Note that each draft has an appendix which lists open issues. These appendixes list known topics that are not clear, need more discussion, or are open to major change. Of course, you are free to discuss other issues in the drafts as well. IMPORTANT: please focus all discussion of the drafts on the "ietf-smime@imc.org" mailing list. The "smime-dev@rsa.com" mailing list should remain for developer's issues only. Information about the "ietf-smime@imc.org" mailing list can be found at . Also, if you are coming to the S/MIME BOF at the IETF meeting in Memphis, please be sure to read the drafts before the BOF. Although there won't be time to discuss the drafts in any detail (the BOF is only one hour long), having people who know what's in the draft always helps move a BOF along. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Sat Apr 12 13:18:45 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA28642 for ietf-smime-bks; Sat, 12 Apr 1997 13:18:45 -0700 (PDT) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA28638 for ; Sat, 12 Apr 1997 13:18:42 -0700 (PDT) Received: from [129.46.85.133] (annex2-p43.qualcomm.com [129.46.85.133]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id NAA21940; Sat, 12 Apr 1997 13:23:30 -0700 (PDT) X-Sender: llundbla@nala.qualcomm.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 12 Apr 1997 13:24:01 -0700 To: ietf-smime@imc.org, smime-dev@RSA.COM From: Laurence Lundblade Subject: 2nd S/MIME BOF meeting minutes Sender: owner-ietf-smime@imc.org Precedence: bulk Second S/MIME BOF Meeting Minutes 38th IETF, Memphis April 8, 1997 Chairperson: Paul Hoffman Agenda: Introduction Status of Drafts Status of S/MIME products Working group formation Issues with current draft Mailing lists: ietf-smime@imc.org - for discussion of the drafts smime-dev@rsa.com - for discussion of developer issues A couple of issues were brought up before we got started on the Agenda: A question was raised as to whether work on the secuity multiparts standard would be pulled into this working group. The problem raised was that they require exact bit integrity for the signature to remain valid, and this is particularly a problem with the multipart/related MIME type. Mention was made that the charter was posted to the mailing lists after the previous BOF and resulted in little response Status of Drafts (Paul Hofman): Two drafts were submitted to the IETF. One is a combination of the previous S/MIME message specification and the interoperability guide. The other is a certificate specification that was split out from the previous documents. Each draft lists open issues. Products status (Blake Ramsdel): Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft) Working group (these notes are cronological; the discussion was chaotic): Intro slide shows: - A working group will result in better publicity in the IETF - Better interaction with IETF - Greater vendor confidence - tried to form 3 mo. ago with little response (to charter) Jeff Schiller, security area director, responds: Purpose is to make a standard, not to get publicity. This BOF must focus and make a decision. A charter must say the working group desires to create a standard because working groups are only for creating standards. There cannot be another BOF. Also, RSA needs to relinquish change control Other issues brought up (chronological order): Vendors must follow what this working group does, or there is no point in having this working group. Tim Matthews of RSA said the main reason for control over the S/MIME name was to gaurantee interoperability between implementations that are labeled S/MIME, but would be willing to turn over control of the name if interoperability was otherwise gauranteed The current document requires intellectual property rights (IPR) of RSA. The reason RC2 is used is because it has been cleared by the commerce department for export. It is very easy for a vendor to export crypto with 40 bit RC2. No other algorithm has the same support (yet). (editors note - RC2 is a trade secret of RSA. It is not patented. Trade secrets are indefinite as long as they are protected, but it is the responsibility of the owner to protect them) Some suggest the RC2 trade secret is gone A poll asked whether implementors were willing to give change control to the IETF. Many were willing. Some reasons given for not forming a working group to produce a standard (and leaving control with RSA) were that we can't get through the process, or that the result has some security hole. The process should not be a rubber stamp process. A point was made that the standard should be open on the issue of algorithms . A point was made that we can't do that with current algorithms (most are encumbered). A point was made that acknowledged that interoperability with current implementations was OK, but that 40 bit crypto is unacceptably insecure for some communities. This point was quickly countered that the debate over the sufficiency of 40 bits was out of the scope of this meeting. We have several choices - S/MIME evolves to be non-proprietary (e.g. stops requiring proprietary algs) - The right to algorithms it uses are released - Do something completely different (e.g., MOSS) Both profiles in S/MIME currently require RC2 (proprietary) There is a similar problem with TLS Jeff suggests one solution that would be acceptable to him (which doesn't mean the IESG and IAB approve (yet)) is to have a single profile that doesn't include RC2, 40 bits. A poll showed this would be acceptable and there was no decension (RSA representive obstains) A point was made that non-US implentors can implement technology that is deemed not exportable in the US. Suggestion that we go ahead without RC2.... Some questioned whether or not this would be "S/MIME". (editor: now we're getting to the nitty gritty...) Jeff (area directory): S/MIME IPR issue must be resolved by July 1, 1997 or working group cannot be formed Tim (RSA Inc.): RSA can work with that time frame Jeff's requirements: Interoperability is a requirement, therefore some algorithms must be mandatory. Have a strong bias towards open algorithms, but can accept some that are not. There are open symmetric algorithms (editor: that can be used instead of RC2) Control must be with in the IETF, e.g., IETF "has a license to do S/MIME" and IETF says what the protocol is. PKCS7 isn't an issue. It can be published as an informational RFC. The patents on the RSA algorithm are not an issue because they will expire. Thus the issue is with the RC2 algorithm because it is a trade secret which will never expire. RSA has not disavowed its IPR for RC2 and it could go on for a long time. (editor's summary: RSA must resolve two issues before a working group can begin work towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2) Change control must be with the IETF (e.g., the rights to the "S/MIME" trademark must be neutrally held.) These must be resolved by July 1, 1997. The RSA representive acknowledged this). On to issues (with a few minutes left) Laurence presented proposal for reorganization of section 3 of the document. The reorganization was for the sake of clarity and to separate the definition of the message formats from the rationale for their use. There was general ascent towards the proposal, though the meeting began to break up. At this point we gave up the meeting was breaking up One last issue raised - does the inside object really have to be MIME encoded or not (editor it wasn't clear whether this was the issue of transfer encoding or the issue of MIME vs 822). From owner-ietf-smime Mon Apr 14 11:13:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA27019 for ietf-smime-bks; Mon, 14 Apr 1997 11:13:20 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA27015 for ; Mon, 14 Apr 1997 11:13:17 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id LAA28843; Mon, 14 Apr 1997 11:13:48 -0700 (PDT) Message-Id: <3.0.32.19970414111749.009afe90@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 14 Apr 1997 11:17:50 -0700 To: Laurence Lundblade , ietf-smime@imc.org, smime-dev@RSA.COM From: Charles Breed Subject: Re: 2nd S/MIME BOF meeting minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk (The meeting was on April 9th, not the 8th...) The issues brought up by the IETF Security Area Director, Jeff Schiller, were inevitable. S/MIME needs to exist with open, non-proprietary profiles as well as profile that require licensing of patented algorithms, especially if one wants an elliptic curve algorithm. I propose the following changes to move this forward as a working group... 1. RSA to give the 'S/MIME' trade mark to a neutral, non-profit organization that's willing to arbitrate interoperability disputes. (or change the name of the spec) 2. The only MUST profile should be RSA (Public Key), 3DES (Symmetric), SHA-1 (Message Digest) 3. Unfortunately, the MUST profile (for interoperability), will be US export controlled. US export requirements should NOT be imposed upon an international standards organization. (Why should someone in Japan be forced to uses 40-bit weak crypto to communicate with someone in Germany, if their profile is unknown?) It is more dangerous to resort to weak crypto than nothing at all. Some folks would want to be able to state, "Do not send me anything less than 128-bit". 4. PKCS #7 to be an informational rfc prior to S/MIME final call 5. The spec should allow for handling of additional certificate types, such as the SPKI (SDSI) working group proposed data structure. regards, Charles Breed At 01:24 PM 4/12/97 -0700, Laurence Lundblade wrote: >Second S/MIME BOF Meeting Minutes >38th IETF, Memphis >April 8, 1997 > >Chairperson: Paul Hoffman > >Agenda: > Introduction > Status of Drafts > Status of S/MIME products > Working group formation > Issues with current draft > >Mailing lists: > ietf-smime@imc.org - for discussion of the drafts > smime-dev@rsa.com - for discussion of developer issues > >A couple of issues were brought up before we got started on the Agenda: > A question was raised as to whether work on the secuity multiparts standard > would be pulled into this working group. The problem raised was that they > require exact bit integrity for the signature to remain valid, and this is > particularly a problem with the multipart/related MIME type. > > Mention was made that the charter was posted to the mailing lists after the > previous BOF and resulted in little response > > >Status of Drafts (Paul Hofman): > Two drafts were submitted to the IETF. One is a combination of the >previous S/MIME > message specification and the interoperability guide. The other is a >certificate > specification that was split out from the previous documents. Each draft >lists open > issues. > > >Products status (Blake Ramsdel): > Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft > Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft) > > >Working group (these notes are cronological; the discussion was chaotic): > Intro slide shows: > - A working group will result in better publicity in the IETF > - Better interaction with IETF > - Greater vendor confidence > - tried to form 3 mo. ago with little response (to charter) > > Jeff Schiller, security area director, responds: > Purpose is to make a standard, not to get publicity. This BOF must >focus and make > a decision. A charter must say the working group desires to create a >standard because > working groups are only for creating standards. There cannot be >another BOF. > > Also, RSA needs to relinquish change control > > Other issues brought up (chronological order): > Vendors must follow what this working group does, or there is no point >in having > this working group. > > Tim Matthews of RSA said the main reason for control over the S/MIME >name was to > gaurantee interoperability between implementations that are labeled >S/MIME, > but would be willing to turn over control of the name if >interoperability was > otherwise gauranteed > > The current document requires intellectual property rights (IPR) of RSA. > > The reason RC2 is used is because it has been cleared by the commerce >department > for export. It is very easy for a vendor to export crypto with 40 bit >RC2. No other > algorithm has the same support (yet). > > (editors note - RC2 is a trade secret of RSA. It is not patented. >Trade secrets are > indefinite as long as they are protected, but it is the >responsibility of the owner > to protect them) > > Some suggest the RC2 trade secret is gone > > A poll asked whether implementors were willing to give change control >to the IETF. > Many were willing. Some reasons given for not forming a working group >to produce a > standard (and leaving control with RSA) were that we can't get through >the process, or > that the result has some security hole. > > The process should not be a rubber stamp process. > > A point was made that the standard should be open on the issue of >algorithms . > > A point was made that we can't do that with current algorithms (most >are encumbered). > > A point was made that acknowledged that interoperability with current >implementations > was OK, but that 40 bit crypto is unacceptably insecure for some >communities. This > point was quickly countered that the debate over the sufficiency of 40 >bits was out of the > scope of this meeting. > > We have several choices > - S/MIME evolves to be non-proprietary (e.g. stops requiring >proprietary algs) > - The right to algorithms it uses are released > - Do something completely different (e.g., MOSS) > Both profiles in S/MIME currently require RC2 (proprietary) > There is a similar problem with TLS > > Jeff suggests one solution that would be acceptable to him (which >doesn't mean the IESG and > IAB approve (yet)) is to have a single profile that doesn't include >RC2, 40 bits. > > A poll showed this would be acceptable and there was no decension (RSA >representive obstains) > > A point was made that non-US implentors can implement technology that >is deemed not > exportable in the US. > > Suggestion that we go ahead without RC2.... Some questioned whether or >not this would > be "S/MIME". > > (editor: now we're getting to the nitty gritty...) > > Jeff (area directory): S/MIME IPR issue must be resolved by July 1, >1997 or working group > cannot be formed > > Tim (RSA Inc.): RSA can work with that time frame > > Jeff's requirements: > Interoperability is a requirement, therefore some algorithms must be >mandatory. Have a > strong bias towards open algorithms, but can accept some that are >not. There are open > symmetric algorithms (editor: that can be used instead of RC2) > > Control must be with in the IETF, e.g., IETF "has a license to do >S/MIME" and IETF says what > the protocol is. > > PKCS7 isn't an issue. It can be published as an informational RFC. > > The patents on the RSA algorithm are not an issue because they will >expire. Thus the > issue is with the RC2 algorithm because it is a trade secret which >will never expire. > RSA has not disavowed its IPR for RC2 and it could go on for a long time. > >(editor's summary: RSA must resolve two issues before a working group can >begin work > towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2) >Change control > must be with the IETF (e.g., the rights to the "S/MIME" trademark must be >neutrally held.) > These must be resolved by July 1, 1997. The RSA representive acknowledged >this). > > > >On to issues (with a few minutes left) > Laurence presented proposal for reorganization of section 3 of the >document. The reorganization > was for the sake of clarity and to separate the definition of the message >formats from the rationale > for their use. There was general ascent towards the proposal, though the >meeting began to break up. > > At this point we gave up the meeting was breaking up > > One last issue raised - does the inside object really have to be MIME >encoded or not (editor it > wasn't clear whether this was the issue of transfer encoding or the issue >of MIME vs 822). > > > > > From owner-ietf-smime Mon Apr 14 11:42:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA27557 for ietf-smime-bks; Mon, 14 Apr 1997 11:42:04 -0700 (PDT) Received: from RSA.COM (chirality.rsa.com [192.80.211.33]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA27549 for ; Mon, 14 Apr 1997 11:42:01 -0700 (PDT) Received: from eagle.rsa.com by RSA.COM with SMTP id AA24452; Mon, 14 Apr 97 10:39:47 PDT Received: from lobester.rsa.com by eagle.rsa.com via smtpd (for chirality.rsa.com [192.80.211.33]) with SMTP; 14 Apr 1997 18:44:22 UT Received: by LOBESTER.rsa.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC48C9.578FF5D0@LOBESTER.rsa.com>; Mon, 14 Apr 1997 11:45:25 -0700 Message-Id: From: Steve Dusse To: "'ietf-smime@imc.org'" , "'smime-dev@RSA.COM'" , "'Charles Breed'" Subject: RE: 2nd S/MIME BOF meeting minutes Date: Mon, 14 Apr 1997 11:45:24 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk Hi Charles, > >5. The spec should allow for handling of additional certificate types, such >as the SPKI (SDSI) working group proposed data structure. > I'm not as up on SPKI as I should be. Does SPKI use some mechanism other than an X.509 certificate for conveying trust ? -steve > > > > > > >At 01:24 PM 4/12/97 -0700, Laurence Lundblade wrote: >>Second S/MIME BOF Meeting Minutes >>38th IETF, Memphis >>April 8, 1997 >> >>Chairperson: Paul Hoffman >> >>Agenda: >> Introduction >> Status of Drafts >> Status of S/MIME products >> Working group formation >> Issues with current draft >> >>Mailing lists: >> ietf-smime@imc.org - for discussion of the drafts >> smime-dev@rsa.com - for discussion of developer issues >> >>A couple of issues were brought up before we got started on the Agenda: >> A question was raised as to whether work on the secuity multiparts >>standard >> would be pulled into this working group. The problem raised was that they >> require exact bit integrity for the signature to remain valid, and this is >> particularly a problem with the multipart/related MIME type. >> >> Mention was made that the charter was posted to the mailing lists after >>the >> previous BOF and resulted in little response >> >> >>Status of Drafts (Paul Hofman): >> Two drafts were submitted to the IETF. One is a combination of the >>previous S/MIME >> message specification and the interoperability guide. The other is a >>certificate >> specification that was split out from the previous documents. Each draft >>lists open >> issues. >> >> >>Products status (Blake Ramsdel): >> Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft >> Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft) >> >> >>Working group (these notes are cronological; the discussion was chaotic): >> Intro slide shows: >> - A working group will result in better publicity in the IETF >> - Better interaction with IETF >> - Greater vendor confidence >> - tried to form 3 mo. ago with little response (to charter) >> >> Jeff Schiller, security area director, responds: >> Purpose is to make a standard, not to get publicity. This BOF must >>focus and make >> a decision. A charter must say the working group desires to create a >>standard because >> working groups are only for creating standards. There cannot be >>another BOF. >> >> Also, RSA needs to relinquish change control >> >> Other issues brought up (chronological order): >> Vendors must follow what this working group does, or there is no point >>in having >> this working group. >> >> Tim Matthews of RSA said the main reason for control over the S/MIME >>name was to >> gaurantee interoperability between implementations that are labeled >>S/MIME, >> but would be willing to turn over control of the name if >>interoperability was >> otherwise gauranteed >> >> The current document requires intellectual property rights (IPR) of >>RSA. >> >> The reason RC2 is used is because it has been cleared by the commerce >>department >> for export. It is very easy for a vendor to export crypto with 40 bit >>RC2. No other >> algorithm has the same support (yet). >> >> (editors note - RC2 is a trade secret of RSA. It is not patented. >>Trade secrets are >> indefinite as long as they are protected, but it is the >>responsibility of the owner >> to protect them) >> >> Some suggest the RC2 trade secret is gone >> >> A poll asked whether implementors were willing to give change control >>to the IETF. >> Many were willing. Some reasons given for not forming a working group >>to produce a >> standard (and leaving control with RSA) were that we can't get through >>the process, or >> that the result has some security hole. >> >> The process should not be a rubber stamp process. >> >> A point was made that the standard should be open on the issue of >>algorithms . >> >> A point was made that we can't do that with current algorithms (most >>are encumbered). >> >> A point was made that acknowledged that interoperability with current >>implementations >> was OK, but that 40 bit crypto is unacceptably insecure for some >>communities. This >> point was quickly countered that the debate over the sufficiency of 40 >>bits was out of the >> scope of this meeting. >> >> We have several choices >> - S/MIME evolves to be non-proprietary (e.g. stops requiring >>proprietary algs) >> - The right to algorithms it uses are released >> - Do something completely different (e.g., MOSS) >> Both profiles in S/MIME currently require RC2 (proprietary) >> There is a similar problem with TLS >> >> Jeff suggests one solution that would be acceptable to him (which >>doesn't mean the IESG and >> IAB approve (yet)) is to have a single profile that doesn't include >>RC2, 40 bits. >> >> A poll showed this would be acceptable and there was no decension (RSA >>representive obstains) >> >> A point was made that non-US implentors can implement technology that >>is deemed not >> exportable in the US. >> >> Suggestion that we go ahead without RC2.... Some questioned whether or >>not this would >> be "S/MIME". >> >> (editor: now we're getting to the nitty gritty...) >> >> Jeff (area directory): S/MIME IPR issue must be resolved by July 1, >>1997 or working group >> cannot be formed >> >> Tim (RSA Inc.): RSA can work with that time frame >> >> Jeff's requirements: >> Interoperability is a requirement, therefore some algorithms must be >>mandatory. Have a >> strong bias towards open algorithms, but can accept some that are >>not. There are open >> symmetric algorithms (editor: that can be used instead of RC2) >> >> Control must be with in the IETF, e.g., IETF "has a license to do >>S/MIME" and IETF says what >> the protocol is. >> >> PKCS7 isn't an issue. It can be published as an informational RFC. >> >> The patents on the RSA algorithm are not an issue because they will >>expire. Thus the >> issue is with the RC2 algorithm because it is a trade secret which >>will never expire. >> RSA has not disavowed its IPR for RC2 and it could go on for a long >>time. >> >>(editor's summary: RSA must resolve two issues before a working group can >>begin work >> towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2) >>Change control >> must be with the IETF (e.g., the rights to the "S/MIME" trademark must be >>neutrally held.) >> These must be resolved by July 1, 1997. The RSA representive acknowledged >>this). >> >> >> >>On to issues (with a few minutes left) >> Laurence presented proposal for reorganization of section 3 of the >>document. The reorganization >> was for the sake of clarity and to separate the definition of the message >>formats from the rationale >> for their use. There was general ascent towards the proposal, though the >>meeting began to break up. >> >> At this point we gave up the meeting was breaking up >> >> One last issue raised - does the inside object really have to be MIME >>encoded or not (editor it >> wasn't clear whether this was the issue of transfer encoding or the issue >>of MIME vs 822). >> >> >> >> >> > From owner-ietf-smime Mon Apr 14 19:07:08 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA02504 for ietf-smime-bks; Mon, 14 Apr 1997 19:07:08 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA02489 for ; Mon, 14 Apr 1997 19:07:02 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Apr 1997 18:52:53 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: Proposed charter, second round Sender: owner-ietf-smime@imc.org Precedence: bulk In order to become a working group, we need general agreement on a charter. I propose the following, which is a revision of the one I proposed in February. Description of the Working Group: S/MIME is a method for encrypting and/or authenticating MIME data. S/MIME defines a format for the MIME data, the algorithms that must be used for interoperability, and the additional operational concerns such as certificates and transport over the Internet. Work on S/MIME has already begun before the formation of this Working Group. This WG will use as a starting point the two drafts already submitted to the IETF for S/MIME. These drafts are based on the PKCS7 message format. The Working Group will most likely maintain interoperability with the message format from the current S/MIME work. A modestly aggressive schedule is specified, due to the amount of existing work on S/MIME. Goals and Milestones: March 1997: Submit first drafts of S/MIME message specification and S/MIME certificate handling July 1997: WG last call on S/MIME message specification July 1997: Submit all reformatted PKCS documents as Informational August 1997: Submit S/MIME message specification for Proposed Standard September 1997: WG last call on S/MIME certificate handling October 1997: Submit S/MIME certificate handling for Proposed Standard --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Mon Apr 14 19:07:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA02509 for ietf-smime-bks; Mon, 14 Apr 1997 19:07:10 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA02493 for ; Mon, 14 Apr 1997 19:07:03 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Apr 1997 18:54:54 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: Minutes from Memphis, edited version, first draft Sender: owner-ietf-smime@imc.org Precedence: bulk Greetings again. Many thanks to Laurence for his minutes of the IETF Memphis meeting. I also received input from other people, and have combined them into the following. Please feel free to comment on the minutes on this mailing list. I'll submit the final version to the IETF next week. Second S/MIME BOF Meeting Minutes 38th IETF, Memphis April 8, 1997 Minutes taken by Laurence Lundblade, edited and revised by Paul Hoffman Chairs: Paul Hoffman and Blake Ramsdell Agenda: Introduction Status of Drafts Status of S/MIME products Working group formation Issues with current draft Mailing lists: ietf-smime@imc.org - for discussion of the drafts smime-dev@rsa.com - for discussion of developer issues A question was raised as to whether work on the secuity multiparts MIME standard would be pulled into this Working Group. The problem raised was that they require exact bit integrity for the signature to remain valid, and this is particularly a problem with the multipart/related MIME type. It was decided that this work was out of scope for the S/MIME group, but should be persued elsewhere. Mention was made that the charter was posted to the mailing lists after the previous BOF and resulted in little response. Status of Drafts: Two drafts were submitted to the IETF. One is a combination of the previous S/MIME message specification and the interoperability guide. The other is a certificate specification that was split out from the previous documents. Each draft lists open issues. The drafts are available at . Products status: Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft) Discussion about forming a Working Group: Paul Hoffman started by stating that a working group will result in better publicity in the IETF, better interaction with other IETF work, and greater vendor confidence. However, he tried to form the WG three months ago with little response to the proposed charter. Jeff Schiller, the IESG area director for security, responded that the purpose of a WG is to make a standard, not to get publicity. This BOF must focus on standards work and make a decision. A charter must say the working group desires to create a standard because working groups are only for creating standards. There cannot be another BOF (you only get two, and this is the second). Also, RSA needs to relinquish change control for the work to become a standard. Vendors must follow what this WG does, or there is no point to creating this WG. Tim Matthews from RSA said the main reason for control over the S/MIME name was to gaurantee interoperability between implementations that are labeled S/MIME, but would be willing to turn over control of the name if interoperability was otherwise gauranteed. The current document requires intellectual property rights (IPR) of RSA. The reason RC2 was used is that it was cleared by the U.S. Commerce Department for expedited export. It is very easy for a vendor to export crypto with 40 bit RC2. (Background note: RC2 is a trade secret of RSA. It is not patented. Trade secrets last forever as long as they are protected, but it is the responsibility of the owner to protect them. Some suggest the RC2 trade secret is gone. For example, there are at least two documents available on the Internet that purport to describe the same algorithm, or a fully interoperable algorithm, to RC2.) The attendees were asked whether implementors in the room were willing to give change control for the spec to the IETF. Many were willing. Some reasons given for not forming a working group to produce a standard (and leaving control with RSA) were that we might not be able to get through the whole process, or that the result has some security hole. A point was made that the standard should be open on the issue of algorithms . A point was made that we can't do that with current algorithms (most are encumbered with some sort of IPR). A point was made that said that interoperability with current implementations was OK, but that 40 bit crypto is unacceptably insecure for some communities. This point was quickly countered that the debate over the sufficiency of 40 bits was out of the scope of this meeting. Jeff Schiller suggested one solution that would be acceptable to him (although this doesn't mean the IESG and IAB approve of it) is to have a single profile that doesn't require RC2. A poll of the room showed that many people thought this would be acceptable. When polled with the inverse question (who would object to the IETF spec not requiring RC2), no one objected. A point was made that non-US implentors can implement technology that is deemed not exportable in the US. There was a suggestion that we go ahead without RC2. Some questioned whether or not this would be "S/MIME". Jeff Schiller said in no uncertain terms that the S/MIME IPR issue must be resolved by July 1, 1997 or working group could not be formed. Tim Matthews from RSA said that RSA can work with that time frame. Jeff also said: - Interoperability is a must, therefore some algorithms must be mandatory. He has a strong bias towards open algorithms, but can accept some that are not. - Control of the spec must be completely with in the IETF, e.g., IETF "has a license to do S/MIME" and IETF says what the protocol is. - PKCS7 isn't an issue. It can be published as an informational RFC. The patents on the RSA algorithm are not an issue because they will expire. Thus the issue is with the RC2 algorithm because it is a trade secret which will never expire. RSA has not disavowed its IPR for RC2 and it could claim IPR for a long time. - RSA must resolve two issues before a working group can begin work towards a standard. RSA must decide what to do with the name "S/MIME". Also, S/MIME must not rely on a trade secret; RSA could say that RC2 was no longer a trade secret. Other issues: Laurence Lundblade presented proposal for reorganization of Section 3 of the message document. The reorganization was for the sake of clarity and to separate the definition of the message formats from the rationale for their use. There was general agreement towards the proposal. Other open issues were going to be addressed, but the meeting started to break up. We decided to take the rest of the discussion to the mailing list. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Mon Apr 14 19:07:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA02506 for ietf-smime-bks; Mon, 14 Apr 1997 19:07:09 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA02500 for ; Mon, 14 Apr 1997 19:07:05 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Apr 1997 19:11:36 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: Keeping the mailing lists separate (ietf-smime edition) Sender: owner-ietf-smime@imc.org Precedence: bulk Greetings, S/MIME spec workers. As you probably know, there are two mailing lists that relate to S/MIME. There is this list (smime-dev@rsa.com), which is for developers implementing S/MIME, and there is anotherh list (ietf-smime@imc.org) for discussing the S/MIME specification work that is going on in the IETF. These two efforts, even though they are being done by mostly the same people, are quite different. The RSA folks and many of their developers are helping support the IETF work, so this is defintely not an "us vs. them" situation. It's "both/and", not "either/or". Please do *not* cross-post to the two mailing lists. There is a long history on the Internet of discussions that happen on two lists at once falling apart as some people only reply to one list. Given that these two efforts are fairly easily defined, and both lists are open to anyone, there is no reason to cross-post, and plenty of reason not to. Discussion such as "how do I implement abc", "who has implemented def", "are there any toolkits for ghi", and so on belong on *the other* list. Discussion such as "should S/MIME have jkl", "will the mno feature go into the next round of S/MIME", and "I think that the pqr feature is unnecessary" should go on *this* list. Again, it is quite alright to be on both lists. In fact, I imagine that any S/MIME developer would care about the IETF work, and would therefore want to be on both lists, even if they only lurk. Similarly, many people working on the S/MIME spec in the IETF would probably care about how the developers are doing. I promise to post occaisional messages here to alert people about implementation issues that come up on the other list that affect the IETF work. To get on the the smime-dev mailing list, send mail to: majordomo@rsa.org with the message subscribe smime-dev --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Tue Apr 15 01:35:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id BAA05472 for ietf-smime-bks; Tue, 15 Apr 1997 01:35:39 -0700 (PDT) Received: from dde.dde.dk (dde.dde.dk [152.95.32.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id BAA05466 for ; Tue, 15 Apr 1997 01:35:34 -0700 (PDT) Received: by dde.dde.dk (5.61/9.3) id AA08271; Tue, 15 Apr 97 10:36:43 +0200 Received: from Knud.dde.dk by dde.dde.dk (5.61/9.3) with SMTP id AA06287; Tue, 15 Apr 97 10:36:43 +0200 Received: by Knud.dde.dk (4.1/9.7) id AA29850; Tue, 15 Apr 97 10:36:21 +0200 Message-Id: <9704150836.AA29850@Knud.dde.dk> X-Mailer: exmh version 2.0beta 12/23/96 To: ietf-smime@imc.org Subject: Re: 2nd S/MIME BOF meeting minutes In-Reply-To: cbreed's message of Mon, 14 Apr 1997 11:17:50 -0700. <3.0.32.19970414111749.009afe90@mail.pgp.com> Date: Tue, 15 Apr 1997 10:36:21 +0200 From: "Frederik H. Andersen" Sender: owner-ietf-smime@imc.org Precedence: bulk cbreed@pgp.com said: > 3. Unfortunately, the MUST profile (for interoperability), will be US > export controlled. US export requirements should NOT be imposed upon > an international standards organization. (Why should someone in Japan > be forced to uses 40-bit weak crypto to communicate with someone in > Germany, if their profile is unknown?) It is more dangerous to resort > to weak crypto than nothing What I find very difficult to understand is, why the technology: - which is the defacto standard - the most widely used (world wide) - which is not suffering from the US-export equirements (as it is already available outside US) - which allows almost arbitrarily strong crypto is not considered for the MUST technology? Another thing, is it not true, assuming the technology is available, that nothing prevents a user in US and a user outside US to communicate using stong crypto ( e.g. 128 bit keys)? /Frederik -- ------------------------------------------------------------------ Frederik H. Andersen Phone: +45 42 84 50 11 Dansk Data Elektronik A/S Fax: +45 42 84 52 20 Herlev Hovedgade 199 Email: fha@dde.dk (MIME accepted) DK-2730 Herlev, DENMARK PGP Fingerprint: 6B BC FB 45 E4 69 CE A2 63 E1 62 1F 0C 65 C2 E4 ------------------------------------------------------------------ From owner-ietf-smime Tue Apr 15 08:12:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA11591 for ietf-smime-bks; Tue, 15 Apr 1997 08:12:50 -0700 (PDT) Received: from out2.ibm.net (out2.ibm.net [165.87.201.252]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA11587 for ; Tue, 15 Apr 1997 08:12:47 -0700 (PDT) Received: (from uucp@localhost) by out2.ibm.net (8.6.9/8.6.9) id PAA407761; Tue, 15 Apr 1997 15:13:22 GMT Received: from slip166-72-232-240.ny.us.ibm.net(166.72.232.240) by out2.ibm.net via smap (V1.3mjr) id smaUEECrx; Tue Apr 15 15:12:58 1997 Received: (from uri@localhost) by alisan.ibm.net (8.7.6/8.7.3) id LAA00222; Tue, 15 Apr 1997 11:13:35 -0400 Date: Tue, 15 Apr 1997 11:13:35 -0400 Message-Id: <199704151513.LAA00222@alisan.ibm.net> From: Uri Blumenthal To: "Frederik H. Andersen" Cc: ietf-smime@imc.org Subject: Re: 2nd S/MIME BOF meeting minutes In-Reply-To: <9704150836.AA29850@Knud.dde.dk> References: <3.0.32.19970414111749.009afe90@mail.pgp.com> <9704150836.AA29850@Knud.dde.dk> Reply-To: NOSPAM!uri@ibm.net Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk >>>>> "F" == Frederik H Andersen writes: F> What I find very difficult to understand is, why the F> technology: - which is the defacto standard........... F> allows almost arbitrarily strong crypto is not considered for F> the MUST technology? Because IETF has a long tradition NOT to require a technology that is not FREELY AVAILABLE? F> Another thing, is it not true, assuming the technology is F> available, that nothing prevents a user in US and a user F> outside US to communicate using stong crypto ( e.g. 128 bit F> keys)? Yes, this is true, to the best of my knowledge. Regards, [To reply, remove "NOSPAM!" from the Uri "Reply-To:" field] -=-=-==-=-=- uri@ibm.net From owner-ietf-smime Tue Apr 15 08:40:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA12067 for ietf-smime-bks; Tue, 15 Apr 1997 08:40:04 -0700 (PDT) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA12063 for ; Tue, 15 Apr 1997 08:40:02 -0700 (PDT) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id IAA24800; Tue, 15 Apr 1997 08:40:03 -0700 (PDT) X-Sender: llundbla@nala.qualcomm.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 08:12:49 -0700 To: ietf-smime@imc.org, smime-dev@RSA.COM From: Laurence Lundblade Subject: 2nd S/MIME BOF meeting minutes - corrections Sender: owner-ietf-smime@imc.org Precedence: bulk (We should probably keep this only on the ietf-smime list, but since I posted to both...) Two little corrections: Blake Ramsdell was co-chair Deming/Worldtalk does not have a capital "T". LL From owner-ietf-smime Tue Apr 15 09:02:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA12289 for ietf-smime-bks; Tue, 15 Apr 1997 09:02:49 -0700 (PDT) Received: from dde.dde.dk (dde.dde.dk [152.95.32.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA12285 for ; Tue, 15 Apr 1997 09:02:45 -0700 (PDT) Received: by dde.dde.dk (5.61/9.3) id AA08365; Tue, 15 Apr 97 18:03:52 +0200 Received: from Knud.dde.dk by dde.dde.dk (5.61/9.3) with SMTP id AA04204; Tue, 15 Apr 97 18:03:52 +0200 Received: by Knud.dde.dk (4.1/9.7) id AA14826; Tue, 15 Apr 97 18:03:30 +0200 Message-Id: <9704151603.AA14826@Knud.dde.dk> X-Mailer: exmh version 2.0beta 12/23/96 To: ietf-smime@imc.org Subject: Re: 2nd S/MIME BOF meeting minutes Date: Tue, 15 Apr 1997 18:03:29 +0200 From: "Frederik H. Andersen" Sender: owner-ietf-smime@imc.org Precedence: bulk On Tue, 15 Apr 1997 11:13:35 -0400 Uri Blumenthal wrote: > Because IETF has a long tradition NOT to require a technology > that is not FREELY AVAILABLE? > Eh, you mean that pgp is not FREELY AVAILABLE? I am probably wrong, but I believed that it was?? I know, that these versions are meant for non-commercial use - is that the problem? What about approaching pgp.com about this as the plan seems to be with the RSA secret code! At least the pgp code is not secret! The techniques are well known. Who could prohibit a free reference implementation f.ex. outside US? Why could that not be freely imported to US? What is the problem in US? RSA again? I'm probably terrible wrong! /Frederik -- ------------------------------------------------------------------ Frederik H. Andersen Phone: +45 42 84 50 11 Dansk Data Elektronik A/S Fax: +45 42 84 52 20 Herlev Hovedgade 199 Email: fha@dde.dk (MIME accepted) DK-2730 Herlev, DENMARK PGP Fingerprint: 6B BC FB 45 E4 69 CE A2 63 E1 62 1F 0C 65 C2 E4 ------------------------------------------------------------------ From owner-ietf-smime Tue Apr 15 09:21:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA12563 for ietf-smime-bks; Tue, 15 Apr 1997 09:21:51 -0700 (PDT) Received: from hail.ncr.disa.mil (hail.ncr.disa.mil [164.117.176.115]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA12559 for ; Tue, 15 Apr 1997 09:21:48 -0700 (PDT) Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id MAA12910; Tue, 15 Apr 1997 12:19:34 -0400 (EDT) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA861131894; Tue, 15 Apr 97 12:13:09 EST Date: Tue, 15 Apr 97 12:13:09 EST From: "David Gaon" Message-Id: <9703158611.AA861131894@ncr.disa.mil> To: lgl@qualcomm.com, ietf-smime@imc.org, smime-dev@RSA.COM, Charles Breed Subject: Re[2]: 2nd S/MIME BOF meeting minutes Sender: owner-ietf-smime@imc.org Precedence: bulk I do not understand why there must be a ""MUST profiles"" albeit for interoperability. Why can't 2 communicating identities negotiate and/or agree (perhaps a-priori) on an algorithm to secure their communications ?? All we need then is an i.d. code to identify the algorithms or a field that says this is negotiable at start of communications. Will someone help clarify this ! David Gaon ______________________________ Reply Separator _________________________________ Subject: Re: 2nd S/MIME BOF meeting minutes Author: Charles Breed at smtp Date: 4/14/97 2:53 PM (The meeting was on April 9th, not the 8th...) The issues brought up by the IETF Security Area Director, Jeff Schiller, were inevitable. S/MIME needs to exist with open, non-proprietary profiles as well as profile that require licensing of patented algorithms, especially if one wants an elliptic curve algorithm. I propose the following changes to move this forward as a working group... 1. RSA to give the 'S/MIME' trade mark to a neutral, non-profit organization that's willing to arbitrate interoperability disputes. (or change the name of the spec) 2. The only MUST profile should be RSA (Public Key), 3DES (Symmetric), SHA-1 (Message Digest) 3. Unfortunately, the MUST profile (for interoperability), will be US export controlled. US export requirements should NOT be imposed upon an international standards organization. (Why should someone in Japan be forced to uses 40-bit weak crypto to communicate with someone in Germany, if their profile is unknown?) It is more dangerous to resort to weak crypto than nothing at all. Some folks would want to be able to state, "Do not send me anything less than 128-bit". 4. PKCS #7 to be an informational rfc prior to S/MIME final call 5. The spec should allow for handling of additional certificate types, such as the SPKI (SDSI) working group proposed data structure. regards, Charles Breed At 01:24 PM 4/12/97 -0700, Laurence Lundblade wrote: >Second S/MIME BOF Meeting Minutes >38th IETF, Memphis >April 8, 1997 > >Chairperson: Paul Hoffman > >Agenda: > Introduction > Status of Drafts > Status of S/MIME products > Working group formation > Issues with current draft > >Mailing lists: > ietf-smime@imc.org - for discussion of the drafts > smime-dev@rsa.com - for discussion of developer issues > >A couple of issues were brought up before we got started on the Agenda: > A question was raised as to whether work on the secuity multiparts standard > would be pulled into this working group. The problem raised was that they > require exact bit integrity for the signature to remain valid, and this is > particularly a problem with the multipart/related MIME type. > > Mention was made that the charter was posted to the mailing lists after the > previous BOF and resulted in little response > > >Status of Drafts (Paul Hofman): > Two drafts were submitted to the IETF. One is a combination of the >previous S/MIME > message specification and the interoperability guide. The other is a >certificate > specification that was split out from the previous documents. Each draft >lists open > issues. > > >Products status (Blake Ramsdel): > Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft > Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft) > > >Working group (these notes are cronological; the discussion was chaotic): > Intro slide shows: > - A working group will result in better publicity in the IETF > - Better interaction with IETF > - Greater vendor confidence > - tried to form 3 mo. ago with little response (to charter) > > Jeff Schiller, security area director, responds: > Purpose is to make a standard, not to get publicity. This BOF must >focus and make > a decision. A charter must say the working group desires to create a >standard because > working groups are only for creating standards. There cannot be >another BOF. > > Also, RSA needs to relinquish change control > > Other issues brought up (chronological order): > Vendors must follow what this working group does, or there is no point >in having > this working group. > > Tim Matthews of RSA said the main reason for control over the S/MIME >name was to > gaurantee interoperability between implementations that are labeled >S/MIME, > but would be willing to turn over control of the name if >interoperability was > otherwise gauranteed > > The current document requires intellectual property rights (IPR) of RSA. > > The reason RC2 is used is because it has been cleared by the commerce >department > for export. It is very easy for a vendor to export crypto with 40 bit >RC2. No other > algorithm has the same support (yet). > > (editors note - RC2 is a trade secret of RSA. It is not patented. >Trade secrets are > indefinite as long as they are protected, but it is the >responsibility of the owner > to protect them) > > Some suggest the RC2 trade secret is gone > > A poll asked whether implementors were willing to give change control >to the IETF. > Many were willing. Some reasons given for not forming a working group >to produce a > standard (and leaving control with RSA) were that we can't get through >the process, or > that the result has some security hole. > > The process should not be a rubber stamp process. > > A point was made that the standard should be open on the issue of >algorithms . > > A point was made that we can't do that with current algorithms (most >are encumbered). > > A point was made that acknowledged that interoperability with current >implementations > was OK, but that 40 bit crypto is unacceptably insecure for some >communities. This > point was quickly countered that the debate over the sufficiency of 40 >bits was out of the > scope of this meeting. > > We have several choices > - S/MIME evolves to be non-proprietary (e.g. stops requiring >proprietary algs) > - The right to algorithms it uses are released > - Do something completely different (e.g., MOSS) > Both profiles in S/MIME currently require RC2 (proprietary) > There is a similar problem with TLS > > Jeff suggests one solution that would be acceptable to him (which >doesn't mean the IESG and > IAB approve (yet)) is to have a single profile that doesn't include >RC2, 40 bits. > > A poll showed this would be acceptable and there was no decension (RSA >representive obstains) > > A point was made that non-US implentors can implement technology that >is deemed not > exportable in the US. > > Suggestion that we go ahead without RC2.... Some questioned whether or >not this would > be "S/MIME". > > (editor: now we're getting to the nitty gritty...) > > Jeff (area directory): S/MIME IPR issue must be resolved by July 1, >1997 or working group > cannot be formed > > Tim (RSA Inc.): RSA can work with that time frame > > Jeff's requirements: > Interoperability is a requirement, therefore some algorithms must be >mandatory. Have a > strong bias towards open algorithms, but can accept some that are >not. There are open > symmetric algorithms (editor: that can be used instead of RC2) > > Control must be with in the IETF, e.g., IETF "has a license to do >S/MIME" and IETF says what > the protocol is. > > PKCS7 isn't an issue. It can be published as an informational RFC. > > The patents on the RSA algorithm are not an issue because they will >expire. Thus the > issue is with the RC2 algorithm because it is a trade secret which >will never expire. > RSA has not disavowed its IPR for RC2 and it could go on for a long time. > >(editor's summary: RSA must resolve two issues before a working group can >begin work > towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2) >Change control > must be with the IETF (e.g., the rights to the "S/MIME" trademark must be >neutrally held.) > These must be resolved by July 1, 1997. The RSA representive acknowledged >this). > > > >On to issues (with a few minutes left) > Laurence presented proposal for reorganization of section 3 of the >document. The reorganization > was for the sake of clarity and to separate the definition of the message >formats from the rationale > for their use. There was general ascent towards the proposal, though the >meeting began to break up. > > At this point we gave up the meeting was breaking up > > One last issue raised - does the inside object really have to be MIME >encoded or not (editor it > wasn't clear whether this was the issue of transfer encoding or the issue >of MIME vs 822). > > > > > From owner-ietf-smime Tue Apr 15 09:51:32 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA12894 for ietf-smime-bks; Tue, 15 Apr 1997 09:51:32 -0700 (PDT) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA12890 for ; Tue, 15 Apr 1997 09:51:29 -0700 (PDT) Received: (from uucp@localhost) by out1.ibm.net (8.6.9/8.6.9) id QAA110531; Tue, 15 Apr 1997 16:48:17 GMT Received: from slip166-72-232-240.ny.us.ibm.net(166.72.232.240) by out1.ibm.net via smap (V1.3mjr) id smaLt8DFW; Tue Apr 15 16:26:16 1997 Received: (from uri@localhost) by alisan.ibm.net (8.7.6/8.7.3) id MAA00839; Tue, 15 Apr 1997 12:26:52 -0400 Date: Tue, 15 Apr 1997 12:26:52 -0400 Message-Id: <199704151626.MAA00839@alisan.ibm.net> From: Uri Blumenthal To: "Frederik H. Andersen" Cc: ietf-smime@imc.org Subject: Re: 2nd S/MIME BOF meeting minutes In-Reply-To: <9704151603.AA14826@Knud.dde.dk> References: <9704151603.AA14826@Knud.dde.dk> Reply-To: NOSPAM!uri@ibm.net Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk >>>>> "F" == Frederik H Andersen writes: F> Eh, you mean that pgp is not FREELY AVAILABLE? I am probably F> wrong, but I believed that it was?? I know, that these F> versions are meant for non-commercial use - is that the F> problem? Yes it is, and yes I was wrong (I thought of a different technology :-). F> What about approaching pgp.com about this as the plan seems to F> be with the RSA secret code! (:-) F> Who could prohibit a free reference implementation F> f.ex. outside US? Why could that not be freely imported to US? It is already done (see pgp263i.tar.gz on your favorite FTP server), and I think I saw it within the US (am not sure though :-). F> What is the problem in US? RSA again? Yeah, it might be, but there are freely available PGP sources in the US as well. They use RSAREF and thus are legal. F> I'm probably terrible wrong! He-he. No, you are not! How about that for a change? (:-) In light of the above - what are the reasons for not making PGP a mandatory format? [Apologies if this has already been discussed at length, in which case just kindly e-mail the replies, with the appropriate NOSPAM correction.] Regards, [To reply, remove "NOSPAM!" from the Uri "Reply-To:" field] -=-=-==-=-=- uri@ibm.net From owner-ietf-smime Tue Apr 15 10:12:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA13215 for ietf-smime-bks; Tue, 15 Apr 1997 10:12:40 -0700 (PDT) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA13210 for ; Tue, 15 Apr 1997 10:12:36 -0700 (PDT) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id KAA10670; Tue, 15 Apr 1997 10:12:07 -0700 (PDT) X-Sender: llundbla@nala.qualcomm.com Message-Id: In-Reply-To: <9703158611.AA861131894@ncr.disa.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 10:09:47 -0700 To: "David Gaon" , ietf-smime@imc.org, Charles Breed From: Laurence Lundblade Subject: Re[2]: 2nd S/MIME BOF meeting minutes Sender: owner-ietf-smime@imc.org Precedence: bulk OK, this is a standards issue, so this discussion should be on ietf-smime. You said it yourself, "albeit for interoperability". We don't want a standard that doesn't guarantee some level of interoperability - that is that two parties are guaranteed to be able to negotiate down to some set of algorithms. LL At 12:13 PM -0500 4/15/97, David Gaon wrote: > I do not understand why there must be a ""MUST profiles"" albeit for > interoperability. > > Why can't 2 communicating identities negotiate and/or agree (perhaps > a-priori) on an algorithm to secure their communications ?? > All we need then is an i.d. code to identify the algorithms or a field > that says this is negotiable at start of communications. > > Will someone help clarify this ! > > David Gaon > > >______________________________ Reply Separator >_________________________________ >Subject: Re: 2nd S/MIME BOF meeting minutes >Author: Charles Breed at smtp >Date: 4/14/97 2:53 PM > > > (The meeting was on April 9th, not the 8th...) > >The issues brought up by the IETF Security Area Director, Jeff Schiller, were >inevitable. S/MIME needs to exist with open, non-proprietary profiles as >well as >profile that require licensing of patented algorithms, especially if one >wants >an elliptic curve algorithm. > > >I propose the following changes to move this forward as a working group... > >1. RSA to give the 'S/MIME' trade mark to a neutral, non-profit organization >that's willing to arbitrate interoperability disputes. (or change the name of >the spec) > >2. The only MUST profile should be RSA (Public Key), 3DES (Symmetric), SHA-1 >(Message Digest) > >3. Unfortunately, the MUST profile (for interoperability), will be US export >controlled. US export requirements should NOT be imposed upon an >international >standards organization. (Why should someone in Japan be forced to uses 40-bit >weak crypto to communicate with someone in Germany, if their profile is >unknown?) It is more dangerous to resort to weak crypto than nothing at all. >Some folks would want to be able to state, "Do not send me anything less than >128-bit". > >4. PKCS #7 to be an informational rfc prior to S/MIME final call > >5. The spec should allow for handling of additional certificate types, >such as >the SPKI (SDSI) working group proposed data structure. > > >regards, >Charles Breed > > > > > >At 01:24 PM 4/12/97 -0700, Laurence Lundblade wrote: >>Second S/MIME BOF Meeting Minutes >>38th IETF, Memphis >>April 8, 1997 >> >>Chairperson: Paul Hoffman >> >>Agenda: >> Introduction >> Status of Drafts >> Status of S/MIME products >> Working group formation >> Issues with current draft >> >>Mailing lists: >> ietf-smime@imc.org - for discussion of the drafts >> smime-dev@rsa.com - for discussion of developer issues >> >>A couple of issues were brought up before we got started on the Agenda: >> A question was raised as to whether work on the secuity multiparts >>standard >> would be pulled into this working group. The problem raised was that they >> require exact bit integrity for the signature to remain valid, and this is >> particularly a problem with the multipart/related MIME type. >> >> Mention was made that the charter was posted to the mailing lists after >>the >> previous BOF and resulted in little response >> >> >>Status of Drafts (Paul Hofman): >> Two drafts were submitted to the IETF. One is a combination of the >>previous S/MIME >> message specification and the interoperability guide. The other is a >>certificate >> specification that was split out from the previous documents. Each draft >>lists open >> issues. >> >> >>Products status (Blake Ramsdel): >> Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft >> Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft) >> >> >>Working group (these notes are cronological; the discussion was chaotic): >> Intro slide shows: >> - A working group will result in better publicity in the IETF >> - Better interaction with IETF >> - Greater vendor confidence >> - tried to form 3 mo. ago with little response (to charter) >> >> Jeff Schiller, security area director, responds: >> Purpose is to make a standard, not to get publicity. This BOF must >>focus and make >> a decision. A charter must say the working group desires to create a >>standard because >> working groups are only for creating standards. There cannot be >>another BOF. >> >> Also, RSA needs to relinquish change control >> >> Other issues brought up (chronological order): >> Vendors must follow what this working group does, or there is no point >>in having >> this working group. >> >> Tim Matthews of RSA said the main reason for control over the S/MIME >>name was to >> gaurantee interoperability between implementations that are labeled >>S/MIME, >> but would be willing to turn over control of the name if >>interoperability was >> otherwise gauranteed >> >> The current document requires intellectual property rights (IPR) of >>RSA. >> >> The reason RC2 is used is because it has been cleared by the commerce >>department >> for export. It is very easy for a vendor to export crypto with 40 bit >>RC2. No other >> algorithm has the same support (yet). >> >> (editors note - RC2 is a trade secret of RSA. It is not patented. >>Trade secrets are >> indefinite as long as they are protected, but it is the >>responsibility of the owner >> to protect them) >> >> Some suggest the RC2 trade secret is gone >> >> A poll asked whether implementors were willing to give change control >>to the IETF. >> Many were willing. Some reasons given for not forming a working group >>to produce a >> standard (and leaving control with RSA) were that we can't get through >>the process, or >> that the result has some security hole. >> >> The process should not be a rubber stamp process. >> >> A point was made that the standard should be open on the issue of >>algorithms . >> >> A point was made that we can't do that with current algorithms (most >>are encumbered). >> >> A point was made that acknowledged that interoperability with current >>implementations >> was OK, but that 40 bit crypto is unacceptably insecure for some >>communities. This >> point was quickly countered that the debate over the sufficiency of 40 >>bits was out of the >> scope of this meeting. >> >> We have several choices >> - S/MIME evolves to be non-proprietary (e.g. stops requiring >>proprietary algs) >> - The right to algorithms it uses are released >> - Do something completely different (e.g., MOSS) >> Both profiles in S/MIME currently require RC2 (proprietary) >> There is a similar problem with TLS >> >> Jeff suggests one solution that would be acceptable to him (which >>doesn't mean the IESG and >> IAB approve (yet)) is to have a single profile that doesn't include >>RC2, 40 bits. >> >> A poll showed this would be acceptable and there was no decension (RSA >>representive obstains) >> >> A point was made that non-US implentors can implement technology that >>is deemed not >> exportable in the US. >> >> Suggestion that we go ahead without RC2.... Some questioned whether or >>not this would >> be "S/MIME". >> >> (editor: now we're getting to the nitty gritty...) >> >> Jeff (area directory): S/MIME IPR issue must be resolved by July 1, >>1997 or working group >> cannot be formed >> >> Tim (RSA Inc.): RSA can work with that time frame >> >> Jeff's requirements: >> Interoperability is a requirement, therefore some algorithms must be >>mandatory. Have a >> strong bias towards open algorithms, but can accept some that are >>not. There are open >> symmetric algorithms (editor: that can be used instead of RC2) >> >> Control must be with in the IETF, e.g., IETF "has a license to do >>S/MIME" and IETF says what >> the protocol is. >> >> PKCS7 isn't an issue. It can be published as an informational RFC. >> >> The patents on the RSA algorithm are not an issue because they will >>expire. Thus the >> issue is with the RC2 algorithm because it is a trade secret which >>will never expire. >> RSA has not disavowed its IPR for RC2 and it could go on for a long >>time. >> >>(editor's summary: RSA must resolve two issues before a working group can >>begin work >> towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2) >>Change control >> must be with the IETF (e.g., the rights to the "S/MIME" trademark must be >>neutrally held.) >> These must be resolved by July 1, 1997. The RSA representive acknowledged >>this). >> >> >> >>On to issues (with a few minutes left) >> Laurence presented proposal for reorganization of section 3 of the >>document. The reorganization >> was for the sake of clarity and to separate the definition of the message >>formats from the rationale >> for their use. There was general ascent towards the proposal, though the >>meeting began to break up. >> >> At this point we gave up the meeting was breaking up >> >> One last issue raised - does the inside object really have to be MIME >>encoded or not (editor it >> wasn't clear whether this was the issue of transfer encoding or the issue >>of MIME vs 822). >> >> >> >> >> From owner-ietf-smime Tue Apr 15 11:27:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA14253 for ietf-smime-bks; Tue, 15 Apr 1997 11:27:23 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA14249 for ; Tue, 15 Apr 1997 11:27:20 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id LAA18214; Tue, 15 Apr 1997 11:27:40 -0700 (PDT) Message-Id: <3.0.32.19970415113143.009a7c20@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 15 Apr 1997 11:31:49 -0700 To: uri@ibm.net, "Frederik H. Andersen" From: Charles Breed Subject: Re: 2nd S/MIME BOF meeting minutes Cc: ietf-smime@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk :note to Paul H, we'll move this off this list... The way I see it... - Yes, freeware versions of pgp are available worldwide - pgp needs to be enhanced to 'handle' other certificates / capabilities - The name PGP is trademarked, just like S/MIME - RSAref is only distributed from the MIT site, an agreement between RSA and MIT - RSAref is strictly for non-commercial use, not for resell - S/MIME was derived from a competing group, without any compatibility with pgp - A single, non-proprietary, open, IETF approved format / data structure that we can all agree upon would be a very good thing!(merged DMS, MSP, PEM, MOSS, S/MIME, PGP/MIME) - The community needs buy in from all the major email vendors for secure email to become a reality. - This reminds me of the pathetic battles between Fast Ethernet, 100VG, CDDI, 25mbATM... (a Rodney King saying comes to mind...) Charles Breed At 12:26 PM 4/15/97 -0400, Uri Blumenthal wrote: >>>>>> "F" == Frederik H Andersen writes: > > F> Eh, you mean that pgp is not FREELY AVAILABLE? I am probably > F> wrong, but I believed that it was?? I know, that these > F> versions are meant for non-commercial use - is that the > F> problem? > >Yes it is, and yes I was wrong (I thought of a different technology :-). > > F> What about approaching pgp.com about this as the plan seems to > F> be with the RSA secret code! > >(:-) > > F> Who could prohibit a free reference implementation > F> f.ex. outside US? Why could that not be freely imported to US? > >It is already done (see pgp263i.tar.gz on your favorite FTP server), >and I think I saw it within the US (am not sure though :-). > > F> What is the problem in US? RSA again? > >Yeah, it might be, but there are freely available PGP sources in >the US as well. They use RSAREF and thus are legal. > > F> I'm probably terrible wrong! > >He-he. No, you are not! How about that for a change? (:-) > >In light of the above - what are the reasons for not making >PGP a mandatory format? [Apologies if this has already been >discussed at length, in which case just kindly e-mail the >replies, with the appropriate NOSPAM correction.] > > >Regards, [To reply, remove "NOSPAM!" from the >Uri "Reply-To:" field] >-=-=-==-=-=- uri@ibm.net > > > From owner-ietf-smime Tue Apr 15 11:23:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA14213 for ietf-smime-bks; Tue, 15 Apr 1997 11:23:09 -0700 (PDT) Received: from RSA.COM (chirality.rsa.com [192.80.211.33]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA14209 for ; Tue, 15 Apr 1997 11:23:06 -0700 (PDT) Received: from eagle.rsa.com by RSA.COM with SMTP id AA00416; Tue, 15 Apr 97 10:20:55 PDT Received: from lobester.rsa.com by eagle.rsa.com via smtpd (for chirality.rsa.com [192.80.211.33]) with SMTP; 15 Apr 1997 18:25:33 UT Received: by LOBESTER.rsa.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC498F.E0A39860@LOBESTER.rsa.com>; Tue, 15 Apr 1997 11:26:35 -0700 Message-Id: From: Steve Dusse To: "'ietf-smime@imc.org'" , "'David Gaon'" Subject: RE: Re[2]: 2nd S/MIME BOF meeting minutes Date: Tue, 15 Apr 1997 11:26:34 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk In the world of peer-to-peer store-and-forward communications (e.g. email) there really is no negotiation possible at "start of communications". This is especially evident in the case of a multicast message, i.e. sending a message to a bunch of recipients. In such an environment, negotiation can be done either out of band beforehand (e.g. by looking up some entries in a directory) or via exchange of email by the end users who are not always savvy enough to effectively negotiate encryption algorithms and key sizes. It was our intent when creating S/MIME to provide some base level of interoperability possible among all S/MIME-enabled user agents (i.e. the "MUSTS") and an easy path to negotiating the use of the strongest possible encryption where both ends are capable (i.e. the "SHOULDS"). -steve >---------- >From: David Gaon[SMTP:gaond@ncr.disa.mil] >Sent: Tuesday, April 15, 1997 10:13 AM >To: lgl@qualcomm.com; ietf-smime@imc.org; smime-dev@RSA.COM; Charles Breed >Subject: Re[2]: 2nd S/MIME BOF meeting minutes > > I do not understand why there must be a ""MUST profiles"" albeit for > interoperability. > > Why can't 2 communicating identities negotiate and/or agree (perhaps > a-priori) on an algorithm to secure their communications ?? > All we need then is an i.d. code to identify the algorithms or a field > that says this is negotiable at start of communications. > > Will someone help clarify this ! > > David Gaon > > >______________________________ Reply Separator >_________________________________ >Subject: Re: 2nd S/MIME BOF meeting minutes >Author: Charles Breed at smtp >Date: 4/14/97 2:53 PM > > > (The meeting was on April 9th, not the 8th...) > >The issues brought up by the IETF Security Area Director, Jeff Schiller, were >inevitable. S/MIME needs to exist with open, non-proprietary profiles as well >as >profile that require licensing of patented algorithms, especially if one >wants >an elliptic curve algorithm. > > >I propose the following changes to move this forward as a working group... > >1. RSA to give the 'S/MIME' trade mark to a neutral, non-profit organization >that's willing to arbitrate interoperability disputes. (or change the name of >the spec) > >2. The only MUST profile should be RSA (Public Key), 3DES (Symmetric), SHA-1 >(Message Digest) > >3. Unfortunately, the MUST profile (for interoperability), will be US export >controlled. US export requirements should NOT be imposed upon an >international >standards organization. (Why should someone in Japan be forced to uses 40-bit >weak crypto to communicate with someone in Germany, if their profile is >unknown?) It is more dangerous to resort to weak crypto than nothing at all. >Some folks would want to be able to state, "Do not send me anything less than >128-bit". > >4. PKCS #7 to be an informational rfc prior to S/MIME final call > >5. The spec should allow for handling of additional certificate types, such >as >the SPKI (SDSI) working group proposed data structure. > > >regards, >Charles Breed > > > > > >At 01:24 PM 4/12/97 -0700, Laurence Lundblade wrote: >>Second S/MIME BOF Meeting Minutes >>38th IETF, Memphis >>April 8, 1997 >> >>Chairperson: Paul Hoffman >> >>Agenda: >> Introduction >> Status of Drafts >> Status of S/MIME products >> Working group formation >> Issues with current draft >> >>Mailing lists: >> ietf-smime@imc.org - for discussion of the drafts >> smime-dev@rsa.com - for discussion of developer issues >> >>A couple of issues were brought up before we got started on the Agenda: >> A question was raised as to whether work on the secuity multiparts >>standard >> would be pulled into this working group. The problem raised was that they >> require exact bit integrity for the signature to remain valid, and this is >> particularly a problem with the multipart/related MIME type. >> >> Mention was made that the charter was posted to the mailing lists after >>the >> previous BOF and resulted in little response >> >> >>Status of Drafts (Paul Hofman): >> Two drafts were submitted to the IETF. One is a combination of the >>previous S/MIME >> message specification and the interoperability guide. The other is a >>certificate >> specification that was split out from the previous documents. Each draft >>lists open >> issues. >> >> >>Products status (Blake Ramsdel): >> Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft >> Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft) >> >> >>Working group (these notes are cronological; the discussion was chaotic): >> Intro slide shows: >> - A working group will result in better publicity in the IETF >> - Better interaction with IETF >> - Greater vendor confidence >> - tried to form 3 mo. ago with little response (to charter) >> >> Jeff Schiller, security area director, responds: >> Purpose is to make a standard, not to get publicity. This BOF must >>focus and make >> a decision. A charter must say the working group desires to create a >>standard because >> working groups are only for creating standards. There cannot be >>another BOF. >> >> Also, RSA needs to relinquish change control >> >> Other issues brought up (chronological order): >> Vendors must follow what this working group does, or there is no point >>in having >> this working group. >> >> Tim Matthews of RSA said the main reason for control over the S/MIME >>name was to >> gaurantee interoperability between implementations that are labeled >>S/MIME, >> but would be willing to turn over control of the name if >>interoperability was >> otherwise gauranteed >> >> The current document requires intellectual property rights (IPR) of >>RSA. >> >> The reason RC2 is used is because it has been cleared by the commerce >>department >> for export. It is very easy for a vendor to export crypto with 40 bit >>RC2. No other >> algorithm has the same support (yet). >> >> (editors note - RC2 is a trade secret of RSA. It is not patented. >>Trade secrets are >> indefinite as long as they are protected, but it is the >>responsibility of the owner >> to protect them) >> >> Some suggest the RC2 trade secret is gone >> >> A poll asked whether implementors were willing to give change control >>to the IETF. >> Many were willing. Some reasons given for not forming a working group >>to produce a >> standard (and leaving control with RSA) were that we can't get through >>the process, or >> that the result has some security hole. >> >> The process should not be a rubber stamp process. >> >> A point was made that the standard should be open on the issue of >>algorithms . >> >> A point was made that we can't do that with current algorithms (most >>are encumbered). >> >> A point was made that acknowledged that interoperability with current >>implementations >> was OK, but that 40 bit crypto is unacceptably insecure for some >>communities. This >> point was quickly countered that the debate over the sufficiency of 40 >>bits was out of the >> scope of this meeting. >> >> We have several choices >> - S/MIME evolves to be non-proprietary (e.g. stops requiring >>proprietary algs) >> - The right to algorithms it uses are released >> - Do something completely different (e.g., MOSS) >> Both profiles in S/MIME currently require RC2 (proprietary) >> There is a similar problem with TLS >> >> Jeff suggests one solution that would be acceptable to him (which >>doesn't mean the IESG and >> IAB approve (yet)) is to have a single profile that doesn't include >>RC2, 40 bits. >> >> A poll showed this would be acceptable and there was no decension (RSA >>representive obstains) >> >> A point was made that non-US implentors can implement technology that >>is deemed not >> exportable in the US. >> >> Suggestion that we go ahead without RC2.... Some questioned whether or >>not this would >> be "S/MIME". >> >> (editor: now we're getting to the nitty gritty...) >> >> Jeff (area directory): S/MIME IPR issue must be resolved by July 1, >>1997 or working group >> cannot be formed >> >> Tim (RSA Inc.): RSA can work with that time frame >> >> Jeff's requirements: >> Interoperability is a requirement, therefore some algorithms must be >>mandatory. Have a >> strong bias towards open algorithms, but can accept some that are >>not. There are open >> symmetric algorithms (editor: that can be used instead of RC2) >> >> Control must be with in the IETF, e.g., IETF "has a license to do >>S/MIME" and IETF says what >> the protocol is. >> >> PKCS7 isn't an issue. It can be published as an informational RFC. >> >> The patents on the RSA algorithm are not an issue because they will >>expire. Thus the >> issue is with the RC2 algorithm because it is a trade secret which >>will never expire. >> RSA has not disavowed its IPR for RC2 and it could go on for a long >>time. >> >>(editor's summary: RSA must resolve two issues before a working group can >>begin work >> towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2) >>Change control >> must be with the IETF (e.g., the rights to the "S/MIME" trademark must be >>neutrally held.) >> These must be resolved by July 1, 1997. The RSA representive acknowledged >>this). >> >> >> >>On to issues (with a few minutes left) >> Laurence presented proposal for reorganization of section 3 of the >>document. The reorganization >> was for the sake of clarity and to separate the definition of the message >>formats from the rationale >> for their use. There was general ascent towards the proposal, though the >>meeting began to break up. >> >> At this point we gave up the meeting was breaking up >> >> One last issue raised - does the inside object really have to be MIME >>encoded or not (editor it >> wasn't clear whether this was the issue of transfer encoding or the issue >>of MIME vs 822). >> >> >> >> >> > > From owner-ietf-smime Tue Apr 15 11:42:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA14509 for ietf-smime-bks; Tue, 15 Apr 1997 11:42:25 -0700 (PDT) Received: from hail.ncr.disa.mil (hail.ncr.disa.mil [164.117.176.115]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA14505 for ; Tue, 15 Apr 1997 11:42:22 -0700 (PDT) Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id OAA01714; Tue, 15 Apr 1997 14:40:20 -0400 (EDT) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA861140431; Tue, 15 Apr 97 14:38:24 EST Date: Tue, 15 Apr 97 14:38:24 EST From: "David Gaon" Message-Id: <9703158611.AA861140431@ncr.disa.mil> To: ietf-smime@imc.org, Steve Dusse Subject: Re[4]: 2nd S/MIME BOF meeting minutes Sender: owner-ietf-smime@imc.org Precedence: bulk Thank you Steve You hit on 2 ways - directory look up and prior e-mail exchange A 3rd way would be to encrypt using an algorithm and identifying the algorithm to the recipient in the open paret of the message. Still, if I understand you correctly, you propose to use the ""MUST"" to securely negotiate for an algorithm and key !! If that be true, then: - why do we need 3 profiles in the spec, surely one would be sufficient - if the profile for negotiation is strong enough, -- then why not use it for the actual exchange of information David Gaon ______________________________ Reply Separator _________________________________ Subject: RE: Re[2]: 2nd S/MIME BOF meeting minutes Author: Steve Dusse at smtp Date: 4/15/97 2:24 PM In the world of peer-to-peer store-and-forward communications (e.g. email) there really is no negotiation possible at "start of communications". This is especially evident in the case of a multicast message, i.e. sending a message to a bunch of recipients. In such an environment, negotiation can be done either out of band beforehand (e.g. by looking up some entries in a directory) or via exchange of email by the end users who are not always savvy enough to effectively negotiate encryption algorithms and key sizes. It was our intent when creating S/MIME to provide some base level of interoperability possible among all S/MIME-enabled user agents (i.e. the "MUSTS") and an easy path to negotiating the use of the strongest possible encryption where both ends are capable (i.e. the "SHOULDS"). -steve >---------- >From: David Gaon[SMTP:gaond@ncr.disa.mil] >Sent: Tuesday, April 15, 1997 10:13 AM >To: lgl@qualcomm.com; ietf-smime@imc.org; smime-dev@RSA.COM; Charles Breed >Subject: Re[2]: 2nd S/MIME BOF meeting minutes > > I do not understand why there must be a ""MUST profiles"" albeit for > interoperability. > > Why can't 2 communicating identities negotiate and/or agree (perhaps > a-priori) on an algorithm to secure their communications ?? > All we need then is an i.d. code to identify the algorithms or a field > that says this is negotiable at start of communications. > > Will someone help clarify this ! > > David Gaon > > >______________________________ Reply Separator >_________________________________ >Subject: Re: 2nd S/MIME BOF meeting minutes >Author: Charles Breed at smtp >Date: 4/14/97 2:53 PM > > > (The meeting was on April 9th, not the 8th...) > >The issues brought up by the IETF Security Area Director, Jeff Schiller, were >inevitable. S/MIME needs to exist with open, non-proprietary profiles as well >as >profile that require licensing of patented algorithms, especially if one >wants >an elliptic curve algorithm. > > >I propose the following changes to move this forward as a working group... > >1. RSA to give the 'S/MIME' trade mark to a neutral, non-profit organization >that's willing to arbitrate interoperability disputes. (or change the name of >the spec) > >2. The only MUST profile should be RSA (Public Key), 3DES (Symmetric), SHA-1 >(Message Digest) > >3. Unfortunately, the MUST profile (for interoperability), will be US export >controlled. US export requirements should NOT be imposed upon an >international >standards organization. (Why should someone in Japan be forced to uses 40-bit >weak crypto to communicate with someone in Germany, if their profile is >unknown?) It is more dangerous to resort to weak crypto than nothing at all. >Some folks would want to be able to state, "Do not send me anything less than >128-bit". > >4. PKCS #7 to be an informational rfc prior to S/MIME final call > >5. The spec should allow for handling of additional certificate types, such >as >the SPKI (SDSI) working group proposed data structure. > > >regards, >Charles Breed > > > > > >At 01:24 PM 4/12/97 -0700, Laurence Lundblade wrote: >>Second S/MIME BOF Meeting Minutes >>38th IETF, Memphis >>April 8, 1997 >> >>Chairperson: Paul Hoffman >> >>Agenda: >> Introduction >> Status of Drafts >> Status of S/MIME products >> Working group formation >> Issues with current draft >> >>Mailing lists: >> ietf-smime@imc.org - for discussion of the drafts >> smime-dev@rsa.com - for discussion of developer issues >> >>A couple of issues were brought up before we got started on the Agenda: >> A question was raised as to whether work on the secuity multiparts >>standard >> would be pulled into this working group. The problem raised was that they >> require exact bit integrity for the signature to remain valid, and this is >> particularly a problem with the multipart/related MIME type. >> >> Mention was made that the charter was posted to the mailing lists after >>the >> previous BOF and resulted in little response >> >> >>Status of Drafts (Paul Hofman): >> Two drafts were submitted to the IETF. One is a combination of the >>previous S/MIME >> message specification and the interoperability guide. The other is a >>certificate >> specification that was split out from the previous documents. Each draft >>lists open >> issues. >> >> >>Products status (Blake Ramsdel): >> Shipping: Entrust, ConnectSoft, Deming/WorldTalk, Frontier, OpenSoft >> Near Shipping: Netscape Messenger, Internet Explorer 4 (Microsoft) >> >> >>Working group (these notes are cronological; the discussion was chaotic): >> Intro slide shows: >> - A working group will result in better publicity in the IETF >> - Better interaction with IETF >> - Greater vendor confidence >> - tried to form 3 mo. ago with little response (to charter) >> >> Jeff Schiller, security area director, responds: >> Purpose is to make a standard, not to get publicity. This BOF must >>focus and make >> a decision. A charter must say the working group desires to create a >>standard because >> working groups are only for creating standards. There cannot be >>another BOF. >> >> Also, RSA needs to relinquish change control >> >> Other issues brought up (chronological order): >> Vendors must follow what this working group does, or there is no point >>in having >> this working group. >> >> Tim Matthews of RSA said the main reason for control over the S/MIME >>name was to >> gaurantee interoperability between implementations that are labeled >>S/MIME, >> but would be willing to turn over control of the name if >>interoperability was >> otherwise gauranteed >> >> The current document requires intellectual property rights (IPR) of >>RSA. >> >> The reason RC2 is used is because it has been cleared by the commerce >>department >> for export. It is very easy for a vendor to export crypto with 40 bit >>RC2. No other >> algorithm has the same support (yet). >> >> (editors note - RC2 is a trade secret of RSA. It is not patented. >>Trade secrets are >> indefinite as long as they are protected, but it is the >>responsibility of the owner >> to protect them) >> >> Some suggest the RC2 trade secret is gone >> >> A poll asked whether implementors were willing to give change control >>to the IETF. >> Many were willing. Some reasons given for not forming a working group >>to produce a >> standard (and leaving control with RSA) were that we can't get through >>the process, or >> that the result has some security hole. >> >> The process should not be a rubber stamp process. >> >> A point was made that the standard should be open on the issue of >>algorithms . >> >> A point was made that we can't do that with current algorithms (most >>are encumbered). >> >> A point was made that acknowledged that interoperability with current >>implementations >> was OK, but that 40 bit crypto is unacceptably insecure for some >>communities. This >> point was quickly countered that the debate over the sufficiency of 40 >>bits was out of the >> scope of this meeting. >> >> We have several choices >> - S/MIME evolves to be non-proprietary (e.g. stops requiring >>proprietary algs) >> - The right to algorithms it uses are released >> - Do something completely different (e.g., MOSS) >> Both profiles in S/MIME currently require RC2 (proprietary) >> There is a similar problem with TLS >> >> Jeff suggests one solution that would be acceptable to him (which >>doesn't mean the IESG and >> IAB approve (yet)) is to have a single profile that doesn't include >>RC2, 40 bits. >> >> A poll showed this would be acceptable and there was no decension (RSA >>representive obstains) >> >> A point was made that non-US implentors can implement technology that >>is deemed not >> exportable in the US. >> >> Suggestion that we go ahead without RC2.... Some questioned whether or >>not this would >> be "S/MIME". >> >> (editor: now we're getting to the nitty gritty...) >> >> Jeff (area directory): S/MIME IPR issue must be resolved by July 1, >>1997 or working group >> cannot be formed >> >> Tim (RSA Inc.): RSA can work with that time frame >> >> Jeff's requirements: >> Interoperability is a requirement, therefore some algorithms must be >>mandatory. Have a >> strong bias towards open algorithms, but can accept some that are >>not. There are open >> symmetric algorithms (editor: that can be used instead of RC2) >> >> Control must be with in the IETF, e.g., IETF "has a license to do >>S/MIME" and IETF says what >> the protocol is. >> >> PKCS7 isn't an issue. It can be published as an informational RFC. >> >> The patents on the RSA algorithm are not an issue because they will >>expire. Thus the >> issue is with the RC2 algorithm because it is a trade secret which >>will never expire. >> RSA has not disavowed its IPR for RC2 and it could go on for a long >>time. >> >>(editor's summary: RSA must resolve two issues before a working group can >>begin work >> towards a standard. 1) S/MIME must not rely on a trade secret (RC2), 2) >>Change control >> must be with the IETF (e.g., the rights to the "S/MIME" trademark must be >>neutrally held.) >> These must be resolved by July 1, 1997. The RSA representive acknowledged >>this). >> >> >> >>On to issues (with a few minutes left) >> Laurence presented proposal for reorganization of section 3 of the >>document. The reorganization >> was for the sake of clarity and to separate the definition of the message >>formats from the rationale >> for their use. There was general ascent towards the proposal, though the >>meeting began to break up. >> >> At this point we gave up the meeting was breaking up >> >> One last issue raised - does the inside object really have to be MIME >>encoded or not (editor it >> wasn't clear whether this was the issue of transfer encoding or the issue >>of MIME vs 822). >> >> >> >> >> > > From owner-ietf-smime Tue Apr 15 12:23:32 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA14932 for ietf-smime-bks; Tue, 15 Apr 1997 12:23:32 -0700 (PDT) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA14928 for ; Tue, 15 Apr 1997 12:23:29 -0700 (PDT) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id MAA03091; Tue, 15 Apr 1997 12:23:26 -0700 (PDT) X-Sender: llundbla@nala.qualcomm.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Apr 1997 12:23:41 -0700 To: Steve Dusse , "'smime-dev@RSA.COM'" , ietf-smime@imc.org, "'weboland@globalkey.com'" From: Laurence Lundblade Subject: RE: RC2 Licensing Sender: owner-ietf-smime@imc.org Precedence: bulk Steve, I know this is a delecate subject, but I'm not at all sure that the domestic issue is moot. There is certainly a community of free and share-ware developers that don't have access to RC2 now that would probably like to have access to it. The question is how important is that community. There are still large segments of the Internet e-mail community that use freeware like Pine. In fact I believe the most UNIX internet e-mail is freeware based as there are few commercial products. This may become an issue as folks try to deploy S/MIME. I'm also not sure that the IETF views this issue as moot. I don't recall the discussions at the BOF being qualified as domestic versus international. My understanding was that any technology that was encumbered indefinitely was a problem. LL At 11:11 AM -0700 4/15/97, Steve Dusse wrote: >Hi Walt, > >RSA's official position on RC2 is that it is a trade secret and that any >implementation of RC2 anywhere in the world, other than the copyrighted >code in RSA's software toolkits, was derived from RSA's toolkits >illegally (e.g. via reverse engineering or otherwise). > >We are working very hard to come up with a licensing scheme that is >acceptable to everyone (an oxymoron of sorts...) for use in S/MIME. >Most of the US e-mail vendors have already licensed this technology so >the issue domestically is fairly moot. Internationally, we have a much >greater challenge, how to get RC2 technology legally to overseas S/MIME >developers in toolkit form. Not an easy task. Suggestions are welcome. > >Cheers, >Steve Dusse >CTO >RSA > > >>---------- >>From: weboland@globalkey.com[SMTP:weboland@globalkey.com] >>Sent: Tuesday, April 15, 1997 8:13 AM >>To: smime-dev@RSA.COM >>Subject: RC2 Licensing >> >> >>Lindsay Mathieson asked the question regarding the licensing issues of >>RC2 (or other RSA algorithms) outside of the RSA toolkits (i.e. using >>the crypl200 library). If there was a response, can you please repeat >>it. I seemed to have missed it. >> >>Thanks, >>Walt Boland >> From owner-ietf-smime Tue Apr 15 12:45:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA15237 for ietf-smime-bks; Tue, 15 Apr 1997 12:45:54 -0700 (PDT) Received: from ayax.commtouch.co.il (smtp.commtouch.co.il [194.90.151.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA15233 for ; Tue, 15 Apr 1997 12:45:49 -0700 (PDT) Received: from bigg ([199.203.201.166]) by ayax.commtouch.co.il (Netscape Mail Server v2.02) with SMTP id AAA224; Tue, 15 Apr 1997 22:45:45 +0300 From: Geoff Klein Message-Id: <19970415224502geoff@bigg> Date: Tue Apr 15 22:45:02 1997 To: spock@RSA.COM, ietf-smime@imc.org, gaond@ncr.disa.mil X-Priority: Normal Subject: Re: RE: Re[2]: 2nd S/MIME BOF meeting minutes X-Mailer: Pronto Secure [Ver 1.13] X-ProntoSecureInfo: T=signed, P=x-pgp Sender: owner-ietf-smime@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: spock@RSA.COM, ietf-smime@imc.org, gaond@ncr.disa.mil Date: Tue Apr 15 22:44:56 1997 > In the world of peer-to-peer store-and-forward communications (e.g. > email) there really is no negotiation possible at "start of > communications". This is especially evident in the case of a multicast > message, i.e. sending a message to a bunch of recipients. > > In such an environment, negotiation can be done either out of band > beforehand (e.g. by looking up some entries in a directory) or via > exchange of email by the end users who are not always savvy enough to > effectively negotiate encryption algorithms and key sizes. It was our > intent when creating S/MIME to provide some base level of > interoperability possible among all S/MIME-enabled user agents (i.e. > the "MUSTS") and an easy path to negotiating the use of the strongest > possible encryption where both ends are capable (i.e. the "SHOULDS"). > > -steve Since certificates are in any case a prerequisit, supported/prefered algorithms could be published as extended properties of an X509. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBM1PozULv5OMYFK1FAQH6nQP+OQf1E2yJ0JgfRGkLBvbh4zAzTgd23le6 FMj4HHQPNV8zHbHFTpby8QVzrb/i4Ufx0IVQpQyKRfeaXrzcF4D3lKuQ/sqfWYUZ miYKo/M64iO8Y8Dgcc5JQmOPiV1U+GlYje39S4iOjJ4yjDr+WODS1kuL6h4FPl2y iM80oZ0XvHE= =VD0l -----END PGP SIGNATURE----- From owner-ietf-smime Tue Apr 15 13:51:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA16141 for ietf-smime-bks; Tue, 15 Apr 1997 13:51:48 -0700 (PDT) Received: from PICARD.3K.COM (picard.3k.com [198.151.172.33]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA16137 for ; Tue, 15 Apr 1997 13:51:46 -0700 (PDT) From: "Chris Bartram" Organization: 3k Associates Reply-To: rcb@3k.com Message-Id: <00438X@PICARD.3K.COM> X-Mailer: NetMail/3000 [Version B.06 97/04/09] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_-+-_-04/15/97 16:51:56-_-+-_" Date: Tue, 15 Apr 1997 16:51:56 -0400 X-Hpdesk-Priority: 3 (Normal Priority) Subject: Fw: Re[2]: RC2 Licensing To: ietf-smime@imc.org Sender: owner-ietf-smime@imc.org Precedence: bulk --_-+-_-04/15/97 16:51:56-_-+-_ Content-Type: Text/Plain Content-Disposition: inline This message has been forwarded to you. --_-+-_-04/15/97 16:51:56-_-+-_ From: "Chris Bartram" Organization: 3k Associates Reply-To: rcb@3k.com Message-Id: <00438Q@PICARD.3K.COM> X-Mailer: NetMail/3000 [Version B.06 97/04/09] MIME-Version: 1.0 Content-Type: Text/Plain Date: Tue, 15 Apr 1997 16:49:19 -0400 X-Hpdesk-Priority: 3 (Normal Priority) Subject: Re[2]: RC2 Licensing To: smime-dev@RSA.COM In SPOCK@RSA.COM writes: > RSA's official position on RC2 is that it is a trade secret and that any > implementation of RC2 anywhere in the world, other than the copyrighted > code in RSA's software toolkits, was derived from RSA's toolkits > illegally (e.g. via reverse engineering or otherwise). > > We are working very hard to come up with a licensing scheme that is > acceptable to everyone (an oxymoron of sorts...) for use in S/MIME. > Most of the US e-mail vendors have already licensed this technology so > the issue domestically is fairly moot. Internationally, we have a much > greater challenge, how to get RC2 technology legally to overseas S/MIME > developers in toolkit form. Not an easy task. Suggestions are welcome. So what about those of us that work on platforms not blessed by RSA? Last I asked (about HP3000s in particular) RSA's position was that they had no interest in porting to that platform... and we're not willing to pay $50k(?) to license source code ourselves to do a port that we'd then have to pay RSA for the right to use... And we can't "legally" use any "public domain" code... And just for fun I even asked about paying RSA to port and was told there weren't resources available to do it even if we (or someone) was willing to pay to have the toolset(s) ported. I'm sure there are other platforms that fall into the same boat. I guess that leaves us stuck with "standards" which we can't legally meet. Wonderful. -Chris Bartram 3k Associates, Inc. --_-+-_-04/15/97 16:51:56-_-+-_-- From owner-ietf-smime Tue Apr 15 17:42:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA19020 for ietf-smime-bks; Tue, 15 Apr 1997 17:42:59 -0700 (PDT) Received: from tumbleweed1.tumbleweed.com (tumbleweed.com [207.88.20.30]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA19016 for ; Tue, 15 Apr 1997 17:42:56 -0700 (PDT) Received: from jeff.tumbleweed.com ([207.220.220.34]) by tumbleweed1.tumbleweed.com (post.office MTA v1.9.1 ID# 0-11773) with SMTP id AAA283; Tue, 15 Apr 1997 17:42:35 -0700 Message-Id: <3.0.32.19970415174212.006aa350@mail.tumbleweed.com> X-Sender: jeff@mail.tumbleweed.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 15 Apr 1997 17:42:13 -0700 To: Laurence Lundblade , Steve Dusse , "'smime-dev@RSA.COM'" , ietf-smime@imc.org, "'weboland@globalkey.com'" From: jeff@tumbleweed.com (Jeff Smith) Subject: RE: RC2 Licensing Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk I would like to know what the licensing fee will be after RC2 has been accepted as a standard compression algorithm for the S/MIME standard. I fear that vendors such as myself would be at a significant risk in this event unless there were open alternatives as part of the standard. On a slightly different but equally relevant note, RSA already has proposed a per unit royalty for use of their algorithms. Companies such as Netscape and Microsoft can afford to buy out a license with lots of cash or stock. Companies such as Tumbleweed Software cannot and hence will have trouble competing, particularly given some of the new business models in place for internet distribution. Importantly, in some respects, Netscape and Microsoft have incentives to support the RC2 standard as it acts as a barrier to entry into the S/MIME market for less capitalized companies. By analogy, although this is not an officially sanctioned standard, PDF is an open trade mark -- Adobe does not own it; they only own the mark for Acrobat. And Adobe changed the Acrobat PDF format in the 1.2 version to remove any proprietary compression algorithms. The legacy issues with PDF 1.1 and 1.0 documents due to proprietary compression algorithms will be around for some time. And in this case, the cost of the license to these proprietary algorithms increased with the proliferation of the format. In short, small internet start-up companies are vulnerable today and will become more vulnerable tomorrow with the existing proposal for RC2. Of course the trademark issue is significant as well. Jeffrey C. Smith CEO, Tumbleweed Software At 12:23 PM 4/15/97 -0700, Laurence Lundblade wrote: >Steve, I know this is a delecate subject, but I'm not at all sure that the >domestic issue is moot. There is certainly a community of free and >share-ware developers that don't have access to RC2 now that would probably >like to have access to it. The question is how important is that >community. There are still large segments of the Internet e-mail community >that use freeware like Pine. In fact I believe the most UNIX internet >e-mail is freeware based as there are few commercial products. This may >become an issue as folks try to deploy S/MIME. > >I'm also not sure that the IETF views this issue as moot. I don't recall >the discussions at the BOF being qualified as domestic versus >international. My understanding was that any technology that was encumbered >indefinitely was a problem. > >LL > > > >At 11:11 AM -0700 4/15/97, Steve Dusse wrote: >>Hi Walt, >> >>RSA's official position on RC2 is that it is a trade secret and that any >>implementation of RC2 anywhere in the world, other than the copyrighted >>code in RSA's software toolkits, was derived from RSA's toolkits >>illegally (e.g. via reverse engineering or otherwise). >> >>We are working very hard to come up with a licensing scheme that is >>acceptable to everyone (an oxymoron of sorts...) for use in S/MIME. >>Most of the US e-mail vendors have already licensed this technology so >>the issue domestically is fairly moot. Internationally, we have a much >>greater challenge, how to get RC2 technology legally to overseas S/MIME >>developers in toolkit form. Not an easy task. Suggestions are welcome. >> >>Cheers, >>Steve Dusse >>CTO >>RSA >> >> >>>---------- >>>From: weboland@globalkey.com[SMTP:weboland@globalkey.com] >>>Sent: Tuesday, April 15, 1997 8:13 AM >>>To: smime-dev@RSA.COM >>>Subject: RC2 Licensing >>> >>> >>>Lindsay Mathieson asked the question regarding the licensing issues of >>>RC2 (or other RSA algorithms) outside of the RSA toolkits (i.e. using >>>the crypl200 library). If there was a response, can you please repeat >>>it. I seemed to have missed it. >>> >>>Thanks, >>>Walt Boland >>> > > > > From owner-ietf-smime Tue Apr 15 21:02:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA20659 for ietf-smime-bks; Tue, 15 Apr 1997 21:02:43 -0700 (PDT) Received: from out2.ibm.net (out2.ibm.net [165.87.201.252]) by mail.proper.com (8.8.5/8.7.3) with SMTP id VAA20655 for ; Tue, 15 Apr 1997 21:02:40 -0700 (PDT) Received: (from uucp@localhost) by out2.ibm.net (8.6.9/8.6.9) id EAA626907; Wed, 16 Apr 1997 04:03:16 GMT Received: from slip166-72-232-161.ny.us.ibm.net(166.72.232.161) by out2.ibm.net via smap (V1.3mjr) id smasFsDM2; Wed Apr 16 04:02:44 1997 Received: (from uri@localhost) by alisan.ibm.net (8.7.6/8.7.3) id AAA03633; Wed, 16 Apr 1997 00:03:16 -0400 Date: Wed, 16 Apr 1997 00:03:16 -0400 Message-Id: <199704160403.AAA03633@alisan.ibm.net> From: Uri Blumenthal To: jeff@tumbleweed.com (Jeff Smith) Cc: smime-dev@RSA.COM, ietf-smime@imc.org Subject: RE: RC2 Licensing In-Reply-To: <3.0.32.19970415174212.006aa350@mail.tumbleweed.com> References: <3.0.32.19970415174212.006aa350@mail.tumbleweed.com> Reply-To: NOSPAM!uri@ibm.net Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk >>>>> "Jeff" == Jeff Smith writes: Jeff> I would like to know what the licensing fee will be after ^^^^^ Jeff> RC2 has been accepted as a standard compression algorithm Jeff> for the S/MIME standard. NO! "If" - NOT "after"! I am STRONGLY against making a non-free algorithm part of the standard. I'm 100% OPPOSED to making it a required standard. In the world where crypto algorithms are in abundance, it is unwise to follow a proprietary lock-in road... There is zero technical justification. Jeff> By analogy, although this is not an officially sanctioned Jeff> standard, PDF is an open trade mark -- Adobe does not own Jeff> it; they only own the mark for Acrobat. And Adobe changed Jeff> the Acrobat PDF format in the 1.2 version to remove any Jeff> proprietary compression algorithms. And there already are free PDF viewers and writers - so PDF has pretty good chance to conquer the Net. Regards, [To reply, remove "NOSPAM!" from the Uri "Reply-To:" field] -=-=-==-=-=- uri@ibm.net From owner-ietf-smime Wed Apr 16 03:41:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id DAA25627 for ietf-smime-bks; Wed, 16 Apr 1997 03:41:47 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id DAA25621 for ; Wed, 16 Apr 1997 03:41:44 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4A18.2DCF1D70@cane.deming.com>; Wed, 16 Apr 1997 03:42:16 -0700 Message-ID: From: Blake Ramsdell To: "'Geoff Klein'" , "'spock@RSA.COM'" , "'ietf-smime@imc.org'" , "'gaond@ncr.disa.mil'" Subject: RE: RE: Re[2]: 2nd S/MIME BOF meeting minutes Date: Wed, 16 Apr 1997 03:42:15 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk I think the problem here is if you put information about your mail capabilities in your certificate, then when your mail capabilities change, your certificate changes. Blake >-----Original Message----- >From: Geoff Klein [SMTP:geoff@commtouch.co.il] >Sent: Tuesday, April 15, 1997 3:45 PM >To: spock@RSA.COM; ietf-smime@imc.org; gaond@ncr.disa.mil >Subject: Re: RE: Re[2]: 2nd S/MIME BOF meeting minutes > >-----BEGIN PGP SIGNED MESSAGE----- > >Mime-Version: 1.0 >Content-Type: text/plain >Content-Transfer-Encoding: 7bit > >To: spock@RSA.COM, ietf-smime@imc.org, gaond@ncr.disa.mil >Date: Tue Apr 15 22:44:56 1997 > > >> In the world of peer-to-peer store-and-forward communications (e.g. >> email) there really is no negotiation possible at "start of >> communications". This is especially evident in the case of a multicast >> message, i.e. sending a message to a bunch of recipients. >> >> In such an environment, negotiation can be done either out of band >> beforehand (e.g. by looking up some entries in a directory) or via >> exchange of email by the end users who are not always savvy enough to >> effectively negotiate encryption algorithms and key sizes. It was our >> intent when creating S/MIME to provide some base level of >> interoperability possible among all S/MIME-enabled user agents (i.e. >> the "MUSTS") and an easy path to negotiating the use of the strongest >> possible encryption where both ends are capable (i.e. the "SHOULDS"). >> >> -steve > >Since certificates are in any case a prerequisit, supported/prefered >algorithms could be published as extended properties of an X509. > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.3i >Charset: noconv > >iQCVAwUBM1PozULv5OMYFK1FAQH6nQP+OQf1E2yJ0JgfRGkLBvbh4zAzTgd23le6 >FMj4HHQPNV8zHbHFTpby8QVzrb/i4Ufx0IVQpQyKRfeaXrzcF4D3lKuQ/sqfWYUZ >miYKo/M64iO8Y8Dgcc5JQmOPiV1U+GlYje39S4iOjJ4yjDr+WODS1kuL6h4FPl2y >iM80oZ0XvHE= >=VD0l >-----END PGP SIGNATURE----- > From owner-ietf-smime Wed Apr 16 05:28:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id FAA26374 for ietf-smime-bks; Wed, 16 Apr 1997 05:28:06 -0700 (PDT) Received: from hail.ncr.disa.mil (hail.ncr.disa.mil [164.117.176.115]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id FAA26366 for ; Wed, 16 Apr 1997 05:28:02 -0700 (PDT) Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id IAA03094; Wed, 16 Apr 1997 08:25:51 -0400 (EDT) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA861204448; Wed, 16 Apr 97 08:23:19 EST Date: Wed, 16 Apr 97 08:23:19 EST From: "David Gaon" Message-Id: <9703168612.AA861204448@ncr.disa.mil> To: geoff@commtouch.co.il, spock@RSA.COM, ietf-smime@imc.org, Blake Ramsdell Subject: Re[5]: 2nd S/MIME BOF meeting minutes Sender: owner-ietf-smime@imc.org Precedence: bulk Why do we need to put all the mail capabilities in the certificate ? Why not separate the fact that I have RSA and put that somewhere in the message header for the recipient (and everybody, I do not care) to see ??? David Gaon ______________________________ Reply Separator _________________________________ Subject: RE: RE: Re[2]: 2nd S/MIME BOF meeting minutes Author: Blake Ramsdell at smtp Date: 4/16/97 6:42 AM I think the problem here is if you put information about your mail capabilities in your certificate, then when your mail capabilities change, your certificate changes. Blake >-----Original Message----- >From: Geoff Klein [SMTP:geoff@commtouch.co.il] >Sent: Tuesday, April 15, 1997 3:45 PM >To: spock@RSA.COM; ietf-smime@imc.org; gaond@ncr.disa.mil >Subject: Re: RE: Re[2]: 2nd S/MIME BOF meeting minutes > >-----BEGIN PGP SIGNED MESSAGE----- > >Mime-Version: 1.0 >Content-Type: text/plain >Content-Transfer-Encoding: 7bit > >To: spock@RSA.COM, ietf-smime@imc.org, gaond@ncr.disa.mil >Date: Tue Apr 15 22:44:56 1997 > > >> In the world of peer-to-peer store-and-forward communications (e.g. >> email) there really is no negotiation possible at "start of >> communications". This is especially evident in the case of a multicast >> message, i.e. sending a message to a bunch of recipients. >> >> In such an environment, negotiation can be done either out of band >> beforehand (e.g. by looking up some entries in a directory) or via >> exchange of email by the end users who are not always savvy enough to >> effectively negotiate encryption algorithms and key sizes. It was our >> intent when creating S/MIME to provide some base level of >> interoperability possible among all S/MIME-enabled user agents (i.e. >> the "MUSTS") and an easy path to negotiating the use of the strongest >> possible encryption where both ends are capable (i.e. the "SHOULDS"). >> >> -steve > >Since certificates are in any case a prerequisit, supported/prefered >algorithms could be published as extended properties of an X509. > >-----BEGIN PGP SIGNATURE----- >Version: 2.6.3i >Charset: noconv > >iQCVAwUBM1PozULv5OMYFK1FAQH6nQP+OQf1E2yJ0JgfRGkLBvbh4zAzTgd23le6 >FMj4HHQPNV8zHbHFTpby8QVzrb/i4Ufx0IVQpQyKRfeaXrzcF4D3lKuQ/sqfWYUZ >miYKo/M64iO8Y8Dgcc5JQmOPiV1U+GlYje39S4iOjJ4yjDr+WODS1kuL6h4FPl2y >iM80oZ0XvHE= >=VD0l >-----END PGP SIGNATURE----- > From owner-ietf-smime Wed Apr 16 08:28:15 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA28673 for ietf-smime-bks; Wed, 16 Apr 1997 08:28:15 -0700 (PDT) Received: from dtol.com (root@DTOL.DTOL.COM [206.51.1.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA28669 for ; Wed, 16 Apr 1997 08:28:07 -0700 (PDT) Received: from bwdldb.ott.bnr.ca (dialup7 [206.51.1.107]) by dtol.com (8.6.12/8.6.9) with SMTP id KAA03698 for ; Wed, 16 Apr 1997 10:29:54 GMT Received: by bwdldb.ott.bnr.ca with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC4A57.52F7E840@bwdldb.ott.bnr.ca>; Wed, 16 Apr 1997 11:14:17 -0400 Message-ID: From: Peter Whittaker To: "'SMIME Dev List'" , "'SMIME IETF'" Subject: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing). Date: Wed, 16 Apr 1997 11:10:58 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ietf-smime@imc.org Precedence: bulk It has been suggested that the IETF consider specifying an alternative "MUST" symmetric encryption algorithm in its version of S/MIME. One of the alternatives is CAST. Entrust Technologies announced in January that it was making CAST available. From the press release: Entrust® Technologies announced today that it is making a version of its CAST encryption algorithm available for free commercial and non-commercial use. ... CAST is a design procedure for symmetric encryption algorithms. Following the design procedure and choosing appropriate values for various parameters creates an algorithm which is tailored to suit particular needs. As a result, CAST defines a family of encryption algorithms, each of which is conceptually simple, and easily implemented, flexible and very efficient in terms of encryption/decryption speed. CAST can be specified as the default in products that require non-proprietary algorithms. The full text of the press release is available at http://www.entrust.com/01_24_97.htm. The paper documenting the CAST design process can be found in our white papers library at http://www.entrust.com/library.htm. Scroll down about halfway to find the CAST papers. There are two, be sure to get them both. Peter Gutmann of New Zealand posted C code for CAST-128, derived from the description on the web page, to sci.scrypt a few weeks ago, so it is globally available now. Test vectors in the spec allow verification that the implementation is correct. My apologies for not having a reference to his article available. I've included the abstracts of the design papers: "Constructing Symmetric Cyphers Using the CAST Design Procedure" Abstract. This paper describes the CAST design procedure for constructing a family of DES-like Substitution-Permutation Network (SPN) ciphers. The version of the CAST algorithm discussed in this paper is now available royalty-free for both commercial and non-commercial use - see the related press release for details. "CAST Design Procedure Addendum" Abstract. This addendum to the CAST paper (above) specifies how to use CAST with a variable key size (40 to 128 bits), provides test vectors for 40-, 80-, and 128-bit keys (so that implementations can be verified for correctness), and includes some AlgorithmIdentifiers (i.e., OBJECT IDENTIFIERs with associated Parameters) which have been defined for CAST. Both papers are available from the Web page in PDF and in MS RTF. The first paper is also scheduled to appear in the journal "Designs, Codes, and Cryptography". Some of the advantages of CAST are: Free for commercial and non-commercial use. Variable key sizes: CAST has been implemented with 40, 64, 80, and 128 bit keys. Guaranteed resistance to differential and linear cryptanalysis attacks. Immunity to weak keys and complementary keys. Additional information about CAST is available from Queen's University: http://adonis.ee.queensu.ca:8000/cast/cast.html pww Peter Whittaker Entrust Key Validation Sequence: 7ORS-NGND-P6ZX Senior Designer, PKI mailto:pww@entrust.com Phone: +1 613 765 2064 Entrust Technologies http://www.entrust.com Fax: +1 613 765 3520 From owner-ietf-smime Wed Apr 16 09:24:58 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA29567 for ietf-smime-bks; Wed, 16 Apr 1997 09:24:58 -0700 (PDT) Received: from ayax.commtouch.co.il (ayax.commtouch.co.il [194.90.151.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA29563 for ; Wed, 16 Apr 1997 09:24:55 -0700 (PDT) Received: from bigg ([199.203.201.6]) by ayax.commtouch.co.il (Netscape Mail Server v2.02) with SMTP id AAA68; Wed, 16 Apr 1997 19:25:06 +0300 From: Geoff Klein Message-Id: <19970416192417geoff@bigg> Date: Wed Apr 16 19:24:17 1997 To: BlakeR@deming.com, geoff@commtouch.co.il, spock@RSA.COM, ietf-smime@imc.org, gaond@ncr.disa.mil X-Priority: Normal Subject: Re[2]: 2nd S/MIME BOF meeting minutes X-Mailer: Pronto Secure [Ver 1.13] X-ProntoSecureInfo: T=signed, P=x-pgp Sender: owner-ietf-smime@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: BlakeR@deming.com, geoff@commtouch.co.il, spock@RSA.COM, ietf-smime@imc.org, gaond@ncr.disa.mil Date: Wed Apr 16 19:24:09 1997 Blake, > I think the problem here is if you put information about your mail > capabilities in your certificate, then when your mail capabilities > change, your certificate changes. Sure, but these don't change that often. IMHO it's a small price to pay for guaranteed international inter operability that would result from a standard method for publishing crypto capabilities. Geoff. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBM1ULP0Lv5OMYFK1FAQFo5gP+Js8PSSaPVk3YBAn/Eat6cSOfwMOTlCO2 wKrtJEUlTdmIvknP4Cs8pUEfU6jIzZT+adZ/6+WIosO/e0Pcyzh5ZxeJzTRcUIwz PyImmHbC9OMOtykNt4QSzhjcNK7oLXA04PnlFbBH6BRxTDtJjNEnm1mppWdkC2gk Nh4th+4Y78s= =Ylud -----END PGP SIGNATURE----- From owner-ietf-smime Wed Apr 16 10:40:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA00759 for ietf-smime-bks; Wed, 16 Apr 1997 10:40:20 -0700 (PDT) Received: from worldtlk.worldtalk.com (worldtlk.worldtalk.com [204.177.91.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA00746 for ; Wed, 16 Apr 1997 10:40:17 -0700 (PDT) Received: from uluru.worldtalk.com by worldtlk.worldtalk.com with ESMTP (1.37.109.16/16.2-WT4.0) id AA022152379; Wed, 16 Apr 1997 10:39:40 -0700 Message-Id: <199704161739.AA022152379@worldtlk.worldtalk.com> To: Geoff Klein Cc: BlakeR@deming.com, spock@RSA.COM, ietf-smime@imc.org, gaond@ncr.disa.mil Subject: Re: Re[2]: 2nd S/MIME BOF meeting minutes References: <19970416192417geoff@bigg> In-Reply-To: Geoff Klein's message of Wed Apr 16 19:24:17 1997 <19970416192417geoff@bigg> X-Mailer: MH [Version 6.8.4]; mh-e [Version 5.0.2] Date: Wed, 16 Apr 1997 10:39:39 -0700 From: Bill Wohler Sender: owner-ietf-smime@imc.org Precedence: bulk Geoff Klein writes: > BlakeR@deming.com writes: > > I think the problem here is if you put information about your mail > > capabilities in your certificate, then when your mail capabilities > > change, your certificate changes. > > Sure, but these don't change that often. More often than certificates would. I see people using more than one mail system at the same time as well. Mail capability information is better left in your X.500 entry (someday!) Bill Wohler Say it with MIME. Maintainer of comp.mail.mh and news.software.nn FAQs. If you're passed on the right, you're in the wrong lane. From owner-ietf-smime Wed Apr 16 13:50:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA03397 for ietf-smime-bks; Wed, 16 Apr 1997 13:50:37 -0700 (PDT) Received: from ayax.commtouch.co.il (smtp.commtouch.co.il [194.90.151.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA03388 for ; Wed, 16 Apr 1997 13:50:14 -0700 (PDT) Received: from bigg ([199.203.201.85]) by ayax.commtouch.co.il (Netscape Mail Server v2.02) with SMTP id AAA209; Wed, 16 Apr 1997 23:50:22 +0300 From: Geoff Klein Message-Id: <19970416234934geoff@bigg> Date: Wed Apr 16 23:49:34 1997 To: wohler@uluru.worldtalk.com X-Priority: Normal Subject: Re: Re[2]: 2nd S/MIME BOF meeting minutes Cc: BlakeR@deming.com, spock@RSA.COM, ietf-smime@imc.org, gaond@ncr.disa.mil X-Mailer: Pronto Secure [Ver 1.13] X-ProntoSecureInfo: T=signed, P=x-pgp Sender: owner-ietf-smime@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: wohler@uluru.worldtalk.com, BlakeR@deming.com, spock@RSA.COM, ietf-smime@imc.org, gaond@ncr.disa.mil Date: Wed Apr 16 23:49:26 1997 Bill Wohler, > More often than certificates would. I see people using more than > one mail system at the same time as well. Presumably with separate email addresses, identities/credentials and certificates ? > Mail capability information is better left in your X.500 entry > (someday!) Until then we bable :) Geoff. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBM1VJbELv5OMYFK1FAQEV/wP/RAASFwkvarQLWhFG5U7u09KcVDmHS+UP kNLEFCV8nMESm3HmzD5cU5odrtEgZcjKJslPLZtequXNMTd88FrLPsKsPQcfQzVm t0sXzaedzyomq9/BpIFvWGtU8zSUrB3o+Lm61IUZpdjHjKTkc/O9agzCzIcShi4l G6rvc68SyBg= =25QH -----END PGP SIGNATURE----- From owner-ietf-smime Wed Apr 16 14:47:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA04269 for ietf-smime-bks; Wed, 16 Apr 1997 14:47:03 -0700 (PDT) Received: from worldtlk.worldtalk.com (worldtlk.worldtalk.com [204.177.91.2]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA04260 for ; Wed, 16 Apr 1997 14:46:58 -0700 (PDT) Received: from uluru.worldtalk.com by worldtlk.worldtalk.com with ESMTP (1.37.109.16/16.2-WT4.0) id AA049777172; Wed, 16 Apr 1997 14:46:12 -0700 Message-Id: <199704162146.AA049777172@worldtlk.worldtalk.com> To: Geoff Klein Cc: BlakeR@deming.com, spock@RSA.COM, ietf-smime@imc.org, gaond@ncr.disa.mil Subject: Re: Re[2]: 2nd S/MIME BOF meeting minutes References: <19970416234934geoff@bigg> In-Reply-To: Geoff Klein's message of Wed Apr 16 23:49:34 1997 <19970416234934geoff@bigg> X-Mailer: MH [Version 6.8.4]; mh-e [Version 5.0.2] Date: Wed, 16 Apr 1997 14:46:12 -0700 From: Bill Wohler Sender: owner-ietf-smime@imc.org Precedence: bulk Geoff Klein writes: > > More often than certificates would. I see people using more than > > one mail system at the same time as well. > > Presumably with separate email addresses, identities/credentials and > certificates ? No, why? In a given day, I'll use MH (mostly), mailx, exmh, pine, ZMail, Eudora, Netscape, etc. and even cat to read my mail depending the need and mood. Why would I need to have a dozen addresses and certificates? Bill Wohler Say it with MIME. Maintainer of comp.mail.mh and news.software.nn FAQs. If you're passed on the right, you're in the wrong lane. From owner-ietf-smime Wed Apr 16 17:04:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA05812 for ietf-smime-bks; Wed, 16 Apr 1997 17:04:24 -0700 (PDT) Received: from dtol.com (root@DTOL.DTOL.COM [206.51.1.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA05808 for ; Wed, 16 Apr 1997 17:04:16 -0700 (PDT) Received: from bwdldb.ott.bnr.ca (dialup2 [206.51.1.102]) by dtol.com (8.6.12/8.6.9) with SMTP id TAA06291 for ; Wed, 16 Apr 1997 19:06:03 GMT Received: by bwdldb.ott.bnr.ca with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC4AA0.896B61B0@bwdldb.ott.bnr.ca>; Wed, 16 Apr 1997 19:58:22 -0400 Message-ID: From: Peter Whittaker To: "'SMIME Dev List'" , "'SMIME IETF'" Subject: Followups in the IETF list (RE: Alternative symmetric algorithm freely available for IETF S/MIME). Date: Wed, 16 Apr 1997 19:56:32 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ietf-smime@imc.org Precedence: bulk Given that the subject at hand is what the IETF might do with the specification it may publish based on S/MIME, it is appropriate to carry all followup discussions to the IETF mailing list. I should have noted this in my original message. My excuse for posting to both lists is that I felt this might have been of broader interest. Nevertheless, followups on what the IETF should do should be directed to the IETF list only. To subscribe to the IETF S/MIME list, send a message to ietf-smime-request@imc.org with the word "subscribe" in the body of the message. pww From owner-ietf-smime Wed Apr 16 18:24:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA06574 for ietf-smime-bks; Wed, 16 Apr 1997 18:24:43 -0700 (PDT) Received: from dot.netrex.net (dot.netrex.net [206.253.225.51]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA06570 for ; Wed, 16 Apr 1997 18:24:39 -0700 (PDT) Received: from rgm3 (rgm3.htt-consult.com [206.62.80.34]) by dot.netrex.net (8.8.5/8.7.3) with SMTP id VAA13798; Wed, 16 Apr 1997 21:25:01 -0400 (EDT) Message-Id: <3.0.1.32.19970416212038.00acf240@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 16 Apr 1997 21:20:38 -0400 To: Peter Whittaker , "'SMIME Dev List'" , "'SMIME IETF'" From: Robert Moskowitz Subject: Re: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing). In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk At 11:10 AM 4/16/97 -0400, Peter Whittaker wrote: >It has been suggested that the IETF consider specifying an alternative >"MUST" symmetric encryption algorithm in its version of S/MIME. One of >the alternatives is CAST. Entrust Technologies announced in January that >it was making CAST available. From the press release: > I was at US Customs today discussing some issues regarding secure communications between Customs and the 'Big 3'. It was clear that it would be hard to ge anything through over there that did not support a FIPS algorithm. As I recall, DES was SHOULD. From what I learned today, I'd say that DES is MUST. And when AES is done then, well I'm not so sure of that.... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ietf-smime Wed Apr 16 19:45:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA07446 for ietf-smime-bks; Wed, 16 Apr 1997 19:45:44 -0700 (PDT) Received: from melcoweb (melcoweb.melco.co.jp [192.218.140.36]) by mail.proper.com (8.8.5/8.7.3) with SMTP id TAA07442 for ; Wed, 16 Apr 1997 19:45:39 -0700 (PDT) Received: by melcoweb (5.65+1.6W/2.7W) id AA10946; Thu, 17 Apr 97 11:42:59 JST Received: from katase by inetgw.topo.melco.co.jp (1.38.193.5/6.4J.6-inetgw1.0) id AA12786; Thu, 17 Apr 1997 11:50:00 +0900 Received: from iss.iss.isl.melco.co.jp by katase.katase.isl.melco.co.jp (4.1/6.4J.6-katase-2/) id AA20570; Thu, 17 Apr 97 11:46:00 JST Received: from edberg by iss.iss.isl.melco.co.jp (1.38.193.4/6.4J.6-isl2-2/iss-master) id AA27846; Thu, 17 Apr 1997 11:45:59 +0900 Received: by edberg with Microsoft Mail id <01BC4B25.A9130380@edberg>; Thu, 17 Apr 1997 11:51:18 +0900 Message-Id: <01BC4B25.A9130380@edberg> From: Takeshi Yoneda To: "'SMIME IETF'" , "'SMIME Dev List'" Subject: Can DES be MUST algorithm in international use of S/MIME? Date: Thu, 17 Apr 1997 11:51:16 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk I think if there is no export limitation about DES, DES is the best candidate for MUST algorithm. But in actual, DES is not exportable outside US and Canada. On the other hand, DES can be implemented outside of US. It would be possible to exchange encrypted messages by DES between US and other countries by using S/MIME compatible softwares in which DES are implemented in each countries. What should I think about such situation? Takeshi Yoneda Mitsubishi Electoric Corp. Info. Tech. R&D Center Infomation Security Dept. TEL +81-467-41-2182 FAX +81-467-41-2138 Takeshi Yoneda From owner-ietf-smime Thu Apr 17 05:22:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id FAA14191 for ietf-smime-bks; Thu, 17 Apr 1997 05:22:14 -0700 (PDT) Received: from hail.ncr.disa.mil (hail.ncr.disa.mil [164.117.176.115]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id FAA14187 for ; Thu, 17 Apr 1997 05:22:11 -0700 (PDT) Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id IAA12561; Thu, 17 Apr 1997 08:19:40 -0400 (EDT) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA861290429; Thu, 17 Apr 97 08:19:30 EST Date: Thu, 17 Apr 97 08:19:30 EST From: "David Gaon" Message-Id: <9703178612.AA861290429@ncr.disa.mil> To: wohler@uluru.worldtalk.com, Geoff Klein Cc: BlakeR@deming.com, spock@RSA.COM, ietf-smime@imc.org Subject: Re[4]: 2nd S/MIME BOF meeting minutes Sender: owner-ietf-smime@imc.org Precedence: bulk > Mail capability information is better left in your X.500 entry > >(someday!) >Until then we bable :) No we don't bable - WE PLAN for that eventuality and design protocols and certificates that separate that information instead of embedding it. David Gaon ______________________________ Reply Separator _________________________________ Subject: Re: Re[2]: 2nd S/MIME BOF meeting minutes Author: Geoff Klein at smtp Date: 4/16/97 6:28 PM -----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: wohler@uluru.worldtalk.com, BlakeR@deming.com, spock@RSA.COM, ietf-smime@imc.org, gaond@ncr.disa.mil Date: Wed Apr 16 23:49:26 1997 Bill Wohler, > More often than certificates would. I see people using more than > one mail system at the same time as well. Presumably with separate email addresses, identities/credentials and certificates ? > Mail capability information is better left in your X.500 entry > (someday!) Until then we bable :) Geoff. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBM1VJbELv5OMYFK1FAQEV/wP/RAASFwkvarQLWhFG5U7u09KcVDmHS+UP kNLEFCV8nMESm3HmzD5cU5odrtEgZcjKJslPLZtequXNMTd88FrLPsKsPQcfQzVm t0sXzaedzyomq9/BpIFvWGtU8zSUrB3o+Lm61IUZpdjHjKTkc/O9agzCzIcShi4l G6rvc68SyBg= =25QH -----END PGP SIGNATURE----- From owner-ietf-smime Thu Apr 17 06:37:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA15036 for ietf-smime-bks; Thu, 17 Apr 1997 06:37:26 -0700 (PDT) Received: from enterprise.powerup.com.au (root@enterprise.powerup.com.au [203.2.122.69]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id GAA15020 for ; Thu, 17 Apr 1997 06:37:15 -0700 (PDT) From: lindsay@powerup.com.au Received: from powerup.com.au (ts1613.powerup.com.au [203.19.191.205]) by enterprise.powerup.com.au (8.8.5/8.6.10) with SMTP id NAA18096; Thu, 17 Apr 1997 13:21:10 GMT Message-Id: <199704171321.NAA18096@enterprise.powerup.com.au> CC: ietf-smime@imc.org Date: 17 Apr 1997 10:57:58 GMT Subject: Re: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing). X-Mailer: Black Paw Communications's MailCat Beta for Win32 Beta Vs 2.0.0.3 To: rgm3@chrysler.com Sender: owner-ietf-smime@imc.org Precedence: bulk >I was at US Customs today discussing some issues regarding secure >communications between Customs and the 'Big 3'. It was clear that it >would >be hard to ge anything through over there that did not support a FIPS >algorithm. Should the IETF be concerned with the us customs export restrictions ? I know I'm not. I don't think domestic US restrictions should be an issue in an international spec, and I'm sure the (large) international developer community feels the same. Perhaps the IETF should just set a algorithm and key size minimum required for implementing a "secure" transaction, and leave concerns with export restrictions upto those effected - i.e. people in the US, not everybody else in the world. -- Lindsay Mathieson Black Paw Communications Using MailCat Beta for Win32 Beta Vs 2.0.0.3, on April 17, 1997, in Win95 4.0 Checkout the latest (and greatest ) mail client, MailCat at: http://www.powerup.com.au/~lindsay From owner-ietf-smime Thu Apr 17 07:26:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA15725 for ietf-smime-bks; Thu, 17 Apr 1997 07:26:47 -0700 (PDT) Received: from dot.netrex.net (dot.netrex.net [206.253.225.51]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id HAA15721 for ; Thu, 17 Apr 1997 07:26:43 -0700 (PDT) Received: from rgm3 (nsn1-gw5-xl1.netrex.com [206.253.228.11]) by dot.netrex.net (8.8.5/8.7.3) with SMTP id KAA08285; Thu, 17 Apr 1997 10:26:11 -0400 (EDT) Message-Id: <3.0.1.32.19970417102042.00b91e80@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 17 Apr 1997 10:20:42 -0400 To: lindsay@powerup.com.au From: Robert Moskowitz Subject: Re: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing). Cc: ietf-smime@imc.org In-Reply-To: <199704171321.NAA18096@enterprise.powerup.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk At 10:57 AM 4/17/97 GMT, lindsay@powerup.com.au wrote: >>I was at US Customs today discussing some issues regarding secure >>communications between Customs and the 'Big 3'. It was clear that it >>would >>be hard to ge anything through over there that did not support a FIPS >>algorithm. > >Should the IETF be concerned with the us customs export restrictions ? I know >I'm not. I don't think domestic US restrictions should be an issue in an >international spec, and I'm sure the (large) international developer >community feels the same. THIS HAS NOTHING TO DO WITH EXPORT!!! Rather what you can use to 'talk' to the government. Forget about things like key recovery fights. That is peanuts and noise. This is basics and is actually easy to meet. >Perhaps the IETF should just set a algorithm and key size minimum required >for implementing a "secure" transaction, and leave concerns with export >restrictions upto those effected - i.e. people in the US, not everybody else >in the world. > > >-- >Lindsay Mathieson >Black Paw Communications > Using MailCat Beta for Win32 Beta Vs 2.0.0.3, on April 17, 1997, in Win95 >4.0 >Checkout the latest (and greatest ) mail client, MailCat at: > http://www.powerup.com.au/~lindsay > > > > Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ietf-smime Thu Apr 17 08:58:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA16779 for ietf-smime-bks; Thu, 17 Apr 1997 08:58:16 -0700 (PDT) Received: from RSA.COM (chirality.rsa.com [192.80.211.33]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA16775 for ; Thu, 17 Apr 1997 08:58:13 -0700 (PDT) Received: from eagle.rsa.com by RSA.COM with SMTP id AA11337; Thu, 17 Apr 97 07:55:59 PDT Received: from lobester.rsa.com by eagle.rsa.com via smtpd (for chirality.rsa.com [192.80.211.33]) with SMTP; 17 Apr 1997 16:00:41 UT Received: by LOBESTER.rsa.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4B0D.F89EB560@LOBESTER.rsa.com>; Thu, 17 Apr 1997 09:01:43 -0700 Message-Id: From: Steve Dusse To: "'SMIME IETF'" , "'rgm3@chrysler.com'" Subject: RE: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). Date: Thu, 17 Apr 1997 09:01:42 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk If DES is a MUST then US software companies will have a difficult time exporting S/MIME-compliant products. -steve >---------- >From: Robert Moskowitz[SMTP:rgm3@chrysler.com] >Sent: Wednesday, April 16, 1997 6:20 PM >To: Peter Whittaker; 'SMIME Dev List'; 'SMIME IETF' >Subject: Re: Alternative symmetric algorithm freely available for IETFS/MIME >(re: RC2 licensing). > >At 11:10 AM 4/16/97 -0400, Peter Whittaker wrote: >>It has been suggested that the IETF consider specifying an alternative >>"MUST" symmetric encryption algorithm in its version of S/MIME. One of >>the alternatives is CAST. Entrust Technologies announced in January that >>it was making CAST available. From the press release: >> >I was at US Customs today discussing some issues regarding secure >communications between Customs and the 'Big 3'. It was clear that it would >be hard to ge anything through over there that did not support a FIPS >algorithm. > >As I recall, DES was SHOULD. From what I learned today, I'd say that DES >is MUST. And when AES is done then, well I'm not so sure of that.... > > >Robert Moskowitz >Chrysler Corporation >(810) 758-8212 > > From owner-ietf-smime Thu Apr 17 09:14:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA17044 for ietf-smime-bks; Thu, 17 Apr 1997 09:14:40 -0700 (PDT) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA17039 for ; Thu, 17 Apr 1997 09:14:30 -0700 (PDT) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id JAA21303; Thu, 17 Apr 1997 09:14:31 -0700 (PDT) X-Sender: llundbla@nala.qualcomm.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Apr 1997 09:04:05 -0700 To: Peter Whittaker , "'SMIME IETF'" From: Laurence Lundblade Subject: Re: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing). Sender: owner-ietf-smime@imc.org Precedence: bulk Peter, what's the (US) export status of CAST? I understand one of the reasons RC2 is attractive is that it has been cleared with the US commerce department for easy export at 40 bits. RC2's ease of export was cited as one of the main reasons for it's use at the IETF BOF. LL At 11:10 AM -0400 4/16/97, Peter Whittaker wrote: >It has been suggested that the IETF consider specifying an alternative >"MUST" symmetric encryption algorithm in its version of S/MIME. One of >the alternatives is CAST. Entrust Technologies announced in January that >it was making CAST available. From the press release: > > > >Peter Whittaker Entrust Key Validation Sequence: 7ORS-NGND-P6ZX >Senior Designer, PKI mailto:pww@entrust.com Phone: +1 613 765 2064 >Entrust Technologies http://www.entrust.com Fax: +1 613 765 3520 From owner-ietf-smime Thu Apr 17 11:56:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA18781 for ietf-smime-bks; Thu, 17 Apr 1997 11:56:23 -0700 (PDT) Received: from guardian.guard.ncsc.mil (guardian.guard.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA18777 for ; Thu, 17 Apr 1997 11:56:20 -0700 (PDT) Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id OAA03806 for ; Thu, 17 Apr 1997 14:56:45 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma003804; Thu Apr 17 14:56:22 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id OAA27700 for ; Thu, 17 Apr 1997 14:53:27 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id OAA21296; Thu, 17 Apr 1997 14:55:53 -0400 Date: Thu, 17 Apr 1997 14:55:53 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199704171855.OAA21296@argon.ncsc.mil> To: ietf-smime@imc.org Subject: RE: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). X-Sun-Charset: US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk > >From: Robert Moskowitz[SMTP:rgm3@chrysler.com] > > > >As I recall, DES was SHOULD. From what I learned today, I'd say that DES > >is MUST. And when AES is done then, well I'm not so sure of that.... > > From: Steve Dusse > > If DES is a MUST then US software companies will have a difficult time > exporting S/MIME-compliant products. > > -steve Why? Presumably DES-40 should be no more difficult to export than RC2-40 (Lotus does it), and DES-56 should be much easier to export than RC2-128. From owner-ietf-smime Thu Apr 17 12:04:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA18925 for ietf-smime-bks; Thu, 17 Apr 1997 12:04:39 -0700 (PDT) Received: from hail.ncr.disa.mil (hail.ncr.disa.mil [164.117.176.115]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA18921 for ; Thu, 17 Apr 1997 12:04:34 -0700 (PDT) Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id PAA14770; Thu, 17 Apr 1997 15:02:04 -0400 (EDT) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA861314429; Thu, 17 Apr 97 14:46:36 EST Date: Thu, 17 Apr 97 14:46:36 EST From: "David Gaon" Message-Id: <9703178613.AA861314429@ncr.disa.mil> To: pww@entrust.com, ietf-smime@imc.org, Laurence Lundblade Subject: Re[2]: Alternative symmetric algorithm freely available for Sender: owner-ietf-smime@imc.org Precedence: bulk There seems to be some distorted logic in negotiations using 40 bit algorithms 1. We all know 40 bits is not secure enough and can be easily broken, so what is the point of negotiating to a higher level algorithm with security using 40 bits ??!! might just as well be in the open (not encrypted at all). 2. If indeed we need to ""securely negotiate"" for an strong algorithm, then we might as well use the negotiation algorithm itself for our transaction if we believe that algorithm is ""secure"" (meaning strong enough to resist breaking and that gives us confidence in the security) David Gaon ______________________________ Reply Separator _________________________________ Subject: Re: Alternative symmetric algorithm freely available for IET Author: Laurence Lundblade at smtp Date: 4/17/97 12:31 PM Peter, what's the (US) export status of CAST? I understand one of the reasons RC2 is attractive is that it has been cleared with the US commerce department for easy export at 40 bits. RC2's ease of export was cited as one of the main reasons for it's use at the IETF BOF. LL At 11:10 AM -0400 4/16/97, Peter Whittaker wrote: >It has been suggested that the IETF consider specifying an alternative >"MUST" symmetric encryption algorithm in its version of S/MIME. One of >the alternatives is CAST. Entrust Technologies announced in January that >it was making CAST available. From the press release: > > > >Peter Whittaker Entrust Key Validation Sequence: 7ORS-NGND-P6ZX >Senior Designer, PKI mailto:pww@entrust.com Phone: +1 613 765 2064 >Entrust Technologies http://www.entrust.com Fax: +1 613 765 3520 From owner-ietf-smime Thu Apr 17 12:16:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA19088 for ietf-smime-bks; Thu, 17 Apr 1997 12:16:01 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA19083 for ; Thu, 17 Apr 1997 12:15:58 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id MAA28367 for ; Thu, 17 Apr 1997 12:16:41 -0700 (PDT) Message-Id: <3.0.32.19970417122043.009c1de0@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Apr 1997 12:20:45 -0700 To: ietf-smime@imc.org From: Charles Breed Subject: US/MIME Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk If we're all hell-bent on an international interoperable "MUST" profile for S/MIME, Let's not lead the naive to think it's "Secure". We all know a brute-force attack against 40-bit cipher can yield clear text in a short amount of time, so I believe, we (the IETF community) has a moral obligation to inform the millions of "unsuspecting" users as to the vulnerability of the proposed specification. Proposal: --------- US/MIME, this spec has ONLY one profile, RSA, RC2-40, SHA-1 and it will be known as the un-secure or US export spec. (or maybe SS/MIME, semi-secure/MIME) S/MIME+ will have a strong "MUST" profile, RSA Public Key with a minimum 1792 bit to match a symmetric cipher (3DES, CAST) of 112 bits with SHA-1. This "MUST" profile allows international interoperability as well, it just limits US companies to export. S/MIME will continue to have other profiles using the defined OIDs. (Yup, it's US export controlled, but ya better take that up with the US Department of Commerce, Not the IETF) regards, Charles Breed From owner-ietf-smime Thu Apr 17 12:30:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA19245 for ietf-smime-bks; Thu, 17 Apr 1997 12:30:49 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA19241 for ; Thu, 17 Apr 1997 12:30:46 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id MAA28611; Thu, 17 Apr 1997 12:31:27 -0700 (PDT) Message-Id: <3.0.32.19970417123528.009c96c0@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Apr 1997 12:35:30 -0700 To: ietf-smime@imc.org From: Charles Breed Subject: S/MIME Charter suggestions... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk After reading our Chairman, Paul Hoffman's (of IMC) S/MIME definition, I propose a few, slight modifications... IETF S/MIME Charter ------------------- Electronic messaging is rapidly replacing traditional forms of communications for individuals and businesses. As digital communication techniques accelerate in popularity, so does the need for data privacy, message integrity, and non-repudiation of origin. The IETF S/MIME Working Group is chartered with defining a standard method to send and receive secure MIME messages that interoperate globally. The group will place particular emphasis on the need for strong cryptography based on open and publicly available algorithms. In fulfillment of this charter, the IETF S/MIME Working Group will define the use of file formats, communications protocols, cryptographic algorithms, digital certificates and other relevant operational concerns. ================ fyi, the currently posted 'charter' for your comparisons... Description of the Working Group: S/MIME is a method for encrypting and/or authenticating MIME data. S/MIME defines a format for the MIME data, the algorithms that must be used for interoperability, and the additional operational concerns such as certificates and transport over the Internet. ================ regards, Charles Breed From owner-ietf-smime Thu Apr 17 13:12:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA19929 for ietf-smime-bks; Thu, 17 Apr 1997 13:12:48 -0700 (PDT) Received: from dot.netrex.net (dot.netrex.net [206.253.225.51]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA19925 for ; Thu, 17 Apr 1997 13:12:45 -0700 (PDT) Received: from rgm3 (nsn1-gw5-xl1.netrex.com [206.253.228.11]) by dot.netrex.net (8.8.5/8.7.3) with SMTP id QAA10744; Thu, 17 Apr 1997 16:13:04 -0400 (EDT) Message-Id: <3.0.1.32.19970417160906.00c2c270@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 17 Apr 1997 16:09:06 -0400 To: Steve Dusse , "'SMIME IETF'" From: Robert Moskowitz Subject: RE: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk At 09:01 AM 4/17/97 -0700, Steve Dusse wrote: >If DES is a MUST then US software companies will have a difficult time >exporting S/MIME-compliant products. Well you can always just give those government workers what they ask for, 40 bit DES :) I never ment to imply that we can't play mind games too. Unless there is something about S/MIME that I missed, but a key escrow of the encrypting certificate would meet the gov's brain-dead key recovery requirement. An S/MIME vendor could present an implementation that shows key recovery working through a CA's key escrow and get out that way. Nah, that would be too easy... Afterall, there is no reason for me to use key escrow (actually not in this case), so it is not the S/MIME implementors fault that i do not provide the key recovery. WAIT A SECOND! Is there a red herring lurking here? How could a vendor get an export license when DES is not a MUST. That must mean that the current MUST crypto is weak enough that it passes the 40 bit export rule. Hmmm. > >-steve > >>---------- >>From: Robert Moskowitz[SMTP:rgm3@chrysler.com] >>Sent: Wednesday, April 16, 1997 6:20 PM >>To: Peter Whittaker; 'SMIME Dev List'; 'SMIME IETF' >>Subject: Re: Alternative symmetric algorithm freely available for IETFS/MIME >>(re: RC2 licensing). >> >>At 11:10 AM 4/16/97 -0400, Peter Whittaker wrote: >>>It has been suggested that the IETF consider specifying an alternative >>>"MUST" symmetric encryption algorithm in its version of S/MIME. One of >>>the alternatives is CAST. Entrust Technologies announced in January that >>>it was making CAST available. From the press release: >>> >>I was at US Customs today discussing some issues regarding secure >>communications between Customs and the 'Big 3'. It was clear that it would >>be hard to ge anything through over there that did not support a FIPS >>algorithm. >> >>As I recall, DES was SHOULD. From what I learned today, I'd say that DES >>is MUST. And when AES is done then, well I'm not so sure of that.... >> >> >>Robert Moskowitz >>Chrysler Corporation >>(810) 758-8212 >> >> > > Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ietf-smime Thu Apr 17 14:13:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA20545 for ietf-smime-bks; Thu, 17 Apr 1997 14:13:49 -0700 (PDT) Received: from omicron.pair.com (omicron.pair.com [207.86.128.27]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA20541 for ; Thu, 17 Apr 1997 14:13:45 -0700 (PDT) From: bpc@blackpaw.com Received: from blackpaw.com (ts0414.powerup.com.au [203.18.83.142]) by omicron.pair.com (8.8.5/8.6.12) with SMTP id RAA29639; Thu, 17 Apr 1997 17:14:03 -0400 (EDT) Date: Thu, 17 Apr 1997 17:14:03 -0400 (EDT) Message-Id: <199704172114.RAA29639@omicron.pair.com> X-Envelope-To: ietf-smime@imc.org CC: ietf-smime@imc.org Subject: Re: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing). X-Mailer: Black Paw Communications's MailCat Beta for Win32 Beta Vs 2.0.0.3 To: rgm3@chrysler.com Sender: owner-ietf-smime@imc.org Precedence: bulk >THIS HAS NOTHING TO DO WITH EXPORT!!! Rather what you can use to >'talk' to the government OK, sorry I misunderstood you there. But then - is what you can use to 'talk' to the US government (mainly a US domestic issue) of concern for the standard ? -- Lindsay Mathieson Black Paw Communications http://www.blackpaw.com/ From owner-ietf-smime Thu Apr 17 14:25:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA20676 for ietf-smime-bks; Thu, 17 Apr 1997 14:25:43 -0700 (PDT) Received: from dot.netrex.net (dot.netrex.net [206.253.225.51]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA20672 for ; Thu, 17 Apr 1997 14:25:40 -0700 (PDT) Received: from rgm3 (nsn1-gw5-xl1.netrex.com [206.253.228.11]) by dot.netrex.net (8.8.5/8.7.3) with SMTP id RAA11293; Thu, 17 Apr 1997 17:26:21 -0400 (EDT) Message-Id: <3.0.1.32.19970417172142.00b2de00@dilbert.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@dilbert.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 17 Apr 1997 17:21:42 -0400 To: bpc@blackpaw.com From: Robert Moskowitz Subject: Re: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing). Cc: ietf-smime@imc.org In-Reply-To: <199704172114.RAA29639@omicron.pair.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk At 05:14 PM 4/17/97 -0400, bpc@blackpaw.com wrote: >>THIS HAS NOTHING TO DO WITH EXPORT!!! Rather what you can use to >>'talk' to the government > >OK, sorry I misunderstood you there. > >But then - is what you can use to 'talk' to the US government (mainly a US >domestic issue) of concern for the standard ? > In part no. But in so many other IETF standards, DES is a must implement. This is the case with IPsec. It is chosen as a MUST implement, because it is available worldwide without licensing encumberences, I think. I also would suspect to see DES in other govs requirements, as many model theirs after FIPS. To make RCn a requirement and DES an option is a major shift in IETF work. RC2 and RC4 are trade secrets. RC5 is published, but licensed, I think. This is much of my concern... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ietf-smime Thu Apr 17 14:57:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA21108 for ietf-smime-bks; Thu, 17 Apr 1997 14:57:42 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA21104 for ; Thu, 17 Apr 1997 14:57:39 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id RAA08449; Thu, 17 Apr 1997 17:57:01 -0400 (EDT) Message-Id: <199704172157.RAA08449@ig.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Steve Dusse cc: ietf-smime@imc.org, moore@cs.utk.edu Subject: Re: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). In-reply-to: Your message of "Thu, 17 Apr 1997 09:01:42 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Apr 1997 17:57:01 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > If DES is a MUST then US software companies will have a difficult time > exporting S/MIME-compliant products. That's for US companies to discuss with Uncle Sam. It's not something that IETF should concern itself with. IETF should concern itself with the quality of the algorithm -- whether it's believed to be of sufficient strength -- and whether it is available under fair and nondiscriminatory terms. US export regs are irrelevant unless they somehow prevent a candidate algorithm from being made widely available under such terms. Keith From owner-ietf-smime Thu Apr 17 15:41:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA21591 for ietf-smime-bks; Thu, 17 Apr 1997 15:41:27 -0700 (PDT) Received: from RSA.COM (chirality.rsa.com [192.80.211.33]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA21587 for ; Thu, 17 Apr 1997 15:41:25 -0700 (PDT) Received: from eagle.rsa.com by RSA.COM with SMTP id AA14802; Thu, 17 Apr 97 14:39:19 PDT Received: by LOBESTER.rsa.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4B46.50B3B600@LOBESTER.rsa.com>; Thu, 17 Apr 1997 15:45:03 -0700 Message-Id: From: Steve Dusse To: "'Keith Moore'" Cc: "'ietf-smime@imc.org'" Subject: RE: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). Date: Thu, 17 Apr 1997 15:45:02 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk Keith makes this point rather succintly. If there is agreement, then I will stand by my earlier conviction; the goals of the IETF are out of step with US companies' business needs. As such, we should find a way to separate the non-business protocol portions of the S/MIME spec from the US business-needs-centric profiling information. Cheers, Steve >---------- >From: Keith Moore[SMTP:moore@cs.utk.edu] >Sent: Thursday, April 17, 1997 2:57 PM >To: Steve Dusse >Cc: ietf-smime@imc.org; moore@cs.utk.edu >Subject: Re: Alternative symmetric algorithm freely available for IETFS/MIME >(re: RC2 licensing). > >> If DES is a MUST then US software companies will have a difficult time >> exporting S/MIME-compliant products. > >That's for US companies to discuss with Uncle Sam. It's not something >that IETF should concern itself with. > >IETF should concern itself with the quality of the algorithm -- >whether it's believed to be of sufficient strength -- and whether it >is available under fair and nondiscriminatory terms. > >US export regs are irrelevant unless they somehow prevent a candidate >algorithm from being made widely available under such terms. > >Keith > > > From owner-ietf-smime Thu Apr 17 15:46:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA21642 for ietf-smime-bks; Thu, 17 Apr 1997 15:46:13 -0700 (PDT) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.2.122.69]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA21638 for ; Thu, 17 Apr 1997 15:46:07 -0700 (PDT) From: bpc@blackpaw.com Received: from powerup.com.au (ts0301.powerup.com.au [203.18.83.97]) by enterprise.powerup.com.au (8.8.5/8.6.10) with SMTP id WAA23043; Thu, 17 Apr 1997 22:43:16 GMT Date: Thu, 17 Apr 1997 22:43:16 GMT Message-Id: <199704172243.WAA23043@enterprise.powerup.com.au> CC: ietf-smime@imc.org Subject: Re: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). X-Mailer: Black Paw Communications's MailCat Beta for Win32 Beta Vs 2.0.0.3 To: Keith Moore Sender: owner-ietf-smime@imc.org Precedence: bulk >US export regs are irrelevant unless they somehow prevent a candidate >algorithm from being made widely available under such terms. Amen - the US domestic scene appears to have *far* to much influence on the current spec -- Lindsay Mathieson Black Paw Communications http://www.blackpaw.com/ From owner-ietf-smime Thu Apr 17 16:13:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA21912 for ietf-smime-bks; Thu, 17 Apr 1997 16:13:27 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA21907 for ; Thu, 17 Apr 1997 16:13:24 -0700 (PDT) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Apr 1997 16:18:10 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: RE: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). Sender: owner-ietf-smime@imc.org Precedence: bulk At 3:45 PM -0700 4/17/97, Steve Dusse wrote: >If there is agreement, then I >will stand by my earlier conviction; the goals of the IETF are out of >step with US companies' business needs. I disagree strongly with your wording. There is no "need" for expidited export of a product; there is a strong desire. To be more specific, there is a strong desire for a small number of companies (mail client manufacturers) for expeditied export. There is a strong need for strong cryptography in all US companies for their messaging. This is why RSA included tripleDES in the original S/MIME spec. Thus, the goals of the IETF are exactly step with US companies' business needs, with the exception of a few companies. >As such, we should find a way >to separate the non-business protocol portions of the S/MIME spec from >the US business-needs-centric profiling information. Again, I disagree with your wording. In my mind, a better way to say this is "we need a spec that meets US companies' business needs, and we need to also at least acknowledge the strong desires of US mail client vendors." Further, I'd like to point out to the group as a whole that just because other countries don't have export controls today, they might tomorrow. The lame ideas of the US government are often imported gleefully by other governments. Thus, the 40-bit crypto problem is temporarily US-only. It could go away in the US, it could appear in other major software-exporting countries, or both. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Thu Apr 17 16:16:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA21975 for ietf-smime-bks; Thu, 17 Apr 1997 16:16:35 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA21971 for ; Thu, 17 Apr 1997 16:16:33 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4B4A.CF48F760@cane.deming.com>; Thu, 17 Apr 1997 16:17:13 -0700 Message-ID: From: Blake Ramsdell To: "'ietf-smime@imc.org'" Subject: Other exportable 40-bit algorithms Date: Thu, 17 Apr 1997 16:17:12 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk Is there any alternative to RC2 40-bit that meets US export requirements for symmetric algorithms, and does not require you to: 1. Wait an eternity for export approval 2. Register every sale of a product to a non-US/Canada company/individual with the government 3. Require you to implement escrow features in your product RC2 40-bit enjoys both an expedited export approval (I seem to remember ours being a month) and does not have the burden of reporting individual unit sales with the government. Is this true of CAST 40-bit or DES-40? Blake From owner-ietf-smime Thu Apr 17 17:28:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA22825 for ietf-smime-bks; Thu, 17 Apr 1997 17:28:10 -0700 (PDT) Received: from out2.ibm.net (out2.ibm.net [165.87.201.252]) by mail.proper.com (8.8.5/8.7.3) with SMTP id RAA22819 for ; Thu, 17 Apr 1997 17:28:07 -0700 (PDT) Received: (from uucp@localhost) by out2.ibm.net (8.6.9/8.6.9) id AAA364261; Fri, 18 Apr 1997 00:28:32 GMT Received: from slip166-72-232-156.ny.us.ibm.net(166.72.232.156) by out2.ibm.net via smap (V1.3mjr) id smaWQADmb; Fri Apr 18 00:10:05 1997 Received: (from uri@localhost) by alisan.ibm.net (8.7.6/8.7.3) id UAA03027; Thu, 17 Apr 1997 20:10:23 -0400 Date: Thu, 17 Apr 1997 20:10:23 -0400 Message-Id: <199704180010.UAA03027@alisan.ibm.net> From: Uri Blumenthal To: Blake Ramsdell Cc: "'ietf-smime@imc.org'" Subject: Other exportable 40-bit algorithms In-Reply-To: References: Reply-To: NOSPAM!uri@ibm.net Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk >>>>> "Blake" == Blake Ramsdell writes: Blake> Is there any alternative to RC2 40-bit that meets US export Blake> requirements for symmetric algorithms, and does not require Blake> you to: Blake> 1. Wait an eternity for export approval 2. Register every Blake> sale of a product to a non-US/Canada company/individual Blake> with the government 3. Require you to implement escrow Blake> features in your product Yes, of course. But you realize, that it's 99.9% unlikely that you'll be allowed to export the source code, right? Blake> RC2 40-bit enjoys both an expedited export approval (I seem Blake> to remember ours being a month) and does not have the Blake> burden of reporting individual unit sales with the Blake> government. Is this true of CAST 40-bit or DES-40? No idea about CAST, probably it's too good for it. Yes for CDMF (IBM-patented, clever reducing the key strength to 40 bits, as opposite to simply accepting a 40-bit key only from a user). Yes for RC4 (legal status unknown to me. The last I heard, RSADSI believes it's their property and would like you to pay for the license). Yes for RC2 (same as RC4). There is no "DES-40" per se, unless you mean CDMF; to the best of my knowledge. I'm not aware of any other crypto-algorithm that has expedited export approval (which doesn't guarantee you'll be allowed to export - simply that "Yes" or "No" will be given within three weeks or so). Regards, Uri -=-=-==-=-=- uri@watson.ibm.com From owner-ietf-smime Thu Apr 17 18:50:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA23335 for ietf-smime-bks; Thu, 17 Apr 1997 18:50:25 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA23331 for ; Thu, 17 Apr 1997 18:50:22 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id SAA04940 for ; Thu, 17 Apr 1997 18:51:07 -0700 (PDT) Message-Id: <3.0.32.19970417185508.009ce840@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Apr 1997 18:55:11 -0700 To: ietf-smime@imc.org From: Charles Breed Subject: RE: Alternative symmetric algorithm freely available for IETF S/MIME (re: RC2 licensing). Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk There are two separate issues here: 1. Proprietary nature of the algorithm and 2. Key length of 40 bit One argument says, 'No RC2 at any length' key because it's owned by someone charging some type of royalty. Don't care if it's 128 bit RC2, it's still RC2. The other argument is, 'Don't want no weak crypto'. Don't care if you're talking CAST@40, DES@40, RC2@40 or ROT13. This is the 'US export' problem. The answer is simple, Let's have strong open algorithms ! ------------------- At 04:18 PM 4/17/97 -0700, you wrote: >At 3:45 PM -0700 4/17/97, Steve Dusse wrote: >>If there is agreement, then I >>will stand by my earlier conviction; the goals of the IETF are out of >>step with US companies' business needs. > >I disagree strongly with your wording. There is no "need" for expidited >export of a product; there is a strong desire. To be more specific, there >is a strong desire for a small number of companies (mail client >manufacturers) for expeditied export. > >There is a strong need for strong cryptography in all US companies for >their messaging. This is why RSA included tripleDES in the original S/MIME >spec. Thus, the goals of the IETF are exactly step with US companies' >business needs, with the exception of a few companies. > >>As such, we should find a way >>to separate the non-business protocol portions of the S/MIME spec from >>the US business-needs-centric profiling information. > >Again, I disagree with your wording. In my mind, a better way to say this >is "we need a spec that meets US companies' business needs, and we need to >also at least acknowledge the strong desires of US mail client vendors." > >Further, I'd like to point out to the group as a whole that just because >other countries don't have export controls today, they might tomorrow. The >lame ideas of the US government are often imported gleefully by other >governments. Thus, the 40-bit crypto problem is temporarily US-only. It >could go away in the US, it could appear in other major software-exporting >countries, or both. > >--Paul E. Hoffman, Director >--Internet Mail Consortium > > > > From owner-ietf-smime Thu Apr 17 18:55:52 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA23372 for ietf-smime-bks; Thu, 17 Apr 1997 18:55:52 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id SAA23367; Thu, 17 Apr 1997 18:55:49 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4B61.0DF8A080@cane.deming.com>; Thu, 17 Apr 1997 18:56:27 -0700 Message-ID: From: Blake Ramsdell To: "'Paul E. Hoffman'" , "'ietf-smime@imc.org'" Subject: RE: Alternative symmetric algorithm freely available forIETFS/MIME (re: RC2 licensing). Date: Thu, 17 Apr 1997 18:56:26 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk I'm don't think that Steve is wrong in his wording that "the goals of the IETF are out of step with US companies' business needs". Consider the following: 1. US companies need to sell products outside the US and Canada 2. The current discussion about removing RC2 40-bit is about removing the necessary component from the specification that would allow this I don't know how more accurate his statement could be. And it's not just "expedited" export of a product that is afforded by having RC2 40-bit -- if you use anything else and you get approval, it is contingent on providing information about each of the customers you have sold the product to. This is, in short, enough paperwork to negate the effort, especially if you have any kind of distribution channel, bundling, or any other non-direct sales where end-user accountability is not possible. This policy may have changed, and if any evidence of this is presented through my other email thread we can discuss the possible replacement of RC2 40-bit. In that thread, I asked if there was any algorithm that met the US export requirements and was not an insurmountable administrative burden to sell as an S/MIME product. We'll see if anything comes up. In any case, this is the business need, and it appears that the IETF wants to head the spec in a different direction. That's why Steve (and I) believe that it is out of step. Blake >-----Original Message----- >From: Paul E. Hoffman [SMTP:phoffman@imc.org] >Sent: Thursday, April 17, 1997 4:18 PM >To: ietf-smime@imc.org >Subject: RE: Alternative symmetric algorithm freely available forIETFS/MIME >(re: RC2 licensing). > >At 3:45 PM -0700 4/17/97, Steve Dusse wrote: >>If there is agreement, then I >>will stand by my earlier conviction; the goals of the IETF are out of >>step with US companies' business needs. > >I disagree strongly with your wording. There is no "need" for expidited >export of a product; there is a strong desire. To be more specific, there >is a strong desire for a small number of companies (mail client >manufacturers) for expeditied export. > >There is a strong need for strong cryptography in all US companies for >their messaging. This is why RSA included tripleDES in the original S/MIME >spec. Thus, the goals of the IETF are exactly step with US companies' >business needs, with the exception of a few companies. > >>As such, we should find a way >>to separate the non-business protocol portions of the S/MIME spec from >>the US business-needs-centric profiling information. > >Again, I disagree with your wording. In my mind, a better way to say this >is "we need a spec that meets US companies' business needs, and we need to >also at least acknowledge the strong desires of US mail client vendors." > >Further, I'd like to point out to the group as a whole that just because >other countries don't have export controls today, they might tomorrow. The >lame ideas of the US government are often imported gleefully by other >governments. Thus, the 40-bit crypto problem is temporarily US-only. It >could go away in the US, it could appear in other major software-exporting >countries, or both. > >--Paul E. Hoffman, Director >--Internet Mail Consortium > > From owner-ietf-smime Thu Apr 17 19:16:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA23529 for ietf-smime-bks; Thu, 17 Apr 1997 19:16:25 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id TAA23525 for ; Thu, 17 Apr 1997 19:16:22 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4B63.EF247280@cane.deming.com>; Thu, 17 Apr 1997 19:17:04 -0700 Message-ID: From: Blake Ramsdell To: "'Charles Breed'" , "'ietf-smime@imc.org'" Subject: RE: S/MIME Charter suggestions... Date: Thu, 17 Apr 1997 19:17:03 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk OK, Charles, I'll bite. How are we going to have strong cryptography that interoperates globally? Blake >-----Original Message----- >From: Charles Breed [SMTP:cbreed@pgp.com] >Sent: Thursday, April 17, 1997 12:36 PM >To: ietf-smime@imc.org >Subject: S/MIME Charter suggestions... > >After reading our Chairman, Paul Hoffman's (of IMC) S/MIME definition, >I propose a few, slight modifications... > > >IETF S/MIME Charter >------------------- >Electronic messaging is rapidly replacing traditional forms >of communications for individuals and businesses. As digital >communication techniques accelerate in popularity, so does >the need for data privacy, message integrity, and >non-repudiation of origin. > >The IETF S/MIME Working Group is chartered with defining a >standard method to send and receive secure MIME messages >that interoperate globally. The group will place particular >emphasis on the need for strong cryptography based on open and >publicly available algorithms. In fulfillment of this charter, >the IETF S/MIME Working Group will define the use of file formats, >communications protocols, cryptographic algorithms, digital >certificates and other relevant operational concerns. > >================ >fyi, the currently posted 'charter' for your comparisons... > > Description of the Working Group: > > S/MIME is a method for encrypting and/or authenticating MIME data. > S/MIME defines a format for the MIME data, the algorithms that must be > used for interoperability, and the additional operational concerns > such as certificates and transport over the Internet. >================ > >regards, >Charles Breed > From owner-ietf-smime Thu Apr 17 19:11:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA23483 for ietf-smime-bks; Thu, 17 Apr 1997 19:11:13 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id TAA23479 for ; Thu, 17 Apr 1997 19:11:10 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4B63.34F94C50@cane.deming.com>; Thu, 17 Apr 1997 19:11:52 -0700 Message-ID: From: Blake Ramsdell To: "'Charles Breed'" , "'ietf-smime@imc.org'" Subject: RE: US/MIME Date: Thu, 17 Apr 1997 19:11:50 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk To further this, I propose the following: SSSL (Semi-Secure-Sockets-Layer) for implementations that can only implement 40-bit RC2 / RC4. This, of course, would be in TLSS (Transport-Level-Semi-Security) also. We can work on the acronyms. These are in use in all of the exportable web servers / browsers from Netscape and Microsoft. Just to be consistent. Blake >-----Original Message----- >From: Charles Breed [SMTP:cbreed@pgp.com] >Sent: Thursday, April 17, 1997 12:21 PM >To: ietf-smime@imc.org >Subject: US/MIME > > >If we're all hell-bent on an international interoperable >"MUST" profile for S/MIME, Let's not lead the naive to think >it's "Secure". We all know a brute-force attack against 40-bit >cipher can yield clear text in a short amount of time, so I >believe, we (the IETF community) has a moral obligation to inform >the millions of "unsuspecting" users as to the vulnerability of the >proposed specification. > >Proposal: >--------- > >US/MIME, this spec has ONLY one profile, RSA, RC2-40, SHA-1 and >it will be known as the un-secure or US export spec. (or maybe >SS/MIME, semi-secure/MIME) > >S/MIME+ will have a strong "MUST" profile, RSA Public Key with >a minimum 1792 bit to match a symmetric cipher (3DES, CAST) of >112 bits with SHA-1. This "MUST" profile allows international >interoperability as well, it just limits US companies to export. >S/MIME will continue to have other profiles using the defined OIDs. > >(Yup, it's US export controlled, but ya better take that up with >the US Department of Commerce, Not the IETF) > > >regards, >Charles Breed From owner-ietf-smime Thu Apr 17 19:11:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA23495 for ietf-smime-bks; Thu, 17 Apr 1997 19:11:55 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA23491 for ; Thu, 17 Apr 1997 19:11:52 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01IHTJJTQXV499EIHM@INNOSOFT.COM> for ietf-smime@imc.org; Thu, 17 Apr 1997 19:11:29 PDT Date: Thu, 17 Apr 1997 18:56:21 -0700 (PDT) From: Ned Freed Subject: RE: Alternative symmetric algorithm freely available for IETF S/MIME). In-reply-to: "Your message dated Wed, 16 Apr 1997 19:56:32 -0400" To: "'SMIME Dev List'" , "'SMIME IETF'" Message-id: <01IHTMW4KM3899EIHM@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk Folks, while it has been very interesting and I've learned some new stuff, I'm afraid the discussion of whether or not the licensing terms for RC2 and it's brethren are adequate is what is moot here. The simple fact of the matter is that as the owner of the intellectual property in question, RSA has five and only five options to chose from: (1) Drop any trade secret claims for the algorithms used in S/MIME. (2) Completely remove them from the S/MIME standard-to-be. It isn't a question of whether or not it can be required -- in point of fact you cannot mention these algorithms at all. (3) Abandon the effort to get S/MIME blessed as an Internet standard. (4) Get the IETF to treat this as an exception to the current rules concerning intellectual property in Internet standards (very unlikely). (5) Get the IETF to change the current rules concerning intellectual property in Internet standards (also very unlikely). To see why this is so, I cite section 10.2 of RFC2026, which is the document describing the requirements of the current Internet Standards Process: 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. Now, it is my understanding that in order to maintain something's trade secret status the owner of that trade secret must keep it confidential and cannot under any circumstances whatsoever agree to its publication. (I'm confident that I can find citations to back up this point if necessary -- unfortunately someone has "borrowed" my patent and trade secret textbook so I cannot do so right now.) If so, this is in direct contradction to the IETF's requirement that material with confidentially emcumberances cannot be used in any part of the Internet Standards Process. In addition, please note that this requirement happens to be one which is unusually clear, unambiguous, and ineluctable -- there are no weasel-words about "only if there's no unencumbered alternative" or "must have reasonable licensing terms", etc. And for my part I think the absence of such words in this case is entirely defensible: Please recall that the standards process contains mandatory review steps, and I find it unacceptable for the review process to involve a need to sign a nondisclosure agreement and quite possibly pay $$$. As such, I will actively oppose any attempts to either change the rules or make an exception in this case. FWIW, I ran this message by the apps area directorate list prior to posting it here. I only received two comments, one from each of the apps area directors. Specifically, Keith Moore replied and said he agrees with my analysis. Harald Alvestrand also replied and says that while he doesn't see a problem with having a simple reference pointing to RC2 and its OID in the document, what is there now is clearly unacceptable. So that's the word from two of the ADs who will have to approve this document before it can enter the IETF standards track. Ned From owner-ietf-smime Thu Apr 17 19:29:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA23612 for ietf-smime-bks; Thu, 17 Apr 1997 19:29:46 -0700 (PDT) Received: from tweety.bhp.com.au (tweety.bhp.com.au [192.83.224.130]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA23608 for ; Thu, 17 Apr 1997 19:29:42 -0700 (PDT) Received: from gossamer.itmel.bhp.com.au (gossamer.itmel.bhp.com.au [134.18.115.254]) by tweety.bhp.com.au (8.8.4/8.8.4) with ESMTP id MAA10238 for ; Fri, 18 Apr 1997 12:29:55 +1000 (EST) Received: from cerberus.bhpese.oz.au (cerberus.itntl.bhp.com.au [134.18.16.17]) by gossamer.itmel.bhp.com.au (8.8.4/8.8.4) with SMTP id MAA26356 for ; Fri, 18 Apr 1997 12:29:23 +1000 (EST) Received: from nc.itntl.bhp.com.au (nc) by cerberus.bhpese.oz.au with SMTP id AA21915; Fri, 18 Apr 1997 12:29:19 +1000; sendmail 5.67a/Sm3.20RMPSU (from Sm@nc.bhpese.oz.au for ietf-smime@imc.org) Received: from nc.itntl.bhp.com.au by nc.itntl.bhp.com.au with ESMTP id MAA19101; Fri, 18 Apr 1997 12:29:18 +1000; sendmail 8.6.10/Sm2.1sun (from Sm@nc.itntl.bhp.com.au for ) Message-Id: <199704180229.MAA19101@nc.itntl.bhp.com.au> To: ietf-smime@imc.org Subject: Re: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" Sender: owner-ietf-smime@imc.org Precedence: bulk >someone wrote: >>If there is agreement, then I >>will stand by my earlier conviction; the goals of the IETF are out of >>step with US companies' business needs. Maybe: "The US Government is out of step with US companies' business needs." Sm From owner-ietf-smime Thu Apr 17 19:43:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA23695 for ietf-smime-bks; Thu, 17 Apr 1997 19:43:39 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA23685 for ; Thu, 17 Apr 1997 19:43:33 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Apr 1997 19:48:23 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: The RC2 debate Sender: owner-ietf-smime@imc.org Precedence: bulk I'd like to second the motion to split the RC2/40 discussion into two parts. Please note the subject of this part, and reply with this subject if you want to talk about whether or not the S/MIME spec should have a MUST or a SHOULD that includes RC2 encryption. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Thu Apr 17 19:43:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA23692 for ietf-smime-bks; Thu, 17 Apr 1997 19:43:38 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA23679 for ; Thu, 17 Apr 1997 19:43:32 -0700 (PDT) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Apr 1997 19:46:07 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: RE: Alternative symmetric algorithm freely available forIETFS/MIME (re: RC2 licensing). Sender: owner-ietf-smime@imc.org Precedence: bulk At 6:56 PM -0700 4/17/97, Blake Ramsdell wrote: >Consider >the following: > >1. US companies need to sell products outside the US and Canada Let's be a bit more specific here. *Some* US companies need to sell products outside the US and Canada (and Mexico, by the way...). Not all of them. The ones you are talking about are companies that create mail client software. They are a teeny minority of US companies. >2. The current discussion about removing RC2 40-bit is about removing >the necessary component from the specification that would allow this Not necessarily true. Some people would like to remove RC2/40 altogether, others would prefer to move it to SHOULD or possibly just a list known, widely-deployed algorithms. I hear no consensus yet, which isn't surprising given the topic. >In any case, this is the business need, and it appears that the IETF >wants to head the spec in a different direction. Wrong and wrong. - It is a business need *for a teeny number of companies*. The vast majority of US/Canada/Mexico companies have a business need for reliable, interoperable, secure email. If the IETF can get that with RC2/40, great. If not, the IETF must listen to the needs of all businesses and still come up with a spec for reliable, interoperable, secure email. - "The IETF" doesn't speak with one voice, and thinking that a handful of comments on one mailing list over two days reflects the voice of the IETF is just plain silly. The debate is only begun, and not very well I might add. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Thu Apr 17 19:43:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA23694 for ietf-smime-bks; Thu, 17 Apr 1997 19:43:38 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA23681 for ; Thu, 17 Apr 1997 19:43:32 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Apr 1997 19:47:55 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: The 40-bit debate Sender: owner-ietf-smime@imc.org Precedence: bulk I'd like to second the motion to split the RC2/40 discussion into two parts. Please note the subject of this part, and reply with this subject if you want to talk about whether or not the S/MIME spec should have a MUST or a SHOULD that includes 40-bit encryption. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Thu Apr 17 19:49:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA23825 for ietf-smime-bks; Thu, 17 Apr 1997 19:49:48 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA23821 for ; Thu, 17 Apr 1997 19:49:46 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id TAA05442 for ; Thu, 17 Apr 1997 19:50:32 -0700 (PDT) Message-Id: <3.0.32.19970417195435.0092cb60@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Apr 1997 19:54:36 -0700 To: ietf-smime@imc.org From: Charles Breed Subject: RE: US/MIME Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk All I'm suggesting is that we clearly differentiate between what is strong and what is not, or S/MIME might make CNN Headline news, (not good for our industry) Joe says, "hey, ya use'g that S/MIME stuff" Mike says, "you bet, send me your companies records" Joe says, "sure thing, they're on their way" :-) At 07:11 PM 4/17/97 -0700, you wrote: >To further this, I propose the following: > >SSSL (Semi-Secure-Sockets-Layer) for implementations that can only >implement 40-bit RC2 / RC4. This, of course, would be in TLSS >(Transport-Level-Semi-Security) also. We can work on the acronyms. >These are in use in all of the exportable web servers / browsers from >Netscape and Microsoft. > >Just to be consistent. > >Blake > >>-----Original Message----- >>From: Charles Breed [SMTP:cbreed@pgp.com] >>Sent: Thursday, April 17, 1997 12:21 PM >>To: ietf-smime@imc.org >>Subject: US/MIME >> >> >>If we're all hell-bent on an international interoperable >>"MUST" profile for S/MIME, Let's not lead the naive to think >>it's "Secure". We all know a brute-force attack against 40-bit >>cipher can yield clear text in a short amount of time, so I >>believe, we (the IETF community) has a moral obligation to inform >>the millions of "unsuspecting" users as to the vulnerability of the >>proposed specification. >> >>Proposal: >>--------- >> >>US/MIME, this spec has ONLY one profile, RSA, RC2-40, SHA-1 and >>it will be known as the un-secure or US export spec. (or maybe >>SS/MIME, semi-secure/MIME) >> >>S/MIME+ will have a strong "MUST" profile, RSA Public Key with >>a minimum 1792 bit to match a symmetric cipher (3DES, CAST) of >>112 bits with SHA-1. This "MUST" profile allows international >>interoperability as well, it just limits US companies to export. >>S/MIME will continue to have other profiles using the defined OIDs. >> >>(Yup, it's US export controlled, but ya better take that up with >>the US Department of Commerce, Not the IETF) >> >> >>regards, >>Charles Breed > > From owner-ietf-smime Thu Apr 17 19:52:51 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA23871 for ietf-smime-bks; Thu, 17 Apr 1997 19:52:51 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA23867 for ; Thu, 17 Apr 1997 19:52:48 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id TAA05479 for ; Thu, 17 Apr 1997 19:53:34 -0700 (PDT) Message-Id: <3.0.32.19970417195737.0092cac0@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Apr 1997 19:57:38 -0700 To: ietf-smime@imc.org From: Charles Breed Subject: RE: S/MIME Charter suggestions... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk Easy, use a strong "MUST" profile. I think you meant to ask, "How do us poor US companies export our products" cb At 07:17 PM 4/17/97 -0700, you wrote: >OK, Charles, I'll bite. How are we going to have strong cryptography >that interoperates globally? > >Blake > >>-----Original Message----- >>From: Charles Breed [SMTP:cbreed@pgp.com] >>Sent: Thursday, April 17, 1997 12:36 PM >>To: ietf-smime@imc.org >>Subject: S/MIME Charter suggestions... >> >>After reading our Chairman, Paul Hoffman's (of IMC) S/MIME definition, >>I propose a few, slight modifications... >> >> >>IETF S/MIME Charter >>------------------- >>Electronic messaging is rapidly replacing traditional forms >>of communications for individuals and businesses. As digital >>communication techniques accelerate in popularity, so does >>the need for data privacy, message integrity, and >>non-repudiation of origin. >> >>The IETF S/MIME Working Group is chartered with defining a >>standard method to send and receive secure MIME messages >>that interoperate globally. The group will place particular >>emphasis on the need for strong cryptography based on open and >>publicly available algorithms. In fulfillment of this charter, >>the IETF S/MIME Working Group will define the use of file formats, >>communications protocols, cryptographic algorithms, digital >>certificates and other relevant operational concerns. >> >>================ >>fyi, the currently posted 'charter' for your comparisons... >> >> Description of the Working Group: >> >> S/MIME is a method for encrypting and/or authenticating MIME data. >> S/MIME defines a format for the MIME data, the algorithms that must be >> used for interoperability, and the additional operational concerns >> such as certificates and transport over the Internet. >>================ >> >>regards, >>Charles Breed >> > > From owner-ietf-smime Thu Apr 17 20:04:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA24018 for ietf-smime-bks; Thu, 17 Apr 1997 20:04:14 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA24014 for ; Thu, 17 Apr 1997 20:04:11 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id UAA05547 for ; Thu, 17 Apr 1997 20:04:57 -0700 (PDT) Message-Id: <3.0.32.19970417200900.009cf220@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Apr 1997 20:09:01 -0700 To: ietf-smime@imc.org From: Charles Breed Subject: Re: The 40-bit debate Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk I vote that we never force a "MUST" with weak 40-bit crypto, Let's not lead the naive to think it's "Secure". We all know a brute-force attack against 40-bit cipher can yield clear text in a short amount of time, so I believe, we (the IETF community) has a moral obligation to the millions of "unsuspecting" users AND we "MUST" have a spec that protects their content, (as one would think a Secure Product would...) Charles Breed At 07:47 PM 4/17/97 -0700, you wrote: >I'd like to second the motion to split the RC2/40 discussion into two >parts. Please note the subject of this part, and reply with this subject if >you want to talk about whether or not the S/MIME spec should have a MUST >or a SHOULD that includes 40-bit encryption. > >--Paul E. Hoffman, Director >--Internet Mail Consortium > > > > From owner-ietf-smime Thu Apr 17 19:59:08 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA23947 for ietf-smime-bks; Thu, 17 Apr 1997 19:59:08 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA23943 for ; Thu, 17 Apr 1997 19:59:05 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id TAA05511 for ; Thu, 17 Apr 1997 19:59:51 -0700 (PDT) Message-Id: <3.0.32.19970417200354.009cf220@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Apr 1997 20:03:56 -0700 To: ietf-smime@imc.org From: Charles Breed Subject: Re: The RC2 debate Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk I vote that RC2 (all key lengths) Should definitely have OIDs, and should be allowed as a viable profile, but not a "MUST". Charles Breed At 07:48 PM 4/17/97 -0700, you wrote: >I'd like to second the motion to split the RC2/40 discussion into two >parts. Please note the subject of this part, and reply with this subject if >you want to talk about whether or not the S/MIME spec should have a MUST >or a SHOULD that includes RC2 encryption. > >--Paul E. Hoffman, Director >--Internet Mail Consortium > > > > From owner-ietf-smime Thu Apr 17 20:37:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA24258 for ietf-smime-bks; Thu, 17 Apr 1997 20:37:19 -0700 (PDT) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by mail.proper.com (8.8.5/8.7.3) with SMTP id UAA24253 for ; Thu, 17 Apr 1997 20:37:16 -0700 (PDT) Received: (from uucp@localhost) by out1.ibm.net (8.6.9/8.6.9) id DAA386902 for ; Fri, 18 Apr 1997 03:38:00 GMT Received: from slip166-72-232-212.ny.us.ibm.net(166.72.232.212) by out1.ibm.net via smap (V1.3mjr) id smaZDkDM2; Fri Apr 18 03:37:44 1997 Received: (from uri@localhost) by alisan.ibm.net (8.7.6/8.7.3) id XAA04733; Thu, 17 Apr 1997 23:38:11 -0400 Date: Thu, 17 Apr 1997 23:38:11 -0400 Message-Id: <199704180338.XAA04733@alisan.ibm.net> From: Uri Blumenthal To: ietf-smime@imc.org Subject: The RC2 debate In-Reply-To: References: Reply-To: NOSPAM!uri@ibm.net Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk >>>>> "Paul" == Paul E Hoffman writes: Paul> I'd like to second the motion to split the RC2/40 discussion Paul> into two parts. Please note the subject of this part, and Paul> reply with this subject if you want to talk about whether or Paul> not the S/MIME spec should have a MUST or a SHOULD that Paul> includes RC2 encryption. S/MIME MUST say "MAY include RC2". NO WAY should it say MUST. From owner-ietf-smime Thu Apr 17 20:46:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA24307 for ietf-smime-bks; Thu, 17 Apr 1997 20:46:13 -0700 (PDT) Received: from enterprise.powerup.com.au (root@enterprise.powerup.com.au [203.2.122.69]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA24303 for ; Thu, 17 Apr 1997 20:46:08 -0700 (PDT) From: lindsay@powerup.com.au Received: from powerup.com.au (ts3309.powerup.com.au [203.32.9.105]) by enterprise.powerup.com.au (8.8.5/8.6.10) with SMTP id DAA05713; Fri, 18 Apr 1997 03:42:22 GMT Date: Fri, 18 Apr 1997 03:42:22 GMT Message-Id: <199704180342.DAA05713@enterprise.powerup.com.au> CC: ietf-smime@imc.org Subject: RE: Alternative symmetric algorithm freely available forIETFS/MIME (re: RC2 licensing). X-Mailer: Black Paw Communications's MailCat Beta for Win32 Beta Vs 2.0.0.3 To: Blake Ramsdell Sender: owner-ietf-smime@imc.org Precedence: bulk >I'm don't think that Steve is wrong in his wording that "the goals of >the IETF are out of step with US companies' business needs". >Consider >the following: The part I have a problem with is "US companies' business needs" - why should we care ? What about the needs of New Zealand business, or european or all the other hundreds of political entities. I State: US domestic restrictions should *not* be a par of the IETF standard setting. Yours Sincerely, Lindsay Mathieson Black Paw Communications From owner-ietf-smime Thu Apr 17 21:03:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA24400 for ietf-smime-bks; Thu, 17 Apr 1997 21:03:50 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id VAA24396 for ; Thu, 17 Apr 1997 21:03:47 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4B72.F0CAAAA0@cane.deming.com>; Thu, 17 Apr 1997 21:04:29 -0700 Message-ID: From: Blake Ramsdell To: "'lindsay@powerup.com.au'" Cc: "'ietf-smime@imc.org'" Subject: RE: Alternative symmetric algorithm freely available forIETFS/MIME (re: RC2 licensing). Date: Thu, 17 Apr 1997 21:04:27 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk Fair enough -- let me put it this way. If US domestic restrictions in this particular case are not part of the IETF standard setting, then how can we possibly come up with a guaranteed interoperable specification (which was the primary goal of S/MIME before being introduced to the IETF, and is still written in the charter that way)? And I certainly hope that if *your* needs weren't being represented by the IETF that you would speak up. It's your duty. Blake >-----Original Message----- >From: lindsay@powerup.com.au [SMTP:lindsay@powerup.com.au] >Sent: Thursday, April 17, 1997 8:42 PM >To: Blake Ramsdell >Cc: ietf-smime@imc.org >Subject: RE: Alternative symmetric algorithm freely available forIETFS/MIME >(re: RC2 licensing). > >>I'm don't think that Steve is wrong in his wording that "the goals of >>the IETF are out of step with US companies' business needs". >>Consider >>the following: > >The part I have a problem with is "US companies' business needs" - why should >we care ? What about the needs of New Zealand business, or european or all >the other hundreds of political entities. > >I State: > US domestic restrictions should *not* be a par of the IETF standard setting. > > >Yours Sincerely, > > >Lindsay Mathieson >Black Paw Communications > > From owner-ietf-smime Thu Apr 17 21:38:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA24566 for ietf-smime-bks; Thu, 17 Apr 1997 21:38:38 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id VAA24562 for ; Thu, 17 Apr 1997 21:38:34 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id AAA09271; Fri, 18 Apr 1997 00:39:05 -0400 (EDT) Message-Id: <199704180439.AAA09271@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Steve Dusse cc: "'Keith Moore'" , "'ietf-smime@imc.org'" Subject: Re: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). In-reply-to: Your message of "Thu, 17 Apr 1997 15:45:02 PDT." Date: Fri, 18 Apr 1997 00:39:05 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > Keith makes this point rather succintly. If there is agreement, then I > will stand by my earlier conviction; the goals of the IETF are out of > step with US companies' business needs. As such, we should find a way > to separate the non-business protocol portions of the S/MIME spec from > the US business-needs-centric profiling information. Seems like US companies need strong encryption as much as anyone else. Or if by "US companies' business needs" you really mean "the marketing concerns of US purveyors of crypto products", then understand this very clearly: the IETF exists to make technical recommendations for the Internet community, NOT to cater to the marketing concerns of US companies. As for separating the specs: yes, I agree. The standard needs to specify sufficiently strong algorithms for the "must-implement" profile, but I know of no reason why a separate informational RFC cannot specify a different profile for those who choose to use it. BTW, your characterization of the difference as "non-business" vs. "business-needs-centric" is ... misleading at best. Let us speak plainly, and call it what it is: "reasonably secure crypto" vs. "crypto weak enough to pass US current export regulations." Keith From owner-ietf-smime Thu Apr 17 21:42:59 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA24584 for ietf-smime-bks; Thu, 17 Apr 1997 21:42:59 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id VAA24579; Thu, 17 Apr 1997 21:42:56 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4B78.68D66110@cane.deming.com>; Thu, 17 Apr 1997 21:43:38 -0700 Message-ID: From: Blake Ramsdell To: "'Paul E. Hoffman'" , "'ietf-smime@imc.org'" Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing). Date: Thu, 17 Apr 1997 21:43:36 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk I wonder how many non-mail client software companies would want to implement and export S/MIME products? Perhaps I was overly broad in my statement that "US companies need to sell products outside the US and Canada", and I should have said that "US companies that want to implement S/MIME need to have the ability to sell products outside the US and Canada". Software is an international business. The *teeny number of companies* is 100% of the current and announced S/MIME vendor market in the US. Every one of them sells outside of the US and Canada. Small in number compared to the number of companies in the US, granted. But it is 100% of the US market that is providing S/MIME. I understand that there is a faction that says that RC2 40-bit should just be changed from MUST to SHOULD. This will cause a lack of interoperability. I further understand that there is a faction that says that RC2 should be removed completely from the algorithm suite. This will also cause a lack of interoperability. This is why I don't differentiate between the two -- the outcome is exactly the same. This is also why I have asked others to propose alternative US exportable algorithms so that we can keep an exportable algorithm in the MUST section, and thus have a minimum level of interoperability. The only ones who have to use it are the ones who are forced to. If you have an idea as to how this debate can continue in an open forum that is more to your liking, let me know. I'm just trying to figure out how to fulfill the proposed charter of this working group which specifies interoperability. Blake >-----Original Message----- >From: Paul E. Hoffman [SMTP:phoffman@imc.org] >Sent: Thursday, April 17, 1997 7:46 PM >To: ietf-smime@imc.org >Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME >(re: RC2 licensing). > >At 6:56 PM -0700 4/17/97, Blake Ramsdell wrote: >>Consider >>the following: >> >>1. US companies need to sell products outside the US and Canada > >Let's be a bit more specific here. *Some* US companies need to sell >products outside the US and Canada (and Mexico, by the way...). Not all of >them. The ones you are talking about are companies that create mail client >software. They are a teeny minority of US companies. > >>2. The current discussion about removing RC2 40-bit is about removing >>the necessary component from the specification that would allow this > >Not necessarily true. Some people would like to remove RC2/40 altogether, >others would prefer to move it to SHOULD or possibly just a list known, >widely-deployed algorithms. I hear no consensus yet, which isn't surprising >given the topic. > >>In any case, this is the business need, and it appears that the IETF >>wants to head the spec in a different direction. > >Wrong and wrong. > >- It is a business need *for a teeny number of companies*. The vast >majority of US/Canada/Mexico companies have a business need for reliable, >interoperable, secure email. If the IETF can get that with RC2/40, great. >If not, the IETF must listen to the needs of all businesses and still come >up with a spec for reliable, interoperable, secure email. > >- "The IETF" doesn't speak with one voice, and thinking that a handful of >comments on one mailing list over two days reflects the voice of the IETF >is just plain silly. The debate is only begun, and not very well I might >add. > >--Paul E. Hoffman, Director >--Internet Mail Consortium > > From owner-ietf-smime Thu Apr 17 21:59:49 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA24743 for ietf-smime-bks; Thu, 17 Apr 1997 21:59:49 -0700 (PDT) Received: from blacklodge.c2.net (blacklodge.c2.net [208.139.36.35]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id VAA24738; Thu, 17 Apr 1997 21:59:46 -0700 (PDT) Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id VAA09972; Thu, 17 Apr 1997 21:59:46 -0700 (PDT) Date: Thu, 17 Apr 1997 21:59:46 -0700 (PDT) From: Raph Levien X-Sender: raph@blacklodge.c2.net To: Blake Ramsdell cc: "'Paul E. Hoffman'" , "'ietf-smime@imc.org'" Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing). In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk On Thu, 17 Apr 1997, Blake Ramsdell wrote: > I understand that there is a faction that says that RC2 40-bit should > just be changed from MUST to SHOULD. This will cause a lack of > interoperability. I further understand that there is a faction that > says that RC2 should be removed completely from the algorithm suite. > This will also cause a lack of interoperability. These statements are simply not true. There is nothing that prevents a non-US company from developing a product containing strong crypto. In fact, for SSL, this has already been done. There is also an independent implementation of PGP. RC2 may actually make interoperability worse, because companies may need to license the RC2 code from RSA to be 100% kosher, and the US may prohibit RSA from exporting this license. What will really kill interoperability for sure is splitting S/MIME into different profiles. Raph From owner-ietf-smime Thu Apr 17 22:18:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA24874 for ietf-smime-bks; Thu, 17 Apr 1997 22:18:41 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id WAA24869; Thu, 17 Apr 1997 22:18:38 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id BAA04610; Fri, 18 Apr 1997 01:19:21 -0400 (EDT) Message-Id: <199704180519.BAA04610@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Paul E. Hoffman" cc: ietf-smime@imc.org, moore@cs.utk.edu Subject: Re: The RC2 debate In-reply-to: Your message of "Thu, 17 Apr 1997 19:48:23 PDT." Date: Fri, 18 Apr 1997 01:19:21 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > Please note the subject of this part, and reply with this subject if > you want to talk about whether or not the S/MIME spec should have a MUST > or a SHOULD that includes RC2 encryption. I think the correct word is "MAY", or perhaps even less -- simply have the spec do nothing more than document the RC2 algorithm-id, and put the profile that uses RC2 in a separate document. So long as RC2 remains proprietary, I can't even see making it a "SHOULD". My reasoning here is entirely due to the status of RC2 as a trade secret, and has nothing to do with key lengths. Keith From owner-ietf-smime Thu Apr 17 22:19:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA24893 for ietf-smime-bks; Thu, 17 Apr 1997 22:19:16 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id WAA24888; Thu, 17 Apr 1997 22:19:14 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4B7D.7AB18220@cane.deming.com>; Thu, 17 Apr 1997 22:19:56 -0700 Message-ID: From: Blake Ramsdell To: "'Raph Levien'" Cc: "'Paul E. Hoffman'" , "'ietf-smime@imc.org'" Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing). Date: Thu, 17 Apr 1997 22:19:53 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk Yes, I understand that two *particular* implementations can interoperate. But can *any* two implementations interoperate? No. Because of US export regulation, you can't possibly answer that question yes, because there will be a vendor that does not implement the export-only algorithm unless that algorithm is labeled MUST. It would be ridiculous for me to say that you had no interoperability at all -- there is always "identity" interoperability with your own product (I hope!). I'm sorry if my language wasn't precise. Of course, I may have been trying to be ridiculous also -- it happens :). Blake >-----Original Message----- >From: Raph Levien [SMTP:raph@acm.org] >Sent: Thursday, April 17, 1997 10:00 PM >To: Blake Ramsdell >Cc: 'Paul E. Hoffman'; 'ietf-smime@imc.org' >Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME >(re: RC2 licensing). > > > >On Thu, 17 Apr 1997, Blake Ramsdell wrote: > >> I understand that there is a faction that says that RC2 40-bit should >> just be changed from MUST to SHOULD. This will cause a lack of >> interoperability. I further understand that there is a faction that >> says that RC2 should be removed completely from the algorithm suite. >> This will also cause a lack of interoperability. > >These statements are simply not true. There is nothing that prevents a >non-US company from developing a product containing strong crypto. In >fact, for SSL, this has already been done. There is also an independent >implementation of PGP. > >RC2 may actually make interoperability worse, because companies may need >to license the RC2 code from RSA to be 100% kosher, and the US may >prohibit RSA from exporting this license. > >What will really kill interoperability for sure is splitting S/MIME into >different profiles. > >Raph From owner-ietf-smime Thu Apr 17 22:33:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA25082 for ietf-smime-bks; Thu, 17 Apr 1997 22:33:44 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id WAA25076; Thu, 17 Apr 1997 22:33:41 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id BAA09073; Fri, 18 Apr 1997 01:34:24 -0400 (EDT) Message-Id: <199704180534.BAA09073@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Paul E. Hoffman" cc: ietf-smime@imc.org, moore@cs.utk.edu Subject: Re: The 40-bit debate In-reply-to: Your message of "Thu, 17 Apr 1997 19:47:55 PDT." Date: Fri, 18 Apr 1997 01:34:23 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > Please note the subject of this part, and reply with this subject if > you want to talk about whether or not the S/MIME spec should have a MUST > or a SHOULD that includes 40-bit encryption. The S/MIME spec can specify a way to do 40-bit crypto if this WG wants it to do so, and can even specify that implementations "MUST" (or "SHOULD") implement it. However, + any MUST or SHOULD algorithm MUST be published and available on fair and nondiscriminatory terms (this is from RFC 2026) + (IMHO) the S/MIME spec will not be of standards-track quality unless it also specifies a "MUST implement" algorithm and key length compatible with the recommendations of RFC 1984. Keith From owner-ietf-smime Thu Apr 17 22:45:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA25177 for ietf-smime-bks; Thu, 17 Apr 1997 22:45:47 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id WAA25169; Thu, 17 Apr 1997 22:45:44 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id BAA09597; Fri, 18 Apr 1997 01:46:11 -0400 (EDT) Message-Id: <199704180546.BAA09597@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Blake Ramsdell cc: "'Paul E. Hoffman'" , "'ietf-smime@imc.org'" , moore@cs.utk.edu Subject: Re: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing). In-reply-to: Your message of "Thu, 17 Apr 1997 21:43:36 PDT." Date: Fri, 18 Apr 1997 01:46:11 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > I understand that there is a faction that says that RC2 40-bit should > just be changed from MUST to SHOULD. This will cause a lack of > interoperability. I further understand that there is a faction that > says that RC2 should be removed completely from the algorithm suite. > This will also cause a lack of interoperability. That's exactly right: the minimum implementation for "Internet Standard S/MIME" (ignoring the trademark issues for the moment) will not and cannot be compatible with existing S/MIME implementations -- at least not unless/until there is a RC2 specification available for public review. To do otherwise would be fundamentally incompatible with the Internet Standards process. On the other hand, nothing says that "Internet Standard S/MIME" products can't also include the ability to interoperate with "S/MIME classic" as long as RSA is willing to license such implementations. Keith From owner-ietf-smime Thu Apr 17 23:12:04 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA25422 for ietf-smime-bks; Thu, 17 Apr 1997 23:12:04 -0700 (PDT) Received: from blacklodge.c2.net (blacklodge.c2.net [208.139.36.35]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA25416; Thu, 17 Apr 1997 23:12:01 -0700 (PDT) Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id XAA12657; Thu, 17 Apr 1997 23:12:09 -0700 (PDT) Date: Thu, 17 Apr 1997 23:12:09 -0700 (PDT) From: Raph Levien X-Sender: raph@blacklodge.c2.net To: Blake Ramsdell cc: "'Paul E. Hoffman'" , "'ietf-smime@imc.org'" Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing). In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk On Thu, 17 Apr 1997, Blake Ramsdell wrote: > Yes, I understand that two *particular* implementations can > interoperate. But can *any* two implementations interoperate? No. > Because of US export regulation, you can't possibly answer that question > yes, because there will be a vendor that does not implement the > export-only algorithm unless that algorithm is labeled MUST. > > It would be ridiculous for me to say that you had no interoperability at > all -- there is always "identity" interoperability with your own product > (I hope!). I'm sorry if my language wasn't precise. Of course, I may > have been trying to be ridiculous also -- it happens :). I still don't agree with you. If the IETF specifies (say) Triple-DES as a MUST algorithm, then *any* two implementations would be able to interoperate. It's just not the case that there would be any US exportable implementations of S/MIME. Thus, there would be no reason for a sending implementation to use an export-only algorithm. Raph From owner-ietf-smime Thu Apr 17 23:29:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA25552 for ietf-smime-bks; Thu, 17 Apr 1997 23:29:38 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id XAA25547; Thu, 17 Apr 1997 23:29:35 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4B87.4F39D6B0@cane.deming.com>; Thu, 17 Apr 1997 23:30:18 -0700 Message-ID: From: Blake Ramsdell To: "'Raph Levien'" Cc: "'Paul E. Hoffman'" , "'ietf-smime@imc.org'" Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing). Date: Thu, 17 Apr 1997 23:30:16 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk We should cut and paste this whole debate from the IMC Resolving Security mailing list last year :). There are currently two profiles in the S/MIME spec. A "RESTRICTED" profile which specifies 40-bit RC2 as a MUST for encryption and decryption, and an "UNRESTRICTED" profile which specifies 40-bit RC2 and triple-DES as a MUST for encryption and decryption. Certainly, if the spec is changed to have only triple-DES, then any two compliant applications will be able to interoperate (I learned a cool word from Ned one time: "axiomatic". This is axiomatic. Even if the spec didn't change, any two compliant applications would be able to interoperate). I probably used the cool word wrong, but you get my point. This leaves the US export-restricted crowd out of the party. I've started this particular rant over on the 40-bit thread, so go over there to discuss that one. Blake >-----Original Message----- >From: Raph Levien [SMTP:raph@acm.org] >Sent: Thursday, April 17, 1997 11:12 PM >To: Blake Ramsdell >Cc: 'Paul E. Hoffman'; 'ietf-smime@imc.org' >Subject: RE: Alternative symmetric algorithm freely availableforIETFS/MIME >(re: RC2 licensing). > > > >On Thu, 17 Apr 1997, Blake Ramsdell wrote: > >> Yes, I understand that two *particular* implementations can >> interoperate. But can *any* two implementations interoperate? No. >> Because of US export regulation, you can't possibly answer that question >> yes, because there will be a vendor that does not implement the >> export-only algorithm unless that algorithm is labeled MUST. >> >> It would be ridiculous for me to say that you had no interoperability at >> all -- there is always "identity" interoperability with your own product >> (I hope!). I'm sorry if my language wasn't precise. Of course, I may >> have been trying to be ridiculous also -- it happens :). > >I still don't agree with you. If the IETF specifies (say) Triple-DES as a >MUST algorithm, then *any* two implementations would be able to >interoperate. It's just not the case that there would be any US >exportable implementations of S/MIME. Thus, there would be no reason for >a sending implementation to use an export-only algorithm. > >Raph > From owner-ietf-smime Thu Apr 17 23:28:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA25540 for ietf-smime-bks; Thu, 17 Apr 1997 23:28:13 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id XAA25536 for ; Thu, 17 Apr 1997 23:28:10 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4B87.1CB76360@cane.deming.com>; Thu, 17 Apr 1997 23:28:53 -0700 Message-ID: From: Blake Ramsdell To: "'ietf-smime@imc.org'" Subject: RE: The 40-bit debate Date: Thu, 17 Apr 1997 23:28:51 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk The only 40-bit debate that exists in my mind is how to make sure that every client has the ability to encrypt and decrypt messages to and from any S/MIME client. And unfortunately, this means mandating the ability to encrypt and decrypt using a 40-bit key. Using 40-bit encryption would meet this (almost) working group's goal of having an interoperable standard, and satisfy the needs of US S/MIME companies that would like to export their products. I understand the "40 bits sux" argument and all the other fist-and-lightning-bolt / my-lock-my-key / golden-key / whatever opinions. The simple fact is, just because it's required, doesn't mean you are required to use it if you can use something else. And just because you use it, doesn't mean that you can't put up a big warning screen that says "WARNING: THIS MESSAGE IS ABOUT TO BE SENT USING 40-BIT ENCRYPTION. IT HAS BEEN THEORIZED THAT YOU COULD BUILD A REALLY BIG COMPUTER THAT CAN DECRYPT IT REALLY QUICKLY, BUT NO ONE HAS REALLY DONE IT YET, OR AT LEAST THEY HAVEN'T ADMITTED TO IT. ACTUALLY, IAN BROKE A 40-BIT KEY IN ABOUT THREE HOURS, BUT I THINK HE USED MORE THAN ONE MACHINE AND HE SKIPPED LUNCH." The point is, that the user has the CHOICE to read a message that came from some dumb, crappy export-only version of some wanker American's product, and the user has the CHOICE to send a message back to that same person. This is most easily accomplished by having a 40-bit algorithm specified as a MUST in the spec. Some of the wanker American products, by the way, are from pretty high-volume companies. We can certainly dump 40-bit out of the MUST, but at that point, you have just broken interoperability with those products. And just because it isn't a MUST in the spec, doesn't mean that people won't implement it, so the moral argument against 40-bit encryption is moot. They're (we're) gonna do it anyway. We're not misleading our customers -- we tell them flat-out about the export limitations and the relative weakness of 40-bit keys are. If they don't like it, then they go to another (presumably non-US) vendor that can give them what they want. They're not stupid. Blake >-----Original Message----- >From: Paul E. Hoffman [SMTP:phoffman@imc.org] >Sent: Thursday, April 17, 1997 7:48 PM >To: ietf-smime@imc.org >Subject: The 40-bit debate > >I'd like to second the motion to split the RC2/40 discussion into two >parts. Please note the subject of this part, and reply with this subject if >you want to talk about whether or not the S/MIME spec should have a MUST >or a SHOULD that includes 40-bit encryption. > >--Paul E. Hoffman, Director >--Internet Mail Consortium > > From owner-ietf-smime Thu Apr 17 23:56:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA25704 for ietf-smime-bks; Thu, 17 Apr 1997 23:56:09 -0700 (PDT) Received: from tweety.bhp.com.au (tweety.bhp.com.au [192.83.224.130]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA25700 for ; Thu, 17 Apr 1997 23:56:04 -0700 (PDT) Received: from gossamer.itmel.bhp.com.au (gossamer.itmel.bhp.com.au [134.18.115.254]) by tweety.bhp.com.au (8.8.4/8.8.4) with ESMTP id QAA00871; Fri, 18 Apr 1997 16:56:18 +1000 (EST) Received: from cerberus.bhpese.oz.au (cerberus.itntl.bhp.com.au [134.18.16.17]) by gossamer.itmel.bhp.com.au (8.8.4/8.8.4) with SMTP id QAA16021; Fri, 18 Apr 1997 16:55:42 +1000 (EST) Received: from nc.itntl.bhp.com.au (nc) by cerberus.bhpese.oz.au with SMTP id AA25211; Fri, 18 Apr 1997 16:55:28 +1000; sendmail 5.67a/Sm3.20RMPSU (from Sm@nc.bhpese.oz.au for BlakeR@deming.com) Received: from nc.itntl.bhp.com.au by nc.itntl.bhp.com.au with ESMTP id QAA25430; Fri, 18 Apr 1997 16:55:28 +1000; sendmail 8.6.10/Sm2.1sun (from Sm@nc.itntl.bhp.com.au for ) Message-Id: <199704180655.QAA25430@nc.itntl.bhp.com.au> To: Blake Ramsdell Cc: ietf-smime@imc.org Subject: Re: The 40-bit debate In-Reply-To: Your message of "Thu, 17 Apr 1997 23:28:51 MST." X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9[" Sender: owner-ietf-smime@imc.org Precedence: bulk >The only 40-bit debate that exists in my mind is how to make sure that >every client has the ability to encrypt and decrypt messages to and from >any S/MIME client. And unfortunately, this means mandating the ability >to encrypt and decrypt using a 40-bit key. Using 40-bit encryption >would meet this (almost) working group's goal of having an interoperable >standard, and satisfy the needs of US S/MIME companies that would like >to export their products. Instead of using 40bit RC2 to provide an illusion of security, why not ship using the identity algorithm, xor with 0, named 'No Security', and be done with it. At least that way those people with out the desire to know any technical details will not be deluded into thinking they are making a secure exchange. This will have the advantage of being exportable. Sm From owner-ietf-smime Fri Apr 18 02:50:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id CAA28300 for ietf-smime-bks; Fri, 18 Apr 1997 02:50:37 -0700 (PDT) Received: from dde.dde.dk (dde.dde.dk [152.95.32.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id CAA28296 for ; Fri, 18 Apr 1997 02:50:26 -0700 (PDT) Received: by dde.dde.dk (5.61/9.3) id AA10337; Fri, 18 Apr 97 10:58:24 +0200 Received: from Knud.dde.dk by dde.dde.dk (5.61/9.3) with SMTP id AA28734; Fri, 18 Apr 97 10:58:24 +0200 Received: by Knud.dde.dk (4.1/9.7) id AA00670; Fri, 18 Apr 97 10:58:49 +0200 Message-Id: <9704180858.AA00670@Knud.dde.dk> X-Mailer: exmh version 2.0beta 12/23/96 To: ietf-smime@imc.org Subject: What's wrong with this format?? Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1189929512P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 18 Apr 1997 10:58:48 +0200 From: "Frederik H. Andersen" Sender: owner-ietf-smime@imc.org Precedence: bulk --==_Exmh_-1189929512P Content-Type: text/plain; charset=us-ascii Hi! cbreed@pgp.com said: > The IETF S/MIME Working Group is chartered with defining a standard > method to send and receive secure MIME messages that interoperate > globally. The group will place particular emphasis on the need for > strong cryptography based on open and publicly available algorithms. If this is the charter, what is wrong with the format of this mail? That is RFC2015? Can't that be used as a MUST profile or do you all feel that it is too PGP specific (althoug this IS the international standard of use today!) I don't quite see why someting like RFC2015 or other relatives to RFC1847 can't be used? /Frederik -- ------------------------------------------------------------------ Frederik H. Andersen Phone: +45 42 84 50 11 Dansk Data Elektronik A/S Fax: +45 42 84 52 20 Herlev Hovedgade 199 Email: fha@dde.dk (MIME accepted) DK-2730 Herlev, DENMARK PGP Fingerprint: 6B BC FB 45 E4 69 CE A2 63 E1 62 1F 0C 65 C2 E4 ------------------------------------------------------------------ --==_Exmh_-1189929512P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.3ia iQBVAwUBM1c3x2/LC8e07F11AQGw7gIAiqsJuj3LE2IeEhJe1oB9ECphBMqQ+JzF 9W9OLn0e9aChQIvMINKHSLYtk3idXIiIPTjbmFmKqPPa5VaHN3KQrw== =H4R0 -----END PGP MESSAGE----- --==_Exmh_-1189929512P-- From owner-ietf-smime Fri Apr 18 03:32:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id DAA29130 for ietf-smime-bks; Fri, 18 Apr 1997 03:32:39 -0700 (PDT) Received: from enterprise.powerup.com.au (root@enterprise.powerup.com.au [203.2.122.69]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id DAA29096 for ; Fri, 18 Apr 1997 03:29:16 -0700 (PDT) From: lindsay@powerup.com.au Received: from powerup.com.au (ts1210.powerup.com.au [203.19.191.74]) by enterprise.powerup.com.au (8.8.5/8.6.10) with SMTP id KAA02884; Fri, 18 Apr 1997 10:26:27 GMT Date: Fri, 18 Apr 1997 10:26:27 GMT Message-Id: <199704181026.KAA02884@enterprise.powerup.com.au> CC: ietf-smime@imc.org Subject: Re: Alternative symmetric algorithm freely availableforIETFS/MIME (re: RC2 licensing). X-Mailer: Black Paw Communications's MailCat Beta for Win32 Beta Vs 2.0.0.3 To: Keith Moore Sender: owner-ietf-smime@imc.org Precedence: bulk > will not and >cannot be compatible with existing S/MIME implementations -- at least >not >unless/until there is a RC2 specification available for public >review. Just because a few companies (e.g. MS & Netscape) have jumped the gun in implementing S/MIME before its finished is no reason lock RC2 into the spec -- Lindsay Mathieson Black Paw Communications Using MailCat Beta for Win32 Beta Vs 2.0.0.3, on April 18, 1997, in Win95 4.0 Checkout the latest (and greatest ) mail client, MailCat at: http://www.powerup.com.au/~lindsay From owner-ietf-smime Fri Apr 18 03:36:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id DAA29160 for ietf-smime-bks; Fri, 18 Apr 1997 03:36:17 -0700 (PDT) Received: from enterprise.powerup.com.au (root@enterprise.powerup.com.au [203.2.122.69]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id DAA29154 for ; Fri, 18 Apr 1997 03:36:08 -0700 (PDT) From: lindsay@powerup.com.au Received: from powerup.com.au (ts1210.powerup.com.au [203.19.191.74]) by enterprise.powerup.com.au (8.8.5/8.6.10) with SMTP id KAA02862; Fri, 18 Apr 1997 10:26:15 GMT Date: Fri, 18 Apr 1997 10:26:15 GMT Message-Id: <199704181026.KAA02862@enterprise.powerup.com.au> CC: ietf-smime@imc.org Subject: RE: The 40-bit debate X-Mailer: Black Paw Communications's MailCat Beta for Win32 Beta Vs 2.0.0.3 To: Blake Ramsdell Sender: owner-ietf-smime@imc.org Precedence: bulk A lot of this discussion seems to be aimed at: 1. Protecting RSA's "investment" in S/MIME 2. Protecting US companies from international competion. Perhaps we could specify a 2 level spec ? : Level 1 : Must implement a 40 bit key (using DES or whatever) Level 2 : Incorporates Level 1 *and* must implement a 128+ bit key using If we where being honest we could label it "Insecure/MIME" & "Secure/MIME" This way everybody would have a base level of compatibility, US companies could sell S/MIME in the US and export I/MIME (basically what happens now), Non-US companies could sell S/MIME everywhere plus exporting to the US. The only loser would be the US companies who can't export S/MIME (a ridiculous situation). I would be perfectly happy with that. -- Lindsay Mathieson Black Paw Communications From owner-ietf-smime Fri Apr 18 06:39:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA01018 for ietf-smime-bks; Fri, 18 Apr 1997 06:39:44 -0700 (PDT) Received: from guardian.guard.ncsc.mil (guardian.guard.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id GAA01014 for ; Fri, 18 Apr 1997 06:39:41 -0700 (PDT) Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA07657 for ; Fri, 18 Apr 1997 09:40:08 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma007655; Fri Apr 18 09:39:58 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id JAA00969 for ; Fri, 18 Apr 1997 09:37:03 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id JAA21904; Fri, 18 Apr 1997 09:39:29 -0400 Date: Fri, 18 Apr 1997 09:39:29 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199704181339.JAA21904@argon.ncsc.mil> To: ietf-smime@imc.org Subject: Re: Other exportable 40-bit algorithms X-Sun-Charset: US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk > From: Uri Blumenthal > > Yes for CDMF (IBM-patented, clever reducing the key strength > to 40 bits, as opposite to simply accepting a 40-bit > key only from a user). > There is no "DES-40" per se, unless you mean CDMF; to the best > of my knowledge. Uri, Are you familiar enough with the SSL/TLS technique of creating export keys (hashing 40 secret bits with 88 salt bits) to state whether it is covered by the CDMF patent? The SSL technique has obviously gotten export approval, and has received some level of cryptographic scrutiny within the SSL/TLS community, and I've heard no mention of it being encumbered. dpk From owner-ietf-smime Fri Apr 18 08:29:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA02547 for ietf-smime-bks; Fri, 18 Apr 1997 08:29:37 -0700 (PDT) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA02543 for ; Fri, 18 Apr 1997 08:29:35 -0700 (PDT) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id IAA28693 for ; Fri, 18 Apr 1997 08:29:45 -0700 (PDT) X-Sender: llundbla@nala.qualcomm.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 08:28:17 -0700 To: ietf-smime@imc.org From: Laurence Lundblade Subject: RE: The 40-bit debate - user's needs Sender: owner-ietf-smime@imc.org Precedence: bulk I think we can put the "US company needs" aside for a moment and look at it from the point of view of the user. The result is more or less the same. The US export law prevents vendors (freeware, shareware or commercial) from meeting the user's need of strong, globally interoperable crypto. So the question for me, is what is the best attack that will get the law changed, or allow us to get around it? The law is the real problem, not one company's desire to make money. The fact that the only algorithm approved for export is IPR of a particular company is sort of an ironic twist to this debate. I suspect the way to get the law changed, is to create public opinion which will in turn put pressure on our legislators. The argument used thus far is that the law is "bad for US business". I don't have the inside track on the politics, but it seems that has had mixed results. So what are the scenarios for public opinion given our two choices to doing 40 bit or not? If we do 40 bit, then we're likely to see the CNN headline and S/MIME may get a black eye. Can the politics be twisted to blame this on the US government? Privacy is certainly an issue the public is sensitive to. If we only do strong with no export, I expect implementations to show up internationally that will interoperate with US implementations. Some US implementations might escape the country too. I'm not sure where the pressure comes from other, than documenting the lost sales. I suspect these arguments are pretty incomplete due to my lack understanding of all the politics, but hopefully approaching the problem of changing the law for the sake of users around the world is a useful alternative to the current debate. LL From owner-ietf-smime Fri Apr 18 09:25:09 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA03161 for ietf-smime-bks; Fri, 18 Apr 1997 09:25:09 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA03156 for ; Fri, 18 Apr 1997 09:25:07 -0700 (PDT) Message-Id: In-Reply-To: <199704181026.KAA02862@enterprise.powerup.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 09:30:01 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: RE: The 40-bit debate Sender: owner-ietf-smime@imc.org Precedence: bulk I guess I should have been more specific when I started this thread. What I should have said was: After reading the current draft (which is available at ), please use the above subject line when replying about whether or not the S/MIME spec should have a MUST or a SHOULD that includes 40-bit encryption. It's clear to me that some people who are replying on this list haven't read the draft since they didn't know that the draft has two profiles, a "restricted" one that has 40-bit only and an "unrestricted" one that has both 40-bit and tripleDES. Section 2.6 of the draft clearly says when the restricted profile should be used, and that's pretty damn rarely. Now, I'm not saying that the current draft is the best solution, particularly since profiles have caused horrible problems for IETF-blessed email in the past, but I believe that this can be worked out for S/MIME. So, everyone, please read the draft, particularly Section 2.6 and all of its subsections, and continue to comment on the 40-bit MUST/SHOULD/MAY issue. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Fri Apr 18 11:09:02 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA04501 for ietf-smime-bks; Fri, 18 Apr 1997 11:09:02 -0700 (PDT) Received: from RSA.COM (chirality.rsa.com [192.80.211.33]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA04497 for ; Fri, 18 Apr 1997 11:08:59 -0700 (PDT) Received: from eagle.rsa.com by RSA.COM with SMTP id AA19275; Fri, 18 Apr 97 10:06:55 PDT Received: by LOBESTER.rsa.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4BE9.6E3E96B0@LOBESTER.rsa.com>; Fri, 18 Apr 1997 11:12:40 -0700 Message-Id: From: Steve Dusse To: "'Keith Moore'" Cc: "'ietf-smime@imc.org'" Subject: RE: Alternative symmetric algorithm freely available for IETFS/MIME (re: RC2 licensing). Date: Fri, 18 Apr 1997 11:12:40 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk Keith, I agree with your characterization of the issues and I will attempt to initiate the separation of protocol from profiling if that seems like an acceptable path to IETF involvement in S/MIME. > >BTW, your characterization of the difference as "non-business" vs. >"business-needs-centric" is ... misleading at best. I disagree. Perhaps a clarification is in order. By US companies' business needs, I am referring to US-based software developers. Roughly speaking, US software companies (my company excepted) derive 50% of their revenue from products that are exported. Export of product with encryption is tightly controlled. RC2 was created specifically to address this business issue, no other. >Let us speak plainly, and call it what it is: "reasonably secure crypto" >vs. "crypto weak enough to pass US current export regulations." Fair enough. -steve > From owner-ietf-smime Fri Apr 18 12:13:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA05501 for ietf-smime-bks; Fri, 18 Apr 1997 12:13:01 -0700 (PDT) Received: from callisto.hip.berkeley.edu (callisto.HIP.Berkeley.EDU [136.152.64.218]) by mail.proper.com (8.8.5/8.7.3) with SMTP id MAA05497 for ; Fri, 18 Apr 1997 12:12:55 -0700 (PDT) Received: (from raph@localhost) by callisto.hip.berkeley.edu (8.6.12/8.6.12) id MAA00778 for ietf-smime@imc.org; Fri, 18 Apr 1997 12:15:02 -0700 Message-ID: <3357C832.37EC2D8F@acm.org> Date: Fri, 18 Apr 1997 12:14:58 -0700 From: Raph Levien X-Mailer: Mozilla 3.0 (X11; U; Linux 1.2.13 i586) MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: The 40-bit debate Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk Blake Ramsdell wrote: > We should cut and paste this whole debate from the IMC Resolving > Security mailing list last year :). Ouch! I feel like we've been through this before, many times before. Nonetheless, I still want to respond to a number of statements here which I feel to be inaccurate. I'll start with Laurence Lundblade: > The US export law prevents vendors (freeware, shareware or commercial) from > meeting the user's need of strong, globally interoperable crypto. This really needs to be clarified. The US export law prevents _US_ vendors from meeting the user's need of strong, globally interoperable crypto. At present, there is nothing stopping a mixture of US and non-US vendors from meeting these needs. In this scenario, the US vendors would be barred from exporting their product. Non-US vendors, on the other hand, would be able to supply the entire world. This would be the case if there were any algorithm other than the 40-bit ones listed as MUST. I should clarify one other point: even listing at least one exportable algorithm as MUST won't guarantee full interoperability. The remaining issue is RSA key length. Unless something happened to the export regs that I'm not aware of, US-export software is still restricted to 512-bit RSA keys. Therefore, this software won't recognize signatures made with unrestricted software, and can't be used to send encrypted messages to unrestricted agents. I'm not sure whether this is still interoperability or not (I'm not trying to be funny here - I think the underlying problem is that we haven't agreed on exactly what "interoperability" means). Paul Hoffman writes: > It's clear to me that some people who are replying on this list haven't > read the draft since they didn't know that the draft has two profiles, a > "restricted" one that has 40-bit only and an "unrestricted" one that has > both 40-bit and tripleDES. Section 2.6 of the draft clearly says when the > restricted profile should be used, and that's pretty damn rarely. I have a few problems with this. 2.6.3 appears to give users the choice between incurring the "risk of failed decryption" and defaulting to RC2/40. Again, I'm not sure we can claim "interoperability" in the former case. I don't mean to whine, but I am quite curious why my earlier proposal (in which the default algorithm was dependent on the length of the recipient's RSA key) was abandoned. This proposal maximized interoperability in the case where one of the agents was restricted, yet prevented RC2/40 from being the default choice in the case where neither agents were restricted. Section 2.6.3.3 also invites protocol attacks: > If a sending agent using the unrestricted profile has not received a > set of capabilities from the intended recipient for the message, but > the sending agent has received at least one message from the > recipient, and the last message received used RC2 in CBC mode at a key > size of 40 bits (indicating that the recipient only uses the > restricted profile), the outgoing message SHOULD use RC2 in CBC mode > at a key size of 40 bits if the sending agent reasonably expects the > recipient to be able to decrypt the message. It is not stated here how the sending agent should determine whether it has receieved "at least one message from the recipient." Does it simply use the e-mail address in the "From:" header field to identify the sender? Or does it require a trusted signature as well? Let's say the sending agent is Alice, the recipient is Bob, and the attacker is Mallet. In the first case, all Mallet would need to do is send mail to Alice saying "From: Bob" and encrypt it using RC2/40. Then, when Alice sent mail to Bob, rule 2.6.3.3 would click in, and the message would also be encrypted with RC2/40. In the second case, there's no language in this section that would prevent replay attacks. If Bob had ever generated a signed RC2/40 message (say, by mistake), then Mallet could forward that message to Alice, which would cause her to use RC2/40 in her messages to Bob until she received the next signed non-RC2/40 message from Bob. But the second case seems to me to be moot, because if we're requiring trusted signatures, then Alice should be able to expect a signed (and timestamped) symmetric algorithm capabilities field in the message, as well. Finally, Steve Dusse writes: > I agree with your characterization of the issues and I will attempt to > initiate the separation of protocol from profiling if that seems like an > acceptable path to IETF involvement in S/MIME. Pardon me for being blunt, but from a user's perspective, having a single protocol with two different profiles is no different from having two different protocols. Going this route means trading interoperability for the privilege of US companies to export software and still have the S/MIME label. I'm not arguing against this choice, just asking that it be made clear exactly what's being proposed. To sum up, I see two choices: 1) Include a strong, non-proprietary algorithm as MUST, and specify that sending agents MUST usae this algorithm when nothing further is known about the recipient's capabilities. 2) Define two profiles. Only guarantee full interoperability when the two agents are in the same profile. Choice (1) would be a strong, globally interoperable solution, but would make it impossible for US vendors to export a product with the S/MIME label. As such, it is an invitation to non-US vendors to walk away with a significant market share. I can see why the US vendors currently in control of S/MIME would prefer not to see this happen. However, the IETF has a rich tradition of making design decisions based on the technical superiority of the resulting protocols, rather than to favor the business interests of individual companies. It will be interesting to see how this gets resolved (this time around, anyway :-). Raph From owner-ietf-smime Fri Apr 18 14:29:31 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA06800 for ietf-smime-bks; Fri, 18 Apr 1997 14:29:31 -0700 (PDT) Received: from netcomsv.netcom.com (uucp3.netcom.com [163.179.3.3]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA06796 for ; Fri, 18 Apr 1997 14:29:29 -0700 (PDT) Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id OAA11724; Fri, 18 Apr 1997 14:26:35 -0700 Received: from cc:Mail by spysouth.spyrus.com id AA861394913 Fri, 18 Apr 97 13:21:53 Date: Fri, 18 Apr 97 13:21:53 From: "Housley, Russ" Message-Id: <9703188613.AA861394913@spysouth.spyrus.com> To: ietf-smime@imc.org Subject: Re: The RC2 debate Sender: owner-ietf-smime@imc.org Precedence: bulk Paul E Hoffman wrote: > I'd like to second the motion to split the RC2/40 discussion > into two parts. Please note the subject of this part, and > reply with this subject if you want to talk about whether or > not the S/MIME spec should have a MUST or a SHOULD that > includes RC2 encryption. S/MIME MAY include RC2. RC2 should not be a MUST. From owner-ietf-smime Fri Apr 18 14:36:00 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA06871 for ietf-smime-bks; Fri, 18 Apr 1997 14:36:00 -0700 (PDT) Received: from netcomsv.netcom.com (uucp5.netcom.com [163.179.3.5]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA06866 for ; Fri, 18 Apr 1997 14:35:58 -0700 (PDT) Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id NAA19488; Fri, 18 Apr 1997 13:52:07 -0700 Received: from cc:Mail by spysouth.spyrus.com id AA861392896 Fri, 18 Apr 97 12:48:16 Date: Fri, 18 Apr 97 12:48:16 From: "Housley, Russ" Message-Id: <9703188613.AA861392896@spysouth.spyrus.com> To: ietf-smime@imc.org, Blake Ramsdell Subject: Re: Other exportable 40-bit algorithms Sender: owner-ietf-smime@imc.org Precedence: bulk All: I have just returned from a meeting with the Export Control office at NSA. I raised this question, and was encouraged by the reponse. It is possible for us to select another 40-bit algorithm (perhaps, DES-40 as suggested in a previous note by Dave Kemp), and get that algorithm approved for expedited export when it is used in conjunction with the our protocol. A similar arrangement has already been made concerning the algorithms used in the SET payment protocol. Russ ______________________________ Reply Separator _________________________________ Subject: Other exportable 40-bit algorithms Author: Blake Ramsdell at internet Date: 4/17/97 3:25 PM Is there any alternative to RC2 40-bit that meets US export requirements for symmetric algorithms, and does not require you to: 1. Wait an eternity for export approval 2. Register every sale of a product to a non-US/Canada company/individual with the government 3. Require you to implement escrow features in your product RC2 40-bit enjoys both an expedited export approval (I seem to remember ours being a month) and does not have the burden of reporting individual unit sales with the government. Is this true of CAST 40-bit or DES-40? Blake From owner-ietf-smime Fri Apr 18 15:37:10 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA07402 for ietf-smime-bks; Fri, 18 Apr 1997 15:37:10 -0700 (PDT) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA07391 for ; Fri, 18 Apr 1997 15:37:02 -0700 (PDT) Received: (from uucp@localhost) by out1.ibm.net (8.6.9/8.6.9) id WAA173599; Fri, 18 Apr 1997 22:37:51 GMT Received: from slip166-72-232-86.ny.us.ibm.net(166.72.232.86) by out1.ibm.net via smap (V1.3mjr) id smaM7QCrx; Fri Apr 18 22:37:30 1997 Received: (from uri@localhost) by alisan.ibm.net (8.7.6/8.7.3) id SAA05475; Fri, 18 Apr 1997 18:37:53 -0400 Date: Fri, 18 Apr 1997 18:37:53 -0400 Message-Id: <199704182237.SAA05475@alisan.ibm.net> From: Uri Blumenthal To: dpkemp@missi.ncsc.mil (David P. Kemp) Cc: ietf-smime@imc.org Subject: Re: Other exportable 40-bit algorithms In-Reply-To: <199704181339.JAA21904@argon.ncsc.mil> References: <199704181339.JAA21904@argon.ncsc.mil> Reply-To: NOSPAM!uri@ibm.net Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk >>>>> "David" == David P Kemp writes: David> Uri, Are you familiar enough with the SSL/TLS technique of David> creating export keys (hashing 40 secret bits with 88 salt David> bits) to state whether it is covered by the CDMF patent? Shame on me - no I am not familiar with how TLS is doing this. Also - I have learned tha common sense usually has little to do wrt. patent applicability. Not being a lawyer - I have no idea whatsoever, whether CDMF patent does or does not apply. Regards, [To reply, remove "NOSPAM!" from the Uri "Reply-To:" field] -=-=-==-=-=- uri@ibm.net From owner-ietf-smime Fri Apr 18 15:46:11 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA07467 for ietf-smime-bks; Fri, 18 Apr 1997 15:46:11 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA07460 for ; Fri, 18 Apr 1997 15:46:07 -0700 (PDT) Message-Id: In-Reply-To: <3357C832.37EC2D8F@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Apr 1997 15:51:03 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: Re: The 40-bit debate Sender: owner-ietf-smime@imc.org Precedence: bulk At 12:14 PM -0700 4/18/97, Raph Levien wrote: >Paul Hoffman writes: > >> It's clear to me that some people who are replying on this list haven't >> read the draft since they didn't know that the draft has two profiles, a >> "restricted" one that has 40-bit only and an "unrestricted" one that has >> both 40-bit and tripleDES. Section 2.6 of the draft clearly says when the >> restricted profile should be used, and that's pretty damn rarely. > >I have a few problems with this. 2.6.3 appears to give users the choice >between incurring the "risk of failed decryption" and defaulting to >RC2/40. Again, I'm not sure we can claim "interoperability" in the >former case. Note that a sender or receiver using the unrestricted profile MUST be able to encrypt *and* decrypt the restricted algorithm. (See the list at the beginning of Section 2.6.2.) Thus, interoperability is assured in 2.6.3, if and only if the unrestricted client really does do both halves of the restricted algorithm. >I don't mean to whine, but I am quite curious why my earlier proposal >(in which the default algorithm was dependent on the length of the >recipient's RSA key) was abandoned. This proposal maximized >interoperability in the case where one of the agents was restricted, yet >prevented RC2/40 from being the default choice in the case where neither >agents were restricted. This was my decision, and I'm willing to turn around an put it back in if the group wants it. The reason I took it out is that your heuristic is both time-dependant and law-dependant, and it seemed wrong to codify this in a long-lasting spec. - What if the US government starts allowing longer RSA keys but not stronger encryption algorithms? - What if the US government decides that 56 bit DES is OK, and allows slightly longer RSA keys to match? The current heuristic jumps from 40-bit RC/2 to full tripleDES. - What if some other government, using broken logic similar to the US, allows strong encryption algorithms but only shorter keys? Again, I'm open to arguments on putting the key-length heuristic back in, but I'd want to feel that the rules in the spec all would be valid five and maybe ten years from now. I'm also willing to put in other heuristics that we all think will pass the test of time. >Section 2.6.3.3 also invites protocol attacks: >. . . >It is not stated here how the sending agent should determine whether it >has receieved "at least one message from the recipient." Does it simply >use the e-mail address in the "From:" header field to identify the >sender? Or does it require a trusted signature as well? Good point. I'll rewrite this to state that only trusted signatures should be used to pass the test in this section. >Pardon me for being blunt, but from a user's perspective, having a >single protocol with two different profiles is no different from having >two different protocols. No need for pardon; in fact, I think thanks are in order. This is probably the most succint statement yet made on the issue. The protocols may have a high level of overlap, but they don't have interoperability, and are thus separate. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Fri Apr 18 21:21:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id VAA09902 for ietf-smime-bks; Fri, 18 Apr 1997 21:21:29 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id VAA09897; Fri, 18 Apr 1997 21:21:24 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id AAA04590; Sat, 19 Apr 1997 00:22:06 -0400 (EDT) Message-Id: <199704190422.AAA04590@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Paul E. Hoffman" cc: ietf-smime@imc.org, moore@cs.utk.edu Subject: Re: The 40-bit debate In-reply-to: Your message of "Fri, 18 Apr 1997 15:51:03 PDT." Date: Sat, 19 Apr 1997 00:22:06 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > >Pardon me for being blunt, but from a user's perspective, having a > >single protocol with two different profiles is no different from having > >two different protocols. > > No need for pardon; in fact, I think thanks are in order. This is probably > the most succint statement yet made on the issue. The protocols may have a > high level of overlap, but they don't have interoperability, and are thus > separate. Yep. That's the best way to think about it. Though if the two protocols share a lot of common code, it's clearly useful for products that want to implement both protocols. Keith From owner-ietf-smime Mon Apr 21 09:34:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA08589 for ietf-smime-bks; Mon, 21 Apr 1997 09:34:54 -0700 (PDT) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA08584 for ; Mon, 21 Apr 1997 09:34:50 -0700 (PDT) Received: from cbreed-5 ([205.180.137.52]) by fusebox.pgp.com (8.8.5/8.8.5) with SMTP id JAA21913 for ; Mon, 21 Apr 1997 09:35:50 -0700 (PDT) Message-Id: <3.0.32.19970421093952.009c1860@mail.pgp.com> X-Sender: cbreed@mail.pgp.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 21 Apr 1997 09:39:54 -0700 To: ietf-smime@imc.org From: Charles Breed Subject: S/MIME Export and the IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk "The IETF has to get out of two businesses: (1) worrying about the market share of a few U.S. software companies and (2) interpreting U.S. export control laws. With a strong-encyption S/MIME standard, U.S. developers will support S/MIME (strong) based upon a new IETF standard and international software developers will support the S/MIME (strong) based upon the same standard. On overseas versions, U.S. software companies can ship US/MIME (40-bit). If they're worried about losing market share, then they can build their client software with a universal API (or better yet, publish the source code) so that strong and weak crypto can both be supported. Thus, when you export the program with US/MIME only, overseas developers could develop and integrate code based on the strong S/MIME. So, you're so certain this would be non-exportable??? Why should the IETF be in the business of determining what's exportable? As someone here said, large U.S. corporations routinely get permission to export 128-bit encyption. U.S. companies can develop their own strong encyrption plug-ins to U.S. software company's client software and get permission to export strong encyption with no sweat. The Internet users are solving real intellectual property and trade secret problems and the U.S. government is fully cooperating with them. They could care less about the market share problems of U.S. software companies, who by the way, exist by virtue of these Internet users. Does the the IETF exist to solve the legal problems of a few U.S. software companies or are they trying to solve real problems that Internet users face every day??? The only course for the IETF is to just do what's technologically sound and let innovation and the marketplace take its course. Savvy U.S. software developers will build API's to their client software (or just distribute their source code, as any good cryptographic software should) and they and their legal advisers, not you or the IETF, will make the decision as to what's exportable. By requiring a proprietary algorithm or code, the IETF is in the business of enforcing export control laws AS THOSE LAWS ARE INTERPRETED BY THE OWNER OF THE PROPRIETATY ALGORITYHM OR CODE. It's about time this stops. Let's reflect upon the charter of the IETF and, if we remember that we're here for the end users and customers, we'll make the right decisions." Bob Kohn, VP Business Dev. PGP, Inc. kohn@pgp.com From owner-ietf-smime Mon Apr 21 10:30:56 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA09365 for ietf-smime-bks; Mon, 21 Apr 1997 10:30:56 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA09361 for ; Mon, 21 Apr 1997 10:30:53 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01IHT65CPRK099ETFU@INNOSOFT.COM> for ietf-smime@imc.org; Mon, 21 Apr 1997 10:31:07 PDT Date: Mon, 21 Apr 1997 10:17:51 -0700 (PDT) From: Ned Freed Subject: Re: S/MIME Export and the IETF In-reply-to: "Your message dated Mon, 21 Apr 1997 09:39:54 -0700" <3.0.32.19970421093952.009c1860@mail.pgp.com> To: Charles Breed Cc: ietf-smime@imc.org Message-id: <01IHYPVBXM4I99ETFU@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-smime@imc.org Precedence: bulk > "The IETF has to get out of two businesses: (1) worrying about the market > share of a few U.S. software companies and (2) interpreting U.S. export > control laws. Hear hear! Charles, I am in complete agreement with this, and moreover I would go so far as to recommend that any charter developed for an S/MIME working group place these concerns out of scope. As it happens I'm also a principal in a US software company that would very much like to be able to sell strong encryption to the 45% of our customer base that happens to be outside the US. And mandating strong encryption in S/MIME absolutely does hurt us in this regard. However, I am also able to separate what's good for the IETF as a whole from what is good for us as a business, and in my judgement what's good for the IETF isn't what's good for us, at least not in the short term, so mandatory strong encryption is what I think the IETF should mandate in S/MIME. This issue is entirely separate from the RC* issue, BTW. RC* with 256 bits of key is every bit as unacceptable as 40 bits is when it comes to IETF confidentiality rules. Ned From owner-ietf-smime Mon Apr 21 13:42:41 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA12409 for ietf-smime-bks; Mon, 21 Apr 1997 13:42:41 -0700 (PDT) Received: from service.esys.ca (root@service.esys.ca [141.118.1.124]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA12405 for ; Mon, 21 Apr 1997 13:42:38 -0700 (PDT) Received: from monet.esys.ca by service.esys.ca with smtp (Smail3.1.28.1 #1) id m0wJPyw-000UnnC; Mon, 21 Apr 97 14:46 MDT Received: from benhur.esys.ca by monet.esys.ca with smtp (Smail3.1.28.1 #6) id m0wJPyG-000RVMC; Mon, 21 Apr 97 14:45 MDT From: Steve Hole Reply-To: ietf-smime@imc.org To: ietf-smime@imc.org Subject: Re: The RC2 debate Message-ID: Date: Mon, 21 Apr 1997 14:43:56 -0600 (MDT) X-Mailer: Simeon for Win32 Version 4.1.1b3 Build (8) X-Authentication: none MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk It seems pretty clear to me. Both Jeff Schiller and Keith Moore have stated categorically that RC2, because of its "trade secret" status is not an acceptible algorithm for an IETF standards track document. They get to decide on that particular issue. I am fully in agreement with them on this issue. Given a willingness to move ahead, the 5 options listed by Ned are now reduced to two options: > (1) Drop any trade secret claims for the algorithms used in S/MIME. > > (2) Completely remove them from the S/MIME standard-to-be. It isn't a > question of whether or not it can be required -- in point of fact > you cannot mention these algorithms at all. The ball is clearly in RSA's court. Will you or will you not relinquish the trade secret status on RC2. The only possible answers to this question are "YES" or "NO". If the answer is no, then it cannot be included in an IETF standards track document. Once we hear officially from RSA on this issue, we can proceed. --- Steve Hole VP, Research and Development The Esys Corporation EMail: steve@esys.ca 900 10040 - 104 St. Phone: 403-424-4922 Edmonton, AB, Canada Fax: 403-424-4925 T5J 0Z6 From owner-ietf-smime Mon Apr 21 13:52:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA12490 for ietf-smime-bks; Mon, 21 Apr 1997 13:52:16 -0700 (PDT) Received: from netcomsv.netcom.com (uucp5.netcom.com [163.179.3.5]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA12486 for ; Mon, 21 Apr 1997 13:52:14 -0700 (PDT) Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id MAA10113; Mon, 21 Apr 1997 12:14:22 -0700 Received: from cc:Mail by spysouth.spyrus.com id AA861641200 Mon, 21 Apr 97 09:46:40 Date: Mon, 21 Apr 97 09:46:40 From: "Housley, Russ" Message-Id: <9703218616.AA861641200@spysouth.spyrus.com> To: ietf-smime@imc.org, Raph Levien Subject: Re: The 40-bit debate Sender: owner-ietf-smime@imc.org Precedence: bulk Raph Levien said: I should clarify one other point: even listing at least one exportable algorithm as MUST won't guarantee full interoperability. The remaining issue is RSA key length. Unless something happened to the export regs that I'm not aware of, US-export software is still restricted to 512-bit RSA keys. Therefore, this software won't recognize signatures made with unrestricted software, and can't be used to send encrypted messages to unrestricted agents. I'm not sure whether this is still interoperability or not (I'm not trying to be funny here - I think the underlying problem is that we haven't agreed on exactly what "interoperability" means). The key sizes associated with signatures are not controlled. The vendor must show that the signature cannot be used for key management, but once this easy task is accomplished, there are no controlls on signature mechanisms. Russ From owner-ietf-smime Mon Apr 21 14:07:17 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA12687 for ietf-smime-bks; Mon, 21 Apr 1997 14:07:17 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA12682 for ; Mon, 21 Apr 1997 14:07:13 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC4E5D.7491D290@cane.deming.com>; Mon, 21 Apr 1997 14:08:15 -0700 Message-ID: From: Blake Ramsdell To: "'Ned Freed'" , "'Charles Breed'" Cc: "'ietf-smime@imc.org'" Subject: RE: S/MIME Export and the IETF Date: Mon, 21 Apr 1997 14:08:13 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk And so Steve was right: "The goals of the IETF are out of step with US companies' business needs". I don't know why anyone ever debated it. The only thing that was ever in scope for me was the interoperability of any two implementations of S/MIME. That's it. The MUST for RC2 40-bit / whatever 40-bit is only to accomplish that goal. I don't know why I have trouble getting this across. Bob, you should get your own email address sometime :). Blake >-----Original Message----- >From: Ned Freed [SMTP:Ned.Freed@innosoft.com] >Sent: Monday, April 21, 1997 10:18 AM >To: Charles Breed >Cc: ietf-smime@imc.org >Subject: Re: S/MIME Export and the IETF > >> "The IETF has to get out of two businesses: (1) worrying about the market >> share of a few U.S. software companies and (2) interpreting U.S. export >> control laws. > >Hear hear! Charles, I am in complete agreement with this, and moreover I >would go so far as to recommend that any charter developed for an S/MIME >working group place these concerns out of scope. > >As it happens I'm also a principal in a US software company that would very >much like to be able to sell strong encryption to the 45% of our customer >base >that happens to be outside the US. And mandating strong encryption in S/MIME >absolutely does hurt us in this regard. However, I am also able to separate >what's good for the IETF as a whole from what is good for us as a business, >and >in my judgement what's good for the IETF isn't what's good for us, at least >not >in the short term, so mandatory strong encryption is what I think the IETF >should mandate in S/MIME. > >This issue is entirely separate from the RC* issue, BTW. RC* with 256 bits >of key is every bit as unacceptable as 40 bits is when it comes to IETF >confidentiality rules. > > Ned From owner-ietf-smime Mon Apr 21 15:38:39 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA13568 for ietf-smime-bks; Mon, 21 Apr 1997 15:38:39 -0700 (PDT) Received: from cs20.cs.auckland.ac.nz (root@cs20.cs.auckland.ac.nz [130.216.34.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA13564 for ; Mon, 21 Apr 1997 15:38:35 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz by cs20.cs.auckland.ac.nz (8.8.3/4.7) id KAA17316; Tue, 22 Apr 1997 10:39:32 +1200 (NZST) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <86166237022725>; Tue, 22 Apr 1997 10:39:30 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org Subject: Re: The RC2 debate Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Tue, 22 Apr 1997 10:39:30 (NZST) Message-ID: <86166237022725@cs26.cs.auckland.ac.nz> Sender: owner-ietf-smime@imc.org Precedence: bulk >It seems pretty clear to me. Both Jeff Schiller and Keith Moore have stated acceptible algorithm for an IETF standards track document. They get to >decide on that particular issue. I am fully in agreement with them on this >issue. I don't know if RSADSI can still claim this to be a trade secret. Because of the questionable status of RC4, the release of RC2 was handled very carefully to make sure it was a genuine clean-room copy, and the whole process was very publicly documented to ensure it could be verified by anyone. First an RC2 implementation was reverse-engineered, then a text-only specification of the algorithm was written by someone on the other side of the planet, and finally a third person (back on the other side of the planet again) who had never seen the reverse-engineerd RC2 code wrote a new implementation based entirely on the text-only specification. The entire process was documented in postings to sci.crypt. Although IANAL, from what I've read of reverse-engineering this should be good enough to withstand scrutiny - in any case a reasonably sizeable non-US company which is using the code has had their lawyers look at it briefly and is confident they'll win any legal challenge, at least based on EU laws which AFAIK are mostly the same as US ones in this regard. Peter. From owner-ietf-smime Tue Apr 22 14:52:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA29828 for ietf-smime-bks; Tue, 22 Apr 1997 14:52:35 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA29824 for ; Tue, 22 Apr 1997 14:52:32 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id RAA08277; Tue, 22 Apr 1997 17:53:26 -0400 (EDT) Message-Id: <199704222153.RAA08277@ig.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: pgut001@cs.auckland.ac.nz cc: ietf-smime@imc.org, moore@cs.utk.edu Subject: Re: The RC2 debate In-reply-to: Your message of "Tue, 22 Apr 1997 10:39:30." <86166237022725@cs26.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Apr 1997 17:53:26 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > I don't know if RSADSI can still claim this to be a trade secret. We still have to have a spec that can be referenced. I personally don't care who wrote the spec, as long as it's published, widely available, and the community agrees that it's good enough to use. Keith From owner-ietf-smime Tue Apr 22 15:03:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA29992 for ietf-smime-bks; Tue, 22 Apr 1997 15:03:14 -0700 (PDT) Received: from cs20.cs.auckland.ac.nz (root@cs20.cs.auckland.ac.nz [130.216.34.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA29987 for ; Tue, 22 Apr 1997 15:03:10 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz by cs20.cs.auckland.ac.nz (8.8.3/4.7) id KAA06053; Wed, 23 Apr 1997 10:04:06 +1200 (NZST) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <86174664502203>; Wed, 23 Apr 1997 10:04:05 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: moore@cs.utk.edu Subject: Re: The RC2 debate Cc: ietf-smime@imc.org Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Wed, 23 Apr 1997 10:04:05 (NZST) Message-ID: <86174664502203@cs26.cs.auckland.ac.nz> Sender: owner-ietf-smime@imc.org Precedence: bulk >We still have to have a spec that can be referenced. > >I personally don't care who wrote the spec, as long as it's published, >widely available, and the community agrees that it's good enough to use. Do a DejaNews search for the subject "Specification for Ron Rivests Cipher No.2" (I didn't call it RC2 :-) posted to sci.crypt on 11 Feb 1996, message-ID <4fk39f$f70@net.auckland.ac.nz>. This has also ended up on a number of FTP sites, and I've seen it on at least one CDROM archive. I assume that's enough to qualify it as "widely published". Peter. From owner-ietf-smime Tue Apr 22 15:39:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA00570 for ietf-smime-bks; Tue, 22 Apr 1997 15:39:54 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA00564 for ; Tue, 22 Apr 1997 15:39:50 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id SAA08482; Tue, 22 Apr 1997 18:40:45 -0400 (EDT) Message-Id: <199704222240.SAA08482@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: pgut001@cs.auckland.ac.nz cc: moore@cs.utk.edu, ietf-smime@imc.org Subject: Re: The RC2 debate In-reply-to: Your message of "Wed, 23 Apr 1997 10:04:05." <86174664502203@cs26.cs.auckland.ac.nz> Date: Tue, 22 Apr 1997 18:40:45 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > Do a DejaNews search for the subject "Specification for Ron Rivests Cipher > No.2" (I didn't call it RC2 :-) posted to sci.crypt on 11 Feb 1996, > message-ID <4fk39f$f70@net.auckland.ac.nz>. This has also ended up on a > number of FTP sites, and I've seen it on at least one CDROM archive. > I assume that's enough to qualify it as "widely published". No, I don't think so. Neither random FTP sites nor a CDROM archive give me any confidence that the specification will be widely available for a reasonable amount of time. Keith From owner-ietf-smime Tue Apr 22 15:24:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA00365 for ietf-smime-bks; Tue, 22 Apr 1997 15:24:18 -0700 (PDT) Received: from cs20.cs.auckland.ac.nz (root@cs20.cs.auckland.ac.nz [130.216.34.10]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA00361 for ; Tue, 22 Apr 1997 15:24:14 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz by cs20.cs.auckland.ac.nz (8.8.3/4.7) id KAA13628; Wed, 23 Apr 1997 10:25:14 +1200 (NZST) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <86174791403985>; Wed, 23 Apr 1997 10:25:14 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org Subject: Re: The RC2 debate Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Wed, 23 Apr 1997 10:25:14 (NZST) Message-ID: <86174791403985@cs26.cs.auckland.ac.nz> Sender: owner-ietf-smime@imc.org Precedence: bulk Since I've had several requests and questions about this (and I'll probably never hear the end of it otherwise), here's the RC2 clean-room stuff including the spec. Peter. -- The original message, from a source in the Netherlands -- Newsgroups: sci.crypt From: anon-remailer@utopia.hacktic.nl (Anonymous) Subject: RC2 source code Date: 29 Jan 1996 06:38:04 +0100 Organization: Hack-Tic International, Inc. Message-ID: <4ehmfs$6nq@utopia.hacktic.nl> [Reverse-engineered RC2 code] -- My spec for RRC.2, from New Zealand -- Newsgroups: sci.crypt From: pgut01@cs.auckland.ac.nz (Peter Gutmann) Subject: Specification for Ron Rivests Cipher No.2 Date: 11 Feb 1996 06:45:03 GMT Organization: University of Auckland Message-ID: <4fk39f$f70@net.auckland.ac.nz> Ron Rivest's Cipher No.2 ------------------------ Ron Rivest's Cipher No.2 (hereafter referred to as RRC.2, other people may refer to it by other names) is word oriented, operating on a block of 64 bits divided into four 16-bit words, with a key table of 64 words. All data units are little-endian. This functional description of the algorithm is based in the paper "The RC5 Encryption Algorithm" (RC5 is a trademark of RSADSI), using the same general layout, terminology, and pseudocode style. Notation and RRC.2 Primitive Operations RRC.2 uses the following primitive operations: 1. Two's-complement addition of words, denoted by "+". The inverse operation, subtraction, is denoted by "-". 2. Bitwise exclusive OR, denoted by "^". 3. Bitwise AND, denoted by "&". 4. Bitwise NOT, denoted by "~". 5. A left-rotation of words; the rotation of word x left by y is denoted x <<< y. The inverse operation, right-rotation, is denoted x >>> y. These operations are directly and efficiently supported by most processors. The RRC.2 Algorithm RRC.2 consists of three components, a *key expansion* algorithm, an *encryption* algorithm, and a *decryption* algorithm. Key Expansion The purpose of the key-expansion routine is to expand the user's key K to fill the expanded key array S, so S resembles an array of random binary words determined by the user's secret key K. Initialising the S-box RRC.2 uses a single 256-byte S-box derived from the ciphertext contents of Beale Cipher No.1 XOR'd with a one-time pad. The Beale Ciphers predate modern cryptography by enough time that there should be no concerns about trapdoors hidden in the data. They have been published widely, and the S-box can be easily recreated from the one-time pad values and the Beale Cipher data taken from a standard source. To initialise the S-box: for i = 0 to 255 do sBox[ i ] = ( beale[ i ] mod 256 ) ^ pad[ i ] The contents of Beale Cipher No.1 and the necessary one-time pad are given as an appendix at the end of this document. For efficiency, implementors may wish to skip the Beale Cipher expansion and store the sBox table directly. Expanding the Secret Key to 128 Bytes The secret key is first expanded to fill 128 bytes (64 words). The expansion consists of taking the sum of the first and last bytes in the user key, looking up the sum (modulo 256) in the S-box, and appending the result to the key. The operation is repeated with the second byte and new last byte of the key until all 128 bytes have been generated. Note that the following pseudocode treats the S array as an array of 128 bytes rather than 64 words. for j = 0 to length-1 do S[ j ] = K[ j ] for j = length to 127 do s[ j ] = sBox[ ( S[ j-length ] + S[ j-1 ] ) mod 256 ]; At this point it is possible to perform a truncation of the effective key length to ease the creation of espionage-enabled software products. However since the author cannot conceive why anyone would want to do this, it will not be considered further. The final phase of the key expansion involves replacing the first byte of S with the entry selected from the S-box: S[ 0 ] = sBox[ S[ 0 ] ] Encryption The cipher has 16 full rounds, each divided into 4 subrounds. Two of the full rounds perform an additional transformation on the data. Note that the following pseudocode treats the S array as an array of 64 words rather than 128 bytes. for i = 0 to 15 do j = i * 4; word0 = ( word0 + ( word1 & ~word3 ) + ( word2 & word3 ) + S[ j+0 ] ) <<< 1 word1 = ( word1 + ( word2 & ~word0 ) + ( word3 & word0 ) + S[ j+1 ] ) <<< 2 word2 = ( word2 + ( word3 & ~word1 ) + ( word0 & word1 ) + S[ j+2 ] ) <<< 3 word3 = ( word3 + ( word0 & ~word2 ) + ( word1 & word2 ) + S[ j+3 ] ) <<< 5 In addition the fifth and eleventh rounds add the contents of the S-box indexed by one of the data words to another of the data words following the four subrounds as follows: word0 = word0 + S[ word3 & 63 ]; word1 = word1 + S[ word0 & 63 ]; word2 = word2 + S[ word1 & 63 ]; word3 = word3 + S[ word2 & 63 ]; Decryption The decryption operation is simply the inverse of the encryption operation. Note that the following pseudocode treats the S array as an array of 64 words rather than 128 bytes. for i = 15 downto 0 do j = i * 4; word3 = ( word3 >>> 5 ) - ( word0 & ~word2 ) - ( word1 & word2 ) - S[ j+3 ] word2 = ( word2 >>> 3 ) - ( word3 & ~word1 ) - ( word0 & word1 ) - S[ j+2 ] word1 = ( word1 >>> 2 ) - ( word2 & ~word0 ) - ( word3 & word0 ) - S[ j+1 ] word0 = ( word0 >>> 1 ) - ( word1 & ~word3 ) - ( word2 & word3 ) - S[ j+0 ] In addition the fifth and eleventh rounds subtract the contents of the S-box indexed by one of the data words from another one of the data words following the four subrounds as follows: word3 = word3 - S[ word2 & 63 ] word2 = word2 - S[ word1 & 63 ] word1 = word1 - S[ word0 & 63 ] word0 = word0 - S[ word3 & 63 ] Test Vectors The following test vectors may be used to test the correctness of an RRC.2 implementation: Key: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 Plain: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 Cipher: 0x1C, 0x19, 0x8A, 0x83, 0x8D, 0xF0, 0x28, 0xB7 Key: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 Plain: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 Cipher: 0x21, 0x82, 0x9C, 0x78, 0xA9, 0xF9, 0xC0, 0x74 Key: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 Plain: 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF Cipher: 0x13, 0xDB, 0x35, 0x17, 0xD3, 0x21, 0x86, 0x9E Key: 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F Plain: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 Cipher: 0x50, 0xDC, 0x01, 0x62, 0xBD, 0x75, 0x7F, 0x31 Appendix: Beale Cipher No.1, "The Locality of the Vault", and One-time Pad for Creating the S-Box Beale Cipher No.1. 71, 194, 38,1701, 89, 76, 11, 83,1629, 48, 94, 63, 132, 16, 111, 95, 84, 341, 975, 14, 40, 64, 27, 81, 139, 213, 63, 90,1120, 8, 15, 3, 126,2018, 40, 74, 758, 485, 604, 230, 436, 664, 582, 150, 251, 284, 308, 231, 124, 211, 486, 225, 401, 370, 11, 101, 305, 139, 189, 17, 33, 88, 208, 193, 145, 1, 94, 73, 416, 918, 263, 28, 500, 538, 356, 117, 136, 219, 27, 176, 130, 10, 460, 25, 485, 18, 436, 65, 84, 200, 283, 118, 320, 138, 36, 416, 280, 15, 71, 224, 961, 44, 16, 401, 39, 88, 61, 304, 12, 21, 24, 283, 134, 92, 63, 246, 486, 682, 7, 219, 184, 360, 780, 18, 64, 463, 474, 131, 160, 79, 73, 440, 95, 18, 64, 581, 34, 69, 128, 367, 460, 17, 81, 12, 103, 820, 62, 110, 97, 103, 862, 70, 60,1317, 471, 540, 208, 121, 890, 346, 36, 150, 59, 568, 614, 13, 120, 63, 219, 812,2160,1780, 99, 35, 18, 21, 136, 872, 15, 28, 170, 88, 4, 30, 44, 112, 18, 147, 436, 195, 320, 37, 122, 113, 6, 140, 8, 120, 305, 42, 58, 461, 44, 106, 301, 13, 408, 680, 93, 86, 116, 530, 82, 568, 9, 102, 38, 416, 89, 71, 216, 728, 965, 818, 2, 38, 121, 195, 14, 326, 148, 234, 18, 55, 131, 234, 361, 824, 5, 81, 623, 48, 961, 19, 26, 33, 10,1101, 365, 92, 88, 181, 275, 346, 201, 206 One-time Pad. 158, 186, 223, 97, 64, 145, 190, 190, 117, 217, 163, 70, 206, 176, 183, 194, 146, 43, 248, 141, 3, 54, 72, 223, 233, 153, 91, 210, 36, 131, 244, 161, 105, 120, 113, 191, 113, 86, 19, 245, 213, 221, 43, 27, 242, 157, 73, 213, 193, 92, 166, 10, 23, 197, 112, 110, 193, 30, 156, 51, 125, 51, 158, 67, 197, 215, 59, 218, 110, 246, 181, 0, 135, 76, 164, 97, 47, 87, 234, 108, 144, 127, 6, 6, 222, 172, 80, 144, 22, 245, 207, 70, 227, 182, 146, 134, 119, 176, 73, 58, 135, 69, 23, 198, 0, 170, 32, 171, 176, 129, 91, 24, 126, 77, 248, 0, 118, 69, 57, 60, 190, 171, 217, 61, 136, 169, 196, 84, 168, 167, 163, 102, 223, 64, 174, 178, 166, 239, 242, 195, 249, 92, 59, 38, 241, 46, 236, 31, 59, 114, 23, 50, 119, 186, 7, 66, 212, 97, 222, 182, 230, 118, 122, 86, 105, 92, 179, 243, 255, 189, 223, 164, 194, 215, 98, 44, 17, 20, 53, 153, 137, 224, 176, 100, 208, 114, 36, 200, 145, 150, 215, 20, 87, 44, 252, 20, 235, 242, 163, 132, 63, 18, 5, 122, 74, 97, 34, 97, 142, 86, 146, 221, 179, 166, 161, 74, 69, 182, 88, 120, 128, 58, 76, 155, 15, 30, 77, 216, 165, 117, 107, 90, 169, 127, 143, 181, 208, 137, 200, 127, 170, 195, 26, 84, 255, 132, 150, 58, 103, 250, 120, 221, 237, 37, 8, 99 Implementation A non-US based programmer who has never seen any encryption code before will shortly be implementing RRC.2 based solely on this specification and not on knowledge of any other encryption algorithms. Stand by. -- The announcement of the clean-room version, from Germany -- Newsgroups: sci.crypt From: daniel@rama.informatik.rwth-aachen.de (Daniel Vogelheim) Subject: RRC.2 implementation available Date: 18 Feb 1996 01:06:08 GMT Organization: RWTH -Aachen / Rechnerbetrieb Informatik Message-ID: <4g5u20$e4k@news.rwth-aachen.de> Hi, I have implemented the RRC.2 cipher and want to make it available to anybody interested. Since I am new to cryptography the code probably isn't of high quality by professional measures, though. (I plan to improve it as I learn.) [...] I'd like to emphasize that the code was written entirely from the spec posted by Peter Gutmann. I have never seen code of any RSA cipher, including "RC2". I am living, working and programming in the Federal Repulic of Germany, which is neither a part of the United States of America nor subject to the latter's legislation or jurisdiction. I wish you all the best, Daniel Vogelheim [There have been further clean-room versions based on my spec, including the one in SSLeay (written in Australia) and apparently one from Finland. Take your pick...] From owner-ietf-smime Tue Apr 22 20:57:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id UAA04197 for ietf-smime-bks; Tue, 22 Apr 1997 20:57:16 -0700 (PDT) Received: from tumbleweed1.tumbleweed.com ([207.220.220.4]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id UAA04193 for ; Tue, 22 Apr 1997 20:57:13 -0700 (PDT) Received: from jeff.tumbleweed.com ([204.30.67.88]) by tumbleweed1.tumbleweed.com (post.office MTA v1.9.1 ID# 0-11773) with SMTP id AAA116; Tue, 22 Apr 1997 20:56:52 -0700 Message-Id: <3.0.32.19970422205647.006bdff0@mail.tumbleweed.com> X-Sender: jeff@mail.tumbleweed.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 22 Apr 1997 20:56:49 -0700 To: pgut001@cs.auckland.ac.nz, ietf-smime@imc.org From: jeff@tumbleweed.com (Jeff Smith) Subject: Re: The RC2 debate Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk Although the analogy is not completely relevant, note that LZW was published everywhere before Unisys decided to extract royalties for any use of the algorithm. Yes, a patent applied to LZW... Also, clean rooms don't always yield the desired results. For example, ask AMD whether Intel was satisfied. >From my perspective the only truly clean solution is for RSA to open up RC2. Otherwise, there is risk, the algo remains proprietary, and it simply should not be included in the specification. -- jeff At 10:25 AM 4/23/97, Peter Gutmann wrote: >Since I've had several requests and questions about this (and I'll probably >never hear the end of it otherwise), here's the RC2 clean-room stuff including >the spec. > >Peter. > >-- The original message, from a source in the Netherlands -- > >Newsgroups: sci.crypt >From: anon-remailer@utopia.hacktic.nl (Anonymous) >Subject: RC2 source code >Date: 29 Jan 1996 06:38:04 +0100 >Organization: Hack-Tic International, Inc. >Message-ID: <4ehmfs$6nq@utopia.hacktic.nl> > >[Reverse-engineered RC2 code] > >-- My spec for RRC.2, from New Zealand -- > >Newsgroups: sci.crypt >From: pgut01@cs.auckland.ac.nz (Peter Gutmann) >Subject: Specification for Ron Rivests Cipher No.2 >Date: 11 Feb 1996 06:45:03 GMT >Organization: University of Auckland >Message-ID: <4fk39f$f70@net.auckland.ac.nz> > > Ron Rivest's Cipher No.2 > ------------------------ > >Ron Rivest's Cipher No.2 (hereafter referred to as RRC.2, other people may >refer to it by other names) is word oriented, operating on a block of 64 bits >divided into four 16-bit words, with a key table of 64 words. All data units >are little-endian. This functional description of the algorithm is based in >the paper "The RC5 Encryption Algorithm" (RC5 is a trademark of RSADSI), using >the same general layout, terminology, and pseudocode style. > > >Notation and RRC.2 Primitive Operations > >RRC.2 uses the following primitive operations: > >1. Two's-complement addition of words, denoted by "+". The inverse operation, > subtraction, is denoted by "-". >2. Bitwise exclusive OR, denoted by "^". >3. Bitwise AND, denoted by "&". >4. Bitwise NOT, denoted by "~". >5. A left-rotation of words; the rotation of word x left by y is denoted > x <<< y. The inverse operation, right-rotation, is denoted x >>> y. > >These operations are directly and efficiently supported by most processors. > > >The RRC.2 Algorithm > >RRC.2 consists of three components, a *key expansion* algorithm, an >*encryption* algorithm, and a *decryption* algorithm. > > >Key Expansion > >The purpose of the key-expansion routine is to expand the user's key K to fill >the expanded key array S, so S resembles an array of random binary words >determined by the user's secret key K. > >Initialising the S-box > >RRC.2 uses a single 256-byte S-box derived from the ciphertext contents of >Beale Cipher No.1 XOR'd with a one-time pad. The Beale Ciphers predate modern >cryptography by enough time that there should be no concerns about trapdoors >hidden in the data. They have been published widely, and the S-box can be >easily recreated from the one-time pad values and the Beale Cipher data taken >from a standard source. To initialise the S-box: > > for i = 0 to 255 do > sBox[ i ] = ( beale[ i ] mod 256 ) ^ pad[ i ] > >The contents of Beale Cipher No.1 and the necessary one-time pad are given as >an appendix at the end of this document. For efficiency, implementors may wish >to skip the Beale Cipher expansion and store the sBox table directly. > >Expanding the Secret Key to 128 Bytes > >The secret key is first expanded to fill 128 bytes (64 words). The expansion >consists of taking the sum of the first and last bytes in the user key, looking >up the sum (modulo 256) in the S-box, and appending the result to the key. The >operation is repeated with the second byte and new last byte of the key until >all 128 bytes have been generated. Note that the following pseudocode treats >the S array as an array of 128 bytes rather than 64 words. > > for j = 0 to length-1 do > S[ j ] = K[ j ] > for j = length to 127 do > s[ j ] = sBox[ ( S[ j-length ] + S[ j-1 ] ) mod 256 ]; > >At this point it is possible to perform a truncation of the effective key >length to ease the creation of espionage-enabled software products. However >since the author cannot conceive why anyone would want to do this, it will not >be considered further. > >The final phase of the key expansion involves replacing the first byte of S >with the entry selected from the S-box: > > S[ 0 ] = sBox[ S[ 0 ] ] > > >Encryption > >The cipher has 16 full rounds, each divided into 4 subrounds. Two of the full >rounds perform an additional transformation on the data. Note that the >following pseudocode treats the S array as an array of 64 words rather than 128 >bytes. > > for i = 0 to 15 do > j = i * 4; > word0 = ( word0 + ( word1 & ~word3 ) + ( word2 & word3 ) + S[ j+0 ] ) <<< 1 > word1 = ( word1 + ( word2 & ~word0 ) + ( word3 & word0 ) + S[ j+1 ] ) <<< 2 > word2 = ( word2 + ( word3 & ~word1 ) + ( word0 & word1 ) + S[ j+2 ] ) <<< 3 > word3 = ( word3 + ( word0 & ~word2 ) + ( word1 & word2 ) + S[ j+3 ] ) <<< 5 > >In addition the fifth and eleventh rounds add the contents of the S-box indexed >by one of the data words to another of the data words following the four >subrounds as follows: > > word0 = word0 + S[ word3 & 63 ]; > word1 = word1 + S[ word0 & 63 ]; > word2 = word2 + S[ word1 & 63 ]; > word3 = word3 + S[ word2 & 63 ]; > > >Decryption > >The decryption operation is simply the inverse of the encryption operation. >Note that the following pseudocode treats the S array as an array of 64 words >rather than 128 bytes. > > for i = 15 downto 0 do > j = i * 4; > word3 = ( word3 >>> 5 ) - ( word0 & ~word2 ) - ( word1 & word2 ) - S[ j+3 ] > word2 = ( word2 >>> 3 ) - ( word3 & ~word1 ) - ( word0 & word1 ) - S[ j+2 ] > word1 = ( word1 >>> 2 ) - ( word2 & ~word0 ) - ( word3 & word0 ) - S[ j+1 ] > word0 = ( word0 >>> 1 ) - ( word1 & ~word3 ) - ( word2 & word3 ) - S[ j+0 ] > >In addition the fifth and eleventh rounds subtract the contents of the S-box >indexed by one of the data words from another one of the data words following >the four subrounds as follows: > > word3 = word3 - S[ word2 & 63 ] > word2 = word2 - S[ word1 & 63 ] > word1 = word1 - S[ word0 & 63 ] > word0 = word0 - S[ word3 & 63 ] > > >Test Vectors > >The following test vectors may be used to test the correctness of an RRC.2 >implementation: > > Key: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 > Plain: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 > Cipher: 0x1C, 0x19, 0x8A, 0x83, 0x8D, 0xF0, 0x28, 0xB7 > > Key: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 > Plain: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 > Cipher: 0x21, 0x82, 0x9C, 0x78, 0xA9, 0xF9, 0xC0, 0x74 > > Key: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 > Plain: 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF > Cipher: 0x13, 0xDB, 0x35, 0x17, 0xD3, 0x21, 0x86, 0x9E > > Key: 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, > 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F > Plain: 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 > Cipher: 0x50, 0xDC, 0x01, 0x62, 0xBD, 0x75, 0x7F, 0x31 > > >Appendix: Beale Cipher No.1, "The Locality of the Vault", and One-time Pad for > Creating the S-Box > >Beale Cipher No.1. > > 71, 194, 38,1701, 89, 76, 11, 83,1629, 48, 94, 63, 132, 16, 111, 95, > 84, 341, 975, 14, 40, 64, 27, 81, 139, 213, 63, 90,1120, 8, 15, 3, > 126,2018, 40, 74, 758, 485, 604, 230, 436, 664, 582, 150, 251, 284, 308, 231, > 124, 211, 486, 225, 401, 370, 11, 101, 305, 139, 189, 17, 33, 88, 208, 193, > 145, 1, 94, 73, 416, 918, 263, 28, 500, 538, 356, 117, 136, 219, 27, 176, > 130, 10, 460, 25, 485, 18, 436, 65, 84, 200, 283, 118, 320, 138, 36, 416, > 280, 15, 71, 224, 961, 44, 16, 401, 39, 88, 61, 304, 12, 21, 24, 283, > 134, 92, 63, 246, 486, 682, 7, 219, 184, 360, 780, 18, 64, 463, 474, 131, > 160, 79, 73, 440, 95, 18, 64, 581, 34, 69, 128, 367, 460, 17, 81, 12, > 103, 820, 62, 110, 97, 103, 862, 70, 60,1317, 471, 540, 208, 121, 890, 346, > 36, 150, 59, 568, 614, 13, 120, 63, 219, 812,2160,1780, 99, 35, 18, 21, > 136, 872, 15, 28, 170, 88, 4, 30, 44, 112, 18, 147, 436, 195, 320, 37, > 122, 113, 6, 140, 8, 120, 305, 42, 58, 461, 44, 106, 301, 13, 408, 680, > 93, 86, 116, 530, 82, 568, 9, 102, 38, 416, 89, 71, 216, 728, 965, 818, > 2, 38, 121, 195, 14, 326, 148, 234, 18, 55, 131, 234, 361, 824, 5, 81, > 623, 48, 961, 19, 26, 33, 10,1101, 365, 92, 88, 181, 275, 346, 201, 206 > >One-time Pad. > > 158, 186, 223, 97, 64, 145, 190, 190, 117, 217, 163, 70, 206, 176, 183, 194, > 146, 43, 248, 141, 3, 54, 72, 223, 233, 153, 91, 210, 36, 131, 244, 161, > 105, 120, 113, 191, 113, 86, 19, 245, 213, 221, 43, 27, 242, 157, 73, 213, > 193, 92, 166, 10, 23, 197, 112, 110, 193, 30, 156, 51, 125, 51, 158, 67, > 197, 215, 59, 218, 110, 246, 181, 0, 135, 76, 164, 97, 47, 87, 234, 108, > 144, 127, 6, 6, 222, 172, 80, 144, 22, 245, 207, 70, 227, 182, 146, 134, > 119, 176, 73, 58, 135, 69, 23, 198, 0, 170, 32, 171, 176, 129, 91, 24, > 126, 77, 248, 0, 118, 69, 57, 60, 190, 171, 217, 61, 136, 169, 196, 84, > 168, 167, 163, 102, 223, 64, 174, 178, 166, 239, 242, 195, 249, 92, 59, 38, > 241, 46, 236, 31, 59, 114, 23, 50, 119, 186, 7, 66, 212, 97, 222, 182, > 230, 118, 122, 86, 105, 92, 179, 243, 255, 189, 223, 164, 194, 215, 98, 44, > 17, 20, 53, 153, 137, 224, 176, 100, 208, 114, 36, 200, 145, 150, 215, 20, > 87, 44, 252, 20, 235, 242, 163, 132, 63, 18, 5, 122, 74, 97, 34, 97, > 142, 86, 146, 221, 179, 166, 161, 74, 69, 182, 88, 120, 128, 58, 76, 155, > 15, 30, 77, 216, 165, 117, 107, 90, 169, 127, 143, 181, 208, 137, 200, 127, > 170, 195, 26, 84, 255, 132, 150, 58, 103, 250, 120, 221, 237, 37, 8, 99 > > >Implementation > >A non-US based programmer who has never seen any encryption code before will >shortly be implementing RRC.2 based solely on this specification and not on >knowledge of any other encryption algorithms. Stand by. > >-- The announcement of the clean-room version, from Germany -- > >Newsgroups: sci.crypt >From: daniel@rama.informatik.rwth-aachen.de (Daniel Vogelheim) >Subject: RRC.2 implementation available >Date: 18 Feb 1996 01:06:08 GMT >Organization: RWTH -Aachen / Rechnerbetrieb Informatik >Message-ID: <4g5u20$e4k@news.rwth-aachen.de> > >Hi, > >I have implemented the RRC.2 cipher and want to make it available to anybody >interested. Since I am new to cryptography the code probably isn't of high >quality by professional measures, though. (I plan to improve it as I learn.) > >[...] > >I'd like to emphasize that the code was written entirely from the spec posted >by Peter Gutmann. I have never seen code of any RSA cipher, including "RC2". I >am living, working and programming in the Federal Repulic of Germany, which is >neither a part of the United States of America nor subject to the latter's >legislation or jurisdiction. > >I wish you all the best, > >Daniel Vogelheim > >[There have been further clean-room versions based on my spec, including the > one in SSLeay (written in Australia) and apparently one from Finland. Take > your pick...] > > From owner-ietf-smime Tue Apr 22 23:00:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA05158 for ietf-smime-bks; Tue, 22 Apr 1997 23:00:20 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA05154 for ; Tue, 22 Apr 1997 23:00:17 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01II02HD9VU899ETFU@INNOSOFT.COM> for ietf-smime@imc.org; Tue, 22 Apr 1997 23:01:12 PDT Date: Tue, 22 Apr 1997 22:23:21 -0700 (PDT) From: Ned Freed Subject: Re: The RC2 debate In-reply-to: "Your message dated Tue, 22 Apr 1997 18:40:45 -0400" <199704222240.SAA08482@ig.cs.utk.edu> To: Keith Moore Cc: pgut001@cs.auckland.ac.nz, moore@cs.utk.edu, ietf-smime@imc.org Message-id: <01II0UDMRV5A99ETFU@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <86174664502203@cs26.cs.auckland.ac.nz> Sender: owner-ietf-smime@imc.org Precedence: bulk > > Do a DejaNews search for the subject "Specification for Ron Rivests Cipher > > No.2" (I didn't call it RC2 :-) posted to sci.crypt on 11 Feb 1996, > > message-ID <4fk39f$f70@net.auckland.ac.nz>. This has also ended up on a > > number of FTP sites, and I've seen it on at least one CDROM archive. > > I assume that's enough to qualify it as "widely published". > No, I don't think so. Neither random FTP sites nor a CDROM archive give > me any confidence that the specification will be widely available for a > reasonable amount of time. And it is totally irrelevant anyway. The stated position of RSA here, which has in fact been posted to this list by RSA representatives, is that they believe this algorithm is still covered by trade secret rules. This means that confidentiality restrictions may still apply, a zillion postings to various newsgroups notwithstanding. And this in turn means that it is a nonstarter as far as the IETF is concerned. Again, the IETF rules concerning this could not be any clearer. More specifically, my understanding of RSA's claim is that they believe all published descriptions of RC2 have been arrived at by reverse engineering code covered by a license that forbids such reverse engineering. The question of whether the "chinese wall" or "clean room" approach that was used is sufficient to invalidate RSA's claims is something that only a court case can decide -- until that happens and RSA is successfully challenged in court and the trade secret status of RC2 is invalidated their position is what counts. Moreover, since trade secret law varies somewhat from one jurisdiction to another, it is even possible that a single successful challenge would be insufficient to invalidate all their claims (and this supposed they would lose, which is far from obvious to me). Finally, I would not recommend that anyone get their hopes over such a challenge ever actually happening. At present RSA clearly believes that maintaining trade secret status is important. As such, if they were ever placed in a position where they would be likely to lose their trade secret status through a legal challenge they would probably simply agree to a license for less than the challenge is going to cost the challenger. And putting on my corporate officer hat for a moment, it is unlikely that a company, especially a public one, would ever turn down such a deal. Companies, even private ones, have a fiduciary responsibility to their stockholders. They do not have a responsibility to engage in expensive legal actions to prove a point, even when those actions are clearly for the good of the community. Ned From owner-ietf-smime Wed Apr 23 00:14:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id AAA05881 for ietf-smime-bks; Wed, 23 Apr 1997 00:14:47 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id AAA05877 for ; Wed, 23 Apr 1997 00:14:44 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id DAA09971; Wed, 23 Apr 1997 03:15:35 -0400 (EDT) Message-Id: <199704230715.DAA09971@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ned Freed cc: Keith Moore , pgut001@cs.auckland.ac.nz, ietf-smime@imc.org Subject: Re: The RC2 debate In-reply-to: Your message of "Tue, 22 Apr 1997 22:23:21 PDT." <01II0UDMRV5A99ETFU@INNOSOFT.COM> Date: Wed, 23 Apr 1997 03:15:35 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > And it is totally irrelevant anyway. The stated position of RSA here, > which has in fact been posted to this list by RSA representatives, is > that they believe this algorithm is still covered by trade secret rules. I for one don't really care whether RSA thinks that RC2 is a trade secret. (or for that matter, what RSA's reasoning is) Just because RSA has an opinion doesn't mean IETF is bound by it. What IETF cares about is that the algorithm is a published standard (either de facto or de jure), and that the technology is available under reasonable and nondiscriminatory terms. If RSA publishes the algorithm, fine; if the algorithm is published by somebody else, fine. But it does have to be published. If this WG can't find a RC2 specification to reference, it needs to use some other symmetric encryption algorithm. (And IMHO it shouldn't waste any more time waiting for RSA to make up its mind...RSA has had plenty of time to publish RC2 if it wants to do that.) > This means that confidentiality restrictions may still apply, a zillion > postings to various newsgroups notwithstanding. And this in turn means > that it is a nonstarter as far as the IETF is concerned. Again, the > IETF rules concerning this could not be any clearer. IETF rules are very clear: we don't take any position as to the validity of anybody else's intellectual property claims. Keith From owner-ietf-smime Wed Apr 23 05:39:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id FAA10177 for ietf-smime-bks; Wed, 23 Apr 1997 05:39:23 -0700 (PDT) Received: from data.dilkie.com ([206.51.1.169]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id FAA10173 for ; Wed, 23 Apr 1997 05:39:19 -0700 (PDT) Received: from GRANNY by data.dilkie.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id JP2BM7LN; Wed, 23 Apr 1997 08:40:21 -0400 Received: by bwdldb.ott.bnr.ca with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC4FC0.A8777F10@bwdldb.ott.bnr.ca>; Wed, 23 Apr 1997 08:30:53 -0400 Message-ID: From: Peter Whittaker To: "'Ned Freed'" , "'Keith Moore'" Cc: "'pgut001@cs.auckland.ac.nz'" , "'ietf-smime@imc.org'" Subject: RE: The RC2 debate Date: Wed, 23 Apr 1997 08:29:22 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Sender: owner-ietf-smime@imc.org Precedence: bulk >> And it is totally irrelevant anyway. The stated position of RSA here, >> which has in fact been posted to this list by RSA representatives, is >> that they believe this algorithm is still covered by trade secret rules. > >I for one don't really care whether RSA thinks that RC2 is a trade secret. >(or for that matter, what RSA's reasoning is) >Just because RSA has an opinion doesn't mean IETF is bound by it. > >What IETF cares about is that the algorithm is a published standard >(either de facto or de jure), and that the technology is available >under reasonable and nondiscriminatory terms. > >If RSA publishes the algorithm, fine; if the algorithm is published by >somebody else, fine. But it does have to be published. If this WG >can't find a RC2 specification to reference, it needs to use some >other symmetric encryption algorithm. (And IMHO it shouldn't waste any >more time waiting for RSA to make up its mind...RSA has had plenty of time >to publish RC2 if it wants to do that.) The IETF does care: they require that the owners of any licensed, patented, or otherwise restrictively controlled technologies release those technologies for use by the IETF. Having one party publish an informational RFC that allows others to implement a technology owned by another party would be wildly irreponsible (as the owner could sue the IETF in all probability, along with the RFC author), and would not allow the IETF or anyone else to use the technology, as it would still be owned by the owner. When licensed technologies are involved, the IETF requires that the owners of the technology make it available, somehow. Take a look at the release in RFC 1319: License to use MD2 is granted for non-commerical Internet Privacy-Enhanced Mail. On the other hand, MD4 (1320) and MD5 (1321) are placed in the public domain. In this case, the IETF can only consider algorithms for which exist appropriate informational RFCs documenting the algorithm and releasing it for use within the IETF (or for broader use). pww From owner-ietf-smime Wed Apr 23 06:45:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id GAA10909 for ietf-smime-bks; Wed, 23 Apr 1997 06:45:29 -0700 (PDT) Received: from guardian.guard.ncsc.mil (guardian.guard.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id GAA10905 for ; Wed, 23 Apr 1997 06:45:26 -0700 (PDT) Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id JAA25082 for ; Wed, 23 Apr 1997 09:46:12 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma025080; Wed Apr 23 09:45:47 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id JAA15589 for ; Wed, 23 Apr 1997 09:42:53 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id JAA26221; Wed, 23 Apr 1997 09:45:19 -0400 Date: Wed, 23 Apr 1997 09:45:19 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199704231345.JAA26221@argon.ncsc.mil> To: ietf-smime@imc.org Subject: Re: The RC2 debate X-Sun-Charset: US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk > From: Keith Moore > > > And it is totally irrelevant anyway. The stated position of RSA here, > > which has in fact been posted to this list by RSA representatives, is > > that they believe this algorithm is still covered by trade secret rules. > > I for one don't really care whether RSA thinks that RC2 is a trade secret. > (or for that matter, what RSA's reasoning is) > Just because RSA has an opinion doesn't mean IETF is bound by it. > > What IETF cares about is that the algorithm is a published standard > (either de facto or de jure), and that the technology is available > under reasonable and nondiscriminatory terms. What the IETF cares about is that proprietary algorithms not be REQUIRED, or even mentioned, in Standards Track specifications when suitable non-proprietary alternatives are available. Freely-available symmetric algorithms exist in abundance, hence RC2 does not belong in the IETF-S/MIME Standard. Implementors of IETF-S/MIME software are always free to also implement RC2, using either licensed or unlicensed code, over and above the requirements of the IETF specification. Many of them probably will, for backward interoperability. Regardless of the legal standing of the clean-room implementation, regardless of the existence of a published specification for RC2 (as an Information RFC, for example), there will always be the the threat of legal action unless RSA changes it's position. The IETF's agnosticism on the validity of the claims is irrelevant - RSA's opinion, valid or not, is what counts. Ned Freed's superlative analysis should be the last word on this issue. How could anyone read it and not be convinced? From owner-ietf-smime Wed Apr 23 09:45:13 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA13751 for ietf-smime-bks; Wed, 23 Apr 1997 09:45:13 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA13743 for ; Wed, 23 Apr 1997 09:45:10 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01II02HD9VU899ETFU@INNOSOFT.COM> for ietf-smime@imc.org; Wed, 23 Apr 1997 09:45:14 PDT Date: Wed, 23 Apr 1997 09:15:35 -0700 (PDT) From: Ned Freed Subject: Re: The RC2 debate In-reply-to: "Your message dated Wed, 23 Apr 1997 03:15:35 -0400" <199704230715.DAA09971@ig.cs.utk.edu> To: Keith Moore Cc: Ned Freed , Keith Moore , pgut001@cs.auckland.ac.nz, ietf-smime@imc.org Message-id: <01II1GV3007K99ETFU@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: <01II0UDMRV5A99ETFU@INNOSOFT.COM> Sender: owner-ietf-smime@imc.org Precedence: bulk > > And it is totally irrelevant anyway. The stated position of RSA here, > > which has in fact been posted to this list by RSA representatives, is > > that they believe this algorithm is still covered by trade secret rules. > I for one don't really care whether RSA thinks that RC2 is a trade secret. > (or for that matter, what RSA's reasoning is) > Just because RSA has an opinion doesn't mean IETF is bound by it. > What IETF cares about is that the algorithm is a published standard > (either de facto or de jure), and that the technology is available > under reasonable and nondiscriminatory terms. Keith, I'm afraid I must disagree with you on this. Again I cite the IETF rules published in RFC2026, specifically section 10.2: 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. A claim of a trade secret is at its core a claim of confidentiality, and RC2 is claimed to be a trade secret. As such, 10.2 applies and we cannot use RC2 in an Internet standard unless its status changes. > If RSA publishes the algorithm, fine; if the algorithm is published by > somebody else, fine. But it does have to be published. If this WG > can't find a RC2 specification to reference, it needs to use some > other symmetric encryption algorithm. (And IMHO it shouldn't waste any > more time waiting for RSA to make up its mind...RSA has had plenty of time > to publish RC2 if it wants to do that.) Again I have to disagree. Publication is not the issue here, the issue is RSA's claim to a confidentiality requirement that covers RC2. As long as such a claim exists we cannot use RC2, period. > > This means that confidentiality restrictions may still apply, a zillion > > postings to various newsgroups notwithstanding. And this in turn means > > that it is a nonstarter as far as the IETF is concerned. Again, the > > IETF rules concerning this could not be any clearer. > IETF rules are very clear: we don't take any position as to the validity > of anybody else's intellectual property claims. Exactly, and this is the entire point. Since the IETF isn't in the business of assessing the validity of IP claims it has no choice but to treat the RSA claims as potentially valid. The underlying problem here seems to be that you think this rule means we can ignore IP issues entirely. It doesn't say this at all. The validity rule is there to keep us out of IP disputes and to keep IP issues out of our technical decision-making process to the greatest extent possible. And when it comes to patents this works quite well, since most patents carry with them no confidentiality restrictions (NSA patents are an exception, BTW.) and by being able to ignore patent status we get to pick the best technology to solve a given problem. But in the case of trade secrets confidentiality restrictions exist as well, and the existance of such absolutely does cause interference in the technical decision-making process. As this has been dealt with by saying that such restrictions cannnot exist for standardized technology. I'd like to expand on the last point a bit because it happens to provide a sound technical basis for rejecting RC2 as well as the more obvious rule-based one. Specifically, the ongoing efforts of RSA to keep the details of RC2 (and to a lesser extent RC4) secret have had a chilling effort on analysis of these algorithms in the cryptographic community. Simply put, I know of the existance of no cryptographic results for RC2 (and precious few for RC4). Now, when it comes to cryptographic algorithms, it is almost axiomatic that trust only comes after careful scrutiny. And while Ron Rivest is a highly competent cryptographer with excellent credentials, he nevertheless could have made some mistake in the design of RC2. And if I put on my mathematician hat for a moment, I'm also uncomfortable with some of the design elements in RC2; the S-box seems a bit small given that it is initialized more or less at random. Others have pointed out that there isn't exactly a shortage of unencumbered symmetric key algorithms, algorithms that have been cryptanalyzed extensively and have withstood the best efforts of the community for many years. It will years before RC2 attains this status, assuming it ever does. As such, there is also a sound technical reason for rejecting RC2 as the algorithm for use in S/MIME. Ned From owner-ietf-smime Wed Apr 23 11:03:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA15088 for ietf-smime-bks; Wed, 23 Apr 1997 11:03:19 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA15083 for ; Wed, 23 Apr 1997 11:03:16 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id OAA13943; Wed, 23 Apr 1997 14:03:46 -0400 (EDT) Message-Id: <199704231803.OAA13943@ig.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Peter Whittaker cc: "'Ned Freed'" , "'Keith Moore'" , "'pgut001@cs.auckland.ac.nz'" , "'ietf-smime@imc.org'" Subject: Re: The RC2 debate In-reply-to: Your message of "Wed, 23 Apr 1997 08:29:22 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Apr 1997 14:03:46 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > The IETF does care: they require that the owners of any licensed, > patented, or otherwise restrictively controlled technologies release > those technologies for use by the IETF. Nope. IETF will *ask* them to agree to license it fairly, but *does not* require them to do so. A standards-track protocol can use technology that is subject to IPR claims, even absent such a license, if the concensus is to use that technology. On the other hand, if the technology (for whatever reason) doesn't get consensus of the community, it doesn't get used in a standards-track protocol. See RFC 2026 for the definitive statements. Keith From owner-ietf-smime Wed Apr 23 11:13:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA15296 for ietf-smime-bks; Wed, 23 Apr 1997 11:13:42 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA15290 for ; Wed, 23 Apr 1997 11:13:38 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01II1JJZ7O9S99G41T@INNOSOFT.COM> for ietf-smime@imc.org; Wed, 23 Apr 1997 11:14:28 PDT Date: Wed, 23 Apr 1997 11:06:35 -0700 (PDT) From: Ned Freed Subject: Re: The RC2 debate In-reply-to: "Your message dated Wed, 23 Apr 1997 13:58:32 -0400" <199704231758.NAA12097@ig.cs.utk.edu> To: Keith Moore Cc: Ned Freed , Keith Moore , pgut001@cs.auckland.ac.nz, ietf-smime@imc.org Message-id: <01II1JYS2SP099G41T@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <01II1GV3007K99ETFU@INNOSOFT.COM> Sender: owner-ietf-smime@imc.org Precedence: bulk Keith, I think you're still missing the point I'm trying to make. You say: > Section 10.2, as it applies to RC2, basically means that IETF can't > reference RC2 in a standards-track protocol *if that reference* is > subject to confidentiality restrictions. The point is that RSA has claimed that any such reference *is* subject to confidentiality restrictions. And you yourself have asserted that the IETF cannot judge the merit of such a claim. As such, you have no choice but to treat it as valid. > So if an IETF WG wants to > use RC2, it has to find a specification for that algorithm which is > not subject to such restrictions. RSA claims that this is flatly impossible to do. > > Again I have to disagree. Publication is not the issue here, the > > issue is RSA's claim to a confidentiality requirement that covers > > RC2. As long as such a claim exists we cannot use RC2, period. > I think we do disagree here. But I for one won't object to use of RC2 > as long as the S/MIME specification can reference a published > specification which is available to anyone. Keith, I don't mean to be unfriendly, but this is an absolute showstopper as far as I'm concerned. So let me be blunt. I believe that progressing a standard with a RC2 reference in it is a formal violation of IETF rules as long the status claimed by RSA doesn't change. And this is one rule I happen to believe must be enforced for the good of the IETF. I also believe I have backed this up with language from the applicable procedures in force today and that your reading of the procedures is entirely specious. As such, I will vociferously object to such a reference every step of the way through the process, and if it the IESG sees fit to approve such a specification in spite of my objections I will file a formal appeal with the IAB, which I believe I will win. Ned From owner-ietf-smime Wed Apr 23 10:57:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA14982 for ietf-smime-bks; Wed, 23 Apr 1997 10:57:54 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA14978 for ; Wed, 23 Apr 1997 10:57:51 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id NAA12097; Wed, 23 Apr 1997 13:58:32 -0400 (EDT) Message-Id: <199704231758.NAA12097@ig.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ned Freed cc: Keith Moore , pgut001@cs.auckland.ac.nz, ietf-smime@imc.org Subject: Re: The RC2 debate In-reply-to: Your message of "Wed, 23 Apr 1997 09:15:35 PDT." <01II1GV3007K99ETFU@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Apr 1997 13:58:32 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > > What IETF cares about is that the algorithm is a published standard > > (either de facto or de jure), and that the technology is available > > under reasonable and nondiscriminatory terms. > > Keith, I'm afraid I must disagree with you on this. Again I cite the > IETF rules published in RFC2026, specifically section 10.2: > > 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. yes, but section 10.3.2 also says: 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. So: a. 10.3.2(B) says that even if RSA claims they have a trade secret, IETF will take no position on whether that claim is valid. b. 10.3.2(A) says that if RSA informs the IESG that IETF's referencing somebody else's RC2 spec is a violation of their intellectual property rights, the IESG will duly note RSA's claim in any RFCs that reference that RC2 spec. c. 10.3.2(C) says that if RSA does claim rights, IETF will try to get them to agree to license the technology under fair terms, but whether such a license is granted DOES NOT prevent the advancement of the document along the standards track. Note however that as a practical matter, if working group members believe -- for whatever reason -- that a technology is too encumbered, that algorithm might not gain consensus support for the group. > A claim of a trade secret is at its core a claim of confidentiality, and > RC2 is claimed to be a trade secret. As such, 10.2 applies and we cannot > use RC2 in an Internet standard unless its status changes. Nope. The IETF stays out of the business of deciding whether the claim has merit. Again, individuals in the community can have their own opinions, and if enough of those opinions are against using RC2, it will be difficult for RC2 to get the consensus it needs to be part of an Internet standards-track protocol. But those individuals don't have to agree on the reason for supporting or not supporting RC2. Section 10.2, as it applies to RC2, basically means that IETF can't reference RC2 in a standards-track protocol *if that reference* is subject to confidentiality restrictions. So if an IETF WG wants to use RC2, it has to find a specification for that algorithm which is not subject to such restrictions. > > If RSA publishes the algorithm, fine; if the algorithm is published by > > somebody else, fine. But it does have to be published. If this WG > > can't find a RC2 specification to reference, it needs to use some > > other symmetric encryption algorithm. (And IMHO it shouldn't waste any > > more time waiting for RSA to make up its mind...RSA has had plenty of time > > to publish RC2 if it wants to do that.) > > Again I have to disagree. Publication is not the issue here, the > issue is RSA's claim to a confidentiality requirement that covers > RC2. As long as such a claim exists we cannot use RC2, period. I think we do disagree here. But I for one won't object to use of RC2 as long as the S/MIME specification can reference a published specification which is available to anyone. > > IETF rules are very clear: we don't take any position as to the validity > > of anybody else's intellectual property claims. > > Exactly, and this is the entire point. Since the IETF isn't in the > business of assessing the validity of IP claims it has no choice > but to treat the RSA claims as potentially valid. "I don't think that means what you think it means"... though I don't think I can state things more clearly than section 10.3.2 of RFC 2026. > Specifically, the ongoing efforts of RSA to keep the details of RC2 > (and to a lesser extent RC4) secret have had a chilling effort on > analysis of these algorithms in the cryptographic community. Simply > put, I know of the existance of no cryptographic results for RC2 > (and precious few for RC4). Now, when it comes to cryptographic > algorithms, it is almost axiomatic that trust only comes after > careful scrutiny. And while Ron Rivest is a highly competent > cryptographer with excellent credentials, he nevertheless could have > made some mistake in the design of RC2. And if I put on my > mathematician hat for a moment, I'm also uncomfortable with some of > the design elements in RC2; the S-box seems a bit small given that > it is initialized more or less at random. Yes, these are indeed problems. But it's up to the community to decide whether an algorithm is suitable for a particular purpose. Keith From owner-ietf-smime Wed Apr 23 11:43:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA15791 for ietf-smime-bks; Wed, 23 Apr 1997 11:43:23 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA15787 for ; Wed, 23 Apr 1997 11:43:20 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id OAA23858; Wed, 23 Apr 1997 14:44:17 -0400 (EDT) Message-Id: <199704231844.OAA23858@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ned Freed cc: Keith Moore , pgut001@cs.auckland.ac.nz, ietf-smime@imc.org Subject: Re: The RC2 debate In-reply-to: Your message of "Wed, 23 Apr 1997 11:06:35 PDT." <01II1JYS2SP099G41T@INNOSOFT.COM> Date: Wed, 23 Apr 1997 14:44:17 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk Ned, This is how I interpret RFC 2026, and this is where I will draw the line on process grounds. I've seen nothing in our recent discussion that would cause me to change my interpretation. Takiing no position on the validity of IPR claims is not tantamount to treating any trade secret claim as if it were valid. The whole intent of the wording in 2026 is to take most IPR-related decisions out of the realm of process, and put them in the hands of the individuals in the community to be decided on a case-by-case basis. As far as I can tell, this is the most effective and reasonable way of dealing with the IPR mess (disaster would be a better word) which has ever been devised by a standards body...but only time will tell. Of course, IF the working group is approved, and IF the working group reaches consensus to use RC2, and IF the specification passes the IESG, you're free to appeal that decision. From a practical point-of-view, I have a hard time that the document will get that far without RSA's cooperation...not to mention yours. Keith From owner-ietf-smime Wed Apr 23 11:51:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA15947 for ietf-smime-bks; Wed, 23 Apr 1997 11:51:37 -0700 (PDT) Received: from blacklodge.c2.net (blacklodge.c2.net [208.139.36.35]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id LAA15943 for ; Wed, 23 Apr 1997 11:51:34 -0700 (PDT) Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id LAA01424; Wed, 23 Apr 1997 11:52:02 -0700 (PDT) Date: Wed, 23 Apr 1997 11:52:02 -0700 (PDT) From: Raph Levien X-Sender: raph@blacklodge.c2.net To: Ned Freed cc: Keith Moore , pgut001@cs.auckland.ac.nz, ietf-smime@imc.org Subject: Re: The RC2 debate In-Reply-To: <01II1JYS2SP099G41T@INNOSOFT.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk I don't believe it's possible that RSA can both assert RC2 as a trade secret and have it considered in an IETF standard. Section 10.2 is RFC 2026 is clear and unambiguous to me. However, another section of RFC 2026 also seems relevant. Paragraph 5 of section 10.3 is even clearer and more unambiguous: > 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. As far as I can see, this absolutely decides the issue. For RC2 to be considered, RSA must agree that it is not confidential. Can there be any other interpretation? Raph From owner-ietf-smime Wed Apr 23 12:05:18 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA16148 for ietf-smime-bks; Wed, 23 Apr 1997 12:05:18 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA16144 for ; Wed, 23 Apr 1997 12:05:15 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id PAA29462; Wed, 23 Apr 1997 15:05:41 -0400 (EDT) Message-Id: <199704231905.PAA29462@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Raph Levien cc: Ned Freed , Keith Moore , pgut001@cs.auckland.ac.nz, ietf-smime@imc.org Subject: Re: The RC2 debate In-reply-to: Your message of "Wed, 23 Apr 1997 11:52:02 PDT." Date: Wed, 23 Apr 1997 15:05:41 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > As far as I can see, this absolutely decides the issue. For RC2 to be > considered, RSA must agree that it is not confidential. Can there be any > other interpretation? Yes. The specification can come from somewhere other than RSA. RSA can complain "but that's *our* protocol", and IETF will duly record that complaint, but that by itself won't stop IETF from considering whether to use it. To me the more interesting question is: assuming a working group received assurance from IESG that it would be allowed to publish an S/MIME spec that referenced someone else's RC2 specification, would it be able to reach consensus that this was the Right Thing to do? Keith From owner-ietf-smime Wed Apr 23 14:38:01 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA19163 for ietf-smime-bks; Wed, 23 Apr 1997 14:38:01 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA19150 for ; Wed, 23 Apr 1997 14:37:25 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id RAA23455; Wed, 23 Apr 1997 17:38:23 -0400 (EDT) Message-Id: <199704232138.RAA23455@ig.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: dpkemp@missi.ncsc.mil (David P. Kemp) cc: ietf-smime@imc.org, moore@cs.utk.edu Subject: Re: The RC2 debate In-reply-to: Your message of "Wed, 23 Apr 1997 09:45:19 EDT." <199704231345.JAA26221@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Apr 1997 17:38:23 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > What the IETF cares about is that proprietary algorithms not be > REQUIRED, or even mentioned, in Standards Track specifications when > suitable non-proprietary alternatives are available. Freely-available > symmetric algorithms exist in abundance, hence RC2 does not belong in the > IETF-S/MIME Standard. The specific language is at the end of section 7.1.2 in RFC 2026: The IESG generally should not favor a particular proprietary specification over technically equivalent and competing specification(s) by making any incorporated vendor specification "required" or "recommended". Note that this constrains the IESG, not an IETF working group, and it has to do with whether the IESG should recommend or require one technology over another, not whether a technology can be placed on the standards-track. (Note also that it says "generally should not", not "must not".) IETF process rules do not prevent a working group from choosing a proprietary technology, even when non-proprietary alternatives are available. Instead, we trust the working groups to make informed and intelligent choices based on all appropriate criteria -- not just on whether someone claims that a technology is their property. > Regardless of the legal standing of the clean-room implementation, > regardless of the existence of a published specification for RC2 (as an > Information RFC, for example), there will always be the the threat of > legal action unless RSA changes it's position. The IETF's agnosticism > on the validity of the claims is irrelevant - RSA's opinion, valid or > not, is what counts. This may indeed be what counts in the minds of some working group participants, and such individual considerations may have an effect on the group's consensus. Keith From owner-ietf-smime Wed Apr 23 18:39:22 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA22180 for ietf-smime-bks; Wed, 23 Apr 1997 18:39:22 -0700 (PDT) Received: from out2.ibm.net (out2.ibm.net [165.87.201.252]) by mail.proper.com (8.8.5/8.7.3) with SMTP id SAA22175 for ; Wed, 23 Apr 1997 18:39:16 -0700 (PDT) Received: (from uucp@localhost) by out2.ibm.net (8.6.9/8.6.9) id BAA402314; Thu, 24 Apr 1997 01:40:17 GMT Received: from slip166-72-232-200.ny.us.ibm.net(166.72.232.200) by out2.ibm.net via smap (V1.3mjr) id smaFEYDmb; Thu Apr 24 01:39:59 1997 Received: (from uri@localhost) by alisan.ibm.net (8.7.6/8.7.3) id VAA00321; Wed, 23 Apr 1997 21:40:34 -0400 Date: Wed, 23 Apr 1997 21:40:34 -0400 Message-Id: <199704240140.VAA00321@alisan.ibm.net> From: Uri Blumenthal To: Ned Freed Cc: Keith Moore , ietf-smime@imc.org Subject: Re: The RC2 debate In-Reply-To: <01II1JYS2SP099G41T@INNOSOFT.COM> References: <01II1GV3007K99ETFU@INNOSOFT.COM> <199704231758.NAA12097@ig.cs.utk.edu> <01II1JYS2SP099G41T@INNOSOFT.COM> Reply-To: NOSPAM!uri@ibm.net Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk Ned, count me in. I fully support your strong position. Regards, [To reply, remove "NOSPAM!" from the Uri "Reply-To:" field] -=-=-==-=-=- uri@ibm.net From owner-ietf-smime Wed Apr 23 18:47:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA22242 for ietf-smime-bks; Wed, 23 Apr 1997 18:47:16 -0700 (PDT) Received: from out2.ibm.net (out2.ibm.net [165.87.201.252]) by mail.proper.com (8.8.5/8.7.3) with SMTP id SAA22238 for ; Wed, 23 Apr 1997 18:47:14 -0700 (PDT) Received: (from uucp@localhost) by out2.ibm.net (8.6.9/8.6.9) id BAA532177 for ; Thu, 24 Apr 1997 01:48:21 GMT Received: from slip166-72-232-200.ny.us.ibm.net(166.72.232.200) by out2.ibm.net via smap (V1.3mjr) id smawGkCkR; Thu Apr 24 01:47:56 1997 Received: (from uri@localhost) by alisan.ibm.net (8.7.6/8.7.3) id VAA00323; Wed, 23 Apr 1997 21:48:46 -0400 Date: Wed, 23 Apr 1997 21:48:46 -0400 Message-Id: <199704240148.VAA00323@alisan.ibm.net> From: Uri Blumenthal To: ietf-smime@imc.org Subject: Re: The RC2 debate In-Reply-To: <199704231905.PAA29462@ig.cs.utk.edu> References: <199704231905.PAA29462@ig.cs.utk.edu> Reply-To: NOSPAM!uri@ibm.net Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk >>>>> "Keith" == Keith Moore writes: Keith> RSA can complain "but that's *our* protocol", and IETF will Keith> duly record that complaint, but that by itself won't stop Keith> IETF from considering whether to use it. Childish. It's not RSA complaining "it's our protocol" that people are concerned about - it's the threat of a lawsuit targeting anyone who's IMPLEMENTING this as you say "protocol" without RSADSI license. Keith> To me the more interesting question is: assuming a working Keith> group received assurance from IESG that it would be allowed Keith> to publish an S/MIME spec that referenced someone else's Keith> RC2 specification, would it be able to reach consensus that Keith> this was the Right Thing to do? Sure, as long as IESG assures the WG that it will pay for a lawyer to defend an implementor of this "published spec" from a lawsuit by the RSA. There is no reason to lock ourselves up in the proprietary ****. Also, as I said, I follow Ned on this all the way. To IAB, if needed. Regards, [To reply, remove "NOSPAM!" from the Uri "Reply-To:" field] -=-=-==-=-=- uri@ibm.net From owner-ietf-smime Thu Apr 24 13:32:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA07059 for ietf-smime-bks; Thu, 24 Apr 1997 13:32:07 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id NAA07054 for ; Thu, 24 Apr 1997 13:32:02 -0700 (PDT) Received: from spot.cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id QAA03472; Thu, 24 Apr 1997 16:32:33 -0400 (EDT) Message-Id: <199704242032.QAA03472@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: uri@ibm.net cc: ietf-smime@imc.org Subject: Re: The RC2 debate In-reply-to: Your message of "Wed, 23 Apr 1997 21:48:46 EDT." <199704240148.VAA00323@alisan.ibm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Apr 1997 16:32:32 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > Keith> RSA can complain "but that's *our* protocol", and IETF will > Keith> duly record that complaint, but that by itself won't stop > Keith> IETF from considering whether to use it. > > Childish. Call it whatever you like, but that's what RFC 2026 says. I strongly suspect that people are missing my point, but I'm tired of trying to explain it. So I'll stop. If you want further clarification, ask me in private mail. Keith From owner-ietf-smime Thu Apr 24 15:32:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA08574 for ietf-smime-bks; Thu, 24 Apr 1997 15:32:37 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA08570 for ; Thu, 24 Apr 1997 15:32:34 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC50C4.E9C07E90@cane.deming.com>; Thu, 24 Apr 1997 15:33:52 -0700 Message-ID: From: Blake Ramsdell To: "'Ned Freed'" , "'Keith Moore'" Cc: "'Keith Moore'" , "'pgut001@cs.auckland.ac.nz'" , "'ietf-smime@imc.org'" Subject: RE: The RC2 debate Date: Thu, 24 Apr 1997 15:33:51 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk On Wednesday, April 23, 1997 11:07 AM, Ned Freed [SMTP:Ned.Freed@innosoft.com] wrote: > Keith, I don't mean to be unfriendly, but this is an absolute showstopper as > far as I'm concerned. So let me be blunt. I believe that progressing a > standard > with a RC2 reference in it is a formal violation of IETF rules as long the > status claimed by RSA doesn't change. And this is one rule I happen to > believe > must be enforced for the good of the IETF. I also believe I have backed this > up > with language from the applicable procedures in force today and that your > reading of the procedures is entirely specious. I don't understand -- the mere *mention* of RC2 in any IETF standard document will cause you to be all cranky? I suppose what you mean is that if RC2 is a MUST then you will be all cranky. I think this is an important distinction, so I'd like to get clarification on it. Blake From owner-ietf-smime Thu Apr 24 23:22:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id XAA12740 for ietf-smime-bks; Thu, 24 Apr 1997 23:22:06 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id XAA12736 for ; Thu, 24 Apr 1997 23:22:04 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01II3MVKKS8G99G095@INNOSOFT.COM> for ietf-smime@imc.org; Thu, 24 Apr 1997 23:22:14 PDT Date: Thu, 24 Apr 1997 23:16:25 -0700 (PDT) From: Ned Freed Subject: RE: The RC2 debate In-reply-to: "Your message dated Thu, 24 Apr 1997 15:33:51 -0700" To: Blake Ramsdell Cc: "'Ned Freed'" , "'Keith Moore'" , "'pgut001@cs.auckland.ac.nz'" , "'ietf-smime@imc.org'" Message-id: <01II3NOEFZVI99G095@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-smime@imc.org Precedence: bulk > On Wednesday, April 23, 1997 11:07 AM, Ned Freed > [SMTP:Ned.Freed@innosoft.com] wrote: > > Keith, I don't mean to be unfriendly, but this is an absolute showstopper as > > far as I'm concerned. So let me be blunt. I believe that progressing a > > standard > > with a RC2 reference in it is a formal violation of IETF rules as long the > > status claimed by RSA doesn't change. And this is one rule I happen to > > believe > > must be enforced for the good of the IETF. I also believe I have backed this > > up > > with language from the applicable procedures in force today and that your > > reading of the procedures is entirely specious. > I don't understand -- the mere *mention* of RC2 in any IETF standard > document will cause you to be all cranky? Yes. My position is that RC2 cannot even be an optional part of the specification unless it is released from trade secret restrictions. As a trade secret the most it can be is an informational part of the specification, and preferably in a separate, informational document. I believe this is what RFC2026 requires. (I also understand Keith's argument on this point -- I just happen to believe his analysis is totally incorrect.) > I suppose what you mean is > that if RC2 is a MUST then you will be all cranky. I think this is an > important distinction, so I'd like to get clarification on it. Nope, that is not what I mean. Ned P.S. I am also somewhat offended by your dismissive term "cranky" here. There are sound technical and procedural reasons for the position I've taken here. From owner-ietf-smime Fri Apr 25 11:31:54 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id LAA01234 for ietf-smime-bks; Fri, 25 Apr 1997 11:31:54 -0700 (PDT) Received: from out1.ibm.net (out1.ibm.net [165.87.194.252]) by mail.proper.com (8.8.5/8.7.3) with SMTP id LAA01230 for ; Fri, 25 Apr 1997 11:31:46 -0700 (PDT) Received: (from uucp@localhost) by out1.ibm.net (8.6.9/8.6.9) id SAA176864; Fri, 25 Apr 1997 18:32:44 GMT Received: from unknown(166.72.0.141) by out1.ibm.net via smap (V1.3mjr) id smaxSIB7s; Fri Apr 25 18:31:13 1997 Received: (from uri@localhost) by alisan.ibm.net (8.7.6/8.7.3) id OAA08871; Fri, 25 Apr 1997 14:31:01 -0400 Date: Fri, 25 Apr 1997 14:31:01 -0400 Message-Id: <199704251831.OAA08871@alisan.ibm.net> From: Uri Blumenthal To: Keith Moore Cc: ietf-smime@imc.org Subject: Re: The RC2 debate In-Reply-To: <199704242032.QAA03472@spot.cs.utk.edu> References: <199704240148.VAA00323@alisan.ibm.net> <199704242032.QAA03472@spot.cs.utk.edu> Reply-To: NOSPAM!uri@ibm.net Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk >>>>> "Keith" == Keith Moore writes: Keith> RSA can complain "but that's *our* protocol", and IETF will Keith> duly record that complaint, but that by itself won't stop Keith> IETF from considering whether to use it. .................... Keith> Call it whatever you like, but that's what RFC 2026 says. Excuse me, but who cares what RFC 2036 says? I thought we weren't discussing what RFC 2036 got to tell us? Keith> I strongly suspect that people are missing my point, but Keith> I'm tired of trying to explain it. So I'll stop. If you Keith> want further clarification, ask me in private mail. Well, it is very possible that your point is missed/misunderstood. However, let me explain what is the point that [mostly] everybody else is making: there is a proprietary algorithm that some would want to "bless" as a standard, because they were [un]lucky enough to purchase a license and implement it in their products. Others are afraid [and for a reason] that such an inclusion will make an unencumbered implementation impossible due to a lawsuit threat from the algorithm "owner". Those others thus violently object against any attempt to sneak RC2 in. It does NOT matter whether IESG allows to document an algorithm, such as RC2. It does NOT matter whether a standard that includes such an algorithm would or would not violate IETF rules (however there is a strong opinion that it would). What DOES matter is that accepting such an algorithm can [and most probably will] negatively affect the availability of the implementations. Everybody wants a standard that is free [to implement]. The rest is irrelevant, IMHO. Regards, [To reply, remove "NOSPAM!" from the Uri "Reply-To:" field] -=-=-==-=-=- uri@ibm.net From owner-ietf-smime Fri Apr 25 12:45:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA02432 for ietf-smime-bks; Fri, 25 Apr 1997 12:45:16 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA02428 for ; Fri, 25 Apr 1997 12:45:13 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id PAA06071; Fri, 25 Apr 1997 15:46:14 -0400 (EDT) Message-Id: <199704251946.PAA06071@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: uri@ibm.net cc: Keith Moore , ietf-smime@imc.org Subject: Re: The RC2 debate In-reply-to: Your message of "Fri, 25 Apr 1997 14:31:01 EDT." <199704251831.OAA08871@alisan.ibm.net> X-SUBJECT-MSG-FROM: Uri Blumenthal Date: Fri, 25 Apr 1997 15:46:14 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > Keith> RSA can complain "but that's *our* protocol", and IETF will > Keith> duly record that complaint, but that by itself won't stop > Keith> IETF from considering whether to use it. > .................... > Keith> Call it whatever you like, but that's what RFC 2026 says. > > Excuse me, but who cares what RFC 2036 says? I thought we weren't > discussing what RFC 2036 got to tell us? Some people have been talking about in terms of use of RC2 being a violation of IETF process. RFC 2026 defines that process, and most of my contribution to this discussion has been an attempt to clarify that process. People's beliefs about the process rules are very relevant to this discussion, because those beliefs color the thinking about the solution space. If a working group decides not to use RC2, that's fine with me. But I hate to see a group making such a decision based on a misunderstanding of IETF process rules. If the group understands the process rules, and still makes the same decision, I'm a lot more comfortable. > Everybody wants a standard that is free [to implement]. Only problem is, the intersection of "free to implement" and "compatible with s/mime" is the null set. So do people here really want to define Yet Another Email Security Standard which can freely be implemented, even if it's incompatible with anything else that's out there? Keith From owner-ietf-smime Fri Apr 25 13:57:19 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA03476 for ietf-smime-bks; Fri, 25 Apr 1997 13:57:19 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA03472 for ; Fri, 25 Apr 1997 13:57:16 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC5180.C5C24C00@cane.deming.com>; Fri, 25 Apr 1997 13:58:37 -0700 Message-ID: From: Blake Ramsdell To: "'Ned Freed'" Cc: "'Keith Moore'" , "'pgut001@cs.auckland.ac.nz'" , "'ietf-smime@imc.org'" Subject: RE: The RC2 debate Date: Fri, 25 Apr 1997 13:58:30 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk On Thursday, April 24, 1997 11:16 PM, Ned Freed [SMTP:Ned.Freed@innosoft.com] wrote: > Yes. My position is that RC2 cannot even be an optional part of the > specification unless it is released from trade secret restrictions. As a > trade > secret the most it can be is an informational part of the specification, and > preferably in a separate, informational document. I don't see the difference between my saying that the algorithm "can be used, but not as a MUST" and you saying that it can be "an informational part of the specification". Both seem to refer to optional algorithms that can be used with the protocol. As far as a separate, informational document, Steve Dusse and the original S/MIME vendors had originally drafted the S/MIME spec using both a message specification (that talked about the MIME types and the use of multipart/signed), and an interoperability profile (describing the exact algorithms to be used in the specification). The latest S/MIME draft fused these two documents together, and I'm not sure if that was the best idea. I agree that algorithm specifics are best left to a separate document -- that way, in the event that the algorithms change for cryptographic or other reasons, the only document that needs to change is the one that specifies the algorithms. The other documents (in this case, the overall MIME message format and the S/MIME certificate handling) will be unchanged. > P.S. I am also somewhat offended by your dismissive term "cranky" here. There > are sound technical and procedural reasons for the position I've taken here. Yes, you've voiced them, and you've whipped yourself into a frenzy (the "vociferous objection" paragraph from your last message. I have trouble spelling it). The point that I was making by trivializing your position as "being cranky" is to lighten the mood. I'm sorry if it offended you, but I think that you got much too fired up about this. The only reason I stepped into this discussion was to clarify whether or not the OPTIONAL use of RC2 is a violation of IETF guidelines, and as far as I can tell it isn't. Please let me know if I have misunderstood your statement about its inclusion as an informational part of the specification as being equivalent to the OPTIONAL use of RC2. Maybe the difference we are having is related to the physical separation of the S/MIME message specification from the interoperability / algorithm profile. Blake From owner-ietf-smime Fri Apr 25 14:06:40 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA03673 for ietf-smime-bks; Fri, 25 Apr 1997 14:06:40 -0700 (PDT) Received: from ig.cs.utk.edu (IG.CS.UTK.EDU [128.169.94.149]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA03669 for ; Fri, 25 Apr 1997 14:06:36 -0700 (PDT) Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id RAA26230; Fri, 25 Apr 1997 17:07:34 -0400 (EDT) Message-Id: <199704252107.RAA26230@ig.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Blake Ramsdell cc: "'Ned Freed'" , "'Keith Moore'" , "'pgut001@cs.auckland.ac.nz'" , "'ietf-smime@imc.org'" Subject: Re: The RC2 debate In-reply-to: Your message of "Fri, 25 Apr 1997 13:58:30 PDT." Date: Fri, 25 Apr 1997 17:07:34 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > The only reason I stepped into this discussion was to clarify whether or > not the OPTIONAL use of RC2 is a violation of IETF guidelines, and as > far as I can tell it isn't. At least for the case of MIME content-type names, we allow assignment of names for proprietary content-types. This was simply pragmatic: there were (unfortunately!) too many proprietary content-types that people wanted to use in MIME, (and were going to be used no matter what the IETF said) and we're better off having them clearly labeled. I imagine that the working group will want to use some kind of algorithm identifier to specify what kind of encryption is being used. If so, the working group could decide the rules governing assignment of algorithm identifiers, and (for example) whether the algorithm had to have a published and openly available specification. My guess is that a set of workable rules would end up being much like those for MIME types. Keith From owner-ietf-smime Fri Apr 25 18:37:27 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA06268 for ietf-smime-bks; Fri, 25 Apr 1997 18:37:27 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA06264 for ; Fri, 25 Apr 1997 18:37:24 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01II4MJ0NL4W99F789@INNOSOFT.COM> for ietf-smime@imc.org; Fri, 25 Apr 1997 18:37:38 PDT Date: Fri, 25 Apr 1997 18:09:02 -0700 (PDT) From: Ned Freed Subject: RE: The RC2 debate In-reply-to: "Your message dated Fri, 25 Apr 1997 13:58:30 -0700" To: Blake Ramsdell Cc: "'Ned Freed'" , "'Keith Moore'" , "'pgut001@cs.auckland.ac.nz'" , "'ietf-smime@imc.org'" Message-id: <01II4S1V889899F789@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-smime@imc.org Precedence: bulk > > Yes. My position is that RC2 cannot even be an optional part of the > > specification unless it is released from trade secret restrictions. As a > > trade > > secret the most it can be is an informational part of the specification, and > > preferably in a separate, informational document. > I don't see the difference between my saying that the algorithm "can be > used, but not as a MUST" and you saying that it can be "an informational > part of the specification". Both seem to refer to optional algorithms > that can be used with the protocol. I beg to differ. An optional part of a formal protocol specification is still part of the specification. As such, it carries with it the IETF imprimateur and all it implies -- it must undergo design and security analysis, it must meet interoperability requirements, and so on. And perhaps more to the point, anything described as a formal part of the protocol will be seen as something implementations must provide; the labelling of mandatory versus optional tends to be overlooked for the most part. An informational document or appendix, on the other hand, is lightyears away from this. An informational document is simply something someone decided to publish. It is nothing more than that. It can be entirely cogent and relevant or it can be the documented ravings of a lunatic. (And I'm afraid there are RFCs that come very close to falling in the latter category.) It can be extremely useful or an April Fool's prank. Other than the RFC editor and an occasional IESG disclaimer, the IETF doesn't assess, bless, or condemn informational documents in any way, shape, or form. This is why the standards track designation is so important and why there's an essential and fundamental difference between informational documents and optional protocol elements in standards-track specifications. > As far as a separate, informational document, Steve Dusse and the > original S/MIME vendors had originally drafted the S/MIME spec using > both a message specification (that talked about the MIME types and the > use of multipart/signed), and an interoperability profile (describing > the exact algorithms to be used in the specification). The latest > S/MIME draft fused these two documents together, and I'm not sure if > that was the best idea. The form the material takes it totally irrelevant. As a practical matter the RFC editor will require separation of informational material from standards-track material prior to publication, but this isn't something we need to worry about at this time. > I agree that algorithm specifics are best left > to a separate document -- that way, in the event that the algorithms > change for cryptographic or other reasons, the only document that needs > to change is the one that specifies the algorithms. The other documents > (in this case, the overall MIME message format and the S/MIME > certificate handling) will be unchanged. We've been down this path many times before and dealt with this particular problem in various different ways in different protocols. The bottom line is that there's no good answer -- if you separate the material people will have trouble putting the pieces together and if you don't people will have trouble taking them apart. Experience has shown you cannot win on this one. But be this as it may, it still simply isn't at all relevant to the issues at hand. > > P.S. I am also somewhat offended by your dismissive term "cranky" here. > > There are sound technical and procedural reasons for the position I've taken here. > Yes, you've voiced them, and you've whipped yourself into a frenzy (the > "vociferous objection" paragraph from your last message. I have trouble > spelling it). The point that I was making by trivializing your position > as "being cranky" is to lighten the mood. I'm sorry if it offended you, > but I think that you got much too fired up about this. You just can't seem to get away from being dismissive and condescending, can you? Anyway, as far as "whipped into a frenzy" goes, I am not in anything even remotely resembling a frenzy over this issue. (Some of you probably remember some of the heated exchanges during the development of MIME; this present matter pales into insignificance in comparison to those.) All I have done here is make the extent and depth of my opposition to the inclusion of RC2 with IP baggage attached in an IETF standard clear. And if you think I'm joking, that this is simply a passing fancy of mine, or that I'm making a mountain out of a molehill you are seriously mistaken. I meant every word I said and I will do everything I said I would do should it become necessary to do so. > The only reason I stepped into this discussion was to clarify whether or > not the OPTIONAL use of RC2 is a violation of IETF guidelines, and as > far as I can tell it isn't. And as far as I can tell it is. I will also point out that I sustantive experience in this area, as I have in the past been forced to remove optional protocol elements on the basis of IETF rules from documents I've edited, and I'm pretty sure I will have to a lot more of these removals from documents I edit in the future. (And no, I don't like having to do this, but I also understand that there are very good reasons for us having the rules we do and I have to follow them just like everyone else.) > Please let me know if I have misunderstood > your statement about its inclusion as an informational part of the > specification as being equivalent to the OPTIONAL use of RC2. My statement stands. My assessment is that RC2 cannot even be an optional part of a standards track specification unless its IP status changes. Ned From owner-ietf-smime Fri Apr 25 18:53:30 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA06398 for ietf-smime-bks; Fri, 25 Apr 1997 18:53:30 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA06393 for ; Fri, 25 Apr 1997 18:53:27 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01II4MJ0NL4W99F789@INNOSOFT.COM> for ietf-smime@imc.org; Fri, 25 Apr 1997 18:53:41 PDT Date: Fri, 25 Apr 1997 18:44:03 -0700 (PDT) From: Ned Freed Subject: Re: The RC2 debate In-reply-to: "Your message dated Fri, 25 Apr 1997 17:07:34 -0400" <199704252107.RAA26230@ig.cs.utk.edu> To: Keith Moore Cc: Blake Ramsdell , "'Ned Freed'" , "'Keith Moore'" , "'pgut001@cs.auckland.ac.nz'" , "'ietf-smime@imc.org'" Message-id: <01II4SLSP0ZK99F789@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII References: Sender: owner-ietf-smime@imc.org Precedence: bulk > > The only reason I stepped into this discussion was to clarify whether or > > not the OPTIONAL use of RC2 is a violation of IETF guidelines, and as > > far as I can tell it isn't. > At least for the case of MIME content-type names, we allow assignment > of names for proprietary content-types. This was simply pragmatic: > there were (unfortunately!) too many proprietary content-types that > people wanted to use in MIME, (and were going to be used no matter what > the IETF said) and we're better off having them clearly labeled. I don't think this comparison is appropriate or useful. A much better comparison would be to the members of the base set of content types defined in the MIME specification. And in this case, as part of a standards-track document, I have had to fight very hard to retain the set that's there now. (At one point it even looked like there would be no primitive types in there other than text/plain.) In particular, it has been a major struggle to retain application/postscript, even though this is an entirely optional part of the specification, the specifications for PostScript are readily available and have no associated confidentiality restrictions of any kind, there are lots of interoperable implementations, a reasonably complete and comprehensive security analysis was done early one, and so on. It also looks fairly likely that I'll be asked to remove multipart/parallel from the base MIME specification and instead move it to an informational document, simply because there don't seem to be a sufficient number of agents that generate it on a regular basis to demonstrate interoperability. > I imagine that the working group will want to use some kind of > algorithm identifier to specify what kind of encryption is being used. > If so, the working group could decide the rules governing assignment > of algorithm identifiers, and (for example) whether the algorithm had > to have a published and openly available specification. My guess > is that a set of workable rules would end up being much like those > for MIME types. I agree but I don't think this is the point. The point is what ends up in the base standards-track document defining S/MIME. I have no problem whatsoever with a separate informational document that begins with a big disclaimer saying the IETF hasn't blessed this in any way and then defines RC2 to some extent and then says that its OID should you care to use it is such-and-such. Ned From owner-ietf-smime Fri Apr 25 22:08:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id WAA07394 for ietf-smime-bks; Fri, 25 Apr 1997 22:08:44 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id WAA07390 for ; Fri, 25 Apr 1997 22:08:41 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC51C5.6E12BC20@cane.deming.com>; Fri, 25 Apr 1997 22:10:05 -0700 Message-ID: From: Blake Ramsdell To: "'Ned Freed'" Cc: "'ietf-smime@imc.org'" Subject: RE: The RC2 debate Date: Fri, 25 Apr 1997 22:10:04 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk OK, Blake the Chimp Boy has finally caught up with the class. Clean slate. If S/MIME becomes standards track, then RC2 cannot even be mentioned as a possible algorithm for use with the protocol. This is because of its trade secret status, as opposed to just being patented. Patented algorithms such as the RSA public-key algorithm, CAST or IDEA are a different issue, correct? I understand that all of these particular algorithms have provisions for non-commercial use. If they didn't, would there be a problem with putting them in the spec? Blake From owner-ietf-smime Sat Apr 26 10:03:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA12928 for ietf-smime-bks; Sat, 26 Apr 1997 10:03:46 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA12924 for ; Sat, 26 Apr 1997 10:03:43 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 26 Apr 1997 10:09:23 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: Request for Moritorium: The RC2 debate Sender: owner-ietf-smime@imc.org Precedence: bulk Thank you all for participating in this discussion, and it has indeed helped the document authors. (No smiley here: I mean it.) It has helped us see where we need to clean up the spec, making it both more secure and (hopefully) easier to understand. That's good, and that's what this kind of work is all about. The author group is actively working on the next revision of the drafts, and you should hopefully see them in a bit more than a week. The RC2 debate can temporarily be tabled with what I believe is the following consensus: the final draft will not have MUST or SHOULD text referring to RC2 if RSA intends to treat RC2 as a trade secret. The next version of the drafts will reflect this consensus. I met with the folks at RSA yesterday. RSA still treats RC2 as a trade secret, they are considering many options, they understand the July 1 deadline set by Jeff Schiller, they want a resolution well before that, and they don't want the RC2 debate delaying the entire process. On that note, I'd like to point out that there are a host of other open issues listed in the drafts, and that some of you might have come up with others. Please feel free to start new threads with any suggestions for resolution on the open topics, or to bring up others. And, again, I request that you read the drafts before posting to the list. The author group will do its best to get the next round out soon. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Sat Apr 26 09:43:48 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA12796 for ietf-smime-bks; Sat, 26 Apr 1997 09:43:48 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA12792 for ; Sat, 26 Apr 1997 09:43:46 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01II5MGRBFR499ETFU@INNOSOFT.COM> for ietf-smime@imc.org; Sat, 26 Apr 1997 09:44:01 PDT Date: Sat, 26 Apr 1997 09:11:44 -0700 (PDT) From: Ned Freed Subject: RE: The RC2 debate In-reply-to: "Your message dated Fri, 25 Apr 1997 22:10:04 -0700" To: Blake Ramsdell Cc: "'Ned Freed'" , "'ietf-smime@imc.org'" Message-id: <01II5NOOFEYW99ETFU@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-smime@imc.org Precedence: bulk > Patented algorithms such as the RSA public-key algorithm, CAST or IDEA > are a different issue, correct? I understand that all of these > particular algorithms have provisions for non-commercial use. If they > didn't, would there be a problem with putting them in the spec? I'm afraid your understanding of the rules is somewhat out of date. This is indeed the way it used to be, but it isn't any longer. The current rules seem quite clear to me -- pure intellectual property issues are something the IETF doesn't factor into their protocol design decisions. If they are known they have to be documented, and an attempt has to be made to obtain reasonable licensing terms (whatever that means), but that's it. As such, there is no problem requiring a patented algorithm in a protocol, even if the patent isn't easily licensable or has no provisions for non-commercial use. The only way to keep such an algorithm out of the standard is to use the interoperability requirements to say it cannot advance to draft because of a lack of interoperable implementations, but all this means is that two different parties have to be able to get a license, not that anyone has to be able to. (And in this era of routine patent portfolio swaps among the big boys this requirement is totally meaningless in practice.) So there is no problem using RSA, Diffie-Hellman, LZW, or designing protocols that negotiate compression along with encryption (this idea is patented, believe it or not), or for that matter the 40-bit variant of DES that IBM apparently has patented. (I'm still looking for a reference to this last, BTW, but cannot find one that includes a useful description of the technique, let alone a description of what the patent actually covers.) The issue with RC2 isn't that it is covered by a trade secret and that trade secrets never expire (this is one of Keith's pet peeves, but there's nothing in the rules that forbids it that I know of), it is that trade secrets imply confidentiality restrictions and such restrictions are forbidden regardless of their origin. If a variant of trade secret existed that didn't require confidentiality it would be perfectly acceptable under current IETF rules, even if its IP claim never expired. (Of course such a variant cannot possibly exist as the very foundation of trade secrecy lies in its confidentiality.) Keith's point here is that he believes the IETF's rule of having to keep IP issues out of the decision process means that RC2's trade secret status cannot be used as a basis of rejecting the protocol. My counter is that the trade secret status is irrelevant, it is the confidentiality restrictions implied by this status that are unacceptable, and I find no language anywhere that allows for an exception to the rules against confidentiality restrictions because the confidentiality restriction arises as a result of a trade secret. BTW, I happen to disagree with the way the IETF chooses to treat patents now and I argued against it at some length when the rule change was made, but the consensus went the other way. This means, BTW, that should this WG decide to replace RC2 with, say, the patented 40-bit IBM DES variant you would have to license this new patent to implement S/MIME, and it would be just too bad if IBM didn't have reasonable licensing terms available for it. See why I don't like the present policy all that much? Ned From owner-ietf-smime Thu May 1 09:42:06 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA10292 for ietf-smime-bks; Thu, 1 May 1997 09:42:06 -0700 (PDT) Received: from eng53.certicom.ca ([204.225.51.194]) by mail.proper.com (8.8.5/8.7.3) with SMTP id JAA10288 for ; Thu, 1 May 1997 09:41:59 -0700 (PDT) Received: from galois.certicom.ca (galois.certicom.ca [204.225.50.1]) by janus with ESMTP (DuhMail/2.0) id MAA09984; Thu, 1 May 1997 12:19:02 -0500 Received: from sales38.sales.certicom.com (sasha.certicom.ca [204.225.51.38]) by eng1.certicom.ca (8.6.12/8.6.9) with SMTP id MAA07810 for ; Thu, 1 May 1997 12:47:18 -0400 Date: Thu, 1 May 1997 12:47:18 -0400 Message-Id: <199705011647.MAA07810@eng1.certicom.ca> X-Sender: banderso@certicom.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-smime@imc.org From: Bill Anderson Subject: IETF S/MIME and Algorithm Independence Sender: owner-ietf-smime@imc.org Precedence: bulk I'd like to make an observation on the current IETF S/MIME draft that I think may need to be addressed. I believe it is the IETF's goal to achieve algorithm-independent drafts wherever possible. This is certainly possible for S/MIME, and I would suggest that it is also desirable. There is an opportunity to define the S/MIME specification to allow a variety of public key algorithms. For example, the NIST Digital Signature Standard (DSS), the Elliptic Curve variant of DSS called ECDSA, and other digital signaure algorithms could be used for signed messages. Similarly, symmetric key wrapping could also be performed by alternate public key algorithms. I see a problem with this being achieved by the draft as it is written because it appears to mandate the use of PKCS #7 message formats. While PKCS #7 is an excellent standard for RSA messages, it is not currently designed to handle other types of cryptography. To summarize: The IETF S/MIME draft may be attempting to achieve algorithm independence, but this attempt is defeated by the requirement for the current PKCS #7 message format. RSA has announced that it will be developing version 2.0 of the standard over the next year. The new standard is intended to be algorithm independent, so this may solve one problem. However, I think we need to be aware that at present the PKCS #7 message format can not address all of the requirements for an algorithm independent S/MIME standard. Bill Anderson From owner-ietf-smime Thu May 1 12:27:20 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id MAA12846 for ietf-smime-bks; Thu, 1 May 1997 12:27:20 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id MAA12842 for ; Thu, 1 May 1997 12:27:17 -0700 (PDT) Message-Id: In-Reply-To: <199705011647.MAA07810@eng1.certicom.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 1 May 1997 12:33:29 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: Re: IETF S/MIME and Algorithm Independence Sender: owner-ietf-smime@imc.org Precedence: bulk At 9:47 AM -0700 5/1/97, Bill Anderson wrote: >I'd like to make an observation on the current IETF S/MIME draft that I >think may need to be addressed. I believe it is the IETF's goal to achieve >algorithm-independent drafts wherever possible. However, there was a mandate that we *not* do that on this work, that we specify a minimum interoperability standard. That is, we don't want MOSS II. >While >PKCS #7 is an excellent standard for RSA messages, it is not currently >designed to handle other types of cryptography. Well, we can all imagine why it was designed the way that it is. I'd be interested in hearing about which other types of cryptography are prevented byt PKCS #7. With the SMIMECapabilities attributes, we're allowing implementations to change anything, including the type of cryptography used. This was specifically to allow the kinds of changes you want, so if some are prevented by PKCS #7, we should deal with that soon. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Fri May 2 08:02:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA27888 for ietf-smime-bks; Fri, 2 May 1997 08:02:24 -0700 (PDT) Received: from netcomsv.netcom.com (uucp12.netcom.com [163.179.3.12]) by mail.proper.com (8.8.5/8.7.3) with SMTP id IAA27883; Fri, 2 May 1997 08:02:20 -0700 (PDT) Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id HAA05813; Fri, 2 May 1997 07:56:20 -0700 Received: from cc:Mail by spysouth.spyrus.com id AA862580830 Fri, 02 May 97 06:47:10 Date: Fri, 02 May 97 06:47:10 From: "Housley, Russ" Message-Id: <9704028625.AA862580830@spysouth.spyrus.com> To: ietf-smime@imc.org, "Paul E. Hoffman" Subject: Re[2]: IETF S/MIME and Algorithm Independence Sender: owner-ietf-smime@imc.org Precedence: bulk >>I'd like to make an observation on the current IETF S/MIME draft that I >>think may need to be addressed. I believe it is the IETF's goal to achieve >>algorithm-independent drafts wherever possible. > >However, there was a mandate that we *not* do that on this work, that we >specify a minimum interoperability standard. That is, we don't want MOSS II. I disagree. We want an algorithm independent protocol, but we want to pick a "must implement" algorithm that ensures interoperability. >>While >>PKCS #7 is an excellent standard for RSA messages, it is not currently >>designed to handle other types of cryptography. > >Well, we can all imagine why it was designed the way that it is. I'd be >interested in hearing about which other types of cryptography are prevented >by PKCS #7. With the SMIMECapabilities attributes, we're allowing >implementations to change anything, including the type of cryptography >used. This was specifically to allow the kinds of changes you want, so if >some are prevented by PKCS #7, we should deal with that soon. Paul, the current structure mandates the use of RSA key management. The standrd should not prohibit the use of other techniques such a Diffie-Hellman. It is possible to have RSA as the "must implement" key management algorithm, but the standardized structure should not prohibit the use of other techniques. Russ From owner-ietf-smime Fri May 2 09:02:24 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA29120 for ietf-smime-bks; Fri, 2 May 1997 09:02:24 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA29116 for ; Fri, 2 May 1997 09:02:21 -0700 (PDT) Message-Id: In-Reply-To: <9704028625.AA862580830@spysouth.spyrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 2 May 1997 09:08:40 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: Re[2]: IETF S/MIME and Algorithm Independence Sender: owner-ietf-smime@imc.org Precedence: bulk >>However, there was a mandate that we *not* do that on this work, that we >>specify a minimum interoperability standard. That is, we don't want MOSS II. > >I disagree. We want an algorithm independent protocol, but we want to pick a >"must implement" algorithm that ensures interoperability. Ah, I think I misunderstood the meaning of "algorithm independent protocol". I my mind, "algorithm independent" means "all algorithms are treated equally", which is what I spoke against. The current (and future) drafts allow all algorithms, but mandate "must implement" for some of them. To me, that's not "algorithm independent" but "multiple algorithm friendly". I think we are in agreement here about what the spec does, just not the terminolgy. >Paul, the current structure mandates the use of RSA key management. The >standrd >should not prohibit the use of other techniques such a Diffie-Hellman. It is >possible to have RSA as the "must implement" key management algorithm, but >the >standardized structure should not prohibit the use of other techniques. And it doesn't. In fact, with the SMIMECapabilities, it makes it easy for an agent that is using some other kind of key management to announce that to the world on every signed and/or encrypted message it sends out. This is described in the beginning of Section 2.5.2 of the drafts. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Fri May 2 14:18:43 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA04268 for ietf-smime-bks; Fri, 2 May 1997 14:18:43 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id OAA04262; Fri, 2 May 1997 14:18:40 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC5703.D813DCB0@cane.deming.com>; Fri, 2 May 1997 14:19:28 -0700 Message-ID: From: Blake Ramsdell To: "'Paul E. Hoffman'" , "'ietf-smime@imc.org'" Subject: RE: Re[2]: IETF S/MIME and Algorithm Independence Date: Fri, 2 May 1997 14:19:26 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk On Friday, May 02, 1997 9:09 AM, Paul E. Hoffman [SMTP:phoffman@imc.org] wrote: > >Paul, the current structure mandates the use of RSA key management. The > >standrd > >should not prohibit the use of other techniques such a Diffie-Hellman. It > >is > >possible to have RSA as the "must implement" key management algorithm, but > >the > >standardized structure should not prohibit the use of other techniques. > > And it doesn't. In fact, with the SMIMECapabilities, it makes it easy for > an agent that is using some other kind of key management to announce that > to the world on every signed and/or encrypted message it sends out. This is > described in the beginning of Section 2.5.2 of the drafts. I think that Russ' (and Bill's original) point was that the PKCS #7 architecture has some things built into it that make it hard to use key management other than RSA. For instance to identify the certificate used to encrypt the session key for a recipient, an "IssuerAndSerialNumber" is used which is the combination of the issuer field and the serialNumber field from an X.509 certificate. Likewise, this same identifier is used for identifying a certificate that should be used for signature verification. This identifier is not suitable/applicable for non-X.509 environments. Also the certificate shuttling mechanism is based on an ExtendedCertificateOrCertificate which is an X.509 certificate, or a (deprecated) PKCS #6 ExtendedCertificate -- not really easy to put in something that isn't X.509. My understanding is that PKCS #7 is being worked on to address some of these things. SMIMECapabilites is helpful for supporting different public-key models, but I think there's some more work that needs to be done in order to have full support. Blake From owner-ietf-smime Fri May 2 15:01:55 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA04931 for ietf-smime-bks; Fri, 2 May 1997 15:01:55 -0700 (PDT) Received: from netcomsv.netcom.com (uucp2.netcom.com [163.179.3.2]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA04926; Fri, 2 May 1997 15:01:52 -0700 (PDT) Received: by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id OAA21755; Fri, 2 May 1997 14:51:44 -0700 Received: from cc:Mail by spysouth.spyrus.com id AA862605358 Fri, 02 May 97 13:35:58 Date: Fri, 02 May 97 13:35:58 From: "Housley, Russ" Message-Id: <9704028626.AA862605358@spysouth.spyrus.com> To: ietf-smime@imc.org, "Paul E. Hoffman" Subject: Re: IETF S/MIME and Algorithm Independence Sender: owner-ietf-smime@imc.org Precedence: bulk Paul: >>Paul, the current structure mandates the use of RSA key management. The >>standrd >>should not prohibit the use of other techniques such a Diffie-Hellman. It is >>possible to have RSA as the "must implement" key management algorithm, but >>the >>standardized structure should not prohibit the use of other techniques. > >And it doesn't. In fact, with the SMIMECapabilities, it makes it easy for >an agent that is using some other kind of key management to announce that >to the world on every signed and/or encrypted message it sends out. This >is described in the beginning of Section 2.5.2 of the drafts. The PKCS#7 structure that supports S/MIME does not permit any key management algorithm to work. For example, there is no place to carry the originator certificate that contains an Diffie-Hellman key. Russ From owner-ietf-smime Fri May 2 16:57:23 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA06114 for ietf-smime-bks; Fri, 2 May 1997 16:57:23 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id QAA06109; Fri, 2 May 1997 16:57:20 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC571A.08C118D0@cane.deming.com>; Fri, 2 May 1997 16:58:18 -0700 Message-ID: From: Blake Ramsdell To: Blake Ramsdell , "'Paul E. Hoffman'" , "'ietf-smime@imc.org'" Subject: RE: Re[2]: IETF S/MIME and Algorithm Independence Date: Fri, 2 May 1997 16:58:17 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk On Friday, May 02, 1997 2:19 PM, Blake Ramsdell wrote: > I think that Russ' (and Bill's original) point was that the PKCS #7 > architecture has some things built into it that make it hard to use key > management other than RSA. Whoops. I mean that "it makes it hard to use key management other than X.509". Sorry about that. Blake From owner-ietf-smime Tue May 6 17:05:36 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA19084 for ietf-smime-bks; Tue, 6 May 1997 17:05:36 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA19079 for ; Tue, 6 May 1997 17:05:32 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 May 1997 17:05:35 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: Restarting the 40-bit debate Sender: owner-ietf-smime@imc.org Precedence: bulk One change we made in the -01 version of the drafts was to remove RC2 from the main part of the draft, and to replace it with an "algorithm" called "FOO/40". The purpose of this is give the list a round of not discussing RC2, but fully discussing the use of a 40-bit weak algorithm. Please read all of Section 2.6 and its subsections carefully. It is the belief of the author team that there is nothing in this section that requires sending using weak encryption, and gives you a precise guideline for determining which encryption method to use in order to not send with weak encryption. I believe that naming and allowing a 40-bit algorithm in the spec will cause many more developers to implement the spec; this is a Good Thing. As much as we may hate it, the US Government's refusal to let US developers ship mail software with stronger security has pretty much prevented all developers, inside the US and outside, from implementing strong-encryption-only specs like PGP/MIME. I think it behooves us to come out with a spec that can be widely implemented but does not force weak encryption. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Tue May 6 17:05:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA19083 for ietf-smime-bks; Tue, 6 May 1997 17:05:35 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA19075 for ; Tue, 6 May 1997 17:05:31 -0700 (PDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 6 May 1997 16:46:13 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: New versions of the drafts available Sender: owner-ietf-smime@imc.org Precedence: bulk I've sent off the -01 versions of the two S/MIME drafts to the Internet Drafts editor. To help avoid the wait for them to be posted on the official directories, I've also updated the IMC copies at: Each draft has a list of changes from the earlier version in an appendix near the end of the draft. Please read them over and feel free to comment. --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Wed May 7 09:44:25 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id JAA11182 for ietf-smime-bks; Wed, 7 May 1997 09:44:25 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id JAA11176; Wed, 7 May 1997 09:44:20 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id MAA09392; Wed, 7 May 1997 12:43:49 -0400 (EDT) Message-Id: <199705071643.MAA09392@spot.cs.utk.edu> X-Mailer: exmh version 2.0gamma 1/27/96 X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Paul E. Hoffman" cc: ietf-smime@imc.org, moore@cs.utk.edu Subject: Re: Restarting the 40-bit debate In-reply-to: Your message of "Tue, 06 May 1997 17:05:35 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 May 1997 12:43:48 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > As much as we may hate it, the US Government's refusal to let US > developers ship mail software with stronger security has pretty much > prevented all developers, inside the US and outside, from > implementing strong-encryption-only specs like PGP/MIME. I don't believe this. First, there are many factors involved besides US export rules -- including the existance of patents and the licensing practices of certain firms. PGP has a reputation which gives it credibility in certain circles and undermines its credibility in others. Second, people are shipping strong encryption products both inside and outside the United States. > I think it behooves us to come out with a spec that can be widely > implemented but does not force weak encryption. People can define and use weak encryption algorithms if they want to. However, I sincerely doubt that something as weak as 40 bits can be considered of sufficient quality for the Internet standards track. Keith From owner-ietf-smime Wed May 7 13:41:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id NAA14786 for ietf-smime-bks; Wed, 7 May 1997 13:41:14 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id NAA14781; Wed, 7 May 1997 13:41:08 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC5AEC.3E297FA0@cane.deming.com>; Wed, 7 May 1997 13:40:36 -0700 Message-ID: From: Blake Ramsdell To: "'Keith Moore'" , "'Paul E. Hoffman'" Cc: "'ietf-smime@imc.org'" Subject: RE: Restarting the 40-bit debate Date: Wed, 7 May 1997 13:40:32 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk On Wednesday, May 07, 1997 9:44 AM, Keith Moore [SMTP:moore@cs.utk.edu] wrote: > > As much as we may hate it, the US Government's refusal to let US > > developers ship mail software with stronger security has pretty much > > prevented all developers, inside the US and outside, from > > implementing strong-encryption-only specs like PGP/MIME. > > I don't believe this. First, there are many factors involved besides > US export rules -- including the existance of patents and the > licensing practices of certain firms. PGP has a reputation which > gives it credibility in certain circles and undermines its credibility > in others. Second, people are shipping strong encryption products > both inside and outside the United States. I think the point is that within the domain of US commercial for-profit software companies, strong-encryption-only specs are only going to appeal to those companies that don't consider their international sales to be important. In my opinion, these companies are missing out on a large market that wants products. We have a large customer base that is non-US, non-Canada and I certainly don't consider ourselves to be the largest company out there (which means that the Apples, IBMs and Microsofts of the world are much more interested in this market than I am). It seems that US companies with an interest in international sales may be a large faction of the overall IETF membership, but I might be wrong. > > I think it behooves us to come out with a spec that can be widely > > implemented but does not force weak encryption. > > People can define and use weak encryption algorithms if they want to. > However, I sincerely doubt that something as weak as 40 bits can be > considered of sufficient quality for the Internet standards track. In these discussions I always end up at the same point. Why is there no differentiation between a spec that allows the OPTION of using a weak algorithm, versus a REQUIREMENT of using a weak algorithm? The argument was presented here before that in the event that something is specified as OPTIONAL, in practice it is always implemented, and thus everyone will be using the weak algorithm. I don't understand how people could make money with such a product, since competitive products that didn't take the "easy way" would stomp them because of the shortcoming. Blake From owner-ietf-smime Wed May 7 14:03:12 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA14983 for ietf-smime-bks; Wed, 7 May 1997 14:03:12 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA14978; Wed, 7 May 1997 14:03:07 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id RAA10520; Wed, 7 May 1997 17:01:42 -0400 (EDT) Message-Id: <199705072101.RAA10520@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Blake Ramsdell cc: "'Keith Moore'" , "'Paul E. Hoffman'" , "'ietf-smime@imc.org'" Subject: Re: Restarting the 40-bit debate In-reply-to: Your message of "Wed, 07 May 1997 13:40:32 PDT." Date: Wed, 07 May 1997 17:01:42 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > In these discussions I always end up at the same point. Why is there no > differentiation between a spec that allows the OPTION of using a weak > algorithm, versus a REQUIREMENT of using a weak algorithm? Optional weak algorithms are fine, as long as there are mandantory algorithms of sufficient strength, and as long as the optional algorithms are not endorsed as part of the standard. Keith From owner-ietf-smime Wed May 7 14:40:46 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id OAA15325 for ietf-smime-bks; Wed, 7 May 1997 14:40:46 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id OAA15320; Wed, 7 May 1997 14:40:42 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id RAA10644; Wed, 7 May 1997 17:40:19 -0400 (EDT) Message-Id: <199705072140.RAA10644@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Blake Ramsdell cc: "'Keith Moore'" , "'Paul E. Hoffman'" , "'ietf-smime@imc.org'" Subject: Re: Restarting the 40-bit debate In-reply-to: Your message of "Wed, 07 May 1997 13:40:32 PDT." Date: Wed, 07 May 1997 17:40:16 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > I think the point is that within the domain of US commercial for-profit > software companies, strong-encryption-only specs are only going to > appeal to those companies that don't consider their international sales > to be important. > > In my opinion, these companies are missing out on a large market that > wants products. [...] > > It seems that US companies with an interest in international sales may > be a large faction of the overall IETF membership, but I might be wrong. You seem to be of the opinion that IETF exists to provide market opportunities to US companies. You also seem to be of the opinion that US companies are somehow "members" of IETF. Finally, you seem to believe that IETF's mission is to endorse the Clinton administraton's cryptography policy by developing standards which are consistent with that policy. None of these is consistent with IETF policy. IETF is international in scope and does not exist to favor US companies in any way, regardless of how they might be impeded by their government. IETF is not a membership organization, and does not recognize companies as members. IETF policy is that individuals, not representatives of organizations, are the technical contributors to its working groups. [see RFC 1603, sect 1.0, next to last paragraph] IETF emphatically does not endorse the policies of governments that prohibit use of encryption, restrict the export of cryptographic technology, or restrict key lengths, or mandate government recovery of keys. [see RFC 1984] If you're trying to acheive such ends, you're in the wrong organization. Keith From owner-ietf-smime Wed May 7 15:36:37 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA16027 for ietf-smime-bks; Wed, 7 May 1997 15:36:37 -0700 (PDT) Received: from enterprise.powerup.com.au (root@enterprise.powerup.com.au [203.2.122.69]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA16023 for ; Wed, 7 May 1997 15:36:34 -0700 (PDT) Received: from lindsay (ts0415.powerup.com.au [203.18.83.143]) by enterprise.powerup.com.au (8.8.5/8.6.10) with SMTP id WAA22429; Wed, 7 May 1997 22:34:23 GMT Date: Wed, 7 May 1997 22:34:23 GMT Message-Id: <199705072234.WAA22429@enterprise.powerup.com.au> CC: ietf-smime@imc.org From: Lindsay Mathieson Subject: Re: Restarting the 40-bit debate X-Mailer: Black Paw Communications's MailCat for Win32 Release Vs 2.1.0.2 To: Keith Moore Sender: owner-ietf-smime@imc.org Precedence: bulk >PGP has a reputation which >gives it credibility in certain circles and undermines its >credibility in others. The only problem I have with implementing PGP, is its chaotic (well non-existent) programmers API, and no windows implementation -- Lindsay Mathieson Black Paw Communications http://www.blackpaw.com/ From owner-ietf-smime Wed May 7 15:37:38 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA16053 for ietf-smime-bks; Wed, 7 May 1997 15:37:38 -0700 (PDT) Received: from enterprise.powerup.com.au (root@enterprise.powerup.com.au [203.2.122.69]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id PAA16047 for ; Wed, 7 May 1997 15:37:33 -0700 (PDT) Received: from lindsay (ts0415.powerup.com.au [203.18.83.143]) by enterprise.powerup.com.au (8.8.5/8.6.10) with SMTP id WAA22395; Wed, 7 May 1997 22:34:17 GMT Date: Wed, 7 May 1997 22:34:17 GMT Message-Id: <199705072234.WAA22395@enterprise.powerup.com.au> CC: ietf-smime@imc.org From: Lindsay Mathieson Subject: RE: Restarting the 40-bit debate X-Mailer: Black Paw Communications's MailCat for Win32 Release Vs 2.1.0.2 To: Blake Ramsdell Sender: owner-ietf-smime@imc.org Precedence: bulk >It seems that US companies with an interest in international sales >may >be a large faction of the overall IETF membership, but I might be >wrong. I suspect so. There are many companies & independant developers from all over the world here as well. I'm afraid what does tend to tick me off, is the assumption that the interests of US companies are the same as everybody else's - "Whats good for America is good for the rest of the world ..." -- Lindsay Mathieson Black Paw Communications http://www.blackpaw.com/ From owner-ietf-smime Wed May 7 15:55:14 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id PAA16253 for ietf-smime-bks; Wed, 7 May 1997 15:55:14 -0700 (PDT) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.5/8.7.3) with SMTP id PAA16249 for ; Wed, 7 May 1997 15:55:03 -0700 (PDT) Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC5AFE.F531DCD0@cane.deming.com>; Wed, 7 May 1997 15:54:34 -0700 Message-ID: From: Blake Ramsdell To: "'Lindsay Mathieson'" Cc: "'ietf-smime@imc.org'" Subject: RE: Restarting the 40-bit debate Date: Wed, 7 May 1997 15:54:32 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk On Wednesday, May 07, 1997 3:34 PM, Lindsay Mathieson [SMTP:bpc@blackpaw.com] wrote: > I'm afraid what does tend to tick me off, is the assumption that the > interests of US companies are the same as everybody else's - "Whats good for > America is good for the rest of the world ..." The only thing that I'm doing is recommending that the IETF standard support a 40-bit algorithm in addition to a strong cryptographic algorithm. Nobody said that it was good for anyone except for US for-profit software companies that implement S/MIME in exportable products. The only reason for pushing the issue is that I believe that a large enough group of people are interested in this feature to make it important to implement, and I don't believe that it hurts anyone if implemented and used properly, which seems like it would be a no-brainer to put in the spec. I'm certainly not trying to make some political statement about "America is superior to all other countries" -- certainly in the international cryptographic game we're not. Blake From owner-ietf-smime Wed May 7 16:11:47 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA16458 for ietf-smime-bks; Wed, 7 May 1997 16:11:47 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA16454 for ; Wed, 7 May 1997 16:11:44 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id TAA10899; Wed, 7 May 1997 19:11:17 -0400 (EDT) Message-Id: <199705072311.TAA10899@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Lindsay Mathieson cc: Keith Moore , ietf-smime@imc.org Subject: Re: Restarting the 40-bit debate In-reply-to: Your message of "Wed, 07 May 1997 22:34:23 GMT." <199705072234.WAA22429@enterprise.powerup.com.au> Date: Wed, 07 May 1997 19:11:17 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > The only problem I have with implementing PGP, is its chaotic (well > non-existent) programmers API, and no windows implementation I was thinking more of the PGP data format than of utilities that call PGP. Granted, PGP would be a lot more widely deployed by now if it had a callable API. Keith From owner-ietf-smime Wed May 7 16:22:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id QAA16582 for ietf-smime-bks; Wed, 7 May 1997 16:22:16 -0700 (PDT) Received: from [165.227.249.100] (dharma.proper.com [165.227.249.100]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id QAA16578 for ; Wed, 7 May 1997 16:22:14 -0700 (PDT) Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 7 May 1997 16:22:24 -0700 To: ietf-smime@imc.org From: "Paul E. Hoffman" Subject: RE: Restarting the 40-bit debate Sender: owner-ietf-smime@imc.org Precedence: bulk Hello!!? Anybody home?!?! Sorry for the sarcasm, but I thought I had made my request explict. Let me try again. We are discussing a protocol here. It is defined in a spec. The spec is publicly available. Is there something wrong with the spec? Does it force weak cryptography? The reason the spec has a 40-bit component is that a competing protocol that doesn't have a 40-bit component has had very little implementation in the years that it has been out. There may be other reasons for this, but what I've heard from US implementors has been that they couldn't implement it without a weak cryptography component, and what I've heard from the one international developer I talked to was that they weren't going to bother with it unless it was clear that US companies would. Thus, there is a desire for a second protocol that might get a bit more implemenentation. If there was wide implementation of the existing protocol this protocol would be worse than useless, it would be destructive. However, the opposite is true. It's mid-1997, and less than 1% of Internet email users have good security or authentication. Let's all work together on that Bad Situation, shall we? The politics behind the lack of implementation for the other spec do *not* matter; the viability of the current spec *does*. If the current spec requires weak cryptography, we don't want it. Period. If the current spec handles the weak cryptography in a fashion that allows people who don't want to touch weak cryptography to still work with the spec, then it is good. Keith, Lindsay, and yes, even Blake: get back on topic. There is work to be done here. Arguing about what's best for US industry, why US laws are bad, and so on, IS A WASTE OF OUR TIME HERE. Looking carefully at the spec and making sure it does not mandate weak cryptography is part of the work at hand. (And, yes, there are still many other issues on the open issues list.) --Paul E. Hoffman, Director --Internet Mail Consortium From owner-ietf-smime Wed May 7 17:08:03 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id RAA16972 for ietf-smime-bks; Wed, 7 May 1997 17:08:03 -0700 (PDT) Received: from btw.plaintalk.bellevue.wa.us (btw.plaintalk.bellevue.wa.us [204.157.220.237]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id RAA16968 for ; Wed, 7 May 1997 17:07:59 -0700 (PDT) Received: from imo.plaintalk.bellevue.wa.us (imo.plaintalk.bellevue.wa.us [192.168.1.7]) by btw.plaintalk.bellevue.wa.us (8.8.5/8.7.3/dpg hack 14dec96) with ESMTP id RAA07904; Wed, 7 May 1997 17:08:11 -0700 (PDT) Received: (from dennisg@localhost) by imo.plaintalk.bellevue.wa.us (8.7.5/8.7.3/dpg hack 5may96) id RAA01191; Wed, 7 May 1997 17:08:10 -0700 (PDT) Message-Id: <199705080008.RAA01191@imo.plaintalk.bellevue.wa.us> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Received: by NeXT.Mailer (1.118.2) From: Dennis Glatting Date: Wed, 7 May 97 17:08:07 -0700 To: Keith Moore Subject: Re: Restarting the 40-bit debate cc: Blake Ramsdell , "'ietf-smime@imc.org'" Reply-To: dennis.glatting@plaintalk.bellevue.wa.us References: <199705072140.RAA10644@spot.cs.utk.edu> Sender: owner-ietf-smime@imc.org Precedence: bulk From: Keith Moore Date: Wed, 07 May 1997 17:40:16 -0400 > > I think the point is that within the domain of US commercial for-profit > > software companies, strong-encryption-only specs are only going to > > appeal to those companies that don't consider their international sales > > to be important. > > > > In my opinion, these companies are missing out on a large market that > > wants products. [...] > > > > It seems that US companies with an interest in international sales may > > be a large faction of the overall IETF membership, but I might be wrong. > > You seem to be of the opinion that IETF exists to provide market > opportunities to US companies. You also seem to be of the > opinion that US companies are somehow "members" of IETF. > Finally, you seem to believe that IETF's mission is to endorse > the Clinton administraton's cryptography policy by > developing standards which are consistent with that policy. > > None of these is consistent with IETF policy. > > IETF is international in scope and does not exist to favor US > companies in any way, regardless of how they might be impeded by > their government. > > IETF is not a membership organization, and does not recognize > companies as members. IETF policy is that individuals, not > representatives of organizations, are the technical > contributors to its working groups. [see RFC 1603, sect 1.0, > next to last paragraph] > > IETF emphatically does not endorse the policies of > governments that prohibit use of encryption, restrict the > export of cryptographic technology, or restrict key lengths, > or mandate government recovery of keys. [see RFC 1984] > At the last IETF a presentation was given showing IETF meeting attendance verses location. When meetings were held outside of North America attendance was low. In San Jose, attendance was high. Both lows and highs were compared against meetings held in other North American cities. I suspect from that data, my own meeting attendance, and cursory examination of previous "IETF MAILING: REGISTERED ATTENDEES" mail messages, American companies do compose a substantial percentage of IETF participants. The IETF may not endorse crypto policies such as the US Government's but those policies do have an impact on the work coming out of the IETF. For example, TLS includes 40 bit crypto. The GSS-API SESAME mechanism proposal includes 40 bit crypto. The IPsec group made the 56 bit DES-CBC ESP transform mandatory to make a political statement to the United States government and to encourage US companies to put pressure on the government to relax export restrictions; however, a 40 bit ESP transform draft was recently submitted. S/MIME, I remember reading in a document from RSA's Web site, includes 40 bit crypto due to US export restrictions and the desire to have an international interoperabe base, though S/MIME is not an IETF standard. I think the conclusion that US export policies influence standards is fair. > If you're trying to achieve such ends, you're in the wrong > organization. > -dpg From owner-ietf-smime Wed May 7 18:14:26 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA17585 for ietf-smime-bks; Wed, 7 May 1997 18:14:26 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA17578; Wed, 7 May 1997 18:14:23 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-8 #8694) id <01IIL513ED0W99E51G@INNOSOFT.COM>; Wed, 7 May 1997 18:13:42 PDT Date: Wed, 07 May 1997 15:00:50 -0700 (PDT) From: Ned Freed Subject: RE: Restarting the 40-bit debate In-reply-to: "Your message dated Wed, 07 May 1997 13:40:32 -0700" To: Blake Ramsdell Cc: "'Keith Moore'" , "'Paul E. Hoffman'" , "'ietf-smime@imc.org'" Message-id: <01IILIPD5N6O99E51G@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-smime@imc.org Precedence: bulk I normally partipate in these discussions as a member of the IETF. I'm going to depart from that position in this posting and answer as an Innosoft corporate officer and employee. > > I don't believe this. First, there are many factors involved besides > > US export rules -- including the existance of patents and the > > licensing practices of certain firms. PGP has a reputation which > > gives it credibility in certain circles and undermines its credibility > > in others. Second, people are shipping strong encryption products > > both inside and outside the United States. > I think the point is that within the domain of US commercial for-profit > software companies, strong-encryption-only specs are only going to > appeal to those companies that don't consider their international sales > to be important. I disagree and I offer the company I work for, Innosoft, as a counterexample. Innosoft currently implements and sells email products internationally. About 45% of our sales and revenues are non-US. We have numerous international distributors and we expend considerable effort as a company working with them. As such, I take it as given that we regard international sales as extremely important. Now, as it happens Innosoft also implements strong encryption services for email (not S/MIME -- this is SASL based transport level stuff) with no provisions for key escrow and no plans to ever add such provisions, which of course we then can only sell to the domestic subset of our customer base. We do not implement weak encryption or key escrow services and have no intention of doing so -- such services simply do not appeal to us as a possible product offering. I suppose we might consider adding them if we had a direct request from an international customer to do so and the customer was fully aware of the consequences of their use, but I've yet to encounter a customer that meets these criteria. > In my opinion, these companies are missing out on a large market that > wants products. We have a large customer base that is non-US, > non-Canada and I certainly don't consider ourselves to be the largest > company out there (which means that the Apples, IBMs and Microsofts of > the world are much more interested in this market than I am). Our assessment of our customer base is that they are a pretty savvy lot. They absolutely do want encryption products, in fact they want them desperately and they hammer on us constantly to provide them, but they aren't interested in products that only implement weak encryption. And they absolutely do know the difference -- I'm sorry, but I've worked on far too many RFPs that demonstrate such knowledge in abundance to believe otherwise. In fact it's hard enough trying to sell our domestic customers on strong encryption after they've read somewhere that such-and-such or so-and-so has been compromised, let alone weak encryption where every week it seems there's another result showing how easy it is in practice to break. The best we could hope for were we to offer weak encryption internationally would be for them to dismiss us as naive fools. A more likely outcome, unfortunately, would be for them to reassess us as knaves trying to sell them a pig in a poke. Either way it falls out this isn't an acceptable tradeoff for us. I suppose we might win in the short term with our less informed customers but we'd lose in the long run, because people have a way of finding these things out. And besides, we have a high degree of committment to our customers to provide them with the best technology that's available, and weak encryption does exactly qualify here. My view of standards requiring weak crypto is that they are simply a last-ditch attempt to generate credibility for these sorts of solutions in the marketplace so that US companies can sell inadequate products to international clientele. Unfortunately the lack of credibility of such solutions is inherent in the solutions themselves so no amount of standards sanction is going to help. In the end all such sanctioning will do is cause a loss of credibility in the standards process itself. The long and short of it is that US manufacturers have been boxed in by the actions of the US government, and the idea that standards will make weak encryption acceptable is really nothing but wishful thinking. This I believe to be the cold, hard, reality, a situation I estimate is costing Innosoft around half a million dollars a year at the present time in lost revenue (more as we continue to grow, of course), and also a situation that our offering weak encryption products won't change appreciably. And while I (naturally) have enormous sympathy for other companies caught in the same bind as we are, this doesn't mean I'm willing to ignore the evidence of my own experience and endorse the use of weak encryption in standards track documents. My sincere belief is that this is simply not in my company's best interest. (I've argued elsewhere with my IETF hat on that it isn't in the IETF's best interest either.) > It seems that US companies with an interest in international sales may > be a large faction of the overall IETF membership, but I might be wrong. I suspect you are quite right in your demographics of the participants here, but as my example shows, your assessment of what necessarily follows from this isn't right in at least one case that I have knowledge of. Ned From owner-ietf-smime Wed May 7 18:23:07 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id SAA17696 for ietf-smime-bks; Wed, 7 May 1997 18:23:07 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id SAA17691 for ; Wed, 7 May 1997 18:23:04 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id VAA11203; Wed, 7 May 1997 21:22:31 -0400 (EDT) Message-Id: <199705080122.VAA11203@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: dennis.glatting@plaintalk.bellevue.wa.us cc: Keith Moore , Blake Ramsdell , "'ietf-smime@imc.org'" Subject: Re: Restarting the 40-bit debate In-reply-to: Your message of "Wed, 07 May 1997 17:08:07 PDT." <199705080008.RAA01191@imo.plaintalk.bellevue.wa.us> Date: Wed, 07 May 1997 21:22:31 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk > At the last IETF a presentation was given showing IETF meeting > attendance verses location. When meetings were held outside > of North America attendance was low. In San Jose, attendance > was high. Both lows and highs were compared against meetings > held in other North American cities. I suspect from that data, > my own meeting attendance, and cursory examination of > previous "IETF MAILING: REGISTERED ATTENDEES" mail > messages, American companies do compose a substantial > percentage of IETF participants. Companies, whether they're based the United States or otherwise, don't participate in IETF working groups. Individuals do. Those individuals cannot be assumed to represent the companies they work for, and at any rate, IETF doesn't recognize such representation. And while there are indeed many IETF participants from the United States, there is no reason to assume that anything remotely resembling a consensus of those participants, support the interests of US companies that want to export weak cryptography. > The IETF may not endorse crypto policies such as the US > Government's but those policies do have an impact on the work > coming out of the IETF. For example, TLS includes 40 bit crypto. > The GSS-API SESAME mechanism proposal includes 40 bit crypto. > The IPsec group made the 56 bit DES-CBC ESP transform mandatory > to make a political statement to the United States government > and to encourage US companies to put pressure on the government > to relax export restrictions; however, a 40 bit ESP transform > draft was recently submitted. All of the examples you give are merely proposals. None of them has been approved for the Internet standards track. > S/MIME, I remember reading in a > document from RSA's Web site, includes 40 bit crypto due to US > export restrictions and the desire to have an international > interoperabe base, though S/MIME is not an IETF standard. S/MIME is not a standard in any formal sense -- that's just a term that RSA likes to use to encourage people to buy in to it. Even calling it a de facto standard would be a stretch. If S/MIME is a standard, so is PGP. Keith From owner-ietf-smime Wed May 7 19:39:42 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA18597 for ietf-smime-bks; Wed, 7 May 1997 19:39:42 -0700 (PDT) Received: from enterprise.powerup.com.au (root@enterprise.powerup.com.au [203.2.122.69]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA18592 for ; Wed, 7 May 1997 19:39:36 -0700 (PDT) Received: from lindsay (ts2210.powerup.com.au [203.18.82.74]) by enterprise.powerup.com.au (8.8.5/8.6.10) with SMTP id CAA26308; Thu, 8 May 1997 02:33:35 GMT Date: Thu, 8 May 1997 02:33:35 GMT Message-Id: <199705080233.CAA26308@enterprise.powerup.com.au> CC: ietf-smime@imc.org From: Lindsay Mathieson Subject: RE: Restarting the 40-bit debate X-Mailer: Black Paw Communications's MailCat for Win32 Release Vs 2.1.1 To: Blake Ramsdell Sender: owner-ietf-smime@imc.org Precedence: bulk >I'm certainly not trying to make some political statement about >"America >is superior to all other countries" -- certainly in the international >cryptographic game we're not. I didn't think you where. What I thought you where saying is that the it would be good for everyone if the standard allowed weak 40 bit encryption so that US companies could export. -- Lindsay Mathieson Black Paw Communications http://www.blackpaw.com/ From owner-ietf-smime Wed May 7 19:39:29 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA18587 for ietf-smime-bks; Wed, 7 May 1997 19:39:29 -0700 (PDT) Received: from enterprise.powerup.com.au (root@enterprise.powerup.com.au [203.2.122.69]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA18582; Wed, 7 May 1997 19:39:25 -0700 (PDT) Received: from lindsay (ts2210.powerup.com.au [203.18.82.74]) by enterprise.powerup.com.au (8.8.5/8.6.10) with SMTP id CAA26186; Thu, 8 May 1997 02:32:55 GMT Date: Thu, 8 May 1997 02:32:55 GMT Message-Id: <199705080232.CAA26186@enterprise.powerup.com.au> CC: ietf-smime@imc.org From: Lindsay Mathieson Subject: RE: Restarting the 40-bit debate X-Mailer: Black Paw Communications's MailCat for Win32 Release Vs 2.1.1 To: "Paul E. Hoffman" Sender: owner-ietf-smime@imc.org Precedence: bulk >Keith, Lindsay, and yes, even Blake: get back on topic. There is work >to be >done here. Arguing about what's best for US industry, why US laws are >bad, >and so on, IS A WASTE OF OUR TIME HERE. Looking carefully at the spec >and >making sure it does not mandate weak cryptography is part of the work >at >hand. Fair enough - noted. I'll keep my mouth shut re politics et al from now on. My apologies for "knee jerking" (it was 6am here!) 40 bit encryption as a "MAY" or "SHOULD" is fine be me anyway. -- Lindsay Mathieson Black Paw Communications http://www.blackpaw.com/ From owner-ietf-smime Wed May 7 19:45:16 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id TAA18675 for ietf-smime-bks; Wed, 7 May 1997 19:45:16 -0700 (PDT) Received: from spot.cs.utk.edu (SPOT.CS.UTK.EDU [128.169.92.189]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id TAA18668 for ; Wed, 7 May 1997 19:45:13 -0700 (PDT) Received: from cs.utk.edu by spot.cs.utk.edu with ESMTP (cf v2.11c-UTK) id WAA11462; Wed, 7 May 1997 22:44:43 -0400 (EDT) Message-Id: <199705080244.WAA11462@spot.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ To: ietf-smime@imc.org Subject: comments on draft-dusse-smime-msg cc: moore@cs.utk.edu From: Keith Moore Date: Wed, 07 May 1997 22:44:43 -0400 Sender: owner-ietf-smime@imc.org Precedence: bulk Any usable encryption protocol must specify at least one strong MUST IMPLEMENT encryption algorithm. (I would define this as one algorithm that has not been broken using only knowledge of the algorithm used and the ciphertext). If there is no MUST IMPLEMENT algorithm, it fails the interoperability requirement. If the only MUST IMPLEMENT algorithms are weak ones, the protocol isn't technically sound -- it fails to provide the service that it claims to provide. As far as I know, DES-EDE3-CBC/tripleDES is sufficiently strong, but the current draft says only "SHOULD implement". This is not sufficient. Engineering standards for bridge design do not allow designs that are known to collapse under load. Neither should IETF approve an encryption standard that is known to be easily breakable. Keith From owner-ietf-smime Thu May 8 07:54:05 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id HAA27621 for ietf-smime-bks; Thu, 8 May 1997 07:54:05 -0700 (PDT) Received: from guardian.guard.ncsc.mil (guardian.guard.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.5/8.7.3) with SMTP id HAA27617 for ; Thu, 8 May 1997 07:54:02 -0700 (PDT) Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id KAA19231 for ; Thu, 8 May 1997 10:53:55 -0400 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma019229; Thu May 8 10:53:51 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id KAA04930 for ; Thu, 8 May 1997 10:41:00 -0400 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id KAA03688; Thu, 8 May 1997 10:43:22 -0400 Date: Thu, 8 May 1997 10:43:22 -0400 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199705081443.KAA03688@argon.ncsc.mil> To: ietf-smime@imc.org Subject: Re: Restarting the 40-bit debate X-Sun-Charset: US-ASCII Sender: owner-ietf-smime@imc.org Precedence: bulk > From: Keith Moore > > You seem to be of the opinion that IETF exists to provide market > opportunities to US companies. You also seem to be of the opinion > that US companies are somehow "members" of IETF. Finally, you seem > to believe that IETF's mission is to endorse the Clinton administraton's > cryptography policy by developing standards which are consistent with > that policy. You seem to be of the opinion that the IETF policy is to promulgate standards that will not be commercially successful. PEM, for example was a well designed mechanism from a security point of view, but failed because it was not flexible enough to accommodate the needs of its users. You seem to be of the opinion that "quality" is a one-dimensional attribute, viz: "However, I sincerely doubt that something as weak as 40 bits can be considered of sufficient quality for the Internet standards track." That's like saying Consumer Reports quality ratings for cars depends only on horsepower. Certainly more is better, but claiming that a 1.8L BMW is of poorer quality than a 4.3L Cavalier is counter-intuitive. There is more than one dimension to be considered. I would argue that "widespread deployment" is one of the more important quality criteria for IETF standards. I believe that John Gilmore, who is no fan of the U.S. Government, would agree - his cryptowall proposal accepted unauthenticated keys as the tradeoff for achieving actual usage. The statement "You also seem to be of the opinion that US companies are somehow "members" of IETF." is mere sound-bite rhetoric, containing more heat than light. No one, certainly not Blake, is under the misapprehension that the IETF has a membership roster or that companies, governments, or universities, US or otherwise, are enrolled as members. Individuals who contribute to the IETF, including the S/MIME working group if it eventually exists, represent their own interests. Those interests may or may not be highly correlated with the interests of their employers/affiliates. I would expect that the smaller the organization, the tighter the correlation. Small software developers should have a particularly strong interest in ensuring that whatever standards they labor to develop will result in increased sales for their companies. Academics, for good or ill, don't have the same incentives. So feel free to contribute to the process, but please refrain from denigrating the motives of the rest of the participants. From owner-ietf-smime Thu May 8 08:44:50 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id IAA28337 for ietf-smime-bks; Thu, 8 May 1997 08:44:50 -0700 (PDT) Received: from nala.qualcomm.com (nala.qualcomm.com [129.46.50.44]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id IAA28333 for ; Thu, 8 May 1997 08:44:48 -0700 (PDT) Received: from [129.46.137.174] (llundblade-mac.qualcomm.com [129.46.137.174]) by nala.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id IAA17863 for ; Thu, 8 May 1997 08:44:31 -0700 (PDT) X-Sender: llundbla@nala.qualcomm.com Message-Id: In-Reply-To: <199705080244.WAA11462@spot.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 8 May 1997 08:43:26 -0700 To: ietf-smime@imc.org From: Laurence Lundblade Subject: comments on the draft, 8bit & binary issues Sender: owner-ietf-smime@imc.org Precedence: bulk The current draft allows the transfer encoding on the secured MIME entities to be 8bit or binary. We've talked about this before, but I'd like to raise the issue again because I think it's probably not the right way of doing it and I'm not sure we've discussed all the points below. I think it's important to separate the binary discussion from the 8bit discussion because there reasons for doing one or the other are quite different. Note also these points are raised for igning and enveloping with application/pkcs7-mime, not multipart signed. Multipart-signed must be 7bit as defined by RFC-1847. Allowing 8bit text mostly avoids the use of quoted-printable/unreadable which is a big issue outside the US. It forces non-USASCII characters to be transfer encoded in a way that makes them less readable than just having the bit stripped (or so I understand). The disadvantage of allowing 8bit text is that in some cases you can't remove a layer of security and forward the message on without changing it. There's no way for the original sender to know what transports the message might be relayed in at a later time. The only safe assumption is 7bit. I would suggest that anyone that can unwrap an application/pcks7-mime message has the ability to transfer decode it. Thus the "quoted-unreadable" argument doesn't apply. The big point in favor of allowing binary is that it saves space by avoiding the layer of base64 on the inside parts in addition to the base64 encoding of the BER encoded PCSK-7 object. I would argue that a factor against allowing binary MIME is difficulty of implementation. I recall in previous discussion that we thought binary was OK because other transport such as HTTP uses it. However, nested multipart objects are not used on the web, and that's when the implementation becomes more difficult. It's certainly not impossible, but it will burden many MIME processors that exist today. There are also mail stores that cannot store binary MIME in common use today. Another argument against binary lack of forwardability for unknown transport as mentioned above in regards to 8bit text. Last, I think having the same transfer encoding requirements, no matter the signing or enveloping format is a desirable thing leading to a simpler standard and simpler implementations and guaranteed forwardability. The primary cost is the increased size for secured binary objects. LL From owner-ietf-smime Thu May 8 10:24:44 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.5/8.7.3) id KAA29812 for ietf-smime-bks; Thu, 8 May 1997 10:24:44 -0700 (PDT) Received: from hail.ncr.disa.mil (hail.ncr.disa.mil [164.117.176.115]) by mail.proper.com (8.8.5/8.7.3) with ESMTP id KAA29808 for ; Thu, 8 May 1997 10:24:41 -0700 (PDT) Received: from ncr.disa.mil ([164.117.176.106]) by hail.ncr.disa.mil (8.7.3/DISA 8.7.3.01) with SMTP id NAA20453; Thu, 8 May 1997 13:20:49 -0400 (EDT) Received: from ccMail by ncr.disa.mil (SMTPLINK V2.11.01) id AA863123004; Thu, 08 May 97 13:19:50 EST Date: Thu, 08 May 97 13:19:50 EST From: "David Gaon" Message-Id: <9704088631.AA863123004@ncr.disa.mil> To: dennis.glatting@plaintalk.bellevue.wa.us, Keith Moore Cc: moore@cs.utk.edu, BlakeR@deming.com, ietf-smime@imc.org Subject: Re[2]: Restarting the 40-bit debate Sender: owner-ietf-smime@imc.org Precedence: bulk Keith You said: >>Companies, whether they're based the United States or otherwise, don't participate in IETF working groups. Individuals do. Those individuals cannot be assumed to represent the companies they work for, and at any rate, IETF doesn't recognize such representation.<< You are playing ostrich here. Whether you like it or not, and whether you want to believe it or not, these individual contributors to the IETF and its proceedings DO REPRESENT their companies and the best interests of their companies, AND NOT NECESSARILY THE BEST INTERESTS OF THE INTERN