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 pro